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, porque 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 8000vLLM 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.
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

