Extracción de datos con LLM: convertir texto desordenado en tablas

Una gran cantidad de información útil vive en texto que ninguna hoja de cálculo puede leer: correos, facturas, currículos, tickets de soporte, contratos, notas. El sueño es verterlo todo en filas y columnas limpias, y esta es una de las tareas donde los modelos de lenguaje cumplen de verdad. A diferencia de la generación libre, la extracción tiene una respuesta correcta —el valor está en el texto o no lo está—, lo que la vuelve a la vez más útil y más verificable que la mayoría de los casos de uso de IA. Este es un recorrido conceptual de cómo hacerlo bien, y dónde sale mal.

Parte del esquema, no del texto

El error más común es pedirle al modelo que "extraiga la información importante". Esa instrucción no tiene respuesta correcta, así que obtienes campos inconsistentes que cambian de forma de un documento al siguiente y que nunca pueden cargarse en una tabla. Empieza en cambio definiendo con precisión el esquema objetivo: los campos exactos que quieres, el tipo de cada uno (texto, número, fecha, categoría, booleano) y qué significa cada uno. "Total de factura como número, moneda como código de tres letras, fecha de vencimiento como AAAA-MM-DD" es un objetivo que el modelo puede acertar de forma consistente. "Lo del dinero" no lo es. El esquema es la especificación; todo aguas abajo depende de hacerlo explícito primero.

Haz de la ausencia un valor de primera clase

Los documentos reales están incompletos. Un campo que esperas a menudo faltará, y esto es lo más importante de manejar, porque un modelo bajo presión de llenar un campo inventará un valor plausible en vez de dejarlo en blanco. Un número de factura inventado luce exactamente como uno real y es mucho más peligroso que una celda vacía, porque nada lo marca como erróneo. Así que define explícitamente cómo luce "no presente" —un nulo, una cadena vacía, un marcador específico— e instruye al modelo a usarlo siempre que el valor genuinamente no esté en el texto. "Devuelve null si el campo no está presente; no adivines" es una de las frases más valiosas en cualquier prompt de extracción.

Pide salida estructurada y restríngela

Pide los datos en un formato estructurado —típicamente JSON que coincida con tu esquema— en vez de prosa que luego tengas que parsear. La mayoría de los modelos y herramientas de servicio actuales soportan salida restringida o estructurada que se ajusta a un esquema que proporcionas, y la mecánica está bien documentada en recursos como la documentación de Hugging Face. Proporciona los nombres de campo exactamente como los quieres, especifica el tipo y los valores permitidos para cada uno, y para los campos categóricos da la lista cerrada de opciones para que el modelo elija de tu taxonomía en vez de inventar etiquetas. Cuanto más ajustada la restricción, más consistente la salida, y la consistencia es todo el punto: estás construyendo filas que tienen que alinearse.

Muestra, no solo digas

La calidad de extracción da un salto cuando incluyes un par de ejemplos trabajados en las instrucciones: un fragmento de entrada representativa y la salida estructurada exacta que quieres de él. Los ejemplos comunican los casos límite que a la prosa le cuesta: cómo formatear una fecha parcial, cómo manejar dos valores cuando esperas uno, qué hacer con un campo que está presente pero es ambiguo. Elige ejemplos que cubran los casos incómodos, no solo los limpios, porque los casos limpios nunca fueron el problema. Un puñado de ejemplos bien elegidos suele valer más que varios párrafos de reglas, y te cuesta casi nada añadirlos.

Valida cada campo tras la extracción

Nunca confíes en los datos extraídos por fe: valídalos en el momento en que vuelven, con código ordinario en vez de otro modelo. Comprueba que los tipos coinciden: un campo de fecha parsea como fecha, un campo numérico es numérico, una categoría es uno de los valores permitidos. Comprueba rangos y formatos: una cantidad no es negativa, un correo contiene una "@", un código coincide con su patrón esperado. Cruza la consistencia interna donde puedas: ¿suman los renglones el total declarado? La validación es donde atrapas tanto los errores del modelo como las entradas genuinamente malformadas, y convierte datos malos silenciosos en una excepción visible y enrutable. Cualquier cosa que falle la validación debería marcarse para una persona, no cargarse en la tabla.

Planifica la ruta para lo que falla

Incluso un pipeline fuerte no extraerá todo correctamente, y fingir lo contrario es como los datos malos envenenan una base de datos. Decide de antemano qué pasa cuando la extracción o la validación fallan: enruta los registros de baja confianza o inválidos a una cola de revisión humana en vez de descartarlos o aceptarlos ciegamente. Este respaldo con humano en el bucle es lo que marca la diferencia entre un sistema en el que puedes confiar y uno que corrompe tus datos en silencio con el tiempo. Es también exactamente el tipo de control consciente de las consecuencias que marcos como el NIST AI Risk Management Framework fomentan: cuando un error tiene costo aguas abajo, una persona permanece en el bucle. La cola de revisión no es señal de fracaso; es la válvula de seguridad que te permite automatizar con confianza el noventa por ciento fácil.

Mide contra una muestra etiquetada

Antes de confiar en un pipeline a escala, mídelo. Etiqueta a mano una muestra representativa de documentos con la extracción correcta, luego ejecuta el pipeline y compara campo por campo. La precisión por campo te dice qué campos son fiables y cuáles necesitan trabajo, y la respuesta casi siempre es despareja, con los campos limpios casi perfectos y los desordenados batallando. Esto te permite tomar una decisión informada: automatiza los campos fiables, enruta los no fiables a revisión. Vuelve a ejecutar la medición cada vez que cambies el esquema, el prompt, los ejemplos o el modelo, porque cada uno de esos puede degradar silenciosamente campos que solían funcionar. La extracción es una de las pocas tareas de IA donde la verdad de referencia es concreta, así que no hay excusa para no medir.

Cuida las entradas antes de culpar al modelo

Una porción sorprendente de los problemas de extracción no tiene nada que ver con el modelo y todo con cómo llegó el texto. Los documentos te llegan como texto digital limpio, como imágenes escaneadas, como exportaciones que destrozan el diseño, o como formatos donde la estructura visual carga un significado que el texto crudo pierde. Cuando una tabla se aplana en una línea corrida, o un escaneo se convierte a texto con errores de caracteres, el modelo está extrayendo de basura y producirá basura por bueno que sea tu esquema. Antes de ajustar prompts, mira lo que al modelo realmente se le da: la entrada tal como la ve el pipeline, no como te luce a ti en pantalla. A menudo el arreglo de mayor apalancamiento está aguas arriba: mejor conversión, estructura preservada, o manejar las imágenes como imágenes en vez de forzarlas por un canal de texto que destruye el mismísimo diseño que contenía la respuesta.

También conviene pensar en el costo y la escala temprano, porque la extracción es con frecuencia un trabajo de alto volumen. Pasar cada documento por el modelo más capaz y caro rara vez es necesario; muchos campos son fáciles y un modelo más pequeño y barato los maneja de forma fiable, con los campos más difíciles o los documentos más difíciles escalados a uno más fuerte. Procesa por lotes lo que puedas, y mide el costo por documento igual que mides la precisión. Un pipeline preciso pero antieconómico a tu volumen real no es realmente desplegable, y el momento de descubrirlo es durante el diseño, no después de haberlo apuntado a un millón de registros.

En resumen

Convertir texto desordenado en tablas es una de las cosas más fiables, verificables y silenciosamente valiosas que puedes hacer con un modelo de lenguaje, si lo tratas como ingeniería, no como magia. Define el esquema primero, haz la ausencia explícita para que el modelo nunca invente un valor, pide salida estructurada restringida, enseña con ejemplos, valida cada campo en código, enruta los fallos a una persona, y mide contra datos etiquetados. Sáltate la validación y la cola de revisión y obtienes una máquina rápida para generar filas plausibles y equivocadas. Constrúyelas, y obtienes datos limpios a partir de texto que ninguna hoja de cálculo podría leer jamás.