Un número que falta se nota. Uno equivocado, no.
De ese único desequilibrio se deriva todo lo demás. Leer documentos con un modelo de lenguaje es algo distinto a escribir texto con uno. Cuando un modelo se inventa un párrafo, alguien suele detectarlo al leerlo. Cuando convierte 349.000 en 340.000, ahí queda una cifra plausible, en el campo correcto, con el formato correcto, y nadie tiene motivo alguno para ir a comprobarla.
Los proyectos de extracción rara vez fracasan de forma ruidosa. Fracasan en silencio, en el tercer dígito, medio año después del arranque.
Un número equivocado cuesta más que uno ausente#
Un campo vacío es una interrupción. Alguien ve el hueco, abre la fuente, lo completa. El precio es un minuto de atención y el sistema sigue siendo fiable.
Un campo equivocado es una decisión. Se reenvía, se recoge en una oferta, se suma a un total. Para cuando alguien se da cuenta, ya figura en otros tres sitios, y la pregunta ya no es cuál es la cifra correcta, sino cuál de las cuatro versiones en circulación venía del original.
Eso da la vuelta a la expectativa habitual. En la extracción, la cobertura es el objetivo barato y la exactitud el caro. Un sistema que deja vacío un ocho por ciento de los campos y acierta en el resto vale más que uno que lo rellena todo y se equivoca en silencio en un dos por ciento.
Por qué los números son el caso más delicado#
Según el modelo y el tokenizador, una cifra de varios dígitos no se procesa como un único valor indivisible, sino que se divide en unidades que no se corresponden necesariamente con el valor que una persona ve en ella. Los trabajos sobre capacidad de conteo y tokenización describen justamente esa ruptura entre la unidad que se quiere y la unidad que se procesa.
A eso se suma un hallazgo sobre la representación numérica. Los estudios muestran que los modelos de lenguaje codifican los números dígito a dígito, en base 10, y que los errores aparecen por dígitos: la predicción incorrecta queda cerca de la correcta en distancia de edición de caracteres y lejos de ella en valor.
Esos trabajos estudian el cálculo y el conteo, no la copia desde un documento. No demuestran, por tanto, que todo error de extracción surja por esa vía. Aun así bastan para la prudencia de la que trata este artículo: un error en una cifra no tiene por qué parecer un error. De 349.000 salen 340.000. De 132 metros cuadrados salen 138. Parece una errata y se comporta como nueve mil euros.
Un formato numérico válido no equivale a una copia literal. Por eso ya no considero «el modelo lee el documento» una arquitectura sólida, sino una suposición que hay que asegurar.
Un esquema válido no dice nada sobre el contenido#
La respuesta habitual a todo esto se llama salida estructurada. Una buena herramienta que resuelve un problema distinto de aquel para el que se la toma.
La propia documentación de OpenAI es precisa en lo que cubre: la respuesta cumple el esquema entregado, ningún campo obligatorio ausente, ningún valor de enumeración inválido. Y es igual de clara sobre el límite, a saber, que las salidas estructuradas pueden seguir conteniendo errores y que una entrada que no encaja con el esquema puede seguir produciendo alucinaciones.
Un esquema garantiza, por tanto, que existirá un campo llamado precio y que contendrá un número. Sobre si ese número está en el documento no dice nada. Aun así, el cumplimiento de la forma se lee como exactitud, porque el resultado parece una fila de base de datos, y eso es justo lo que lo hace peligroso. Cuanto más ordenada la forma, menos pregunta nadie por el contenido.
La fuente se fija antes que el modelo#
La primera de las cinco capas es una regla sobre las entradas, no sobre las instrucciones: el modelo no recibe una dirección desnuda, sino el texto que se descargó y se guardó previamente.
Una dirección no prueba qué contenido se procesó realmente. Las páginas cambian, una descarga puede fallar, y sin una copia guardada después no se puede decir qué había allí en el momento de la extracción. Si el documento se descarga antes, se guarda y se entrega como texto fijo, hay exactamente una versión en juego.
No es un detalle marginal de seguridad. Todo lo que viene después, cada comprobación y cada referencia, depende de que haya un único documento y de que siga estando disponible más tarde.
Los números primero, y sin modelo#
La segunda capa es la que le da el título a este artículo. Precios, superficies, número de habitaciones, fechas e identificadores se extraen primero del texto fuente sin el modelo, por patrón, como candidatos. El modelo recibe después el texto y esos candidatos, y su tarea es la asignación: qué cifra corresponde a qué campo, qué dice la descripción, cómo se relacionan las partes. El valor en sí no puede volver a generarlo.
Lo fiable que sea ese primer paso depende del documento. Con HTML limpio o un PDF con texto incrustado es muy fiable. Con un escaneo la incertidumbre empieza ya en el reconocimiento de texto, y las tablas, los distintos separadores decimales, las monedas y las cifras partidas por saltos de línea no lo facilitan. Determinista significa aquí trazable, no automáticamente correcto.
Aun así, el reparto sigue las fortalezas. Un modelo de lenguaje ayuda bien a decidir si una cifra designa la superficie de parcela o la habitable, porque esa es una pregunta sobre el lenguaje. Para llevar once dígitos intactos a lo largo de un contexto extenso es la opción más débil, porque esa es una pregunta sobre copiar. La asignación también queda sujeta a revisión; simplemente es la tarea en la que el modelo sí ayuda.
Quien revisa no puede ser quien escribe#
La tercera capa es una comprobación que contrasta el resultado con el texto original, y lo decisivo es que no ocurra dentro del mismo contexto en que se produjo. Nada de «revísalo otra vez» al final de la misma conversación. La segunda pasada recibe el texto original, el resultado y criterios fijos, y en los campos críticos el cotejo se ejecuta además de forma mecánica.
Por qué hace falta esa separación lo muestra Large Language Models Cannot Self-Correct Reasoning Yet, presentado en ICLR 2024. Un grupo de Google DeepMind y la Universidad de Illinois estudió la autocorrección intrínseca, es decir, el caso en que un modelo revisa su propia respuesta sin retroalimentación externa. A los modelos les costó y, en parte de los casos, el resultado empeoró tras el paso de corrección.
El hallazgo vale para ese caso concreto, y ahí está la lección aprovechable. Un modelo que acaba de producir una respuesta la produjo porque la consideraba correcta; pedirle un juicio desde dentro de la misma conversación es pedirle que se contradiga. En cambio, si recibe el texto fuente y una afirmación concreta que cotejar, ya no es el mismo caso.
Lo que falta, entonces, no es necesariamente otro modelo. Es retroalimentación externa. En la extracción viene regalada: el texto fuente está al lado.
Cada campo indica de dónde sale#
La cuarta capa es una exigencia pequeña con un efecto grande. Cada campo extraído lleva consigo el pasaje del que procede.
Con eso, la comprobación deja de ser una cuestión de criterio. O el pasaje citado contiene el valor o no, y ese cotejo es mecánico y barato. Se desprende de la propia arquitectura y no necesita ningún estudio como prueba; los trabajos sobre extracción anclada a citas van en la misma dirección, porque la comprobación se ejecuta entonces contra el documento y no contra otra base de datos derivada.
Hay una cosa que hay que tener presente, o la capa solo funciona a medias. El cotejo literal se sostiene mientras el valor guardado figure así en el documento. En cuanto se normaliza, deja de ser cierto: de «349.000 €» sale 349000, de «01.03.2026» sale 2026-03-01. Por eso cada campo lleva ambas versiones, el valor bruto tal como está y el valor guardado, además de la indicación de qué ocurrió en medio. Si no, se comprueba también la conversión y, ante un fallo, no se sabe cuál de los dos pasos falló.
El beneficio indirecto es mayor que el directo. Un campo que no puede nombrar su fuente no está simplemente peor respaldado, es otra categoría. Es una suposición. En cuanto la prueba es obligatoria, las suposiciones se vuelven visibles en lugar de desaparecer en la misma tabla que todo lo demás, y entonces se puede decidir qué hacer con ellas.
La última capa sale del propio asunto#
La quinta capa ya no tiene nada que ver con modelos de lenguaje. Es aritmética del oficio: precio contra superficie, habitaciones contra superficie, año de construcción contra un rango plausible. Lo que se sale se marca, no se borra.
Recoge el resto, y es la única capa que atrapa además un valor que sí está en el documento y ahí es incorrecto, porque la fuente tenía una errata. Contra una fuente equivocada no sirve ningún anclaje a la cita. La plausibilidad sí sirve.
Dónde pasa la línea#
Nada de esto habla en contra de dejar que los modelos toquen datos. Habla a favor de un reparto del trabajo, y la línea es real.
Al modelo le pertenece el valor cuando el valor es lenguaje: una clasificación, un resumen, un sí o un no a la pregunta de si el texto menciona un jardín. Lo que no le confiaría son valores que una persona repasaría en un extracto bancario. Si alguien pudiera preguntar razonablemente de dónde sale esa cifra, la cifra necesita una vía trazable y una prueba.
El precio honesto de este camino es que lleva más tiempo que una instrucción con esquema y se deja enseñar peor. No hay un momento en el que pegues una dirección y aparezca una tabla limpia. Hay, en cambio, un recorrido con una aburrida comprobación de patrones en medio. La demostración llega dos meses después, cuando alguien pregunta de dónde sale una cifra y la respuesta tarda cuatro segundos.
De todos los atajos posibles, uno sería especialmente peligroso: prescindir de la comprobación independiente. Es la capa que parece más prescindible mientras todo va bien, y la que atrapa justo aquello en lo que nadie pensó.
Un sistema que puede mostrar sus fuentes no es una versión más cuidadosa de otro que no puede. Es un producto distinto, y es el único que yo dejaría acercarse a los datos de un cliente.
