Alucinaciones en LLM: 5 técnicas para reducirlas en producción

Un modelo responde con total seguridad a una pregunta que no sabe contestar correctamente. Inventa una cita, completa un número que falta, confirma la suposición implícita en la pregunta — y toda la respuesta suena convincente. A esto lo llamamos alucinación (del inglés *hallucination*): la generación de un output verosímil pero factualmente incorrecto. En un entorno experimental resulta irritante. En producción — al trabajar con documentación, contratos, normas técnicas o requisitos de clientes — causa daño real.

La práctica demuestra que la tasa base de alucinaciones de los modelos frontier se sitúa en el orden de unidades a decenas de puntos porcentuales en preguntas especializadas donde el modelo carece de grounding suficiente. El objetivo de este artículo no es prometer un sistema libre de alucinaciones — ese no existe. El objetivo es mostrar cinco técnicas capaces de reducir significativamente este problema en producción, y explicar por qué cada una funciona de forma distinta y por qué ninguna es suficiente por sí sola.

Por qué las alucinaciones no desaparecen del todo

Antes de pasar a las técnicas, hay que entender la causa raíz. Los LLM no buscan hechos — generan tokens basándose en lo que es estadísticamente probable en un contexto dado. El modelo no distingue entre "sé" y "no sé": si no está explícitamente entrenado o instruido para expresar incertidumbre, por defecto genera una respuesta fluida y verosímil.

El tamaño del modelo por sí solo no resuelve el problema — un modelo más grande puede alucinar con más convicción, porque sus capacidades lingüísticas son superiores y sus outputs suenan más persuasivos. Sin una estrategia de grounding, el escalado del modelo no reduce el riesgo; en algunos casos incluso lo aumenta.

Consecuencia para los despliegues en producción: las alucinaciones hay que gestionarlas arquitectónicamente, no simplemente elegir un modelo mejor.

Técnica 1: Grounding mediante RAG con fuentes citables

RAG (*Retrieval-Augmented Generation*) es hoy el mecanismo más extendido para reducir alucinaciones en preguntas factuales. El principio es sencillo: en lugar de que el modelo responda desde su memoria paramétrica (lo que aprendió durante el entrenamiento), recibe en su contexto pasajes relevantes de documentos verificados. La respuesta debe entonces basarse en ese contexto.

Pegar documentos en el prompt sin más no es suficiente. Un sistema de grounding de calidad tiene tres capas:

• Retrieval — búsqueda vectorial (por ejemplo con Qdrant o pgvector) complementada con búsqueda híbrida (BM25 + vectores), para recuperar no solo pasajes semánticamente similares sino también los relevantes por palabras clave
• Reranking — un modelo cross-encoder reordena los resultados; sin reranking, el retrieval devuelve chunks relevantes mezclados con otros de menor calidad; el reranker mejora sustancialmente la precisión de la selección
• Citabilidad — el modelo recibe la instrucción de que cada afirmación debe estar respaldada por una fuente concreta con referencia al documento y la página; si la fuente no existe, no la inventa

La citabilidad es clave no solo para la precisión, sino también para la verificabilidad: el usuario ve de dónde proviene la información y puede comprobarlo. En la práctica, esto aumenta notablemente la confianza y pone de manifiesto los casos en que el modelo ignoró o inventó una cita. Puedes leer más sobre la evaluación del pipeline RAG en el artículo Cómo evaluar RAG (RAGAS), donde describimos las métricas de faithfulness y answer relevance.

Advertencia importante: RAG no lo resuelve todo. Si el retrieval devuelve chunks incorrectos (mismatch de embeddings, chunking deficiente, base de datos desactualizada), el modelo puede alucinar incluso con contexto — o, lo que es peor, alucinar con una cita falsa. RAG es condición necesaria, no suficiente.

Técnica 2: Output estructurado y validación programática

El texto libre es difícil de verificar. Si el modelo devuelve una respuesta en una estructura definida con precisión — esquema JSON, modelo Pydantic, enumeración de valores permitidos — podemos validar el output de forma automática antes de que llegue al usuario o al siguiente sistema.

Los modelos y frameworks modernos soportan structured outputs (*outputs estructurados*): el modelo está forzado a generar tokens que se ajusten al esquema proporcionado. Una alucinación no puede inventar un campo que el esquema no contiene. Si el campo permitido es risk_level con los valores ["low", "medium", "high"], el modelo no puede devolver "critical" ni ningún sinsentido.

En la práctica combinamos tres pasos:

1. 1.Definir el esquema de salida (por ejemplo, un JSON schema o un modelo Pydantic)
2. 2.Usar structured outputs / JSON mode en la llamada a la API
3. 3.Validación programática del output — si el output no se ajusta al esquema, la llamada se repite o se escala a revisión humana

Este enfoque funciona mejor en tareas acotadas: extracción de entidades, clasificación, cumplimentación de formularios, conversión de un documento a una estructura. Para texto libre (resúmenes, interpretaciones) la aplicabilidad es limitada, pero incluso aquí podemos validar al menos la presencia de campos obligatorios (por ejemplo, una sección "Fuentes" o "Advertencias").

Técnica 3: Permitir el "no sé" — calibración de la incertidumbre

Uno de los pasos más simples y eficaces es permitir explícitamente al modelo responder "no sé" o "no puedo determinarlo a partir de la información disponible". Esto suena trivial, pero la mayoría de los prompts de producción lo omiten — y el modelo, por defecto, genera una respuesta aunque no disponga de la información.

Concretamente, en el system prompt (*prompt de sistema*) recomendamos formulaciones del estilo:

• Si la respuesta no se desprende de los documentos proporcionados, indica explícitamente que la información no está disponible.
• No deduzcas ni inferas hechos que no estén presentes en el contexto.
• Si tienes dudas, expresa el grado de incertidumbre con palabras ("probablemente", "según la información disponible").

Es importante entender que la calibración de la incertidumbre debe ser una instrucción activa, no simplemente la ausencia de una prohibición de alucinar. "No alucinaciones" no es suficiente — el modelo entiende la instrucción, pero no tiene mecanismo para cumplirla sin un marco explícito para expresar incertidumbre.

En ámbitos regulados (documentos legales, documentación técnica, normas de seguridad) recomendamos además definir una regla de escalado: si el modelo no puede responder con suficiente certeza, la respuesta debe incluir una indicación para verificar con la persona competente. Esto reduce directamente el riesgo de error silencioso — la situación en que el sistema responde con seguridad y el error pasa desapercibido.

Técnica 4: LLM-as-Judge — verificación automática de outputs

LLM-as-Judge (*LLM como juez*) es una técnica en la que un segundo modelo de lenguaje evalúa el output del primero. En producción se utiliza para la detección automática de alucinaciones, la verificación de consistencia con el contexto y la evaluación de la calidad de la respuesta — sin necesidad de un revisor humano en cada respuesta.

El flujo típico es el siguiente:

1. 1.El modelo primario genera una respuesta
2. 2.El modelo verificador recibe una tripleta: pregunta + contexto fuente + respuesta generada
3. 3.El modelo verificador evalúa: ¿contiene la respuesta afirmaciones no respaldadas por el contexto? ¿Es la respuesta factualmente consistente con las fuentes?
4. 4.En función de la puntuación, la respuesta se entrega, se bloquea o se envía a revisión humana

Para el modelo verificador recomendamos usar un modelo igual o más potente que el primario — un verificador más débil no puede detectar de forma fiable los errores de uno más fuerte. En la práctica observamos buenos resultados combinando un modelo primario ejecutado en local con un verificador frontier (por ejemplo, de la clase Claude Sonnet o GPT-4o) para las respuestas críticas.

Frameworks como Langfuse o Arize Phoenix permiten incorporar este flujo al pipeline de producción con logging, alertas y análisis retrospectivo. Puedes leer más sobre el enfoque global para medir la calidad en el artículo Cómo medir la calidad de una aplicación LLM (evals).

Limitación: LLM-as-Judge no es infalible — el modelo verificador también puede "estar de acuerdo" con una respuesta alucinada si ambas son consistentes entre sí pero factualmente incorrectas. Por eso lo combinamos con el grounding (técnica 1) y con auditorías humanas periódicas de una muestra de outputs.

Técnica 5: Temperatura, sampling y prompt engineering

La última técnica es la más barata de implementar, pero tiene el menor efecto sin las demás capas. Aun así, es importante.

La temperatura (*temperature*) influye en la aleatoriedad de la generación. Una temperatura baja (por ejemplo, 0.0–0.2) produce outputs más deterministas y consistentes — el modelo elige el token más probable, no uno aleatorio. Para tareas factuales (extracción, clasificación, respuestas a preguntas a partir de documentos) recomendamos temperatura baja. Para tareas creativas o generativas una temperatura más alta es deseable, aunque también aumenta el riesgo de desviaciones.

El prompt engineering para reducir alucinaciones tiene varios principios contrastados:

• Ejemplos few-shot — muestra al modelo ejemplos de comportamiento correcto, incluyendo ejemplos donde la respuesta es "no sé"; el modelo aprende ese comportamiento en contexto
• Especificación explícita del formato — "responde únicamente a partir de los siguientes documentos; cierra cada afirmación con una cita numerada"
• Instrucciones negativas — "no inferas información que no esté explícitamente mencionada en el contexto"
• Chain-of-thought (*cadena de pensamiento*) — para preguntas complejas, pedir al modelo que razone la respuesta paso a paso antes del output final; en tareas sensibles esto reduce significativamente el "cortocircuito" hacia una respuesta alucinada

Advertencia: los prompts son frágiles — funcionan para un modelo y versión concretos. Al cambiar de modelo o versión, los prompts deben reevaluarse. El prompt engineering es, por tanto, una actividad continua, no un entregable de una sola vez. Más detalle sobre este tema en el artículo Prompt engineering para producción.

Las cinco técnicas en conjunto

Ninguna técnica es suficiente por sí sola. En la práctica las combinamos en capas:

• Capa base — RAG con citas + permiso de "no sé" en el system prompt
• Capa de output — output estructurado + validación programática
• Capa de verificación — LLM-as-Judge para respuestas críticas
• Capa de calibración — temperatura baja + prompt few-shot para consistencia

El efecto de la combinación es sustancialmente mayor que la suma de las técnicas individuales. Los sistemas de producción donde hemos implementado las cuatro capas alcanzan una tasa de errores factuales notablemente inferior a los sistemas con una sola capa — del orden de décimas de punto porcentual frente a unidades de puntos en preguntas especializadas. Los números exactos dependen del dominio, la calidad de los documentos fuente y el método de evaluación.

Qué no ayuda con las alucinaciones

Para ser completos: qué no reduce las alucinaciones de forma fiable:

• Un modelo más grande — puede alucinar con más convicción; sin estrategia de grounding no sirve
• Un contexto más largo — más datos en el contexto no implica menos alucinaciones; el modelo puede ignorar el contexto relevante o interpretarlo incorrectamente
• Una simple prohibición de alucinar en el prompt — el modelo no entiende el concepto de "alucinación" de un modo que le permita prevenirla activamente; necesita instrucciones positivas para expresar incertidumbre
• La puntuación de benchmarks del modelo — MMLU y benchmarks similares están saturados y no miden el comportamiento en producción en dominios especializados; el resultado en un leaderboard no correlaciona de forma fiable con la tasa de alucinaciones en tu aplicación concreta

Preguntas frecuentes

¿Es posible crear un sistema que nunca alumine?

No. Los LLM son modelos generativos estocásticos — siempre existe una probabilidad no nula de output alucinado. El objetivo no es error cero, sino reducirlo a un nivel aceptable para el caso de uso dado e introducir mecanismos para detectar y capturar los errores antes de que causen daño. Para decisiones críticas (legales, médicas, de seguridad), la revisión humana sigue siendo imprescindible.

¿Ayuda el fine-tuning con datos corporativos a reducir las alucinaciones?

Solo parcialmente y no de forma directa. El fine-tuning (*ajuste fino del modelo* con datos propios) mejora el estilo de las respuestas, la terminología y el formato — pero no mejora la precisión factual si el modelo no recibe el contexto correspondiente durante la inferencia. Para reducir alucinaciones, RAG suele ser un enfoque más eficaz y más económico. Fine-tuning y RAG no se excluyen mutuamente — su combinación tiene sentido en despliegues más avanzados. El proceso de decisión entre ambos lo describimos en el artículo RAG vs fine-tuning — cómo decidir.

¿Cómo medir cuánto alucina nuestra aplicación LLM?

Una evaluación sistemática requiere un dataset de evaluación — un conjunto de preguntas con respuestas correctas o documentos fuente — y un framework de evaluación como RAGAS (para pipelines RAG) o Langfuse (para aplicaciones LLM en general). La evaluación automatizada mediante LLM-as-Judge puede cubrir grandes volúmenes, pero debe calibrarse frente a la valoración humana al menos en una muestra. Recomendamos siempre una auditoría humana periódica de los outputs en producción, no solo en el despliegue inicial.

¿Aumenta la temperatura baja el riesgo de respuestas estereotipadas o incompletas?

Sí, es un trade-off real. Una temperatura baja reduce la variabilidad — el modelo elige de forma consistente los tokens más probables, lo que en casos extremos puede llevar a frases repetitivas u omitir información menos probable pero relevante. En la práctica recomendamos una temperatura de 0.1–0.3 para tareas factuales, no el cero absoluto, y combinarla con instrucciones explícitas de exhaustividad en la respuesta.

¿Cuánto cuesta implementar estas técnicas?

Los costes son principalmente de implementación y operativos. Un pipeline RAG requiere una base de datos vectorial, un modelo de embeddings y lógica de retrieval — en una solución self-hosted (por ejemplo, Qdrant + modelo de embeddings de código abierto) hablamos de pocos euros al mes de infraestructura. LLM-as-Judge duplica el número de llamadas LLM para los outputs críticos, lo que incrementa los costes de API. Los structured outputs no tienen prácticamente coste adicional. La inversión total depende del volumen, pero en aplicaciones corporativas típicas (decenas a cientos de consultas diarias), el incremento de costes es despreciable frente al riesgo de un error silencioso en producción.

*Si planeas desplegar LLM en un entorno donde la precisión factual influye directamente en las decisiones — desde documentación técnica hasta soporte al cliente o cumplimiento normativo — estaremos encantados de ayudarte a evaluar qué combinación de técnicas tiene sentido para tu caso concreto. MP Industrial Solutions cuenta con experiencia en despliegues de producción tanto en entornos industriales como regulados.*