Schemas de herramientas y funciones

La llamada de funciones permite que un modelo solicite que su código ejecute una acción. Cada herramienta se declara con un nombre, una descripción (que indica cuándo usarla) y un JSON Schema para sus parámetros.

El modelo nunca ejecuta código; emite una solicitud de llamada estructurada que su entorno de ejecución distribuye. El esquema es lo que hace que los argumentos se puedan analizar.

Una definición de herramienta es una declaración de una capacidad respaldada por un esquema.

Cuando hay muchas herramientas disponibles, el modelo elige principalmente según la descripción. Escriba las descripciones como reglas de decisión:

• Indique cuándo usarla y cuándo no.
• Diferénciela de las herramientas similares.
• Mencione los requisitos previos necesarios.

Las descripciones deficientes provocan una selección incorrecta de herramientas con más frecuencia que los esquemas deficientes provocan errores en los argumentos.

La llamada de funciones es multiturno. El modelo hace una llamada, usted la ejecuta, añade el resultado y el modelo continúa.

Los modelos modernos pueden solicitar varias llamadas a herramientas en un mismo turno cuando las acciones son independientes. Su entorno de ejecución debe iterar sobre todas las tool_calls, ejecutarlas (idealmente de forma concurrente) y devolver un mensaje de herramienta por cada tool_call_id.

Nunca dé por hecho que habrá una sola llamada; itere siempre.

Controle la selección con tool_choice:

• auto — el modelo decide.
• required — debe llamar a alguna herramienta.
• {name: ...} — fuerza una herramienta específica.
• none — desactiva las herramientas durante este turno.

Forzar una herramienta específica convierte la llamada de funciones en una extracción puramente estructurada.

Incluso con esquemas estrictos, trate los argumentos de las herramientas como entradas no confiables. Vuelva a validarlos según el esquema y aplique las reglas de negocio antes de interactuar con sistemas reales (bases de datos, pagos o borrado de archivos).

Cuando una herramienta falla, devuelva un error estructurado como resultado de la herramienta en lugar de lanzar una excepción. El modelo podrá disculparse, reintentar con argumentos corregidos o elegir otra herramienta.

Haga que los errores sean accionables: incluya un motivo y, cuando sea seguro, una indicación para recuperarse.

Docenas de herramientas degradan la precisión de selección y aumentan el coste en tokens (cada esquema está en el contexto en cada turno). Medidas paliativas:

• Agrupe acciones relacionadas detrás de una herramienta con un enum action.
• Exponga dinámicamente solo las herramientas relevantes para el estado actual.
• Use espacios de nombres para reducir la confusión entre herramientas similares.

Para las acciones destructivas, incorpore la seguridad en el propio esquema: exija un campo de confirmación explícito, limite los rangos y evite los identificadores de texto libre en favor de enumeraciones o patrones validados.

Trate la selección de herramientas como un comportamiento medible. Cree un conjunto de evaluación de prompts asociados con la herramienta y los argumentos esperados, y compruebe que el modelo elija correctamente. Realice un seguimiento de las regresiones cuando reformule las descripciones o añada herramientas nuevas.

Un modelo emite dos tool_calls independientes en un mismo turno del asistente. ¿Qué debe hacer el entorno de ejecución?

Esquemas de herramientas y funciones en la práctica:

• Las descripciones determinan la selección; los esquemas determinan argumentos analizables.
• Recorra todas las tool_calls; admita la ejecución en paralelo.
• Controle el comportamiento con tool_choice; fuerce una herramienta para la extracción pura.
• Vuelva a validar los argumentos y devuelva errores estructurados.
• Mantenga reducida la superficie de herramientas y refuerce la seguridad de las acciones destructivas.

A continuación: bucles de reparación y validación para cuando la salida siga siendo incorrecta.