FinanceBench: Por qué el RAG de almacenamiento de vectores falla con documentos financieros reales

FinanceBench llega en un momento en que cada proveedor de IA empresarial afirma que su sistema puede "responder preguntas de sus documentos financieros". Este artículo de Patronus AI pone a prueba esas afirmaciones utilizando presentaciones reales ante la SEC y preguntas de "libro abierto" cuidadosamente seleccionadas. Los resultados son una lectura incómoda para cualquiera que esté construyendo IA para finanzas.

El artículo

Islam et al. presentan FinanceBench: A New Benchmark for Financial Question Answering (arXiv:2311.11944), una suite de pruebas de 10,231 preguntas sobre empresas que cotizan en bolsa extraídas de presentaciones reales ante la SEC: informes anuales 10-K, presentaciones trimestrales 10-Q, informes actuales 8-K y transcripciones de llamadas de resultados. A diferencia de los conjuntos de datos de preguntas y respuestas financieras anteriores (FinQA, TAT-QA), que presentan tablas y pasajes pre-extraídos, FinanceBench requiere que un sistema recupere evidencia de documentos completos antes de responder. Ese es el entorno realista. Las preguntas están diseñadas para ser fácticamente inequívocas y, en palabras de los autores, "un estándar mínimo de rendimiento".

El equipo evaluó 16 configuraciones que abarcan GPT-4-Turbo, Llama2 y Claude2 a través de cuatro estrategias de recuperación: libro cerrado (sin recuperación), almacenamiento de vectores compartido, almacenamiento de vectores por documento y prompts de contexto largo que alimentan la página relevante completa. Evaluadores humanos revisaron manualmente las 2,400 respuestas de 150 casos de código abierto.

Ideas clave

• La recuperación no es el cuello de botella. GPT-4-Turbo, al recibir el pasaje del oráculo (la página exacta que contiene la respuesta), solo alcanza el 85% de precisión. El prompting de contexto largo (alimentando la página correcta automáticamente) obtiene un 79%. Una recuperación perfecta solo mejora el resultado en seis puntos.
• El RAG de almacenamiento de vectores es el verdadero problema. GPT-4-Turbo con un almacenamiento de vectores por documento: 50% correcto, 39% rechazado. Con un almacenamiento de vectores compartido entre empresas: 19% correcto, 68% rechazado. El titular "tasa de fallo del 81%" proviene de esa configuración de almacenamiento compartido, que es la que realmente utilizan la mayoría de las demostraciones empresariales.
• Los modelos fallan de manera diferente. Llama2 alucina agresivamente (54–70% incorrecto); GPT-4-Turbo rechaza (39–68% rechazado en lugar de erróneo). Ambos modos de fallo son inaceptables en producción, pero no representan riesgos equivalentes.
• El 66% de las preguntas requieren razonamiento numérico. Tasas de crecimiento, márgenes, deltas interanuales. Aquí es donde los modelos fallan más comúnmente: errores de cálculo, confusión de unidades, errores de signo.
• El contexto largo casi lo rescata. Claude2 con contexto largo: 76% correcto. GPT-4-Turbo con contexto largo: 79%. Estos son los mejores números prácticos, logrados omitiendo la recuperación y alimentando directamente toda la página relevante.
• Incluso el oráculo tiene filtraciones. Con evidencia perfecta, el techo es del 85%, no del 100%. El quince por ciento de los fallos son fallos de razonamiento puro sin componente de recuperación.

Qué se sostiene y qué no

El diseño del benchmark es sólido. Insistir en documentos reales en lugar de fragmentos pre-extraídos es la elección metodológica correcta; pone a prueba lo que realmente importa en el despliegue. La evaluación manual de 2,400 respuestas es costosa y creíble.

Lo que encuentro menos convincente es extraer clasificaciones de n=150. La diferencia entre Claude2 con contexto largo (76%) y GPT-4-Turbo con contexto largo (79%) carece de significado estadístico con ese tamaño de muestra, pero el artículo lo presenta como una clasificación. El benchmark completo de 10,231 preguntas existe pero no tiene una puntuación pública, lo que limita la reproducción independiente.

El resultado del oráculo es también el hallazgo más importante y menos analizado. Si los modelos fallan el 15% de las veces con la página correcta en la mano, el problema es el razonamiento y la aritmética, no la recuperación. El artículo señala las herramientas de calculadora y la cadena de pensamiento (chain-of-thought) como trabajo futuro; esos experimentos deberían haber sido el centro de este artículo, no una nota al pie.

El benchmark también reconoce que se dirige a un "rendimiento mínimo": preguntas de un solo documento con respuestas inequívocas. Se excluyen el razonamiento entre documentos, las tendencias plurianuales y las comparaciones entre empresas. Los artículos que citen la cifra del 79% de contexto largo rara vez mencionarán esta advertencia.

Por qué esto importa para la IA financiera

El caso de uso de escritura inversa (write-back) de Beancount se ajusta casi directamente a los modos de fallo de FinanceBench. Un agente que recupera una entrada de transacción y verifica si el monto coincide con un extracto bancario está realizando la misma tarea de recuperación y aritmética que mide este benchmark. El techo del oráculo (85% incluso con un contexto perfecto) es la restricción de diseño relevante: incluso si el agente encuentra la entrada correcta en el libro contable, existe una probabilidad real de que calcule mal la comparación, confunda el signo o lea mal las unidades.

La división de fallos entre Llama2 y GPT-4 importa para la arquitectura del agente. Un rechazo es recuperable (se deriva a revisión humana); una coincidencia alucinada registrada en el libro contable no lo es. Esto aboga por preferir un comportamiento de rechazo conservador sobre una alucinación confiada, incluso a costa de una tasa de éxito aparente más baja.

La ventaja del contexto largo (79% frente a 50%) es prácticamente frustrante para las aplicaciones de libros contables. Los archivos de Beancount de varios años son demasiado grandes para alimentarlos completos. Resolver la recuperación sobre documentos numéricos densos —no solo la recuperación de texto— sigue siendo un problema abierto.

Qué leer a continuación

• FinQA: A Dataset of Numerical Reasoning over Financial Data (Chen et al., EMNLP 2021, arXiv:2109.00122): el benchmark precursor que FinanceBench mejora explícitamente; útil para entender qué hizo bien el campo antes de que se requiriera la recuperación de documentos reales.
• DocFinQA: A Long-Context Financial Reasoning Dataset (Reddy et al., ACL 2024): amplía FinanceBench con preguntas de múltiples saltos más difíciles que requieren razonamiento entre secciones dentro de una misma presentación.
• PAL: Program-Aided Language Models (Gao et al., arXiv:2211.10435, ICML 2023): delega la aritmética a un intérprete de Python, abordando directamente el 66% de las preguntas de FinanceBench que fallan en el razonamiento numérico.