Phase 14 - Lesson 06

Uso de Herramientas y Llamada de Funciones

Toolformer (Schick et al., 2023) inició la anotación autosupervisada de herramientas. Berkeley Function Calling Leaderboard V4 (Patil et al., 2025) establece la barra para 2026: 40% agentic, 30% multi-turn, 10% live, 10% non-live, 10% hallucination. El turno único (single-turn) está resuelto. La memoria, la toma de decisiones dinámica y las cadenas de herramientas de largo horizonte (long-horizon tool chains) no lo están.

Tipo: Construcción Lenguajes: Python (stdlib) Prerrequisitos: Phase 14 · 01 (Agent Loop), Phase 13 · 01 (Function Calling Deep Dive) Tiempo: ~60 minutos

Objetivos de Aprendizaje

• Explicar la señal de entrenamiento autosupervisado de Toolformer: mantener las anotaciones de herramientas solo cuando la ejecución reduzca la pérdida del siguiente token (next-token loss).
• Nombrar las cinco categorías de evaluación de BFCL V4 y qué mide cada una.
• Implementar un registro de herramientas de la biblioteca estándar (stdlib) con validación de esquema, coerción de argumentos y sandboxing de ejecución.
• Diagnosticar los tres problemas abiertos de 2026: encadenamiento de herramientas de largo horizonte (long-horizon tool chaining), toma de decisiones dinámica y memoria.

El Problema

El uso primitivo de herramientas preguntaba: ¿puede el modelo predecir una llamada de función correcta? El uso moderno de herramientas pregunta: ¿puede el modelo encadenar herramientas a lo largo de 40 pasos, con memoria, con observabilidad parcial, con recuperación de fallas de herramientas, sin alucinar herramientas que no existen?

Toolformer estableció la línea de base: los modelos pueden aprender cuándo llamar herramientas con autosupervisión. BFCL V4 define el objetivo de evaluación para 2026. La brecha entre ellos es el espacio en el que viven los agentes de producción.

El Concepto

Toolformer (Schick et al., NeurIPS 2023)

Idea: permitir que el modelo anote su propio corpus de preentrenamiento con llamadas candidatas a API. Para cada candidata, ejecutarla. Mantener la anotación solo si incluir el resultado de la herramienta reduce la pérdida en el siguiente token. Ajustar con precisión (fine-tune) sobre el corpus filtrado.

Herramientas cubiertas: calculadora, sistema de preguntas y respuestas (QA), motores de búsqueda, traductor, calendario. La señal de autosupervisión trata puramente sobre si la herramienta ayuda a predecir el texto, sin etiquetas humanas.

Resultado de escala: el uso de herramientas surge a escala. Los modelos más pequeños se ven perjudicados por las anotaciones de herramientas; los modelos más grandes se benefician. Esta es la razón por la cual los modelos de frontera de 2026 tienen un sólido uso de herramientas integrado, mientras que la mayoría de los modelos de 7B necesitan un ajuste fino explícito de uso de herramientas para ser confiables.

Berkeley Function Calling Leaderboard V4 (Patil et al., ICML 2025)

BFCL es la evaluación de facto para 2026. Composición de V4:

• Agentic (40%) — trayectorias completas del agente: memoria, multi-turn, decisiones dinámicas.
• Multi-Turn (30%) — conversaciones interactivas con cadenas de herramientas.
• Live (10%) — prompts reales enviados por usuarios (distribución más difícil).
• Non-Live (10%) — casos de prueba sintéticos.
• Hallucination (10%) — detectar cuándo no se debe llamar a ninguna herramienta.

V3 introdujo la evaluación basada en el estado: después de una secuencia de herramientas, verificar el estado real de la API (por ejemplo, "¿se ha creado el archivo?") en lugar de coincidir con el AST de las llamadas a herramientas. V4 agregó categorías de búsqueda web, memoria y sensibilidad al formato.

Hallazgo clave de 2026: las llamadas a funciones de un solo turno (single-turn) están casi resueltas. Los fallos se concentran en la memoria (llevar el contexto a través de los turnos), la toma de decisiones dinámica (elegir herramientas en función de los resultados previos), las cadenas de largo horizonte (desviación después de más de 20 pasos) y la detección de alucinaciones (negarse a llamar cuando ninguna herramienta se ajusta).

Esquema de herramientas (Tool schema)

Cada proveedor tiene un esquema. Difieren en los detalles pero comparten la misma estructura:

name: string
description: string (what it does, when to use it)
input_schema: JSON Schema (properties, required, types, enums)

Anthropic usa input_schema directamente. OpenAI usa function.parameters. Ambos aceptan JSON Schema. Las descripciones son cruciales (load-bearing); el modelo las lee para elegir la herramienta correcta. Las descripciones de herramientas deficientes son la causa principal número 1 de los fallos por elección de herramienta incorrecta.

Validación de argumentos

No confíes en ninguna llamada a herramientas. Validar:

1. Coerción de tipos. El modelo puede devolver una cadena "5" donde el esquema especifica int. Coaccionar si no es ambiguo; rechazar en caso contrario.
2. Validación de enum. Si el esquema indica status in {"open", "closed"} y el modelo emite "in_progress", rechazar con un error descriptivo.
3. Campos requeridos. Campo requerido faltante -> observación de error inmediata de vuelta al modelo, no una caída del sistema (crash).
4. Validación de formato. Fechas, correos electrónicos, URLs: validar con analizadores (parsers) concretos, no con expresiones regulares (regex).

Cada fallo de validación debe devolver una observación estructurada para que el modelo pueda volver a intentarlo con la forma correcta.

Llamadas paralelas a herramientas

Los proveedores modernos admiten llamadas paralelas a herramientas en un solo turno del asistente. El bucle:

1. El modelo emite 3 llamadas a herramientas con tool_use_ids distintos.
2. El runtime las ejecuta (en paralelo si son independientes).
3. Cada resultado regresa como un bloque tool_result correlacionado por tool_use_id.

Regra de ingeniería: tratar los IDs de correlación como esenciales (load-bearing). Intercámbialos y obtendrás un enrutamiento de resultado incorrecto a la herramienta equivocada.

Sandboxing

La ejecución de herramientas es el límite del sandbox. Consulta la Lección 09 para más detalles. Versión corta: cada herramienta debe especificar la superficie de lectura/escritura, el acceso a la red, el tiempo de espera (timeout) y el límite de memoria. Un run_shell(cmd) genérico es una señal de alerta; un git_status() específico es más seguro.

Constrúyelo

code/main.py implementa un registro de herramientas con formato de producción:

• Validador de subconjunto de JSON Schema (solo stdlib).
• Registro de herramientas con descripción, esquema de entrada, tiempo de espera (timeout) y ejecutor.
• Coerción de argumentos y validación de enums.
• Despacho paralelo de herramientas con IDs de correlación.
• Observaciones de error como cadenas estructuradas.

Ejecútalo:

python3 code/main.py

El rastreo (trace) muestra a un mini-agente llamando a tres herramientas en un solo turno, con una llamada deliberadamente malformada que es rechazada con un error descriptivo sobre el cual el modelo puede actuar.

Úsalo

Cada proveedor tiene su propio esquema de herramientas: Anthropic, OpenAI, Gemini, Bedrock. Usa una capa de traducción (OpenAI Agents SDK, Vercel AI SDK, adaptador de herramientas de LangChain) si necesitas soporte multiproveedor. BFCL es el benchmark de referencia: ejecútalo contra tu agente antes de lanzarlo si el uso de herramientas es fundamental para el producto.

Envíalo

outputs/skill-tool-registry.md genera un catálogo de herramientas, esquema y registro para un dominio de tareas determinado. Inclui comprobaciones de calidad de la descripción (¿la descripción de cada herramienta le indica al modelo cuándo usarla?).

Ejercicios

1. Agrega una herramienta "no-op" que le permita al modelo rechazar explícitamente el uso de cualquier otra herramienta. Mide el rendimiento en una prueba de alucinación similar a BFCL.
2. Implementa la coerción de argumentos para int-como-cadena y float-como-cadena. ¿Dónde empieza la coerción a ocultar errores reales?
3. Agrega un tiempo de espera (timeout) por herramienta y un disyuntor (circuit breaker: rechazar la herramienta durante 60 segundos después de 3 fallos consecutivos). ¿Qué cambia esto sobre cómo se recupera el modelo?
4. Lee la descripción de BFCL V4. Elige una categoría (por ejemplo, "multi-turn") y ejecuta 10 prompts de ejemplo a través de tu agente. Reporta la tasa de aprobación.
5. Adapta el validador stdlib a Pydantic o Zod. ¿Qué detectaron Pydantic/Zod que la versión de juguete no detectó?

Términos Clave

Lecturas Adicionales

• Schick et al., Toolformer (arXiv:2302.04761) — anotación autosupervisada de herramientas
• Berkeley Function Calling Leaderboard (V4) — benchmark de evaluación de 2026
• Anthropic, Documentación de uso de herramientas — esquema de herramientas en producción en el Claude Agent SDK
• OpenAI Agents SDK docs — tipo de herramienta de función y Guardrails