Testing y evals para agentes

El código común es fácil de verificar: si una función recibe 2 y 2 y no devuelve 4, hay un bug. Un agenteAgente Sistema en el que un modelo, dentro de un bucle, elige la siguiente acción hasta decidir que terminó o alcanzar una condición de parada. no funciona así. Entre el pedido y el resultado hay decisiones de un modelo, que no se pueden leer como código, rara vez tienen una única respuesta correcta y cambian cada vez que cambian el promptPrompt Todo lo que se envía al modelo en una llamada: instrucciones, mensajes de la conversación y las definiciones de herramientas, si las hay., las herramientas o el modelo.

La salida es separar el sistema en dos. Casi todo lo que rodea al modelo (el loop que lo llama, las reglas sobre lo que puede hacer, el código que lee sus respuestas) se comporta igual cada vez, y se testea como cualquier software. Las decisiones del modelo se evalúan, con otras herramientas y otras expectativas.

Esta lección cubre cuatro ideas: por qué tests y evalsEval Medición de qué tan bien se comporta el sistema completo en casos realistas, incluidos los pasos que dio en el camino, calificada con verificaciones imperfectas y leída con estadística. son distintos, cómo reemplazar al modelo durante los tests, cómo proteger el diseño mismo y qué debe medir una eval de agentes, incluido por qué un control que no puede fallar es peor que no tener ninguno.

Tests y evals no son lo mismo

Los dos errores comunes son simétricos: testear todo contra un modelo real con verificaciones exactas (tests lentos, caros y que fallan al azar), o no correr nunca contra un modelo real (tests en verde, producto roto). Los tests no prueban que el agente resuelva tareas; las evals no revelan un camino del código que se salta el control de permisos.

Reemplazar al modelo

Para testear el código que rodea al modelo, se reemplaza el modelo por un doble que sigue un guion: devuelve una lista fija de respuestas, incluidos pedidos de usar herramientas, y registra lo que recibió. Eso es un modelo falsoModelo falso Sustituto guionado de un modelo real, para que las pruebas del código que lo rodea den siempre el mismo resultado.. Permite provocar a propósito lo que un modelo real hace rara vez, como una salida rota, una herramienta que no existe o un intento de escribir fuera de su carpeta, y verificar que el sistema reacciona bien.

Es una buena regla general: falsea el modelo, no el protocolo. Si también falseas la capa de red y el formato de los mensajes, no te enterarás el día en que el proveedor cambie un campo.

Proteger el diseño, no solo el comportamiento

Algunas garantías tratan de cómo está construido el sistema. Una común: "toda llamada a herramienta pasa por un único punto de control", donde se revisan los permisos y se registra la acción. Un test normal prueba que el camino de hoy pasa por ese punto. No puede probar que nadie agregó un segundo camino que lo evita.

Para eso, un test puede leer el código fuente y fallar si se rompe la regla, por ejemplo si el punto de control se llama desde más de un lugar. Estos tests protegen invariantes de arquitectura: reglas sobre la forma del código que deben seguir siendo ciertas a medida que crece.

Los lugares donde dos partes se encuentran necesitan sus propios controles. Cuando otro programa lee tu salida, su formato es una promesa, así que docket hace fallar un test si el esquema publicado de su salida se aparta del código en un solo byte (Harness mode (ADR 0001)). Y dos partes testeadas por separado pueden fallar juntas: en docket, un cambio escribía un rechazo como texto plano mientras otro lo leía con un patrón, y juntos perdían los detalles. El arreglo fue una sola función dueña del formato, más un test que usa juntos el escritor real y el lector real.

Qué mide una eval de agentes

Una eval de agentes mira varias cosas a la vez:

• Resultado: ¿el producto final es correcto? Para código: compila, pasan los tests del proyecto y también tests ocultos que el agente nunca vio.
• Trayectoria: ¿el camino fue razonable? ¿Tocó archivos prohibidos, intentó comandos peligrosos o editó un test para que pasara?
• Costo: turnos, tokensToken Pedacito de texto, a menudo parte de una palabra, que el modelo lee y escribe y por el que cobran los proveedores. y tiempo.
• Seguridad: cómo maneja casos hostiles, como instrucciones escondidas en los datos que lee.

Dos agentes con la misma tarea. Mira el camino que siguió cada uno, no solo el resultado:

Agente A: buscar → leer → editar → correr tests → listo          5 pasos  12k tokens
Agente B: leer ×14 → reescribir el test que falla para que pase
          → editar código → correr tests → listo                21 pasos  80k tokens

Una eval que solo mira el resultado les da la misma nota. Una eval de trayectoria descubre que B costó seis veces más y "pasó" cambiando el test que debía juzgarlo.

Cuando no hay una verificación exacta ("¿esta respuesta es útil?"), un enfoque común es LLM-as-a-judgeLLM-as-a-judge Usar un modelo para calificar salidas; es confiable a escala solo después de contrastar sus notas con las de personas.: otro modelo califica el resultado.

Esa eliminación es la lección: una eval que no puede fallar es peor que no tener eval, porque produce falsa confianza. Para evaluar los modelos en sí, mira Evaluar modelos.

En la práctica

• Corre ambas mitades. Tests rápidos y exactos en cada cambio; evals con el modelo real tan seguido como permita el presupuestoPresupuesto Límite duro sobre tokens, llamadas, tiempo o dinero, aplicado antes de gastar el recurso., por ejemplo un conjunto pequeño en cada cambio y el completo antes de cambiar de modelo.
• Mira el camino, no solo el puntaje. Una tasa de éxito esconde agentes que hacen trampa o desperdician.
• Convierte cada incidente de producción en un caso de eval, para que la misma falla no vuelva sin que nadie lo note.
• Asegúrate de que cada control pueda ponerse en rojo. Rompe una vez, a propósito, lo que protege y mira cómo falla.

Para profundizar

La documentación de docket muestra cómo separa la evidencia sobre su propio código de la evidencia sobre los modelos (en inglés):

• Adoption evidence publica los resultados de los escenarios guionados, cuenta las detenciones seguras como fallas y dice con claridad qué no miden.
• Harness mode (ADR 0001) explica por qué el formato de salida de docket tiene versión para un programa externo y está fijado por un test que regenera el esquema y lo compara.
• Development harness and context policy describe cómo se califican los cambios en las skills de los agentes: un agente nuevo hace la tarea, y una rúbrica que nunca ve juzga los archivos, los diffs y los códigos de salida, no la redacción.
• Models, gateways, and coding harnesses aconseja elegir un modelo solo después de evals con tus herramientas y tareas reales, y deja las pruebas con modelos en vivo como opcionales.

Para llevar

• Testea lo que se comporta igual cada vez; evalúa las decisiones del modelo con tasas sobre muchas corridas.
• Reemplaza el modelo por un falso guionado en los tests, pero conserva el formato real de los mensajes.
• Los tests que leen el código protegen reglas de diseño, como un único punto de control, que los tests de comportamiento no pueden.
• Una eval de agentes mira resultado, trayectoria, costo y seguridad; un modelo juez necesita calibrarse primero.
• Una eval o un control que no puede fallar produce falsa confianza.

Comprueba lo aprendido