Lección 5: Conjuntos de evaluación: empieza con 20 tareas reales

Objetivos de aprendizaje:

• Explicar por qué «esperemos a tener cientos de casos» es un error, y por qué los cambios de la etapa temprana tienen tamaños de efecto tan grandes que unos pocos casos alcanzan para distinguir versiones
• Diseñar un lote de casos de evaluación siguiendo estos principios: anclados en el uso real, complementados con casos límite, calificación automatizada cuando se pueda, cantidad por encima de calidad por caso, e inclusión deliberada de casos ambiguos — cada uno emparejado con un resultado verificable
• Usar conjuntos reservados para evitar sobreajustar los prompts hasta convertirlos en «modelos que solo aprueban estas preguntas», e identificar qué problemas no ven las evaluaciones automatizadas y solo atrapa la prueba manual

Requisitos: Lecciones 1–4 («parece terminado» ≠ terminado, objetivos de verificación con el estado final primero, verificadores deterministas, jueces LLM) | Anterior: << Lección 4 | Siguiente: Lección 6 >>

Un motivo de demora particularmente común

Seguro has visto esta escena. Alguien plantea la idea: «deberíamos armar un conjunto de evaluación para nuestro agente». Otra persona responde: «un conjunto de evaluación necesita cientos de casos para tener significancia estadística, ¿no? Correr diez o veinte casos produce puntuaciones sin sentido que confunden más de lo que informan. Juntemos primero casos reales de usuarios y armamos el conjunto cuando tengamos suficientes».

Suena profesional. Disciplinado. Después pasan seis meses, los casos siguen en un documento compartido, el prompt se revisó treinta veces y nadie puede decir si alguna de esas revisiones fue una mejora o un retroceso.

El postmortem de ingeniería de Anthropic sobre su sistema multiagente de investigación señala directamente esta excusa: escuchan seguido que los equipos de desarrollo de IA demoran la creación de evaluaciones porque creen que solo las evaluaciones grandes con cientos de casos de prueba sirven, cuando en realidad lo mejor es empezar de inmediato con pruebas a pequeña escala con unos pocos ejemplos, en vez de demorarlo¹.

Esta lección aclara exactamente eso: por qué los conjuntos pequeños sí funcionan al principio, cómo debería verse un caso, cómo seleccionar esos casos y cómo evitar «ajustar el agente hasta volverlo experto en estas preguntas específicas y en nada más».

Tamaño del efecto: por qué unos pocos casos bastan para ver diferencias al principio

Empecemos por un término. El tamaño del efecto se refiere a qué tan grande es la brecha que produce un cambio: ¿es pasar de 71,2% a 72,4%, o un salto de 30% a 80%? Las brechas grandes requieren menos muestras; las pequeñas requieren más. Esto no tiene nada de místico, es el mismo sentido común que usas para juzgar cuál de dos vasos de agua está más caliente: una diferencia de 30 grados es obvia al tacto, una diferencia de medio grado exige un termómetro.

El desarrollo temprano de agentes pertenece a la primera categoría. El postmortem oficial lo dice sin rodeos: en el desarrollo temprano de agentes los cambios tienden a tener impactos dramáticos porque abunda la fruta al alcance de la mano; un retoque del prompt podría subir las tasas de éxito de 30% a 80%, y con tamaños de efecto así de grandes puedes detectar los cambios con apenas unos pocos casos de prueba¹.

Imagina esta escena: tienes 6 casos, 2 aprueban antes del cambio, 5 aprueban después. ¿Necesitas un valor p? No. Lo que necesitas es fijar esta versión del prompt e ir a buscar la siguiente mejora de 30% a 80%.

La escala con la que ellos empezaron tampoco es misteriosa: un conjunto de unas 20 consultas que representaban patrones de uso reales¹. Veinte no es un umbral mágico, es apenas una cantidad que puedes terminar en una tarde y empezar a usar ese mismo día.

Lo inverso también se sostiene: cuando tu agente ya está en 80% o más y los cambios que quedan mueven la aguja uno o dos puntos, unos pocos casos genuinamente no alcanzan para distinguirlos. En ese punto necesitas más casos — pero para entonces ya tienes un conjunto de evaluación en funcionamiento, y ampliarlo es muchísimo más fácil que construirlo de cero. Consigue la regla primero y después hablamos de precisión; no esperes a que la regla sea precisa para empezar a medir.

Composición mínima de un caso de evaluación

Un conjunto de evaluación no es «una pila de prompts». Una pila de prompts solo te permite mirar salidas de reojo, lo cual se vuelve tedioso a la segunda lectura y autoengañoso a la tercera.

El artículo de ingeniería de herramientas es directo: cada prompt de evaluación debería estar emparejado con una respuesta o un resultado verificable; tu verificador puede ser tan simple como una comparación exacta de cadenas entre la verdad de referencia y las respuestas muestreadas, o tan avanzado como reclutar a Claude para juzgar la respuesta². Esto se conecta directamente con los criterios de éxito de la Lección 2, los verificadores deterministas de la Lección 3 y los jueces LLM de la Lección 4 — esas lecciones te enseñaron cómo verificar, esta te enseña qué verificar.

Así que un caso utilizable necesita al menos tres componentes escritos con claridad:

prompt   : Entrada al agente (escríbela como la diría un usuario)expected : Un resultado verificable (estado final, cadena, cambio de estado o rúbrica)verifier : Quién juzga — verificador determinista o juez LLM

Estructurado como datos, se ve así:

El campo expected aquí describe estados finales y evidencia observable, no «la secuencia que el agente debería razonar». La conclusión de la Lección 2 sigue aplicando: para un mismo objetivo, el agente podría tomar varios caminos válidos, así que no fijes el camino en el código. El artículo de ingeniería de herramientas también te recuerda que opcionalmente puedes especificar las herramientas que esperas que un agente llame, para medir si los agentes captan el propósito de cada herramienta, pero que como podría haber varios caminos válidos, evites sobreespecificar o sobreajustar a estrategias².

El campo mustCallTools quizá te recuerde a expectedTools de la Lección 2. Vale la pena dejar clara la relación entre ambos. Las afirmaciones negativas (mustNotContain, mustNotCallTools — no digas «te la cambié», no adivines un número de pedido y lo consultes) son en esencia salvaguardas de estado final que describen «lo que no debía pasar no pasó», y se pueden imponer de forma estricta. Las afirmaciones positivas sobre herramientas (que haya llamado cierta herramienta) son las afirmaciones de trayectoria de la Lección 2, y esas tres disciplinas aplican sin cambios: afirma solo pertenencia al conjunto, lista solo la o las dos herramientas que de verdad te importan, y si la afirmación falla pero el estado final aprueba, registra una observación en vez de reprobar el caso de inmediato. Solo se endurece en un escenario: cuando la información clave de la respuesta solo puede provenir del valor de retorno de esa herramienta. El caso cs-003 es exactamente de ese tipo — el juicio «ya fue enviado» solo puede venir de getOrder, así que si la herramienta no se llamó, esa declaración es fabricada, y eso vuelve exigible esta afirmación positiva. Ante la duda, trátala como blanda.

Una nota más: este caso tiene mustNotContain con «te la cambié» — se cuida de que el agente acepte de palabra cambiar la dirección mientras en realidad no hace nada. Esa «finalización verbal» es justamente el tema de la Lección 1.

Cinco reglas para diseñar conjuntos de evaluación

Las cinco reglas de abajo combinan los principios de diseño de la documentación «Test and Evaluate» de la plataforma de Claude y las prácticas del artículo de ingeniería de herramientas en una sola lista de verificación — las citas después de cada regla indican su fuente.

Uno: anclar en el uso real. Genera muchas tareas de evaluación, ancladas en usos del mundo real²; diseña evaluaciones que reflejen tu distribución real de tareas³. El criterio es directo: si este prompt no se copió de logs reales, ¿puedes señalarlo y decir «tres usuarios preguntaron exactamente esto la semana pasada»? Si no, probablemente sea algo que imaginaste sentado en tu escritorio.

Dos: no te pierdas los casos límite. La documentación oficial acompaña «refleja tu distribución real de tareas» inmediatamente con un recordatorio: no olvides tener en cuenta los casos límite³. La distribución real es el cuerpo, los casos límite son el seguro. Un conjunto de evaluación compuesto enteramente de casos límite te va a confundir — te vas a pasar un mes arreglando un problema que aparece dos veces al mes.

Tres: automatiza la calificación cuando se pueda. Estructura las preguntas para permitir calificación automatizada, por ejemplo opción múltiple, coincidencia de cadenas, calificación por código, calificación por LLM³. Esto determina si tu conjunto de evaluación se puede ejecutar repetidamente. Los casos que te exigen leer cinco minutos para juzgar aprobado/fallido — después de escribir diez de esos, nunca vas a querer ejecutarlos una segunda vez.

Cuatro: prioriza cantidad sobre calidad. La redacción oficial: más preguntas con calificación automatizada de señal levemente menor es mejor que menos preguntas con evaluaciones humanas de alta calidad calificadas a mano³. Esta es la más contraintuitiva y también la que más tiempo te ahorra — invierte tu tiempo en escribir diez casos más, no en pulir hasta la perfección los criterios de calificación de un caso.

Cinco: recolecta casos ambiguos a propósito. La documentación lista explícitamente un tipo de caso de prueba que vale la pena incluir: casos de prueba ambiguos en los que hasta a los humanos les costaría llegar a un consenso de valoración³. No son para subir las puntuaciones, son para sacar los desacuerdos a la superficie. Cuando tu agente titubea en estos casos, es señal de que las reglas mismas a nivel producto no están definidas, y eso lo tiene que resolver producto, no es algo que la ingeniería de prompts pueda arreglar.

Un punto más que no es un «principio de diseño» pero es igual de crítico: no hagas el entorno de evaluación demasiado simple. El artículo de ingeniería de herramientas recomienda evitar entornos «sandbox» demasiado simplistas o superficiales que no pongan tus herramientas bajo suficiente complejidad; las tareas de evaluación fuertes podrían requerir varias llamadas a herramientas, potencialmente decenas². Una pregunta que se responde con una sola consulta a la base de datos no va a revelar si tu agente pierde el contexto para la séptima llamada a herramienta.

Conjuntos reservados: no ajustes tu prompt hasta que solo sea bueno en estas preguntas

Supongamos que armaste juiciosamente 20 casos y empezaste a ajustar prompts. La primera versión aprueba 8 casos, una revisión aprueba 12, otra aprueba 16, otra aprueba 19. Excelente.

El problema: ¿cuánto de ese éxito de 19 casos viene de que el agente de verdad se volvió más fuerte, y cuánto de que fuiste incrustando calladamente las características de estas 20 preguntas dentro del prompt? Por ejemplo, notas que el caso 7 sigue fallando, así que le agregas una línea al prompt de sistema: «para temas de devolución prioriza citar la política de 7 días sin preguntas» — el caso 7 aprueba, pero lo que realmente hiciste fue escribir la respuesta de esa pregunta.

Este fenómeno se llama sobreajuste: el modelo (o, en este contexto, la configuración entera de prompt más herramientas) aprende las características del material de entrenamiento en vez de las regularidades de la tarea misma.

El remedio del artículo de ingeniería de herramientas es una sola oración, pero crítica: se apoyaron en conjuntos de prueba reservados para asegurarse de no sobreajustar a sus evaluaciones «de entrenamiento»².

Un conjunto reservado es un lote de casos apartados desde el principio, que no miras, no ejecutas y no tocas durante el ajuste del día a día. Todo su valor viene de «no estar contaminado». Algunas disciplinas que vale la pena codificar en los acuerdos del equipo:

• Ejecútalo solo en hitos. El ajuste diario de prompts ejecuta solo el conjunto de desarrollo (las evaluaciones «de entrenamiento» de la cita anterior — esta lección lo llama conjunto de desarrollo, registrado como dev en el campo JSON); ejecuta el conjunto reservado solo antes de una entrega o después de cambios estructurales (cambiar de modelo, reescribir descripciones de herramientas, modificar el bucle de arnés).
• Mira solo los agregados. Revisa la tasa de aprobación global y los IDs de los casos que fallaron, no abras la transcripción completa de cada caso reservado que falló para depurarlos uno por uno. En cuanto modificas un prompt para arreglar un caso reservado específico, ese caso ya pasó a ser parte del conjunto de desarrollo.
• Retíralo si se contamina. Si de verdad abriste unos cuantos casos reservados mientras depurabas un problema, fusiónalos al conjunto de desarrollo y repón un lote fresco de casos reservados. El conjunto reservado es consumible, no una reliquia familiar.
• Documenta quién tiene acceso. Los equipos pequeños suelen saltarse esto. Acordar que «las ejecuciones del conjunto reservado las hace una sola persona antes de las entregas, y los resultados se publican en el canal como una única línea con la puntuación» es muchísimo más efectivo que promesas verbales de «disciplina, muchachos».

Vale mencionar una práctica de ingeniería común: enganchar las evaluaciones a CI para que cada commit ejecute automáticamente el conjunto de desarrollo, compare las puntuaciones con la versión anterior y bloquee si la puntuación baja. Esto es práctica de ingeniería estándar, la orquestación depende de tu pipeline y este curso no la va a desarrollar — la Lección 6 va a construir «el circuito de evaluación que de verdad corre», y si lo conectas a CI es decisión tuya.

Lo que las evaluaciones automatizadas se pierden, lo atrapan los humanos

Una vez que el conjunto de evaluación está armado, corriendo y puntuando bien, ¿puedes eliminar las pruebas humanas?

No. El postmortem oficial es explícito: incluso en un mundo de evaluaciones automatizadas, la prueba manual sigue siendo esencial¹. La razón es que las personas que prueban agentes encuentran casos límite que las evaluaciones no ven — incluidas respuestas alucinadas ante consultas inusuales, fallos del sistema o sesgos sutiles de selección de fuentes¹.

La tercera categoría merece mención especial por lo típica que es. Sus evaluadores humanos notaron que los agentes iniciales elegían de manera consistente granjas de contenido optimizadas para SEO por encima de fuentes autorizadas pero peor rankeadas, como PDF académicos o blogs personales¹.

Detente un momento a considerar cómo se ve ese sesgo. Cada instancia individual parece estar bien — el agente da una respuesta citada, con fuentes, que suena plausible. La verificación de hechos aprueba, el formato de las citas aprueba, la completitud aprueba, y ninguna de tus dimensiones de puntuación detecta problema alguno (a menos que tu rúbrica incluya justo la dimensión «calidad de las fuentes» de la Lección 4 y sus criterios sean lo bastante afilados). Pero mirar cien salidas juntas revela el patrón: está eligiendo sistemáticamente el tipo de contenido más fácil de encontrar.

Tu conjunto de evaluación no puede ver esta clase de patrón por adelantado, porque el conjunto de evaluación se escribe con base en modos de fallo que ya conoces — los modos que no se te ocurrieron naturalmente no tienen casos que los cuiden. La prueba manual no reemplaza a las evaluaciones, les suministra entradas nuevas: cada vez que descubres un patrón así, codifícalo en un caso para que la próxima vez se revise automáticamente.

Otra clase pertenece naturalmente al conjunto de evaluación: los comportamientos que la documentación dice explícitamente que «no están garantizados». La documentación de uso de herramientas ofrece un buen ejemplo — si el prompt del usuario no incluye suficiente información para llenar todos los parámetros requeridos de una herramienta, Claude Opus tiene muchas más probabilidades de reconocer que falta un parámetro y pedirlo; pero la documentación aclara de inmediato que ese comportamiento no está garantizado, especialmente para prompts más ambiguos y para modelos menos capaces⁴.

«Muchas más probabilidades» y «no está garantizado» son señales: si eso se sostiene en tu escenario, lo tienes que probar tú. Cualquier comportamiento del que dependa la lógica de tu producto pero que la documentación solo describa en términos probabilísticos vale la pena monitorearlo con unos pocos casos de forma continua.

El conjunto de evaluación es una regla: primero consigue la regla, después los cambios importan

Retomemos esta lección en conjunto.

La secuencia del artículo de ingeniería de herramientas es: empieza levantando un prototipo rápido de tus herramientas y probándolas localmente, y después ejecuta una evaluación exhaustiva para medir los cambios posteriores². Fíjate en «los cambios posteriores» — la evaluación no es para darle una puntuación al estado actual y darlo por terminado, su valor es volver medibles todos los cambios que vienen después. Con ella, «esta versión del prompt es mejor» pasa de ser una sensación a ser una conclusión.

El artículo sobre construcción de agentes va más lejos: como con cualquier funcionalidad basada en LLM, la clave del éxito es medir el desempeño e iterar sobre las implementaciones; y lo repiten — deberías considerar agregar complejidad solo cuando mejora demostrablemente los resultados⁵.

Esta afirmación pesa cuando se lee en contexto. Las técnicas que aprendiste en los nueve cursos anteriores — división del trabajo multiagente, sistemas de memoria, compactación de contexto, recuperación desde puntos de control — todas y cada una agregan complejidad. Sin un conjunto de evaluación no puedes responder «¿agregar esto realmente mejoró las cosas?», así que solo puedes agregar por instinto, y agregar por instinto significa que sigues agregando. El conjunto de evaluación es la evidencia que te permite quitar un diseño vistoso.

Cuán grande es suficientemente grande: no hay respuesta numérica

Para cerrar, una palabra sobre proporciones.

Busqué en cada fuente primaria que cita este curso, y ninguna da un umbral de «cuántos casos hacen suficiente un conjunto de evaluación». Lo que existe es una escala de arranque (unas 20 consultas reales) y una guía direccional (prioriza cantidad sobre calidad por caso). Así que no salgas a buscar ese número, y no le creas a nadie que cite a la ligera «al menos 50».

El criterio real es con lo que abrió esta lección: dado el tamaño del efecto de tus cambios actuales, ¿tus casos existentes todavía pueden distinguirlos?

• Cambias una versión, la cuenta de aprobados salta de 6 a 15 — suficiente, sigue adelante.
• Cambias una versión, la cuenta de aprobados oscila entre 17 y 18, y ejecutar dos veces da resultados distintos — insuficiente por ahora, momento de agregar casos o de reducir el ruido del método de calificación (repasa la consistencia del juez de la Lección 4).
• Los dos enfoques que quieres comparar difieren en un solo caso — esa no es una pregunta de «cuál es mejor», es una pregunta de «tu regla no resuelve esta diferencia».

La cantidad de casos sigue a la necesidad de resolución, no a algún número psicológico.

En cuanto a cómo ejecutar de verdad este lote de casos — un bucle por tarea, cómo estratificar la calificación, qué rastrear además de la tasa de aprobación — eso es la Lección 6. Lo que necesitas llevarte de esta lección es el lote de casos en sí.

💻 Ejercicios

Resumen

• «Esperemos a tener cientos de casos antes de armar un conjunto de evaluación» es la excusa de demora más común, y el postmortem oficial la refuta directamente: los equipos suelen demorar la creación de evaluaciones porque creen que solo las evaluaciones grandes con cientos de casos sirven, cuando el enfoque correcto es empezar de inmediato con pruebas a pequeña escala con unos pocos ejemplos¹.
• Los conjuntos pequeños sí funcionan al principio, y la base es el tamaño del efecto — un solo retoque del prompt podría subir las tasas de éxito de 30% a 80%, y una brecha así de grande se distingue con apenas unos pocos casos; ellos mismos empezaron con un conjunto de unas 20 consultas que representaban patrones de uso reales¹.
• Las tareas de evaluación deberían estar ancladas en usos del mundo real², reflejar tu distribución real de tareas y tener en cuenta los casos límite³; al mismo tiempo evita los entornos sandbox demasiado simplistas, ya que las tareas de evaluación fuertes podrían requerir varias llamadas a herramientas, potencialmente decenas².
• Estructura las preguntas para permitir calificación automatizada (opción múltiple, coincidencia de cadenas, calificación por código, calificación por LLM)³, y prioriza cantidad sobre calidad — más preguntas con calificación automatizada de señal levemente menor es mejor que menos preguntas con evaluaciones humanas de alta calidad calificadas a mano³.
• Recolecta a propósito una categoría de casos de prueba ambiguos en los que hasta a los humanos les costaría llegar a un consenso de valoración³: no son para subir las puntuaciones, son para sacar a la superficie los desacuerdos en las reglas mismas del producto.
• Cada prompt de evaluación debería estar emparejado con un resultado verificable, con verificadores que van desde la comparación exacta de cadenas hasta reclutar a Claude como juez² — esto se conecta directamente con las Lecciones 2, 3 y 4.
• Los conjuntos de prueba reservados previenen el sobreajuste, y apoyarse en ellos asegura no sobreajustar a las evaluaciones «de entrenamiento»²; las disciplinas centrales son no mirarlos a diario, mirar solo los agregados y retirarlos si se contaminan.
• Las evaluaciones automatizadas tienen puntos ciegos inherentes: las personas que prueban agentes encuentran casos límite que las evaluaciones no ven, incluidas respuestas alucinadas ante consultas inusuales, fallos del sistema y sesgos sutiles de selección de fuentes¹; el ejemplo real es que los agentes iniciales elegían de manera consistente granjas de contenido optimizadas para SEO por encima de fuentes autorizadas pero peor rankeadas, como PDF académicos o blogs personales¹. Incluso con evaluaciones automatizadas, la prueba manual sigue siendo esencial¹.
• Los comportamientos que la documentación dice explícitamente que «no están garantizados» pertenecen naturalmente al conjunto de evaluación, como si el modelo va a pedir por su cuenta los parámetros requeridos que faltan — la documentación declara que ese comportamiento no está garantizado, especialmente para prompts más ambiguos y para modelos menos capaces⁴.
• El valor del conjunto de evaluación es volver medibles todos los cambios posteriores: ejecuta una evaluación exhaustiva para medir los cambios posteriores²; el éxito depende de medir el desempeño e iterar, y la complejidad solo vale la pena agregarla cuando mejora demostrablemente los resultados⁵.
• Ninguna fuente primaria da un umbral numérico de «cuán grande es suficientemente grande». El criterio es: dado el tamaño del efecto de tus cambios actuales, ¿tus casos existentes todavía pueden distinguirlos? Cuando ya no puedas distinguirlos, ese es el momento de ampliar.

>> Lección 6: Práctica: construye un circuito de evaluación para tu agente