Resumen Técnico: APEX–Accounting

Declaración del Problema

Si bien los modelos de lenguaje de gran tamaño (LLM) han demostrado competencia al aprobar exámenes de certificación profesional (p. ej., CPA, CMA) y mejorar la calidad general del trabajo, existe una falta de evaluaciones que midan su capacidad para realizar el trabajo real y cotidiano de los contadores. Los benchmarks existentes como AuditBench, FinMaster y AccountingBench suelen depender de transacciones sintéticas, simuladores de solo texto o estudios de caso de una sola empresa que no logran capturar la naturaleza repetitiva, procedimental y densa en documentos del cierre de mes y la teneduría de libros. Los autores argumentan que las evaluaciones actuales no prueban suficientemente el "trabajo real" de los contadores, el cual implica conciliar cuentas, acumular gastos, registrar transacciones y producir informes a través de diversos y complejos contextos empresariales.

Metodología

Diseño del Benchmark (APEX–Accounting)

APEX–Accounting es un benchmark cerrado desarrollado por Mercor en asociación con Ramp, que consta de 160 tareas distribuidas en 10 mundos de empresas generados sintéticamente.

• Construcción de los Mundos: Cada mundo representa una empresa autónoma congelada al cierre de mes, adhiriéndose a los principios de contabilidad de devengo de los EE. UU. (U.S. GAAP). Los mundos se construyeron en cuatro etapas: definición del alcance, especificación detallada (incluyendo "registros trampa" para contradicciones sembradas), derivación de la guía de estilo y generación de archivos. Todos los archivos (hojas de cálculo, PDFs, exportaciones de software contable) son novedosos y han sido filtrados contra fuentes públicas para evitar la memorización.
• Categorías de Tareas: Las 160 tareas se dividen en cuatro categorías:
  1. Conciliación (61 tareas): Vincular dos fuentes, identificar discrepancias y explicarlas o corregirlas.
  2. Entrada de Datos (26 tareas): Registrar transacciones, asientos de diario y facturas.
  3. Análisis de Variaciones (28 tareas): Comparar resultados reales contra presupuestos o expectativas.
  4. Programas de Amortización y Acumulaciones (45 tareas): Construir programas, calcular acumulaciones y arrastrar saldos.
• Participación de Expertos: 42 expertos en contabilidad (mediana de 11 años de experiencia, 52% provenientes de firmas Big Four) redactaron las tareas, las resolvieron para crear "respuestas de oro" (golden responses) y escribieron rúbricas binarias basadas en resultados. Cada tarea incluye un prompt, archivos de entrada requeridos, una respuesta de oro y una rúbrica con un promedio de 13.7 criterios.

Configuración Experimental

• Modelos Evaluados: Se probaron nueve modelos de frontera, incluyendo Claude-Fable-5, Muse-Spark-1.1, GPT-5.6-Sol y otros. Cada modelo ejecutó cada tarea 8 veces, generando 11,520 trayectorias.
• Harnesses (Entornos de Ejecución): Se utilizaron dos entornos de agente:
  • Loop Harness: Una arquitectura estándar de bucle canonical con herramientas (while-loop-with-tools).
  • Ramp Harness: Un entorno especializado construido con Ramp que cuenta con conciencia de reintentos, listas blancas de herramientas, validación y delegación de subagentes para reflejar las restricciones del mundo real de la contabilidad.
• Calificación: Un modelo DeepSeek-v4-Flash, optimizado con un prompt GEPA, sirvió como juez. Fue validado contra la verdad fundamental de expertos humanos (1,687 criterios), alcanzando una precisión del 97.1% (F1 = 0.970). El juez evalúa la salida final contra los criterios de la rúbrica binaria sin acceso al registro de la trayectoria intermedia.
• Métricas:
  • Media de Criteria@3: La métrica principal, que promedia el porcentaje de criterios de la rúbrica cumplidos a través de 3 ejecuciones seleccionadas al azar por tarea.
  • Pass@k / Pass^k: Mide el techo de capacidad (Pass@8: aprobar al menos una vez en 8 intentos) y la consistencia (Pass^8: aprobar los 8 intentos).
  • Ablación de Costos: Experimentos que varían el presupuesto de tokens de $1 a$50 por tarea para analizar la relación entre el gasto y el rendimiento.

Resultados Clave

Rendimiento del Leaderboard

• Mejor Desempeño: Claude-Fable-5 (Max) logró el Mean Criteria@3 más alto de 56.4%, seguido de Muse-Spark-1.1 (52.6%) y GPT-5.6-Sol (51.5%).
• Brecha de Consistencia: A pesar de los altos puntajes de Mean Criteria@3, la consistencia sigue siendo extremadamente baja. Ningún modelo logró un puntaje Pass^8 superior al 2.6% (GPT-5.6-Sol). El Pass@8 más alto fue de 21.5% (Muse-Spark-1.1), lo que indica que, si bien los modelos pueden resolver una tarea ocasionalmente, no pueden hacerlo de manera confiable de principio a fin.
• Dificultad por Categoría: "Schedules & Accruals" resultó ser la categoría más difícil, con todos los modelos puntuando entre 7 y 21 puntos porcentuales por debajo de las otras categorías, lo que refleja su naturaleza de múltiples pasos y alta carga de juicio.

Análisis de Costo y Presupuesto

• Impacto del Presupuesto de Tokens: Aumentar el presupuesto de $1 a$50 mejoró significamente los puntajes para modelos costosos (por ejemplo, Claude-Fable-5 ganó +43.4 puntos porcentuales), mientras que los modelos más económicos (por ejemplo, Muse-Spark-1.1) vieron mejoras mínimas.
• Paradoja de Simpson: El estudio observó un caso de la Paradoja de Simpson: aunque aumentar el presupuesto total elevó los puntajes, dentro de un presupuesto fijo, las tareas donde los modelos gastaron más tokens se correlacionaron con puntajes más bajos. Esto se atribuye a la dificultad de la tarea: las tareas más difíciles consumen más tokens pero siguen siendo más difíciles de resolver.
• Impacto del Harness: Cambiar del Loop Harness estándar al especializado Ramp Harness resultó en un cambio promedio insignificante (+1.2 puntos porcentuales), lo que sugiere que la capacidad del modelo es un impulsor de rendimiento más fuerte que la arquitectura específica del agente para estas tareas.

Análisis de Fallos

El análisis de las trayectorias de bajo puntaje de los tres modelos principales reveló un perfil de falla notablemente similar:

• Dominio del Razonamiento: Los fallos de razonamiento representaron el 59–79% de todos los errores anotados.
• Modos de Fallo Específicos: Los sub-fallos más comunes fueron el razonamiento no numérico (aplicar lógica errónea a datos no numéricos) y los errores de manejo de datos (filtrado, unión o agregación incorrectos).
• Información vs. Lógica: Los modelos encuentran de manera confiable los archivos de entrada correctos (los fallos de recolección de información fueron raros). El principal modo de fallo fue el manejo incorrecto del razonamiento de múltiples pasos sobre esos datos: sustituir la lógica de autorización correcta, perder resultados intermedios correctos o no llevar las conclusiones hasta la respuesta final.
• Uso de Herramientas: Ningún fallo anotado involucró errores de uso de herramientas, lo que sugiere que las arquitecturas de agentes actuales son suficientes para la interacción con herramientas, pero la capacidad de razonamiento subyacente es el cuello de botella.

Significancia y Reivindicaciones

El artículo afirma que APEX–Accounting proporciona la primera evaluación rigurosa de los modelos de frontera en flujos de trabajo contables del mundo real, yendo más allá de los exámenes de certificación hacia la aplicación práctica.

• Limitaciones Actuales: Los resultados indican que, si bien los modelos de frontera pueden recuperar información y realizar pasos aislados, aún no son capaces de cerrar los libros de manera supervisada y confiable. Los bajos puntajes de Pass^8 (máximo 2.6%) resaltan una brecha significativa entre el "techo de capacidad" y el "despliegue confiable".
• Dirección Futura: Los autores argumentan que el progreso vendrá menos de la mejora de los entornos de agentes (que mostraron un impacto mínimo) y más de la mejora de los propios modelos. Específicamente, sugieren la necesidad de un entrenamiento específico en contabilidad para inculcar la disciplina necesaria para llevar a cabo resultados de múltiples pasos, detectar contradicciones en documentos y negarse a registrar asientos sin evidencia suficiente.
• Utilidad del Benchmark: Como un benchmark cerrado, APEX–Accounting permite la evaluación de cualquier modelo de frontera previa solicitud, ofreciendo una métrica estandarizada para la industria para rastrear el progreso en la automatización del trabajo de conocimiento especializado.