Un agente responde bien la pregunta de un cliente. El eval pasa, todo en verde. Por el camino llamó a una API interna de administración que jamás debió tocar, adivinó la mitad de los argumentos y llegó al número correcto por pura suerte. El eval vio «respuesta correcta» y siguió de largo. Acabas de mandar a producción un sistema que tarde o temprano va a llamar a esa misma API con menos suerte.
Una respuesta correcta con la tool call equivocada sigue siendo un bug. Y casi ningún eval de agentes lo detecta, porque califica el output e ignora el camino que lo produjo.
La respuesta no es la acción
En un chatbot el output es el producto, así que puntuar la respuesta basta. En un agente con tools, el output es la punta visible de algo que además leyó datos, llamó a APIs y cambió estado. Dos agentes pueden dar la misma respuesta correcta: uno llamando a la tool correcta con los argumentos correctos y frenando antes del paso irreversible; el otro llamando a la tool equivocada, adivinando parámetros y teniendo suerte. Misma respuesta. Misma nota. Riesgo de producción radicalmente distinto.
Por eso el eval tiene que incluir los efectos secundarios y no solo la transcripción: ¿llamó a la tool correcta, evitó las que no tenía permitidas, pasó los argumentos correctos, frenó antes de la acción irreversible y dejó el evento de auditoría que un humano va a necesitar después? Un eval que solo lee la respuesta final está ciego ante la parte del sistema que sí puede hacer daño.
La investigación ya separa estas señales
Aquí está la pista: incluso en el entrenamiento, el campo dejó de tratar el uso de tools como una recompensa única. ToolRL descompone la recompensa en coincidencia del nombre de la tool, de los nombres de parámetro y de sus valores —tres señales separadas, porque «llamó a una tool» y «llamó bien a la tool correcta» no son lo mismo. THOR usa RL jerárquico y puntúa como objetivos distintos la resolución del problema a nivel de trayectoria y el éxito de ejecución del código a nivel de paso. ReTool intercala ejecución de código con razonamiento y premia cuándo y cómo se invocan las tools, no solo la respuesta que sale al final.
El hilo común cuesta pasarlo por alto: si quienes entrenan estos modelos puntúan la tool call aparte de la respuesta, tu eval de producción —el que decide si un cambio sale— no puede permitirse fundirlas en un único pass/fail.
Qué implica esto para tu forma de evaluar
- Puntúa la trayectoria, no solo la respuesta. El eval que bloquea revisa las tool calls: tool correcta, argumentos correctos, permitida para este usuario y este estado del objeto, frenada antes de lo irreversible y con el evento de auditoría emitido.
- Una respuesta correcta obtenida con una tool call mala es un eval fallido, no aprobado. Acertar por suerte es exactamente el modo de fallo que intentas dejar fuera de producción: pasa hoy y te pasa la factura mañana.
- Solo puedes calificar la tool call si la puedes ver. Eso es un trace, no un log. Y la versión en runtime de esta misma disciplina es un verificador que revisa la acción antes de que dispare el efecto.
En un chatbot, la respuesta es toda la historia. En un agente, la respuesta es lo que ve el cliente, y la tool call es lo que mueve el dinero, toca los datos o reserva el vuelo equivocado. Califica las dos, o estarás entregando un sistema que es correcto hasta el día en que se equivoca caro.