Prevención de alucinaciones - Documentación de Entity Enricher

Prevención de alucinaciones

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.

El problema de la alucinación estructurada

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:

Precisión falsa

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.

Presión del esquema

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.

Propagación silenciosa

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.

Patrones comunes de alucinación

PatrónEjemploCausa
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 entidadesAtributos de la Empresa A en la Empresa BNombres similares en datos de entrenamiento superpuestos
Valores predeterminados plausibles"employees": 500El 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

8 capas de defensa

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.

1
Clasificación previa

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.

2
Campos nullable y prompting conservador

Todas las estrategias instruyen al LLM: «Sea preciso y conservador: prefiera nulo antes que adivinar». Los campos de esquema que admiten nulo dan al modelo permiso explícito para decir «No lo sé».

Esto aborda directamente la presión del esquema, la causa n.º 1 de la alucinación estructurada.

3
Delimitación de dominios de especialización

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.

4
Enfoque de clave de búsqueda

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.

5
Validación de esquemas y autocorrección

8 reglas de validación comprueban la salida del LLM en busca de discrepancias de tipos, referencias no válidas y errores estructurales. Una validación fallida activa ModelRetry: los errores se devuelven al LLM para su corrección.

Hasta 6 intentos de corrección automática en una sola ejecución del agente. El LLM corrige sus propios errores.

6
Conservar la lógica

Los campos marcados con preserve: true (ID, SKU, marcas de tiempo) se restauran a sus valores de entrada originales tras el enriquecimiento. El LLM no puede sobrescribir los datos de referencia.

Campos protegidos: ID de entidades, códigos de sistema (EAN, SKU), identificadores de importación, marcas de tiempo de creación.

7
Consenso multimodelo

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.

8
Resolución de conflictos y arbitraje

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.

Pipeline de defensa

1Clasificación previaBloquear tipos de entidad incorrectos
2Nullable + prompts conservadoresReducir la presión del schema
3Delimitación de dominios de especializaciónAcote lo que el LLM debe responder
4Enfoque de clave de búsquedaApóyese en los identificadores
5Validación y autocorrecciónCorrija los errores estructurales
6Conservar la lógicaProteger la verdad de referencia
7Consenso multimodeloDetectar discrepancias
8Arbitraje de conflictosResolver con razonamiento
Preenriquecimiento
Durante el enriquecimiento
Posenriquecimiento

Filosofía de diseño

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.

Qué hace Entity Enricher
  • Da a los LLM permiso explícito para devolver null
  • Realiza validación cruzada con varios models independientes
  • Evita que se sobrescriban datos válidos conocidos
  • Muestra total transparencia en la resolución de conflictos
Qué hacen las herramientas típicas
  • Obligar a los LLM a rellenar todos los campos, sin importar qué
  • Depender de un único modelo sin validación cruzada
  • Permitir que el LLM sobrescriba libremente los datos de entrada
  • Devolver los resultados como una caja negra sin registro de auditoría