Lección 2: Qué verificar: primero el estado final, el proceso como respaldo

Objetivos de aprendizaje:

• Entender por qué «registrar los pasos correctos y después cotejarlos uno por uno» está condenado a juzgar mal a los agentes, y cambiar a la evaluación del estado final
• Para los flujos de trabajo complejos, identificar unos pocos puntos de control de verificación discretos que confirmen que «ocurrieron los cambios de estado esperados», en lugar de validar cada paso
• Convertir un requisito vago en criterios de éxito medibles, alcanzables y multidimensionales, y saber hasta dónde llevar las aserciones de trayectoria

Requisitos: Terminaste la Lección 1 y sabes que, cuando no hay una comprobación que se pueda ejecutar, tú te conviertes en el bucle de verificación | Anterior: Lección 1 << | Siguiente: Lección 3 >>

Tres ejecuciones, tres veredictos de «falló»

Decides agregarle verificación a tu agente. El primer impulso es casi universal: registrar el «enfoque estándar». Recorres la tarea a mano una vez, anotas cada paso —el paso 1 debería llamar a search, el paso 2 debería llamar a fetch_page, el paso 3 debería llamar a write_note— y guardas eso como la clave de respuestas. De ahí en adelante, cada vez que el agente se ejecuta, cotejas su secuencia de llamadas con esa respuesta, paso por paso. Una discrepancia y falla.

La ejecutas tres veces. Tres fallas.

Revisas las salidas: tres resúmenes, hechos correctos, fuentes confiables, todos los ángulos pedidos cubiertos. La única diferencia fue el camino: la primera ejecución buscó en tres fuentes y con eso alcanzó, la segunda buscó en diez, la tercera buscó primero las definiciones de la terminología antes de ponerse a buscar. Esto es exactamente lo que Anthropic observó en su propio sistema multiagente de investigación: incluso con puntos de partida idénticos, los agentes podrían tomar caminos válidos completamente distintos para llegar a su objetivo, uno buscando en tres fuentes mientras otro busca en diez, o usando herramientas distintas para encontrar la misma respuesta¹.

Lo que falló no fue el agente. Fue tu método de verificación.

En realidad no sabes cuáles son los «pasos correctos»

La evaluación tradicional carga con un supuesto por defecto enterrado bien hondo: dada la entrada X, el sistema debería seguir el camino Y y producir la salida Z, los mismos pasos cada vez¹. Este supuesto se sostiene con tanta naturalidad en los sistemas deterministas que la mayoría nunca se da cuenta de que es un supuesto. Los agentes lo dan vuelta de inmediato.

Lo verdaderamente incómodo no es solo que «el camino va a variar»; es esta oración:

"Because we don’t always know what the right steps are, we usually can't just check if agents followed the “correct” steps we prescribed in advance. Instead, we need flexible evaluation methods that judge whether agents achieved the right outcomes while also following a reasonable process."¹

(Como no siempre sabemos cuáles son los pasos correctos, por lo general no podemos limitarnos a comprobar si los agentes siguieron los pasos «correctos» que prescribimos de antemano. En cambio, necesitamos métodos de evaluación flexibles que juzguen si los agentes alcanzaron los resultados correctos siguiendo además un proceso razonable.)

«No siempre sabemos cuáles son los pasos correctos»: esa es la clave. El camino que registraste no es el único camino correcto. Es solo el camino que te tocó tomar esa vez. Lo elevaste a clave de respuestas, y así todo otro enfoque se convirtió en un error.

Fíjate en la segunda mitad: «siguiendo además un proceso razonable». Esto no significa ignorar el proceso por completo. Significa no usar un camino fijo como vara de medir.

Evaluación del estado final: juzgar resultados, no el flujo

El enfoque de Anthropic es directo: concentrarse en la evaluación del estado final en lugar del análisis turno por turno; no juzgues si el agente siguió un proceso específico, juzga si alcanzó el estado final correcto¹. Este enfoque reconoce que los agentes pueden encontrar caminos alternativos hacia la misma meta, sin dejar de asegurar que entreguen el resultado buscado¹.

Primero, una definición en palabras llanas de «estado final»: después de que la tarea termina, el estado que puedes observar en el entorno y verificar a posteriori. Qué archivos aparecieron en el sistema de archivos, qué valores tienen ahora los campos de ese registro de base de datos, qué etiqueta lleva el ticket, si el JSON devuelto trae status: "resolved".

Una prueba de tornasol útil: el estado final es un sustantivo, no un verbo. «Llamó a rename_file» es un verbo; «todos los nombres de archivo cumplen cierto formato» es un sustantivo. La verificación solo acepta sustantivos.

Tarea: renombrar los PDF de facturas de downloads/ a "fecha_proveedor.pdf"
Verificación por pasos (frágil)        Verificación del estado final (estable)1. Llamar a list_files                 downloads/ ya no tiene los nombres originales2. Llamar a read_pdf para cada uno     Cada nombre cumple ^\d{8}_[a-z0-9-]+\.pdf$3. Llamar a extract_date               La cantidad de archivos coincide con la previa, nada perdido ni agregado4. Llamar a rename_file para cada uno  Las fechas de los nombres coinciden con las fechas de las facturas en el PDF

La columna izquierda falla en el momento en que el agente usa una lectura por lotes en vez de cuatro lecturas individuales, aunque los resultados sean idénticos. A la columna derecha no le importa cómo lee, porque describe «cómo se ve downloads/ ahora», sin relación con cómo llegó a ese estado.

Hay un punto fácil de pasar por alto al escribir aserciones de estado final: anota también lo que no debería cambiar. Esa línea de arriba, «la cantidad de archivos coincide con la previa», es una de ellas. Si el agente renombra dos archivos con el mismo nombre y el segundo sobrescribe al primero, la comprobación de «todos los nombres son válidos» pasa a la perfección. Las aserciones de estado final tienen que proteger las dos cosas: que «los cambios esperados ocurrieron» y que «los cambios inesperados no».

Flujos de trabajo complejos: repartir la evaluación entre puntos de control

La evaluación del estado final no es «ignorar el proceso por completo». La oración que sigue en la fuente da una salida: para los flujos de trabajo complejos, divide la evaluación en puntos de control discretos donde deberían haber ocurrido cambios de estado específicos, en lugar de intentar validar cada paso intermedio¹.

Fíjate en la formulación: «deberían haber ocurrido cambios de estado específicos», sigue siendo estado, siguen siendo sustantivos. Solo se mueve el punto de observación de «la línea de meta» a «unos pocos lugares del camino».

Aviso de colisión de términos: el «punto de control» del curso 9 de esta serie se refiere a guardar el contexto: escribir en disco el estado en ejecución del agente para que pueda retomar desde ahí después de una caída, con fines de recuperación. El «punto de control» de esta lección se refiere a verificar el estado: confirmar que los cambios de estado esperados ocurrieron en cierto punto del flujo, con fines de validación. Las posiciones a menudo se superponen (que donde pones un punto de control también verifiques es natural), pero resuelven problemas distintos. Mezclarlos en la discusión lleva a confusión, así que de aquí en adelante llamaremos a estos «puntos de control de verificación» y a los del curso 9 «puntos de control de recuperación».

Para saber cuándo vale la pena agregar un punto de control de verificación, mira tres cosas:

• Flujo de trabajo largo, estado final demasiado lejos del inicio. Cuando falla solo sabes que «no llegó al final», no dónde empezó la desviación.
• Operaciones irreversibles. Correos enviados, inventario descontado, archivos sobrescritos: para cuando el estado final revela el error, ya es tarde.
• La salida intermedia es la base de los pasos siguientes. El script de migración crea la tabla y después carga los datos; si la estructura de la tabla está mal, todos los datos cargados son basura y el costo de rehacer se multiplica.

Si no aplica ninguna, no agregues ninguno.

Dónde agregarlos: en las posiciones donde el estado sufre un cambio sustantivo, no después de cada llamada a herramienta.

Tarea: migrar la tabla de usuarios del esquema viejo al esquema nuevo
Punto de control de verificación 1 (tras crear la tabla): la tabla new_users existe, las columnas coinciden exactamente con el esquema objetivoPunto de control de verificación 2 (tras cargar los datos): filas de new_users == filas de old_users, sin claves primarias duplicadasEstado final: la app lee la tabla nueva y pasa la prueba de humo (la comprobación más básica de «¿arranca?»), old_users renombrada a old_users_backup
Qué no comprobamos: si escribió CREATE TABLE o copió de una plantilla,si cargó todo de una vez o por lotes, cuántos lotes, cuántas filas por lote.

Dos puntos de control, un estado final. Tres aserciones gobiernan la migración entera. Si te fueras por «validar cada paso intermedio», este flujo de trabajo podría generar decenas de aserciones, la mayoría penalizando diferencias legítimas de implementación.

Detente aquí: qué tiene de malo esta propuesta

Cómo definir los criterios de éxito: medibles, alcanzables, multidimensionales

Esas tres palabras, «estado final correcto», tienen que aterrizar en números concretos o en juicios claros; si no, volviste en círculo a «se ve bien». La documentación oficial da dos requisitos duros para los criterios de éxito:

• Medibles: usa métricas cuantitativas o escalas cualitativas bien definidas (una escala es una lista de verificación con una rúbrica de puntuación; los detalles de cómo escribir una son contenido de la Lección 4). Los números aportan claridad y escalabilidad, pero las medidas cualitativas pueden ser valiosas si se aplican de manera consistente junto con las cuantitativas².
• Alcanzables: basa tus objetivos en referencias de la industria, experimentos previos, investigación en IA o conocimiento experto. Tus métricas de éxito no deberían ser irreales para las capacidades actuales de los modelos de frontera².

Y uno más: la mayoría de los casos de uso necesitan una evaluación multidimensional a lo largo de varios criterios de éxito².

El ejemplo completo de la documentación oficial es una sola oración (las anotaciones entre paréntesis son del original):

"The sentiment analysis model should achieve an F1 score of at least 0.85 (Measurable, Specific) on a held-out test set* of 10,000 diverse Twitter posts (Relevant), which is a 5% improvement over the current baseline (Achievable)."²

(El modelo de análisis de sentimiento debería alcanzar un puntaje F1 de al menos 0.85 (medible, específico) sobre un conjunto de prueba reservado de 10,000 publicaciones diversas de Twitter (relevante), lo que representa una mejora del 5% sobre la línea base actual (alcanzable).)

Vale la pena desarmar esta oración porque cada componente bloquea un modo de falla específico:

Esa última fila es el método concreto de «alcanzable»: el umbral no se deduce hacia atrás desde los deseos; es un paso chico hacia adelante desde el estado actual. Si no tienes línea base, ejecuta una versión de la implementación más ingenua y usa su puntaje como línea base. Cuando ni siquiera puedes ejecutar una línea base, no te apures a fijar números.

Hay una pregunta todavía más temprana. Cuando Anthropic describe los escenarios apropiados para agentes, dice: los agentes aportan más valor en las tareas que requieren tanto conversación como acción, tienen criterios de éxito claros, habilitan bucles de retroalimentación e integran una supervisión humana significativa³. Léelo al revés: si no logras escribir criterios de éxito para esta tarea de ninguna manera, el problema no es el paso de verificación; esta tarea no debería haberse entregado por completo al agente para que la ejecute solo. Si no puedes escribir criterios, te toca mirar todo el proceso, y como decía la Lección 1, en ese punto tú te conviertes en el bucle de verificación.

Aserciones de trayectoria: puedes agregarlas, pero no las fijes en duro

La evaluación del estado final atrapa el «¿el resultado es correcto?», pero se le escapa una clase de problema: si el agente de verdad reconoce esa herramienta nueva que le diste.

La documentación oficial ofrece un agregado opcional: para cada par de prompt y respuesta, opcionalmente también puedes especificar las herramientas que esperas que el agente llame para resolver la tarea, y así medir si los agentes captan bien el propósito de cada herramienta durante la evaluación⁴. Esto es una aserción de trayectoria: no juzga el orden, no juzga la cantidad, solo juzga si ciertas herramientas aparecieron en la trayectoria.

Cuándo sirve: acabas de agregar una herramienta search_internal_docs y quieres que el agente la use para las preguntas sobre procesos internos. Pero se va a buscar en la web pública, encuentra una respuesta lo bastante parecida, y la validación del estado final igual pasa. Solo la trayectoria puede ver esa diferencia.

El límite está escrito en la oración inmediatamente siguiente: como puede haber varios caminos válidos para resolver las tareas correctamente, intenta evitar la sobreespecificación o el sobreajuste a estrategias⁴.

Límites concretos:

• Comprueba solo la pertenencia al conjunto, no el orden ni la cantidad
• Lista solo la herramienta —o las dos— que de verdad te importan; no copies la secuencia entera ahí dentro: eso es grabar y reproducir otra vez
• Si la aserción de trayectoria falla pero el estado final pasa: registra una observación, no hagas fallar la evaluación entera
• Es un agregado opcional, no el valor por defecto. El valor por defecto sigue siendo el estado final¹

Más allá de la tasa de aprobación: qué más registrar

Después de una ejecución de evaluación, si lo único que obtienes es una tasa de aprobación, te vas a quedar sin nada que decir: ¿qué significa 78%? ¿Lo próximo que deberías ajustar es el prompt o las herramientas?

La documentación oficial recomienda recolectar estas métricas además de la exactitud de alto nivel: el tiempo total de ejecución de las llamadas a herramientas individuales y de las tareas, la cantidad total de llamadas a herramientas, el consumo total de tokens y los errores de herramientas⁴. Estas métricas no participan del juicio; participan del diagnóstico.

La documentación oficial da dos lecturas:

• Muchas llamadas a herramientas redundantes podrían sugerir que conviene dimensionar mejor los parámetros de paginación o de límite de tokens⁴
• Muchos errores de herramientas por parámetros inválidos podrían sugerir que a las herramientas les vendrían bien descripciones más claras o mejores ejemplos⁴

Lo que comparten: apuntan el dedo al diseño de las herramientas, no al modelo. Muchas llamadas redundantes suelen significar que solo puede traer 20 ítems por vez y entonces tiene que paginar por diez páginas; muchos errores de parámetros suelen significar que la descripción de la herramienta no explicó qué formato necesita ese campo. Estos problemas tienen su raíz del lado de las herramientas: agregarle al prompt de sistema un «llama menos seguido» o un «escribe los parámetros con cuidado» por lo general no funciona; hay que ajustar el diseño de parámetros de la herramienta y su descripción.

Tirando de este hilo salen algunos más (lo de abajo no está avalado oficialmente, son juicios de ingeniería extrapolados de los dos anteriores: verifícalos con tus propios datos): tasa de aprobación sin cambios pero consumo de tokens duplicado significa que este cambio no es gratis; una categoría de tareas con una varianza de duración especialmente grande probablemente esconde reintentos o vueltas en círculo; errores concentrados en una sola herramienta, mira primero esa herramienta, no sospeches del prompt.

Una ejecución de evaluación debería volcar al menos estas columnas; la Lección 6, al construir el arnés de evaluación, las va a usar directamente (para ahorrar ancho de columna, los tokens de entrada y de salida se van a fusionar en uno):

case_id | passed | duration_ms | tool_calls | tokens_in | tokens_out | tool_errors

Límites: tres cosas que no hay que hacer

Uno: no intentes validar cada paso intermedio¹. Este es el límite más fácil de romper de esta lección, porque la intuición de que «verificar más es más seguro» es muy fuerte. El resultado real es el opuesto: cuanto más finas son las aserciones, más diferencias legítimas quedan penalizadas, más ruidosa se vuelve la evaluación, hasta que empiezas a ignorar el rojo, y en ese punto ya no sirve para nada.

Dos: no conviertas las aserciones de trayectoria en el valor por defecto. Agregar una aserción de trayectoria es tan barato que puedes escribir otra entrada de expectedTools sin esfuerzo. Para la décima entrada ya estás prescribiendo estrategia en lo sustancial, y solo en lo formal lo sigues llamando «aserción». Cada vez que agregas una, pregúntate: ¿la salida de verdad se rompe si no se llama a esta herramienta? Si la respuesta es «no necesariamente», no la agregues.

Tres: no fijes los umbrales después de la ejecución. Mirar un puntaje de 0.82 y decir «con 0.8 debería alcanzar», y mirar 0.86 y decir «tiene que ser 0.85», son el mismo autoengaño. Fija los umbrales antes de la ejecución y anota la justificación.

💻 Ejercicios

Resumen

• La evaluación tradicional supone «dada la entrada X, sigue el camino Y, obtén la salida Z»; los agentes no cumplen ese supuesto: puntos de partida idénticos pueden aun así tomar caminos completamente distintos pero válidos, uno buscando en tres fuentes y otro en diez¹
• No siempre sabes cuáles son los pasos correctos, así que por lo general no puedes comprobar si los agentes siguieron los pasos que prescribiste; usa métodos de evaluación flexibles que juzguen si alcanzaron los resultados correctos siguiendo un proceso razonable¹
• El enfoque por defecto es la evaluación del estado final y no el análisis turno por turno: no juzgues si siguió un proceso específico, juzga si alcanzó el estado final correcto¹. El estado final son sustantivos y no verbos, y tiene que proteger las dos cosas: que «los cambios esperados ocurrieron» y que «los cambios inesperados no»
• Para los flujos de trabajo complejos, divide la evaluación en puntos de control discretos que confirmen que «deberían haber ocurrido cambios de estado específicos», no intentes validar cada paso intermedio¹. El «punto de control» de aquí se refiere a verificar el estado, distinto del punto de control de guardado de contexto del curso 9
• Los criterios de éxito deben ser medibles (métricas cuantitativas o escalas cualitativas bien definidas) y alcanzables (basar los objetivos en referencias de la industria, experimentos previos o conocimiento experto), y la mayoría de los casos de uso necesitan una evaluación multidimensional²
• La documentación oficial lista «tener criterios de éxito claros, habilitar bucles de retroalimentación» entre las condiciones donde los agentes aportan más valor³; léelo al revés: las tareas para las que no puedes escribir criterios de éxito no deberían entregarse por completo a los agentes para que las ejecuten solos; te va a tocar mirar todo el tiempo
• Las aserciones de trayectoria son un agregado opcional: puedes especificar qué herramientas esperas que llame, para medir si capta el propósito de las herramientas, pero como los caminos válidos no son uno solo, evita la sobreespecificación y el sobreajuste a estrategias⁴
• Más allá de la tasa de aprobación, registra también el tiempo de ejecución, la cantidad de llamadas, el consumo de tokens y los errores de herramientas; con muchas llamadas redundantes considera ajustar los parámetros de paginación y de límite de tokens, y con muchos errores de parámetros inválidos considera hacer más claras las descripciones y los ejemplos de las herramientas⁴

>> Lección 3: Verificadores deterministas: solo cuentan las comprobaciones que dan aprobado/fallido