Un agente puede responder bien en una demostración y fallar cuando empieza a conversar con clientes reales. En Bodega del iPhone lo vivimos de primera mano: el asistente confundía información de compra y venta, mezclaba referencias y, en ocasiones, respondía sobre productos que el negocio no ofrecía.
La mejora llegó al cambiar la información que podía consultar y las decisiones que debía tomar antes de responder. Esta experiencia muestra cómo abordamos esos errores y por qué, cuando una empresa pregunta por la tasa de alucinación de un bot, la respuesta necesita contexto.
Un caso histórico. El proyecto se desarrolló aproximadamente entre año y medio y dos años antes de este relato, según recuerda el responsable de Solventio. El foco está en las decisiones y los aprendizajes de aquella implementación.
El problema: una buena prueba no era suficiente
Bodega del iPhone compraba y vendía celulares Apple y recibía muchas consultas por WhatsApp. El equipo necesitaba atender preguntas sobre referencias y precios sin repetir manualmente la misma búsqueda en cada conversación.
Construimos un asistente sobre la plataforma de asistentes de OpenAI, con documentos como fuente de consulta. El enfoque inicial utilizaba recuperación de información, conocida como RAG: buscar contenido relevante y entregárselo al modelo para preparar su respuesta.
Escribimos instrucciones, ajustamos el comportamiento e hicimos pruebas controladas. En ese entorno parecía funcionar. Con la variedad de mensajes que llegaban a producción aparecieron dificultades que nuestras pruebas no habían cubierto suficientemente:
- Ante una intención de compra del negocio, recuperaba información del catálogo de venta al público.
- Si no encontraba una referencia, podía completar la respuesta con un producto o dato inexistente.
- Llegaba a mencionar Android, aunque el alcance del negocio era Apple.
- Prolongaba conversaciones fuera de su alcance en lugar de reconocer el límite.
Estos incidentes combinaban problemas distintos: recuperación equivocada, selección incorrecta de herramientas y afirmaciones sin respaldo. Para corregirlos era necesario mirar el recorrido completo de la consulta.
El método: identificar, consultar, comprobar y responder
Añadir más restricciones al prompt no bastó. La decisión central fue sustituir la búsqueda abierta en documentos para precios y referencias por consultas delimitadas a una base de datos externa.
1. Separar la intención de compra y de venta
Comprar y vender significan cosas distintas según quién habla. Si el cliente quiere vender su iPhone, corresponde consultar las condiciones de compra del negocio. Si quiere comprar uno, corresponde consultar la oferta de venta al público.
Separamos ambas bases para reducir el riesgo de mezclar sus datos. El agente debía identificar la intención y el producto antes de consultar. Cuando faltaba un dato necesario, la respuesta adecuada era pedirlo, no elegir una referencia por su cuenta.
2. Entregar únicamente la información necesaria
El agente identificaba el producto con buen desempeño en las pruebas de aquella implementación. Aprovechamos esa capacidad para que una herramienta consultara la referencia específica y devolviera un resultado acotado.
Traer todo el catálogo para contestar una pregunta de precio aumentaba las posibilidades de mezclar información. Reducimos lo que el asistente tenía a mano: una consulta concreta debía recibir datos concretos del producto y de la operación correspondiente.
La base externa no se convirtió por sí sola en una garantía. Lo que ayudó fue combinar datos estructurados, separación de operaciones y un alcance claro para cada consulta.
3. Distinguir una lista de una cotización
También había clientes que pedían ver las opciones disponibles. El agente necesitaba poder consultar una lista sin tratarla como la respuesta a una cotización específica.
Definimos cuándo solicitar un listado y cuándo recuperar el detalle de una referencia. El criterio era la intención y la información disponible en ese momento, no simplemente que la conversación estuviera empezando o terminando. Si alguien elegía un producto de la lista, el siguiente paso era consultar su detalle antes de dar una respuesta específica.
4. Derivar cuando no había una respuesta respaldada
Otro cambio fue reconocer los casos que debía atender una persona. Ante preguntas que antes terminaban en una respuesta inventada, el asistente pasó a transferir la atención a un asesor.
Ejemplo ilustrativo del recorrido: “Quiero venderles mi iPhone” → identificar referencia y datos necesarios → consultar la base de compra del negocio → responder con la información disponible o pasar a un asesor. No es una transcripción real de un cliente.
Qué cambió y cómo leer el 60/40 y el 90/10
El responsable de Solventio recuerda la evolución como un paso aproximado de 60/40 a 90/10, una manera de describir que el comportamiento útil se volvió mucho más frecuente después de los ajustes.
Son estimaciones retrospectivas de aquella experiencia, no una medición auditada de alucinaciones. No tenemos aquí una muestra documentada, un periodo de evaluación ni una clasificación que permita separar respuestas correctas, errores y derivaciones. Por eso no sería preciso afirmar que “el bot tenía exactamente un 40 % de alucinación y terminó con un 10 %”.
Una transferencia correcta tampoco equivale a una alucinación ni a una consulta resuelta automáticamente. Es un resultado diferente: el agente reconoce un límite y permite que una persona continúe. El aprendizaje más útil fue dejar de medir el valor del asistente solo por cuánto respondía y prestar atención a qué podía responder con respaldo.
Qué hacemos hoy con guardrails y harnesses
Los modelos han ampliado sus capacidades para interpretar instrucciones y utilizar herramientas. Esto permite instrucciones más claras y, según el modelo y la tarea, menos extensas. No significa que podamos eliminar reglas, comprobaciones o pruebas porque el modelo sea más reciente.
Hoy el diseño de un agente puede incorporar guardrails: controles de entrada, de herramientas y de salida. En un catálogo, por ejemplo, una validación puede impedir responder con un precio si no corresponde al registro recuperado o rechazar referencias fuera del alcance autorizado. Los controles importantes deben apoyarse en datos y lógica verificable, además del prompt.
El harness es el entorno que coordina al modelo: conserva el estado de la tarea, ejecuta herramientas y decide qué comprobaciones ocurren antes de entregar el resultado. No es simplemente “recibir texto y devolver texto”. Para una consulta de producto, un recorrido posible es identificar la intención, consultar la fuente, validar el resultado y después responder o derivar.
Pedirle al modelo que revise su respuesta puede ayudar, pero no constituye una verificación independiente: también puede repetir un error. Por eso conviene comprobar los datos contra su fuente y evaluar el resultado del sistema completo. Anthropic explica esta relación entre modelo, herramientas y evaluación.
La memoria: otro reto en conversaciones largas
En nuestro trabajo con agentes para tareas de oficina también hemos observado una dificultad diferente: conservar decisiones, preferencias y formas de trabajar entre conversaciones. Que un asistente olvide una plantilla acordada no es lo mismo que inventar un precio, aunque ambos problemas afecten la confianza.
Las skills permiten empaquetar instrucciones y recursos para repetir un procedimiento con una guía consistente. Cuando una parte debe ejecutarse exactamente igual, también puede apoyarse en código o plantillas. El estándar Agent Skills describe este formato.
Hay varias opciones de memoria que conviene distinguir:
- Hermes Agent documenta memoria persistente y un sistema de skills reutilizables. Guardar aprendizajes ayuda a mantener continuidad, pero no implica que cada aprendizaje sea correcto ni que el modelo se reentrene automáticamente. Documentación de Hermes.
- Honcho ofrece una capa de memoria orientada a mantener contexto y comprensión de los participantes a través de las interacciones. Sitio oficial de Honcho.
- Hindsight permite almacenar información, recuperarla y elaborar respuestas a partir de los recuerdos guardados. Documentación de Hindsight.
- Las memorias basadas en grafos, como las que documenta Zep, organizan hechos y relaciones para recuperar contexto, incluyendo cambios a lo largo del tiempo. Documentación de Zep.
Estas referencias describen opciones actuales; no forman parte de la implementación histórica de Bodega del iPhone. La memoria necesita selección, actualización y separación por usuario o empresa. Recordar un precio antiguo nunca debe sustituir una consulta al catálogo vigente.
Cómo evaluar el riesgo antes de poner un agente a atender
Para responder con rigor “¿cuánto alucina?”, proponemos definir primero qué cuenta como error y sobre qué conjunto de conversaciones se medirá. Una evaluación útil debería incluir:
- Consultas normales, mensajes ambiguos, cambios de intención y conversaciones de varios turnos.
- Productos inexistentes, información faltante y herramientas que no responden.
- Comprobación de referencias, precios y disponibilidad contra la fuente vigente.
- Medición separada de afirmaciones sin respaldo, consultas resueltas y derivaciones correctas o innecesarias.
- Revisión de conversaciones reales y repetición de las pruebas después de cambiar modelos, datos o instrucciones.
Si medimos alucinación por respuesta, el indicador puede ser el número de respuestas evaluadas con al menos una afirmación factual sin respaldo dividido por el total de respuestas evaluadas. Debe acompañarse de la muestra, el periodo y la gravedad de los errores; una cifra aislada oculta demasiado.
Errores frecuentes son confiar únicamente en una demo, entregar información excesiva, mezclar éxito con transferencia y asumir que una conversación corta elimina el riesgo. Una atención acotada y bien conectada a sus fuentes facilita el control, pero su desempeño debe comprobarse en cada implementación.
Lo que este caso nos enseñó
En Bodega del iPhone mejoramos el comportamiento al organizar las fuentes, limitar cada consulta y dar una salida clara cuando la información no alcanzaba. Ese principio sigue siendo útil: la calidad de un agente depende del modelo y del sistema que lo rodea.
Hoy contamos con más recursos para diseñar ese sistema. No publicamos una tasa universal de alucinación para todos nuestros bots ni una promesa de cero errores. Preferimos acordar qué debe resolver cada agente, cómo lo vamos a comprobar y cuándo debe intervenir una persona.
¿Quieres evaluar un agente con preguntas reales de tu operación? Conversemos sobre tus consultas, fuentes de información y criterios de aceptación. También puedes conocer el caso de Seguridad Omega: IA para preparar respuestas contractuales y el de Cardedeu: construir la atención con IA junto al equipo comercial.