Seis métricas de evaluación de RAG que son importantes en la producción
Recall@K, nDCG, MRR, fidelidad, latencia y costo: cómo depurar la recuperación de información que parece mejor en teoría mientras las respuestas empeoran.
Los tutoriales iniciales sobre RAG hacen que el proceso parezca sencillo: dividir documentos, incrustarlos, almacenar vectores, elegir un pequeño valor para top_k y llamar al modelo. Ese procedimiento puede parecer eficaz en una demostración, pero la producción no es tan indulgente.
Las preguntas llegan de forma desordenada. Los documentos originales se contradicen entre sí. Algunos prompts requieren evidencia de varios lugares al mismo tiempo. Los usuarios inventan formulaciones que nunca aparecieron en el conjunto de pruebas original. Una configuración que obtenía buenos resultados en pruebas estándar comienza a dar respuestas extrañamente inestables.
Mientras se ajustaba el sistema de recuperación para un asistente de tipo empresarial, ese patrón se hizo evidente. La falta de evidencia obligó al equipo a aumentar la profundidad de recuperación. Las puntuaciones en recuperación sin conexión mejoraron, al igual que la tasa de recuerdo. Las métricas indicaban “mejoras”, pero las respuestas generadas empeoraron.
El contexto adicional no ayudaba. A veces incluso causaba problemas. Los pasajes relevantes llegaban mezclados con duplicados, elementos irrelevantes y conflictos ocasionales.
Esa experiencia cambió la forma de evaluar. La pregunta dejó de ser “¿hemos seleccionado el archivo correcto?” y pasó a ser “¿cada etapa del proceso puede demostrar que está cumpliendo su función?”
Depurar sistemas RAG en tiempo real permite separar varios aspectos que, en las demostraciones, se reducen a una sola puntuación: qué tan bien se recuperan los datos, qué tan bien se clasifican, cuán buena es la respuesta, si las afirmaciones están fundamentadas, cuánto tiempo esperan los usuarios y cuánto cuesta cada solicitud. La pregunta que todos hacen a continuación —¿cómo deberíamos elegir el tamaño de los fragmentos y el valor top-k?— ya no merece una respuesta genérica basada en números.
Trata el problema como una optimización fuera de línea: crea datos de referencia, mide las señales adecuadas, identifica los compromisos, verifica consultas no vistas y luego confirma que el resultado sigue siendo bueno en entornos reales.
Seis métricas son especialmente útiles: Recall@K, nDCG, MRR, Faithfulness, Latency y Costo. Cada una revela un tipo diferente de fallo. Juntas explican cómo un prototipo se convierte en un sistema operativo.
Comience con la recuperación de información
Cuando las respuestas empeoran, vuelva al inicio del proceso antes de reescribir los prompts, cambiar de modelo o añadir agentes. Haga la pregunta directa: ¿se está encontrando siquiera la evidencia necesaria? Un modelo no puede utilizar material que nunca haya entrado en la ventana de contexto.
1. Recall@K: cobertura de la evidencia requerida
Recall@K determina qué fracción de los elementos verdaderamente relevantes aparecen entre los K resultados más importantes.
Tomemos un bot ITSM ante la pregunta: “El servicio de pago falló tras una conmutación de base de datos; ¿qué pasos de recuperación debo seguir?”. Supongamos que se necesitan cinco datos. Los cinco resultados principales del sistema de recuperación solo incluyen cuatro de ellos. El Recall@5 es 0.80.
Ese único número ya guía el proceso de depuración. Es posible que el generador no sea el culpable; el veinte por ciento de las pruebas necesarias nunca llegó. Regla práctica: mejore lo que ve el modelo antes de culpar la forma en que escribe.
También explica por qué un valor fijo de top_k = 5 no es sagrado. Al cambiar K de 5 a 10 y observar cómo el Recall aumenta de 0.80 a 0.94, se deduce que el índice contiene el material necesario pero la selección es demasiado superficial. Aumentar K también conlleva el riesgo de saturar la solicitud con ruido, por lo que a continuación vienen las métricas de clasificación.
2. nDCG: ¿están los mejores resultados cerca de la parte superior?
Solo la cobertura no es suficiente. La posición también importa.
Dos sistemas pueden utilizar el mismo manual de procedimientos. Uno lo coloca primero, luego otro procedimiento útil y después secciones menos relevantes. El otro oculta el manual en la posición ocho, entre páginas poco relacionadas. Recall similar; productos muy diferentes.
Las puntuaciones nDCG (ganancia acumulada descontada normalizada) evalúan la relevancia y otorgan mayor importancia a que los elementos más relevantes aparezcan primero. El trabajo clásico sobre ganancias descontadas de Järvelin y Kekäläinen existe precisamente por esa razón.
El reordenamiento hace esto concreto en el contexto de RAG: se recuperan veinte candidatos, se mantienen cinco para el modelo, y el orden de esos veinte determina si los cinco seleccionados son realmente buenos. Un alto nivel de recuperación acompañado de un ordenamiento deficiente puede hacer que el pasaje adecuado esté en la lista pero fuera del prompt final.
La recuperación verifica el descubrimiento de información; nDCG, en cambio, verifica un ordenamiento inteligente.
3. MRR: ¿cuán rápido se obtiene el primer resultado útil?
El promedio del rango recíproco se centra en el primer resultado relevante:
[
RR = \frac{1}{\text{rank of first relevant result}}
]
Rango 1 → RR 1.0. Rango 5 → RR 0.2. Al promediarlo en un conjunto de consultas, el MRR es una señal clara cuando el primer resultado bueno domina la experiencia del usuario.
Los asistentes interactivos a menudo se detienen después del primer pasaje relevante. Un recuperador que oculta el manual adecuado en la posición nueve puede parecer funcional en Recall@20, pero seguir funcionando mal en la interfaz de usuario.
Cuando “más contexto” tiene efectos negativos
Aunque los números de recuperación mejoraron, la calidad de las respuestas siguió disminuyendo. El modelo se encontraba inmerso en texto redundante y contradictorio. Las métricas de clasificación explican este problema: un valor K más alto, sin una mejor organización, introduce ruido en la solicitud. Eso conduce a verificaciones de coherencia.
4. Fidelidad: afirmaciones vinculadas al texto recuperado
La fidelidad se refiere a si las afirmaciones de la respuesta están respaldadas por el contexto recuperado. Un texto fluido que inventa un paso, establece umbral o combina dos políticas en una tercera incumple la fidelidad, incluso si suena convincente.
Se debe mantener la fidelidad separada de la corrección.
Supongamos que el corpus aún contiene una regla de contraseña obsoleta: vencer cada 60 días. El modelo la recupera y la repite. La respuesta puede ser completamente fiel a la página recuperada y, aun así, incorrecta con respecto a la fuente de verdad pretendida.
- Fidelidad: ¿está respaldada por lo que se recuperó?
- Corrección: ¿es verdadera según la política establecida?
Esa distinción es importante siempre que las bases de conocimiento cambian dentro de un sistema en funcionamiento.
5. Latencia: tiempo que los usuarios exigentes pueden esperar
La calidad sin conexión es inútil si el producto no puede permitirse ese tiempo de espera.
Comparemos dos configuraciones. Una alcanza un 91% de precisión en las respuestas con una latencia de recuperación de 120 ms. La otra logra un 93% con 650 ms. La segunda gana solo en precisión. Las limitaciones del producto determinan si realmente es mejor. Los asistentes interactivos con presupuestos estrictos de respuesta pueden rechazar ese retraso, y la recuperación es solo una parte del tiempo total.
Una solicitud en tiempo real puede incluir tareas de reescritura, recuperación de datos, reclasificación, generación de contexto y creación de contenido. Es necesario medir las etapas del proceso así como el camino completo desde el inicio hasta el final. Es preferible utilizar distribuciones estadísticas en lugar de promedios. Un promedio de 400 ms con un P95 de 1,8 s no se parece en nada a un sistema cuyos valores P50/P95/P99 permanezcan bajos.
Incluya la latencia en el plan de evaluación desde el primer día, y no solo como una métrica operativa una vez que la arquitectura esté definida.
6. Costo: qué ocurre con millones de consultas
Los aspectos económicos se vuelven relevantes en el momento en que un prototipo se convierte en un producto.
Aumentar el número de resultados top-k afecta más que la tasa de recuperación. Esto puede incrementar el trabajo del motor de reclasificación, el tamaño del contexto final, la cantidad de tokens de entrada, la latencia y el consumo de recursos de infraestructura.
Si cada bloque contiene en promedio 600 tokens, entonces:
Final K = 5
se insertan aproximadamente 3,000 tokens recuperados. Ir a:
Final K = 15
y estás más cerca de los 9,000: el triple de la masa recuperada. El tráfico mínimo oculta las consecuencias económicas. Millones de solicitudes lo convierten en una opción de producto. Top-k es al mismo tiempo un parámetro para la calidad, la latencia y el costo.
Qué significa realmente “ajustar el tamaño del bloque y top-k”
La pregunta en la entrevista no busca dos números mágicos, sino un diseño experimental.
Crea aproximadamente 200 consultas representativas relacionadas con la resolución de problemas, procedimientos, incidentes/RCA, políticas, ambigüedades, conexiones múltiples y casos extremos. Deja que los expertos en el área evalúen su relevancia.
Prueba diferentes tamaños de bloque, como:
Chunk sizes:
256
512
1024
2048
y prueba también diferentes grillas de /candidate-K, como:
Overlap:
64
128
256Candidate K:
5
10
20
Una grilla de 4 × 3 × 3 genera unas 36 configuraciones. Evalúa cada una con más de un indicador:
Recall@K
nDCG@K
MRR
Answer correctness
Faithfulness
Latency
Cost
Luego elige la configuración óptima en términos de calidad, latencia y costo, no necesariamente la que ofrece el mayor porcentaje de recuperación o F1.
Resultados de experimentos contraintuitivos
Supongamos que tres configuraciones arrojan los siguientes resultados:
- A: Recall@10 0.94, nDCG@10 0.81, precisión 0.89, fidelidad 0.95, P95 510 ms, $0.025
- B: Recall@10 0.91, nDCG@10 0.88, precisión 0.94, fidelidad 0.96, P95 560 ms, $0.027
- C: Recall@10 0.97, nDCG@10 0.79, precisión 0.86, fidelidad 0.76, P95 820 ms, $0.034
Solo en base al Recall, C es la mejor opción. Sin embargo, C genera las respuestas más débiles; al parecer, la recuperación adicional perjudica la generación. B tiene un Recall menor, pero lidera en nDCG, precisión y fidelidad con solo una ligera penalización por latencia/costo. Esa es la configuración que merece ser analizada en profundidad, y explica por qué la regla “gana quien tenga la puntuación de recuperación más alta” no es válida en todos los casos. Es necesario optimizar según el objetivo real del producto.
Fallo → siguiente investigación
- Recall@K bajo → fragmentación, embeddings, índice, filtros de metadatos, formato de la consulta, estrategia de recuperación
Esa lista de verificación convierte la depuración en un procedimiento sistemático.
Mantener el ciclo activo en producción
Un benchmark único no representa el estado final. Se necesita una evaluación continua. El tráfico real difiere de los conjuntos preparados previamente: cambian las formulaciones, los documentos se actualizan, las políticas evolucionan, aparecen nuevos servicios y surgen casos límite. Ampliar el conjunto de evaluación con los fallos que ocurren en producción.
Carta de calificación madura
Ninguna métrica por sí sola cuenta toda la historia. Una tarjeta útil registra conjuntamente el alcance, el ranking, la exactitud, la fidelidad, los percentiles de latencia y la economía por unidad.
Haga preguntas antes de ajustar
Cuando alguien exija un tamaño de bloque y un top-k, responda primero con preguntas: ¿qué estamos optimizando?, ¿cómo es el conjunto etiquetado? y, ¿cuál es el costo de una recuperación fallida? Con esas respuestas, las configuraciones se convierten en resultados experimentales.
Un posible resultado podría ser:
512 tokens
128 overlap
Candidate K = 20
Final K = 5
Otro:
1024 tokens
64 overlap
Candidate K = 10
Final K = 4
El particionamiento semántico podría superar a ambos. Un reordenador podría hacer que el K final sea más importante que los K candidatos.
No confíe en un valor universal sin medición. Un sistema RAG no es “bueno” solo porque recupera más información, lo hace más rápido o suena convincente. Es bueno cuando encuentra las pruebas adecuadas, las clasifica correctamente, proporciona al modelo la cantidad justa de contexto, genera respuestas tanto correctas como fundamentadas, y se mantiene dentro de los límites de latencia y costo del producto.
Esa brecha —entre configurar un pipeline y diseñar un sistema de producción— es precisamente el punto clave.
Deje de adivinar los parámetros
No existe una longitud mítica para los fragmentos de texto, ni un valor top-k universal, ni ninguna métrica por sí sola que pueda indicar que una implementación está lista. Incluso un mejor Recall@K puede perjudicar la calidad de las respuestas. Una capacidad de recuperación sólida aún puede permitir afirmaciones sin sustento. Una alta precisión también puede fallar si la latencia o el costo aumentan exponencialmente a escala.
Equilibre la cobertura, el ranking, la generación fundamentada, la latencia y el costo según la carga de trabajo que realmente atiende.
Preferencia: verdad de referencia → pruebas de recuperación → verificaciones de clasificación → calidad de respuesta de extremo a extremo → validación de latencia/costo → casos no vistos en espera → monitoreo en producción → errores en los datos de entrada que se reintegran al conjunto.
Luego, chunk_size=512 o top_k=5 son evidencias, no meras creencias populares.
Presentar las seis métricas en una sola página
Una hoja de puntuación práctica para una revisión semanal de RAG podría verse así:
- Recall@K y MRR para “¿encontramos evidencias, y con qué rapidez?”
- nDCG para “¿pusimos las mejores evidencias primero?”
- Fidelidad y corrección de la respuesta para “¿la generación se mantuvo honesta y precisa?”
- Latencia P50/P95 para “¿pueden esperar los usuarios?”
- Costo por respuesta exitosa para “¿puede esperar el departamento financiero?”
Revísalos juntos. Un aumento en Recall@K acompañado de una disminución en la fidelidad no es una ventaja. Una reducción en la latencia que haga colapsar el nDCG tampoco es una ventaja. El propósito del marco de seis métricas es hacer visibles esos compromisos en lugar de ocultarlos dentro de un único número F1.
La verdad objetiva es el recurso escaso
Las métricas solo son tan buenas como las etiquetas que las sustentan. Si los expertos en el área nunca determinan qué pasajes son relevantes, Recall@K no sirve de nada. Si nadie califica la relevancia, el nDCG se convierte en un valor binario ruidoso. Si los evaluadores de fidelidad no son consistentes, las puntuaciones también varían.
Dedica tiempo al etiquetado de la misma manera que lo haces para los experimentos de incrustación. Doscientas consultas evaluadas cuidadosamente suelen enseñar más que dos mil sin etiquetar. Actualiza ese conjunto con los tickets de producción: cada “deducible incorrecto”, “regla de contraseña obsoleta” y “manual no consultado” es un caso potencial.
De la experimentación al control de cambios
Cuando una configuración resulta exitosa en entorno offline, promuévala como cualquier otro cambio en producción. Registre la rejilla que probó, los parámetros ganadores, los resultados de los casos no incluidos y el rango de latencia/costo que aceptó. Luego observe las mismas métricas en el tráfico real durante un período de pruebas. Si las consultas en producción difieren, incorpore esos fallos al conjunto etiquetado y ejecute nuevamente la rejilla. Ese ciclo —y no el tamaño por defecto de un artículo de blog— es lo que distingue a un sistema ajustado adecuadamente de una demostración basada en suerte.
Por qué mienten los prototipos
Los cuadernos de demostración suelen corregir el conjunto de consultas, congelar el corpus y ocultar la latencia tras una sola llamada. En entornos de producción ocurre lo contrario: las consultas cambian, los documentos se actualizan constantemente y los usuarios abandonan las respuestas lentas. Por eso una configuración que parecía excelente en una prueba estática puede resultar poco fiable después del lanzamiento. Las seis métricas mencionadas anteriormente son una forma de hacer explícitas esas dimensiones ocultas antes de lanzar el producto, y de mantenerlas así una vez lanzado.
Cuando alguien solicita un tamaño de bloque predeterminado y un valor top-k predeterminado, convierta esa solicitud en un plan de experimentación. Asigne un nombre al objetivo, al conjunto etiquetado, al presupuesto de latencia y al techo de costos. Luego deje que la matriz genere los números correspondientes. Cualquier otra cosa no es más que conjeturas disfrazadas de ingeniería.
Mantenga la tabla de indicadores visible en las revisiones semanales para que los compromisos queden claros para todo el equipo.
Lecturas relacionadas
- Un mapa estratificado de conceptos de ingeniería de IA y cuándo son importantes — Aprenda qué conceptos de ingeniería de IA determinan si un sistema funciona en absoluto, cuáles son cruciales una vez que se desarrolla para producción y cuáles pueden esperar.
- Gestionando LLM como juez como sistema de producción vivo — Conozca cómo el ciclo de vida de cuatro etapas de Netflix —datos reales, entrenamiento ajustado con criterios específicos, despliegue seguro y monitoreo continuo— mantiene preciso a un LLM en escala.
- Monitoreo de LLM en producción: métricas, calidad, coste y seguridad — SLIs para latencia, errores, tokens, fundamentación y seguridad, además de alertas que detectan un deterioro silencioso de la calidad.