Diseña evaluaciones que capturen los pasos del agente, no solo las salidas

Estás a punto de lanzar un agente que puede buscar, editar, llamar herramientas o mover dinero. Si su valor depende del camino que recorre, tus evaluaciones deben puntuar ese camino, no solo la respuesta final.

La mayoría de las evaluaciones de agentes aún solo preguntan si la respuesta llegó. Para un chatbot, eso puede ser suficiente. Para un agente que actúa a través de sistemas, el camino es el producto. Una respuesta correcta producida por un paso prohibido es un fallo de cumplimiento.

Una salida correcta puede ocultar un paso prohibido

En la tarea django-11555, un agente de código entregó una corrección exitosa después de usar una operación grep prohibida, y sin embargo la métrica de salida aprobó la ejecución mientras que la métrica de trayectoria la hizo fallar. El usuario no recibió un parche incorrecto. El usuario recibió un parche hecho por un agente que rompió la regla que debía seguir.

Cuando la regla limita al agente a una ruta de búsqueda permitida, la violación es un problema de enrutamiento. La trayectoria es donde reside la afirmación de seguridad del producto. Una violación de enrutamiento también es una violación de confianza. Si la promesa de tu producto es que el agente se mantiene dentro de una ruta de recuperación segura, las comprobaciones solo de salida pasarán por alto exactamente el comportamiento que hace que los usuarios pierdan la confianza en él. La respuesta final puede parecer pulida. Los registros pueden mostrar que el agente usó una ruta prohibida.

Los diseñadores suelen tratar la trayectoria como un detalle de implementación. Se pierden la interfaz entre el modelo y el sistema. Cada llamada a una herramienta, cada lectura de archivo, cada consulta de búsqueda y cada cambio de estado es una decisión que el usuario no puede ver pero sí puede sentir. Si el agente lee un archivo que no debería leer, o llama a un endpoint que no debería llamar, el usuario puede no saber por qué la respuesta se siente extraña. La evaluación debería detectarlo antes que el usuario.

Puntuaciones de salida estables pueden ocultar comportamiento inestable

La evaluación utilizó 30 tareas de Django de la misma época del codebase. En esa comparación, la aplicación mediante prompt simple cumplió la regla de solo búsqueda vectorial el 77% de las veces; la aplicación mediante bandera de herramienta la cumplió el 60% de las veces. Si solo rastreas la respuesta final, no verás qué mecanismo de aplicación está haciendo el trabajo.

En las variantes de generación aumentada por recuperación, test_passed se mantuvo en el rango del 70% al 77%, mientras que el cumplimiento de solo búsqueda vectorial osciló entre el 60% y el 100%. La calidad de la salida puede parecer estable mientras el comportamiento oscila enormemente. Diseñar para la media lanza las excepciones.

Mantén la puntuación de comportamiento separada de la calidad de la salida. No promedies una puntuación de cumplimiento dentro de una puntuación de calidad. Un panel que mezcle ambas puntuaciones mostrará una media saludable y una regla rota. Un eje pregunta si la respuesta es útil. El otro pregunta si el agente se mantuvo dentro de las reglas que hacen que el producto sea seguro, auditable y soportable. Cuando los ejes divergen, usa esa divergencia para decidir qué corregir antes del lanzamiento.

Dos puntuadores pueden compartir un punto ciego

Las comprobaciones deterministas pueden ser frágiles. Pueden malinterpretar un registro, sobrecontar una fuga o marcar un paso inofensivo. Una comprobación puede estar mal, pero una comprobación incorrecta es visible y corregible. La primera comprobación determinista de fugas sobrecontó las fugas por un factor de cuatro, y el juez LLM cometió el mismo error. El acuerdo entre dos puntuadores puede ser ceguera compartida.

Una métrica de agente mide, en números o juicios, qué tan bien un agente cumplió su objetivo; un puntuador es una rutina basada en código o en juez LLM que la calcula. Si la métrica pregunta si el agente se mantuvo dentro de las herramientas permitidas, el puntuador debe inspeccionar la trayectoria, no solo la respuesta final. Si la métrica pregunta si la respuesta cumplió el comportamiento requerido, un juez de modelo puede ayudar, pero un puntuador determinista sigue siendo el responsable de los pasos prohibidos.

Audita el puntuador antes de confiar en la puntuación. Ejecuta un pequeño conjunto de trayectorias conocidas como correctas y conocidas como incorrectas. Verifica que el puntuador determinista marque las incorrectas e ignore las inofensivas. Verifica que el juez de modelo no herede el mismo punto ciego. Corrige el puntuador antes de actuar sobre la puntuación.

Puntúa la regla y luego haz fallar la ejecución

El rediseño es una regla de evaluación de trayectoria. Lista los pasos que deben ocurrir, los pasos que no deben ocurrir, y adjunta una comprobación determinista a cada uno. Si alguna comprobación falla, la ejecución falla, incluso cuando la salida pasa.

• Escribe la regla como un paso: el agente debe usar la ruta de solo búsqueda vectorial y no debe usar el comando grep prohibido.
• Adjunta un puntuador determinista a cada paso, comprobando las llamadas reales a herramientas, los accesos a archivos o los eventos de API.
• Haz fallar la ejecución ante cualquier violación, y luego reporta la puntuación de salida y la puntuación de comportamiento por separado.

Cuando la salida pasa pero la trayectoria falla, bloquea la ejecución, repara el paso y vuelve a ejecutar la evaluación.