"El modelo alucinó" no es un diagnóstico, es una queja. El trabajo real empieza cuando conviertes ese reporte vago en una causa raíz reproducible — y la mayoría de las veces la causa no está en el modelo, está en tu pipeline.
No todas las alucinaciones tienen la misma causa raíz. Clasifica el incidente antes de tocar código:
- **Invención factual pura** — el modelo afirma algo falso sin que haya contexto relacionado en el prompt. Suele ser un problema de conocimiento paramétrico mal aplicado. - **Contradicción del contexto provisto** — el modelo tenía la información correcta en el prompt (documento recuperado, tool result) y aun así respondió algo distinto. Este es el más grave, porque indica que el modelo está ignorando el grounding que le diste. - **Sobregeneralización de un patrón** — responde con seguridad algo que "suena" correcto para ese tipo de pregunta pero no aplica al caso específico.
El segundo tipo casi siempre apunta a un problema de tu pipeline (context engineering, no el modelo). El primero y el tercero suelen necesitar ajustes de prompt o modelo.
Todo lo que hagas depende de poder reproducir el fallo. Loguea el `request_id` de cada llamada desde el día uno — es gratis y resuelve el 80% de la fricción de debugging después.
Sin el prompt exacto y el `request_id` guardados, "reproducir" el bug significa adivinar qué se le mandó al modelo hace tres días. Guarda el payload completo (system, messages, tools) asociado a cada respuesta que llega a producción — no solo el output.
El error más común: asumes que el modelo tenía cierta información porque "está en la base de datos", pero nunca verificas que efectivamente llegó al prompt. Antes de culpar al modelo, imprime el prompt exacto que se envió y verifica:
- ¿El documento relevante fue recuperado por tu paso de RAG, o el retrieval falló silenciosamente? - ¿El contexto llegó completo o fue truncado por un límite de tokens? - ¿El tool result que el modelo necesitaba llegó con `is_error: true` y el modelo improvisó una respuesta en vez de reportar el error?
Si el modelo respondió con seguridad sobre algo que no estaba en su contexto, no alucinó por capricho — probablemente rellenó un hueco que tu pipeline le dejó.
En modelos que soportan `effort`, un nivel bajo puede hacer que el modelo responda rápido sin verificar internamente su propia respuesta contra el contexto provisto. Si el caso de uso es sensible a precisión (extracción legal, datos financieros, respuestas médicas), sube el nivel de esfuerzo antes de rediseñar todo el prompt.
Un patrón que reduce alucinaciones de forma medible: instruir explícitamente que decir "no tengo esa información" es una respuesta válida y preferida sobre inventar algo plausible.
Este ajuste por sí solo suele reducir alucinaciones de contradicción de contexto de forma significativa — pero requiere que tu contexto realmente tenga la información cuando la necesitas, o el modelo va a decir "no sé" con demasiada frecuencia (un problema distinto pero más manejable).
Cuando encuentres un caso de alucinación reproducible, no lo arregles ad hoc y sigas adelante — conviértelo en un caso de test permanente. Un set de 30-50 casos reales (no sintéticos) que corres cada vez que cambias el prompt o el modelo es la única defensa real contra regresiones silenciosas.
Una técnica subutilizada: pídele al modelo que audite su propia respuesta contra el contexto, en una segunda llamada separada.
Esta segunda llamada es barata (puedes usar un modelo más chico) y detecta contradicciones de contexto de forma mucho más confiable que revisar el output a ojo. Es, en esencia, el mismo principio que el patrón de reflexión que cubro más adelante — solo que aplicado como herramienta de debugging en vez de como parte del flujo de producción.
La disciplina real aquí no es una técnica única, es el orden: reproducir, auditar contexto, ajustar effort, forzar admisión de incertidumbre, y solo al final tocar el prompt de fondo — con un set de regresión que evite que el próximo despliegue rompa lo que acabas de arreglar.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel