Capítulo 9 — La tríada de evaluación de RAG

Novena entrega del recorrido capítulo por capítulo de LLM Primer III: Enhancing Enterprise AI with RAG. En el que tres fallos distintos colapsan en un único síntoma — y el campo inventa una métrica de tres cabezas que finalmente le dice al equipo qué síntoma es cuál.

Por qué existe este capítulo

Un sistema RAG puede fallar en tres sitios distintos, y desde fuera los fallos parecen idénticos. El retriever trae el contexto equivocado. El modelo ignora el contexto correcto. El modelo honra el contexto pero responde a una pregunta distinta de la que se hizo. Cada equipo en producción ha intentado, en algún momento, arreglar uno de esos fallos mientras medía otro. Este capítulo trata sobre el vocabulario pequeño y testarudo que evita ese error.

Es también un capítulo sobre un cambio. La recuperación de información clásica se evaluaba contra ground truth etiquetada — consultas con documentos correctos conocidos, precisión y recall computados contra las etiquetas. RAG opera en un mundo donde no existen esas etiquetas. Las preguntas son abiertas, las respuestas son generativas, el contexto relevante es el que el modelo necesita en ese momento. La tríada se diseñó para este mundo. Mide consistencia entre etapas, no acuerdo con una referencia.

9.1 Por qué tres señales, no una

El instinto de un equipo nuevo es calificar la respuesta final. El usuario tecleó una pregunta, el sistema produjo una respuesta, o la respuesta es correcta o no lo es. El instinto falla porque la respuesta final es un compuesto de cada etapa, y cuando falla el compuesto no te dice nada sobre qué etapa arreglar. ¿Se perdió el documento correcto? ¿Se recuperó pero se ignoró? ¿Se usó pero se respondió a una pregunta distinta? Tres bugs distintos, tres arreglos distintos, un síntoma indistinguible.

La tríada separa la pipeline en los tres lugares donde la información sobrevive o se pierde. Recuperación, fundamentación, respuesta. Cada uno recibe su propia métrica: Relevancia del Contexto, Fidelidad, Relevancia de la Respuesta. Lo que hace útil a la estructura no es que las tres sean exhaustivas — no lo son — sino que sean independientes. Un sistema puede puntuar bien en una y mal en otra, y cuando lo hace, el equipo sabe dónde mirar. Cuando se cambia el modelo de embedding, la Relevancia del Contexto debería moverse. Cuando se cambia el prompt, la Fidelidad debería moverse. Cuando la métrica que tenía que moverse se mueve, el equipo sabe que el cambio funcionó. Una sola puntuación de extremo a extremo colapsa todo esto en algo que no se puede depurar.

9.2 Relevancia del Contexto — ¿recuperaste el contexto correcto?

La Relevancia del Contexto pregunta si los chunks recuperados son sobre la pregunta, frase por frase, puntuados por un juez LLM. Captura precisión de recuperación — la fracción de la ventana de contexto que se está gastando en material relevante. Una puntuación alta significa que el retriever no está malgastando tokens. Una baja significa que está trayendo ruido, y el modelo paga ese ruido en latencia y en calidad, porque los contextos largos e irrelevantes han demostrado repetidamente degradar la generación.

Lo que la Relevancia del Contexto no captura es el recall — si todos los chunks que el modelo habría necesitado se recuperaron de verdad. Un retriever que trae un chunk perfecto y nada más puntúa perfecto, aunque la respuesta requiriera dos y el segundo se perdiera. El recall es un problema propio, medido contra conjuntos dorados curados donde los documentos que portan la respuesta son conocidos. El capítulo también nombra dos artefactos que vale la pena conocer: el chunking agresivo infla la Relevancia del Contexto sin mejorar necesariamente la respuesta, y promediar sin pesos sobre un top-k fijo puede hacer parecer malo a un retriever cuando los chunks irrelevantes en las posiciones cuatro a diez apenas afectan al modelo.

9.3 Fidelidad — ¿honró el modelo el contexto?

La Fidelidad, a veces llamada Groundedness, hace la pregunta opuesta: de las afirmaciones que produjo el modelo, ¿qué fracción puede sustentarse en el contexto recuperado? El cálculo estándar descompone la respuesta en afirmaciones atómicas y pregunta al juez, para cada una, si el contexto la sustenta. La descomposición es la parte que importa. Una respuesta larga evaluada como un único bloque tiende a puntuarse o totalmente fundamentada o totalmente no fundamentada, con el juez resolviendo hacia la dirección a la que se incline el sentido general. Las afirmaciones atómicas obligan al juez a evaluar cada aseveración por separado — lo que captura el fallo común donde una respuesta mayormente correcta contiene una frase que el contexto nunca sustentó.

El capítulo es honesto sobre la asimetría de la Fidelidad: penaliza la invención pero no la omisión. Un modelo que se niega a responder puntúa perfecto. Un modelo que da una respuesta correcta y bien fundamentada pero deja caer un matiz crucial del contexto también puntúa bien. Es además la métrica que más probablemente saca a la luz un problema de prompt en lugar de un problema de modelo. Cuando la Relevancia del Contexto es alta y la Fidelidad es baja, la respuesta está casi siempre en el system prompt, no en el modelo — las instrucciones son demasiado blandas para mantener al modelo dentro del contexto. Aprieta el prompt antes de culpar al modelo.

9.4 Relevancia de la Respuesta y el cambio sin referencia

La Relevancia de la Respuesta es la más fácil de malinterpretar. No mide corrección, y no mide fundamentación. Mide si la respuesta atiende a la pregunta que se hizo. Una respuesta factualmente correcta que responde a una pregunta ligeramente distinta puntúa mal. Un rechazo educado puntúa mal. El cálculo estándar es una inversión ingeniosa: dada la respuesta, generar las preguntas a las que plausiblemente podría responder, y luego comparar esas preguntas generadas con la original. Si están cerca, la respuesta es certera. Si se alejan, el modelo ha divagado.

La Relevancia de la Respuesta es también donde el cambio a evaluación sin referencia muerde con más fuerza. Ninguna de estas métricas puede computarse comparando contra una respuesta correcta etiquetada — el espacio de respuestas aceptables es infinito y no enumerable. Así que el campo ha convergido en LLM-como-Juez: un modelo de frontera califica cada métrica usando un prompt documentado. La técnica escala. Es barata. Correlaciona aproximadamente con el juicio humano. También tiene modos de fallo bien documentados — sesgo de posición en comparaciones por pares, sesgo de longitud, sesgo por familia de modelos, deriva de calibración tras actualizaciones silenciosas del modelo, y el problema más profundo de que jueces y generadores comparten corpus de entrenamiento y por tanto fallan de forma correlacionada. La defensa no es técnica sino operativa: fija el modelo juez y el prompt, calibra contra un pequeño conjunto etiquetado a mano, enruta una pequeña fracción de salidas juzgadas a revisión humana, y trata cualquier cambio del juez como un evento de re-baselining que invalida las comparaciones históricas.

Lo que prepara el Capítulo 9

La tríada da un vocabulario para qué medir. No dice cómo correr las mediciones de verdad — los prompts para el juez, la lógica de descomposición, la elección de embedding, la tasa de muestreo, los dashboards, las alertas. Nada de eso se construye desde cero. En los últimos dos años ha surgido un puñado pequeño de frameworks para hacer la tríada medible en la práctica, cada uno con sus propias opiniones sobre cómo debería sentirse la evaluación en producción. El Capítulo 10 los recorre uno al lado del otro.

Próximamente — Capítulo 10: Frameworks de evaluación líderes. RAGAS, TruLens, DeepEval y las plataformas de observabilidad — para qué sirve cada uno, dónde terminan las librerías metric-first y empiezan las plataformas de producción, y el Hueco de Evaluación que ninguna ha cerrado aún.