FinTrace: Evaluación a Nivel de Trayectoria del Llamado a Herramientas de LLM para Tareas Financieras

FinTrace (arXiv:2604.10015) llega una semana después de FinToolBench, que registré la última vez, y los dos artículos están en conversación directa entre sí. Mientras que FinToolBench mide si un agente llama a las herramientas adecuadas, FinTrace plantea la pregunta más difícil: incluso cuando un agente llama a las herramientas correctas, ¿realmente razona sobre los resultados? Esa distinción es el eje del artículo y, creo, el eje de todo el problema del agente de escritura de Beancount.

El artículo

Cao et al. presentan FinTrace, un benchmark de 800 trayectorias anotadas por expertos que abarcan 34 categorías de tareas financieras del mundo real a través de niveles de dificultad fácil, medio y difícil. Los autores construyen su evaluación en torno a una rúbrica de nueve métricas organizadas en cuatro ejes: corrección de la acción (F1 de llamado a herramientas, relevancia de la tarea), eficiencia de ejecución (eficiencia de pasos, puntuación de redundancia), calidad del proceso (progresión lógica, utilización de información, puntuación de progreso) y calidad de salida (tasa de aprobación de tareas, calidad de la respuesta final). Evalúan 13 LLM y también publican FinTrace-Training, un conjunto de datos de 8.196 trayectorias de preferencia seleccionadas para el ajuste fino.

La afirmación central es que los modelos de frontera han dominado la selección de herramientas pero fallan sistemáticamente en el paso más difícil: usar lo que las herramientas devuelven. El benchmark sondea esto con una escala de 5 puntos para la utilización de información, progresión lógica y puntuación de progreso, además de métricas algorítmicas para el F1 de herramientas y la eficiencia de pasos.

Ideas clave

• El modelo con mejor desempeño, Claude-Opus-4.6, alcanza un F1 de Llamado a Herramientas de 0,896 —una selección sólida— pero obtiene solo 3,23/5 en Utilización de Información, la más débil de las cuatro métricas orientadas a la salida.
• La Tasa de Aprobación de Tareas de Claude-Opus-4.6 es de 2,65/5, y la Calidad de la Respuesta Final es de 3,34/5; incluso el modelo superior no produce de manera consistente respuestas correctas y completas.
• Qwen-3.5-9B exhibe un patrón degenerado: Eficiencia de Pasos (1,000) y Redundancia (1,000) casi perfectas porque apenas llama a ninguna herramienta, lo que se refleja en un F1 de Llamado a Herramientas de 0,109. Eficiente pero inútil.
• El entrenamiento en FinTrace-Training mejora las métricas de proceso intermedio (la Progresión Lógica aumenta de 2,29 a 2,56 con DPO; la Puntuación de Progreso de 2,00 a 2,30), pero la Calidad de la Respuesta Final permanece estancada —ninguna variante supera significativamente el promedio de 1,21 en la escala de 1 a 5 para modelos pequeños.
• DPO supera a SFT en la supresión de modos de fallo catastróficos: la proporción de puntuaciones de Progresión Lógica de 1 cae del 11,9% (SFT) al 9,5% (DPO).
• La subcategoría universalmente peor en los 13 modelos es el Razonamiento QA, donde Claude-Opus-4.6 logra solo 0,62 en total —un techo difícil compartido incluso por el modelo de frontera más fuerte.

Qué se sostiene — y qué no

El hallazgo central —que la selección de herramientas y el razonamiento sobre las herramientas son disociables— está bien motivado y la rúbrica de cuatro ejes es una contribución genuina. Los benchmarks anteriores como FinToolBench se detienen en las trazas de ejecución; FinTrace añade métricas de calidad del proceso juzgadas por LLM que exponen lo que sucede entre medias. El κ de Cohen inter-evaluador de 0,89 en la validación de 100 muestras es alentador para un benchmark construido en parte sobre jueces LLM.

Dicho esto, varias elecciones metodológicas limitan lo que puedo extraer de las cifras a primera vista. Las 34 categorías de tareas no se enumeran en el artículo principal —se relegan al Apéndice B— por lo que no puedo saber qué tan representativas son de la práctica financiera del mundo real. Los niveles de dificultad se definen por rangos percentiles dentro del propio grupo de consultas del benchmark, lo cual es una medida circular: "difícil" solo significa inusual en relación con las otras 800 trayectorias, no difícil en un sentido absoluto.

El análisis de ajuste fino es frustrante. Entrenar un modelo de 9B en FinTrace-Training mejora el razonamiento intermedio, pero la calidad de la respuesta final sigue rota. El artículo atribuye esto a una "desconexión" entre el proceso y la salida, pero no explica por qué. La explicación más plausible —que un modelo de 9B carece del recuerdo de hechos y la capacidad aritmética necesaria para las tareas financieras, independientemente de la calidad de la trayectoria— se deja sin abordar. Mostrar los resultados de DPO solo para Qwen-3.5-9B también hace imposible saber si los modelos más grandes se benefician más.

También soy escéptico sobre la agregación de la puntuación global. Combinar métricas algorítmicas (F1 ∈ [0,1]) con puntuaciones juzgadas por LLM en escalas Likert de 1 a 5 normalizando a [0,1] y promediando combina tipos de fallos muy diferentes. Un modelo que llama a las herramientas equivocadas por completo no es el mismo tipo de error que un modelo que llama a las herramientas correctas y luego ignora el resultado.

Por qué esto es importante para la IA financiera

El hallazgo principal se traslada directamente al problema de escritura (write-back) de Beancount. Un agente que llama de manera confiable a las herramientas de CLI de Beancount correctas pero luego malinterpreta el resultado —por ejemplo, analizando una respuesta de balance de situación y publicando en la cuenta equivocada— es peor que ninguna automatización: produce entradas de libro mayor erróneas con seguridad que parecen correctas para un revisor casual.

La métrica de Utilización de Información es la que vigilaría más de cerca para cualquier agente de Beancount. El hecho de que el mejor modelo disponible obtenga una puntuación de 3,23/5 en esto en un benchmark financiero controlado debería ser una restricción obligatoria para cualquier despliegue en producción. Argumenta a favor de la revisión humana obligatoria de cualquier operación de escritura, al menos hasta que veamos esa puntuación consistentemente por encima de 4,0.

FinTrace también confirma lo que ReDAct sugirió la semana pasada: la arquitectura correcta no es el razonamiento de LLM de extremo a extremo, sino una canalización que externaliza la verificación. Un agente que selecciona bien las herramientas (F1 de herramientas ~0,9) y luego pasa los resultados a un paso de validación separado antes de actuar es más defendible que uno que intenta razonar sobre la salida bruta de la herramienta en una sola pasada.

Qué leer a continuación

• FinMCP-Bench (arXiv:2603.24943): el artículo complementario que utiliza MCP como el estándar de interfaz de herramientas, el siguiente en la lista de lectura —directamente comparable a FinTrace pero construido sobre una capa de protocolo diferente.
• "Benchmarking LLM Tool-Use in the Wild" (arXiv:2604.06185): apareció simultáneamente y evalúa el llamado a herramientas fuera de las finanzas; aclararía si la brecha de utilización de información es específica del dominio o general.
• "Data-Driven Function Calling Improvements in Large Language Model for Online Financial QA" (arXiv:2604.05387): aborda los mismos modos de fallo del llamado a herramientas desde una perspectiva de datos de entrenamiento y puede explicar lo que le falta al DPO de FinTrace-Training.