La Guía Definitiva para Evals: Comienza con 100 Revisiones Manuales y un 'Dictador Benevolente'

Perspectiva

Estos son Hamel Hussein y Shrea Shankar - profesores del curso #1 de evals en Maven, que han entrenado a más de 2,000 PMs e ingenieros incluyendo equipos de OpenAI y Anthropic. Su proceso es sorprendentemente manual al principio, y ese es el punto.

“El error más común es: ¿no puede el AI simplemente evaluarlo?” No funciona. Cuando Hamel mostró un trace donde un AI programó una visita virtual que no existía, ChatGPT diría “se ve bien” porque carece del contexto para saber que esa característica no existe. El experto de dominio lo detecta en segundos. Los LLMs pierden el olor del producto.

El proceso: codificación abierta con un dictador benevolente. Mira traces (registros de interacciones LLM). Escribe notas rápidas sobre qué está mal - solo el primer error más ascendente que veas. No intentes encontrarlo todo. No uses comités. Designa a una persona cuyo gusto confíes (el experto de dominio). Mantenlo informal: “jank” está bien como nota. Revisa al menos 100 traces hasta que llegues a la “saturación teórica” - cuando dejas de aprender cosas nuevas.

El análisis de errores precede la escritura de pruebas. Esto es diferente de la ingeniería de software donde saltas a pruebas unitarias. Con LLMs, la superficie es demasiado grande y el comportamiento muy estocástico. Necesitas análisis de datos primero para entender qué incluso probar. Solo después de la codificación abierta codificas patrones en evals automatizadas.

El ejemplo del agente inmobiliario es perfecto. El usuario pregunta sobre disponibilidad. El AI dice “no tenemos eso, que tengas un buen día.” Técnicamente correcto. ¿A nivel de producto? Terrible. Una herramienta de gestión de leads debería pasar a una persona, no cerrar la conversación. Ese es el tipo de cosa que solo una persona de producto detecta.

No hagas los evals caros. Solo puntuaciones binarias (aprobado/reprobado). Un experto de dominio, no un comité. Muestrea tus datos, no revises todo. El objetivo no es la perfección - es la mejora accionable. Si haces el proceso caro, no lo harás.

Puntos Clave

• Los LLMs no pueden hacer análisis de errores - Carecen de contexto; dicen “se ve bien” en fracasos de producto obvios
• Codificación abierta - Escribe notas rápidas sobre el primer error; no encuentres todo; sé informal
• Dictador benevolente - Un experto de dominio cuyo gusto confías; no comités
• Mínimo 100 traces - Hasta saturación teórica; te engancharás después de 20
• Saturación teórica - Para cuando dejes de aprender cosas nuevas
• Solo puntuaciones binarias - Aprobado/reprobado; no hagas escalas 1-5; hace todo manejable
• Análisis de errores → pruebas - Diferente de la ingeniería de software; entiende antes de codificar
• Persona de producto requerida - Los ingenieros pierden el olor del producto; la experiencia de dominio es crítica
• Muestrea, no revises todo - Hace el proceso sostenible
• “Jank” es válido - Mantén las notas informales; la especificidad importa más que el pulido

Visión General

La evaluación de AI no es pruebas automatizadas - es análisis de datos que requiere juicio humano. Las compañías que envían productos de AI confiables no están usando marcos sofisticados; están poniendo expertos de dominio frente a traces y dejándoles desarrollar gusto. No existe atajo.