Mitiga las alucinaciones del LLM paso a paso

Por qué una alucinación no se «arregla» con un prompt

Antes de tocar configuración, conviene aceptar una realidad incómoda: las alucinaciones no son un bug que se elimina con una instrucción más firme. Son un comportamiento emergente del funcionamiento probabilístico del modelo. Un LLM genera el token más probable dada una secuencia, no consulta una base de hechos. Cuando el contexto no contiene la respuesta, el modelo no se detiene: completa con lo que estadísticamente encaja. Eso significa que cualquier configuración que prometas «cero alucinaciones» te está vendiendo humo.

Lo que sí puedes hacer es reducir la superficie donde aparecen, detectarlas antes de que lleguen al usuario y degradar el sistema de forma controlada cuando la confianza cae. Este artículo es una secuencia de configuración real, con parámetros concretos, umbrales y verificaciones, para equipos que ya tienen un LLM en producción o están a punto de ponerlo.

Paso 1: separa los tipos de alucinación antes de configurar nada

No todas las alucinaciones se mitigan igual. Configurar sin clasificar lleva a parchear el sitio equivocado. Distingue al menos estas cuatro, porque cada una pide una capa distinta:

• Factual: el modelo afirma un dato falso (una fecha, una cifra, una ley). Se combate con recuperación de contexto y verificación externa.
• De atribución: inventa una fuente, un autor o una cita. Es la más peligrosa en contenido editorial porque parece verificable.
• De instrucción: ignora una restricción del sistema (responde en otro idioma, rompe el formato). Se combate con validación de salida.
• De razonamiento: los pasos intermedios son plausibles pero la conclusión no se sigue. Se combate con descomposición y comprobación de cada paso.

Un caso que veo repetidamente en equipos de contenido: configuran temperatura a 0 pensando que eso acaba con las invenciones de fuentes. Baja la variabilidad, sí, pero un modelo con temperatura 0 sigue inventando referencias si no tiene el dato. La temperatura reduce la dispersión, no la ignorancia.

Paso 2: fija la temperatura y el sampling según la tarea

La configuración del sampling es el primer dial real. No existe un valor universal; existe un valor por tipo de tarea. Guíate por esta tabla:

Advertencia de experto: bajar top_p a 0,5 recorta la cola de tokens improbables, lo que reduce invenciones raras pero también vuelve el texto más plano y repetitivo. En tareas de extracción estructurada conviene combinarlo con constrained decoding (gramáticas o esquemas JSON forzados), que es más efectivo que cualquier ajuste de temperatura para evitar campos inventados.

Paso 3: monta recuperación con umbral de rechazo

La palanca más potente contra la alucinación factual es no dejar que el modelo responda de memoria. Configura un pipeline RAG (retrieval-augmented generation) con estas decisiones explícitas:

1. Troceado: fragmentos de 300 a 600 tokens con solapamiento del 10-15%. Fragmentos demasiado grandes diluyen la señal; demasiado pequeños pierden el contexto que evita interpretaciones erróneas.
2. Recuperación híbrida: combina búsqueda semántica (embeddings) con búsqueda léxica (BM25). La semántica falla con identificadores, códigos y nombres propios; la léxica falla con paráfrasis. Juntas cubren más.
3. Umbral de similitud: define una puntuación mínima (por ejemplo, 0,75 en similitud coseno, ajustada tras medir con tu propio corpus) por debajo de la cual el sistema no llama al modelo y devuelve un mensaje de «no tengo información suficiente».
4. Prompt de contexto cerrado: instruye al modelo a responder solo con los fragmentos recuperados y a indicar explícitamente cuando el contexto no cubre la pregunta. Esta instrucción no es infalible, pero combinada con el umbral reduce drásticamente las respuestas inventadas.

Aquí va el error práctico que casi todos cometen la primera vez: configurar el umbral de recuperación demasiado alto. El sistema empieza a rechazar preguntas legítimas y el equipo, frustrado, lo baja a cero. El umbral correcto no se adivina: se calibra con un conjunto de 50 a 100 preguntas reales, midiendo cuántas veces rechaza una pregunta que sí tenía respuesta frente a cuántas veces responde sin contexto. Sin ese conjunto de calibración, cualquier umbral es una corazonada.

Paso 4: instrucciones de sistema que sí funcionan (y las que no)

Las frases del tipo «no inventes nada» tienen eficacia limitada. Funcionan mejor las instrucciones operativas y verificables:

• En lugar de «sé preciso», usa «cita el fragmento de contexto del que sale cada afirmación; si no hay fragmento, responde ‘no consta'».
• En lugar de «no alucines», usa «si la pregunta requiere datos posteriores a tu conocimiento o no presentes en el contexto, dilo antes de responder».
• Añade un formato de salida con campos obligatorios: respuesta, fuentes (lista de fragmentos usados), confianza (alta/media/baja). El campo de fuentes fuerza al modelo a comprometerse y facilita la verificación automática.

Lo que no funciona: apilar diez restricciones negativas en el prompt de sistema. A partir de cierto número, el modelo empieza a ignorar las primeras o a sobre-restringirse y rechazar peticiones válidas. Prioriza tres o cuatro reglas críticas y valida cada una con pruebas.

Paso 5: verificación de salida antes de mostrar al usuario

La configuración no termina en el modelo. Añade una capa de validación programática entre la respuesta y el usuario:

• Validación de esquema: si esperas JSON, rechaza cualquier salida que no cumpla el esquema. No intentes repararla con otro prompt sin marcar el fallo.
• Comprobación de entidades: extrae nombres, fechas y cifras de la respuesta y compáralos con el contexto recuperado. Si una entidad no aparece en ninguna fuente, márcala.
• Verificación de citas: si el modelo cita un documento, comprueba que ese documento existe en tu índice y que el fragmento citado está en él. Las citas inventadas se detectan así con alta fiabilidad.
• Segunda pasada con otro modelo o prompt: un modelo más pequeño actuando como verificador puede señalar afirmaciones no sustentadas. No es infalible y añade latencia, pero en flujos de contenido editorial compensa.

Matiz importante: la verificación automática tiene falsos positivos. Un verificador demasiado estricto rechazará respuestas correctas que parafrasean el contexto en lugar de citarlo literalmente. Configura el verificador para comparar significado, no coincidencia exacta de cadenas, o tendrás un sistema que rechaza todo.

Paso 6: define el comportamiento de degradación

Un sistema maduro sabe qué hacer cuando no está seguro. Configura explícitamente estos estados:

1. Confianza alta: respuesta directa con fuentes.
2. Confianza media: respuesta con advertencia visible y enlaces a las fuentes para verificación humana.
3. Confianza baja: no responder; ofrecer reformular la pregunta o derivar a un humano.
4. Fallo de validación: registrar el caso completo (prompt, contexto recuperado, salida, motivo del rechazo) para análisis posterior.

El registro es la parte que más se olvida y la más valiosa. Sin un log de fallos no puedes mejorar umbrales ni prompts; solo puedes rezar. Según la documentación de los principales proveedores de modelos, la evaluación continua con conjuntos de prueba propios es la única forma fiable de medir si tus cambios reducen alucinaciones o solo las desplazan.

Paso 7: mide con un conjunto de prueba propio, no con benchmarks públicos

Los benchmarks genéricos no reflejan tu dominio. Configura un conjunto de evaluación con tres tipos de casos: preguntas que tu sistema debe responder correctamente, preguntas fuera de alcance que debe rechazar y preguntas con trampa (premisas falsas) que debe corregir. Ejecuta ese conjunto cada vez que cambies temperatura, prompt, modelo o umbral de recuperación.

Dos métricas mínimas: tasa de invención (respuestas con afirmaciones no sustentadas dividido entre respuestas dadas) y tasa de rechazo correcto (preguntas fuera de alcance rechazadas dividido entre preguntas fuera de alcance). Si optimizas solo la primera, el sistema acabará rechazándolo todo; si optimizas solo la segunda, responderá inventando. Se mueven en tensión y hay que vigilarlas juntas.

Lo que esta configuración no resuelve

Transparencia total: incluso con todo lo anterior bien montado, quedan alucinaciones residuales. Los casos que peor se controlan son las alucinaciones de razonamiento en preguntas que requieren varios pasos encadenados, las que surgen de contexto recuperado ambiguo (documentos que se contradicen entre sí) y las que aparecen cuando el usuario empuja al modelo con premisas falsas persistentes. En dominios regulados (salud, legal, financiero) ninguna configuración sustituye la revisión humana; el sistema puede asistir, pero la responsabilidad de la afirmación final no es delegable al modelo.

La expectativa realista no es cero alucinaciones, sino alucinaciones detectadas antes de causar daño, con un sistema que sabe cuándo callarse. Esa es la configuración que puedes defender ante un cliente o un auditor.

Sobre el autor: Deivi Sanz — Soy David, conocido como Deivi Sanz, especialista en SEO y marketing digital con más de 15 años de experiencia ayudando a negocios a destacar en el mundo online. Mi pasión es transformar ideas en estrategias digitales efectivas, combinando análisis de datos, creatividad y las últimas tendencias en posicionamiento web. En este blog comparto mis conocimientos sobre SEO técnico, content marketing y growth hacking, siempre con un enfoque práctico y resultados medibles. Cuando no estoy optimizando webs o escribiendo artículos, me encontrarás explorando nuevas herramientas SEO, analizando casos de éxito o disfrutando de un buen café mientras planifico la siguiente estrategia viral. También me gusta implementar ideas creando plugin para WordPress o aplicaciones para Android.

Perfiles verificables: Sitio web

Publicado el 25 de October de 2026. Última revisión: 25 de October de 2026.