La tesis en una frase: reducir alucinaciones de IA en producción es un problema de ingeniería resuelto a medias por todo el mundo y explicado con humo por casi todos. Hay tres o cuatro cosas que mueven la aguja de verdad y una docena que se venden como si lo hicieran y no. Este es el scorecard: técnica por técnica, con veredicto. Si alguien te vende una de las de "humo" como la solución, ya sabes por dónde va.
Antes de entrar: esto no es el "por qué" de la alucinación. Que el modelo prediga lo plausible y no lo verdadero, y que esté entrenado para no callarse nunca, lo contamos en por qué la IA alucina y qué exigirle a tu proveedor. Aquí damos por hecho el diagnóstico y vamos a lo que de verdad importa en producción: qué palancas tocar y cuáles ignorar.
Cómo leer este scorecard de técnicas para reducir alucinaciones de IA en producción
Cada técnica lleva un veredicto de tres: mueve la aguja (bájala y notarás menos alucinación en tus datos), depende (ayuda en un caso concreto, no es general) y humo (se vende como solución y casi no cambia nada). El criterio no es teórico: es qué pasa cuando lo pones delante de datos reales y volumen real, no de una demo con cinco preguntas elegidas.
Lo que es humo (o casi)
Empezamos por lo que más se vende y menos rinde, porque es donde más dinero y tiempo se pierde.
- "Dile en el prompt que no invente". Humo. Añadir "no te inventes nada, si no lo sabes di que no lo sabes" ayuda un poco en el margen, pero le estás pidiendo honestidad a un sistema que no tiene un interruptor de verdad dentro. Cuando no sabe algo tuyo, el prompt no le da el dato; solo le pide que se calle, y obedece a ratos. Útil como cinturón, inútil como freno.
- Bajar la temperatura. Humo para esto. La temperatura controla cuánto se arriesga el modelo al elegir la siguiente palabra, no si el dato es correcto. A temperatura 0 alucina de forma más consistente, no menos. Reduce la variabilidad, no la falsedad.
- El modelo más nuevo y más grande. Depende, tirando a humo. Un modelo mejor alucina algo menos en conocimiento general, pero sobre TUS datos —los que no estaban en su entrenamiento— sigue sin tener ni idea, por potente que sea. Cambiar de modelo no te resuelve el problema que más duele: el de tu información.
- Fine-tuning "para enseñarle tus datos". Humo para hechos, útil para estilo. Afinar un modelo le enseña a sonar como tú y a seguir formatos, no a memorizar datos frescos y citables. Si tu dato cambia cada semana, el fine-tuning va siempre por detrás. Para hechos, lo que quieres es grounding, no fine-tuning —lo explicamos abajo—.
Lo que mueve la aguja de verdad
Estas son las piezas de ingeniería que sí bajan la alucinación donde importa. Ninguna es un truco; todas son exigibles a quien te monte el sistema.
- Grounding / RAG: responde con tus documentos delante, no de memoria. Mueve la aguja, y es la palanca número uno. El sistema busca primero en tu documentación los fragmentos relevantes y se los pone al modelo para que responda sobre ellos. El hecho vive fuera del modelo, en una base que controlas. No elimina la alucinación, pero la corta donde más duele: en tus datos. Cómo se monta esa capa —qué documentos, cómo se trocean, cómo se recupera— lo detallamos en cómo entrenar un agente con tu propia información.
- Citas verificables: cada afirmación con su fuente. Mueve la aguja, porque convierte la alucinación de invisible en auditable. Un sistema serio enseña el fragmento exacto que usó para cada respuesta. Si la cita no respalda lo que dice, saltas. Y la regla dura: si el sistema no puede citar de dónde sale una respuesta, esa respuesta no se despliega.
- Abstención: dejar que diga "no lo sé". Mueve la aguja, y casi nadie la implementa. Configurar el sistema para que, por debajo de un umbral de confianza o sin fuente que respalde, responda "no tengo esto" en vez de improvisar, elimina la categoría de error más cara: la respuesta falsa con aplomo. Es incómodo porque baja la tasa de respuesta; es correcto porque sube la de aciertos.
- Humano en el bucle donde el error cuesta (no en todo). Mueve la aguja sin matar el ahorro. Meter a una persona a revisar cada respuesta elimina el ROI; no meterla en ninguna es una ruleta. El diseño correcto pone el freno humano solo donde el error es caro o irreversible —un importe, un compromiso legal, un mensaje al cliente— y deja pasar lo barato de deshacer.
- Evals: medir la tasa de alucinación. Mueve la aguja indirectamente, y es innegociable. Medir no baja la alucinación por sí solo, pero sin un número que puedas ver cada semana no sabes si tus otras palancas funcionan ni cuándo el sistema se ha degradado. Lo que no se mide, se degrada en silencio.
El scorecard de un vistazo
| Técnica | ¿Mueve la aguja? | Por qué |
|---|---|---|
| Prompt "no inventes" | Humo | Le pides honestidad a un sistema sin dato; obedece a ratos |
| Bajar temperatura | Humo | Controla la variabilidad, no la verdad |
| Modelo más nuevo/grande | Depende | Mejora el saber general, no tus datos |
| Fine-tuning para hechos | Humo | Enseña estilo, no datos frescos y citables |
| Grounding / RAG | Sí | El hecho vive fuera del modelo, en tu base |
| Citas verificables | Sí | Convierte la alucinación en auditable |
| Abstención ("no lo sé") | Sí | Elimina la respuesta falsa con aplomo |
| Humano donde el error cuesta | Sí | Freno solo en lo caro o irreversible |
| Evals / medir la tasa | Sí | Sin número no sabes si lo demás funciona |
El checklist de producción
Si vas a poner IA en producción y no quieres que la alucinación te llegue al cliente, esto es lo mínimo exigible: grounding sobre tus documentos, citas en cada respuesta, abstención configurada, humano en los puntos caros y una eval que mida la tasa cada semana. Lo demás —prompts, temperatura, el modelo del mes— es afinado, no cimiento. Y ojo: una IA que alucina es solo un síntoma de un problema más grande, el del dato sucio y el proyecto sin dueño, que contamos en por qué fracasan los proyectos de automatización con IA.
Montar esas cinco piezas y sostenerlas es exactamente lo que hacemos en infraestructura de IA empresarial: no te entregamos un modelo que promete no mentir, te dejamos un sistema que sabe cuándo callar y enseña de dónde saca cada respuesta. La diferencia entre las dos cosas es la que separa una demo de un sistema en producción.