
De flujo de n8n a modelo ajustado: un playbook paso a paso para agencias
Una guía táctica para agencias de n8n: recopila datos de interacción de clientes vía flujos de trabajo, limpia y formatea, ajusta un modelo en Ertas Studio, despliega localmente y conecta de vuelta a n8n para inferencia.
Tienes flujos de n8n ejecutándose para tus clientes. Llaman a las APIs de OpenAI o Anthropic para tareas de clasificación, resumen, generación o análisis. Los flujos funcionan, pero los costos de API consumen tus márgenes y la calidad es inconsistente.
Aquí está el playbook para convertir esos flujos de n8n existentes en un pipeline de fine-tuning — usando los datos de interacción que ya estás generando para entrenar un modelo personalizado que es más barato, más rápido y más preciso.
Visión general del pipeline
n8n Workflows (existing) → Data Collection → Cleaning → Fine-Tuning → Local Deployment → n8n Workflows (updated)
Empiezas y terminas con n8n. Los pasos intermedios transforman los datos de uso de tu cliente en un modelo personalizado que reemplaza las llamadas API.
Paso 1: recopila datos de interacción del cliente vía n8n
Tus flujos de n8n existentes ya contienen los datos de entrenamiento que necesitas — cada llamada API incluye una entrada (la instrucción) y una salida (la respuesta del modelo). Solo necesitas capturarlos.
Agrega una rama de recopilación de datos
Para cada flujo que llama a una API de IA, agrega una rama paralela que registre la interacción:
-
Después del nodo HTTP Request (llamada API), agrega un nodo Set que extraiga:
- El prompt/mensaje de entrada enviado a la API
- La respuesta recibida de la API
- Un timestamp
- Identificador del cliente
- Tipo de tarea (clasificación, resumen, etc.)
-
Enruta esto a un nodo de Google Sheets, Airtable o PostgreSQL que almacene los registros.
Para flujos ya en producción, puedes agregar esta rama de registro sin interrumpir el flujo existente — el modelo de ramificación de n8n te permite agregar rutas paralelas.
Qué capturar
{
"instruction": "Summarise this customer support ticket: [ticket text]",
"response": "The customer is requesting a refund for order #12345 due to a defective product received on 2026-01-15...",
"task_type": "ticket_summarisation",
"client_id": "client_acme",
"timestamp": "2026-02-10T14:30:00Z",
"model_used": "gpt-4o",
"was_accepted": true
}
El campo was_accepted es opcional pero valioso — si el equipo del cliente revisa las salidas de IA y a veces las rechaza, rastrear esto ayuda a filtrar datos de entrenamiento de alta calidad.
Objetivos de volumen
| Calidad del fine-tuning | Ejemplos necesarios | Tiempo de recopilación (típico) |
|---|---|---|
| Mínimo viable | 500 | 1-2 semanas |
| Buena calidad | 1,500-2,000 | 3-6 semanas |
| Listo para producción | 3,000+ | 6-12 semanas |
Empieza a recopilar ahora, aunque estés a semanas del fine-tuning. Más datos producen mejores modelos.
Paso 2: limpia y formatea el dataset
Los logs crudos de interacción necesitan limpieza antes del fine-tuning. Construye un flujo de n8n para esto o hazlo manualmente — la elección depende del volumen.
Limpieza automatizada (flujo de n8n)
Crea un flujo de limpieza de datos que:
- Lee desde tu almacén de datos (Google Sheets, PostgreSQL, etc.)
- Filtra respuestas rechazadas (donde
was_acceptedes false) - Elimina duplicados (misma instrucción con misma respuesta)
- Normaliza formato (saltos de línea consistentes, eliminar espacios en blanco)
- Valida estructura (campos de instrucción y respuesta no están vacíos, longitud razonable)
- Exporta como JSONL (un objeto JSON por línea)
Revisión manual
Para la primera corrida de fine-tuning, revisa manualmente una muestra (100-200 ejemplos):
- ¿Las instrucciones son claras y representativas de la tarea?
- ¿Las respuestas son de alta calidad? (¿Querrías que el modelo produzca esto?)
- ¿Hay datos sensibles que necesitan eliminarse? (PII, claves API, referencias internas)
- ¿Hay casos extremos que deberían excluirse del entrenamiento?
Formato de salida
El archivo JSONL final debería verse así:
{"instruction": "Classify this email as: billing, technical, general, or spam.\n\nEmail: I can't log into my account after the update...", "response": "technical"}
{"instruction": "Summarise this support ticket for the weekly report:\n\nTicket: Customer reported that...", "response": "Customer experienced login failure after v2.3 update. Resolution: cleared browser cache and reset session tokens. Time to resolve: 15 minutes."}
Paso 3: ajusta en Ertas Studio
Con tu archivo JSONL limpio listo:
- Crea un proyecto en Ertas Studio para este cliente y tarea
- Sube el archivo JSONL — Studio valida el formato y muestra estadísticas de los datos
- Selecciona modelo base — Llama 3.1 8B para la mayoría de las tareas de agencia, Mistral 7B como alternativa
- Configura el entrenamiento:
- Rango LoRA: 16 (por defecto, funciona para la mayoría de las tareas)
- Épocas: 3
- Learning rate: 2e-4
- Inicia el entrenamiento — típicamente 30-60 minutos para 2,000 ejemplos en un modelo 8B
- Evalúa — usa la comparación lado a lado de Studio para probar el modelo ajustado contra entradas de muestra
Control de calidad
Antes de desplegar, prueba con 20-30 ejemplos que el modelo nunca ha visto:
- ¿El modelo ajustado iguala o supera la calidad del modelo de API?
- ¿El formato de salida es consistente?
- ¿Maneja los casos extremos correctamente?
Si la calidad no es suficiente, las correcciones comunes son:
- Agregar más datos de entrenamiento (especialmente para los casos donde la calidad es débil)
- Aumentar el rango LoRA de 16 a 32
- Agregar otra época de entrenamiento
- Mejorar la calidad de los datos (eliminar ejemplos ruidosos)
Paso 4: despliega el modelo localmente
Exporta tu modelo ajustado desde Ertas Studio en formato GGUF (para Ollama) o SafeTensors (para vLLM).
Despliega con Ollama
# Create a Modelfile
echo 'FROM llama3.1:8b
ADAPTER /path/to/your-adapter.gguf' > Modelfile
# Register the model
ollama create client-acme-summariser -f Modelfile
# Test it
ollama run client-acme-summariser "Summarise this ticket: ..."
Ollama expone una API compatible con OpenAI en http://localhost:11434/v1/chat/completions.
Despliega con vLLM
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-3.1-8B \
--enable-lora \
--lora-modules client-acme=/path/to/adapter \
--host 0.0.0.0 --port 8000
vLLM expone una API compatible con OpenAI en http://your-server:8000/v1/chat/completions.
Paso 5: conecta n8n a tu modelo local
Aquí está la recompensa. Actualiza tus flujos de n8n existentes para apuntar a tu modelo local en lugar de la API en la nube.
Opción A: cambia la URL de la API
Si estás usando el nodo HTTP Request de n8n para llamar a OpenAI:
- Cambia la URL de
https://api.openai.com/v1/chat/completionsahttp://localhost:11434/v1/chat/completions(Ollama) ohttp://your-server:8000/v1/chat/completions(vLLM) - Actualiza el parámetro del modelo de
gpt-4oal nombre de tu modelo - Elimina o actualiza la clave API (Ollama no requiere una)
Eso es todo. El formato de solicitud/respuesta es idéntico. La lógica de tu flujo, manejo de errores y procesamiento de salida se mantienen iguales.
Opción B: usa las credenciales de OpenAI de n8n con URL base personalizada
- En n8n, crea una nueva credencial de OpenAI
- Establece la URL base a tu endpoint local
- Establece la clave API como cualquier cadena (por ejemplo, "local")
- Usa esta credencial en tus nodos OpenAI existentes
- Cambia el nombre del modelo a tu modelo ajustado
Este enfoque no requiere cambios en el flujo más allá de actualizar la credencial — cada nodo que usa la credencial automáticamente cambia a inferencia local.
Probando el cambio
Antes de cambiar flujos de producción:
- Clona el flujo — crea una copia que use el modelo local
- Ejecuta ambos en paralelo por 24-48 horas
- Compara salidas — ¿los resultados del modelo local son iguales o mejores?
- Monitorea latencia — la inferencia local debería ser más rápida para la mayoría de las cargas de trabajo
- Cambia — actualiza el flujo de producción para usar el endpoint local
Paso 6: itera y mejora
El fine-tuning no es un evento único. El modelo mejora con retroalimentación:
Recopilación continua de datos
Mantén la rama de recopilación de datos activa en tus flujos actualizados. Ahora captura:
- Interacciones con tu modelo ajustado (no la API)
- Retroalimentación del cliente (aceptado/rechazado)
- Casos extremos donde el modelo tiene bajo rendimiento
Reentrenamiento periódico
Cada 4-8 semanas (o cuando surjan problemas de calidad):
- Exporta nuevos datos de interacción desde tu pipeline de registro
- Agrega ejemplos correctivos para casos donde el modelo tuvo dificultades
- Combina con los datos de entrenamiento originales
- Reentrena en Ertas Studio
- Evalúa contra la versión anterior del modelo
- Despliega si mejoró
Rastrea la mejora a lo largo del tiempo
Registra versiones de modelos y métricas de calidad correspondientes. Después de 3-4 ciclos de entrenamiento, verás mejoras medibles a medida que el modelo aprende de patrones de uso del mundo real.
El impacto en el negocio
| Métrica | Antes (API) | Después (local fine-tuned) |
|---|---|---|
| Costo mensual de API (por cliente) | $150-500 | ~$0 |
| Latencia de respuesta | 800-2000ms | 200-500ms |
| Calidad de salida | Genérica | Específica del cliente |
| Privacidad de datos | Datos enviados a terceros | Datos se quedan locales |
| Escalabilidad | Aumento lineal de costos | Costo fijo (nivel de GPU) |
Para la mayoría de las agencias, el cambio se paga solo en 1-3 meses. Más importante, transforma el servicio de "conectamos tus flujos a ChatGPT" a "construimos modelos de IA personalizados entrenados con tus datos" — una propuesta de valor significativamente más alta.
Ship AI that runs on your users' devices.
Ertas early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.
Lectura adicional
- n8n + LLMs locales: construyendo automatización compatible con HIPAA — Flujos de n8n + LLM local específicos para salud
- Stack tecnológico de agencia de IA para clientes legales — La arquitectura completa para agencias que sirven a bufetes de abogados
Ship AI that runs on your users' devices.
Early bird pricing starts at $14.50/mo — locked in for life. Plans for builders and agencies.
Keep reading

Multi-Client Fine-Tuning: One Base Model, Custom LoRA Adapters Per Law Firm
How to use LoRA adapters to serve multiple law firm clients from a single base model — covering architecture, training, hot-swapping, cost efficiency, and data isolation guarantees.

Managing 50+ LoRA Adapters in Production: Versioning and Organization
Practical systems for managing dozens of LoRA adapters across multiple clients, tasks, and base models — covering naming conventions, metadata, registries, multi-LoRA serving, and scaling milestones from 10 to 100+ adapters.

How to Power OpenClaw with Fine-Tuned Local Models (No API Costs)
OpenClaw defaults to cloud APIs that charge per token. Here's how to run it on fine-tuned local models via Ollama for better domain performance and zero marginal inference cost.