Fine-Tuning para Tool Calling: Cómo construir agentes de IA confiables con modelos pequeños

Los agentes de IA están en todas partes en 2026. Cada plataforma de automatización, cada constructor no-code, cada herramienta de flujo de trabajo tiene una funcionalidad de "agente de IA". Y casi todos funcionan de la misma manera: enviar el mensaje del usuario a GPT-4, preguntarle qué herramienta llamar, parsear la respuesta estructurada, ejecutar la herramienta.

El problema: este patrón es caro, poco confiable en los márgenes, y completamente dependiente de una API en la nube.

La solución: ajustar un modelo pequeño con tu esquema de herramientas específico. Obtienes selección de herramientas más confiable, salida estructurada consistente, y cero costo por consulta.

Qué requiere realmente el tool calling

Cuando un agente de IA "llama a una herramienta", esto es lo que el modelo realmente hace:

1. Recibe un mensaje del usuario + una lista de herramientas disponibles (con sus esquemas)
2. Decide qué herramienta (si alguna) llamar
3. Genera el nombre de la función y parámetros estructurados (JSON)
4. Retorna la llamada a herramienta en un formato específico

Los pasos 2 y 3 son la contribución del modelo. El paso 2 es clasificación (¿qué herramienta coincide con la intención del usuario?). El paso 3 es generación de salida estructurada (producir JSON válido que coincida con un esquema).

Ninguno de estos requiere inteligencia de modelo frontier. La clasificación es coincidencia de patrones. La salida estructurada es seguimiento de plantilla. Estas son exactamente las tareas donde los modelos pequeños ajustados igualan o superan a GPT-4.

Por qué los modelos genéricos fallan en tool calling

Usar GPT-4 o un modelo open-weight genérico para tool calling funciona — la mayor parte del tiempo. Pero los modos de fallo son específicos y frustrantes:

Nombres de funciones alucinados

El modelo inventa nombres de herramientas que no existen en tu esquema. "search_database" en lugar de "query_db." "send_notification" en lugar de "notify_user." Lo suficientemente cercano para que un humano entienda, lo suficientemente incorrecto para romper tu pipeline.

Tipos de parámetros incorrectos

El esquema dice que user_id es un entero. El modelo retorna "user_id": "42" (string). Tu API downstream lo rechaza. El agente falla silenciosamente o reintenta en un loop.

Llamadas a herramientas innecesarias

El usuario hace una pregunta simple que no necesita ninguna herramienta. El modelo llama a una herramienta de todas formas — porque se le dijo que hay herramientas disponibles e intenta ser útil. Ahora tienes una llamada API desperdiciada y una respuesta más lenta.

Inconsistencia de formato

Diferentes llamadas a la API producen diferentes estructuras JSON. A veces el modelo envuelve la respuesta en bloques de código markdown. A veces añade texto de explicación alrededor del JSON. A veces cambia el orden de las claves. Cada inconsistencia es un caso extremo de parsing.

Costo a escala

Cada decisión de tool-calling cuesta dinero. Tool calling de GPT-4o: $2.50-$10 por millón de tokens. Para un agente manejando 10,000 decisiones por día, eso son $75-$300/mes solo por el paso de "enrutamiento" — antes de que se haga trabajo real.

Cómo el fine-tuning arregla esto

Fine-tuning enseña al modelo tus herramientas específicas, tus esquemas específicos, y tus patrones de llamada específicos. El resultado:

La mejora de precisión viene de la especificidad. Un modelo genérico maneja miles de posibles esquemas de herramientas. Tu modelo ajustado maneja tus 5-20 herramientas. No necesita generalizar — necesita acertar sobre tus herramientas específicas, cada vez.

Formato de dataset para fine-tuning de tool-calling

Los datos de entrenamiento siguen el formato de conversación, con llamadas a herramientas como un tipo de mensaje especial. Esta es la estructura:

Ejemplo 1: Llamada simple a herramienta

{
  "messages": [
    {
      "role": "system",
      "content": "You are an assistant with access to the following tools:\n\n- get_order_status(order_id: string): Returns the current status of an order\n- search_products(query: string, category?: string): Searches the product catalog\n- create_support_ticket(subject: string, description: string, priority: 'low' | 'medium' | 'high'): Creates a support ticket"
    },
    {
      "role": "user",
      "content": "What's the status of my order #ORD-2847?"
    },
    {
      "role": "assistant",
      "content": null,
      "tool_calls": [
        {
          "function": {
            "name": "get_order_status",
            "arguments": "{\"order_id\": \"ORD-2847\"}"
          }
        }
      ]
    },
    {
      "role": "tool",
      "content": "{\"status\": \"shipped\", \"tracking\": \"1Z999AA10123456784\", \"eta\": \"2026-02-24\"}"
    },
    {
      "role": "assistant",
      "content": "Your order #ORD-2847 has been shipped! The tracking number is 1Z999AA10123456784 and the estimated delivery date is February 24, 2026."
    }
  ]
}

Ejemplo 2: No se necesita herramienta

{
  "messages": [
    {
      "role": "system",
      "content": "You are an assistant with access to the following tools: [same tools]"
    },
    {
      "role": "user",
      "content": "What's your return policy?"
    },
    {
      "role": "assistant",
      "content": "Our return policy allows returns within 30 days of purchase for a full refund. Items must be in their original condition. Would you like me to help you start a return?"
    }
  ]
}

Incluir ejemplos donde el modelo NO debería llamar una herramienta es crítico. Sin estos, el modelo aprende a siempre llamar algo.

Ejemplo 3: Llamada multi-herramienta

{
  "messages": [
    {
      "role": "system",
      "content": "You are an assistant with access to the following tools: [same tools]"
    },
    {
      "role": "user",
      "content": "I got the wrong item in order #ORD-2847. I need to file a complaint."
    },
    {
      "role": "assistant",
      "content": null,
      "tool_calls": [
        {
          "function": {
            "name": "get_order_status",
            "arguments": "{\"order_id\": \"ORD-2847\"}"
          }
        },
        {
          "function": {
            "name": "create_support_ticket",
            "arguments": "{\"subject\": \"Wrong item received - ORD-2847\", \"description\": \"Customer reports receiving the wrong item in order ORD-2847.\", \"priority\": \"high\"}"
          }
        }
      ]
    }
  ]
}

Construyendo tu dataset de entrenamiento

Paso 1: Define tu esquema de herramientas

Lista cada herramienta que tu agente puede llamar. Para cada herramienta, define:

• Nombre de función (exactamente como tu código lo espera)
• Parámetros (nombre, tipo, requerido/opcional)
• Tipo de retorno
• Cuándo usarla (descripción en lenguaje natural)

Empieza pequeño. 5-10 herramientas es el punto ideal para una primera ejecución de fine-tuning. Puedes expandir después.

Paso 2: Genera ejemplos de entrenamiento

Para cada herramienta, crea 20-40 ejemplos cubriendo:

• Llamadas claras: La intención del usuario obviamente mapea a una herramienta
• Casos ambiguos: La intención del usuario podría mapear a múltiples herramientas (entrena al modelo con tu enrutamiento preferido)
• Casos sin herramienta: Preguntas que el modelo debería responder directamente sin llamar ninguna herramienta
• Casos multi-herramienta: Escenarios que requieren llamadas a herramientas secuenciales o paralelas
• Casos extremos: Fraseado inusual, información faltante (el modelo debería pedir aclaración), solicitudes inválidas

200-500 ejemplos totales son típicamente suficientes para un agente de 5-10 herramientas. La calidad importa más que la cantidad — consulta nuestra guía sobre calidad de datos sobre cantidad.

Paso 3: Formatea como JSONL

Convierte tus ejemplos al formato de conversación mostrado arriba, un objeto JSON por línea. Este es el formato estándar para fine-tuning en Ertas y la mayoría de otras plataformas.

Paso 4: Ajusta

Sube tu dataset JSONL a Ertas, selecciona un modelo base (Llama 3.1 8B Instruct o Qwen 2.5 7B Instruct son buenas opciones — usa la variante Instruct, no Base), configura el entrenamiento, y ejecuta.

Usa la variante Instruct específicamente porque el tool calling requiere mezclar salida estructurada con respuestas en lenguaje natural. Los modelos Base luchan con esta combinación. Consulta la investigación sobre este tema.

Paso 5: Evalúa

Prueba contra un conjunto reservado de 50-100 ejemplos. Mide:

• Precisión de selección de herramienta: ¿Eligió la herramienta correcta?
• Corrección de parámetros: ¿Están todos los parámetros presentes, tipo correcto, valor correcto?
• Precisión de no-llamada: ¿Evitó correctamente llamar una herramienta cuando no se necesitaba ninguna?
• Cumplimiento de formato: ¿La salida es JSON válido y parseable cada vez?

Desplegando tu modelo de tool-calling

Inferencia local con Ollama

Exporta tu modelo ajustado como GGUF, importa en Ollama, y sirve vía su API. El endpoint compatible con OpenAI de Ollama significa que tu framework de agente existente (LangChain, CrewAI, etc.) funciona con un cambio de URL de una línea.

Integración con n8n

Para flujos de trabajo n8n, reemplaza el nodo de OpenAI con un nodo de Ollama apuntando a tu modelo ajustado. La lógica del flujo de trabajo permanece idéntica — solo cambia el endpoint del modelo. El costo de API cae de cientos por mes a cero.

Integración con Make.com

Para automatizaciones de Make.com, usa un módulo HTTP para llamar al endpoint de tu API de Ollama. El modelo retorna llamadas a herramientas en formato JSON que Make.com puede parsear y enrutar a módulos subsiguientes.

Cuándo todavía necesitas GPT-4 para tool calling

Los modelos pequeños ajustados sobresalen con esquemas de herramientas fijos con patrones bien definidos. No son la elección correcta para cada escenario:

• Descubrimiento dinámico de herramientas: Si las herramientas disponibles cambian por sesión (sistemas de plugins, acciones configuradas por el usuario), la flexibilidad de un modelo genérico es valiosa
• Razonamiento complejo multi-paso: Si la selección de herramientas requiere razonamiento multi-hop ("para responder esto, necesito llamar herramienta A, usar su salida para parametrizar herramienta B, luego..."), los modelos más grandes manejan mejor la planificación
• Conjuntos de herramientas muy grandes (50+): Con más de 50 herramientas, el problema de clasificación se vuelve más difícil y puede requerir un modelo más grande o un enfoque de enrutamiento de dos etapas
• Herramientas novedosas sin datos de entrenamiento: Si estás añadiendo herramientas frecuentemente y no puedes reentrenar cada vez, la capacidad zero-shot de un modelo genérico ayuda a cerrar la brecha

Para la mayoría de agentes en producción con 5-20 herramientas bien definidas, un modelo ajustado de 8B es la mejor opción — más confiable, más rápido, e infinitamente más barato.

Primeros pasos

1. Lista las herramientas de tu agente y sus esquemas
2. Crea 200-500 ejemplos de entrenamiento (incluyendo casos sin herramienta y casos extremos)
3. Formatea como JSONL
4. Ajusta en Ertas — selecciona Llama 3.1 8B Instruct o Qwen 2.5 7B Instruct
5. Evalúa con ejemplos reservados
6. Despliega vía Ollama y conecta a tu plataforma de automatización
7. Monitorea la precisión en producción y reentrena periódicamente con nuevos ejemplos

El cerebro de tu agente de IA no necesita costar $10 por millón de tokens. Ajústalo una vez, córrelo localmente, y nunca pagues por enrutamiento de herramientas de nuevo.

---

Referencias: Weights & Biases — Fine-tuning LLMs for Function Calling, Hugging Face — Function Calling Fine-Tuning with xLAM, Parlance Labs — Fine-Tuning for Function Calling.