Cómo evaluar el tool calling de IA: checklist práctica

Una evaluación de tool use empieza por el resultado verificable de la tarea, no por preguntar si el modelo llamó a la función esperada. Fija el estado inicial, la petición del usuario, las herramientas disponibles, los límites de datos y autoridad, los cambios permitidos, el criterio de finalización y los eventos prohibidos. De lo contrario, el exact match con una llamada de referencia premia una sola trayectoria aunque otra ruta segura llegue al mismo resultado correcto.

Separa herramientas de read, propose y mutate. Buscar un documento, preparar un borrador y enviar un correo tienen riesgos distintos y necesitan graders distintos. Para cada fixture, versiona prompt, modelo, tool catalog, schemas, policy y snapshot del sandbox. Las tareas reales deben exigir gestión de ambigüedad, aclaraciones, varias llamadas y manejo de errores, no solo repetir el nombre de una función presente en la solicitud.

• Initial state → registros conocidos, permisos, reloj y dependencias externas.
• Expected outcome → estado final verificable o abstention correcta.
• Allowed trajectory → invariantes obligatorios sin imponer una única ruta.
• Forbidden event → read/write no autorizado, filtración, duplicado o acción sin approval.

Construye slices para selección correcta, confusión entre tools similares, llamada omitida, llamada innecesaria y casos donde no se necesita ninguna herramienta. Prueba por separado entidad desconocida, campo obligatorio ausente, fecha ambigua, tenant incorrecto, identificador stale y solicitudes fuera de autoridad. JSON válido solo demuestra forma: un semantic grader debe verificar que los argumentos coinciden con intención, estado y policy.

Tool precision y recall solo son útiles dentro de un slice concreto. Una alta precisión global puede ocultar que el modelo elige sistemáticamente una herramienta mutating peligrosa en lugar de una comprobación read-only. Añade casos negativos donde lo correcto sea pedir aclaración, rechazar o escalar a una persona. En parallel calls, verifica la independencia de las operaciones y que el resultado no dependa de un orden aleatorio de finalización.

Un mock que siempre devuelve success no prueba tool calling. El entorno de evaluación debe reproducir schema validation, authorization, latency, pagination, rate limits, partial results, timeouts y side effects. Para herramientas mutating, usa una base aislada o un entorno record-replay con read-back autoritativo. El harness registra model proposal, policy verdict, request real, tool response y estado final como eventos separados.

Inyecta fallos controlados: 429 antes de ejecutar, timeout después del commit, evolución de schema, revocación de permisos entre planning y execution, entrega duplicada y estado stale. Tras un resultado incierto, la trayectoria correcta primero reconcilia con una operación read-only en vez de reintentar a ciegas. La idempotency key debe quedar establemente ligada a la intención de la operación; una nueva key aleatoria en cada intento no evita duplicados.

El outcome grader lee el system of record y verifica que se alcanzó el estado requerido. El trajectory grader busca eventos obligatorios y prohibidos: authorization antes de write, approval ligado al payload exacto, ausencia de secretos en arguments, manejo correcto de tool errors y parada tras completar. El side-effect grader cuenta duplicados, writes huérfanos, destinations incorrectos y cambios fuera de scope. Una respuesta final impecable no compensa una acción peligrosa en el trace.

No exijas coincidencia literal de cada paso cuando haya varias trayectorias válidas. El orden exacto importa para invariantes de seguridad—por ejemplo, consultar policy antes de un refund—pero no para dos read calls independientes. Un model grader puede evaluar la calidad de la explicación o si una aclaración era pertinente; permissions, schema, ledger balance y final state deben verificarse de forma determinista. La calibración humana sigue siendo necesaria para criterios de negocio ambiguos.

• Outcome → estado correcto, respuesta o rechazo justificado.
• Trajectory → decisions, calls, policy gates y error transitions correctos.
• Integrity → ningún side effect innecesario, duplicado o no autorizado.
• Efficiency → calls, tokens, latencia y coste por tarea verificada con éxito.

El rendimiento de las herramientas no depende solo del modelo. Nombres, descripciones, overlap, parámetros, formato de respuesta, cantidad de tools disponibles y contexto devuelto cambian el comportamiento del agente. Compara candidate y baseline en un frozen regression set y en un conjunto held-out separado. La ablación de un factor cada vez ayuda a distinguir una mejora de schema de un cambio accidental de sampling o data leakage.

Reporta task success, critical policy violations, validez semántica de argumentos, confusion matrix de tool selection, llamadas innecesarias, recovery success, final-state mismatch, latencia p95 y coste por verified success. Añade repeticiones e intervalos de confianza para runs estocásticos. No traslades un benchmark de proveedor a tu workflow: production catalog, distribución de datos, permisos y superficie de error son diferentes.

El decision record fija dataset, modelo, prompt, catalog, schemas, executor, policy, thresholds, owner y rollback revision. Un unauthorized write crítico, cross-tenant read, exposición de secretos, approval bypass o acción financiera duplicada bloquea el release sin importar el task success medio. Una regresión no crítica puede reducir el catalog, desactivar parallel calls, devolver una herramienta a read-only o exigir human approval.

El rollout pasa por sandbox offline, shadow traffic sin side effects, canary read-only, writes con approval y solo después bounded autonomy. La production telemetry usa el mismo event schema que el eval harness, con controles de redaction y retention. Tras un incidente, primero reconcilia el estado externo, bloquea el tool/version afectado y restaura el known-good envelope; el trace saneado se convierte en regression fixture permanente.