Tu LLM no es un pipeline de documentos

Hay un momento en todo proyecto de IA donde la demo se ve tan bien que tu cerebro empieza a borrar código silenciosamente. Ves un modelo "leer" un extracto bancario y piensas: esto es. Podemos saltarnos el OCR. Podemos saltarnos el análisis de layout. Quizás podemos saltarnos la mitad del pipeline. En la versión de película, alguien presiona Enter y cae una cascada de JSON desde la nube.

En la realidad, la cascada es un goteo. Y alguien todavía tiene que traer un trapeador.

Escribimos esto desde el tejido cicatricial de intentar hacer que los LLMs y VLMs hagan extracción de extremo a extremo (end-to-end) en PDFs financieros. No un documento de tres páginas cuidadosamente seleccionado con un kerning perfecto, sino los PDFs sin glamour que aparecen en producción: 120 páginas, múltiples layouts y algunos escaneos en el medio, con una marca de taza de café dándote una útil marca de agua alrededor de la página 42.

Si quieres el final por adelantado: los modelos son excelentes asistentes dentro de un pipeline de documentos. Son pésimos pipelines.

El primer éxito

Mi primer éxito fue casi cinematográfico. Le mostré una página limpia a un modelo de visión-lenguaje. "Dame fecha, comerciante, monto, saldo". Obedeció, cortésmente, en JSON. Los límites de la tabla se veían bien. Las marcas decimales eran correctas. Escribí un mensaje de Slack al equipo que empezaba con "Y si..."

Esta es la parte donde la cámara corta a un montaje mío intentando "Y si..." en un extracto real.

Mismo banco, plantilla diferente. Totales renombrados de "Este periodo" a "Subtotal". Débitos impresos como positivos. Un salto de página que corta una descripción de fila por la mitad. Un eslogan en el encabezado que el modelo decide que es la última línea de una transacción. Un escaneo con líneas de cuadrícula gris claro que se desvanecen lo suficiente para confundir la detección de filas. Fila perdida, contenido alterado, repeticiones.

Ser servicial es el problema. Ser servicial no es auditable.

Aquí hay un ejemplo concreto de dónde tropiezan los VLMs incluso con la afirmación del "mejor modelo de OCR del mundo" de Mistral AI.

Comparando los dos, la columna Crédito desaparece y varios valores aterrizan en las columnas equivocadas, un fallo clásico de estructura de tabla.

En contraste, los modelos de Holofin están entrenados específicamente para la estructura de tablas financieras. En estas páginas, y esas están en el rango inferior de la escala de complejidad, recuperan el esquema completo y corrigen las asignaciones de celdas con perfecta precisión. Si quieres reemplazar la entrada manual de datos, obtener la estructura correcta en la etapa de OCR es innegociable.

Las formas silenciosas en que un modelo puede equivocarse

Lo que nos pone nerviosos no son los errores obvios. Esos son fáciles de atrapar. Lo que nos pone nerviosos son los verosímiles.

Puedes mirar la salida de un modelo y sentir que todo está bien. Los números están formateados. Los campos están presentes. El JSON valida. Solo más tarde notas que un "Total" aparentemente razonable es una cifra del año hasta la fecha (year-to-date), o que un saldo inicial se leyó como una transacción, o que una línea envuelta fusionó dos comerciantes en una quimera que nunca existió. Nadie lanzó un error; el sistema siguió adelante.

Solíamos pensar que este es un problema de precisión. No lo es (o no solo). Es un problema de calibración. Precisión es "¿Qué tan cerca estamos?". Calibración es "¿Cuánto deberíamos confiar en esto?". Los modelos parecen precisos en las demos. Los pipelines necesitan calibración en producción.

Como vimos, hay publicaciones de blog y pruebas públicas que refuerzan esto. Algunos VLMs comercializados como "capaces de OCR" pueden, de hecho, leer tablas ordenadas en páginas ordenadas, pero tropiezan con el tipo exacto de desorden que acabamos de describir. Calidad del escaneo, deriva del layout, signos de los montos: los tipos de variaciones que son rutina en el mundo real convierten extracciones seguras en ficción segura. No necesitas malicia para alucinar; solo necesitas la página 57.

El costo que nadie cita en la demo

También está la factura.

Toma un ejemplo conservador: un extracto de 120 páginas. Incluso si lo divides en dos páginas por solicitud, estás enviando ~60 prompts. Agregarás instrucciones, tal vez algunos ejemplos para estabilizar las salidas. Si estás usando un VLM, cada página es un embedding de imagen encima de los tokens. Multiplica por 60. Multiplica por reintentos. Multiplica por una segunda pasada cuando te des cuenta de que necesitas verificación. La latencia sube de "rápida" a "hazte un té". El costo sube de centavos a euros.

Orden de magnitud, no una promesa: procesar un archivo de más de 100 páginas con un solo VLM grande puede aterrizar en el vecindario de "varios euros por documento", y minutos de tiempo real (wall time).

Puedes, por supuesto, ajustar esto hacia abajo, pero nota lo que eso implica. Los mismos trucos que lo hacen asequible (modelos más pequeños, menos llamadas, prompts más ajustados) generalmente provienen de hacer menos con el modelo y más con código. Lo que nos lleva a la parte aburrida e ineludible.

Y la factura se infla silenciosamente cuando agregas "k-LLM" o astucia Agéntica. Enrutas las páginas raras a un segundo modelo, muestreas dos veces para estar más seguro, agregas una pasada de verificación, tal vez subtitulas primero y extraes después—cada red de seguridad es otro viaje de ida y vuelta y otro taxímetro corriendo. Lo que parecía una llamada se convierte en un pequeño comité, y el costo simplemente se infla.

El pipeline que terminas construyendo de todos modos

En algún momento dejamos de preguntar "¿Puede un modelo leer esto?" y empezamos a preguntar "Si el modelo lee esto, ¿podemos probarlo?"

La prueba no es sexy. Significa que guardas coordenadas para cada token. Significa que puedes mostrarle a un regulador el cuadro de píxeles en la página 83 que se convirtió en "€-1,237.45". Significa que concilias saldos iniciales y finales a través de las páginas, y te asustas si la suma de los deltas no coincide. Significa que notas cuando dos totales diferentes viven en la misma página y no están de acuerdo sobre ser totales.

Puedes hacer todo eso con modelos. Pero una vez que has escrito suficiente andamiaje para estar seguro (la redundancia de OCR, la geometría, los parsers estrictos, la conciliación) sucede algo curioso: el modelo ya no es el héroe. Es el especialista al que llamas para disputas y casos extremos.

Esto es algo bueno.

Donde el modelo realmente brilla

Todavía nos gustan estos modelos. Solo nos gustan en el alcance correcto.

Si dos pasadas deterministas no están de acuerdo sobre la convención de signos 'Débito/Crédito'—por ejemplo, montos impresos como positivos con una columna D/C separada, pídele al modelo que arbitre y explique su elección. Si un encabezado cambió silenciosamente de 'Frais' a 'Frais de tenue de compte' o 'Commissions d’intervention', pídele al modelo que lo mapee a tu esquema canónico. Si hay una nota al pie como 'dont TVA 20 %' o una sección 'CB différé' que cambia cuándo se aplican los montos, pídele al modelo que lo marque antes de clasificar erróneamente un lote de transacciones.

En otras palabras: trata al modelo como un juez o traductor. No le pidas que sea el escáner, el parser y el contador.

¿Pero no están mejorando los modelos?

Absolutamente. Nos encantaría estar equivocados en seis meses. Contextos más grandes reducen el dolor de la fragmentación (chunking). Los backbones de visión siguen mejorando. El uso de herramientas y el multi-pass ayudan muchísimo.

Incluso entonces, las partes que nos importan para los documentos financieros no desaparecen: procedencia, conciliación, detección de deriva y la capacidad de explicar cualquier número a alguien a quien no le importan tus prompts. Mejores modelos hacen que las decisiones de juicio sean más limpias. No nos absuelven de ofrecer recibos.

Si tu caso de uso es "extraer totales de páginas únicas brillantes", tal vez la caja negra esté bien. Si tu caso de uso es "ingestar 120 páginas de extractos de calidad mixta de 17 bancos, cumplir con un SLA y pasar una auditoría", todavía querrás las barandillas (guardrails). También querrás que la factura sea predecible.

La lista de verificación invisible que ahora llevamos

Ya no imprimimos una lista de verificación; simplemente la buscamos como llaves en un bolsillo. ¿Podemos procesar un extracto de 120 páginas sin lanzar tiempos de espera (timeouts)? ¿Retenemos la procedencia de página y coordenadas para cada valor extraído? Si sumamos las transacciones, ¿obtenemos el delta del saldo, o tenemos un agujero en alguna parte? ¿Qué sucede cuando un modelo se atasca en la página 87: seguimos adelante o escondemos el fallo en un sobre JSON ordenado? ¿Podríamos ejecutar esto con los modelos apagados y aún obtener algo utilizable? ¿Notaremos cuando un banco envíe silenciosamente la "Plantilla v7" y mueva una columna, o el sistema aceptará cortésmente la nueva realidad y archivará tonterías bajo los nombres de campo correctos?

Estas no son preguntas de deep learning. Son preguntas de software. Lo cual es reconfortante, honestamente.

Si debes buscar una pelea, busca una pequeña

Lo que consistentemente reduce el costo y aumenta la confianza es la disciplina de alcance. Pídele al modelo que elija entre candidatos, no que invente estructura. Pide un índice, no un párrafo. Agrupa celdas ambiguas para que 20 decisiones cuesten un viaje de ida y vuelta. Cachéalo todo lo que puedas: si has visto una plantilla, aprende sus peculiaridades una vez y reutiliza ese conocimiento. Y cuando el modelo pierda, asegúrate de que pierda de una manera que un humano pueda arreglar en un clic.

Haz esto y obtendrás la magia donde importa: en las esquinas raras donde las reglas se vuelven frágiles. Sáltate esto y obtendrás una forma muy costosa de estar confiadamente equivocado.

Los LLMs y VLMs siguen siendo la parte más encantadora del stack, siempre y cuando no sean todo el stack. El trabajo no es eliminar las partes aburridas. El trabajo es construir cosas aburridas para que la magia tenga algo firme sobre lo que pararse.

En Holofin, nos apoyamos en esa disciplina: construir primero el andamiaje confiable—procedencia, conciliaciones, comprobaciones de deriva—y luego invitar a los modelos a arbitrar donde las reglas se desdibujan. Mantiene los fallos locales y ruidosos, hace que los costos sean predecibles y deja que la magia haga su parte sin cargar con todo el peso.

Actualización de diciembre de 2025: Mistral OCR 3

Revisamos este tema en diciembre de 2025 cuando Mistral lanzó mistral-ocr-3. A pesar de la nueva versión y las continuas afirmaciones de una mejor comprensión de documentos, observamos los mismos problemas espaciales en las tablas: columnas fusionándose, valores aterrizando en celdas incorrectas y la columna de Crédito desapareciendo en las mismas muestras de extractos bancarios. El desafío fundamental de la recuperación de la estructura de tablas sigue sin resolverse por los VLMs de propósito general.