Alucinaciones de IA en producción: cómo un retailer las redujo del 15% al 1,5% sin cambiar de modelo

Al cierre del primer mes en producción, aproximadamente el 15% de las respuestas de un sistema de recomendación de inventario basado en LLM eran alucinaciones de IA en producción: textos que sonaban seguros y no se apoyaban en nada real. Seis meses después, la tasa era del 1,5%. Y la palanca no fue un modelo mejor. Fue dejar de tratar el stack de LLM como un asunto de cada aplicación y empezar a tratarlo como infraestructura de plataforma.

La historia la cuenta Aditya Mulik, ingeniero de Walmart Global Tech, en un extenso artículo publicado en InfoQ. El proyecto es una plataforma de precisión de inventario en una gran organización de retail. Allí, los registros del sistema se desvían de lo que hay físicamente en las estanterías por pérdidas, daños, robos y errores de conteo, y esa brecha deteriora los pedidos y la disponibilidad de producto. Un sistema multiagente analiza señales de discrepancia en millones de SKUs y miles de millones de registros históricos, y genera recomendaciones correctivas. Enruta tráfico empresarial por modelos como Gemini y GPT, y hoy da servicio a decenas de equipos en casos como auditorías de inventario, revisión de reabastecimiento y triaje de discrepancias.

Por qué las aplicaciones LLM aisladas fallan a escala

El patrón se repite: el prototipo funciona, la primera semana en producción parece bien, y luego aparecen problemas que las evaluaciones no detectaron. En este caso fueron tres: límites de tasa (throttling) del proveedor del modelo bajo volumen real, contexto defectuoso (las recomendaciones erróneas casi siempre venían de los datos que se le daban al modelo, no del modelo) y, el más grave, las alucinaciones, que pasaron de ser eventos raros a una tasa constante.

Lo peligroso es que una alucinación no es un stack trace: pasa todos los chequeos de salud tradicionales, un servicio posterior la consume y actúa sobre ella. A eso se suma el gasto de tokens sin atribución, que llega como una sola línea en la factura del proveedor, y una observabilidad de LLM inexistente: las herramientas APM tradicionales no detectan la degradación semántica. El equipo concluyó que son problemas transversales, no bugs de aplicación, y que cada equipo resolviéndolos por su cuenta produce N copias del mismo código de andamiaje.

Cómo funciona la plataforma de LLM que bajó las alucinaciones al 1,5%

Los resultados se apoyan en varias piezas compartidas, según el artículo y las reseñas de daily.dev:

Bucle de reintentos automático que captura errores de formato, de grounding y de infraestructura, apoyado en validación de salidas estructuradas con esquemas Pydantic. Es la pieza que recortó las alucinaciones sin tocar el modelo base.

Compuerta de validación de intención: si ningún agente encaja, devuelve "unclassified" en lugar de asignar la consulta al agente con mayor puntaje. Esto elimina alucinaciones fuera de intención y mejora el enrutamiento multiagente.

Registro de prompts con historial, que permite actualizar o revertir instrucciones en tiempo de ejecución con trazabilidad completa.

Autorización de herramientas en el servidor del recurso con política de denegación por defecto, no solo en el API gateway.

Métricas en el ingreso de cada solicitud: tasa de alucinación y costo de tokens por equipo.

El autor publicó además un repositorio con todas estas primitivas, ejecutable con llama3.1 vía Ollama y LiteLLM a costo cero de API. Como señala el análisis de EE2.ai, el texto no detalla los costos de construir la plataforma ni las alternativas descartadas, un dato que conviene tener presente al evaluar el caso.

Lecciones para tu organización: cuándo y cómo montar una plataforma de LLM

La lección más valiosa es de timing: el punto de decisión no es la primera aplicación, sino la segunda. Cuando diez equipos ya envían funcionalidades con LLM, reconstruir los cimientos es una migración larga y dolorosa. A cambio, un contrato claro (la aplicación declara modelo, versión de prompt, esquema, herramientas y motor de evaluación, y la plataforma resuelve el resto) permite llevar un caso nuevo a producción en días, no en meses.

Pasos concretos:

1. Mide antes de optimizar. Instrumenta la tasa de alucinación y el costo por equipo desde el primer día. Añadir esta atribución a una ruta en vivo cuesta semanas de ingeniería. Compañías como Shopify, que gestiona un presupuesto de tokens a gran escala con sistemas internos, muestran que el control del consumo es una disciplina propia.
2. Valida cada salida. Esquemas estrictos, reintentos clasificados por tipo de error y una respuesta explícita de "no sé" o "sin clasificar" valen más que cambiar de modelo.
3. Versiona los prompts como código. Cambiarlos sin auditoría es la forma más fácil de romper en silencio el comportamiento de tu IA.
4. Aplica denegación por defecto en cada herramienta. Es la misma lógica de confianza cero que GitHub aplica a los agentes de IA en CI/CD: si un bug del orquestador puede exponer todas las herramientas, tu seguridad depende de una sola capa.
5. Invierte en gobierno de modelos. A medida que proliferan agentes y casos de uso, se vuelve imprescindible la visibilidad que Netflix buscó con su Model Lifecycle Graph para gestionar cientos de modelos interconectados.

El error a evitar: pensar que la fiabilidad es un problema del proveedor del modelo. La evidencia de este caso indica lo contrario: la tasa de alucinación es una métrica que la plataforma puede controlar.

Reducir las alucinaciones de IA en producción es una decisión de arquitectura

El mensaje de fondo para CTOs y gerentes de innovación es incómodo y útil: mientras esperas el próximo modelo, tu ventaja competitiva puede estar en la capa que lo rodea. Pasar de 15% a 1,5% de alucinaciones de IA en producción sin cambiar de modelo convierte la fiabilidad en una cuestión de ingeniería, no de suerte. La pregunta para tu próximo comité: ¿cuántos equipos de tu empresa están resolviendo hoy, por separado, los mismos problemas de reintentos, prompts y costos?