Alucinaciones de LLM: cómo detectarlas, limitarlas y gestionar el riesgo en producción

Qué son las alucinaciones y por qué aparecen

Una alucinación en un LLM es la generación de información que suena creíble, pero es factualmente falsa o injustificada. No es un „error” en el sentido de un fallo del sistema, es una consecuencia del modo de funcionamiento de los modelos de lenguaje. El LLM no „sabe” del modo en que lo hace una base de datos: predice el siguiente token más probable, basándose en la estadística del entrenamiento. Cuando en el prompt aparece una pregunta para la que el modelo no tiene buena cobertura en los datos de entrenamiento, genera la respuesta „que suena más probable”. A menudo esta respuesta es correcta. A veces no.

Escenarios típicos de alucinaciones en aplicaciones empresariales:

Citación de sentencias judiciales inexistentes o artículos de leyes inventados en asesoría jurídica
Inventar nombres de funciones, clases o librerías al generar código
Proporcionar estadísticas o fechas incorrectas en informes
Inventar contactos, direcciones, números de teléfono
Mezclar hechos sobre diferentes empresas o personas con nombres similares

Capa 1: Grounding (RAG)

La técnica individual más eficaz para reducir las alucinaciones es el grounding: proporcionar al modelo documentos o datos concretos como contexto, del cual debe extraer respuestas. RAG clásico (Retrieval-Augmented Generation):

Pregunta del usuario → búsqueda de los fragmentos de documentos más relevantes (vector search en pgvector / Qdrant / Milvus)
Fragmentos + pregunta → prompt con la instrucción „responde exclusivamente basándote en los siguientes documentos”
Respuesta del modelo → verificación de que contiene citas/referencias a las fuentes

RAG reduce las alucinaciones típicamente en un 60-80% en aplicaciones del tipo „responde preguntas sobre nuestra base de conocimiento”. No las elimina por completo: el modelo todavía puede „interpretar” los documentos de manera no autorizada. De ahí la necesidad de capas adicionales.

Capa 2: Self-consistency y ensemble

La self-consistency es una técnica que consiste en plantear la misma pregunta varias veces (o a varios modelos diferentes) y comparar las respuestas. Cuando las respuestas son coherentes: alta confianza. Cuando difieren: señal de que el tema es incierto.

Variante práctica: pregunta a Claude Sonnet, Llama 70B y Bielik la misma pregunta. Si las tres devuelven el mismo número, fecha, hecho: probablemente correcto. Si difieren: escalado a humano o a un modelo más caro (Opus). Este patrón, implementado en el routing de LLM de 8 niveles, combina la reducción de costes con la mejora de la fiabilidad.

Capa 3: Evaluation pipelines

El despliegue de LLM en producción sin evaluation pipeline es como escribir código sin pruebas. Métricas concretas:

Faithfulness: si la respuesta se deriva de los documentos proporcionados. Medido por un segundo modelo de IA (LLM-as-judge) o una librería del tipo RAGAS, deepeval.
Answer relevance: si la respuesta aborda la pregunta del usuario.
Context precision: si los mejores fragmentos fueron devueltos por el retrieval (calidad del vector search).
Groundedness score: porcentaje de afirmaciones en la respuesta para las que se puede indicar una fuente en el contexto.

Cada nuevo build de una aplicación basada en LLM debería pasar un conjunto de 50-500 preguntas de evaluación con ground truth conocido. Si el faithfulness cae por debajo del 90%: deployment blocked.

Capa 4: Guardrails y validación de output

Los guardrails son reglas que validan el output del LLM antes de entregarlo al usuario. Ejemplos:

Schema validation: el output debe cumplir un esquema concreto (JSON Schema, Pydantic). Las alucinaciones del tipo „campos inventados” se detectan mecánicamente.
Forbidden patterns: detección y bloqueo de patrones inadmisibles (PII sin enmascaramiento, datos financieros fuera de contexto, contenido potencialmente dañino).
Citation enforcement: cada afirmación factual debe tener una cita de la fuente. Si el modelo no cita: la respuesta se rechaza.
Numeric range validation: los números en el output se verifican en términos de sensatez (p. ej., precio > 0, fecha ≤ hoy, porcentaje en el rango 0-100).
Cross-reference check: comparación del output con una base de datos de hechos (p. ej., KRS, diccionario de citas de leyes).

Librerías: Guardrails AI, NeMo Guardrails, instructor (para schema enforcement). Una implementación propia a menudo es más simple y barata de mantener.

Capa 5: Human-in-the-loop

Para aplicaciones de alto riesgo (decisiones legales, médicas, financieras, de RR. HH.), la capa human-in-the-loop es indispensable. Los modelos de IA no toman la decisión final, apoyan al humano. Patrones concretos:

Draft + review: la IA genera la primera versión del documento/respuesta, el humano verifica y aprueba antes del envío.
Confidence threshold: las respuestas con bajo confidence (de self-consistency o explicit confidence asking) se escalan automáticamente al humano.
Random sampling QA: el 5-10% de todas las respuestas del LLM son auditadas manualmente, independientemente del confidence: métrica de calidad básica en el tiempo.
Feedback loop: el usuario puede marcar una respuesta errónea; el sistema aprende y mejora el retrieval, prompts, parámetros.

Medición: cómo saber que la reducción funciona

Métricas de producción concretas que vale la pena monitorear:

Hallucination rate: porcentaje de respuestas clasificadas como alucinación en evaluación manual (sampling). Objetivo: por debajo del 2% para aplicaciones business-critical.
User feedback rate: porcentaje de usuarios que marcaron una respuesta como errónea.
Escalation rate: porcentaje de consultas escaladas al humano. Demasiado bajo (por debajo del 5%): el sistema probablemente omite casos inciertos. Demasiado alto (por encima del 30%): el sistema no aporta valor de automatización.
Faithfulness score en tests de regresión: tendencia mensual.
Time-to-correction: desde la detección de una alucinación hasta la implementación de una corrección (mejor retrieval, nuevo guardrail, fine-tuning).

Conclusiones para los responsables de decisiones

Las alucinaciones son gestionables: requieren inversión en arquitectura defensiva en múltiples capas. Las empresas que implementan LLM sin esta arquitectura tarde o temprano se enfrentarán a un incidente grave (publicación de información incorrecta al cliente, decisión errónea basada en datos alucinados, daño reputacional). El coste de construir un stack defensivo completo (RAG + evaluation + guardrails + human-in-the-loop) es típicamente del 15-30% del coste del propio despliegue del LLM, y es una inversión absolutamente necesaria para aplicaciones de producción. Las consecuencias de la omisión son asimétricas: bajo coste de inacción en el 95% de los casos, catastrófico en el 5%.