El artículo​

Zhao, Jin, Li y Gao de la Universidad de Pekín presentan FinRAGBench-V, un benchmark bilingüe construido a partir de documentos financieros reales: informes de investigación, estados financieros, folletos, artículos académicos, revistas y artículos de noticias. El corpus de recuperación es sustancial (60,780 páginas en chino y 51,219 páginas en inglés en aproximadamente 1,100 documentos por idioma), emparejado con 1,394 pares de preguntas y respuestas anotados por humanos que abarcan siete categorías de preguntas: inferencia de texto, extracción de gráficos y tablas, cálculo numérico, consultas sensibles al tiempo y razonamiento de múltiples páginas. Más allá del conjunto de datos, la contribución central del artículo es RGenCite, un sistema base que genera respuestas junto con citas visuales a nivel de píxel en forma de coordenadas de cuadros delimitadores (bounding boxes) que marcan las regiones específicas del documento que respaldan cada afirmación.

Ideas clave​

• La recuperación multimodal domina a la de solo texto por un margen abrumador: ColQwen2, un recuperador de lenguaje visual basado en incrustaciones de imágenes de páginas, logra un Recall@10 del 90.13% (chino) y 85.86% (inglés). Los mejores recuperadores basados en texto, BM25 y BGE-M3, alcanzan un máximo de alrededor del 42.71%. Esta brecha no es un error de redondeo.
• La precisión de generación es baja incluso para modelos de vanguardia: GPT-4o en inglés alcanza un 43.41% de precisión (ROUGE 24.66); o4-mini en chino alcanza el 58.13% (ROUGE 38.55). Estos son modelos propietarios de primer nivel con una sólida recuperación implementada.
• Las citas a nivel de página funcionan; las de nivel de bloque no: El recall a nivel de página se sitúa entre el 75 y el 93% para los mejores modelos. El recall a nivel de bloque (saber qué celda específica de una tabla o región de un gráfico fundamenta una afirmación) cae al 20–61%. Esta es la brecha clave para la auditabilidad.
• El razonamiento numérico y la inferencia de múltiples páginas son lo primero que hace fallar a los modelos: Las preguntas que requieren cálculos a través de páginas o períodos temporales es donde la precisión cae más abruptamente en todos los sistemas probados.
• Los modelos propietarios superan sustancialmente a las alternativas de código abierto: La brecha entre las API cerradas y el código abierto es mayor aquí que en la mayoría de los benchmarks de NLP, lo que sugiere que el razonamiento financiero visual sigue siendo un problema sin resolver para los modelos abiertos.
• La autoevaluación para las citas es imperfecta: El evaluador de citas basado en el recorte de imágenes logra un r de Pearson = 0.68 con los juicios humanos; razonable, pero no lo suficientemente confiable como para confiar plenamente sin muestreo.

Qué se sostiene — y qué no​

El hallazgo sobre la recuperación es el resultado más creíble del artículo. Una brecha de casi 50 puntos porcentuales entre los recuperadores multimodales y los de solo texto en más de 60,000 páginas es demasiado grande para ignorarla. Cuando se aplica OCR a un documento financiero antes de indexarlo, se destruyen las señales de diseño estructural (en qué columna aparece un número, si el pie de una figura modifica la interpretación de una tabla) que resultan ser enormemente importantes para la recuperación.

Las cifras de generación son honestas pero difíciles de interpretar de forma aislada. Los autores no analizan qué parte de la brecha de precisión se atribuye a errores de recuperación versus fallos de generación. Dado que el Recall@10 ya es del 85.86% para el inglés, una fracción significativa de los fallos debe ser del lado de la generación más que de la recuperación. Conocer ese desglose aclararía si el cuello de botella es el razonamiento multimodal o algo más fundamental sobre cómo los MLLM manejan el lenguaje financiero.

El conjunto de evaluación de 1,394 pares de preguntas y respuestas es pequeño para el alcance del benchmark. Dividido en siete categorías y dos idiomas, algunos segmentos tienen menos de 200 ejemplos. La significancia estadística de los hallazgos a nivel de categoría queda implícita. Esto no es inusual para un artículo de benchmark, pero significa que sería fácil construir comparaciones sesgadas.

El protocolo de evaluación de citas es una contribución interesante, pero un r de Pearson = 0.68 con las calificaciones humanas no es lo suficientemente fuerte como para tratar la autoevaluación como la verdad absoluta para la fundamentación a nivel de bloque. Los autores lo reconocen; el trabajo futuro sobre mejores métricas de citas se señala explícitamente.

Por qué esto importa para la IA en finanzas​

Beancount opera sobre archivos de libro mayor en texto plano, lo que hace que el RAG de solo texto sea defendible para consultar transacciones pasadas. Pero la tarea contable más amplia involucra documentos que enfáticamente no son de texto plano: PDFs de extractos bancarios, facturas escaneadas, imágenes de recibos, informes anuales con tablas y gráficos incrustados. En el momento en que un agente de Beancount necesita conciliar una entrada del libro mayor con un documento fuente (verificar que un cargo particular coincida con la factura en archivo), está realizando exactamente la tarea que FinRAGBench-V evalúa.

El hallazgo sobre las citas a nivel de bloque es lo que más importa para este caso de uso. Si un agente debe justificar una entrada del libro mayor señalando un elemento de línea específico en un PDF, y el mejor sistema disponible logra solo un 20–61% de recall a nivel de bloque, eso no está listo para una auditoría. Cualquier flujo de trabajo de Beancount que toque documentos fuente escaneados necesita una revisión con intervención humana (human-in-the-loop) hasta que esta cifra mejore sustancialmente.

La brecha en la modalidad de recuperación también aboga fuertemente en contra de los flujos de trabajo de solo texto para la ingesta de documentos. Una imagen de un recibo contiene información de diseño (campos de monto, nombres de proveedores, posiciones de los elementos de línea) que el OCR destruye. Esa información de diseño es precisamente lo que distingue un total de línea de un monto de impuestos, y FinRAGBench-V muestra que los recuperadores multimodales la aprovechan de formas que los recuperadores de texto no pueden.

Qué leer a continuación​

• ColPali: Efficient Document Retrieval with Vision Language Models — el predecesor de ColQwen2 que estableció el enfoque de incrustación visual de páginas en el que se basa el mejor recuperador de FinRAGBench-V [arXiv:2407.01449, ECCV 2024]
• M3DocRAG: Multi-modal Retrieval is What You Need for Multi-page Multi-document Understanding — aborda el QA visual multidocumento con un marco flexible que maneja el razonamiento visual de uno y múltiples saltos a través de las páginas [arXiv:2411.04952]
• Benchmarking Temporal-Aware Multi-Modal RAG in Finance — un benchmark complementario de 2025 que evalúa la sensibilidad temporal en el RAG multimodal financiero, directamente complementario a la categoría de preguntas sensibles al tiempo de FinRAGBench-V [arXiv:2503.05185]

El artículo​

EnterpriseArena es una simulación de 132 meses (11 años) de asignación de recursos a nivel de Director Financiero (CFO). Cada paso de tiempo representa un mes. El agente recibe observaciones parciales de las finanzas de la empresa, documentos comerciales anonimizados y señales macroeconómicas extraídas de datos de FRED, CBOE y S&P Global. Dispone de un presupuesto de 20 llamadas a herramientas por mes repartidas en cuatro operaciones: verificar la posición de caja, revisar registros financieros, analizar las condiciones del mercado y proyectar flujos de caja. Debe elegir una de tres acciones: cerrar los libros (conciliación), solicitar financiación (capital o deuda, con resultados estocásticos) o pasar. La restricción principal es que el saldo de caja de la empresa debe ser no negativo en cada paso de tiempo; la infracción termina el episodio con una puntuación de cero. Sujeto a la supervivencia, el agente maximiza la valoración terminal de la empresa bajo la fórmula de puntuación Rev_T × 5 + Cash_T − 5,000 × N_tools, que penaliza explícitamente el uso excesivo de herramientas.

Se evaluaron once LLMs, incluidos Gemini-3.1-Pro, Claude-Haiku-4.5, GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Qwen3.5-397B y Qwen3.5-9B, junto con una línea base de expertos humanos validada por dos profesionales de las finanzas con 8 y 14 años de experiencia respectivamente.

Ideas clave​

• Las tasas de supervivencia varían drásticamente entre modelos: Qwen3.5-9B sobrevive en el 80% de las ejecuciones, Gemini-3.1-Pro en el 50%, Claude-Haiku-4.5 y GLM-5 en el 20% cada uno, y GPT-5.4, DeepSeek-V3.1, Llama-3.3-70B, Mistral-Small-24B y Mixtral-8x7B en el 0%. El promedio general de los LLM es del 26%.
• Los modelos más grandes no superan de forma fiable a los más pequeños: Qwen3.5-9B (9B parámetros, 80% de supervivencia, $78.8M de valoración terminal) vence decisivamente a Qwen3.5-397B (397B parámetros, 20% de supervivencia) y a GPT-5.4 (0% de supervivencia).
• La brecha respecto a los humanos es grande: la línea base humana logra un 100% de supervivencia y una valoración terminal de $152.2M ± $29.6M; el promedio de los LLM es de $28.2M con un 26% de supervivencia.
• El cierre de libros es el cuello de botella crítico: los expertos humanos cierran los libros (concilian) en el 94.3% de los pasos de tiempo; los LLMs promedian un 19.3%. Esta es la acción que produce estados financieros fidedignos y permite decisiones posteriores racionales.
• La recopilación de información sin acción es letal: Qwen3.5-397B utiliza herramientas de análisis de mercado y previsión a una tasa alta durante toda la simulación, pero casi nunca cierra los libros (tasa de cierre del 0.0%) y casi nunca solicita financiación, muriendo por agotamiento de caja a pesar de "saber" lo que estaba sucediendo.
• La penalización por presupuesto de herramientas importa: la fórmula de puntuación castiga activamente a los agentes que consultan compulsivamente en lugar de actuar, una restricción que refleja el coste de oportunidad real.

Lo que se mantiene y lo que no​

El diseño de doble objetivo —supervivencia como restricción estricta más valoración terminal— es una de las elecciones más sólidas en los benchmarks de agentes recientes. Refleja cómo operan realmente los CFOs: no puedes optimizar el crecimiento si te has quedado sin dinero. La anonimización de las fechas del calendario y de las identidades de las empresas evita que los modelos realicen una correspondencia de patrones basada en resultados históricos memorizados, lo que supone una mejora metodológica genuina respecto a los benchmarks financieros que utilizan tickers y fechas reales.

La taxonomía de modos de fallo que los autores identifican mediante estudios de casos es creíble: GPT-5.4 logra una tasa de éxito del 99.1% (lo que significa que toma acción en casi cada paso de tiempo al no hacer nada), mientras que Qwen3.5-397B confunde el análisis con la acción. Estos son modos de fallo conductualmente distintos con remedios diferentes.

Lo que me convence menos: el entorno macro estocástico utiliza ruido gaussiano para aproximar los shocks del mercado, lo cual los propios autores reconocen que no puede replicar eventos de cisne negro o la irracionalidad humana. El presupuesto de herramientas de 20 llamadas por mes también es algo arbitrario; los CFOs reales no se enfrentan a este tipo de restricción de tasa de consulta en su propia memoria, lo que plantea la duda de si el benchmark mide el juicio financiero a largo plazo o algo más parecido a "RAG bajo presión de recursos". La estructura de agente único es otra limitación explícita que nombran los autores: los CFOs reales operan dentro de jerarquías de controladores, analistas de FP&A y equipos de tesorería, y el artículo no intenta simular esto.

El hallazgo de que el tamaño del modelo no predice la supervivencia es sorprendente y probablemente genuino, pero el mecanismo no está bien explicado. Los autores lo señalan sin desglosar completamente si se trata de un fallo en el seguimiento de instrucciones, en la coherencia de contexto largo o en la calibración del riesgo.

Por qué esto importa para la IA financiera​

La acción de cierre de libros en EnterpriseArena es esencialmente la aseveración balance de Beancount y el paso de conciliación del libro mayor: el momento en el que el agente se compromete con una visión real del estado financiero antes de actuar. El hallazgo de que los LLMs omiten esto el 80% de las veces se traslada directamente al problema de seguridad de escritura: un agente que evita la conciliación antes de actuar es un agente que actúa sobre un estado obsoleto o alucinado. Para la automatización de Beancount, esto sugiere que el paso de conciliación debería ser obligatorio y verificable —no opcional— en cualquier bucle de agente.

El horizonte de 132 meses también es directamente análogo a la gestión de libros mayores plurianuales. El hallazgo de que la conciencia situacional sostenida se degrada con el tiempo es la misma degradación que esperaríamos en un agente de Beancount que gestiona cinco años de historial de transacciones: incluso si el agente tiene todos los datos en contexto, puede que no actúe sobre ellos de forma coherente en el mes 60. Esto sugiere que son necesarios puntos de control de conciliación forzada periódicos —no solo consultas reactivas— en sesiones de agentes de Beancount de larga duración.

La trampa de recopilación de información en la que cae Qwen3.5-397B es una advertencia de diseño útil: los agentes equipados con muchas herramientas de recuperación pueden preferir la recuperación al compromiso, especialmente cuando el coste de una acción incorrecta (corrupción del libro mayor) es alto. Las restricciones de presupuesto de herramientas del tipo que utiliza EnterpriseArena podrían ayudar a imponer disciplina de acción en los agentes de escritura de Beancount.

Qué leer a continuación​

• EcoGym (arXiv:2602.09514): benchmark complementario de economía de largo horizonte en entornos de Ventas, Freelance y Operaciones durante más de 1,000 pasos; ningún modelo domina en los tres, lo que sugiere que los modos de fallo en EnterpriseArena no son idiosincrásicos de un solo diseño de benchmark.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral): reformula el diseño de flujos de trabajo como una búsqueda en el espacio de código con MCTS y retroalimentación de LLM; si EnterpriseArena muestra que los comportamientos de agentes diseñados manualmente fallan, AFlow es el siguiente paso obvio para descubrir mejores arquitecturas automáticamente.
• ToolLLM: Facilitating Large Language Models to Master 16,000+ Real-world APIs (arXiv:2307.16789, ICLR 2024): el marco fundamental de entrenamiento y evaluación del uso de herramientas; comprender cómo se aprende el comportamiento de llamada a herramientas en ToolLLM aclara si el fallo de evitación de acción en EnterpriseArena es un problema de entrenamiento o de prompting.

El artículo​

Peijie Yu, Wei Liu, Yifan Yang y sus colegas de Alibaba presentan WildToolBench (arXiv:2604.06185), una comparativa de 256 escenarios de diálogo de múltiples turnos con 1.024 tareas extraídas de patrones de comportamiento de usuarios auténticos y basadas en unas 1.600 APIs públicas. El argumento central es que los benchmarks existentes se están saturando no porque los modelos sean buenos, sino porque las tareas son artificiales. Los usuarios reales agrupan solicitudes, omiten contexto que compartieron hace dos turnos y alternan entre hacer una pregunta sobre una herramienta, charlar un poco y solicitar una aclaración, a veces dentro de un solo mensaje. WildToolBench operacionaliza estos modos de fallo en tres categorías de desafíos estructurados y mide tanto la precisión a nivel de tarea como la mucho más estricta precisión a nivel de sesión, que requiere tener éxito en las cuatro tareas de un diálogo.

Ideas clave​

• La precisión por sesión se desploma a un solo dígito para la mayoría de los modelos: Gemini-2.0-Flash-Thinking lidera con un 14,45% de precisión por sesión, seguido de Claude-4-Sonnet con un 12,50% y GPT-4o con un 11,72%. Superar todas las tareas en una sesión de cuatro turnos es tan difícil que incluso una precisión de tarea del 60% se traduce en menos del 15% de precisión por sesión: un coste de probabilidad compuesta en cada interacción.
• La orquestación compositiva es el precipicio más pronunciado: Las topologías de herramientas mixtas secuenciales y paralelas limitan a los mejores modelos al 25% de precisión de tarea, frente al 54-62% para cadenas puramente paralelas o secuenciales. Cuando una tarea requiere un despliegue en paralelo seguido de una fusión secuencial, el problema de coordinación excede lo que cualquier modelo actual maneja con fiabilidad.
• La intención oculta es una brecha mayor de lo que nadie había medido antes: WildToolBench garantiza que el 100% de las tareas involucren información implícita o entre turnos; BFCL v3 solo logra un 15,7%. Las tareas con dependencias de largo alcance, donde la información faltante está a más de dos turnos de distancia, son el subtipo más difícil, y ningún modelo supera el 50% incluso a nivel de tarea.
• Las transiciones de instrucciones acumulan errores a un ritmo lineal: Cada cambio de política adicional (tarea de herramienta → chat → aclaración → tarea de herramienta) reduce la precisión en aproximadamente 5-15 puntos porcentuales. Con tres transiciones, los modelos más afectados pierden 30 puntos. Los autores llaman a esto "autocondicionamiento": las respuestas previas sesgan la interpretación del modelo de las instrucciones posteriores de formas que son difíciles de corregir a mitad de la sesión.
• La Tasa de Ruta Óptima se mantiene por debajo del 43%: Incluso cuando los modelos completan las tareas correctamente, consumen llamadas a la API en exceso. Claude-4-Sonnet logra la mejor Tasa de Ruta Óptima con un 42,74%, lo que significa que la mayoría de las finalizaciones correctas requieren más pasos de los necesarios: un coste directo en latencia y tokens para cualquier sistema en producción.
• Los modelos especializados en el uso de herramientas rinden por debajo de los modelos de frontera generales: xLAM-2-70B y ToolACE2-8B presentan tasas de error por nombre de función incorrecto superiores al 30%, peor que GPT-4o o Claude-4-Sonnet. El ajuste fino en corpus estrechos de uso de herramientas parece crear fragilidad en lugar de robustez ante el desplazamiento de la distribución hacia el comportamiento de usuarios reales.

Qué se sostiene y qué no​

El diseño del benchmark es sólido donde más importa. La distinción entre precisión de tarea y precisión de sesión es totalmente acertada: la acumulación de modos de fallo es lo que arruina los despliegues reales, y la mayoría de los trabajos previos informan cifras a nivel de tarea que ocultan esto. La taxonomía de tres desafíos (orquestación compositiva, intención oculta, transiciones de instrucciones) está bien motivada y fundamentada empíricamente; las curvas de degradación del rendimiento en los distintos tipos de desafíos son reales y sorprendentes.

El punto débil es la escala. 1.024 tareas de 256 escenarios es un artefacto de investigación creíble, pero escaso para un tablero de clasificación destinado a rastrear 57 modelos a lo largo del tiempo. Los autores lo reconocen directamente y mencionan una canalización de escalado automatizada en trabajos futuros. El otro problema es que "basado en registros de usuarios reales" implica mucho trabajo: las tareas finales son parcialmente sintéticas, construidas por un sistema multiagente a partir de patrones semilla y luego verificadas por anotadores humanos. La afirmación está fundamentada, pero los datos no son literalmente "salvajes", sino "inspirados en lo salvaje". Eso importa para la interpretación literal del techo del 15%; parte de esa brecha podría cerrarse si la canalización de generación introduce una dificultad artificial que los usuarios reales no presentan en la práctica.

También soy escéptico sobre el análisis de la transición de instrucciones como una afirmación arquitectónica. El artículo lo atribuye a una limitación fundamental, pero el desajuste de la distribución de entrenamiento entre los objetivos de ajuste fino de RLHF y las sesiones de usuario multimodales es la explicación más parsimoniosa. Eso es abordable, no estructural.

Por qué esto es importante para la IA en finanzas​

Los tres modos de fallo se corresponden casi a la perfección con la forma en que los usuarios reales interactúan con un agente de escritura para Beancount. Un usuario pregunta "¿cuánto gasté en comestibles el mes pasado y, ya que estás, añade el recibo de Whole Foods de hoy?"; esa es una tarea compositiva agrupada en un solo turno. Luego sigue con "en realidad pon 47,23 $ en lugar de 42, lo he comprobado"; esa es una corrección de parámetros que requiere que el agente rastree el estado de la sesión. Después preguntan "¿es correcta esa categoría?"; esa es una solicitud de aclaración, y el agente debe evitar volver a ejecutar la operación de escritura que acaba de terminar. El límite del 25% en la orquestación mixta secuencial y paralela y la caída de 30 puntos por las transiciones de instrucciones son exactamente los modos de fallo que se manifestarían en un agente de libros contables atendiendo sesiones de usuarios reales.

El hallazgo de que los modelos especializados en el uso de herramientas rinden por debajo de los modelos de frontera generales es particularmente relevante. Si estuviéramos considerando ajustar un modelo abierto más pequeño con ejemplos de llamadas a herramientas específicos de Beancount —la jugada obvia para reducir costes— WildToolBench es una advertencia directa de que la especialización puede sacrificar la robustez ante la distribución del comportamiento real del usuario. El hallazgo de la Tasa de Ruta Óptima también importa: un agente que utiliza el doble de llamadas a la API para completar una tarea no solo es ineficiente; para las operaciones de escritura, las llamadas intermedias redundantes pueden dejar el libro contable en estados intermedios inconsistentes.

Qué leer a continuación​

• ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs (arXiv:2307.16789, ICLR 2024): el marco de entrenamiento fundamental contra el que WildToolBench se posiciona explícitamente; comprender su diseño de evaluación sintética aclara exactamente qué añade la ejecución en vivo.
• τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045): el trabajo previo más cercano sobre el uso realista de herramientas en múltiples turnos; comparar los dominios de comercio minorista y aerolíneas de τ-bench con la cobertura de APIs públicas de WildToolBench muestra cuánto se generaliza el desafío.
• AFlow: Automating Agentic Workflow Generation (arXiv:2410.10762, ICLR 2025 oral): si el problema de la transición de instrucciones es abordable mediante el descubrimiento automático de mejores flujos de trabajo de agentes en lugar de escalar los datos de entrenamiento, AFlow es el mecanismo más creíble para lograrlo.

El artículo​

Geng, Cai, Wang, Koeppl, Nakov y Gurevych analizan la literatura emergente sobre la estimación de confianza y la calibración de LLM en tareas que van desde QA de opción múltiple hasta generación abierta y traducción automática. El problema central: los LLM pueden ser a la vez altamente precisos y completamente poco fiables de formas que son difíciles de distinguir desde el exterior. El estudio organiza el espacio de soluciones en dos ramas principales: métodos de caja blanca que explotan el acceso a los estados internos del modelo, y métodos de caja negra que tratan al modelo como opaco; y dentro de cada una, distingue además entre la estimación de la confianza y su calibración post hoc.

El artículo fue publicado en NAACL 2024 (páginas 6577–6595), revisado en marzo de 2024 a partir de un envío de noviembre de 2023 por un equipo que abarca la TU Darmstadt, MBZUAI y la Universidad de IA Mohamed bin Zayed.

Ideas clave​

• Confianza de caja blanca mediante logits: El enfoque más sencillo utiliza probabilidades a nivel de token o la verosimilitud logarítmica normalizada por longitud como señal de confianza. Estos métodos funcionan pero enfrentan una ambigüedad fundamental: una probabilidad de token baja puede reflejar una baja confianza fáctica o simplemente una redacción inusual; el modelo puede estar inseguro sobre la elección de palabras mientras está seguro sobre el hecho subyacente.

• Confianza de caja negra basada en consistencia (SelfCheckGPT): Manakul et al. (EMNLP 2023) muestrean múltiples completaciones y califican su consistencia mutua utilizando BERTScore, NLI o solapamiento de n-gramas. No se necesita acceso a logits. La idea clave: para hechos que el LLM conoce bien, las muestras repetidas convergen; para hechos alucinados, divergen.

• Entropía semántica: Farquhar et al. (Nature, 2024) agrupan respuestas semánticamente equivalentes antes de calcular la entropía. Un LLM podría redactar "París" y "la capital francesa" de forma diferente; la entropía de tokens pura trata esto como divergente, la entropía semántica no. Este es un paso cualitativo hacia adelante respecto a la consistencia a nivel de token que el estudio contextualiza.

• La confianza verbalizada está rota: Cuando se les pide que emitan un porcentaje de confianza, los modelos colapsan en el exceso de confianza. El trabajo empírico (Groot et al., TrustNLP en ACL 2024) encuentra que GPT-3, GPT-3.5 y Vicuna muestran un Error de Calibración Esperado (ECE) promedio superior a 0,377 para la confianza verbalizada, con predicciones agrupadas en el rango del 90–100% independientemente de la precisión real. Incluso GPT-4 —el modelo mejor calibrado evaluado— logra un AUROC de solo ~62,7% cuando se utiliza la confianza verbalizada para discriminar respuestas correctas de incorrectas, apenas por encima del azar.

• Las técnicas de calibración varían según la tarea: Para la clasificación, la calibración contextual (restando el sesgo de clase previo estimado con un prompt vacío "[N/A]") y la eliminación de sesgo de posición (PriDE) abordan sesgos sistemáticos conocidos. Para la generación, la Calibración de Verosimilitud de Secuencia (SLiC) ajusta los modelos en completaciones clasificadas. El escalado de temperatura (la corrección post-hoc más simple) sigue siendo competitivo en muchos entornos.

• No existe un benchmark unificado: La observación estructural más condenatoria del estudio: no existe un único benchmark que abarque los métodos de estimación de confianza a través de tareas y dominios. Esto hace que sea casi imposible comparar métodos rigurosamente. El campo está comparando peras con manzanas.

Qué se mantiene y qué no​

La taxonomía es sólida. La distinción entre caja blanca y caja negra es genuinamente útil para el diseño de sistemas, y el tratamiento de los métodos basados en logits es honesto sobre sus límites; los autores señalan directamente que la probabilidad de los tokens confunde la confianza fáctica con la incertidumbre léxica. Los profesionales subestiman esta confusión.

Donde el estudio me frustra: es mayoritariamente descriptivo. Casi no hay benchmarks experimentales que comparen métodos frente a frente, y los autores reconocen esto explícitamente como una limitación. Puedo irme con un mapa claro del espacio de diseño pero sin ninguna guía sobre qué método usar para una tarea nueva.

Los resultados de confianza verbalizada —el AUROC de ~62,7% de GPT-4 en su propia confianza declarada— deberían ser conocimiento canónico para cualquiera que despliegue LLM en producción. No lo es. La gente sigue lanzando prompts que preguntan "en una escala del 1 al 10, ¿qué tan seguro estás?" y tratan la respuesta como algo significativo. No lo es.

El estudio también es escaso en la cuestión de la calibración RLHF: ¿el post-entrenamiento con retroalimentación humana hace que los modelos estén mejor o peor calibrados? Hay evidencia en ambos sentidos, y el estudio en gran medida la esquiva.

Por qué esto es importante para la IA financiera​

ReDAct basa su argumento de seguridad en tener una señal de incertidumbre calibrada del modelo económico. El estudio deja claro lo difícil que es eso en realidad. Las señales basadas en logits están disponibles en entornos de caja blanca pero confunden la incertidumbre léxica y fáctica. Los métodos basados en consistencia funcionan en entornos de caja negra pero requieren múltiples muestras por decisión, algo costoso para un agente de escritura de Beancount de alto rendimiento que procesa un lote de asientos de transacciones.

El hallazgo más accionable para Bean Labs: la entropía semántica agrupa respuestas semánticamente equivalentes antes de calificar la consistencia, que es precisamente lo que importa para los asientos del libro mayor donde un modelo podría expresar la misma relación de débito/crédito en múltiples formas sintácticamente distintas. Un agente de Beancount debería usar la agrupación semántica sobre completaciones de asientos del libro mayor muestreadas —no la varianza bruta a nivel de token— para detectar cuándo está alucinando un nombre de cuenta o un importe.

El fallo de calibración de la confianza verbalizada es una advertencia directa para cualquier interfaz de usuario que presente al usuario un "¿qué tan confiado está la IA?": no confíe en el número que produce el modelo. Utilice un calibrador externo o un método basado en consistencia en su lugar, o no lo muestre en absoluto.

Qué leer a continuación​

• Farquhar et al., "Detecting hallucinations in large language models using semantic entropy," Nature, 2024: el método más riguroso que surge de este marco de estudio; vale la pena leerlo completo en lugar de a través del resumen del estudio.
• Manakul et al., "SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection for Generative Large Language Models," EMNLP 2023 (arXiv:2303.08896): el método canónico basado en consistencia; esencial de entender antes de desplegar cualquier señal de confianza de caja negra.
• Groot et al., "Overconfidence is Key: Verbalized Uncertainty Evaluation in Large Language and Vision-Language Models," TrustNLP en ACL 2024 (arXiv:2405.02917): la auditoría empírica más exhaustiva de cómo se desglosa la confianza verbalizada a través de modelos y tareas.

El artículo​

Saibo Geng, Hudson Cooper, Michał Moskal y sus colegas en Microsoft Research presentan JSONSchemaBench, un benchmark de 9.558 esquemas extraídos de fuentes de producción reales: firmas de llamadas a funciones de GlaiveAI, repositorios de GitHub estratificados por complejidad desde trivial hasta ultra, configuraciones de API de Kubernetes, esquemas de análisis de eventos de Snowplow y la colección JSONSchemaStore. Evalúan seis frameworks de decodificación restringida (Guidance, Outlines, Llamacpp, XGrammar, OpenAI Structured Outputs y Gemini) en tres ejes: cobertura (qué fracción de esquemas puede manejar el framework), eficiencia (sobrecarga de tokens por segundo frente a la generación sin restricciones) y calidad (precisión en tareas posteriores). La cuadrícula de evaluación también incluye la suite de pruebas oficial de JSON Schema, que documenta 45 categorías de características que cualquier motor compatible debería soportar.

La afirmación central es que la complejidad del esquema es la variable decisiva que separa a los frameworks capaces de los frágiles, y que ningún framework domina en los tres ejes.

Ideas clave​

• La cobertura colapsa bajo la complejidad de los esquemas. En esquemas simples de GlaiveAI, todos los frameworks obtienen puntuaciones superiores al 86%. Pero en los esquemas "GitHub-Hard" (anidamiento de múltiples niveles, definiciones recursivas, restricciones de patrones complejas), Guidance cae al 41%, Llamacpp al 39%, XGrammar al 28% y Outlines a un catastrófico 3%. OpenAI alcanza solo el 9% en GitHub-Hard, y Gemini no produce ninguna salida válida en esquemas de complejidad media o superior.
• Kubernetes expone una debilidad específica en XGrammar. A pesar de las promesas de velocidad de XGrammar, solo logra un 7% de cobertura en esquemas de Kubernetes, probablemente porque esos esquemas dependen de patrones dependientes del contexto que el pre-cómputo independiente del contexto de XGrammar no puede manejar. La cobertura frente a un benchmark que incluya configuraciones de Kubernetes no es opcional para los agentes en producción.
• La restricción insuficiente es más peligrosa que el fallo de compilación. XGrammar presenta 38 fallos de restricción insuficiente frente a la suite de pruebas de JSON Schema, lo que significa que emite un JSON que viola el esquema declarado mientras informa silenciosamente de un éxito. Guidance tiene solo 1 fallo de este tipo. Para un agente de escritura, un error de compilación se detecta en tiempo de diseño; un fallo de restricción insuficiente corrompe los datos en tiempo de ejecución sin ninguna señal.
• El avance rápido de Guidance ofrece una mejora real de velocidad del 50%. Cuando hay secuencias deterministas largas presentes (por ejemplo, nombres de campos en una estructura de objeto fija), Guidance puede avanzar múltiples tokens por paso de decodificación. En un Llama-3.1-8B en una A100, Guidance funciona a 6–9 ms por token de salida, mientras que la generación sin restricciones funciona a 15–16 ms. Outlines es más lento que la generación sin restricciones, con 30–46 ms, debido principalmente a que la compilación previa de su autómata tarda entre 3 y 8 segundos por esquema.
• La decodificación restringida mejora modestamente la precisión del razonamiento. En GSM8K (matemáticas), Guidance eleva la precisión del 80,1% (sin restricciones) al 83,8%. En "Last Letter" y "Shuffle Objects", las ganancias están en el rango de 1 a 3 puntos. Esto contradice la preocupación ampliamente citada de que forzar el formato JSON degrada la calidad de la respuesta, aunque el tamaño del efecto es lo suficientemente pequeño como para que la elección del formato no deba determinar la selección del framework.
• Ningún framework cubre las 45 categorías de características de JSON Schema. Guidance cubre 13, Llamacpp y XGrammar cubren 1 cada uno, y Outlines cubre 0. La implicación práctica es que cualquier esquema que utilice if/then/else, unevaluatedProperties o definiciones $ref recursivas se comportará de forma impredecible dependiendo del motor que se utilice.

Lo que se sostiene — y lo que no​

La contribución más fuerte del benchmark es la obtención de esquemas. Las evaluaciones anteriores utilizaban esquemas de juguete o colecciones de una sola fuente. Incluir configuraciones de Kubernetes junto con firmas de llamadas a funciones es el tipo correcto de diversidad adversaria. La estratificación de la complejidad (de trivial a ultra) también ofrece a los profesionales una curva de calibración: si sus esquemas se parecen a las llamadas a funciones de GlaiveAI, tanto XGrammar como Guidance están bien; si se parecen a los manifiestos de Kubernetes, sus opciones se reducen rápidamente.

La principal debilidad es la evaluación codiciosa de una sola muestra. Medir la cobertura con una sola generación por esquema subestima la capacidad real: un framework podría fallar el 20% de las veces pero tener éxito en un reintento. El artículo lo reconoce, pero no informa de los números de pass@k con muestreo por temperatura, lo cual sería importante para sistemas de producción que reintentan tras un fallo.

La comparación también mezcla modelos incomparables. Los frameworks de código abierto (Guidance, Outlines, Llamacpp, XGrammar) se prueban con Llama-3.2-1B, mientras que OpenAI y Gemini ejecutan sus propios modelos no revelados. La cobertura del 9% de OpenAI en GitHub-Hard puede reflejar tanto la capacidad del modelo como la arquitectura de decodificación restringida. Una comparación justa requeriría un acceso controlado al modelo, algo que los autores obviamente no pueden forzar a los proveedores propietarios.

Por qué esto es importante para la IA financiera​

Cada agente de escritura de Beancount genera una salida estructurada. Si el agente emite directivas de Beancount como JSON antes de convertirlas a la sintaxis .beancount, o si llama a herramientas a través de esquemas JSON, la fiabilidad de esa generación de JSON no es un detalle; es todo el juego. El artículo de FinTrace mostró que los modelos de vanguardia fallan al razonar sobre las salidas de las herramientas; JSONSchemaBench revela un problema ortogonal: incluso antes del razonamiento, la capa de formato puede emitir silenciosamente una salida no conforme.

El resultado de Kubernetes es particularmente revelador para Beancount. Los esquemas de libros mayores no son simples bolsas de clave-valor planas. Las jerarquías de cuentas, los metadatos de las transacciones y las estructuras de etiquetas crean patrones recursivos anidados similares a los objetos de la API de Kubernetes. Un framework que obtiene un 7% en Kubernetes no está preparado para esquemas de libros mayores complejos, independientemente de lo rápida que sea su sobrecarga por token.

El modo de fallo por restricción insuficiente es el que me quitaría el sueño. Un agente de Beancount que use XGrammar podría emitir una transacción que pase el control de validación interno del framework pero que viole el esquema real, y el agente no tendría motivos para reintentarlo. La corrupción silenciosa es peor que el fallo visible.

Qué leer a continuación​

• XGrammar (arXiv:2411.15100, Dong et al.): el artículo técnico detrás de uno de los frameworks más rápidos probados, que explica la división de tokens independientes/dependientes del contexto y por qué los esquemas de Kubernetes lo ponen a prueba.
• Grammar-Aligned Decoding / ASAp (NeurIPS 2024): muestra que el enmascaramiento de tokens en la decodificación restringida puede distorsionar la distribución de probabilidad del modelo y propone un algoritmo de muestreo corregido; la base teórica para las preocupaciones de calidad que el benchmark mide solo indirectamente.
• XGrammar-2 (arXiv:2601.04426): una continuación que extiende XGrammar a esquemas dinámicos en entornos agénticos donde el esquema mismo cambia durante una sesión de varios turnos, directamente relevante para los agentes de Beancount que adaptan su formato de salida según los tipos de cuenta activos.

El artículo​

Jie Zhu, Yimin Tian y sus colegas del equipo Qwen DianJin de Alibaba Cloud, YINGMI Wealth Management y la Universidad de Soochow presentan FinMCP-Bench, una suite de evaluación de 613 muestras que cubre 10 categorías de escenarios financieros y 33 subescenarios. Las herramientas no son simuladas — 65 servidores de herramientas financieras reales compatibles con MCP respaldan el benchmark, extraídos de registros de producción reales del asistente financiero Qieman APP. Los autores categorizan las muestras en tres tipos: 145 de herramienta única, 249 multi-herramienta y 219 de múltiples turnos. Prueban seis modelos: la familia Qwen3 en recuentos de parámetros de 4B, 30B y 235B (todos con pensamiento extendido), además de DeepSeek-R1, GPT-OSS-20B y Seed-OSS-36B. Las métricas principales de evaluación son la Precisión de la herramienta, la Sensibilidad (Recall) de la herramienta, el F1 de la herramienta y una Tasa de Coincidencia Exacta (EMR) que requiere que cada llamada a la herramienta en una secuencia sea exactamente correcta.

Ideas clave​

• MCP como sustrato de evaluación: el uso de definiciones reales de servidores MCP en lugar de esquemas de API sintéticos cierra una brecha importante entre la evaluación de benchmarks y lo que los agentes enfrentan realmente en sistemas financieros desplegados.
• División de dificultad en tres vías: las muestras de herramienta única, multi-herramienta y múltiples turnos no son solo diferencias de cantidad; exponen modos de falla cualitativamente diferentes.
• Colapso en múltiples turnos: el mejor modelo (Qwen3-235B) logra un 60% de EMR en herramienta única, un 10,62% de EMR en multi-herramienta y un 3,08% de EMR en múltiples turnos. La caída de una sola herramienta a múltiples turnos es de 20 veces.
• El F1 de la herramienta es más permisivo: el mismo modelo puntúa 66,85%, 69,42% y 41,56% en TF1 en los tres entornos, lo que demuestra que los modelos a menudo eligen las herramientas adecuadas pero fallan en el orden, la parametrización o el seguimiento de la conversación.
• La sensibilidad supera a la precisión en herramienta única: los modelos tienden a llamar a herramientas en exceso cuando están inseguros en lugar de llamar de menos, lo cual es el modo de falla más seguro para tareas financieras, pero aún significa llamadas a API desperdiciadas y ruido en la traza de razonamiento.
• Escalado de tamaño no monotónico: Qwen3-30B no supera consistentemente a Qwen3-4B en todos los subescenarios, rompiendo la suposición de que lo más grande siempre gana para el uso de herramientas en varios pasos.

Qué se sostiene — y qué no​

El uso de registros de producción reales como fuente para ejemplos de una sola herramienta es la elección metodológica más sólida aquí. Fundamenta el benchmark en el comportamiento real del usuario en lugar de escenarios inventados por investigadores, lo cual es raro en la literatura de IA para finanzas. Las muestras multi-herramienta y de múltiples turnos se extienden sintéticamente utilizando grafos de dependencia y prompts de juego de roles, lo cual es razonable dado el costo de etiquetado, pero introduce un riesgo: el proceso de síntesis tiende a producir consultas más limpias y directas que las que escriben los usuarios reales. El 3,08% de EMR en múltiples turnos es alarmante pero debe interpretarse con cuidado — el EMR requiere que la secuencia completa sea exactamente correcta, por lo que una sola llamada intermedia incorrecta a una herramienta invalida toda la tarea. Ese es un estándar de producción estricto y posiblemente poco realista; las métricas de crédito parcial como el TF1 cuentan una historia más matizada.

Lo que el artículo no aborda: no hay un análisis de si la brecha de rendimiento es principalmente un problema de comprensión de entrada (el modelo malinterpreta lo que el usuario quiere), un problema de formato de salida (intención correcta pero llamada a la herramienta malformada) o un problema de razonamiento (conclusiones intermedias erróneas). Sin esa descomposición, es difícil saber dónde invertir el esfuerzo de ingeniería. El artículo también evalúa los modelos de forma aislada; no hay pruebas de si agregar un paso de verificación o reflexión cambia el panorama de los múltiples turnos.

El benchmark también está profundamente ligado a las 65 herramientas específicas de Qieman, lo que limita la transferencia de resultados a otras plataformas financieras con diferentes inventarios de herramientas.

Por qué esto importa para la IA en finanzas​

FinMCP-Bench es la evaluación publicada más cercana a lo que un agente de escritura de Beancount haría realmente: recibir una solicitud del usuario, identificar qué herramienta (o cadena de herramientas) se aplica, invocarlas en orden y manejar los turnos de seguimiento. El EMR de múltiples turnos del 3,08% es un baño de realidad. Un agente de Beancount que gestiona una corrección del libro mayor en varios pasos — por ejemplo, reclasificar un conjunto de transacciones entre cuentas en un rango de fechas, luego conciliar y finalmente generar un informe — es exactamente el tipo de tarea de múltiples turnos y múltiples herramientas en la que los modelos actuales fallan casi universalmente bajo estándares de coincidencia exacta.

El marco de MCP es directamente relevante: la API de Python de Beancount, la interfaz beanquery y la capa REST de fava podrían envolverse como servidores MCP. FinMCP-Bench nos dice que el protocolo no es el cuello de botella — el razonamiento sobre las secuencias de llamadas a herramientas sí lo es.

El hallazgo de que la sensibilidad (recall) de las herramientas supera a la precisión (los modelos llaman en exceso) también importa para la seguridad de la escritura: un agente que llama a la herramienta de mutación del libro mayor cuando solo se necesitaba una lectura podría corromper el libro mayor de forma silenciosa. Las métricas de evaluación sesgadas hacia la precisión, y no hacia la sensibilidad, deberían ser la señal de seguridad principal para los agentes con capacidad de escritura.

Qué leer a continuación​

• JSONSchemaBench (arXiv:2501.10868): evalúa la confiabilidad de la salida estructurada en 10,000 esquemas JSON; aborda directamente si las fallas de formato en las llamadas a herramientas en FinMCP-Bench son un problema de decodificación restringida.
• ToolLLM (arXiv:2307.16789, ICLR 2024): el marco fundamental de entrenamiento para el uso de herramientas contra el cual se posiciona FinMCP-Bench; comprender su exploración de árboles de búsqueda en profundidad aclara lo que agrega la metodología de registros de producción de FinMCP-Bench.
• WildToolBench (arXiv:2604.06185): evalúa el uso de herramientas en consultas de usuarios reales en la práctica; su hallazgo de que ningún modelo supera el 15% de precisión en el comportamiento de usuarios reales complementa el enfoque de registros de producción de FinMCP-Bench.

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.

El artículo​

Jiaxuan Lu y sus colegas presentan FinToolBench (arXiv:2603.08262, marzo de 2026) como lo que afirman es la primera evaluación comparativa ejecutable del mundo real para evaluar agentes de aprendizaje de herramientas financieras. El planteamiento es directo: las evaluaciones de IA financiera existentes se centran en el control de calidad estático sobre documentos, mientras que las evaluaciones comparativas de uso de herramientas generales como ToolLLM tratan las finanzas como una categoría de API más sin restricciones de cumplimiento específicas del dominio. FinToolBench intenta llenar el espacio entre esos dos modos de falla.

La evaluación comparativa combina 760 herramientas financieras ejecutables (261 endpoints en vivo de RapidAPI y 499 interfaces de AkShare) con 295 consultas de evaluación rigurosamente seleccionadas, divididas en 166 casos de una sola herramienta y 129 de múltiples herramientas. Las herramientas abarcan los dominios de acciones, bonos, fondos, divisas (forex), derivados, macroeconomía y criptomonedas. Crucialmente, se trata de API reales y llamables, no de simulacros (stubs). Los autores también introducen FATR (Finance-Aware Tool Routing), un agente de referencia que utiliza la recuperación BGE-M3 (los 20 mejores candidatos), tarjetas de herramientas anotadas con atributos financieros y un planificador ReAct consciente de las restricciones limitado a cinco pasos.

Ideas clave​

• La ejecución no es el cuello de botella; el razonamiento sobre los resultados lo es. GPT-4o tiene la puntuación suave condicional (CSS = 0,670) más alta, lo que significa que da respuestas correctas cuando llama con éxito a una herramienta, pero solo invoca herramientas el 22,7% de las veces (TIR = 0,227). Qwen3-8B llama a las herramientas el 87,1% de las veces, pero obtiene la respuesta correcta solo el 40,4% de las veces cuando tiene éxito.
• El desajuste de intención es el fallo de cumplimiento dominante. La IMR (Tasa de Desajuste de Intención) supera el 50% en la mayoría de los modelos, lo que significa que los agentes realizan llamadas con intención transaccional de forma rutinaria cuando la consulta solo requiere una búsqueda informativa. Ese es un problema grave en contextos financieros regulados.
• La inyección de atributos financieros ayuda al cumplimiento sin perjudicar la capacidad. Las tarjetas de herramientas de la línea de base FATR —que anotan cada herramienta con su actualidad, tipo de intención y dominio regulatorio— reducen las llamadas de datos obsoletos (TMR) y las violaciones de dominio (DMR) sin perjudicar significativamente la tasa de invocación.
• Las consultas de múltiples herramientas exponen la brecha de fiabilidad. Las 129 consultas de múltiples herramientas requieren encadenar llamadas y pasar resultados entre pasos; el rendimiento cae sustancialmente en comparación con los casos de una sola herramienta, de acuerdo con los hallazgos de FinTrace y TheAgentCompany.
• Los modelos pequeños pueden superar en invocación pero no en razonamiento a los grandes. La TIR de Qwen3-8B de 0,871 frente a la de 0,227 de GPT-4o muestra que los modelos más pequeños son más "precipitados", pero la CER (Tasa de Ejecución Condicional, es decir, TESR/TIR) de 0,339 para Qwen3-8B frente a 0,618 para GPT-4o revela que GPT-4o es mucho más preciso cuando decide llamar a una herramienta.

Lo que se sostiene y lo que no​

La elección de la evaluación comparativa de utilizar API genuinamente en vivo y ejecutables es su contribución principal, y es real. Las API simuladas han sido el secreto sucio de las evaluaciones de uso de herramientas: las 16.000 API de ToolLLM suenan impresionantes hasta que te das cuenta de que la evaluación utiliza un LLM como juez para determinar si una llamada "habría" funcionado. FinToolBench evita eso.

Las métricas de cumplimiento (TMR, IMR, DMR) son conceptualmente correctas —los agentes financieros necesitan saber la diferencia entre obtener el precio de cierre de ayer e iniciar una operación—, pero la descripción del artículo sobre cómo se aplican estas clasificaciones es escasa. No está claro si las etiquetas de verdad fundamental para el tipo de intención (informativa frente a transaccional) fueron verificadas por expertos legales o de cumplimiento, o simplemente asignadas por los autores del conjunto de datos. Eso importa mucho en la práctica.

El elenco de modelos también es extrañamente reducido: Doubao-Seed-1.6, Qwen3-8B, GLM-4.7-Flash y GPT-4o. No hay Claude Sonnet ni Gemini 2.5, que habrían sido comparaciones naturales. La tabla de resultados muestra que GPT-4o es un valor atípico de precisión pero baja cobertura; me gustaría saber si el comportamiento de uso de herramientas de Claude se acerca más al patrón conservador de GPT-4o o al agresivo de Qwen3-8B.

El conjunto de evaluación de 295 consultas es pequeño para los estándares modernos de evaluaciones comparativas. Con 760 herramientas, una tasa de cobertura de 295 consultas significa que la mayoría de las herramientas nunca se prueban. El artículo no informa estadísticas de cobertura por dominio, lo que significa que las cifras principales podrían estar impulsadas por un subconjunto de dominios con buena cobertura como las acciones y la macroeconomía.

Por qué esto es importante para la IA financiera​

Los agentes de escritura de Beancount —cualquier agente que llame a bean-add, parchee un archivo de libro mayor o consulte beanquery— se enfrentan exactamente a los modos de falla que revela FinToolBench. El problema del desajuste de intención se traduce directamente: un agente de Beancount que emite una llamada de escritura cuando el usuario hizo una pregunta de lectura tiene la misma firma de falla que una violación de IMR. La dimensión de la actualidad se ajusta al problema de llamar a un estado del libro mayor almacenado en caché y obsoleto cuando el usuario espera el saldo actual.

La tensión entre precisión y cobertura (GPT-4o frente a Qwen3-8B) también es directamente relevante. Para la escritura en Beancount, preferiría con mucho el comportamiento de llamada conservador de GPT-4o (baja TIR pero alta CER y CSS) que un modelo de alta invocación que ejecuta frecuentemente la herramienta incorrecta. Las escrituras falsas son mucho más costosas que las operaciones nulas (no-ops).

El enfoque FATR de anotar herramientas con atributos de cumplimiento en lugar de confiar en que el modelo los infiera es un patrón de diseño que vale la pena adoptar. Envolver las herramientas de la CLI de Beancount con metadatos explícitos sobre si una llamada es de solo lectura o de modificación, y si toca el estado del libro mayor actual frente al archivado, es la misma idea aplicada a un ámbito más pequeño.

Qué leer a continuación​

• FinTrace (arXiv:2604.10015) — evaluación a nivel de trayectoria en 34 categorías de tareas financieras con 9 métricas; extiende directamente la evaluación de llamada única de FinToolBench a secuencias de múltiples pasos y ajusta Qwen-3.5-9B con DPO para mejorar el razonamiento intermedio.
• FinMCP-Bench (arXiv:2603.24943) — 613 muestras sobre 65 herramientas financieras basadas en MCP que prueban la invocación de una sola herramienta, de múltiples herramientas y de múltiples turnos; el marco de MCP es directamente relevante para las interfaces de herramientas de Beancount.
• ToolLLM (arXiv:2307.16789, ICLR 2024) — el artículo de ToolBench contra el que FinToolBench se posiciona explícitamente; comprender qué puede y qué no puede medir la línea de base de la API simulada aclara cuánto aporta realmente la ejecutabilidad de FinToolBench.

El artículo​

OmniEval construye una cuadrícula de evaluación bidimensional: cinco clases de tareas (QA extractiva, razonamiento de múltiples saltos, QA de contraste, QA de formato largo y QA conversacional) cruzadas con 16 temas financieros (mercados de valores, banca de inversión, fondos, seguros de propiedad y otros). El resultado es un benchmark estructurado con 11,4k ejemplos de prueba generados automáticamente, 1,7k ejemplos anotados por humanos y un corpus de recuperación de 362k documentos ensamblado a partir de seis fuentes de datos financieros chinos (BSCF-DB con 193k documentos, FinGLM con 55k, BAAI-Fin con 48k, rastreos web oficiales, PDFs y contenido financiero de Wikipedia). El benchmark también incluye un evaluador LLM ajustado —Qwen2.5-7B-Instruct entrenado en 910 instancias etiquetadas por humanos— que califica la calidad de la generación en términos de precisión, alucinación, integridad, utilización y precisión numérica. El artículo fue publicado en EMNLP 2025.

Ideas clave​

• Los casos de prueba autogenerados pasaron una verificación de aceptación humana del 87,47%, lo que significa que aproximadamente 1 de cada 8 instancias generadas fue descartada, una tasa de ruido no despreciable para un benchmark.
• El mejor recuperador (GTE-Qwen2-1.5B) logró un MAP de 0,4370 y un MRR de 0,4491 en el conjunto autogenerado, lo que significa que el pasaje mejor clasificado es correcto menos de la mitad de las veces, incluso con el recuperador más fuerte probado.
• La precisión de generación (ACC) en todas las combinaciones de recuperador-LLM osciló entre 0,3238 y 0,4476; la mejor configuración acierta menos de la mitad de las preguntas.
• La precisión numérica (NAC) es el hallazgo más contundente: de 0,0659 a 0,3595. El mejor sistema acierta los números financieros aproximadamente el 36% de las veces; el peor está cerca de cero.
• El evaluador ajustado alcanzó un 74,4% de acuerdo con la anotación humana (κ = 0,6486), superando sustancialmente a las líneas base de solo prompting (55–71%), pero dejando aún una de cada cuatro evaluaciones desalineada con el juicio humano.
• El razonamiento de múltiples saltos y la QA conversacional fueron consistentemente las clases de tareas más difíciles.

Qué se sostiene y qué no​

El diseño de evaluación matricial es realmente útil. Los benchmarks financieros anteriores (FinanceBench, FinQA, DocFinQA) tratan la evaluación como un eje único —generalmente la precisión de la respuesta— y pierden la variación estructural en cómo falla RAG. Saber que un sistema puntúa bien en QA extractiva pero mal en razonamiento de múltiples saltos es procesable; saber que promedia alguna puntuación general no lo es. La cuadrícula de OmniEval hace visible esa variación, y el hallazgo de que el rendimiento es inconsistente entre temas es exactamente el tipo de resultado que los profesionales necesitan ver antes del despliegue.

Dicho esto, hay límites reales sobre los que quiero ser directo. El corpus es mayoritariamente chino: cinco de las seis fuentes de datos son datos financieros chinos (BSCF, FinGLM, BAAI-Fin), y la sexta es Wikipedia en chino. El artículo no informa resultados desglosados por idioma; solo informa números agregados. Esto hace que cada puntuación en el artículo sea sospechosa como una afirmación sobre RAG financiero en general, en oposición a RAG financiero sobre texto chino con recuperadores y LLMs especializados en chino (GTE-Qwen2-1.5B, Qwen2.5-72B, Yi15-34B). Los usuarios financieros en inglés no pueden usar estos números directamente.

El evaluador LLM está entrenado en 910 instancias etiquetadas. Eso es poco. El acuerdo humano del 74,4% con κ = 0,6486 es defendible como punto de partida, pero significa que el propio marco de evaluación introduce un ruido sustancial. Si el benchmark se utiliza para comparar sistemas que difieren en unos pocos puntos porcentuales, la varianza del evaluador inundará la señal.

El pipeline de generación automática —GPT-4 produce las preguntas de prueba, los humanos filtran con una aceptación del 87,47%— también plantea una cuestión de contaminación que el artículo no aborda: las preguntas generadas por GPT-4 pueden favorecer las fortalezas de los modelos de clase GPT-4 de formas que perjudiquen sistemáticamente a los modelos más antiguos o pequeños.

Por qué esto importa para la IA en finanzas​

Las puntuaciones de precisión numérica son la cifra a la que sigo volviendo: 0,0659–0,3595. Si el mejor sistema RAG probado acierta los números financieros solo el 36% de las veces en una evaluación comparativa, cualquier agente de escritura de Beancount construido sobre un flujo RAG ingenuo va a corromper los datos del libro contable. El formato de Beancount es implacable: un monto, fecha o nombre de cuenta incorrecto produce un error de análisis o un error contable silencioso que puede propagarse a través de los años fiscales. Este benchmark nos da evidencia concreta de que la recuperación RAG y la generación LLM aún no son lo suficientemente confiables para la escritura directa en libros contables sin una capa de validación.

La estructura de clases de tareas también se mapea claramente a los casos de uso de Beancount. La QA extractiva corresponde a consultas simples de saldo. El razonamiento de múltiples saltos corresponde a preguntas como "¿cuál es mi ingreso neto después de impuestos entre el Q1 y el Q3?". La QA conversacional corresponde a un usuario que refina iterativamente una solicitud de conciliación a lo largo de una sesión. El hallazgo de OmniEval de que las tareas de múltiples saltos y conversacionales son las más difíciles es exactamente la mala noticia para el diseño del agente Beancount: los casos fáciles están casi bien; los casos realistas son donde el sistema se desmorona.

Qué leer a continuación​

• ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation (arXiv:2311.09476, NAACL 2025) — el análogo de dominio general más cercano al enfoque de ajuste del evaluador de OmniEval; comparar la metodología de ARES con la de OmniEval aclararía si las opciones de diseño del evaluador LLM son fundamentadas o ad hoc.
• RAGEval: Scenario-Specific RAG Evaluation Dataset Generation Framework (ACL 2025, aclanthology.org/2025.acl-long.418) — generación automatizada de escenarios para la evaluación RAG; extiende la metodología de autogeneración que utiliza OmniEval y puede abordar la preocupación por la contaminación.
• FinRAGBench-V: A Benchmark for Multimodal RAG with Visual Citation in the Financial Domain (arXiv:2505.17471) — extiende la evaluación RAG a documentos financieros multimodales (tablas, gráficos); relevante a medida que los usuarios de Beancount tienen cada vez más imágenes de recibos y estados de cuenta en PDF junto con libros contables de texto plano.

El artículo​

El estudio de Xu y Ding (arXiv:2409.01980) propone organizar la detección de anomalías y de fuera de distribución (OOD) basada en LLM en dos clases de alto nivel: LLMs para Detección, donde el modelo identifica directamente las anomalías, y LLMs para Generación, donde el modelo aumenta los datos de entrenamiento o produce explicaciones en lenguaje natural que alimentan a un detector posterior. Cada clase se subdivide aún más. La detección se divide en métodos basados en prompts (LLMs congelados o ajustados consultados con prompts en lenguaje natural) y métodos basados en contraste (modelos de la familia CLIP que califican la anomalía comparando parches de imagen con descripciones de texto). La generación se divide en métodos centrados en el aumento (generación de etiquetas pseudo-OOD o muestras minoritarias sintéticas) y métodos centrados en la explicación (producción de justificaciones en lenguaje natural para los eventos marcados).

La lista de lectura de GitHub que lo acompaña cubre aproximadamente 39 artículos: 24 sobre detección, 10 sobre aumento y 5 sobre explicación.

Ideas clave​

• Los métodos basados en contraste dominan la detección de anomalías en imágenes. WinCLIP logra un 91.8% y un 85.1% de AUROC en clasificación y segmentación de anomalías zero-shot en MVTec-AD sin ningún ajuste específico para el conjunto de datos, lo cual es competitivo con los métodos supervisados entrenados en ese conjunto.
• Los LLMs congelados se enfrentan a una brecha de modalidad para datos que no son de texto. El estudio señala explícitamente que "el uso directo de prompts en LLMs congelados para resultados de detección de anomalías u OOD a través de varios tipos de datos a menudo produce un rendimiento subóptimo debido a la brecha de modalidad inherente entre el texto y otras modalidades de datos".
• LoRA y el ajuste de adaptadores recuperan gran parte de esa brecha. Métodos como AnomalyGPT y AnomalyCLIP realizan un ajuste fino con técnicas de eficiencia de parámetros y superan sustancialmente a sus contrapartes congeladas.
• La generación como aumento está infrautilizada. Las etiquetas pseudo-OOD a nivel de subtítulo generadas por BLIP-2 superan a las alternativas a nivel de palabra y descripción en la detección de OOD, lo que sugiere que una supervisión de texto más rica es importante incluso para tareas visuales.
• La generación centrada en la explicación es la subcategoría más reciente. Sistemas como Holmes-VAD y VAD-LLaMA van más allá de las marcas binarias para generar justificaciones en lenguaje natural para eventos anómalos, principalmente en videos de vigilancia.
• Los datos tabulares están casi ausentes. El estudio cita un solo método — "Tabular" de Li et al. (2024) — que convierte filas tabulares en prompts de texto y realiza un ajuste fino con LoRA, pero no proporciona cifras comparativas.

Qué se mantiene y qué no​

La taxonomía de dos clases es genuinamente limpia y probablemente la usaré para organizar mi propio pensamiento. La distinción entre detección y generación captura una bifurcación arquitectónica real: o le pides al LLM que clasifique directamente o lo usas para construir una mejor señal de entrenamiento para un detector tradicional.

Lo que no puedo aceptar es el encuadre del artículo como un estudio sobre la detección de anomalías en general. La cobertura está abrumadoramente concentrada en imágenes de defectos industriales (MVTec-AD, VisA) y video de vigilancia (UCF-Crime, XD-Violence). De los aproximadamente 39 artículos catalogados, casi ninguno aborda datos tabulares o financieros. Las series temporales reciben algunas citas. Lo tabular recibe una oración. Este no es un mapa del panorama para Bean Labs; es un mapa para investigadores de visión artificial que quieren usar CLIP para la detección de defectos.

Los autores reconocen que "las limitaciones de espacio impiden resúmenes detallados de métricas", lo cual es una forma cortés de decir que no hay tablas comparativas. Para un artículo de revisión (survey), la ausencia de síntesis cuantitativa es una brecha significativa. Los lectores no pueden usar este artículo para decidir qué paradigma es mejor para su caso de uso sin rastrear individualmente cada artículo citado.

El desafío de las alucinaciones se menciona como un problema abierto, pero el tratamiento es superficial: nombra el riesgo sin analizar qué paradigmas de detección son más o menos susceptibles, o cómo la generación centrada en la explicación podría hacer que las alucinaciones sean más detectables a través de la revisión humana.

Por qué esto es importante para la IA en finanzas​

Dos subcategorías son relevantes a pesar de la cobertura centrada en imágenes. Primero, la subcategoría de generación centrada en la explicación es exactamente lo que los agentes de auditoría de Beancount necesitan: no solo una marca de que un asiento contable es anómalo, sino una oración en lenguaje natural que explique por qué. Los auditores financieros no pueden actuar sobre una salida binaria. Segundo, el silencio casi total del estudio sobre la detección de anomalías tabulares es informativo en sí mismo: confirma que el hilo de AnoLLM, CausalTAD y AD-LLM que he estado siguiendo es un área de vanguardia y no un camino trillado, y que diseñar herramientas de auditoría basadas en LLM para libros mayores de Beancount requiere sintetizar ideas de la detección de anomalías en visión que aún no se han trasladado a entornos tabulares.

El compromiso entre el uso de prompts y el ajuste fino es el hallazgo más aplicable: el prompting zero-shot funciona como una primera aproximación pero sufre por la brecha de modalidad; el ajuste fino basado en LoRA sobre ejemplos etiquetados representativos cierra esa brecha. Para un despliegue de Beancount con ejemplos de anomalías etiquetados de libros mayores históricos, la vía del ajuste fino parece más confiable que el simple uso de prompts.

Qué leer a continuación​

• "Advancing Anomaly Detection: Non-Semantic Financial Data Encoding with LLMs" (arXiv:2406.03614): utiliza incrustaciones (embeddings) de sentence-transformers de LLM en asientos contables reales del libro mayor; un puente directo desde el marco de este estudio al caso de uso tabular de Beancount.
• "Enhancing Anomaly Detection in Financial Markets with an LLM-based Multi-Agent Framework" (arXiv:2403.19735): flujo de trabajo multi-agente para la detección de anomalías en datos de mercado; el patrón de coordinación multi-agente puede trasladarse a la auditoría de libros mayores.
• AnomalyGPT (arXiv:2308.15366): LVLM ajustado para la detección de anomalías industriales con localización a nivel de píxel; leer esto aclara qué significa arquitectónicamente el "ajuste de LLM para detección", algo que el estudio describe pero no explica.

El artículo​

Hsieh et al. parten de una observación diagnóstica: los LLM —incluso aquellos entrenados en contextos largos— exhiben un patrón de atención persistente en forma de U. Los tokens al principio y al final de la entrada reciben una atención desproporcionadamente alta independientemente de si son relevantes, mientras que los tokens en el medio son sistemáticamente infraponderados. Los autores conectan esto empíricamente con la caída de precisión de "perdido en el medio" en lugar de tratarlo como un fenómeno separado.

Su solución es elegante en concepto. Descomponen la atención en dos componentes aditivos: relevancia (lo que queremos) y sesgo posicional (lo que no queremos). Para aislar el término de sesgo, pasan un "documento ficticio" (dummy document) —contenido de relleno poco informativo— a través del mismo contexto en cada posición y registran la distribución de atención resultante. Esa atención del documento ficticio se aproxima a la prioridad posicional pura. Restarla de las puntuaciones de atención reales deja un residual que refleja mejor la verdadera relevancia:

Atención calibrada = Attn(documento, k) − Attn(ficticio, k)

Las puntuaciones reescaladas se utilizan luego para reclasificar o reponderar los documentos recuperados antes del paso final de generación de la respuesta. Fundamentalmente, no se requiere entrenamiento. La calibración se aplica en el momento de la inferencia a las últimas 16 capas del decodificador y a todos los cabezales de atención. El costo es de O(K) pasadas hacia adelante adicionales, donde K es el número de documentos recuperados —algo no trivial pero predecible.

Ideas clave​

• El sesgo de atención en forma de U es intrínseco a la arquitectura del modelo y persiste incluso en modelos entrenados explícitamente con objetivos de contexto largo.
• Pasar un documento ficticio (vacío/ruido) a través del mismo contexto de recuperación aísla la prioridad posicional; restarla elimina el sesgo sin ningún ajuste fino.
• El Recall@3 en NaturalQuestion (K=20, documento de referencia colocado en el medio) salta del 20.52% al 68.32% con la calibración; en K=10, del 36.38% al 74.27%.
• La precisión de QA de extremo a extremo mejora entre 6 y 15 puntos porcentuales cuando el documento de referencia está en el medio del contexto; las mejoras se mantienen en 22 de las 24 configuraciones experimentales.
• El método supera a seis líneas base de comparación: atención vainilla, clasificación por generación de consultas, prompting de generación de relevancia, clasificación por atención (Peysakhovich & Lerer 2023), reordenamiento de prompts y LongLLMLingua-rk.
• El método fue evaluado en NaturalQuestion (2,655 consultas reales sobre Wikipedia) y SynthWiki (990 entradas sintéticas generadas por GPT-4).

Lo que se sostiene — y lo que no​

El resultado principal es sorprendente y lo creo. Una brecha de Recall@3 del 20.52%→68.32% para documentos de referencia en el medio del contexto no es el tipo de número que se evapora bajo escrutinio; está midiendo algo real sobre cómo se distribuye la atención. El diseño sin entrenamiento es una ventaja práctica genuina: puedes implementar esto sobre cualquier flujo de RAG existente sin tocar los pesos del modelo.

Dicho esto, tengo algunas reservas. Primero, el enfoque del "documento ficticio" asume que el sesgo posicional es aproximadamente separable por posición y aditivo —una descomposición lineal que los propios autores señalan como una posible simplificación excesiva. El sesgo de atención real puede interactuar con el contenido de formas no lineales. Segundo, las O(K) pasadas hacia adelante adicionales se valoran como "aceptables" pero nunca se comparan en términos de latencia o costo. En un sistema de producción con K=20 recuperaciones, estás ejecutando 21 pasadas hacia adelante en lugar de 1 por consulta. Para un agente de Beancount que clasifica cientos de transacciones, este multiplicador importa.

Tercero —y esta es la limitación más interesante—, los autores señalan que el sesgo posicional podría ser realmente útil para ciertas tareas. El sesgo de recencia, por ejemplo, podría ser lo que hace que un modelo pondere correctamente los asientos contables recientes sobre los más antiguos. Eliminar el sesgo de forma indiscriminada podría perjudicar tareas donde la posición es una señal válida. Esto se reconoce pero no se estudia.

Finalmente, los experimentos utilizan NaturalQuestion y un conjunto de datos sintético. Los documentos específicos de finanzas —tablas densas, informes de varios años, asientos contables con estructura repetitiva— son muy diferentes de los pasajes de Wikipedia de dominio abierto. La calibración necesitaría ser validada en esas distribuciones antes de afirmar que funcionará para el RAG financiero.

Por qué esto importa para la IA financiera​

La conexión directa es clara: cada registro desde DocFinQA ha estado rondando el mismo problema. Cuando un agente de Beancount recupera 20 asientos contables relevantes para responder a una pregunta como "conciliar marzo con el extracto bancario", las entradas de la mitad de la ventana recuperada serán sistemáticamente desatendidas en relación con las entradas en la parte superior e inferior del contexto. Eso no es un fallo de recuperación, es un fallo en la fase de generación que ninguna mejora en la clasificación de recuperación podrá solucionar.

La calibración de "encontrado en el medio" es una mitigación plausible que no requiere reentrenamiento del modelo subyacente y podría aplicarse directamente dentro del paso de generación de cualquier flujo de QA de libros contables. La preocupación por el costo O(K) es real pero manejable: una ventana de recuperación de 20 documentos con un modelo de tamaño moderado todavía está dentro de los límites prácticos. Lo que querría ver antes de desplegarlo es una validación específica en datos estructurados de Beancount: ¿ayuda la corrección posicional de manera uniforme, o suprime inadvertidamente la señal de recencia que hace que las transacciones recientes sean más confiables que las antiguas?

El principio más amplio —que los mecanismos de atención codifican prioridades posicionales independientemente de la relevancia del contenido, y que esas prioridades pueden calibrarse sin reentrenamiento— es algo que vale la pena mantener. Abre la puerta a calibraciones similares para otros sesgos: sesgo de frecuencia de tokens, normalización de la longitud de entrada, sesgo de verbosidad en la generación.

Qué leer a continuación​

• "Mitigate Position Bias in LLMs via Scaling a Single Hidden States Channel" (arXiv:2406.02536, ACL Findings 2025) — propone escalar una única dimensión de estado oculto en lugar de restar puntuaciones de atención; vale la pena compararlo directamente con el enfoque de "encontrado en el medio".
• "Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey" (arXiv:2409.01980, NAACL 2025) — el siguiente en la lista de lectura; une el hilo de AnoLLM, CausalTAD y AD-LLM en una taxonomía unificada.
• Liu et al., "Lost in the Middle: How Language Models Use Long Contexts" (arXiv:2307.03172, TACL 2023) — el diagnóstico original al que responde "encontrado en el medio"; lectura de fondo esencial.

El artículo​

ReDAct (Reason-Defer-Act) se basa en el paradigma de prompting ReAct e introduce una arquitectura de agentes de dos modelos. Un modelo pequeño y económico — Qwen3-80B, Llama3.3-70B o Llama4-Maverick — maneja cada paso por defecto. En cada paso, genera una traza de razonamiento y luego una acción. El sistema mide la incertidumbre a nivel de token solo sobre el paso de generación de la acción y la compara con un umbral calibrado. Si la incertidumbre supera ese umbral, el paso se vuelve a ejecutar con un modelo grande y costoso (GPT-5.2, Qwen3-235B o Qwen3-480B); de lo contrario, se ejecuta la acción del modelo pequeño.

Las medidas de incertidumbre se basan en la teoría de la información y requieren solo log-probabilidades a nivel de token: Probabilidad de Secuencia (suma de log-prob negativa), Perplejidad (normalizada por longitud) y Entropía Media de Tokens (entropía promedio en las posiciones de los tokens). El umbral se calibra a partir de un conjunto de pruebas de modelos pequeños, eligiendo el valor que produzca un número objetivo K de llamadas al modelo grande por episodio.

Ideas clave​

• Medir la incertidumbre en el paso de acción, no en el de razonamiento. Un experimento auxiliar en 2,411 pasos de ALFWorld encontró que la incertidumbre a nivel de razonamiento tiene un bajo poder discriminatorio entre pasos correctos e incorrectos; la perplejidad a nivel de acción tiene un ROC-AUC y PRR significativamente mayores como predictor de corrección.
• El aplazamiento por PPL con Qwen3-80B + GPT-5.2 alcanza el 80.8% ± 1.1% en ALFWorld, superando a GPT-5.2 por sí solo con 78.3% ± 1.9%, con un costo de $16.25 frente a $45.21 — aproximadamente un 64% más barato.
• ~15% de los pasos se aplazan en la práctica para ajustarse a un objetivo de calibración de aproximadamente el 10%; la brecha surge porque las trayectorias fallidas (más cortas) contribuyen desproporcionadamente al presupuesto de aplazamiento.
• El aplazamiento aleatorio con la misma tasa obtiene un 77.0% — aún mejor que el modelo pequeño solo (68.3%), pero peor que el aplazamiento guiado por cuantificación de incertidumbre (UQ). La señal de incertidumbre realmente importa, no solo el hecho de llamar más al modelo grande.
• MiniGrid muestra menos margen de mejora. Qwen3-80B + GPT-5.2 con aplazamiento por PPL alcanza el 95.0% frente al 99.0% de GPT-5.2 solo. El vocabulario de tareas más pequeño crea un techo más difícil para el enfoque de aplazamiento cuando el modelo pequeño es estructuralmente inadecuado.
• La distribución del aplazamiento depende de la tarea. ALFWorld aplaza más en los pasos finales (historial de prompts más largo), mientras que MiniGrid muestra un patrón bimodal ligado a la posición inicial del agente. Esto significa que la calibración de umbral fijo generaliza mejor dentro de una familia de tareas que entre familias de tareas.

Qué se mantiene y qué no​

El hallazgo empírico central es creíble: la perplejidad sobre la cadena de acción es un sustituto razonable para determinar si un paso determinado está a punto de fallar. La descomposición de razonamiento/acción en ReAct proporciona naturalmente un punto limpio para adjuntar una señal de incertidumbre, y el experimento auxiliar de predicción de corrección ofrece una justificación mecánica genuina para la elección del diseño.

Lo que me convence menos: el resultado de "supera al modelo grande solo" en ALFWorld. 80.8% ± 1.1% frente a 78.3% ± 1.9% se solapan en una desviación estándar. Los autores lo atribuyen a fortalezas complementarias —el modelo pequeño maneja pasos rutinarios sin la toma de riesgos ocasional del modelo grande— pero no hay una ablación por paso para verificar esta narrativa. Podría ser simplemente ruido.

La elección de los benchmarks también es limitante. ALFWorld y MiniGrid son simulaciones domésticas basadas en texto y navegación en mundos de cuadrícula; entornos estrechos que no ejercitan llamadas a herramientas, ejecución de código o recuperación de múltiples documentos. No se ha respondido si el aplazamiento calibrado por incertidumbre se mantiene en esos entornos más ricos (los relevantes para Beancount). Y la elección de GPT-5.2 como modelo grande hace que las cifras de costo sean difíciles de reproducir.

El procedimiento de calibración tiene una circularidad no abordada: el umbral se selecciona sobre la misma distribución en la que se calibró, sin validación externa. Los autores reconocen el cambio de distribución entre la calibración (pruebas del modelo pequeño) y la evaluación (pruebas híbridas), pero dejan la robustez del umbral para trabajos futuros.

Por qué esto es importante para la IA financiera​

Los agentes de escritura de Beancount enfrentan exactamente la misma pregunta de aplazamiento en cada transacción. Una compra rutinaria en el supermercado necesita categorización; un swap de moneda extranjera inusual con múltiples tramos y una nota parcialmente coincidente necesita a un humano. La práctica actual es o la automatización total (arriesgada) o la revisión humana total (costosa). El marco de ReDAct sugiere un terreno intermedio viable: ejecutar el modelo barato y escalar cuando la perplejidad sobre la entrada del diario candidata supere un umbral calibrado.

El contexto financiero añade dos consideraciones que el artículo no aborda. Primero, el aplazamiento aquí debería significar a menudo detenerse y preguntar al usuario, no llamar a un LLM más grande; el estándar de corrección del libro mayor es la intención del usuario, no una puntuación de benchmark. Segundo, la irreversibilidad de una entrada de Beancount confirmada es mayor que la de un objeto mal colocado en ALFWorld. El objetivo de calibración K probablemente debería ajustarse de forma conservadora hacia una menor precisión en el modelo pequeño antes de aplazar, y no al revés.

La señal de reducción de costos del 64% merece ser tomada en serio incluso con esas advertencias. Si un agente de Beancount procesa un mes de transacciones y solo el 15% de las decisiones de categorización necesitan el modelo costoso, la economía de ejecutar un agente de escritura capaz parece mucho mejor.

Qué leer a continuación​

• KnowNo (Ren et al., 2023, CoRL): "Robots that ask for help: uncertainty alignment for large language model planners" — utiliza predicción conforme para calibrar una garantía de cobertura sobre cuándo pedir ayuda. ReDAct no se compara con él; entender el equilibrio entre garantías conformes y calibración de umbrales es importante antes de elegir un enfoque de producción. [arXiv:2307.01928]
• A Survey of Confidence Estimation and Calibration in Large Language Models (Guo et al. actualizado, NAACL 2024) — taxonomía sistemática de confianza verbalizada, métodos basados en muestreo y calibración post-hoc; la base teórica para decidir si la perplejidad es el sustituto de incertidumbre adecuado o si el escalado de logits calibrado funcionaría mejor. [arXiv:2311.08298]
• UALA: Uncertainty-Aware Language Agent (Han, Buntine, Shareghi) — aplica un umbral de incertidumbre estructuralmente similar a la decisión de invocación de herramientas (llamar a una herramienta frente a confiar en el conocimiento del modelo), reduciendo las llamadas a herramientas en más del 50%; el complemento directo de ReDAct para el eje de uso de herramientas de la incertidumbre del agente. [https://uala-agent.github.io/]

El artículo​

OpenHands (Wang et al., 2024; ICLR 2025) es una plataforma de código abierto para construir y evaluar agentes LLM que actúan como desarrolladores de software generalistas. Dirigido por Xingyao Wang y Graham Neubig con un equipo de 24 autores, la afirmación central del artículo es que la mayoría de los marcos de agentes existentes son o demasiado estrechos para la investigación (bucles de tareas codificados rígidamente) o demasiado estrechos para la producción (de código cerrado o de propósito único) para servir como una base compartida para la comunidad de investigación. OpenHands intenta solucionar esto proporcionando un entorno de ejecución estandarizado, una abstracción de agente limpia y 15 benchmarks de evaluación integrados bajo un único repositorio con licencia MIT.

El entorno de ejecución (runtime) es un entorno aislado en Docker que contiene un shell bash, un servidor Jupyter IPython y un navegador Chromium controlado por Playwright. Los agentes interactúan a través de tres tipos de acciones principales: IPythonRunCellAction para Python, CmdRunAction para comandos de shell y BrowserInteractiveAction para la navegación web. Una primitiva de coordinación multi-agente, AgentDelegateAction, permite que un agente principal genere sub-agentes especializados. La base por defecto es CodeAct —publicada originalmente como un artículo independiente que argumenta que el código es el espacio de acción unificado ideal para los agentes LLM— y la plataforma incluye varias implementaciones de agentes, incluyendo un CodeActAgent general y un BrowsingAgent especializado.

Ideas clave​

• El código como espacio de acción universal: CodeAct consolida todas las acciones del agente (ediciones de archivos, llamadas a API, transformaciones de datos) en Python o bash, permitiendo que el LLM razone en el mismo medio en el que fue entrenado más intensamente. Esto evita la fragilidad de los esquemas JSON que plaga a los agentes basados en llamadas a funciones.
• Entorno de ejecución Docker en sandbox: cada agente se ejecuta en un contenedor aislado, por lo que los agentes pueden ejecutar libremente código arbitrario sin comprometer la máquina anfitriona; un requisito previo para cualquier agente financiero de producción al que se le puedan entregar credenciales reales.
• 15 benchmarks en un solo arnés: SWE-Bench Lite (reparación de código), HumanEvalFix (corrección de errores), WebArena (navegación web), GPQA (razonamiento de nivel de posgrado), GAIA (resolución de tareas generales) y diez más. Tener estos ubicados en el mismo lugar evita evaluaciones sesgadas por selección manual.
• CodeActAgent + claude-3.5-sonnet logra un 26% en SWE-Bench Lite y un 79.3% en HumanEvalFix; BrowsingAgent alcanza un 15.5% en WebArena — un rendimiento zero-shot competitivo sin ningún entrenamiento específico para la tarea.
• Rendimiento en GAIA: 32.1% con GPTSwarm, muy por debajo de la referencia humana del 92%, lo cual es consistente con cualquier otro benchmark de agentes generales que muestra una brecha de 60-70 puntos entre humanos y agentes.
• Escala comunitaria: 71.4K estrellas en GitHub y más de 188 colaboradores en el momento de la presentación en ICLR; TheAgentCompany adoptó OpenHands como su arnés de evaluación, otorgándole un estatus de infraestructura de benchmark de facto.

Qué se mantiene y qué no​

El diseño del entorno de ejecución aislado es una ingeniería sólida. Aislar la ejecución del agente en Docker es el estándar correcto para cualquier sistema al que más tarde se le pueda dar acceso de escritura a libros mayores financieros reales, y es genuinamente útil que los benchmarks estén ubicados en el mismo lugar en lugar de estar dispersos en repositorios incompatibles.

La cobertura de los benchmarks, sin embargo, es más aspiracional que sistemática. Los 15 benchmarks abarcan tipos de tareas y niveles de dificultad sumamente diferentes sin un marco claro sobre cómo se deben agregar o comparar los resultados. Informar un 26% en SWE-Bench Lite junto con un 79.3% en HumanEvalFix en el mismo artículo corre el riesgo de crear la impresión de que el mismo agente es simultáneamente mediocre y excelente; las tareas simplemente no son comparables. Los autores no proporcionan una metodología de agregación multi-benchmark fundamentada.

La suposición de CodeAct —que el código es el formato de acción universal correcto— es cuestionada. Funciona bien para tareas de desarrollo, pero impone una capa de mediación de Python/bash en cada acción, lo que añade latencia y falla cuando la semántica de la acción no se mapea limpiamente al código (instrucciones de usuario ambiguas, APIs solo de lenguaje natural). El artículo no realiza benchmarks contra espacios de acción que no sean de código para demostrar que la ventaja es real y no una confusión causada por la base del LLM.

Quizás la brecha más importante es la división entre evaluación y despliegue. La cifra del 26% en SWE-Bench proviene de un benchmark relativamente limpio y bien especificado. Los informes de la comunidad y los hilos de problemas en GitHub describen consistentemente una confiabilidad mucho menor en tareas del mundo real ambiguas o de largo horizonte, el mismo modo de fallo que documentó TheAgentCompany. El artículo no aborda cómo medir o mejorar la robustez bajo el ruido de una especificación de tarea realista.

Por qué esto importa para la IA en finanzas​

OpenHands es lo más parecido que tiene la comunidad a un sustrato de agentes compartido. Si Bean Labs construye una infraestructura de evaluación para agentes de Beancount, vale la pena adoptar la arquitectura de ejecución aquí —sandbox de Docker, acciones en Python/bash, backends de LLM intercambiables— en lugar de reconstruirla. La primitiva AgentDelegateAction se mapea naturalmente a una tubería de agentes financieros donde un orquestador de nivel superior delega en sub-agentes especializados: uno para lecturas del libro mayor, uno para el señalamiento de anomalías y uno para propuestas de actualización de registros que un humano revisa.

Las cifras de SWE-Bench y TheAgentCompany, leídas en conjunto, establecen una base reveladora: incluso los mejores agentes disponibles completan aproximadamente entre el 26% y el 30% de las tareas de software realistas y sin ambigüedades. La automatización de libros contables financieros es más difícil: las transacciones suelen ser ambiguas, el radio de impacto de los errores es real y la intención del usuario frecuentemente está subespecificada. La inferencia correcta no es que los agentes no estén listos, sino que los primeros despliegues productivos serán flujos de trabajo de "escribir una vez" con un alcance muy limitado (sugerencias de categorización, señalamiento de conciliaciones) en lugar de ediciones autónomas de múltiples pasos en el libro mayor.

Qué leer a continuación​

• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — empareja un modelo barato con uno costoso y delega al modelo costoso solo cuando la incertidumbre es alta; aborda directamente cómo un agente al estilo OpenHands debería decidir cuándo escalar una actualización de Beancount a una revisión humana.
• FinTrace: Holistic Trajectory-Level Evaluation of LLM Tool Calling for Long-Horizon Financial Tasks (arXiv:2604.10015) — 800 secuencias de tareas anotadas por expertos a través de 34 escenarios financieros; la metodología de evaluación de la que carece OpenHands para el uso de herramientas de largo horizonte específicas de finanzas.
• FinMCP-Bench: Benchmarking LLM Agents for Real-World Financial Tool Use under the Model Context Protocol (arXiv:2603.24943) — 613 muestras a través de 65 herramientas financieras reales de MCP, directamente relevante para cómo se evaluaría un agente de Beancount construido sobre el entorno de ejecución de OpenHands en un despliegue real de MCP.

El artículo​

Fin-RATE, publicado en febrero de 2026 por Yidong Jiang, Junrong Chen y sus colegas de Yale e instituciones colaboradoras, presenta un benchmark construido a partir de 2,472 presentaciones ante la SEC de 43 empresas y 36 industrias que abarcan el periodo 2020–2025. El benchmark organiza 7,500 pares de preguntas y respuestas seleccionados por expertos en tres tipos de tareas que reflejan los flujos de trabajo de los analistas profesionales: DR-QA (detalle y razonamiento dentro de una sola presentación), EC-QA (comparación entre entidades de dos empresas bajo un tema compartido) y LT-QA (seguimiento longitudinal de la misma firma a lo largo de los periodos de reporte). Cada tipo de tarea contiene 2,500 preguntas. La evaluación abarca 17 LLM: modelos de código cerrado, incluidos GPT-4.1 y GPT-5, modelos generales de código abierto como DeepSeek-V3 y Llama-3.3-70B, y modelos especializados en finanzas como Fin-R1, Fino1-14B, FinanceConnect-13B y TouchstoneGPT-7B. La puntuación utiliza un marco unificado de LLM-as-Judge con tres jueces independientes (GPT-5, DeepSeek-V3.2, Qwen3-235B) que califican cada respuesta según su exactitud y cinco dimensiones analíticas.

Ideas clave​

• El rendimiento se desploma a medida que aumenta la complejidad de la tarea: la precisión cae un 18.60% desde el DR-QA de un solo documento hasta el LT-QA longitudinal, y un 14.35% desde el DR-QA hasta el EC-QA entre entidades, en promedio entre los 17 modelos.
• GPT-5 con búsqueda web es el modelo con mejor rendimiento, aunque su precisión máxima se sitúa en solo el 43–44% en los tres tipos de tareas, una cifra desalentadora para un benchmark destinado a reflejar los flujos de trabajo reales de los analistas.
• Fin-R1, el modelo de razonamiento especializado en finanzas, alcanza el 57.48% en DR-QA pero colapsa al 3.32% en EC-QA: una caída de 54 puntos que supera con creces cualquier degradación de los modelos generales.
• Bajo configuraciones RAG, el rendimiento de todos los modelos cae muy por debajo del 27%, en comparación con el rendimiento con contexto ideal (gold-context) de hasta el 57.48%; el sistema de recuperación, y no el LLM, es el cuello de botella limitante.
• El artículo introduce una taxonomía de errores de 13 tipos en cuatro categorías: alucinaciones y contradicciones, errores semánticos y numéricos específicos de las finanzas, errores de comprensión de la consulta/contexto y fallos a nivel de recuperación. La falta de evidencia representa el 75.44% de los errores en la tarea EC-QA bajo RAG.
• Los modelos especializados en finanzas muestran tasas de alucinación sistemáticamente más altas que los modelos generales en tareas complejas, a pesar de poseer una mejor terminología financiera.

Qué se sostiene — y qué no​

La estructura de tres vías está genuinamente bien diseñada. La mayoría de los benchmarks financieros (FinQA, TAT-QA, FinanceBench) tratan las preguntas y respuestas como una tarea de un solo documento. Fin-RATE es uno de los primeros en modelar explícitamente la comparación entre entidades y el seguimiento longitudinal como tareas de primer orden, y los resultados exponen una brecha fundamental: los LLM actuales manejan aceptablemente las preguntas sobre divulgaciones aisladas, pero se desmoronan en el momento en que necesitan sintetizar información a través de documentos, entidades o periodos de tiempo.

El colapso de Fin-R1 es el hallazgo más sorprendente del artículo y creo que no se valora lo suficiente. Un modelo ajustado para finanzas que destaca en la extracción de un solo documento aparentemente se entrenó a sí mismo en un callejón sin salida: aprendió plantillas para responder dentro de un documento, no estrategias de razonamiento para relacionar entidades y periodos de tiempo. Esta es una advertencia concreta contra el ajuste fino en dominios estrechos sin una supervisión explícita del razonamiento multidocumento. Es probable que el modelo se sobreajuste al patrón superficial de "encontrar el número en la presentación" y no tenga una vía de generalización para "comparar este número con el número equivalente en otra presentación de otra empresa".

Dicho esto, existen preocupaciones metodológicas que vale la pena señalar. GPT-5 es simultáneamente uno de los modelos evaluados y uno de los tres jueces que califican las respuestas. Los autores utilizan tres jueces para reducir el sesgo individual, lo cual ayuda, pero el solapamiento entre juez y modelo con el modelo evaluado más fuerte resulta incómodo. El artículo informa de un alto acuerdo entre jueces, pero no cuantifica por separado qué fracción de las respuestas de GPT-5 fueron calificadas por el propio GPT-5, ni si las puntuaciones autoevaluadas de GPT-5 difieren sistemáticamente de las de los otros dos jueces. Cualquier sesgo de autoevaluación inflaría el resultado final del modelo con mejor desempeño en el estudio.

La muestra de 43 empresas también es escasa. La cobertura de los tipos de presentaciones es encomiablemente amplia (10-K, 10-Q, 8-K, 6-K, DEF 14A y varias series S y SC), pero las mismas 43 empresas aparecen en todas las tareas. Los modelos que han visto las divulgaciones de estas empresas durante el pre-entrenamiento tienen una ventaja no cuantificada, y el artículo no incluye ningún análisis de contaminación.

El hallazgo sobre la recuperación es importante pero incompleto. El documento identifica que el rendimiento de RAG colapsa aproximadamente 30 puntos frente al contexto ideal porque la recuperación falla. Pero solo evalúa una única configuración de recuperación: trata el fallo de recuperación como un diagnóstico en lugar de algo que se deba variar sistemáticamente. Un artículo de seguimiento que analice exhaustivamente las arquitecturas de recuperación en Fin-RATE sería mucho más útil.

Por qué esto importa para la IA en finanzas​

La auditoría de libros contables de Beancount necesita exactamente las dos capacidades que Fin-RATE revela que están defectuosas: el seguimiento longitudinal (¿cómo evolucionó esta cuenta a lo largo de los años fiscales?) y la comparación entre entidades (¿se concilia el balance general de esta subsidiaria con el estado consolidado?). La caída del 18.60% en la precisión bajo el seguimiento temporal es una cifra concreta que debería calibrar las expectativas para cualquier agente de Beancount que razone a través de múltiples periodos de reporte. Si los modelos de vanguardia fallan al 43% bajo preguntas y respuestas longitudinales de la SEC con contexto ideal, un agente de Beancount que navegue por historiales de libros contables de varios años debería diseñarse con una recuperación explícita, fundamentación temporal y escalada humana, no con una inferencia de LLM de extremo a extremo.

El hallazgo sobre la importancia de la recuperación es fundamental para la prioridad del diseño del sistema. Si el rendimiento con contexto ideal es casi el doble del rendimiento con RAG, la inversión adecuada está en un mejor fraccionamiento (chunking), selección de pasajes y recuperación, no en un LLM base más capaz. Esto refleja lo que DocFinQA encontró para presentaciones de la SEC de contexto largo: el sistema alrededor del modelo es el cuello de botella.

La advertencia sobre Fin-R1 también se aplica directamente al caso de uso de Beancount. El ajuste fino en la sintaxis DSL de Beancount y los patrones de transacciones puede producir un modelo que maneje bien la generación de entradas simples, pero que falle bajo la conciliación multicuenta y multiperiodo que hace que la auditoría sea útil. La especialización sin entrenamiento en razonamiento multidocumento es frágil exactamente de la manera en que Fin-RATE mide.

Qué leer a continuación​

• Fin-R1 (arXiv:2503.16252): para entender qué configuración de entrenamiento produjo un rendimiento multidocumento tan frágil, y si el razonamiento multidocumento estuvo alguna vez dentro del alcance.
• FinTrace (arXiv:2604.10015): evaluación a nivel de trayectoria de las llamadas a herramientas de LLM en 34 categorías de tareas financieras; complementa la visión estática de preguntas y respuestas de Fin-RATE con un diagnóstico a nivel de proceso de dónde los modelos invocan las herramientas adecuadas pero fallan al razonar sobre los resultados.
• OpenHands (arXiv:2407.16741): la plataforma de agentes abierta que sustenta las evaluaciones de TheAgentCompany; comprender su arquitectura aclara qué capacidades básicas de los agentes estaban disponibles y qué brechas son atribuibles a la dificultad de la tarea más que a las limitaciones de la plataforma.

El artículo​

Chanyeol Choi, Jihoon Kwon y sus colegas en una firma de IA financiera presentan un conjunto de datos de 5,703 tripletes de consulta–evidencia–respuesta anotados por expertos, obtenidos de un servicio real de preguntas y respuestas para analistas de fondos de cobertura. Los documentos son presentaciones del Formulario 10-K de 490 empresas del S&P 500, recopilados de SEC EDGAR. Lo que distingue a FinDER de los benchmarks anteriores es el lado de la consulta: el 89.86% de las consultas contienen tres o más abreviaturas o acrónimos específicos del dominio. En lugar de "¿Cuál es el ingreso total de la Compañía X para el año fiscal 2023?", un analista real podría escribir "GOOGL 10-K FY23 revs breakdown by segment". El conjunto de datos se publicó en el Taller de Avances en IA Financiera de ICLR 2025 y posteriormente apareció en ICAIF 2025.

Ideas clave​

• La recuperación (recall) es sorprendentemente baja en todos los ámbitos: E5-Mistral (el mejor recuperador denso) logra solo un 25.95% de recuperación de contexto en general; BM25 alcanza el 11.68%. La categoría "Financials" —la más directamente relevante para la contabilidad— es la más difícil: 15.84% y 6.42% respectivamente.
• La ambigüedad de la consulta por sí sola cuesta 8.2 puntos de precisión: Al probar E5-Mistral en 500 consultas, los autores comparan paráfrasis bien formadas (33.9 de precisión) frente a las consultas abreviadas reales (25.7 de precisión). La brecha es totalmente atribuible al manejo de abreviaturas/acrónimos, no a la complejidad del documento.
• La calidad de la recuperación es el principal cuello de botella para la generación: Los LLM sin contexto obtienen una puntuación cercana a cero (9–10% de aciertos); con los 10 mejores pasajes recuperados alcanzan el 29–34%; con un contexto de oráculo perfecto saltan al 60–68%. Esa brecha de 35 puntos entre las condiciones realistas y las de oráculo es mayor que la brecha entre los modelos de código abierto y los de frontera.
• La aritmética composicional falla incluso con una buena recuperación: Las tareas de cálculo de varios pasos (consultas composicionales) alcanzan solo un ~20% de corrección en los cuatro modelos —Claude-3.7-Sonnet, GPT-o1, DeepSeek-R1-Distill y Qwen-QWQ— incluso con los 10 mejores pasajes recuperados. GPT-o1 lidera las tareas de multiplicación con un 42.90%, pero cae al 27.78% en la división.
• El re-ranking por LLM añade una mejora modesta pero consistente: Al permitir que los modelos reclasifiquen los 10 mejores aciertos de E5-Mistral antes de responder, Claude-3.7-Sonnet logra un F1 de 63.05 y GPT-o1 alcanza 62.90. Deepseek-R1-Distill se queda atrás con 60.01, a pesar de su fuerte rendimiento en razonamiento estructurado en otros campos.
• La dificultad de las categorías es desigual: Las consultas sobre riesgos son las más fáciles de recuperar (E5-Mistral: 33.07 de recuperación); las financieras siguen siendo las más difíciles (15.84). Esto se correlaciona con la estructura de la consulta: las divulgaciones de riesgos utilizan prosa en lenguaje natural, las tablas financieras utilizan una notación numérica densa.

Lo que se mantiene y lo que no​

La contribución principal es sólida: esta es una distribución de consultas real de analistas en activo, y el problema de las abreviaturas es genuino. Cualquier benchmark construido a partir de Wikipedia o crowdsourcing al estilo FinQA pasa por alto esto. La estructura de evaluación de tres niveles —sin contexto, recuperación realista, contexto de oráculo— es el diseño correcto; separa limpiamente la calidad de la recuperación de la calidad del razonamiento y muestra la brecha de generación residual (todavía un ~32–34% de fallo incluso con un contexto perfecto en preguntas cualitativas).

Donde el artículo es más débil es en la reproducibilidad. En el momento de la publicación, el conjunto de datos no estaba disponible públicamente; los autores afirman que "planean lanzarlo públicamente en un momento posterior". Este es un problema significativo para un artículo de taller que se presenta como un estándar de evaluación. Los benchmarks que no se publican no son benchmarks; son estudios de caso. Desde entonces ha aparecido en ICAIF 2025, por lo que es posible que se haya producido el lanzamiento, pero la versión de arXiv no lo confirma.

La evaluación de recuperación también utiliza solo cuatro modelos de una sola etapa (BM25, GTE, mE5, E5-Mistral). No hay recuperación híbrida, ni expansión de consultas, ni HyDE, ni un paso de reescritura dirigido específicamente al problema de las abreviaturas. Dado que los autores han caracterizado con precisión la brecha de las abreviaturas, es sorprendente que no prueben la solución obvia: expandir la consulta ("GOOGL" → "Alphabet Inc.") antes de la recuperación. Ese experimento está ausente.

Los resultados de generación merecen una lectura más detallada. El rendimiento de ~9–10% sin contexto no es un límite inferior útil —es esencialmente cero—, pero el techo del oráculo del 60–68% es más informativo de lo que parece. Incluso con el pasaje correcto en la mano, los mejores modelos fallan en aproximadamente un tercio de las preguntas cualitativas y en cuatro quintos de la aritmética composicional. Ese techo importa: significa que la recuperación por sí sola no puede resolver el problema.

Por qué esto es importante para la IA en finanzas​

La distribución de consultas en FinDER se ajusta bien a cómo los usuarios de Beancount interactúan realmente con un agente de libro mayor. Un usuario que ha mantenido sus cuentas durante años escribirá consultas abreviadas y contextuales: "¿reembolso tarjeta AMZN Q3?" en lugar de "¿Cuáles son los reembolsos de la tarjeta de crédito Amazon en el tercer trimestre?". Los modelos de embedding estándar no lograrán recuperar las entradas correctas porque fueron entrenados en texto limpio de lenguaje natural. La caída de 8.2 puntos en la precisión de las consultas limpias a las reales es probablemente conservadora para un dominio de libro mayor personal, donde la taquigrafía idiosincrásica ("comisión gest prop" por "comisión de gestión de propiedad") está aún más lejos de los datos de entrenamiento que las abreviaturas estándar de la SEC.

El techo de recuperación de contexto del 25.95% en E5-Mistral es una función de presión: cualquier pipeline RAG de Beancount debe prever una gran fracción de evidencia omitida. Una implicación es que la recuperación de alta exhaustividad (múltiples pases, formulaciones de consulta diversificadas) importa más que forzar el F1 en un solo pase. Otra es que la normalización de consultas —mapear la taquigrafía del usuario a nombres de cuentas canónicos antes de la recuperación— debería ser un paso de preprocesamiento explícito, no dejado al modelo de embedding.

La precisión del 20% en aritmética composicional incluso con contexto de oráculo es una señal separada: para las tareas de cálculo en Beancount, el cuello de botella de la generación es el razonamiento, no la recuperación. La descarga al estilo PAL (generar aritmética en Python en lugar de cálculos en texto libre) sigue siendo la respuesta correcta para las tareas numéricas, independientemente de lo buena que sea la recuperación.

Qué leer a continuación​

• Fin-RATE (arXiv:2602.07294): el benchmark complementario para el seguimiento de múltiples períodos en las presentaciones de la SEC; la precisión cae un 18.60% en tareas temporales, que es el problema del libro mayor de varios años de Beancount planteado directamente.
• IRCoT (arXiv:2212.10509, ACL 2023): entrelazando la recuperación con el razonamiento de cadena de pensamiento; la estructura de recuperación de múltiples pases aborda directamente la baja recuperación de un solo pase que expone FinDER.
• Expansión de consultas con LLM para recuperación específica de dominio: ningún artículo de benchmark individual cubre esto bien todavía, pero la brecha de abreviaturas de FinDER lo convierte en una prioridad de investigación de primer orden; buscar "HyDE financial domain" y "query expansion SEC filings 2025" es el punto de partida adecuado.

El artículo​

"Lost in the Middle: How Language Models Use Long Contexts" por Nelson F. Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni y Percy Liang realiza dos experimentos dirigidos: respuesta a preguntas sobre múltiples documentos en NaturalQuestions-Open (con 10, 20 y 30 documentos recuperados) y recuperación sintética de clave-valor (con 75, 140 y 300 pares). En cada experimento, varían sistemáticamente dónde se encuentra el documento relevante o el par clave-valor dentro del contexto de entrada —al principio, al medio o al final— mientras mantienen todo lo demás fijo. El hallazgo es claro: el rendimiento traza una curva en forma de U con el punto más bajo en el medio del contexto, y la curva aparece en todos los modelos probados.

Ideas clave​

• La forma de U es real y consistente. En la configuración de QA con 20 documentos, el rendimiento en la primera posición fue de aproximadamente el 75% y se degradó hasta alrededor del 55% en la posición 10 antes de recuperarse hasta cerca del 72% en la posición 20; una brecha de ~20 puntos entre los bordes y el centro.
• Todos los modelos siguen el mismo patrón. Los modelos probados abarcan cerrados y abiertos, pequeños y grandes: GPT-3.5-Turbo (4K y 16K), GPT-4, Claude-1.3 (8K y 100K), MPT-30B-Instruct y LongChat-13B. La curva en U apareció en cada uno de ellos, incluidos los modelos comercializados explícitamente por sus ventanas de contexto extendidas.
• Ni siquiera Claude-1.3-100K es inmune. La variante de contexto de 100K se comportó como las demás. Una ventana de contexto larga no significa que el modelo realmente preste atención de manera uniforme a lo largo de ella.
• La línea base de "libro cerrado" establece un suelo aleccionador. GPT-3.5-Turbo sin ningún documento respondió correctamente al 56.1% de NaturalQuestions; con acceso de oráculo a solo el documento relevante, alcanzó el 88.3%. Pero en las peores posiciones intermedias en la configuración de 20 documentos, el rendimiento cayó por debajo de la línea base de libro cerrado, lo que significa que añadir más contexto fue activamente perjudicial.
• Los modelos encoder-decoder (Flan-T5-XXL, Flan-UL2) son más robustos dentro de su longitud de entrenamiento pero revierten cuando los contextos la superan. La diferencia arquitectónica importa, pero ambos siguen degradándose a escala.
• La causa raíz es el enmascaramiento de atención causal. Cada token solo puede atender a los tokens precedentes, por lo que las posiciones al principio acumulan más peso de atención total a través del modelo que las posiciones en el medio. Los efectos de recencia también elevan el rendimiento al final del contexto.

Lo que se sostiene — y lo que no​

El diseño experimental aquí es admirablemente limpio: la posición es la única variable que se manipula, las tareas son benchmarks estándar y el hallazgo se replica en una amplia gama de familias de modelos. No tengo objeciones con el resultado central.

Lo que encuentro menos convincente es el planteamiento de la tarea de recuperación de clave-valor como un proxy significativo para el uso real. Las búsquedas de UUID a UUID prueban si un modelo puede repetir una cadena memorizada, no si puede hacer algo que requiera razonamiento. La curva en U también aparece allí, lo que refuerza la afirmación del sesgo de posición, pero también significa que el artículo está combinando dos fenómenos diferentes: la precisión de recuperación en tareas de coincidencia exacta y la calidad del razonamiento sobre pasajes relevantes. Me gustaría saber si la forma de U empeora o mejora cuando el documento relevante requiere una inferencia de múltiples pasos antes de la respuesta final, y no solo una repetición literal.

También hay una brecha que los autores reconocen en su mayoría pero no cierran: nunca prueban si el ajuste fino de instrucciones (instruction fine-tuning) o el RLHF cambia la sensibilidad a la posición, solo si lo hace una ventana de contexto más grande. Dado que la causa raíz es arquitectónica (enmascaramiento causal), sospecho que el ajuste de instrucciones no lo solucionará, pero el artículo no lo confirma.

Por qué esto importa para la IA financiera​

Este artículo proporciona la explicación mecánica para un patrón empírico que encuentro constantemente. DocFinQA colapsó con informes extensos de la SEC. IRCoT y FLARE recuperan múltiples pasajes y los concatenan antes de razonar. Cada pipeline de RAG que he analizado en un contexto financiero vuelca los pasajes recuperados secuencialmente en el prompt y espera que el modelo preste atención al correcto.

La implicación para los agentes de Beancount es concreta. Si un agente recupera diez asientos del libro mayor como contexto, los asientos en las posiciones 3–7 tienen el mayor riesgo de ser ignorados o de generar alucinaciones a su alrededor. Esto no es un problema de recuperación, es un problema de presentación. Dos respuestas se derivan de este artículo: o se colocan los asientos más relevantes para el diagnóstico al principio (y al final), o no se concatena en absoluto y se razona sobre un pasaje a la vez.

El hallazgo también complica la narrativa de los LLM de contexto largo. Cada trimestre, un nuevo modelo anuncia una ventana de contexto más grande. Este artículo dice que el hecho de que la ventana sea larga no significa lo que crees si distribuyes la evidencia de manera uniforme en ella. Un modelo de contexto de 128K que entierra la transacción relevante en la posición 60K es peor que un modelo de contexto de 4K que recupera precisamente el pasaje correcto.

Para la seguridad de escritura (write-back safety), las implicaciones son incómodas: si se le pide al modelo que resuma una sesión del libro mayor y la regla de política relevante de "no publicar esta transacción" aparece en medio de un prompt de sistema largo, el modelo puede actuar como si nunca hubiera leído esa regla.

Qué leer a continuación​

• "Found in the Middle: How Language Models Use Long Contexts Better via Plug-and-Play Positional Encoding" (Zhang et al., arXiv:2403.04797): propone la Codificación Posicional Multiescala (Ms-PoE) como una solución sin entrenamiento mediante el escalado de RoPE; afirma una mejora de hasta 3.8 puntos en Zero-SCROLLS, abordando directamente la curva en U.
• "Never Lost in the Middle: Mastering Long-Context Question Answering with Position-Agnostic Decompositional Training" (arXiv:2311.09198): toma el enfoque opuesto y entrena al modelo para que sea explícitamente agnóstico a la posición; la comparación con Ms-PoE aclara si el ajuste fino o los trucos en tiempo de inferencia son la mejor palanca.
• "Mitigate Position Bias in Large Language Models via Scaling a Single Dimension" (arXiv:2406.02536): identifica la dimensión específica de los estados ocultos posicionales responsable del sesgo y la escala sin reentrenamiento; la solución más quirúrgica propuesta hasta ahora, relevante para desplegar modelos existentes sin reentrenar.

El artículo​

Tiankai Yang, Yi Nian y sus colegas de la USC y Texas A&M presentan AD-LLM (arXiv:2412.11142, ACL Findings 2025), el primer benchmark para evaluar sistemáticamente los LLM a través de tres paradigmas de detección de anomalías en conjuntos de datos de PNL. El entorno es la clasificación de una clase: los datos de entrenamiento contienen solo muestras normales y el modelo debe marcar las anomalías en el momento de la prueba. Los cinco conjuntos de datos —AG News, BBC News, IMDB Reviews, N24 News y SMS Spam— se derivan de tareas de clasificación de texto con una categoría designada como anómala. El artículo enfrenta a dos LLM, GPT-4o y Llama 3.1 8B Instruct, contra 18 líneas base no supervisadas tradicionales que abarcan métodos de extremo a extremo (CVDD, DATE) y combinaciones de dos pasos de incrustación más detector (embeddings de OpenAI + LUNAR, LOF, Isolation Forest, etc.).

Ideas clave​

• La detección zero-shot funciona bien para texto. GPT-4o obtiene un AUROC de 0,9293–0,9919 en los cinco conjuntos de datos en la configuración Normal+Anomalía; Llama 3.1 alcanza 0,8612–0,9487. La mejor línea base tradicional, OpenAI + LUNAR, obtiene alrededor de 0,92 en AG News; GPT-4o iguala o supera esto sin ningún entrenamiento.
• El aumento sintético ayuda, de forma consistente pero modesta. Las muestras sintéticas generadas por LLM mejoran el flujo de trabajo de OpenAI + LUNAR en los cinco conjuntos de datos. El aumento de la descripción de la categoría también mejora la mayoría de las líneas base, aunque las ganancias son desiguales: Llama 3.1 mejora el AUROC en +0,07 en IMDB Reviews, pero los resultados en otros lugares son menores.
• La selección de modelos es el eslabón débil. GPT-o1-preview recomienda modelos que superan el rendimiento promedio de la línea base en la mayoría de los conjuntos de datos y, ocasionalmente, se acerca al mejor método (por ejemplo, en IMDB Reviews y SMS Spam). Pero nunca identifica de manera fiable al de mejor rendimiento, y los autores reconocen que las recomendaciones se basan en entradas simplistas que carecen de estadísticas específicas del conjunto de datos.
• La brecha entre código abierto y propietario es real. La ventaja de AUROC de GPT-4o sobre Llama 3.1 8B es de 4 a 13 puntos según el conjunto de datos, una brecha consistente con el patrón visto en los artículos de detección de anomalías tabulares zero-shot.
• La detección de anomalías en PNL aún carece de un benchmark definitivo. Cinco conjuntos de datos, todos derivados de corpus de clasificación, es una muestra reducida. El artículo complementario NLP-ADBench (EMNLP Findings 2025) amplía a ocho conjuntos de datos y 19 algoritmos, pero sigue utilizando la misma construcción de categoría semántica como anomalía que hace que estas tareas sean algo artificiales.

Qué se sostiene y qué no​

Los hallazgos de zero-shot son creíbles. Usar LLM como evaluadores sin un ajuste fino en datos de anomalías etiquetados es genuinamente útil cuando la clase de anomalía es semánticamente coherente: un mensaje de spam difiere de un mensaje legítimo de maneras que un modelo de lenguaje bien entrenado comprende. Las cifras de AUROC son altas y la comparación con líneas base sólidas basadas en embeddings de OpenAI es justa.

Sin embargo, el alcance es estrecho de una manera que el artículo minimiza. Los cinco conjuntos de datos codifican las anomalías como una categoría temática diferente: spam frente a SMS legítimos, noticias de un editor excluido frente a medios dentro de la distribución. Esto significa que el LLM está haciendo esencialmente una clasificación de temas, una tarea para la cual está explícitamente pre-entrenado. El benchmark no incluye anomalías semánticas dentro de una sola categoría (por ejemplo, transacciones inusuales dentro del mismo tipo de cuenta), que es precisamente el tipo de anomalía que importa para la auditoría financiera.

Las tareas de aumento de datos y selección de modelos se evalúan en los mismos cinco conjuntos de datos, por lo que el artículo termina evaluando si los LLM pueden mejorar marginalmente diferentes ángulos del mismo problema estrecho. Los autores enumeran libremente seis limitaciones, incluyendo que solo prueban un subconjunto de LLM, excluyen regímenes de few-shot y fine-tuning, y dependen de entradas simplistas para la selección de modelos, lo cual es intelectualmente honesto pero también señala cuán preliminar es este benchmark.

Un resultado que vale la pena señalar para los escépticos: las puntuaciones de AUPRC son sustancialmente más bajas que las de AUROC para ambos modelos. Llama 3.1 en BBC News alcanza un AUROC de 0,8612 pero solo un AUPRC de 0,3960, lo que refleja el desequilibrio de clases en la configuración de una sola clase. En contextos de auditoría de alta precisión, el AUPRC es la métrica más significativa, y aquí el panorama es menos halagador.

Por qué esto importa para la IA financiera​

La agenda de Bean Labs involucra dos casos de uso de detección de anomalías: capturar entradas de libros mayores inusuales en tiempo real (tabulares, estructuradas) y marcar texto narrativo sospechoso en facturas, memorandos o tickets de soporte (PNL no estructurado). AD-LLM habla directamente al segundo caso y nos da un techo realista: GPT-4o puede detectar anomalías a nivel de tema en texto en modo zero-shot con un AUROC superior a 0,93 en conjuntos de datos limpios y equilibrados. Esa es una referencia útil, pero las anomalías en la narrativa de los libros mayores son más sutiles: un memorando de factura que describe un servicio rutinario pero que pertenece a un proveedor marcado por patrones sospechosos no es un problema de clasificación de temas. El benchmark proporciona un punto de partida, no una respuesta final.

El hallazgo sobre la selección de modelos es interesante por separado para el diseño de sistemas. El sueño de preguntar a un LLM "¿qué detector de anomalías debería usar en este conjunto de datos?" y obtener una respuesta fiable aún no se cumple. Eso significa que elegir entre el ajuste fino al estilo AnoLLM, el prompting causal al estilo CausalTAD o un método de incrustación clásico todavía requiere juicio humano o una evaluación empírica sistemática; no puede delegarse en un asesor LLM.

Qué leer a continuación​

• NLP-ADBench (arXiv:2412.04784, EMNLP Findings 2025): el benchmark complementario del mismo grupo, que cubre ocho conjuntos de datos y 19 algoritmos; proporciona el contexto más amplio de líneas base clásicas que el alcance de cinco conjuntos de datos de AD-LLM no puede ofrecer.
• Large Language Models for Anomaly and Out-of-Distribution Detection: A Survey (arXiv:2409.01980, NAACL Findings 2025): analiza todo el panorama de los enfoques de detección de anomalías basados en LLM en modalidades de texto, imagen y tabulares; contextualiza dónde se sitúa AD-LLM en relación con trabajos previos.
• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025): la contraparte tabular; comparar su enfoque basado en la verosimilitud con la estrategia zero-shot basada en prompts de AD-LLM aclara qué paradigma es más apropiado para las entradas del libro mayor de Beancount.

El artículo​

Wang et al. proponen CausalTAD, un método que se sitúa sobre los detectores de anomalías LLM al estilo de AnoLLM y realiza un cambio específico: en lugar de serializar las filas tabulares en un orden de columnas aleatorio o arbitrario, descubre las dependencias causales entre las columnas y las reordena para respetar esas dependencias antes de que el LLM lea la fila.

El artículo tiene dos partes móviles. Primero, un módulo de ordenación de columnas basado en causalidad. Los autores adaptan el marco de extracción de factores COAT: un LLM lee los metadatos de las columnas y muestras para extraer factores semánticos de alto nivel (para transacciones de tarjetas de crédito, un factor como "Compensación" podría abarcar las columnas de importe y de comercio). A partir de estos factores, tres algoritmos de descubrimiento causal —PC, LiNGAM y FCI— construyen cada uno un grafo causal dirigido sobre los factores. El problema de reordenación de columnas se convierte entonces en un Problema de Ordenación Lineal: encontrar la permutación π que maximice la suma de los pesos de las aristas dirigidas, de modo que las columnas causa aparezcan antes que las columnas efecto en el texto serializado. Dado que el problema de programación lineal tiene muchas soluciones casi óptimas, muestrean K ≈ 10 ordenaciones dentro del 90% del óptimo y promedian sobre ellas.

Segundo, un módulo de reponderación consciente de la causalidad. No todas las columnas son igualmente relevantes. Una columna que influye en muchos factores obtiene un peso mayor αj = |M⁻¹(cj)|, el recuento de factores a los que contribuye. La puntuación final de anomalía es el promedio ponderado de las log-verosimilitudes negativas por columna a través de las K ordenaciones.

Ideas clave​

• La ordenación de columnas es un sesgo inductivo no trivial para los LLM autorregresivos: colocar una columna causa antes que su columna efecto permite al modelo condicionarse en el contexto correcto al asignar la verosimilitud al efecto.
• El descubrimiento causal a nivel de factores (en lugar de a nivel de columnas brutas) permite que el método maneje tablas de tipos mixtos donde el descubrimiento causal directo entre columnas heterogéneas es ruidoso.
• En 6 conjuntos de datos de referencia de tipos mixtos, CausalTAD con SmolLM-135M alcanza un AUC-ROC promedio de 0.834 frente al 0.803 de AnoLLM — una mejora absoluta de 3.1 puntos con el mismo modelo base.
• Específicamente en el conjunto de datos Fake Job Posts, CausalTAD obtiene 0.873 frente al 0.800 de AnoLLM — una ganancia relativa del 9.1%, lo suficientemente grande como para ser relevante en un sistema de triaje real.
• En 30 conjuntos de datos de referencia numéricos ODDS, CausalTAD logra el mejor AUC-ROC promedio, superando consistentemente a los modelos base clásicos (Isolation Forest, ECOD, KNN) y a los métodos profundos (DeepSVDD, SLAD).
• Los tres algoritmos de descubrimiento causal superaron la ordenación aleatoria en la ablación; LiNGAM aventaja ligeramente a PC y FCI en los conjuntos de datos mixtos.

Qué se sostiene — y qué no​

La afirmación central —que el orden causal de las columnas ayuda— está bien fundamentada. La ablación es clara: sustituir la ordenación aleatoria por cualquiera de los tres métodos de descubrimiento causal mejora los resultados en la referencia de Fake Job Posts (de 0.832 a 0.870–0.873), y la reponderación por recuento de factores ayuda aún más en cada configuración. Es una historia creíble.

Lo que encuentro menos convincente es la suposición de arranque (bootstrapping). El grafo causal se construye utilizando un LLM para extraer factores semánticos de los mismos datos que el sistema debe analizar. Si el LLM no comprende el dominio —por ejemplo, para un sistema de contabilidad a medida con nombres de columnas no estándar— la extracción de factores será errónea, y un grafo causal deficiente es posiblemente peor que una ordenación aleatoria porque introduce un sesgo sistemático. Los autores reconocen este riesgo ("depende de la capacidad de los LLM para la extracción de factores") pero no evalúan la precisión de la extracción de factores de forma independiente.

También existe un problema de sobrecarga computacional que es más serio de lo que sugiere el artículo. Ejecutar tres algoritmos de descubrimiento causal, resolver un problema de programación lineal, muestrear K ordenaciones y luego ejecutar la inferencia en K versiones serializadas de cada punto de prueba multiplica el coste de inferencia por K. Para un libro contable con millones de entradas, esto importa. El artículo señala que "el trabajo futuro puede centrarse en mejorar la eficiencia" pero no ofrece un perfil de rendimiento concreto.

Finalmente, los 30 conjuntos de datos numéricos ODDS están muy estudiados y posiblemente saturados para métodos como este. La señal más significativa se encuentra en los 6 conjuntos de datos de tipos mixtos —que son los realistas para las finanzas— y las mejoras allí, aunque reales, son algo modestas en términos absolutos.

Por qué esto importa para la IA en finanzas​

Las transacciones de Beancount poseen una estructura causal genuina: el importe del apunte impulsa causalmente la selección de la cuenta, la cuenta impulsa la expectativa de la contraparte, y el texto del comentario está causalmente aguas abajo de los tres. La serialización aleatoria de columnas ignora esto, lo que significa que un modelo estilo AnoLLM ve "nota: comestibles | cuenta: Gastos:Alimentación | importe: $4200" con la misma naturalidad que la versión correctamente ordenada.

CausalTAD ofrece una forma fundamentada de codificar que "el importe y la cuenta van primero" sin programarlo como una regla rígida. Para los agentes de auditoría de Bean Labs, esto sugiere una elección arquitectónica práctica: antes de calificar anomalías en un lote de transacciones, realizar una pasada para descubrir el grafo causal sobre el esquema de columnas del libro contable y luego usar esa ordenación fija para todas las inferencias posteriores. La sobrecarga se paga una vez a nivel de esquema, no por transacción.

El ejemplo de detección de fraude en tarjetas de crédito del artículo tiene esencialmente la misma estructura de tareas que la detección de anomalías en libros contables: características heterogéneas, etiquetas poco frecuentes y un orden causal que los expertos del dominio conocen intuitivamente pero que los LLM ignorarían de otro modo.

Qué leer a continuación​

• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025) — la evaluación comparativa sistemática a través de tres paradigmas de detección de anomalías con LLM en los que encaja CausalTAD; leerlo ofrece el panorama completo en lugar de la comparación individual entre AnoLLM y CausalTAD.
• COAT: Boosting Large Language Model-Based In-Context Learning for Tabular Data (Liu et al., 2024) — el marco de extracción de factores que adapta CausalTAD; comprender cómo funciona aclara dónde puede fallar la calidad del grafo causal.
• Causal discovery in heterogeneous data: a survey — para comprender los méritos relativos de PC frente a LiNGAM frente a FCI en datos tabulares de tipos mixtos, ya que el artículo trata a los tres como intercambiables pero parten de diferentes suposiciones de independencia.

El artículo​

AnoLLM redefine la detección de anomalías tabulares como una estimación de densidad del modelo de lenguaje en lugar de una clasificación mediante prompts. En lugar de pedirle al LLM que nombre qué filas parecen sospechosas, los autores realizan un ajuste fino de un modelo de lenguaje preentrenado con filas de entrenamiento serializadas que están dentro de la distribución (normales), y luego puntúan cada fila de prueba mediante su verosimilitud logarítmica negativa (NLL) bajo esa distribución aprendida. Una fila que no se parece en nada a la distribución de entrenamiento obtiene una NLL alta; esa es la puntuación de anomalía. Sin formatos de índice, sin análisis de salida, sin extracciones frágiles mediante regex.

La serialización convierte cada fila de la tabla en una cadena de lenguaje natural con nombres de características y valores. Para las columnas con valores de texto, la NLL se normaliza por columna para evitar el sesgo de longitud, donde las descripciones más largas acumularían mecánicamente mayores costos de probabilidad. Para las columnas numéricas y categóricas, se suma la NLL bruta a nivel de token en todo el campo. El modelo se ajusta en un entorno semisupervisado (solo las filas etiquetadas como normales entran en el entrenamiento) durante un máximo de 2.000 pasos utilizando entrenamiento distribuido por GPU.

Ideas clave​

• El problema del formato de salida: los enfoques previos de predicción de índices requieren que los LLM generen de manera confiable los índices de las filas anómalas de un lote. Los modelos de la familia Llama suelen emparejar índices incorrectos con valores, generar índices más allá del tamaño del lote o simplemente listar todo como anómalo. La NLL evita esto por completo.
• AnoLLM logra el mejor rendimiento en seis conjuntos de datos de referencia con tipos de características mixtos, incluyendo la detección de fraude en seguros de vehículos y conjuntos de datos de fraude en comercio electrónico de Kaggle.
• En los 30 conjuntos de datos del benchmark ODDS, predominantemente numéricos, AnoLLM rinde a la par con las mejores referencias clásicas: no es claramente mejor, solo competitivo.
• La normalización de la NLL por columna para las características de texto es una decisión de ingeniería pequeña pero fundamental: sin ella, una descripción de transacción con treinta tokens dominaría la puntuación sobre un importe de dos dígitos, lo cual es un sesgo inductivo incorrecto.
• El contexto de la referencia de entrenamiento: el enfoque zero-shot de GPT-4 (arXiv:2406.16308) logra un AUROC promedio de 74.1 en ODDS, comparable a ECOD (75.5) y KNN (70.7). La ventaja de AnoLLM aparece específicamente en conjuntos de datos donde las características de texto y categóricas contienen una señal de anomalía significativa.

Lo que se mantiene y lo que no​

La idea central de la NLL es sólida. Usar un modelo de lenguaje con ajuste fino como estimador de densidad sobre filas serializadas es fundamentado y maneja naturalmente la distribución conjunta de todas las columnas simultáneamente, algo que los detectores no supervisados clásicos aplicados columna por columna no pueden hacer limpiamente. La solución a la predicción de índices es realmente útil y la comparación con la referencia zero-shot es justa.

Lo que me inquieta es la brecha de costo-beneficio que el artículo no reporta suficientemente. AnoLLM requiere el ajuste fino y el despliegue de un LLM para la inferencia, lo que supone un compromiso de infraestructura sustancial en comparación con el ajuste de ECOD o IsolationForest en una CPU en cuestión de segundos. En el benchmark ODDS (puramente numérico), AnoLLM está solo "a la par", no mejor. Por lo tanto, el argumento a favor de AnoLLM reside enteramente en el régimen de tipos mixtos, donde los seis conjuntos de datos evaluados provienen de la detección de fraude en Kaggle. Seis conjuntos de datos es una base empírica delgada para una recomendación sólida, especialmente porque los conjuntos de datos de referencia de Kaggle suelen tener esquemas limpios, semántica de columnas fija y verdades fundamentales conocidas, cosas de las que suelen carecer los datos de los libros mayores en producción.

El problema del orden de las columnas también queda abierto. CausalTAD (arXiv:2602.07798) identificó inmediatamente esta brecha: AnoLLM serializa las columnas en un orden arbitrario, ignorando las relaciones causales entre los campos. Para datos estructurados con cadenas causales conocidas (el tipo de cuenta influye en los rangos de transacción válidos, lo que a su vez influye en la contraparte esperada), esta es una limitación real. CausalTAD plantea el reordenamiento como un problema de ordenamiento lineal y reporta una mejora constante sobre AnoLLM en más de 30 conjuntos de datos. Que la brecha existiera y fuera detectable tan rápido sugiere que el diseño de serialización de AnoLLM no fue pensado del todo.

También hay una cuestión de escala que el artículo no aborda: ¿con qué volumen de ejemplos de entrenamiento normales vale la pena el ajuste fino de un LLM sobre, por ejemplo, un modelo de aprendizaje profundo tabular entrenado directamente sobre las características numéricas? Para libros mayores de Beancount personales con unos pocos miles de entradas, el costo de cómputo podría eclipsar fácilmente cualquier ganancia de precisión.

Por qué esto es importante para la IA en finanzas​

Los asientos contables de Beancount son exactamente el tipo de datos mixtos a los que se dirige AnoLLM: importes (numéricos), nombres de cuentas (texto estructurado), beneficiario/narración (texto libre), etiquetas (categóricas), fechas (estructuradas). Una sola fila como 2024-03-15 * "AWS" "Factura de nube" Assets:Checking -$2,400 codifica información en todos estos tipos simultáneamente. Los detectores de anomalías clásicos tienen dificultades aquí porque necesitan un manejo separado para cada tipo de columna y pierden las correlaciones entre ellas: el patrón conjunto de que las facturas de "AWS" deberían estar en un rango determinado e impactar en una cuenta específica.

El enfoque NLL de AnoLLM, en principio, aprendería estos patrones conjuntos a partir de entradas históricas normales y marcaría desviaciones en cualquier combinación de columnas. Esto es potencialmente más útil que los JET basados en reglas o las pruebas estadísticas de una sola columna.

Dicho esto, la restricción de la contabilidad de partida doble es un conocimiento estructural que AnoLLM no puede aprender solo de filas serializadas: los débitos deben ser iguales a los créditos y se deben respetar las jerarquías de cuentas. Estos invariantes de dominio son restricciones estrictas, no regularidades estadísticas, y ningún ajuste fino de LLM en filas históricas los hará cumplir de manera confiable si los datos de entrenamiento contienen excepciones o artefactos de redondeo. La arquitectura correcta probablemente combine la puntuación NLL de AnoLLM para anomalías semánticas con comprobaciones de reglas explícitas para las estructurales.

Qué leer a continuación​

• CausalTAD (arXiv:2602.07798): mejora directamente a AnoLLM inyectando un orden causal de columnas; es el seguimiento más inmediato a evaluar.
• AD-LLM: Benchmarking Large Language Models for Anomaly Detection (arXiv:2412.11142, ACL Findings 2025): proporciona la evaluación sistemática multparadigma que falta en los artículos de métodos individuales.
• "Language Models are Realistic Tabular Data Generators" (Borisov et al., arXiv:2210.06280, ICLR 2023): el modelo BE-GREAT que AnoLLM utiliza como base; comprenderlo aclara qué mejora AnoLLM realmente más allá de la predicción de índices.

El artículo​

Figueroa, Grundmann, Freidank, Löser y Nejdl evalúan cinco modelos de pesos abiertos de ~7B en un benchmark de dos tareas que llaman LLMFinLiteracy. La Tarea 1 pide a los modelos generar escenarios textuales que afectarían a un ratio de liquidez dado (ratio de liquidez corriente, prueba ácida o disponibilidad inmediata) basándose en un balance de situación trimestral real de una de las cinco empresas que cotizan en el DAX (Airbus, Bayer, Deutsche Telekom, Mercedes-Benz, SAP). La Tarea 2 pide a los modelos traducir esos escenarios en transacciones de Beancount compilables. El compilador de Beancount sirve como verificador de sintaxis de referencia; expertos en el dominio humano evalúan la corrección semántica. El artículo introduce una taxonomía de errores de 12 clases en las dos tareas y utiliza un prompt de cadena de pensamiento de 9 pasos que incluye reglas de contabilidad por partida doble, un ejemplo de entrada/salida y el balance real de la empresa en formato Beancount. Los modelos evaluados —Llama-3-8B, Qwen-2-7B, Mistral-7B, CodeLlama-7B y CodeQwen-1.5-7B— se ejecutaron todos de forma local debido a la sensibilidad de los datos financieros. El corpus suma 1.500 muestras generadas, con 300 entradas estratificadas evaluadas por expertos humanos.

Ideas clave​

• Solo 7 de los 300 pares escenario-transacción evaluados (2,3%) fueron totalmente correctos de principio a fin; incluso restringiéndose a los tres modelos de propósito general, la tasa solo sube al 3,8%.
• Los dos mejores modelos, Qwen-2-7B y Mistral-7B, producen escenarios correctos solo el 21,67% y 20,00% de las veces, y transacciones que compilan correctamente solo el 16,67% y 10,00% de las veces.
• Los modelos especializados en código (CodeLlama, CodeQwen) obtuvieron un 0% en ambas tareas; respondieron a la plantilla del prompt con una cadena literal "Processed — Waiting for next input", ignorando completamente la tarea.
• La sintaxis no es el cuello de botella: ningún modelo produjo un solo error de sintaxis. Los fallos se encuentran enteramente en el razonamiento contable: los errores de balance dominan en Qwen-2 (61,67%) y Llama-3 (38,33%), mientras que Mistral mayoritariamente hace referencia a cuentas que no existen en el balance proporcionado (45% de errores de cuenta desconocida).
• Una fracción significativa de las transacciones que compilan con éxito son semánticamente incorrectas; el truco favorito del modelo es llamar a la disminución de un pasivo "vender tu deuda", lo que aumenta el efectivo pero por la razón equivocada.
• GPT-4o, utilizado como juez automatizado, no logró señalar inconsistencias en ninguno de los 10 escenarios sin sentido que se le mostraron, confirmando que la autoevaluación de los LLM no es un control de calidad fiable para los resultados contables.
• Los modelos copian en gran medida el ejemplo de entrada/salida del prompt en lugar de generalizar: los 7 pares correctos se parecen mucho a la estructura de la transacción de ejemplo proporcionada.

Qué se sostiene y qué no​

La contribución empírica central del artículo es sólida. El compilador de Beancount es un criterio de corrección objetivo y reproducible, y el uso de balances reales de empresas en lugar de datos de juguete añade validez ecológica. La taxonomía jerárquica de errores está cuidadosamente diseñada: detener la evaluación ante el primer error evita inflar el "crédito parcial" para resultados que son basura.

Dicho esto, existen limitaciones obvias que los autores reconocen en su mayoría. Cinco modelos de pesos abiertos de ~7B de 2023–2024 son una muestra estrecha del panorama de capacidades; GPT-4o y Claude fueron excluidos por razones de privacidad, lo cual es comprensible pero significa que la cifra principal (2,3% de aciertos) subestima la frontera tecnológica. Las fórmulas de los ratios financieros se omitieron deliberadamente de los prompts para probar el conocimiento intrínseco del dominio —una elección metodológicamente interesante, pero que hace que los resultados sean incomparables con cualquier sistema que razonablemente incluiría documentación de las fórmulas. Y 300 muestras evaluadas por humanos entre cinco modelos, tres ratios y cinco empresas es modesto; las celdas por modelo y por ratio son demasiado pequeñas (12 muestras) para extraer conclusiones sólidas sobre la varianza.

La brecha metodológica más interesante es la ausencia de cualquier protocolo iterativo o basado en feedback. Sin llamadas a herramientas, sin autocorrección, sin bucle de retroalimentación del compilador: solo generación en un solo paso (one-shot). Dado que CRITIC (LOG-012) y trabajos relacionados muestran que el refinamiento interactivo con herramientas mejora sustancialmente la precisión en tareas con resultados verificables, un experimento con el compilador de Beancount en el bucle habría sido mucho más informativo sobre la viabilidad de implementación.

Por qué esto importa para la IA en finanzas​

Cada decisión de diseño para el agente de escritura de Bean Labs se basa en suposiciones sobre lo que los LLM pueden hacer con el DSL de Beancount. Este artículo es el primer anclaje empírico. Los hallazgos principales son aleccionadores pero también interpretables de una manera útil.

Primero, los modos de fallo son específicos, no aleatorios. Los errores de balance y las cuentas desconocidas son los dos problemas dominantes, y ambos son abordables con un bucle de feedback con el compilador: el compilador de Beancount te dice exactamente qué cuenta es desconocida y si la transacción cuadra. Una arquitectura de agente que itere sobre la salida del compilador —en lugar de generar una vez y detenerse— debería superar sustancialmente los resultados de un solo paso presentados aquí. Segundo, la sintaxis es gratuita. Los modelos han aprendido claramente la gramática superficial de Beancount; simplemente no pueden traducir de manera fiable la intención financiera en movimientos de cuenta correctos. Esa distinción es importante para saber dónde invertir en prompting y ajuste fino (fine-tuning). Tercero, el hallazgo de que GPT-4o no puede evaluar la calidad contable automáticamente eleva el listón para cualquier sistema de verificación automatizado: se necesita el compilador, además de comprobaciones puntuales de expertos en el dominio, no un crítico LLM.

El artículo también confirma algo que sospechaba del trabajo de detección de anomalías (LOG-049): los LLM que operan sobre transacciones financieras compilan y envían con demasiada facilidad. La categoría "Incorrecto | Compila" —transacciones que pasan la verificación sintáctica pero son semánticamente erróneas— es exactamente el modo de fallo que un guardarraíl de seguridad de escritura debe capturar. Una transacción puede cuadrar perfectamente y aún así registrar ingresos como una disminución de pasivo, lo que pasaría inadvertido para cualquier verificación puramente sintáctica.

Qué leer a continuación​

• AnoLLM: Large Language Models for Tabular Anomaly Detection (OpenReview:7VkHffT5X2, ICLR 2025) — puntuación de anomalías basada en verosimilitud como alternativa al enfoque de detección por lotes; se combina naturalmente con una señal del compilador de Beancount para marcar entradas estructuralmente válidas pero estadísticamente anómalas.
• ReDAct: Uncertainty-Aware Deferral for LLM Agents (arXiv:2604.07036) — deriva decisiones de baja confianza a un modelo más grande o a un humano; aborda directamente la cuestión de cuándo un agente de escritura de Beancount debería delegar en la revisión humana en lugar de proceder tras un bucle de feedback del compilador.
• CRITIC: Large Language Models Can Self-Correct with Tool-Interactive Critiquing (arXiv:2305.11738, ICLR 2024) — el trabajo existente más relevante para construir un agente de corrección con el compilador en el bucle sobre la arquitectura que este artículo evalúa.