Un usuario pregunta por la política de vacaciones y recibe una respuesta basada en un documento que ya no existe. En ese escenario, el índice de Qdrant todavía conserva el documento y nadie registra qué fragmentos llegan al LLM. Medir la calidad de un sistema RAG empieza por esa capa: qué recupera, en qué orden y con qué puntuación.
La recuperación decide el resultado
El flujo habitual convierte la pregunta en un embedding; Qdrant recupera los k fragmentos más próximos mediante HNSW y los envía al LLM. El bi-encoder codifica la pregunta y el fragmento por separado, dentro del mismo modelo, y compara sus vectores. Eso puede elevar fragmentos que comparten el tema general, aunque no contengan la información solicitada.
Registra en cada consulta los fragmentos recuperados, sus puntuaciones y los modelos utilizados. Sin ese registro, una caída de calidad no muestra qué cambió ni en qué punto del pipeline. El leaderboard MTEB de Hugging Face reúne resultados por tarea e idioma; úsalo como punto de partida y confirma la selección con tus propias consultas. Con esa base, el siguiente paso es reordenar los candidatos antes de enviarlos al LLM.
Re-ranking: un segundo filtro con más contexto
Un cross-encoder recibe la pregunta y el fragmento juntos y produce una puntuación de relevancia para esa pareja. Este enfoque evalúa la relación conjunta, mientras que la similitud coseno solo compara vectores generados por separado. Ejecutarlo sobre todo el corpus eleva el coste; por eso, el patrón habitual consiste en recuperar una lista corta con Qdrant, reordenarla con el cross-encoder y enviar al LLM los fragmentos mejor clasificados. Entre las opciones están la API comercial Cohere Rerank y el modelo abierto BAAI/bge-reranker-v2-m3, disponible en Hugging Face.
La API Query de Qdrant admite prefetch y fusión RRF, con la que puedes ordenar resultados de búsquedas densas y dispersas. Qdrant también admite multivectores para recuperación de late interaction en patrones como ColBERT. Al incorporar un re-ranker, cambian tanto el orden de los fragmentos como el contexto que recibe el LLM. Repite la evaluación de respuestas sobre un conjunto fijo y compara los resultados antes y después del cambio.
Métricas de recuperación que significan algo
Para aplicar las métricas de recuperación, crea un golden set con consultas representativas y sus fragmentos relevantes etiquetados a mano. Recall@k mide qué proporción de los fragmentos relevantes aparece entre los k primeros. MRR calcula el promedio de la posición recíproca del primer resultado relevante. nDCG valora el orden completo y admite distintos niveles de relevancia.
Exporta las consultas de tus logs y etiqueta la relevancia a nivel de fragmento. Un mismo documento puede estar relacionado con el tema y no contener la respuesta necesaria. Estas métricas muestran si el sistema recupera la evidencia y la coloca en posiciones útiles. Para comprobar si la respuesta final aprovecha esa evidencia, hace falta evaluar también la generación.
Evaluar la generación: fidelidad y relevancia de la respuesta
Recuperar bien no garantiza responder bien, porque el LLM puede ignorar el contexto o añadir información que no aparece en los fragmentos. RAGAS puede estimar la fidelidad de la respuesta, su relevancia respecto a la pregunta y la precisión del contexto mediante un LLM como juez. Ese juez no equivale a una fuente de verdad: una respuesta más larga puede obtener una buena puntuación sin aportar más pruebas. Complementa las métricas automáticas con una muestra manual revisada periódicamente.
Cuando la respuesta correcta se reduce a una cifra, un nombre o un plazo, la coincidencia exacta o una regla determinista resulta más fácil de auditar que un juez LLM. Si el RAG alimenta agentes con herramientas, los permisos, las cuotas y los registros de la capa MCP afectan a lo que el agente puede hacer con la respuesta. La guía MCP en producción: guardarraíles, cuotas y registros de tus agentes explica cómo controlar esa capa.
Del golden set al pipeline de CI
Guarda el golden set versionado junto al código y ejecuta la evaluación con cada cambio de modelo de embeddings, prompt o re-ranker. Establece qué variaciones bloquean el despliegue y qué casos deben revisarse manualmente. Cuando cambies el modelo de embeddings, crea una colección nueva y reindexa el corpus; sus vectores no comparten el mismo espacio de referencia, aunque tengan dimensiones idénticas. Probar ambos modelos en la misma colección produce comparaciones poco fiables.
Si los datos no pueden salir de tu infraestructura, los modelos abiertos de embeddings y re-ranking pueden ejecutarse en local con una infraestructura adecuada. Qdrant también puede funcionar dentro de tu red, de modo que el índice no depende de un servicio externo. La guía IA local y RGPD: privacidad desde el diseño en tu propia infraestructura describe ese enfoque.
Empieza con un conjunto inicial de consultas reales y etiqueta la relevancia de cada fragmento. Calcula Recall@k y MRR antes y después de aplicar un cross-encoder a los primeros candidatos de Qdrant, con el mismo valor de k en ambas ejecuciones. Ejecuta esa evaluación en CI cada vez que cambien el modelo, el prompt o el re-ranker. Cada ajuste queda asociado a una evidencia concreta: un fragmento relevante que cae de posición, un documento que deja de entrar en el contexto o una respuesta sin respaldo.