Si su sistema RAG no tiene eval set, cada cambio de prompt es un release basado en sensaciones. La buena noticia: puede construir un eval set útil en una semana. No uno perfecto — uno útil. Lo perfecto es la trampa que impide a los equipos tener evals en absoluto.
Esta es la receta que usamos en engagements donde el cliente tiene de 0 a 5 evals el día uno y necesita 200 al final de la semana.
La forma
Quiere tres cosas:
- Un corpus congelado — los documentos reales sobre los que recupera su sistema, fijados en un momento puntual del tiempo.
- 200 preguntas que un usuario real podría hacer, con respuestas y citas de referencia.
- Un conjunto held-out — 30 de esas 200, bajo llave, nunca usadas para ajustar nada.
El conjunto held-out es el más importante y el que más veces se omite. Volveremos a él.
Día 1–2: extraer preguntas reales
Sáltese los workshops de "¿qué preguntarían los usuarios?". Producen preguntas que ningún usuario ha hecho realmente. Vaya a sus fuentes:
- Tickets de soporte que mencionen cualquier tema que cubre el RAG.
- Logs de búsqueda de su barra de búsqueda actual, si tiene una.
- Canales de Slack donde la gente hace la pregunta internamente.
- Los logs de chat de su sistema LLM actual, si tiene uno en marcha.
Apunte a 250 preguntas en bruto. Deduplique, normalice el fraseo, descarte las obviamente fuera de alcance. Acabará en ~200.
Día 3: etiquetar por dificultad y tema
Clasifique cada pregunta:
- Dificultad: trivial (la respuesta está en un párrafo), media (la respuesta requiere sintetizar de 2 a 3 documentos), difícil (requiere entender un procedimiento o una regla).
- Área temática — normalmente de 5 a 15 cubos, según su dominio.
- Bandera adversarial — preguntas diseñadas para disparar modos de fallo conocidos (fuera de alcance, información contradictoria, información recientemente actualizada).
Quiere una mezcla. Una suite que sea 90% preguntas triviales le dirá que su sistema es genial, y desplegará una regresión porque los casos medios y difíciles se rompieron.
Día 4: ground truth
Para cada pregunta necesita:
- La respuesta esperada — escrita, de 1 a 3 frases, la respuesta que daría un experto del dominio.
- Los pasajes de apoyo — punteros (IDs de documento, rangos de líneas, IDs de chunk) a las partes del corpus que deberían recuperarse para responder a la pregunta.
Esta es la parte lenta. Planifique ~3 minutos por pregunta = ~10 horas para 200 preguntas. Dos personas en paralelo, media semana. Use un experto del dominio.
Vale la pena. Esta es la parte que convierte "el LLM dijo algo plausible" en "el LLM citó la fuente correcta y obtuvo la respuesta correcta".
Día 5: baselines + métricas
Ejecute su sistema actual (o un stub si no tiene uno) contra las 170 preguntas visibles. Registre:
- Retrieval@k: ¿incluían los top-k chunks recuperados los pasajes de apoyo esperados?
- Corrección de la respuesta: calificada por un juez LLM contra la respuesta esperada, con la referencia held-out. Calibre el juez contra ~30 calificaciones humanas para asegurarse de que no se limita a aprobar por sello.
- Precisión de citas: del conjunto de citas devueltas, ¿qué fracción apoya realmente la afirmación?
Ya tiene baselines. Todo cambio futuro de prompt o de retrieval aparecerá como un delta sobre estas.
El conjunto de "no optimizar contra esto"
Las 30 preguntas held-out existen por una razón: pillarse a uno mismo.
Todo equipo que construye un eval set acaba ajustando el sistema contra el eval set. Nueva revisión de prompt, ejecutar evals, la puntuación subió, deploy. Tres meses después, su puntuación dentro de la suite es del 95% y la satisfacción del usuario sigue sin moverse porque ha estado haciendo overfitting.
Las 30 preguntas held-out se ejecutan solo durante chequeos trimestrales de salud. Si retroceden mientras el resto de la suite mejora, esa es la alarma de humo del overfitting. Son un control sobre el control.
No las mire. No las amplíe. No las sustituya por equivalentes. Guárdelas bajo llave.
Lo que esto le aporta
- Una señal reproducible que vigila los cambios de prompt y de retrieval.
- Un baseline con el que comparar al evaluar nuevas versiones de LLM.
- Una respuesta defendible a "¿cómo sabe que su RAG funciona bien?"
Construya la v1 en una semana. Itere las preguntas mensualmente. Reemplace el conjunto held-out una vez al año.
Nunca tendrá tiempo para construir el eval set perfecto. Sí tiene absolutamente tiempo para construir el útil.