Ya lo montaste. Levantaste tu RAG sobre tu documentación interna, le hiciste tres preguntas, contestó bonito, y lo enseñaste en la junta. Todos aplaudieron. Y aquí está la pregunta incómoda que nadie hizo en esa junta: ¿cómo sabes que no está alucinando con cara seria?
Porque eso es exactamente lo que un buen modelo hace cuando no sabe: te contesta con la misma seguridad, la misma prosa pulida y el mismo aplomo con que te da un dato correcto. La confianza del tono no tiene ninguna correlación con la verdad del contenido. Y un RAG que suena convincente el 100% del tiempo pero acierta el 70% es, para un negocio, peor que no tener nada: porque le crees.
Evaluar el RAG es el eslabón que casi todos saltan. Montar es divertido —hay tutoriales, hay demos, hay dopamina—. Medir es aburrido, no sale en el video de YouTube, y obliga a admitir que tu juguete nuevo falla. Por eso este artículo va de justo eso: cómo se mide un RAG sin engañarte a ti mismo.
Un RAG falla en dos lugares distintos
El error de principiante es tratar al RAG como una caja negra: "contestó mal, algo está roto". Pero un RAG tiene dos etapas, y cada una puede fallar por su cuenta. Si no separas dónde falló, terminas moviendo perillas a ciegas.
Compuerta 1 — el retrieval: ¿trajo lo correcto?
Antes de que el modelo escriba una sola palabra, el sistema fue a tu base de conocimiento y recuperó unos fragmentos. Si trajo los fragmentos equivocados, no hay modelo en el mundo que salve la respuesta: le pediste que cocine con los ingredientes incorrectos. Esto se mide sin IA, con métricas viejas y honestas de recuperación de información:
- Recall@k: de los fragmentos que de verdad contenían la respuesta, ¿cuántos aparecieron entre los primeros k que trajo? Es la pregunta de "¿se le escapó lo importante?".
- Precision@k: de los k que trajo, ¿cuántos eran relevantes? Mide cuánta basura le estás metiendo al contexto (y la basura confunde al modelo y cuesta tokens).
- MRR (rango recíproco medio): ¿qué tan arriba salió el primer fragmento bueno? Porque no es lo mismo que la respuesta correcta salga en el puesto 1 que en el puesto 9.
Lo bonito de esta compuerta: es determinista y barata. No necesitas otro modelo para calcularla, solo tu golden set. Y si aquí sale mal, ya sabes que el problema es tu chunking, tu embeddings o tu reranking —no el modelo—.
Compuerta 2 — la generación: ¿la respuesta se apega a lo que trajo?
Supongamos que el retrieval trajo los fragmentos correctos. El modelo todavía puede arruinarlo de dos maneras: inventando cosas que no están en el contexto (la alucinación clásica), o contestando algo que no era lo que preguntaste. Las dos métricas centrales:
- Fidelidad (faithfulness o groundedness): ¿cada afirmación de la respuesta está soportada por los fragmentos recuperados? Esta es la métrica antialucinación por excelencia. Una respuesta puede ser verdadera en el mundo pero infiel al contexto —y eso también es un problema, porque significa que el modelo está jalando de su memoria, no de tus datos—.
- Relevancia de la respuesta: ¿contestó la pregunta que le hiciste, o se fue por la tangente con datos correctos pero inútiles?
El golden set: el trabajo aburrido que lo sostiene todo
Nada de lo anterior funciona sin un golden set: un conjunto de preguntas reales de tu operación, cada una con su respuesta correcta y —idealmente— con los fragmentos de documento que la sustentan. Cincuenta a cien preguntas bien elegidas ya te dicen muchísimo. Esta es la parte que nadie quiere hacer porque es trabajo humano, manual, de gente que conoce el negocio. No hay atajo: un RAG sin golden set no se está evaluando, se está admirando.
Y una advertencia de soberanía: ese golden set contiene tus preguntas reales y tus respuestas reales —o sea, tu conocimiento de negocio destilado—. Es de los activos más sensibles que vas a producir. No vive en la laptop de nadie ni en una hoja de cálculo en la nube de un tercero.
El juez automático (y su asterisco)
Calificar fidelidad y relevancia a mano en cada corrida no escala. La técnica de moda es LLM-como-juez: usar un modelo para calificar las respuestas de otro. Funciona sorprendentemente bien, y hay frameworks abiertos que lo empaquetan. Pero trae tres asteriscos que conviene decir en voz alta:
- El juez también se equivoca. Hay que calibrarlo: comparar sus notas contra un puñado de juicios humanos hasta confiar en que correlacionan. Un juez sin calibrar es cambiar una caja negra por dos.
- El juez tiene sesgos conocidos —premia respuestas largas, se autoprefiere—. Se administran, no se ignoran.
- Para que el eval sea soberano, el juez corre en casa también. No tiene sentido montar un RAG local para no mandar tus datos afuera y luego mandárselos, pregunta por pregunta, a una API de terceros para que los califique. El juez local puede ser más modesto —un modelo corriendo con Ollama alcanza para esto—.
Se mide siempre, no una vez
El error final es tratar el eval como un examen de admisión: pasó una vez, ya quedó. No. Cada cosa que toques después —cambiar el modelo, ajustar el chunking, editar el prompt, actualizar los documentos— puede mejorar una métrica y romper otra sin que te enteres. A eso se le llama regresión, y la única defensa es correr el golden set completo en cada cambio, como quien corre pruebas de software. El golden set deja de ser un examen y se vuelve tu red de seguridad.
El resumen honesto
Un RAG que no se mide no es un sistema, es una demo con suerte. Y medirlo no es glamuroso: es un golden set armado a mano, dos compuertas —retrieval y generación—, un juez calibrado corriendo en tu propia infraestructura, y la disciplina de repetirlo en cada cambio. Es exactamente el tipo de trabajo poco fotogénico que separa un piloto que impresiona en la junta de un sistema en el que de verdad puedes basar una decisión. La buena noticia: cuando lo tienes, dejas de creerle al tono de tu RAG y empiezas a creerle a los números —que es lo único que se puede auditar—.