Tu agente de IA no entiende cuando le preguntas por un código exacto

Si tienes un catálogo de productos, servicios o programas con códigos o referencias —SKU, códigos de programa, números de referencia, nombres de modelo—, hay una pregunta que deberías hacerle hoy mismo a tu agente de IA: pídele información sobre uno de esos códigos exactos. No un nombre, un código.

Hay una probabilidad real de que te responda mal. O peor: que invente una respuesta que suena perfectamente convincente pero es falsa.

Un caso real (anonimizado)

Trabajamos con una institución educativa que gestiona un catálogo de más de 100 programas académicos, cada uno con un código interno corto (algo como "ECBTI 17" o un código numérico de registro oficial). Su agente de IA, entrenado sobre toda la documentación de la institución, respondía de maravilla cuando un usuario preguntaba en lenguaje natural: "¿qué carreras de tecnología tienen?", "¿cuánto cuesta la maestría en seguridad informática?". Respuestas correctas, con los montos exactos, citando la fuente real.

Pero cuando alguien preguntaba directamente por un código —exactamente el tipo de pregunta que hace quien ya investigó un poco y solo quiere confirmar un dato puntual— el agente fallaba. En el peor de los casos, inventaba un programa que no existe, con un nombre que sonaba perfectamente plausible pero que no estaba en ningún documento real de la institución.

Hicimos una prueba controlada con 9 preguntas reales de ese tipo. El agente solo respondía bien al 44% de ellas.

Por qué pasa esto

La mayoría de los agentes de IA basados en RAG (la tecnología que permite que un agente "lea" tus documentos para responder) usan un único método de búsqueda: comparan el significado de la pregunta con el significado de cada fragmento de tus documentos. Esto funciona excelente para lenguaje natural, incluso con errores de ortografía — el sistema entiende que "tecnologia en agronegosios" (con errores) y "Tecnología en Gestión de Agronegocios" (correcto) son básicamente lo mismo.

El problema es que un código corto como "ECBTI 17" no tiene "significado" en ese sentido. Para el motor de búsqueda semántica, es casi ruido. Y cuando la búsqueda no encuentra nada relevante, el modelo de lenguaje —que está diseñado para siempre dar una respuesta útil— puede terminar generando algo que parece correcto pero no lo es. Eso se llama alucinación, y en un negocio real tiene un coste: un cliente que recibe información falsa sobre un producto, un precio o una condición de servicio. Es el mismo riesgo que describimos al diseñar un agente de soporte técnico que no debe inventar una solución que no ha verificado: la confianza del usuario depende de que el agente admita no saber, en vez de rellenar el hueco con algo plausible.

La solución que no funcionó (y por qué es importante saberlo)

Nuestra primera corrección, antes de encontrar la solución real, fue dejar que el modelo filtrara la búsqueda usando etiquetas y categorías de los documentos ("busca solo en la categoría X"). Sonaba razonable: dar más estructura debería ayudar.

Resultó ser contraproducente. El modelo, sin darse cuenta, a veces inventaba una categoría que no existía en los documentos reales — y ese filtro inventado excluía el documento correcto antes de que la búsqueda tuviera oportunidad de encontrarlo. Medimos tres variantes de esta idea contra el mismo catálogo real, y la que mejor funcionó fue, sorprendentemente, la más simple: que el modelo nunca tenga la opción de inventar un filtro. Sin filtros automáticos, la tasa de respuestas correctas pasó del 12% al 87%.

La lección aplicable a cualquier negocio que use IA: más "inteligencia artificial decidiendo cómo buscar" no siempre es mejor. A veces, menos autonomía del modelo en los pasos críticos produce resultados más confiables.

La solución que sí funcionó

Implementamos lo que se llama búsqueda híbrida: en vez de depender de un solo método, el sistema ahora combina dos búsquedas independientes —una por significado (la que ya tenía) y una nueva por coincidencia exacta de texto— y fusiona los resultados de ambas con un algoritmo que no favorece artificialmente a ninguna de las dos.

Con este cambio activado, repetimos la prueba con la misma pregunta exacta por un código: antes, cero resultados. Después, el resultado correcto, único y sin ambigüedad.

Y lo que nos importaba tanto como el resultado: ninguna de las preguntas normales en lenguaje natural empeoró. El agente sigue entendiendo bien errores de ortografía, nombres parciales y preguntas conversacionales — la mejora es un complemento, no un reemplazo.

Lo que esto significa para tu negocio

Si tu agente de IA responde consultas sobre un catálogo con códigos, referencias, números de modelo o cualquier identificador corto —y la mayoría de catálogos los tienen—, vale la pena hacer esta prueba:

1. Pídele al agente información sobre un código o referencia específica, tal como un cliente real lo escribiría.
2. Si responde con seguridad pero de forma genérica, vaga, o con un nombre de producto que no reconoces del todo, probablemente estás viendo el mismo problema.
3. La solución no es "entrenar más al modelo" ni "darle más contexto" — es activar un mecanismo de búsqueda complementario, diseñado específicamente para este tipo de consulta.

Esto lo activamos por defecto en las bases de conocimiento de los agentes que implementamos en Ceibot: búsqueda híbrida, activada automáticamente, sin que el cliente final note ningún cambio salvo que ahora las preguntas que antes fallaban, funcionan. Es exactamente el tipo de mejora que nunca ves en una demo rápida, pero que determina si un agente de IA es confiable en producción o solo se ve bien en una presentación.