RAG 5: evaluar mejoras sin fabricar evidencia
Cómo compararía dos sistemas con preguntas reales y evidencias revisadas, sin contar fragmentos relacionados como pruebas independientes.
En este artículo
El estudio Taesa enseñó que miles de fragmentos no garantizan miles de observaciones independientes. En la próxima evaluación hay otro riesgo: reemplazar chunks por preguntas sintéticas muy parecidas y conservar el mismo error estadístico. Antes de calcular un intervalo, necesito definir qué población quiero representar y qué unidades generaron esas preguntas.
Construir una referencia que se pueda discutir
Empezaría con preguntas de usuarios y especialistas, registrando tarea, fecha de referencia, permisos y evidencias necesarias. Algunas preguntas admiten varias fuentes equivalentes; otras requieren dos o más pasajes. Incluiría ausencia de información, contradicciones, versiones antiguas y consultas fuera del acceso del usuario. Una respuesta de referencia no debe reducirse a una sola cadena de texto cuando existen alternativas correctas.
Dos revisores pueden examinar una muestra y resolver desacuerdos, conservando el historial de decisiones. Separaría desarrollo y prueba por familias o casos y, cuando la aplicación lo exija, por tiempo. No afirmaría que esa división representa toda la empresa si las preguntas son de conveniencia. La evaluación puede ser útil y aun así tener un alcance limitado.
Medir cada etapa y la respuesta completa
En recuperación mediría recall de evidencias y, si hay relevancia graduada, nDCG. En generación revisaría corrección, completitud, soporte de las afirmaciones y citas. Una cita que existe puede no respaldar la frase. También reportaría respuestas indebidas cuando falta evidencia, rechazos innecesarios, violaciones de acceso, coste y latencia p95. El promedio no debe ocultar un fallo grave en un tipo documental.
EnterpriseRAG-Bench añade conflictos y duplicados a un corpus empresarial sintético; sus documentos aplanados no reproducen las pérdidas de un parser de PDF. EnterpriseRAG, otro trabajo de 2026, combina ruido, lagunas y restricciones de respuesta. Son benchmarks distintos. Ambos ayudan a diseñar casos difíciles, pero ninguno reemplaza documentos reales ni demuestra que un juez LLM sea suficiente para nuestra evaluación.
EnterpriseRAG-Bench: corpus sintético y límites
EnterpriseRAG: restricciones y evidencia insuficiente
Comparar diferencias, respetar grupos
Ejecutaría las variantes sobre las mismas preguntas y calcularía diferencias pareadas. Si se muestrearon casos independientes con varias preguntas dentro, reamostraría casos conservando todas sus preguntas y ambos sistemas. Si una pregunta conecta varios documentos, agrupar por documento puede ser insuficiente: hay que definir casos, familias o un diseño que represente esa dependencia. El bootstrap no corrige por sí solo un muestreo sesgado.
# Design pseudocode: independently sampled cases
for b in range(B):
sampled_cases = sample_cases_with_replacement(case_ids)
# Preserve multiplicity; keep questions and systems paired.
delta[b] = metric(B_system, sampled_cases) - metric(A_system, sampled_cases)
# Declare weighting, interval method and degenerate-replicate policy.No usaría automáticamente percentiles con pocos grupos: el caso Taesa ya mostró subcobertura. Reportaría tamaño y composición de muestra, intervalo, método y límites de calibración. Antes del test fijaría la mejora mínima útil y regresiones inaceptables. Si un reranker gana poco y duplica la latencia, mantener el sistema simple puede ser la decisión correcta.
Caso Taesa: unidad de reamostrado y limitaciones
Descargar scripts, manifiesto y documentación de la revisión