EN·ES·PT
Guía de campo · evaluación de RAG

Cómo probar de verdad un sistema RAG.

La mayoría de las demos de generación aumentada por recuperación se califican a ojo: alguien lee tres respuestas, parecen plausibles, se lanza. Eso no es evaluación — es optimismo. Un sistema RAG falla de maneras específicas y comprobables: cita el fragmento equivocado, inventa un hecho que el contexto recuperado nunca dijo, o responde con seguridad cuando debería haber dicho «eso no lo tengo». Cada uno de esos modos de fallo tiene una comprobación que lo atrapa. Esta es la lista de verificación, y está fundamentada en un panel que construí donde la cobertura de citas es del 100 % por construcción — no hay ninguna ruta de código que pueda generar una frase sin citar.

Prueba: la implementación 100 % citada → Pruebe la demo de evaluación en vivo → Certificado: ISTQB CT-AI
5
dimensiones que toda evaluación de RAG debe cubrir
100%
cobertura de citas en la implementación de referencia
0
rutas de generación sin citar (por construcción)
1
demo en vivo que puede calificar usted mismo

La cifra del 100 % es estructural, no una puntuación de benchmark: el pipeline no puede emitir una frase de respuesta que no esté ligada a una fuente recuperada. Verifíquelo en la implementación case-studies.html.

La lista de verificación · qué mide una evaluación de RAG real

Cinco cosas, o estás adivinando.

Un arnés de evaluación de RAG con aprobado/reprobado tiene que puntuar las cinco sobre un conjunto de preguntas fijo — idealmente un conjunto de referencia con fuentes correctas conocidas — y bloquear el lanzamiento según los resultados. Omita una y habrá dejado toda una clase de fallos sin probar.

  • 01Cobertura de citas. ¿Qué fracción de las afirmaciones de la respuesta lleva una cita que realmente las respalda? No «tiene una nota al pie» — el fragmento citado debe contener la afirmación. Objetivo: que cada frase de peso sea rastreable hasta una fuente recuperada.
  • 02Precisión y exhaustividad de la recuperación. ¿El recuperador trajo los fragmentos que contienen la respuesta (exhaustividad) y cuánto ruido vino con ellos (precisión)? Un generador perfecto no puede salvar a un recuperador que nunca trajo el pasaje correcto.
  • 03Fundamentación / fidelidad. ¿Cada afirmación se deriva del contexto recuperado, o el modelo añadió «conocimiento» del preentrenamiento que no está en las fuentes? Aquí es donde se esconde la alucinación incluso cuando hay citas.
  • 04Abstención cuando no hay evidencia. Cuando el corpus genuinamente no contiene la respuesta, ¿el sistema lo dice — o fabula? Pruébelo con preguntas fuera del corpus y exija una respuesta explícita de «evidencia insuficiente».
  • 05Latencia y costo por consulta. Recuperación + reordenamiento + generación suman milisegundos y tokens cada uno. Mide la latencia p50/p95 y el costo por consulta, porque un sistema preciso que nadie puede permitirse ejecutar sigue siendo un sistema fallido.
Flujo de evaluación de RAG Una consulta de usuario fluye hacia la recuperación, que devuelve fragmentos ordenados por relevancia. Una barrera de fundamentación luego produce una respuesta fundamentada y citada cuando la evidencia es suficiente, o se abstiene cuando no lo es. Consulta pregunta del usuario Recuperación embed + búsqueda Fragmentos ordenados rerank top-k Barrera de evidencia Fundamentada + citada Abstención sin evidencia suficiente insuficiente

La barrera lo es todo. Las respuestas solo salen cuando la evidencia recuperada respalda cada afirmación; de lo contrario, el sistema se abstiene en vez de fabular. Eliminar la rama de abstención es la causa más común de un RAG «seguro pero equivocado».

La matriz · modo de fallo → la comprobación que lo atrapa

Cada forma en que RAG se rompe, y su prueba.

Modos de fallo de RAG mapeados a la comprobación de evaluación que atrapa cada uno
Modo de falloLo que ve el usuarioLa comprobación que lo atrapa
Afirmación sin citarUna frase segura sin ninguna fuente que pueda verificar.Cobertura de citas
Cita al fragmento equivocadoUna nota al pie que apunta a un pasaje que no respalda la afirmación.Derivación cita → afirmación
Recuperación omitida«No lo sé» cuando la respuesta estaba en el corpus desde el principio.Exhaustividad de recuperación
Recuperación ruidosaLa respuesta se desvía porque fragmentos irrelevantes saturaron la ventana de contexto.Precisión de recuperación
Hecho alucinadoUn detalle plausible que las fuentes en realidad nunca contuvieron.Fundamentación / fidelidad
Fabulación seguraUna respuesta completa a una pregunta que el corpus no puede respaldar.Abstención cuando no hay evidencia
Índice desactualizadoLa respuesta de ayer al documento de hoy.Comprobación de frescura / reindexación
Precisión inasequibleRespuestas correctas que tardan 8 segundos y cuestan dinero real cada una.Latencia y costo por consulta

Un arnés serio ejecuta toda esta matriz sobre un conjunto de referencia fijo en cada cambio, y hace fallar la compilación cuando alguna fila empeora — la misma disciplina de bloqueo ante regresiones que hay detrás de mi trabajo de QA.

La prueba · cobertura de citas por construcción

100 % citado, porque no hay otra ruta.

La decisión de diseño

En lugar de generar prosa y confiar en que las citas encajen, el pipeline vincula cada segmento de respuesta emitido al fragmento recuperado del que proviene. Si una afirmación no tiene un fragmento de respaldo, no se escribe — el sistema se abstiene en ese punto en vez de inventar uno.

Por qué es estructural

La cobertura de citas no es una puntuación que haya perseguido a base de ajustes — es una propiedad de la ruta de código. No hay ninguna ruta de generación sin citar que pueda sufrir una regresión. Esa es la diferencia entre «normalmente citamos» y «no podemos no citar».

Míralo funcionando

El caso de estudio del panel de investigación recorre la implementación. Y la propia demo de evaluación en vivo del sitio le permite pegar una respuesta de IA y verla calificada frente al mismo tipo de comprobaciones en tiempo real.

▸ ver la implementación 100 % citada ▸ probar la demo de evaluación en vivo la cobertura es estructural · verifíquelo usted mismo
Por qué aceptar esta lista de verificación de mí

Bloqueo mis propios lanzamientos con evidencia.

La disciplina de abstenerse y citar de arriba no es teoría. Mi QA OS detectó 15 CVE de gravedad alta/crítica en su propio conjunto de dependencias, bloqueó su propio lanzamiento y se parcheó el mismo día hasta alcanzar 3.759 pruebas aprobadas en 13 de 13 barreras. Mi suite de regresión de SDET ejecuta 37 de 37 especificaciones, cero fallos intermitentes, en 15,3 segundos. Todo este sitio ejecuta su propio QA — más de 100 comprobaciones, limpio en axe — e incluye una demo de evaluación en vivo que puede romper usted mismo.

15 CVE atrapados, lanzamiento bloqueado 3.759 pruebas · 13/13 barreras 37/37 especificaciones · 0 intermitencias · 15,3 s ISTQB CT-AI ISTQB Test Automation Engineer
▸ los CVE detectados ▸ la corrección del mismo día ▸ la suite 37/37 ↗
Relacionado · más sobre probar la IA
Contratar a un ingeniero de QA de IA →Consultor de evaluación de LLM →Pruebas de agentes de IA →Reducir la intermitencia de pruebas →

¿Le preocupa que su sistema RAG esté adivinando?

Reserve una llamada y le construiré un arnés de evaluación que puntúe las cinco dimensiones y bloquee sus lanzamientos — o califique la respuesta de su IA en vivo, ahora mismo.

Reservar una llamada → probar la demo de evaluación en vivo → ver la implementación 100 % citada →
ejemplo práctico

Lo que la barrera atrapa realmente.

Un fallo real de RAG no es un cierre inesperado — es una respuesta segura y equivocada que se lee bien. Aquí hay una que la evaluación atrapa:

Consulta

«¿Cuál es nuestra ventana de reembolso para los planes empresariales?»

✕ recuperó el fragmento equivocado

La mejor coincidencia fue la política de consumidor («devolución de dinero en 30 días»). El modelo respondió «Sí — 30 días» — fluido, seguro y equivocado para el ámbito empresarial. Un humano lo lee por encima y lo lanza.

✓ la barrera lo atrapa, luego se corrige

La puntuación de fidelidad detecta que la respuesta no está fundamentada en una fuente empresarial — reprueba la barrera de citas. La recuperación se ajusta para traer los términos del formulario de pedido; la respuesta corregida cita la cláusula correcta.

El punto: la respuesta equivocada se veía idéntica en calidad a la correcta. Solo una comprobación de fundamentación las distinguió.

preguntas frecuentes

Preguntas, respondidas.

¿En qué se diferencia probar un RAG de probar un LLM simple?
RAG tiene dos superficies de fallo: la recuperación (¿trajo el contexto correcto?) y la generación (¿respondió con fidelidad y lo citó?). Debe medir ambas — una respuesta segura basada en el fragmento equivocado sigue siendo incorrecta.
¿Cómo se mide la fidelidad y la alucinación?
Cada respuesta se puntúa frente a su contexto recuperado con un LLM como juez, más comprobaciones deterministas de citas, de modo que una respuesta que no está fundamentada en una fuente real falla incluso cuando se lee bien.
¿Puede ejecutarse la evaluación de RAG en CI?
Sí. La suite bloquea las fusiones — un cambio de recuperación o de prompt que reduzca la cobertura de citas se pone en rojo antes de llegar a producción.
¿Qué obtenemos al final?
Una suite de evaluación de RAG calificada en su repositorio, un panel puntuado, una barrera en CI y un runbook que su equipo puede operar.
¿Cuál es la diferencia entre cobertura de citas y fundamentación?
La cobertura de citas pregunta si la respuesta llega a citar sus fuentes; la fundamentación pregunta si esas fuentes citadas realmente respaldan cada afirmación. Una respuesta puede citar un fragmento y aun así malinterpretarlo — por eso ambas se puntúan por separado.
¿Qué métricas de recuperación mide — precisión y exhaustividad del contexto?
Precisión del contexto (¿los fragmentos recuperados correspondían?) y exhaustividad del contexto (¿la recuperación omitió un fragmento que la respuesta necesitaba?). Ambas se ejecutan contra un conjunto de preguntas etiquetadas, de modo que un cambio en el recuperador mueve un número en lugar de una impresión.
¿Corrige el pipeline de recuperación o solo lo mide?
La medición va primero, pero la evaluación apunta directamente a la corrección — segmentación, embeddings, reordenamiento o el prompt. Puedo implementar esos cambios y volver a ejecutar la suite para demostrar la mejora.
¿Cómo evita que el modelo invente hechos?
Cada afirmación se contrasta con el contexto recuperado, y las respuestas sin una fuente de respaldo no superan la calificación. Junto con una prueba de abstención, el sistema se puntúa por decir «no lo sé» en lugar de adivinar.
¿Esto funciona con mi base de datos vectorial y mi modelo de embeddings?
Sí — la evaluación se sitúa por encima de su stack y trata la recuperación como una caja negra, de modo que cualquier base de datos vectorial o modelo de embeddings funciona. Cambiar cualquiera de los dos se convierte en un experimento medible en lugar de un cambio a ciegas.
¿Qué entregables recibo de una evaluación de RAG?
Una suite de evaluación calificada en su repositorio, un panel puntuado que cubre recuperación y fundamentación, una barrera en CI que bloquea las regresiones y un runbook que su equipo puede operar sin mí.