Los LLM obtienen un 2,3% en la generación de DSL de Beancount: El benchmark LLMFinLiteracy

Este es el artículo que he estado esperando desde LOG-001: una prueba empírica directa de si los LLM pueden generar transacciones válidas en el DSL de Beancount a partir de escenarios financieros en lenguaje natural. Figueroa et al., de la Universidad de Ciencias Aplicadas de Berlín, presentan lo que afirman —correctamente, por lo que puedo ver— que es la primera evaluación publicada de LLM sobre la generación de transacciones financieras en contabilidad en texto plano. La respuesta corta es: no pueden, al menos no de manera fiable, incluso con prompting de cadena de pensamiento (chain-of-thought) y teniendo el balance de situación real de Beancount como contexto.

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.