Un RAG sobre 11 000 archivos confundía referencias y devolvía datos de otra máquina

Un bot para el departamento de ventas que responde sobre documentación técnica se equivoca a un coste mayor que el chat de soporte de una tienda online. El gerente recibe una cifra, se la pasa al cliente y el cliente pide la máquina equivocada. Es justo el caso que se analiza en Habr: 11 000 archivos de documentación técnica, más de 100 gerentes de ventas y un bot RAG que citaba con total seguridad cifras de la ficha de un modelo vecino.

Qué se sabe del caso

La publicación en el feed de Habr solo está disponible por ahora como anuncio, así que nos basamos únicamente en lo que declara. El resto del texto es lógica de ingeniería general de este tipo de sistemas, no un resumen de mediciones del autor.

• Corpus: unos 11 000 archivos de documentación técnica.
• Audiencia: más de 100 gerentes de ventas.
• Síntoma: el bot responde con seguridad, pero toma los parámetros de la ficha de otra máquina.
• Clase de problema: consultas por código de artículo y por designación exacta del modelo.
• Resultado declarado: el autor describe qué acabó funcionando, con un análisis de las causas.

Por qué el vector confunde los códigos de artículo

Los embeddings densos comprimen un fragmento de texto en un vector que refleja su significado. Para una pregunta como «qué potencia tiene el husillo de este centro de mecanizado» funciona bien. Con una consulta por código de artículo como «XYZ-4200-B» la situación cambia. El tokenizador divide esa cadena en subpalabras, y el modelo de embeddings no tiene por qué considerar relevante la diferencia entre «4200-B» y «4200-D». En el espacio vectorial, esas designaciones quedan como vecinas.

Las fichas de producto de una misma serie agravan el problema. Están escritas con una misma plantilla: las mismas secciones, las mismas formulaciones, las mismas tablas. Solo cambian las cifras. Para un embedding son casi el mismo documento, y la búsqueda devuelve sin problema en el top-5 chunks de varios modelos a la vez.

Después actúa la mecánica habitual del LLM. Cuando recibe en el contexto un fragmento verosímil, lo cita. No sabe que la ficha no es la correcta, porque la consulta contiene un código de artículo y el contexto no, y nadie comprueba esa discrepancia. El error se produce en la fase de retrieval, no en la de generación, de modo que retocar el prompt de sistema aquí resulta casi inútil.

Qué revisar en tu RAG

El conjunto de técnicas para este tipo de tareas es conocido, y conviene probar cada una con consultas reales de los gerentes.

Primera: búsqueda híbrida. Un índice léxico como BM25 se sitúa junto al vectorial, y los resultados se combinan mediante Reciprocal Rank Fusion o ponderación. La coincidencia exacta de la cadena del código de artículo obtiene un peso que el vector no tiene.

Segunda: extracción de identificadores de la consulta. Si la pregunta contiene un código de artículo, se puede reconocer con una expresión regular o mediante un catálogo de modelos, y usarlo como filtro estricto sobre los metadatos del documento. Así, la ficha ajena simplemente no entra en los resultados.

Tercera: contexto dentro del chunk. Si al trocear se añade a cada fragmento el nombre del modelo, la serie y el nombre del archivo, la tabla de cifras deja de ser anónima.

Cuarta: reranker. Un cross-encoder aplicado sobre los N mejores candidatos empareja mejor la consulta y el fragmento que la comparación de dos vectores independientes.

Quinta, la más barata: comprobación antes de responder. Si el código de artículo de la consulta no aparece en las fuentes que han pasado al contexto, el bot debe decir «no lo he encontrado» en lugar de adivinar.

Para las pruebas, reúna un conjunto de preguntas reales con códigos de artículo, incluidos pares de modelos parecidos, y calcule la proporción de casos en que el documento correcto aparece en el top-k. Esta métrica revelará el problema antes de que lo note el cliente.