Un agente responde correctamente la pregunta de un cliente. La evaluación pasa, en verde. En el camino, llamó una API interna de admin que nunca debió tocar, adivinó la mitad de los argumentos y llegó al número correcto por suerte. La evaluación vio "respuesta correcta" y siguió de largo. Acabas de enviar a producción un sistema que tarde o temprano va a llamar esa misma API con menos suerte.
Una respuesta correcta desde el tool call equivocado sigue siendo un bug. Y la mayoría de los evals de agentes no lo pueden ver, porque califican el output e ignoran el camino que lo produjo.
La respuesta no es la acción
Para un chatbot, el output es el producto — scorear la respuesta es suficiente. Para un agente que usa tools, el output es la punta visible de algo que además leyó datos, llamó APIs y cambió estado. Dos agentes pueden producir la misma respuesta correcta: uno llamando la tool correcta con los argumentos correctos y deteniéndose antes del paso irreversible, el otro llamando la tool equivocada, adivinando parámetros y teniendo suerte. Misma respuesta. Mismo score de eval. Riesgo de producción radicalmente distinto.
Por eso la evaluación tiene que incluir los efectos secundarios, no solo la transcripción: ¿el agente llamó la tool correcta, evitó las que no tenía permitido, pasó los argumentos correctos, se detuvo antes de la acción irreversible y dejó el evento de auditoría que un humano necesitaría después? Una evaluación que solo lee la respuesta final está ciega a la parte del sistema que de verdad puede hacer daño.
La investigación ya separa estas señales
Aquí está la pista: incluso en tiempo de entrenamiento, el campo dejó de tratar el uso de tools como una sola recompensa. ToolRL descompone la recompensa de tool en coincidencia de nombres de tool, nombres de parámetros y valores de parámetros — tres señales separadas, porque "llamó una tool" y "llamó la tool correcta correctamente" son cosas distintas. THOR usa RL jerárquico que scorea la resolución de problemas a nivel de trayectoria y el éxito de ejecución de código a nivel de paso como objetivos distintos. ReTool intercala ejecución de código con razonamiento y recompensa cuándo y cómo se invocan las tools, no solo la respuesta que sale al final.
El hilo conductor es difícil de pasar por alto: si los investigadores que entrenan estos modelos scorean el tool call por separado de la respuesta, tu eval de producción — lo que decide si un cambio se envía — no puede permitirse colapsarlos en un solo pass/fail.
Qué significa esto para cómo evalúas
- Scorea la trayectoria, no solo la respuesta. La evaluación bloqueante revisa los tool calls: tool correcta, argumentos correctos, permitida para este usuario y este estado del objeto, detenida antes de cualquier cosa irreversible, evento de auditoría emitido.
- Una respuesta correcta alcanzada a través de un tool call malo es una evaluación fallida, no aprobada. Acertar por suerte es precisamente el modo de falla que intentas mantener fuera de producción — pasa hoy y te factura mañana.
- Solo puedes calificar el tool call si lo puedes ver. Eso es un trace, no un log — y la versión en runtime de esta disciplina es un verificador que revisa la acción antes de que se dispare el efecto secundario.
En un chatbot, la respuesta es toda la historia. En un agente, la respuesta es la parte que el cliente ve — y el tool call es la parte que mueve el dinero, toca los datos o reserva el vuelo equivocado. Califica ambas, o estás enviando un sistema que es correcto hasta que se equivoca de forma cara.