Function calling es el mecanismo que permite que un modelo de OpenAI deje de solo "hablar" y empiece a activar código real: consultar una base de datos, ejecutar una acción de negocio, o devolver datos en un formato exacto que tu sistema puede procesar sin parsear texto libre.
Antes de function calling, integrar un LLM con un sistema real significaba pedirle "responde en JSON" y rezar porque el formato fuera consistente, además de parsear con regex frágil. Function calling (renombrado `tools` en la API actual) resuelve esto de raíz: defines funciones disponibles con un JSON Schema estricto, y el modelo devuelve una llamada estructurada y validable a esa función cuando decide que es necesaria, en lugar de texto libre.
Es importante entender que el modelo nunca ejecuta la función directamente — solo genera la intención estructurada (nombre de función + argumentos). Tu código es responsable de ejecutarla y devolver el resultado al modelo en un turno siguiente.
El ciclo completo requiere un segundo turno donde le devuelves al modelo el resultado real de ejecutar la función, para que formule la respuesta final en lenguaje natural.
Los modelos actuales pueden solicitar múltiples llamadas a funciones en un solo turno cuando la tarea lo requiere (por ejemplo, "dame el clima de Guatemala y de Ciudad de México"). Tu código debe iterar sobre `tool_calls` (que es una lista) y responder cada una con su `tool_call_id` correspondiente antes del siguiente turno — omitir alguna causa un error de la API porque espera una respuesta por cada llamada pendiente.
Con `strict: true` en la definición de la función (o usando `response_format` con un JSON Schema para salidas directas sin function calling), la API garantiza que la salida cumple exactamente el esquema definido — sin campos faltantes, sin tipos incorrectos, sin necesidad de validación adicional ni reintentos por JSON malformado. Esto fue una limitación real en versiones anteriores del API, donde el modelo ocasionalmente producía JSON casi válido pero no perfecto.
Los patrones más comunes en implementaciones empresariales: routers de intención (una función `escalar_a_humano` que el modelo invoca cuando detecta frustración o un tema fuera de su alcance), agentes de consulta (funciones de solo lectura hacia bases de datos, con el LLM decidiendo qué consultar según la pregunta), y extracción estructurada de documentos (convertir facturas o correos no estructurados en JSON con campos fijos, usando la función como "molde" del output esperado, no como una acción externa real).
Definir demasiadas funciones similares (el modelo confunde cuál usar cuando hay solapamiento semántico), descripciones ambiguas en los parámetros (si `ciudad` no aclara si acepta "CDMX" o requiere "Ciudad de México", el modelo adivina), y no validar los argumentos recibidos antes de ejecutarlos — el modelo puede generar valores fuera de rango o mal formados, y tu código de ejecución debe tratar esos argumentos como input no confiable, igual que cualquier input de usuario.
Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.
Contactar a Carlos Montiel