SincroDev Logo SincroDev

Extracción estructurada con LLMs: de texto libre a JSON válido


Una de las aplicaciones más útiles de los LLM no es conversar.

Es transformar texto caótico en datos utilizables.

Ejemplos:

  • correos de clientes
  • formularios abiertos
  • mensajes de WhatsApp
  • tickets
  • notas internas

Si logras extraer estructura confiable desde ese texto, puedes conectar la IA con sistemas reales.

Qué vas a construir

Vamos a diseñar un patrón para pasar de esto:

Hola, soy Juan Pérez. Me cobraron dos veces la suscripción anual y necesito una solución urgente.

a esto:

{
  "nombre_cliente": "Juan Pérez",
  "intencion": "facturacion",
  "problema": "doble_cobro",
  "urgencia": "alta"
}

La clave no es que el texto “suene bien”.

La clave es que salga en un formato que otro sistema pueda usar.

Cuándo conviene este enfoque

Tiene sentido cuando:

  • el input llega en lenguaje natural
  • necesitas clasificar o rutear automáticamente
  • quieres alimentar un CRM, base de datos o workflow

No conviene cuando:

  • los datos ya vienen perfectamente estructurados
  • la extracción puede resolverse con una regla determinista simple

La IA no debería reemplazar regex o parsing clásico cuando no hace falta.

Paso 1: Decide qué campos necesitas de verdad

No empieces por el modelo. Empieza por la estructura destino.

Ejemplo:

{
  "nombre_cliente": "",
  "email": "",
  "intencion": "",
  "prioridad": "",
  "accion_sugerida": ""
}

Si no sabes para qué se usará cada campo, probablemente todavía no estás listo para automatizar esa extracción.

Paso 2: Usa un esquema claro

Mientras más explícita sea la salida esperada, mejor.

Ejemplo de prompt:

Analiza el siguiente mensaje y responde en JSON estricto.

Campos requeridos:
- nombre_cliente: string
- email: string | null
- intencion: compra | queja | duda | facturacion
- prioridad: baja | media | alta
- accion_sugerida: responder | escalar | pedir_mas_datos

Si un dato no está presente, usa null.

Mensaje:
"""
{texto}
"""

Esto reduce ambigüedad y facilita la validación posterior.

Paso 3: Usa ejemplos si la tarea tiene matices

Si la clasificación o extracción es ambigua, añade ejemplos.

Ejemplo:

Mensaje: "No puedo entrar a mi cuenta desde ayer"
Salida:
{
  "nombre_cliente": null,
  "email": null,
  "intencion": "duda",
  "prioridad": "media",
  "accion_sugerida": "responder"
}

Los ejemplos alinean mucho mejor que una instrucción vaga.

Paso 4: Exige JSON estricto

Si el output va a una automatización, no quieres párrafos.

Quieres algo que puedas parsear.

Ejemplo mínimo de flujo:

Texto libre

LLM

JSON

Validador

Sistema / automatización

Ese paso de validación no es opcional.

Paso 5: Valida el resultado

El LLM puede devolver:

  • JSON válido
  • JSON roto
  • campos faltantes
  • valores inesperados

Debes validar antes de usar.

Pseudocódigo:

schema = {
  "intencion": {"compra", "queja", "duda", "facturacion"},
  "prioridad": {"baja", "media", "alta"},
}

result = llm_extract(text)

if result["intencion"] not in schema["intencion"]:
    result["intencion"] = "duda"

Si el output no pasa validación, debe:

  • ir a revisión manual
  • o caer en un fallback seguro

Paso 6: Diseña fallbacks razonables

Nunca assumes que el modelo acertará siempre.

Patrón útil:

{
  "nombre_cliente": null,
  "email": null,
  "intencion": "duda",
  "prioridad": "media",
  "accion_sugerida": "pedir_mas_datos"
}

Eso es mucho mejor que inventar datos y romper el flujo downstream.

Paso 7: Integra el JSON a un sistema real

Una vez validado, ya puedes usar la salida en:

  • n8n
  • una API
  • una base de datos
  • Slack
  • un CRM

Ejemplo:

Correo entrante

LLM extrae JSON

Validación

Guardar en CRM

Notificar según prioridad

Ese es el punto donde la IA deja de ser demo y pasa a ser infraestructura útil.

Ejemplo de salida útil

{
  "nombre_cliente": "María López",
  "email": "maria@empresa.com",
  "intencion": "queja",
  "prioridad": "alta",
  "accion_sugerida": "escalar"
}

Con eso ya puedes:

  • asignar un owner
  • crear ticket
  • disparar alerta
  • actualizar una base

Errores comunes

1) Pedir demasiados campos

Si el texto no trae suficiente información, el modelo empezará a inventar.

2) No validar el output

Esto es uno de los errores más repetidos y más caros.

3) Mezclar extracción con razonamiento abierto

Si quieres estructura, reduce libertad. No pidas ensayo y JSON al mismo tiempo.

4) No definir qué hacer cuando falta información

El sistema debe saber cómo comportarse ante datos incompletos.

5) Querer usar IA donde una regla fija bastaba

No hace falta LLM para extraer un email si ya viene en un campo exacto.

Qué medir

No alcanza con mirar ejemplos bonitos.

Mide:

  • tasa de JSON válido
  • precisión por campo
  • frecuencia de fallback
  • impacto en el flujo real

Porque el éxito no es “qué lindo quedó el output”.

El éxito es si ese output realmente sirve para operar.

Cuándo este patrón ya da valor

Da valor cuando:

  • reduces trabajo manual de lectura
  • haces que texto libre entre a sistemas estructurados
  • evitas copiar y pegar datos repetitivos

Ese salto es enorme para muchos equipos.

Resumen

Para extraer estructura útil con LLMs necesitas:

  1. un esquema claro
  2. JSON estricto
  3. ejemplos cuando haga falta
  4. validación posterior
  5. fallback seguro
  6. integración con un flujo real

La magia no está en el modelo.

Está en lograr que texto ambiguo termine convertido en datos confiables para el resto del sistema.

Si quieres llevar este patrón a formularios, tickets, soporte o automatizaciones con IA, puedes escribirme desde Sobre Mí.