La pregunta que más oigo a los equipos con una funcionalidad de IA en producción es: "Hemos cambiado el prompt, ¿ahora va mejor o peor?". Sin evaluaciones, nadie lo sabe. Alguien prueba cinco preguntas, las respuestas parecen correctas, el cambio se lanza y una semana después los tickets de soporte revelan una regresión en un caso que nadie probó. Esta guía muestra cómo construir evals de LLM que detecten esas regresiones antes que los usuarios: qué medir, de dónde sacar los datos de prueba, cuándo fiarse de un LLM como juez y cómo ejecutarlo todo con cada cambio.

Por qué las aplicaciones LLM necesitan su propio tipo de testing

Los tests tradicionales afirman salidas exactas: add(2, 2) == 4. Las salidas de un LLM no son deterministas, son abiertas y a menudo tienen muchas respuestas correctas. Eso no hace imposible el testing; cambia su forma.

Un eval es un experimento repetible: un conjunto fijo de entradas, el sistema bajo prueba y un método de evaluación que convierte las salidas en puntuaciones. Ejecuta el mismo eval antes y después de un cambio y podrás comparar versiones con números en lugar de impresiones. La documentación de Anthropic lo resume así: define primero los criterios de éxito y después construye tests que los midan (Anthropic: define success criteria; develop tests).

Los evals importan para tres decisiones que tomarás una y otra vez:

  • Cambios de prompt y de pipeline: ¿ha ayudado el nuevo chunking, el nuevo recuperador o el nuevo prompt?
  • Cambios de modelo: ¿podemos pasar a un modelo más nuevo o más barato sin perder calidad? Consulta optimización de costes de LLM.
  • Puertas de lanzamiento: ¿esta versión es lo bastante buena para salir?

Paso 1: define qué significa "bueno"

Los objetivos vagos producen evals inútiles. "El asistente debe ser útil" no se puede medir; esto sí:

Dimensión de calidad Criterio de ejemplo Cómo evaluarlo
Corrección La respuesta coincide con la referencia en preguntas factuales Coincidencia exacta o aproximada, juez LLM
Fundamentación Cada afirmación está respaldada por las fuentes recuperadas Juez LLM con las fuentes
Rechazo Dice "no lo sé" cuando la respuesta no está en los documentos Comprobación en código sobre un subconjunto etiquetado
Formato Devuelve JSON válido conforme al esquema Validación del esquema
Seguridad Nunca revela datos de otro cliente Comprobación en código, conjunto de red-team
Tono y longitud Menos de 120 palabras, sin lenguaje de marketing Comprobación en código, juez LLM
Éxito de la tarea (agentes) El ticket se creó con los campos correctos Comprobar el estado resultante del sistema

Elige de tres a cinco dimensiones que sean las más importantes para tu producto. Cada una necesita una definición clara de aprobado/suspenso que dos personas aplicarían igual.

Paso 2: construye un conjunto de referencia a partir de la realidad

El conjunto de referencia (golden dataset) es el corazón de todo eval. Su calidad importa más que su tamaño.

  • Parte del tráfico real. Saca de 100 a 200 preguntas de tickets de soporte, logs de chat, consultas de búsqueda y correos comerciales. Las preguntas sintéticas escritas por el equipo son más limpias que la realidad y no recogen las erratas, la ambigüedad y la mezcla de idiomas que producen de verdad los usuarios.
  • Cubre la distribución y después los extremos. La mayoría de los elementos deben parecerse al tráfico cotidiano; añade casos límite deliberados: preguntas sin respuesta en los documentos, peticiones ambiguas, entradas maliciosas y tareas de varios pasos.
  • Guarda referencias, no solo entradas. Para cada elemento, registra la respuesta esperada o los hechos clave que debe contener, el documento de origen si procede y etiquetas como billing, refusal o multi-turn.
  • Versiónalo. Guarda el conjunto en Git junto al código. Cuando aparezca un fallo en producción, añádelo para que nunca pueda volver en silencio.
{"id": "billing-017",
 "input": "Can I get a refund if I cancel my annual plan after 3 months?",
 "must_include": ["pro-rated refund", "within 30 days"],
 "source": "policies/refunds.md#annual-plans",
 "tags": ["billing", "policy"]}

Paso 3: elige los métodos de evaluación, primero los más baratos

Usa el evaluador más sencillo que mida el criterio de forma fiable.

Las comprobaciones en código son rápidas, gratuitas y deterministas: coincidencia exacta, expresiones regulares, validación de esquema JSON, "contiene el hecho requerido", límites de longitud o verificar que la llamada a la API de un agente produjo el registro correcto. Úsalas siempre que puedas.

LLM-as-a-judge cubre lo que el código no puede: fundamentación, completitud, tono. Los modelos potentes coinciden con las preferencias humanas la mayoría de las veces en muchas tareas (Zheng et al., 2023), pero los jueces tienen sesgos conocidos. Tienden a preferir la primera de dos respuestas y las respuestas más largas, así que aleatoriza el orden y controla la longitud (Wang et al., 2023).

Reglas para un juez en el que puedas confiar:

  1. Evalúa un criterio por llamada con una rúbrica clara y una escala binaria o de 1 a 3. "Puntúa la calidad del 1 al 10" produce ruido.
  2. Pide un razonamiento breve antes del veredicto y registra ambos.
  3. Calibra con personas. Haz que una persona etiquete de 50 a 100 salidas y mide el grado de acuerdo. La investigación sobre la alineación de evaluadores muestra que los criterios se desplazan a medida que las personas ven más salidas, así que itera la rúbrica con ejemplos reales (Shankar et al., 2024).
  4. Usa un modelo capaz como juez y mantenlo fijo entre ejecuciones, o estarás comparando dos objetivos en movimiento.
JUDGE_PROMPT = """You grade answers from a customer support assistant.
Criterion: GROUNDEDNESS. Every factual claim in the answer must be
supported by the sources. Ignore style.

<sources>{sources}</sources>
<answer>{answer}</answer>

First write one sentence of reasoning, then output exactly
PASS or FAIL on the last line."""

La revisión humana sigue siendo la verdad de referencia. Reserva unas horas a la semana para que alguien que conozca el dominio lea una muestra de conversaciones de producción y de elementos del eval con puntuación baja. Es la forma más rápida de descubrir modos de fallo que tus métricas todavía no recogen.

En sistemas con recuperación, mide por separado la recuperación y la generación —recall del documento correcto frente a fidelidad de la respuesta—, como se describe en RAG para empresas. Frameworks como RAGAS automatizan parte de esto (Es et al., 2023).

Paso 4: ejecuta los evals con cada cambio

Un eval que alguien ejecuta "cuando se acuerda" no es una red de seguridad. Intégralo en el ciclo de desarrollo:

  • Pull requests: un subconjunto rápido (30–50 elementos, comprobaciones en código y unas pocas llamadas al juez) se ejecuta en CI y publica las puntuaciones en el PR.
  • Cada noche o antes de cada versión: el conjunto completo con todos los jueces, comparado con la última versión.
  • Umbrales, no perfección: haz fallar el build si una métrica clave baja más de un margen acordado, por ejemplo la fundamentación en más de 3 puntos.
  • Ejecuta cada elemento más de una vez cuando las salidas varíen mucho; promedia dos o tres muestras para separar los cambios reales del ruido.

Herramientas open source como promptfoo permiten describir casos de prueba y aserciones en archivos de configuración y ejecutarlos desde CI; a menudo también basta con un pequeño script propio. La herramienta importa menos que el hábito.

Paso 5: cierra el ciclo con producción

Los evals offline predicen la calidad; los datos de producción la confirman. Sigue:

  • Feedback explícito: pulgar arriba/abajo, aunque cuenta con tasas de respuesta bajas.
  • Señales implícitas: preguntas reformuladas, escalados a una persona, sesiones abandonadas, respuestas copiadas y pegadas.
  • Resultados de negocio: tasa de resolución, tiempo de resolución, conversión.

Cada semana, toma una muestra de fallos de producción, etiquétalos y añade los representativos al conjunto de referencia. En unos meses, el conjunto se convierte en el activo más valioso del proyecto: codifica qué significa "bueno" para tus usuarios. En atención al cliente, son las mismas métricas que uso para decidir dónde funcionan los agentes de IA y dónde no.

Errores habituales

  • Probar solo los caminos felices. La mayoría de los incidentes de producción vienen de rechazos, ambigüedad y entradas maliciosas.
  • Una única puntuación agregada. Un solo "calidad: 82%" oculta que las preguntas de facturación bajaron del 90% al 60%. Informa por etiqueta.
  • Usar como juez el modelo que se está probando. Usa un modelo juez fijo y capaz, y calíbralo.
  • No renovar nunca el conjunto. Los productos, los documentos y los usuarios cambian; el eval debe cambiar con ellos.
  • No medir el coste ni la latencia. Un prompt un 2% mejor pero tres veces más lento puede ser una regresión para los usuarios.

Guías relacionadas

Los evals se conectan con el resto del ciclo de vida de un LLM: las trazas de producción alimentan tu conjunto (observabilidad de LLM), los cambios de prompt se prueban contra él (prompt engineering para desarrolladores) y la elección de modelo depende de él (cómo elegir un LLM).

Preguntas frecuentes

¿Cuántos casos de prueba necesitamos? Empieza con 50–100 reales y crece hasta unos cientos. Cubrir escenarios reales importa más que el tamaño.

¿Podemos fiarnos solo de LLM-as-a-judge? No sin calibrarlo. Mide primero el acuerdo con etiquetas humanas y mantén las comprobaciones en código para todo lo que puedan verificar.

¿Cómo evaluamos agentes? Evalúa el estado final —¿se creó el registro correcto?, ¿se redactó el correo correcto?— y la trayectoria: número de pasos, errores de herramientas y acciones innecesarias.

¿Cuánto cuesta ejecutar evals? Normalmente una pequeña fracción del gasto de producción. El procesamiento por lotes y la caché reducen aún más el coste de los jueces.

¿Quién debería ser responsable del conjunto de evals? Un responsable de producto o un experto del dominio, junto con ingeniería. Los ingenieros lo mantienen en marcha; los expertos del dominio deciden qué es una respuesta correcta.

Fuentes

  1. Anthropic. Define your success criteria y Create strong empirical evaluations.
  2. Zheng et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena.
  3. Wang et al. (2023). Large Language Models are not Fair Evaluators.
  4. Shankar et al. (2024). Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences.
  5. Es et al. (2023). RAGAS: Automated Evaluation of Retrieval Augmented Generation.
  6. Hamel Husain. Your AI product needs evals.
  7. Documentación de promptfoo.