Ha enviado un sistema RAG. Funciona... en su mayor parte. A veces las respuestas son impresionantemente buenas. A veces afirma con seguridad algo que está completamente equivocado, citando un documento que no dice lo que el modelo afirma que dice. Y a veces se pierde la respuesta por completo a pesar de que el documento correcto se encuentra ahí mismo en su base de conocimientos.
Este es el estado normal de un sistema RAG de producción. La pregunta no es si tiene problemas de calidad (los tiene), sino si tiene una forma sistemática de encontrarlos y solucionarlos. Para eso están las retrospectivas RAG: examinar periódicamente dónde falla su canalización y realizar mejoras específicas en lugar de adivinar.
Por qué los sistemas RAG necesitan sus propias retrospectivas
RAG no es un solo sistema. Es una cadena de componentes y la calidad de cada eslabón determina el resultado final. Cuando la respuesta es mala, el fallo puede estar en cualquier parte:
- Ingestión: Los documentos se analizaron incorrectamente, los fragmentos se dividieron en lugares incorrectos y se perdieron metadatos
- Recuperación: La consulta de búsqueda no coincidió con los documentos correctos, el modelo de incrustación no detectó la conexión semántica, su top-K era demasiado pequeño o demasiado grande
- Asamblea de contexto: Los fragmentos recuperados eran relevantes individualmente pero se contradecían entre sí, o la ventana de contexto estaba llena de ruido
- Generación: El modelo alucinó a pesar de un buen contexto, o ignoró el contexto relevante a favor de su conocimiento paramétrico.
Las retrospectivas de software estándar no están equipadas para desenmarañar estos modos de falla. Necesita un formato que rastree los resultados defectuosos a lo largo del proceso para encontrar el punto real de falla. De lo contrario, terminará "arreglando" la recuperación cuando el problema real era la fragmentación, o reescribiendo mensajes cuando el problema real era la recuperación.
Métricas que vale la pena seguir
Antes de ejecutar una retrospectiva RAG, necesita datos. No todas las métricas posibles, solo las suficientes para diagnosticar los modos de falla más comunes.
Calidad de recuperación
Precisión@K: De los documentos K recuperados, ¿cuántos eran realmente relevantes? Si estás retirando 10 fragmentos y solo 2 son útiles, estás inundando la ventana de contexto con ruido.
Recuerda@K: De todos los documentos relevantes en su base de conocimientos, ¿cuántos terminaron en sus primeros resultados? Un recuerdo bajo significa que existen las respuestas correctas pero su recuperación no puede encontrarlas.
MRR (Rango recíproco medio): ¿Dónde aparece el primer resultado relevante en tu ranking? Si el mejor documento está constantemente en la posición 5 en lugar de en la posición 1, es necesario mejorar su clasificación incluso si la recuperación es buena.
No es necesario calcularlos en toda su base de conocimientos. Muestre entre 50 y 100 consultas recientes, haga que un juez humano determine qué documentos recuperados eran relevantes y calcule a partir de ahí. Haga esto mensualmente.
Calidad de generación
Fidelidad: ¿La respuesta generada refleja realmente lo que dicen los documentos recuperados? Ésta es la cuestión de las alucinaciones. Puede verificar esto comparando los resultados con el contexto proporcionado.
Relevancia de la respuesta: ¿La respuesta realmente responde a la pregunta que se hizo? Es posible generar un resumen perfectamente fiel de los documentos recuperados que no capta por completo la intención del usuario.
Utilización del contexto: Cuando la información correcta está en el contexto recuperado, ¿la utiliza realmente el modelo? Si constantemente recupera buenos documentos y el modelo los ignora, ese es un problema del lado de la generación (generalmente un problema de aviso).
Métricas operativas
Latencia: ¿Cuánto tiempo lleva todo el proceso desde la consulta hasta la respuesta? Divida esto por componente para saber si la recuperación o la generación es el cuello de botella.
Costo por consulta: Realice un seguimiento del uso de tokens y de los costos de API. Algunas mejoras de calidad (como ampliar la ventana de contexto o reclasificar) aumentan significativamente el costo.
Ejecutando la retrospectiva
Preparación (antes de la reunión)
Asigne a alguien para que prepare una "muestra de errores": entre 10 y 15 consultas recientes en las que el resultado fue incorrecto o de mala calidad. Para cada uno, capture el estado completo de la canalización: la consulta original, qué se recuperó, qué contexto se envió al modelo y qué generó el modelo. Este rastro es esencial. Sin él, estás depurando a ciegas.
Prepare también sus tendencias métricas. ¿Las cosas están mejorando o empeorando desde la última retro? ¿Algún cambio brusco?
La Reunión (60 minutos)
Revisión de métricas (10 minutos). Recorra las métricas de recuperación y generación. Céntrese en las tendencias y las sorpresas, no en una recitación número por número. "La precisión@5 cayó de 0,72 a 0,58 este mes" es útil. Leer cada métrica de un tablero no lo es.
Análisis de fallos (35 minutos). Este es el núcleo de lo retro. Tome la muestra de fallas y clasifique cada una según el lugar donde se rompió la tubería:
- Fallo de recuperación: No se recuperaron los documentos correctos. ¿Por qué? ¿La consulta y el documento no coinciden? ¿Limitación del modelo de incrustación? ¿El filtrado de metadatos es demasiado agresivo?
- Fallo de fragmentación: Se recuperó el documento correcto, pero los límites de los fragmentos dividieron la respuesta en dos fragmentos y solo se devolvió uno. O el fragmento era demasiado grande y estaba diluido con contenido irrelevante.
- Fallo del contexto: Se recuperaron buenos fragmentos, pero el orden o truncamiento de la ventana de contexto perdió la información importante. O fragmentos en conflicto confundieron el modelo.
- Fallo de generación: Se proporcionó un buen contexto, pero el modelo alucinó de todos modos, ignoró el contexto o dio una respuesta vaga en lugar de la específica disponible en los documentos.
Para cada falla, pregunte: "¿Cuál es la solución más barata que habría detectado o evitado esto?" A veces es un ajuste rápido. A veces se trata de volver a fragmentar un documento específico. A veces es un cambio sistémico.
Priorización y elementos de acción (15 minutos). Agrupe las fallas por causa raíz. El patrón que causó la mayor cantidad de fallas recibe la mayor atención. Elija 2 o 3 mejoras para implementar antes de la próxima retrospectiva.
Patrones de fallas comunes y soluciones
Estos son los patrones que verá con más frecuencia y los enfoques prácticos para cada uno:
"El documento correcto está en nuestra base de conocimientos, pero no lo recuperamos". Suele ser un problema de similitud de incrustación. La consulta del usuario utiliza un vocabulario diferente al del documento fuente. Correcciones: agregue un paso de expansión de la consulta (reescriba la consulta del usuario en varias frases), implemente la búsqueda híbrida (combine incrustaciones semánticas con concordancia de palabras clave como BM25) o mejore el filtrado de metadatos para reducir el espacio de búsqueda.
"Recuperamos el documento correcto pero el fragmento equivocado". Su estrategia de fragmentación es más importante de lo que la mayoría de los equipos creen. Si utiliza fragmentación de tamaño fijo (por ejemplo, 500 tokens), es casi seguro que está dividiendo contenido importante entre límites. Correcciones: utilice fragmentación semántica (división basada en cambios de tema), agregue superposición de fragmentos, pruebe la fragmentación jerárquica donde los fragmentos principales más grandes proporcionan contexto para fragmentos secundarios más pequeños.
"El modelo ignora el buen contexto e inventa cosas". Este es un problema de conducta modelo y de incitación. El conocimiento paramétrico del modelo entra en conflicto con el contexto proporcionado y el conocimiento paramétrico está ganando. Correcciones: ajuste el mensaje del sistema para indicar explícitamente al modelo que solo use el contexto proporcionado, agregue una instrucción "si el contexto no contiene la respuesta, dígalo", considere reducir la temperatura del modelo.
"Las respuestas son correctas pero demasiado lentas". Los problemas de latencia generalmente provienen de uno de tres lugares: demasiadas llamadas de recuperación, una ventana de contexto demasiado grande (más tokens = generación más lenta) o pasos de reclasificación que agregan tiempo de procesamiento. Perfile su tubería componente por componente. La solución depende de hacia dónde va el tiempo.
"La calidad es inconsistente: excelente para algunos temas, terrible para otros". Esto suele significar que algunas partes de su base de conocimientos están mejor indexadas que otras. Quizás ciertos documentos se analizaron mal o ciertos temas carecen de cobertura suficiente. Mapee sus fracasos por área temática y encontrará las lagunas.
Construyendo un circuito de mejora continua
Los equipos RAG más eficaces tratan su sistema como un producto, no como un proyecto. Nunca está "hecho". Cada retrospectiva debería producir mejoras incrementales, y esas mejoras deberían poder medirse en la próxima retrospectiva.
Una cadencia práctica:
- Semanal: Revisión rápida de métricas de calidad automatizadas (puede ser asíncrona, simplemente consulte el panel)
- Quincenal o mensual: Retrospectiva completa con análisis de fallos.
- Trimestral: Decisiones arquitectónicas más importantes: ¿deberíamos cambiar los modelos de integración, reestructurar nuestra base de conocimientos, adoptar una nueva estrategia de fragmentación?
Mantenga un documento actualizado de lo que ha probado y el impacto que tuvo. La optimización RAG es iterativa y no lineal: a veces revisará enfoques que no funcionaron antes porque el resto del proceso ha cambiado lo suficiente como para que funcionen ahora.
Evita la trampa de objetos brillantes
Cada semana hay un nuevo documento o marco que pretende resolver la calidad RAG. Resista la tentación de rediseñar su canalización basándose en una publicación de blog. En su lugar, utilice sus datos retrospectivos para identificar su mayor problema de calidad real y resolver ese problema específico. Quizás la respuesta sea un nuevo y elegante modelo de reclasificación. Lo más probable es que esté arreglando la forma en que fragmenta la documentación de su producto.
Los equipos que mejoran más rápido no son los que utilizan la arquitectura más sofisticada. Son los que tienen el circuito de retroalimentación más estrecho entre "este resultado fue malo" y "este es el motivo específico y esto es lo que cambiamos".
Prueba NextRetro gratis — Clasifique los patrones de falla RAG con columnas y vote qué mejoras de canalización priorizar.
Última actualización: febrero 2026
Tiempo de lectura: 7 minutos
