El stack de evals para LLM: cómo medir de verdad tu función de IA

La habilidad para la que nadie se entrenó

Todos los equipos están entregando funciones con LLM. Casi ningún equipo tiene una forma real de saber si esas funciones son buenas.

La cohorte AI Evals For Engineers & PMs de Hamel Husain y Shreya Shankar ha entrenado a más de 2,000 practicantes, incluyendo ingenieros y PMs de OpenAI y Anthropic. La razón por la que se llenó no es la teoría. Es que la gente que está construyendo este tipo de cosas se dio cuenta de que su proceso de QA era "pídele al prompt engineer que lea 30 salidas y confíe en la intuición".

Hamel llama a esto una "vibes eval". Es la práctica dominante, y es la razón por la que tantas funciones de IA se entregan, demuestran bien y luego se degradan en silencio. En el podcast de Lenny's Newsletter, Hamel y Shreya argumentaron que las evals son ahora la habilidad con más apalancamiento en el trabajo de producto de IA, más importante que la artesanía de prompts, más importante que elegir el modelo correcto. La razón es estructural. Si no puedes medir la calidad, no puedes mejorarla.

La mayoría de los equipos lo sabe. Aun así no lo hacen. ¿Por qué? Porque las evals parecen trabajo de infraestructura, no tienen un dueño claro, y la primera versión siempre se siente peor que leer salidas a mano. El truco está en darse cuenta de que "leer salidas a mano" es la eval. La disciplina consiste en hacerlo una vez, anotar lo que viste y nunca volver a hacerlo de la misma forma.

Este texto es el playbook. Es agnóstico de herramientas a propósito. Puedes correr este stack con Inspect AI del UK AI Safety Institute, Phoenix de Arize, Promptfoo, Langfuse, el framework OpenAI Evals, las herramientas de eval de Anthropic, o un stack de scripts en Python y una hoja de Google Sheets. La metodología es la que carga el peso.

"Se ve bien" deja de funcionar a escala

La primera vez que entregas una función con LLM, "se ve bien" es una vara aceptable. Escribiste el prompt, probaste diez entradas, las salidas se ven razonables, presionas deploy.

La segunda vez, estás en problemas.

Las salidas de LLM son no deterministas por diseño. Una temperatura de 0 reduce la varianza pero no la elimina. El mismo prompt con el mismo modelo puede producir respuestas sutilmente distintas entre ejecuciones, y desde luego entre versiones de modelo. Encima, añade las cosas que cambian por debajo:

Deriva del modelo. Los proveedores actualizan modelos con el mismo nombre. GPT-4o hoy no es el GPT-4o de hace tres meses. La misma cadena en tu configuración, comportamiento distinto. No vas a recibir una notificación.
Cambio de distribución. Las entradas que envían los usuarios reales no son las entradas con las que tú probaste. Prompts más cortos, otros idiomas, formatos raros, adjuntos. La cola larga es donde las evals importan más.
Entropía del prompt. Cada vez que alguien edita el system prompt para resolver la queja de un usuario, corres el riesgo de romper otros tres casos de uso que olvidaste que existían. Sin evals, esto es invisible hasta que los tickets de soporte se disparan.
Deriva de retrieval. Si usas RAG, tu índice cambia constantemente. La parte de retrieval de tu pipeline se degrada en silencio.

El impuesto oculto es el tiempo de tu equipo. Cada cambio se convierte en media jornada de alguien haciendo clic en prompts. Cada actualización de modelo se vuelve un ejercicio de "déjame revisar algunos" que lleva una semana. Cada escalamiento se vuelve una investigación puntual porque nadie puede responder "¿esto es una regresión, o siempre ha estado roto para consultas como esta?"

Las evals reales hacen que esas preguntas se respondan barato. El costo está al inicio. El ahorro se acumula.

Anatomía de un stack de evals para LLM

Hay cinco capas. Se construyen una sobre la otra. Saltarse una capa significa que las que están arriba puntúan ruido.

Capa	Propósito	Ejemplos de herramientas	Trampas
1. Traces	Capturar cada entrada, salida, llamada a herramienta, conjunto de retrieval, latencia y costo de ejecuciones en producción	Langfuse, Phoenix, exporters de OpenTelemetry	Muestrear con demasiada agresividad; omitir payloads de tool calls; PII en los logs
2. Análisis de errores	Hacer open coding de 50 a 100 traces reales, agrupar modos de falla, construir una taxonomía de errores	Notion, Airtable, un CSV	Saltarse este paso; que una sola persona lo haga sin calibración
3. Golden dataset	50 a 100 ejemplos etiquetados a mano que cubran cada modo de falla y el camino feliz	Formato de dataset de Inspect AI, JSONL, tu propio esquema	Datos solo sintéticos; sin cobertura de los modos de falla que encontraste en el paso 2
4. LLM-as-judge	Un modelo de puntuación con una rúbrica, validado contra etiquetas humanas a >=85% de coincidencia	OpenAI Evals, Promptfoo, Inspect AI, custom	Usar un juez que nunca validaste; puntuar con un solo juez; deriva de la rúbrica
5. Integración con CI	Correr la eval en cada PR, bloquear merges si hay regresión, alertar sobre degradación	GitHub Actions, GitLab CI, runners propios	Correr demasiado lento; sin techo de costo; alza de precio del modelo juez

El orden importa. No puedes construir un golden dataset sin antes descubrir qué modos de falla existen (análisis de errores), y no puedes hacer análisis de errores sin traces. No puedes validar un juez sin un golden set etiquetado. No puedes correr el pipeline en CI hasta que el juez sea realmente confiable.

El resumen paso a paso del currículo de Hamel y Shreya que hizo Aakash Gupta recorre este mismo esqueleto con nombres ligeramente distintos, y es lo más cercano que tiene el campo a una forma consensuada. Vamos capa por capa.

Paso 1: capturar traces

Un trace es el registro completo de una interacción con LLM. No solo la entrada y la salida, sino todo lo que el sistema hizo entre medias.

Un trace útil contiene:

El historial completo de mensajes (system prompt, turnos del usuario, turnos del asistente)
El nombre y versión del modelo, exactamente como se llamó
Todas las tool calls, sus argumentos y sus respuestas
Para RAG: la consulta de retrieval, los documentos devueltos, los scores y los documentos que realmente se usaron en el prompt final
Conteo de tokens, latencia desglosada por etapa y costo en dólares
Un ID de solicitud que puedas cruzar de vuelta con la sesión del usuario
Cualquier señal de feedback (pulgar arriba, clic en copiar, regenerar, abandono)

El principio: el trace es la fuente de verdad. Si no puedes reconstruir exactamente lo que el modelo vio e hizo a partir del trace por sí solo, tu eval está corriendo aguas abajo de una suposición.

Sobre el muestreo, el trade-off es volumen contra costo. Para un producto de alto tráfico, registra el 100% de los traces pero retén los payloads completos solo de una muestra (5 a 10%), con el resto reducido a metadatos. Registra el 100% de los traces con error (fallas en tool calls, timeouts, retrieval con baja confianza, feedback negativo). Esos son tu mina de oro.

Sobre PII: los traces contendrán datos del usuario. Aplica las mismas reglas de redacción y retención que usas para cualquier otro log de producción. La mayoría de los equipos hashean los IDs de usuario, eliminan correos y rotan logs en un calendario de 30 a 90 días.

Si lo estás armando por tu cuenta, escribe un pequeño wrapper alrededor de tu SDK de LLM que emita JSON estructurado a tu pipeline de logging. El formato importa menos que la disciplina de loggear siempre.

Paso 2: análisis de errores (open coding)

Este es el paso que todos se saltan, y es el paso que hace que todo lo demás funcione.

La investigación de Shreya Shankar toma una técnica de la investigación cualitativa llamada open coding. Te sientas con 50 a 100 traces reales. Los lees. Anotas qué está mal (o bien). No impones categorías por adelantado. Dejas que las categorías emerjan de los datos.

En concreto:

Saca 100 traces de producción. Mezcla muestras aleatorias con traces marcados por feedback negativo, errores o alta latencia.
Abre una hoja de cálculo. Columnas: ID del trace, resumen de la entrada, resumen de la salida, problema (texto libre), severidad (1-3), tags (empieza vacío).
Para cada trace, escribe qué está mal en lenguaje claro. No "mala salida". Específico: "alucinó un nombre de función que no existe en el código del usuario", o "respondió en el idioma equivocado", o "rechazó una solicitud benigna".
Después de 20 a 30 traces, los mismos problemas siguen apareciendo. Empieza a etiquetarlos. Tags de dos palabras están bien.
Después de los 100, agrupa los tags. Lo normal es que termines con 5 a 15 modos de falla distintos más "se ve bien".

Esa es tu taxonomía de errores. Hamel describe esto en sus Field Notes on LLM Evals como el momento en que las preocupaciones vagas se vuelven afirmaciones comprobables. "El bot alucina a veces" se convierte en "el bot alucina nombres de función en el 8% de las consultas relacionadas con código, especialmente cuando los nombres de variables son poco comunes". Eso es algo para lo que puedes escribir una eval.

Un segundo par de ojos importa. Haz que alguien más codifique los mismos 30 traces de forma independiente. Donde no coincidan, la taxonomía es difusa y necesita afinarse. Esta es la misma comprobación de coincidencia entre anotadores que después aplicarás al juez LLM.

Paso 3: construir un golden dataset

Un golden dataset es un conjunto fijo de entradas, comportamientos esperados y etiquetas contra el cual se evalúa tu pipeline. Piénsalo como tu suite de pruebas de regresión para un LLM.

Tamaño: 50 a 100 ejemplos es un punto de partida real. No 10 (demasiado ruidoso). No 1,000 (demasiado caro, demasiado lento). Hazlo crecer a medida que encuentres nuevos modos de falla, pero la primera versión debe ser lo bastante pequeña como para que una persona pueda leer cada ejemplo en una tarde.

Cobertura: cada modo de falla del análisis de errores necesita al menos 5 a 10 ejemplos. Más 20 a 30 ejemplos del camino feliz. Más algunos casos límite (muy largos, muy cortos, no en inglés, adversariales). El paper de arXiv Constructing Domain-Specific Evaluation Sets for LLM-as-a-judge vale la pena para una estrategia de cobertura.

Criterios de inclusión:

Entradas reales de usuario por encima de las sintéticas. Solo sintético es una trampa conocida: tiende a parecerse a los prompts que tu equipo escribiría, no a lo que los usuarios envían en realidad.
Cada ejemplo tiene un resultado esperado etiquetado. Para generación abierta, eso es una rúbrica (debe X, no debe Y, idealmente Z), no una cadena literal esperada.
Cada ejemplo está etiquetado con uno o más modos de falla.
Los datos sensibles están limpios.

Rúbrica de etiquetado: escribe qué se ve como "bueno". Para algunas tareas, coincidencia exacta (¿llamó a la API correcta?). Para la mayoría, es una rúbrica de propiedades: "debe citar al menos un documento recuperado", "no debe rechazar", "debe estar en el idioma del usuario", "no debe inventar nombres de función". Cada propiedad es una verificación binaria.

Cadencia de actualización: una vez por trimestre, saca un lote nuevo de 50 a 100 traces de producción y repite el open coding. Se agregan nuevos modos de falla. Los viejos que ya no ocurren se quedan (quieres cobertura de regresión). Cuando el modelo o el prompt cambian de forma significativa, haz una actualización fuera de ciclo.

La trampa que hay que evitar: no dejes que el equipo que escribe el prompt sea también el único que escriba el golden dataset. Va a sobreajustarse a las fortalezas del prompt. Haz que alguien fuera del trabajo diario del prompt etiquete al menos la mitad de los ejemplos.

Paso 4: LLM-as-judge con validación humana

Para tareas sin una única respuesta correcta (resumen, clasificación con categorías difusas, Q&A abierto), necesitas una manera de puntuar salidas a escala. La puntuación manual no corre en cada PR.

LLM-as-judge es la técnica: usar una llamada separada a un LLM para puntuar la salida de tu pipeline contra la rúbrica. Funciona. El análisis de Confident AI sobre métodos de LLM-as-judge reporta que la coincidencia entre juez y humano cruzó el 85% en varios benchmarks en 2025-2026, lo que es aproximadamente el nivel de coincidencia que dos humanos muestran entre sí en tareas subjetivas. No es perfecto, pero es lo bastante bueno como para ser útil, si lo validas.

La metodología, en orden:

Escribe una rúbrica para el juez. No "¿esta respuesta es buena?". Específico: "¿La respuesta cita al menos uno de los documentos provistos? S/N. ¿La respuesta rechaza cuando no debería? S/N. ¿La respuesta inventa nombres de función que no están en el código del usuario? S/N." Binario o Likert corto. Los jueces son malos con escalas de 1 a 10.
Elige un modelo juez. Un modelo general fuerte (clase GPT-4 o clase Claude Sonnet/Opus) suele superar a los modelos más pequeños, pero para corridas de eval de alto volumen, un juez más barato está bien si lo validas.
Etiqueta tu golden set a mano. Dos humanos, de forma independiente. Calcula la coincidencia entre anotadores (kappa de Cohen o porcentaje simple de coincidencia en un binario). Si los humanos no coinciden por encima del 80 a 85%, tu rúbrica es demasiado difusa. Afínala.
Corre el juez sobre el mismo conjunto. Compara las etiquetas del juez contra las etiquetas humanas. Si la coincidencia juez-humano está por debajo del 80%, tu prompt de rúbrica para el juez está mal, o el modelo juez es demasiado débil. Itera sobre el prompt del juez.
Pon el juez en producción solo cuando la coincidencia esté en 85% o más. Por debajo de eso, estás automatizando ruido.

Errores comunes:

Usar una sola llamada del juez sin validar. La coincidencia podría ser del 60%. Nunca lo sabrías.
Usar el mismo modelo para generar y juzgar. Hay un sesgo conocido de auto-preferencia. Usa una familia de modelos distinta para el juez cuando puedas.
Dejar que la rúbrica del juez se desvíe de la rúbrica humana. Tienen que ser el mismo prompt. Si modificas uno, re-valida.
Usar una sola llamada del juez como verdad de referencia. Para evals de alto impacto, corre el juez con tres llamadas independientes y toma el voto de mayoría. El desacuerdo entre llamadas del juez es en sí mismo una señal.

Una vez validado, el juez puede puntuar miles de salidas en minutos por unos pocos dólares. Esa es la recompensa. Pasas de "hacemos eval antes de cada release" a "hacemos eval en cada PR".

Paso 5: conectarlo con CI/CD

El punto entero de este stack es que nadie tenga que acordarse de correr las evals. CI lo hace.

Una forma que funciona:

En cada PR que toque prompts, configuraciones del modelo o código del pipeline: corre la golden eval. Bloquea el merge si cualquier métrica cae más de un umbral (digamos 3 puntos porcentuales en exactitud, o cualquier regresión en una verificación dura como "no debe rechazar solicitudes benignas").
En cada cambio de versión de modelo: corre la eval completa en infraestructura equivalente a producción. Compara lado a lado.
En un calendario nocturno: corre la eval contra una muestra de traces frescos de producción. Esto detecta el cambio de distribución que el golden set estático no ve.
Techos de costo: pon un tope al presupuesto de eval por PR. Un default sensato es entre 1 y 5 USD por corrida. Si tu eval cuesta más, muestrea el golden set o usa un juez más barato para evals en tiempo de PR y el juez completo para releases.

Un patrón que funciona: una "fast eval" de 20 a 30 ejemplos en cada commit (menos de 2 minutos) y una "full eval" de 100 a 300 ejemplos en la aprobación de PR y en main. Mismo pipeline, distintos tamaños de muestra.

El reporte importa. El comentario del PR debe mostrar la tasa de aprobación general, la tasa por modo de falla, el diff contra main y enlaces a los traces fallidos. No entierres esto en un archivo de log.

Alerta sobre deriva de la línea base. Si la tasa nocturna de aprobación cae 5 puntos y se queda ahí dos días, algo cambió (una actualización del modelo, un cambio en el índice de retrieval, un servicio aguas abajo). La eval también es tu capa de monitoreo.

Antipatrones que los equipos siguen entregando

Algunos patrones que conviene vigilar, porque siguen apareciendo en equipos reales:

Vibes evals entregadas a producción. Un ingeniero mira de reojo 20 salidas, dice "lánzalo", y la función sale en vivo. Tres semanas después, nadie puede responder "¿esto está mejor que la semana pasada?".

Puntuar con un solo juez sin validar. Alguien lee sobre LLM-as-judge, escribe un prompt de una línea ("califica esto del 1 al 10"), y empieza a tomar decisiones con base en esas puntuaciones. Las puntuaciones son ruido.

Sin taxonomía de errores. El equipo se saltó el open coding. El golden set se escribió de memoria. Se sobreajusta a casos obvios y se pierde cada modo de falla interesante que encuentran los usuarios reales.

Sin verificación de coincidencia humana. Cuando dos humanos no han coincidido en las etiquetas, la "coincidencia" del juez con uno de ellos no significa nada.

Solo datos sintéticos. El golden set lo genera otro LLM. Se ve genial. Pasa cada eval. Producción se rompe porque las entradas reales de los usuarios no se parecen a las entradas generadas por LLM.

Un solo número que lo resume todo. "Nuestro score de eval es 87%". ¿En qué? ¿Sobre qué modos de falla? Las tasas de aprobación por modo de falla son obligatorias. Un agregado oculta las fallas que importan.

La eval como pensamiento tardío. Tratada como un ejercicio trimestral en lugar de un pipeline continuo. Se vuelve obsoleta dentro de un ciclo de release. Nadie confía en ella.

El plan de evals de 7 días para un equipo sin evals

Si partes de cero, aquí hay una semana que te lleva a un pipeline funcional.

Día 1: capturar traces. Elige una función con LLM. Añade logging que capture entrada, salida, tool calls, contexto de retrieval si lo hay, versión del modelo y un ID de solicitud. Envíalo a donde vivan tus logs. No elijas una herramienta todavía; un archivo JSONL funciona para la semana uno. Meta al final del día: 100 o más traces de producción.

Día 2: open coding, ronda uno. Saca 50 traces. Una persona los lee. Anotación en texto libre de qué está mal o bien. No categorices todavía. Solo describe.

Día 3: open coding, ronda dos. Una segunda persona hace los mismos 50. Comparen notas. Construyan la taxonomía de modos de falla a partir de los patrones. Apunten a 5 a 12 modos de falla nombrados. Estimen la frecuencia aproximada de cada uno.

Día 4: golden dataset v0. Toma 50 a 80 ejemplos que cubran cada modo de falla más el camino feliz. Etiqueta cada uno con una rúbrica: qué debe ser cierto para una buena respuesta. Guárdalo como JSONL o una hoja de cálculo, no importa, pero guárdalo en control de versiones.

Día 5: construir el juez. Escribe un prompt de juez que puntúe cada propiedad de la rúbrica como binario. Elige un modelo juez de una familia distinta a la de tu modelo de producción. Córrelo sobre el golden set.

Día 6: validar el juez. Haz que dos humanos etiqueten el mismo golden set contra la misma rúbrica. Calcula la coincidencia humano-humano y la coincidencia juez-humano. Si juez-humano está por debajo del 80%, itera el prompt del juez. Detente cuando llegues al 85% o se te acabe el día seis. Si no puedes llegar al 85%, el problema es tu rúbrica. Afina las preguntas binarias.

Día 7: conectar CI. Una GitHub Action que corra la eval en PRs que toquen prompts o código del pipeline. Saca un comentario con la tasa de aprobación, el desglose por modo de falla y enlaces a los traces fallidos. Pon un presupuesto. Pon un umbral de regresión.

Fin de la semana: tienes traces, una taxonomía, un golden set, un juez validado y una compuerta de CI. El stack completo. Es pequeño, y ese es el punto. Crece a partir de aquí.

Después de la semana uno, vas a gastar la mayor parte de tu tiempo de evals en tres cosas: hacer crecer el golden set, refinar la rúbrica cuando encuentres ambigüedad e investigar regresiones que detecte el CI. Nada de esto requiere otra construcción grande.

Preguntas frecuentes

¿Cuál es la diferencia entre una vibes eval y una eval real?

Una vibes eval es "leí 20 salidas y se ve mejor". Una eval real tiene: un conjunto fijo de entradas, una rúbrica escrita, un mecanismo de puntuación que no depende de quién esté leyendo en ese momento y una manera de comparar dos corridas. La prueba más rápida: si no puedes responder "¿cuál fue el score de eval la semana pasada y esta semana, y qué modos de falla retrocedieron?", no tienes una eval real.

¿Qué tan grande debería ser mi golden dataset?

50 a 100 ejemplos para la primera versión. Lo bastante grande como para cubrir cada modo de falla con 5 a 10 casos, lo bastante pequeño como para que una persona pueda leerlo todo en una tarde. Hazlo crecer con el tiempo a medida que encuentres nuevos modos de falla en producción. La mayoría de los pipelines maduros se sientan en 200 a 500 ejemplos; muy pocos se benefician de pasar de 1,000 a menos que estén evaluando muchos casos de uso distintos.

¿LLM-as-judge realmente coincide con humanos?

Cuando lo validas, sí. La investigación de Confident AI reporta coincidencia juez-humano superior al 85% en rúbricas validadas en 2025-2026, lo que es aproximadamente el nivel en el que dos humanos coinciden entre sí. La trampa: esto solo se sostiene cuando has calibrado al juez contra etiquetas humanas primero. Un prompt de juez copiado de un tutorial, sin validar, es solo una máquina de opiniones.

¿Necesito una herramienta especializada de evals, o puedo hacer la mía?

Para la semana uno, hazla tú. Archivos JSONL, un script en Python, una hoja de cálculo para etiquetas. Una vez que te quede chico (normalmente cuando varias personas necesitan etiquetar, o cuando quieres una UI para navegar traces), elige una herramienta. Inspect AI, Phoenix, Promptfoo, Langfuse y el framework OpenAI Evals cubren todos la misma forma básica con distinta ergonomía. La metodología es el foso, no la herramienta.

¿Cuándo debería volver a etiquetar mi golden dataset?

Trimestralmente como línea base. Fuera de ciclo cuando cambias modelos, cuando cambias el prompt de forma significativa, cuando los tickets de soporte se disparan con un nuevo modo de falla, o cuando tu eval nocturna contra traces frescos de producción muestra que el golden set ya no es representativo.

Reflexiones finales

Los equipos que ganen los próximos dos años de trabajo de producto de IA no son los que tengan los prompts más ingeniosos. Son los que pueden responder, en cualquier martes, "¿nuestra función de IA está hoy mejor que el mes pasado, en qué dimensiones y para qué usuarios?". Esa es una pregunta de evals, no una pregunta de prompts.

La metodología se ha estabilizado: traces, análisis de errores, golden dataset, juez validado, loop de CI. Cinco capas, cada una construible en uno o dos días por un equipo pequeño. La brecha entre los equipos que tienen un stack de evals y los que no se está ensanchando rápido.

Si entregaste una función con LLM y no puedes responder la pregunta de regresión con confianza, tu tarea de la semana uno no es otro ajuste de prompt. Es un archivo JSONL, cincuenta traces y una hoja de cálculo de etiquetas. El resto del stack sale de ahí. Empieza chico, valida sin piedad, entrega el pipeline antes que la próxima función.