Objeto de evidencia
Estudio reproducible de evaluación RAG
Cuándo un sistema de recuperación debe responder y cuándo debe callarse
Quería que el sistema respondiera solo cuando la búsqueda léxica y la búsqueda densa coincidían en el mismo documento vigente, y que se callara en caso contrario. Dejé fija esa regla, y tres condiciones de éxito, antes de abrir el conjunto de reserva. En el corpus sintético de soporte la regla cumplió las tres. Acertó 17 de las 20 preguntas que respondió, y cubrió 17 de las 22 que tenían respuesta en el corpus. Aun así respondió 3 de 14 preguntas que tendría que haber rechazado. En las 36 preguntas, la decisión fue correcta 28 veces. Esa última cifra es contexto: no era una de las tres condiciones. El estudio no redacta la respuesta. El Explorer es otra demo.
Entrada directa: esta página se sostiene sola. No implica un recorrido de Decision Room desde Home.
Forma, Procedencia y Estado son dimensiones separadas, no una sola insignia.
- Forma
- Investigación
- Procedencia
- SintéticoPúblico
- Estado
- Holdout consumido
- Qué es
- Evidencia de investigación / metodología: benchmark sintético versionado con protocolo fijo y paquete de evidencia SHA-256.
- Pregunta / contexto
- ¿Cuándo debería un sistema RAG responder o diferir ante evidencia de recuperación conflictiva o débil?
- Qué se hizo
- Comparé recuperación léxica/densa/híbrida con un gate de consenso top-1 preregistrado y un holdout desvelado una sola vez.
- Qué se aprendió
- Reglas más estrictas de answer/defer se pueden evaluar de forma reproducible en un holdout sintético; después el holdout queda consumido.
- Qué sostiene aquí
- Credibilidad metodológica del estudio de recuperación. Distinta de Explorer, que es otra demo, con otro corpus, y aquí no está alojada.
- Qué no demuestra
- Rendimiento RAG en producción, madurez comercial, resultados de cliente ni equivalencia con métricas del Explorer. El holdout está consumido, no es validación no vista.
Lo corrí sobre un benchmark sintético, con un conjunto de reserva de 36 preguntas que ya está abierto. Las cifras son de ese benchmark. No son un resultado de producción.
Por qué existe este estudio
Construí este estudio para mirar fallos de recuperación y la decisión de responder o dar un paso atrás. Compara la recuperación léxica y la densa, un híbrido de las dos, y un reordenado que prefiere los documentos vigentes a los obsoletos. El protocolo, y la separación entre desarrollo y conjunto de reserva, se quedó fijo.
La pregunta que estaba probando
Un documento que parece relevante no siempre es motivo para responder. Quería una regla más estricta para los casos incómodos: la búsqueda léxica y la densa no coinciden, compiten un documento vigente y uno obsoleto, la pregunta pide una aclaración, o la evidencia es demasiado floja para responder con seguridad.
Qué incluyó el estudio
- Un baseline de recuperación léxica BM25.
- Un baseline de recuperación densa MiniLM.
- Fusión reciprocal-rank (RRF) con pesos iguales.
- Reranking status-aware con prioridad a documentos actuales.
- Análisis de consenso, riesgo selectivo y separabilidad de señales.
- Un benchmark sintético versionado con partición development/holdout congelada.
- Un gate de consenso top-1 y tres criterios de éxito registrados antes del holdout.
- Una evaluación única unblinded del holdout.
- Informes deterministas y un registro de artefactos SHA-256.
Qué mantuve fijo
- Utilicé solo un benchmark sintético: sin tráfico de producción y sin corpus empresarial real.
- El holdout permaneció fijo en 36 consultas, con una composición fija answer, clarify y abstain.
- Congelé las reglas del gate y los tres criterios de éxito antes de cualquier evaluación del holdout.
- Mantuve separados development y holdout hasta la evaluación única.
- El holdout está unblinded, por lo que no puede reutilizarse como evidencia no vista.
- No reajusto el gate en este benchmark después de observar el holdout.
- La regeneración de integridad solo comprueba reproducibilidad; no crea nueva evidencia de evaluación.
- Estos resultados no respaldan afirmaciones a nivel poblacional ni de despliegue en producción.
Cómo funciona el gate de respuesta o diferimiento
- 01
Recuperación léxica
BM25 aporta evidencia de términos exactos y solapamiento de tokens.
- 02
Recuperación densa
Los embeddings MiniLM fijados aportan evidencia semántica de recuperación.
- 03
Fusión híbrida
La reciprocal-rank fusion combina rankings léxicos y densos con pesos iguales.
- 04
Reranking status-aware
Se priorizan documentos actuales frente a evidencia obsoleta.
- 05
Gate de consenso top-1
El sistema responde solo cuando BM25, la recuperación densa y el ranking final con prioridad a documentos actuales coinciden en el mismo primer documento; en caso contrario, difiere.
Cómo realicé el estudio
- 01
Establecer baselines
Empecé con baselines de recuperación léxica BM25 y densa MiniLM sobre los corpora sintéticos.
- 02
Añadir fusión y estado documental
Combiné rankings léxicos y densos con reciprocal-rank fusion de pesos iguales y apliqué reranking status-aware con prioridad a documentos actuales.
- 03
Analizar señales de fallo
Examiné fallos de consenso, riesgo selectivo y separabilidad de señales para ver cuándo la evidencia de recuperación bastaba para responder.
- 04
Congelar el benchmark
Construí un benchmark sintético versionado con una partición development/holdout congelada antes de la evaluación final.
- 05
Preregistrar el gate y los criterios
Registré el gate de consenso top-1 y tres criterios de éxito antes de cualquier acceso al holdout.
- 06
Evaluar una sola vez
Ejecuté una evaluación única unblinded del holdout sin cambiar después el gate ni los umbrales.
- 07
Preparar el paquete de evidencia
Ensamblé informes JSON deterministas y un paquete de estudio versionado. La generación no forma parte de este estudio.
Qué produje
- Corpora sintéticos versionados.
- Una implementación tipada de recuperación y evaluación.
- Informes JSON deterministas.
- Un artefacto de preregistro.
- Un informe de la evaluación única del holdout.
- Un informe final del estudio.
- Un paquete de estudio versionado. La generación no está implementada.
- Comprobaciones automatizadas de integridad y reproducibilidad.
- Un paquete de estudio versionado con verificación SHA-256.
Tecnologías
- Python
- uv
- pytest
- BM25
- sentence-transformers
- all-MiniLM-L6-v2
- reciprocal-rank fusion
- SHA-256 artifact verification
Qué mostró el benchmark
Resultado de holdout sintético preregistrado
Criterios de éxito congelados
PASS 3/3
PASS 3/3 significa que se superaron los tres criterios preregistrados en el holdout de 36 consultas: 17/20, 17/22 y 3/14. Esos tres criterios son los únicos criterios de éxito congelados. Congelé el gate y los umbrales antes de ver el holdout y no los cambié después.
Métrica de holdout sintético
Precisión de consultas respondidas
17/20 = 0.850
El umbral congelado exigía al menos 0.75.
Métrica de holdout sintético
Cobertura de consultas que admiten respuesta
17/22 = 0.773
El umbral congelado exigía al menos 0.70.
Métrica de holdout sintético
Tasa de respuesta indebida
3/14 = 0.214
El umbral congelado permitía como máximo 0.50 para consultas en las que se esperaba diferir.
Métrica descriptiva de holdout sintético
Exactitud de decisión
28/36 = 0.778
28/36 = 0.778 es contexto descriptivo reportado junto con precisión, cobertura y errores de diferimiento. No fue uno de los tres criterios de éxito congelados.
Evidencia de reproducibilidad
Paquete de evidencia
La generación no está implementada
Benchmark sintético. El holdout está desvelado y no puede reutilizarse como no visto. No son métricas de Explorer ni un resultado de cliente.
Qué no demuestran los resultados
- Se trata de un único benchmark sintético con un holdout fijo y pequeño de 36 consultas.
- La composición answer, clarify y abstain estaba fijada.
- No evalué un corpus empresarial real ni tráfico real de soporte.
- El sistema no produce una probabilidad calibrada ni una puntuación de confianza.
- No evalué la generación de respuestas.
- Tres consultas abstain fueron respondidas indebidamente.
- Se difirieron cinco consultas que admitían respuesta.
- No hay evidencia de generalización a otros corpora, dominios o idiomas.
- El holdout está unblinded y no puede reutilizarse como evidencia no vista.
- Estos resultados no muestran rendimiento en producción ni corrección garantizada de respuestas.
Qué necesitaría antes de utilizarlo con datos reales
- Antes de utilizar este enfoque con datos reales, crearía un nuevo holdout representativo.
- Estimaría la prevalencia y el coste de las respuestas indebidas y de los diferimientos innecesarios.
- Definiría el ciclo de vida documental y la responsabilidad sobre el estado de los documentos.
- Mediría la calidad de recuperación, el comportamiento de diferimiento, la latencia y el coste.
- Definiría controles de acceso para material sensible.
- Incorporaría escalado humano para casos diferidos o inciertos.
- Evaluaría la generación de respuestas por separado del consenso de recuperación.
- Si el gate cambiara, exigiría nuevos datos confirmatorios antes de confiar en él.
Dónde puede ayudar este método
- Diseño de retrieval para responder o abstenerse, dentro del techo del estudio público. No es assurance empaquetado.
- Diseño de políticas de capacidad de respuesta y abstención.
- Análisis de respuesta indebida y de conflictos de evidencia.
- Diseño de evaluación sintética y representativa.
- Recuperación de conocimiento status-aware.
- Diseño de protocolos de evaluación.
- Informes técnicos de evidencia y decisión.
Evidencia del proyecto
- Ver el repositorio público
Código fuente, corpora sintéticos, tests, informes y controles de reproducibilidad del estudio.
Estudio, demo y siguientes pasos
Ver Sistemas de recuperación y evaluación
Demo interactiva complementaria
RAG Explorer es una demo interactiva separada que utiliza su propio corpus sintético. No utiliza el holdout del estudio ni reproduce sus resultados o métricas.
Existe otra demo, con un corpus distinto, que no reproduce las cifras de este estudio. Actualmente no está disponible públicamente.
Una cita puede estar obsoleta
Un pasaje recuperado puede ser una cita real y, aun así, no ser el que conviene usar. Si un documento más nuevo lo sustituyó, una respuesta fiel al pasaje viejo está anclada y sigue desfasada. El estudio trata de esa decisión. No redacta la respuesta.
Responder o abstenerse es una de tres preguntas separadas. Las otras dos son si una configuración supera una barra fijada antes, y si un cambio posterior empeora la salida. Evaluar el texto de una respuesta generada sería otro trabajo. Hoy estas piezas no forman un sistema.
| Decisión de la compuerta | Respondió | Se abstuvo |
|---|---|---|
| Se esperaba respuesta | 17 | 5 |
| Se esperaba abstenerse | 3 | 11 |
36 consultas de holdout. Compuerta top-1, versión 1.0.0, puntuada una vez. Filas: comportamiento esperado. Columnas: decisión de la compuerta.
17 es respuesta esperada y dada. 5 es respuesta esperada y, sin embargo, abstención: abstenciones indebidas. 3 es abstención esperada y, sin embargo, respuesta: respuestas indebidas. 11 es abstención esperada y cumplida. 17 + 5 + 3 + 11 = 36.
Respuestas cuando se esperaba abstenerse
Cada panel es un corte y una regla distintos. No son tres medidas del mismo conjunto.
12 / 14
36 consultas de desarrollo. Regla de consenso a profundidad 3. De las 14 de las que se esperaba abstenerse, respondió en 12. Esta regla no se puntuó en el holdout.
7 / 14
Las mismas 36 consultas de desarrollo, con otra regla: la compuerta top-1. De las 14 de abstención esperada, respondió en 7. Este corte sirvió para elegir la regla. No es el holdout.
3 / 14
Otras 36 consultas, el holdout. Compuerta top-1, versión 1.0.0. De las 14 de abstención esperada, respondió en 3.
- BM25
- Dense MiniLM
- Hybrid RRF
- Status-aware RRF
| Proporción de 22 consultas con respuesta esperada | @1 | @3 | @5 |
|---|---|---|---|
| BM25 | 0.000 | 0.636 | 0.773 |
| Dense MiniLM | 0.045 | 0.545 | 0.682 |
| Hybrid RRF | 0.000 | 0.455 | 0.636 |
| Status-aware RRF | 0.000 | 0.000 | 0.000 |
Corte de desarrollo, solo las 22 consultas de las que se esperaba respuesta. La cifra es la proporción en la que un documento obsoleto aparece dentro de ese corte del ranking. @5 significa dentro de los cinco primeros, no el quinto puesto aislado.
Status-aware RRF es el rerank que prioriza el documento vigente. En este corte queda en 0.000 dentro de @1, @3 y @5. No es la precisión de la compuerta ni un resultado del holdout.