Cuando los LLM producen datos estructurados, pueden fabricar hechos que parecen verosímiles. Entity Enricher utiliza 8 capas de defensa para garantizar que obtenga datos precisos o ningún dato, nunca ficción que suena convincente.
En un texto libre, una frase alucinada es evidentemente vaga. En una salida estructurada, un campo alucinado como "founded_year": 1987 parece fiable y resulta casi imposible de distinguir de un valor correcto. Tres factores lo hacen especialmente peligroso:
Un valor JSON alucinado se ve exactamente igual que uno real. No hay matices, no hay “aproximadamente”: solo un dato limpio y seguro que resulta ser incorrecto.
Los campos obligatorios fuerzan al LLM a producir un valor incluso cuando no dispone de información. El modelo inventa datos en lugar de dejar un hueco en la estructura.
Los datos estructurados se integran directamente en bases de datos, analíticas y automatizaciones. Un valor incorrecto se propaga por los pipelines sin revisión humana.
| Patrón | Ejemplo | Causa |
|---|---|---|
| Fabricación con confianza | "ceo": "John Smith" | El LLM rellena un campo obligatorio con un nombre plausible |
| Confusión temporal | "revenue": "$2.3B" | Fecha de corte de los datos de entrenamiento o confusión de periodos |
| Conflación de entidades | Atributos de la Empresa A en la Empresa B | Nombres similares en datos de entrenamiento superpuestos |
| Valores predeterminados plausibles | "employees": 500 | El LLM elige un número «razonable» en lugar de admitir que no lo sabe |
| Relaciones inventadas | "subsidiary_of": "Alphabet" | El LLM infiere una relación que no existe |
Varios de estos patrones se originan en el esquema, no en el modelo: una propiedad como revenue deja abiertos la moneda, el periodo y el alcance (grupo o entidad), y un nombre para algo que la entidad simplemente no tiene no le deja al modelo nada que consultar. La verificación de ambigüedad detecta ambos casos, enumera las lecturas que admite la propiedad y sugiere el cambio de nombre o la descripción que fija exactamente una de ellas.
Entity Enricher no depende de una sola técnica. Apila 8 capas de defensa independientes, cada una orientada a un modo de fallo distinto. Si una capa pasa por alto una alucinación, la siguiente la detecta.
Antes de que comience el enriquecimiento, un LLM rápido clasifica si la entidad coincide con el tipo de esquema. Esto bloquea la alucinación de entidades completas en el origen.
Ejemplo: «Titán» frente a un esquema «Planeta» se marca como una luna: los modelos de enriquecimiento reciben este contexto y usan null para los campos específicos de planetas.
Todas las estrategias instruyen al LLM: «Sea preciso y conservador: nunca invente un valor». El modelo declara los campos que no pudo determinar en lugar de rellenarlos con marcadores de posición, y esas declaraciones se convierten en valores null honestos en la salida.
Esto aborda directamente la presión del esquema, la causa n.º 1 de la alucinación estructurada. Un valor desconocido declarado también desambigua las respuestas reales: un 0 que el modelo respalda es un dato; un 0 declarado no lo es.
Las propiedades del esquema se agrupan por dominio de especialización. Cada llamada LLM solo ve los campos dentro de su dominio, con instrucciones para centrarse exclusivamente en esa área.
Un alcance más acotado significa menos oportunidad de alucinar. Un experto financiero nunca adivina sobre datos regulatorios.
Las propiedades clave (marcadas con is_key: true) se resaltan en los prompts para anclar el LLM en la información identificativa antes de rellenar otros campos.
Esto ancla el modelo a hechos conocidos, reduciendo la desviación hacia detalles inventados.
La salida del enriquecimiento se valida frente a los tipos, formatos y la estructura del esquema. Un fallo activa ModelRetry: el error concreto se devuelve al LLM para su corrección, y la reparación es quirúrgica: solo se vuelven a pedir las hojas que llegaron mal, no la respuesta completa.
Hasta 5 intentos de corrección automática dentro de una misma ejecución del agente. (La generación de esquemas se corrige de otra forma: paso a paso, con alternativas deterministas.)
Los campos marcados como preserve: true (ID, SKU, identificadores de importación) se restauran a sus valores de entrada originales tras el enrichment: el LLM no puede sobrescribir los datos de referencia. Las solicitudes de enrichment deben proporcionar un valor para cada campo preservado, de modo que nada quede fijado a null ni se invente.
Dentro de los arrays, los elementos enriquecidos se emparejan con sus elementos de entrada mediante sus campos clave; los elementos que la IA descubre reciben null en lugar de un identificador inventado.
Ejecutar la misma entidad a través de 2 o más modelos independientes y comparar las salidas campo por campo. Las discrepancias se marcan como posibles alucinaciones.
Si Claude dice que los ingresos son de $2.3B y GPT-4 dice $1.8B, ese conflicto se detecta y se muestra.
Los conflictos detectados se resuelven mediante votación basada en reglas (mayoría, mediana, unión) o mediante un árbitro LLM dedicado que evalúa la precisión, la exhaustividad y la coherencia.
Cada decisión de arbitraje incluye el razonamiento y el nivel de confianza: transparencia total sobre cómo se resolvieron los conflictos.
Principio fundamental
Es preferible que falten datos a que sean incorrectos. Cada capa refuerza este principio: el sistema está diseñado para devolver null en lugar de una invención que suene plausible.