Tool Calling ajustado para flujos de trabajo en n8n y Make.com

Tienes un flujo de trabajo en n8n que funciona. Un cliente envía un mensaje, un nodo de OpenAI decide qué acción tomar, y el flujo se ramifica en consecuencia. Buscar pedido, verificar estado, emitir reembolso, escalar a un humano. Se ejecuta 500 veces al día. La factura de OpenAI es de $450/mes y sigue subiendo.

Aquí está el patrón que elimina ese costo por completo: extraer datos de entrenamiento de tus ejecuciones existentes del flujo de trabajo, ajustar un modelo pequeño en tu esquema específico de herramientas, desplegarlo localmente con Ollama, y cambiar el nodo de OpenAI por un nodo de HTTP Request apuntando a localhost.

Mismo flujo de trabajo. Misma lógica de enrutamiento. Misma salida estructurada. Cero costo de API.

La arquitectura

El patrón actual en la mayoría de los flujos de trabajo de IA en n8n:

Webhook → OpenAI Node (tool selection) → Switch Node → Action Branches

El reemplazo:

Webhook → HTTP Request (local Ollama) → Switch Node → Action Branches

El único nodo que cambia es el punto de decisión de IA. Todo lo que está después — el nodo Switch, las ramas de acción, las escrituras a base de datos, los envíos de correo — permanece idéntico.

El trabajo del modelo ajustado es estrecho: recibir un mensaje del usuario, generar un nombre de herramienta y parámetros como JSON. No necesita ser un asistente de propósito general. No necesita escribir poesía ni resumir documentos. Necesita clasificar intención y extraer parámetros para tus herramientas específicas.

El ejemplo: un flujo de trabajo de soporte al cliente con 8 herramientas

Vamos a recorrer un flujo de trabajo real con ocho herramientas:

En n8n, este flujo de trabajo se ve así: trigger de Webhook, nodo de OpenAI con definiciones de herramientas, nodo Switch sobre el nombre de la herramienta, ocho ramas ejecutando cada una la acción correspondiente.

El nodo de OpenAI cuesta $0.02-0.04 por ejecución dependiendo de la longitud del prompt y el modelo. A 500 ejecuciones por día, eso son $300-600/mes solo por la decisión de enrutamiento.

Paso 1: Extraer datos de entrenamiento de los logs del flujo de trabajo

n8n almacena datos de ejecución para cada corrida del flujo. Esta es tu fuente de datos de entrenamiento — mensajes reales de usuarios emparejados con las llamadas a herramientas reales que funcionaron.

En n8n, ve a Executions en tu flujo de trabajo y filtra por ejecuciones exitosas. Cada ejecución contiene la entrada (mensaje del usuario) y la salida del nodo de OpenAI (selección de herramienta + parámetros).

Exporta estos datos. Puedes usar la API de n8n o un nodo Code para extraerlos:

// n8n Code Node — extract training pairs from execution history
const executions = await this.helpers.httpRequest({
  method: 'GET',
  url: 'http://localhost:5678/api/v1/executions',
  headers: { 'X-N8N-API-KEY': 'your-api-key' },
  qs: { workflowId: 'your-workflow-id', status: 'success', limit: 1000 }
});

const trainingPairs = executions.data.map(exec => {
  const webhookData = exec.data.resultData.runData['Webhook'][0];
  const openaiData = exec.data.resultData.runData['OpenAI'][0];

  return {
    userMessage: webhookData.data.main[0][0].json.body.message,
    toolCall: openaiData.data.main[0][0].json.tool_calls[0]
  };
});

return trainingPairs;

Esto te da pares reales de entrada-salida. Si has estado ejecutando el flujo durante un mes a 500 ejecuciones/día, son 15,000 ejemplos etiquetados. Más que suficiente.

Filtra por calidad: Elimina ejecuciones donde el mensaje del usuario estaba vacío, donde la llamada a la herramienta fue seguida por un error en la rama posterior (indicando una decisión de enrutamiento incorrecta), o donde el flujo fue corregido manualmente.

Paso 2: Formatear para fine-tuning

Convierte tus pares extraídos al formato estándar de entrenamiento JSONL:

{"messages": [{"role": "system", "content": "You are a customer support router. Given a customer message, call the appropriate tool. Available tools: lookup_order, check_status, initiate_refund, update_address, send_notification, check_inventory, apply_discount, escalate_to_human."}, {"role": "user", "content": "Where's my order ORD-48291?"}, {"role": "assistant", "tool_calls": [{"function": {"name": "lookup_order", "arguments": "{\"order_id\": \"ORD-48291\"}"}}]}]}

Incluye los esquemas completos de las herramientas en el mensaje de sistema. Mantenlo idéntico en todos los ejemplos — este es el mismo system prompt que usarás en tiempo de inferencia.

Para el flujo de trabajo de 8 herramientas, apunta a esta distribución:

La distribución debería aproximarse a tu tráfico real. Si lookup_order representa el 30% de tus solicitudes, debería tener más ejemplos. Si no tienes suficientes datos reales para una herramienta, usa expansión sintética para llenar los vacíos.

Paso 3: Ajustar el modelo

Para enrutamiento de tool-calling, un modelo de 7B u 8B es más que suficiente. Qwen 2.5 7B y Llama 3.3 8B funcionan bien. Estás entrenando un clasificador con salida estructurada, no un asistente general.

Con Ertas, el proceso de fine-tuning es:

1. Sube tu dataset JSONL
2. Selecciona tu modelo base (Qwen 2.5 7B recomendado para tool calling)
3. Configura LoRA — rango 16, alpha 32, apunta a todas las capas de atención
4. Entrena durante 3 épocas con tasa de aprendizaje 2e-4

Tiempo de entrenamiento en una sola GPU: 30-45 minutos para 1,100 ejemplos. La salida es un adaptador LoRA — un archivo de 50-100MB que se superpone al modelo base.

Si aún no tienes suficientes datos reales de ejecución, construye un dataset sintético a partir de tus esquemas de herramientas primero, entrena un modelo inicial, despliégalo, y reentréna con datos reales después de unas semanas.

Paso 4: Desplegar con Ollama

Exporta tu modelo ajustado en formato GGUF y crea un Modelfile de Ollama:

FROM ./qwen2.5-7b-customer-tools.gguf

PARAMETER temperature 0.1
PARAMETER num_ctx 2048

SYSTEM """You are a customer support router. Given a customer message, call the appropriate tool. Available tools: lookup_order, check_status, initiate_refund, update_address, send_notification, check_inventory, apply_discount, escalate_to_human. Respond with a JSON tool call or a conversational message if no tool applies."""

ollama create customer-router -f Modelfile
ollama run customer-router

Pruébalo:

curl http://localhost:11434/api/chat -d '{
  "model": "customer-router",
  "messages": [{"role": "user", "content": "I want a refund for ORD-55123, it was defective"}],
  "stream": false
}'

Salida esperada:

{
  "tool_calls": [{
    "function": {
      "name": "initiate_refund",
      "arguments": "{\"order_id\": \"ORD-55123\", \"reason\": \"defective\"}"
    }
  }]
}

Tiempo de respuesta en una máquina con 16GB de RAM: 200-400ms. Suficientemente rápido para ejecución de flujos en tiempo real.

Paso 5: Reemplazar el nodo de OpenAI en n8n

En tu flujo de trabajo de n8n, reemplaza el nodo de OpenAI con un nodo HTTP Request:

Configuración del nodo HTTP Request:

• Método: POST
• URL: http://localhost:11434/api/chat
• Body (JSON):

{
  "model": "customer-router",
  "messages": [
    {
      "role": "user",
      "content": "={{ $json.body.message }}"
    }
  ],
  "stream": false,
  "format": "json"
}

La respuesta de Ollama contiene la llamada a la herramienta en la misma estructura. Tu nodo Switch posterior analiza el nombre de la herramienta y enruta a la rama correcta — exactamente como antes.

Actualiza el nodo Switch para analizar desde el formato de respuesta de Ollama en lugar del formato de respuesta de OpenAI. El nombre de la herramienta está en la misma ubicación; puede que necesites ajustar ligeramente la ruta JSON.

La comparación de costos

Aquí están las matemáticas reales a diferentes volúmenes de automatización:

La columna "Ajustado local" es $0 porque la inferencia en tu propio hardware no tiene costo marginal. Ya estás pagando por el servidor. El costo de electricidad para inferencia es insignificante — menos de $5/mes incluso a 5,000 ejecuciones diarias.

Costos únicos: cómputo de fine-tuning ($5-20 en GPU en la nube, o gratis en Ertas), más 4-8 horas de tu tiempo construyendo el dataset y probando.

Punto de equilibrio a 100 ejecuciones diarias: menos de una semana.

Equivalente en Make.com

El mismo patrón funciona en Make.com. Reemplaza el módulo de OpenAI con un módulo HTTP que llame a tu endpoint local de Ollama.

Configuración del módulo HTTP:

• URL: http://your-server-ip:11434/api/chat
• Método: POST
• Tipo de body: Raw (JSON)
• Contenido de la solicitud:

{
  "model": "customer-router",
  "messages": [{"role": "user", "content": "{{1.body.message}}"}],
  "stream": false,
  "format": "json"
}

Si tu instancia de Make.com corre en la nube y tu instancia de Ollama corre on-prem, necesitarás exponer el endpoint de Ollama. Opciones: Cloudflare Tunnel (gratis), ngrok, o una VPN. Para producción, usa Cloudflare Tunnel con políticas de acceso para restringir quién puede alcanzar el endpoint.

El modelo de precios de Make.com en realidad hace que los ahorros sean más dramáticos. Pagas por operación, y el módulo de OpenAI cuenta como una operación más el pago a OpenAI por separado. Con el módulo HTTP llamando a un endpoint local, sigues pagando por la operación de Make.com pero eliminas el costo de OpenAI por completo.

Mejora en la fiabilidad

Este es el beneficio subestimado. Los ahorros de costos atraen la atención, pero la fiabilidad suele ser la ganancia más importante.

Un modelo genérico de GPT-4 ocasionalmente alucina nombres de herramientas. Podría generar search_order en lugar de lookup_order, o refund_order en lugar de initiate_refund. Suficientemente cercano para que un humano lo entienda, suficientemente incorrecto para romper tu nodo Switch.

Un modelo ajustado entrenado exclusivamente en tus ocho nombres de herramientas nunca alucinará un noveno. Solo ha visto estos ocho nombres en sus datos de entrenamiento. El espacio de salida está restringido a tu esquema real.

En pruebas a lo largo de flujos de trabajo de soporte al cliente, los modelos ajustados de 7B logran:

• Precisión en selección de herramientas: 94-97% (vs 89-93% para GPT-4o-mini con ingeniería de prompts)
• Precisión en extracción de parámetros: 91-95% (vs 87-92% para GPT-4o-mini)
• Cumplimiento del esquema: 99.5%+ (vs 96-98% para GPT-4o-mini)
• Nombres de herramientas alucinados: 0% (vs 1-3% para modelos genéricos)

Esa tasa de alucinación del 1-3% en modelos genéricos no suena como mucho hasta que estás ejecutando 500 ejecuciones por día. Al 2%, eso son 10 ejecuciones fallidas diarias — 10 clientes que encuentran un error, 10 tickets de soporte, 10 intervenciones manuales.

Manejo de casos extremos

¿Qué pasa con los mensajes que no coinciden con ninguna herramienta? El modelo necesita responder conversacionalmente.

Incluye ejemplos negativos en tus datos de entrenamiento — mensajes como "What are your business hours?" o "Thanks for the help!" que no deberían activar ninguna herramienta. Entrena al modelo para generar una respuesta conversacional para estos.

¿Qué pasa con mensajes que podrían coincidir con múltiples herramientas? "I want to return my order and change my address" — esto necesita dos llamadas a herramientas. Entrena ejemplos multi-herramienta si tu flujo soporta ejecución secuencial, o entrena al modelo para elegir la intención principal y manejar la segunda en un turno de seguimiento.

¿Qué pasa con herramientas nuevas? Cuando agregas una novena herramienta a tu flujo, necesitas reentrenar. Agrega ejemplos para la nueva herramienta a tu dataset, incluye ejemplos negativos que la distingan de herramientas existentes similares, y ejecuta un fine-tuning rápido. Con LoRA, reentrenar toma 30-45 minutos. Puedes hacerlo durante la hora del almuerzo.

---

Haciendo el cambio

Aquí está la lista de verificación para la migración:

1. Exporta el historial de ejecuciones de tu flujo de n8n/Make.com (mínimo 500 ejecuciones exitosas)
2. Formatea como JSONL con estructura adecuada de tool-call y 20% de ejemplos negativos
3. Ajusta un modelo de 7B con LoRA (30-45 minutos)
4. Despliega en Ollama en la misma máquina o red que tu motor de flujos de trabajo
5. Reemplaza el nodo de OpenAI con un nodo HTTP Request apuntando a localhost:11434
6. Prueba con 50 mensajes reales antes de cambiar el tráfico de producción
7. Monitorea las primeras 1,000 ejecuciones, comparando la precisión de selección de herramientas contra la línea base de OpenAI
8. Rereentrena mensualmente con nuevos datos de ejecución para mejora continua

La parte más difícil es el paso 1 — sentirte cómodo con la idea de que un modelo de 7B ejecutándose en tu propio hardware puede igualar la precisión de enrutamiento de GPT-4 para tus herramientas específicas. Una vez que veas los resultados de las pruebas, el resto es plomería directa.

Tus flujos siguen ejecutándose. Tu automatización sigue funcionando. Tu factura de API baja a cero.

Lectura adicional

• Cómo reemplazar el nodo de OpenAI en n8n con un modelo ajustado — Guía de migración paso a paso con capturas de pantalla de configuración nodo por nodo.
• Make.com con IA local: la guía completa de integración — Recorrido completo para conectar módulos HTTP de Make.com a endpoints locales de Ollama.
• n8n + Ollama + modelos ajustados: el stack de costo cero — Guía de arquitectura para ejecutar el stack completo de automatización en un solo servidor sin costos recurrentes.