Prompt engineering para extracción de datos

La clave para mejorar la extracción de datos con Claude no está en el modelo, sino en el prompt que escribes. Si le pides "saca los datos" sin reglas claras, obtienes un deseo, no una instrucción. Este contenido es para quienes construyen extractores automáticos de facturas y documentos y quieren resultados confiables.

Cuando le dices a Claude que extraiga información sin especificar qué campos quieres, qué hacer con lo que falta y cómo actuar cuando el documento no es claro, terminas con datos inconsistentes. Una factura no siempre trae el IVA desglosado, ni la fecha en el mismo lugar, ni un solo total. Tu prompt tiene que saber qué hacer con todo eso antes de toparse con ello.

Por qué un mal resultado casi nunca es culpa del modelo

La mayoría de la gente cree que un mal resultado de extracción es culpa del modelo, y casi nunca lo es. Claude hace exactamente lo que le pides. El problema aparece cuando "sacar los datos" es una petición vaga en lugar de un conjunto de reglas concretas.

Lo que cambia todo es darle tres cosas claras:

• Qué campos quieres exactamente.
• Qué poner cuando uno de esos campos no aparece.
• Qué hacer cuando el documento no está claro.

Con estas tres definiciones, dejas de esperar que Claude adivine y empiezas a controlar el resultado.

¿Por qué falla la extracción de datos con IA? Casi siempre falla por un prompt sin reglas, no por el modelo. Si no defines los campos exactos y qué hacer con datos faltantes, el modelo adivina y rompe la consistencia.

Qué reglas debo agregar al prompt para obtener un JSON limpio

Partiendo del archivo de la clase anterior, ya obteníamos un JSON, pero necesitábamos que el prompt fuera más específico [00:42]. Al inicio del prompt se agregan dos líneas de normalización que evitan errores de formato comunes.

Las instrucciones de normalización que se añadieron son:

• Devolver la información como un JSON usando exactamente las claves definidas.
• Normalizar los montos con números sin símbolos de moneda, para no mezclar el símbolo dentro del número.
• Usar un código ISO para la moneda cuando se pueda inferir, por ejemplo USD.

Después, al final del prompt se agregaron tres reglas para manejar lo que falta o no se entiende [01:20]. Estas reglas son las que evitan que el archivo se rompa al validar datos.

¿Qué debo hacer cuando un campo de la factura está vacío? Usa null o un string que diga "sin" seguido del nombre del campo, en lugar de adivinar. Así evitas valores en blanco que rompen la validación.

Cómo manejo la moneda y los impuestos separados

Las reglas para casos ambiguos quedaron así de concretas:

• Si la factura no muestra una moneda explícita, usar null.
• Si hay impuestos separados, incluirlos en items solo cuando aparecen como una línea propia.
• Si no puede leer un campo, usar null o un string con el nombre del campo, nunca inventar.

Con esto, cualquier valor que no exista o no se pueda leer queda controlado y no deja el archivo en blanco.

Cómo evito que Claude confunda un nombre propio con el proveedor

Aquí viene lo interesante. Al probar el código, se eliminó el nombre del proveedor del invoice text y la factura decía solo "factura emitida" con fecha y hora [02:35]. El resultado asumió que Juan Pérez era el proveedor, cuando en realidad Juan Pérez era la persona que atendió.

Al quitar también esa referencia y dejar solo "Cesde Chapinero", el código respetó la regla y marcó "sin provider", porque el campo se llama provider [03:20]. Toda la información adicional se mantuvo intacta.

Para resolver la confusión del nombre, se agregó una regla adicional: no todos los nombres propios en el contenido son un proveedor. El prompt debe verificar si es un proveedor real y, si no está seguro, respetar la regla anterior de usar null o el string con el nombre del campo [03:55]. Incluso con la frase "Atendido por Juan Pérez en la sede Chapinero", el modelo ya no lo confunde con el proveedor.

Qué pasa cuando el documento tiene muy poca información

Se probó un invoice text aún más simple, sin proveedor, sin cantidad y sin precio unitario, solo con "factura emitida", fecha, servicio y total [04:30]. El resultado respetó todas las reglas:

• Marcó el proveedor como faltante.
• Devolvió la fecha, la moneda y el total de 129,9.
• Puso "soporte" en la descripción porque estaba explícito.
• Dejó cantidad y precio unitario como null al no tener información.

El modelo prefiere responder null antes que adivinar, respetando la configuración que le diste.

En qué se diferencia un extractor de datos de un chatbot

Un chatbot lo usas tú mirando la pantalla y leyendo cada respuesta. El extractor de datos trabaja distinto: nadie lo mira. Le entra un PDF, entiende y procesa los datos, y devuelve un JSON con lo necesario [05:10].

Esa información puede ir directo a una base de datos o a una hoja de cálculo sin que un humano la revise en el medio. Por eso las reglas del prompt son tan importantes: son la única garantía de calidad en un proceso automático.

El reto que se propone es claro: ya tienes el JSON al final de cada consulta, ahora haz que esos valores se agreguen directamente a una hoja de cálculo de Google Drive. Si te suena complejo, apóyate en Claude para crear el software. ¿Qué otro uso le darías a este extractor? Cuéntame en los comentarios cómo te fue con el reto.