Habr: 6 causas por las que falla la memoria de un agente RAG y cómo comprobar el retrieval

Cuando un agente RAG responde fuera de lugar, la primera sospechosa suele ser la LLM. En la práctica, lo más frecuente es que el fallo esté en la búsqueda: si el fragmento necesario no llega al contexto, incluso un modelo potente se inventará la respuesta o dirá que no tiene datos. El análisis de Habr se centra en seis causas de estos fallos y en un método para diagnosticar el retrieval. El anuncio de la publicación solo incluye la definición de la tecnología; la lista de causas queda oculta tras un corte ("под катом"). Por eso, a continuación presentamos un mapa de los fallos típicos, en el orden en que los suelen revisar los ingenieros.

RAG (Retrieval-Augmented Generation) conecta el modelo con una base de conocimiento externa. El agente no se apoya solo en lo aprendido durante el entrenamiento: primero busca información en documentos corporativos, manuales o internet, y redacta la respuesta a partir de ella. El pipeline tiene al menos cinco etapas: segmentación de documentos, vectorización, indexación, búsqueda y ensamblado del contexto. Un error en cualquiera de ellas se ve igual: el agente "se ha olvidado".

Dónde suele romperse la búsqueda

La primera zona de riesgo es la segmentación en chunks. Los fragmentos demasiado pequeños pierden contexto; los demasiado grandes diluyen el significado del vector. Una tabla cortada por la mitad o una definición separada de su término no aparecerán con ninguna consulta.

La segunda es el modelo de embeddings. Si funciona mal con el ruso, con terminología especializada o con código, textos semánticamente cercanos acabarán lejos unos de otros en el espacio vectorial.

La tercera es la actualización del índice. Se actualiza un documento, pero no se lanza la reindexación, y el agente cita con total seguridad la versión del reglamento del año pasado. Para la memoria del agente, es la fuente más frecuente de respuestas "obsoletas".

La cuarta es la formulación de la consulta. El usuario escribe "¿cómo tramito unas vacaciones?", pero en la base el documento se llama "Procedimiento de concesión de las vacaciones anuales retribuidas". Ayudan la reescritura de la consulta y la división de una pregunta compleja en subconsultas.

La quinta es el ranking. La búsqueda vectorial pura encuentra mal códigos de artículo, nombres y siglas. Un esquema híbrido con BM25 y un reranker sobre los mejores candidatos suelen aportar una mejora notable de precisión.

La sexta es el ensamblado del contexto. Los modelos aprovechan peor los datos situados en medio de un prompt largo. Los duplicados, los fragmentos superfluos y un orden poco acertado reducen la calidad, aunque la búsqueda haya funcionado bien.

Cómo diagnosticar el retrieval

El principio básico: comprobar la búsqueda por separado de la generación. Para ello se reúne un conjunto de referencia de preguntas, cada una con su fragmento fuente asignado de antemano. Bastan unas decenas o un par de cientos de ejemplos, pero deben reflejar consultas reales de los usuarios, no inventadas por los desarrolladores.

Después se calculan las métricas:

• recall@k: proporción de preguntas para las que el fragmento necesario aparece entre los k primeros resultados. Si aquí hay un fallo, no hace falta mirar más allá;
• precision@k: cuánto de lo encontrado resulta realmente útil, es decir, cuánto ruido llega al prompt;
• MRR: en qué posición media se sitúa el primer resultado correcto;
• nDCG: calidad del orden de los resultados cuando hay varios fragmentos relevantes;
• latencia de la búsqueda y del reranking, porque una precisión comprada con segundos de espera suele ser inaceptable para un agente.

Si el recall es alto y las respuestas son malas, el problema está más abajo en el pipeline: en el ensamblado del contexto o en el propio modelo. Si el recall es bajo, se empieza por los chunks y los embeddings.

Orden práctico de actuación

Primero, reúna el conjunto de referencia y fije las cifras de partida. Después cambie un parámetro cada vez: tamaño del chunk, modelo de embeddings, incorporación de BM25, reranker, número de fragmentos que se pasan al modelo. Contraste cada cambio con las métricas, no con la impresión que dejen unas cuantas conversaciones acertadas.

Configure el monitoreo por separado: registre la consulta, los fragmentos encontrados y sus puntuaciones. Cuando un usuario se queje de una respuesta incorrecta, mire antes que nada si el documento necesario estaba entre los resultados. Establezca una reindexación periódica y compruebe que los documentos actualizados han llegado realmente al índice. Y no intente arreglar el retrieval con el prompt: pedir "responde con más precisión" no devolverá un dato que no está en el contexto.