Evaluar recuperación, fidelidad y utilidad

Una demo que responde bien a cinco preguntas no demuestra que el sistema sea fiable. RAG es una cadena de componentes: corpus, ingestión, filtros, recuperación, reranking, generación, citas e interfaz. Si solo mides la respuesta final, sabrás que algo falla pero no dónde.

La evaluación debe separar capas y volver a unirlas en métricas de negocio y riesgo.

Construye un conjunto de evaluación versionado

Parte de las preguntas recopiladas al delimitar el caso. Para cada una registra, cuando sea posible:

• pregunta;
• usuario o grupo;
• contexto necesario;
• fuente o fuentes esperadas;
• pasajes relevantes;
• respuesta aceptable;
• condiciones que deben aparecer;
• comportamiento de abstención;
• riesgo;
• tipo de pregunta.

Incluye preguntas difíciles y negativas. Un benchmark compuesto solo por preguntas fáciles crea una visión artificialmente optimista.

Conserva versiones. Cuando cambie corpus o producto, añade nuevos casos sin borrar el histórico.

Mide el corpus y la ingestión

Antes del retriever, comprueba:

• documentos esperados presentes;
• versiones correctas;
• permisos propagados;
• chunks activos;
• páginas fallidas;
• contenido duplicado;
• fuentes retiradas realmente ausentes.

Si el pasaje correcto no existe en el índice, no tiene sentido ajustar el generador.

Mide recuperación

Para preguntas con fuente esperada puedes evaluar si el documento o pasaje aparece en top-k y en qué posición. Algunas métricas posibles son recall@k, precision@k, MRR o medidas específicas del producto.

No conviertas una métrica en objetivo universal. En una pregunta donde perder una política crítica es inaceptable, priorizar recall puede ser distinto a un buscador donde el usuario revisa diez resultados.

Segmenta por tipo de pregunta, dominio y riesgo.

Mide la respuesta por dimensiones separadas

Una respuesta puede ser relevante y no estar respaldada. Puede estar respaldada y omitir una condición. Puede ser correcta pero inútil para la tarea.

Evalúa al menos cuando proceda:

• groundedness o fidelidad al contexto;
• relevancia;
• completitud;
• corrección frente a referencia;
• calidad de citas;
• preservación de condiciones;
• abstención;
• ausencia de contenido no autorizado.

Los evaluadores automáticos pueden ayudar a escalar, pero sus puntuaciones son instrumentos, no verdad absoluta. Conserva casos revisados por personas y reglas deterministas donde sea posible.

Añade métricas de sistema

El usuario también experimenta:

• latencia;
• errores;
• disponibilidad;
• coste;
• tasa de abstención;
• tasa de consultas sin resultados;
• carga de revisión humana.

Una configuración que mejora groundedness un poco y triplica latencia puede no ser adecuada para la tarea. La evaluación debe reflejar el servicio completo.

Analiza por causa

Clasifica cada fallo:

corpus → chunking → metadato/filtro → consulta → recuperación → reranking → generación → cita → permiso → interfaz

Esta taxonomía permite corregir la capa causal.

Si la fuente correcta nunca se recuperó, cambiar el prompt de respuesta es una intervención mal dirigida. Si se recuperó pero el modelo ignoró la excepción, entonces sí estás ante un problema de generación o formato.

Define umbrales por riesgo

No uses una media global para ocultar fallos críticos. Separa preguntas de alto impacto.

Puedes aceptar más abstención en un segmento sensible si evita respuestas sin evidencia. Puedes permitir una respuesta más exploratoria en una base de conocimiento no crítica. La decisión debe estar documentada.

El NIST AI RMF insiste en que las mediciones dependan del contexto y se acompañen de conjuntos realistas representativos del uso esperado. Es un marco voluntario, no una regla de cumplimiento universal, pero el principio de evaluación contextual es útil para este diseño.

Combina evaluación determinista, humana y asistida por modelos

No todas las dimensiones necesitan el mismo evaluador.

Puedes medir de forma determinista si la fuente esperada está en top-k, si una cita apunta a un ID existente o si se produjo una filtración entre tenants. La revisión humana es adecuada para utilidad, interpretación de condiciones y casos donde el contexto empresarial importa. Los evaluadores basados en modelos pueden ayudar a escalar dimensiones como groundedness o relevancia, pero requieren calibración y no sustituyen todas las referencias humanas.

Construye una pequeña muestra «gold» revisada con especial cuidado y úsala para comprobar que los evaluadores automáticos se comportan de forma razonable.

Mide regresión, no solo calidad absoluta

Cuando cambias chunking, modelo o ranking, compara contra una versión anterior. Una mejora global puede ocultar pérdidas en preguntas críticas.

Mantén:

• baseline;
• versión candidata;
• diferencias por pregunta;
• cambios por segmento;
• nuevas regresiones;
• mejoras confirmadas.

Esto convierte la evaluación en una herramienta de ingeniería y no en una nota de marketing.

Ejercicio: cuadro de evaluación

Construye una tabla con:

• versión del sistema;
• versión del corpus;
• segmento;
• retrieval@k;
• groundedness;
• completitud;
• citas válidas;
• abstención correcta;
• incidentes de permiso;
• latencia p50/p95 si dispones de ella;
• coste medio;
• utilidad humana;
• principales causas de fallo.

Define antes del piloto qué métricas bloquean despliegue y cuáles sirven solo para diagnóstico.

Criterio de salida

Al finalizar, debes contar con un sistema de evaluación que pueda decir no solo «la respuesta fue mala», sino qué componente falló y qué riesgo introduce. A partir de aquí la operación podrá detectar regresiones cuando cambien documentos, modelos o configuraciones.