Modelos Ajustados para Agentes LangGraph: Reemplaza GPT-4 en Tu Stack de Agentes

LangGraph es el framework dominante para construir agentes de IA con estado en 2026. Te da control explícito sobre el estado del agente, soporta ciclos y ramificación condicional, y maneja la complejidad que los frameworks más simples no pueden. Si estás construyendo agentes de producción en Python, probablemente estás usando LangGraph o algo fuertemente inspirado en él.

El patrón por defecto en cada tutorial de LangGraph: ChatOpenAI(model="gpt-4o") como motor de razonamiento. Cada nodo que necesita pensar, enrutar, resumir o generar llama a GPT-4. Y cada llamada cuesta dinero.

Un agente LangGraph típico con 5 nodos — enrutador, investigador, analizador, respondedor, revisor — hace 5-15 llamadas LLM por ejecución de tarea. A precios de GPT-4o, eso es $0.05-$0.30 por ejecución. Ejecuta 1,000 tareas por día y estás gastando $50-$300/día, o $1,500-$9,000/mes. Solo en inferencia.

La mayoría de esas llamadas LLM no necesitan GPT-4. Necesitan un modelo que conozca tus herramientas específicas, tu lógica de enrutamiento específica y tu formato de output específico. Eso es lo que te da el fine-tuning.

Desglosando Lo Que Cada Nodo del Agente Realmente Hace

Los agentes LangGraph son grafos de nodos, donde cada nodo realiza una función específica. Categoricemos lo que cada tipo de nodo realmente requiere de un LLM:

Nodos Enrutadores (Clasificación)

El enrutador observa la solicitud entrante y decide qué camino debe tomar el agente. "¿Es esto una pregunta de facturación, un problema de soporte técnico o una consulta de ventas?" Esta es una tarea de clasificación con un conjunto fijo de categorías.

Precisión de clasificación de GPT-4 en categorías bien definidas: ~95-98%. Precisión de un modelo 8B ajustado en las mismas categorías: ~96-99%. El modelo ajustado frecuentemente es más preciso porque está entrenado exclusivamente en tus categorías y nunca alucina categorías que no existen.

Nodos de Selección de Herramientas (Output Estructurado)

El agente decide qué herramienta llamar y genera los parámetros. "Llamar a search_knowledge_base con {"query": "refund policy", "category": "billing"}." Esto es generación de output estructurado — el modelo necesita producir JSON válido que coincida con un esquema específico.

Los modelos ajustados sobresalen aquí. Aprenden tus nombres exactos de herramientas, tus esquemas exactos de parámetros y tus convenciones exactas de llamada. No más nombres de funciones alucinados o tipos de parámetros incorrectos. Consulta nuestro desglose detallado en Fine-Tuning para Tool Calling.

Nodos de Generación de Respuestas (Texto Específico de Dominio)

El agente genera la respuesta final al usuario basándose en el contexto recopilado. Esto requiere conocimiento del dominio, tono apropiado y síntesis precisa de información.

Para respuestas específicas de dominio (legal, médico, financiero, soporte al cliente), un modelo ajustado entrenado en tu corpus de respuestas aprobadas produce output más consistente que GPT-4 con un system prompt. No se desvía, no alucina lenguaje de exención que no aprobaste y no cambia aleatoriamente el tono entre respuestas.

Nodos de Resumen de Estado (Compresión)

En agentes de larga ejecución, periódicamente resumes el estado de la conversación para caber dentro de los límites de contexto. "Aquí están los últimos 20 mensajes. Resume los hechos clave." Esta es una tarea de compresión.

Un modelo de resumen ajustado entrenado en tu formato específico de estado produce resúmenes que preservan los campos que tus nodos posteriores realmente necesitan, en lugar de un resumen genérico que podría descartar detalles críticos.

Nodos de Razonamiento Complejo (Lógica Multi-Paso)

"Dados estos tres puntos de datos, determina si el cliente califica para un plan premium, y si es así, calcula el descuento." Razonamiento multi-paso con combinaciones novedosas de hechos.

Aquí es donde los modelos frontier aún justifican su costo. El razonamiento complejo multi-paso en problemas novedosos es la única área donde GPT-4 y Claude consistentemente superan a los modelos pequeños ajustados. No puedes ajustar tu camino hacia la inteligencia general — solo puedes ajustar para patrones que el modelo ha visto.

La Arquitectura Híbrida

La arquitectura práctica no es "reemplaza todo con modelos ajustados" — es "reemplaza todo lo que se puede ajustar y mantén la API en la nube para lo que no se puede."

Entrada del Usuario
    │
    ▼
[Nodo Enrutador] ← 8B ajustado (clasificación)
    │
    ├── Camino A: Consulta Simple
    │   └── [Nodo de Respuesta] ← 8B ajustado (respuesta de dominio)
    │
    ├── Camino B: Consulta que Requiere Herramienta
    │   ├── [Selección de Herramienta] ← 8B ajustado (output estructurado)
    │   ├── [Ejecución de Herramienta] ← No necesita LLM
    │   └── [Nodo de Respuesta] ← 8B ajustado (respuesta de dominio)
    │
    └── Camino C: Razonamiento Complejo
        └── [Nodo de Análisis] ← GPT-4o (razonamiento multi-paso)
            └── [Nodo de Respuesta] ← 8B ajustado (formatear output)

En esta arquitectura, 80-90% de las solicitudes siguen el Camino A o B — manejadas completamente por el modelo ajustado. Solo el 10-20% genuinamente complejo se enruta a GPT-4. Tu factura de API cae 80-90%.

Datos de Entrenamiento desde Trazas de Agentes

LangGraph hace que la recopilación de datos de entrenamiento sea sencilla porque cada ejecución produce una traza completa — la entrada y salida de cada nodo, cada decisión, cada llamada a herramienta. Estas trazas son tu dataset de entrenamiento.

Recopilando Trazas

Habilita el rastreo de LangSmith o construye logging personalizado en cada nodo:

from langchain_core.tracers import LangChainTracer

# Cada ejecución se registra automáticamente
tracer = LangChainTracer(project_name="agent-training-data")
agent.invoke(input, config={"callbacks": [tracer]})

Después de ejecutar tu agente con GPT-4 durante 2-4 semanas, tendrás miles de ejecuciones rastreadas. Cada traza contiene los pares exactos de entrada-salida para cada nodo — datos de entrenamiento listos para usar.

Filtrado y Formateo

No todas las trazas son buenos datos de entrenamiento. Filtra por:

• Ejecuciones exitosas — el agente logró el objetivo sin errores
• Llamadas a herramientas limpias — sin reintentos por parámetros malformados
• Feedback positivo del usuario — si recopilas feedback, pondera esas trazas más alto

Formatea cada par entrada-salida de nodo como un ejemplo de entrenamiento:

{
  "messages": [
    {"role": "system", "content": "You are a routing agent. Classify the user's request into one of: billing, technical, sales, general."},
    {"role": "user", "content": "I was charged twice for my subscription last month"},
    {"role": "assistant", "content": "billing"}
  ]
}

Para nodos de tool-calling:

{
  "messages": [
    {"role": "system", "content": "Select the appropriate tool and parameters for the user's request. Available tools: search_kb, create_ticket, get_account_info."},
    {"role": "user", "content": "Look up the refund policy for annual plans"},
    {"role": "assistant", "content": "{\"tool\": \"search_kb\", \"params\": {\"query\": \"refund policy annual plans\", \"category\": \"billing\"}}"}
  ]
}

Entrenando Adaptadores LoRA Separados

Para máxima eficiencia, entrena adaptadores LoRA separados para cada tipo de nodo:

• Adaptador enrutador: Entrenado en decisiones de enrutamiento (dataset pequeño, entrenamiento rápido)
• Adaptador de tool-calling: Entrenado en selección de herramientas y generación de parámetros
• Adaptador de respuesta: Entrenado en generación de respuestas específicas del dominio
• Adaptador de resumen: Entrenado en compresión de estado

Cada adaptador pesa 50-200MB. Puedes intercambiarlos en caliente por nodo, o fusionar el más utilizado con el modelo base y cargar los demás bajo demanda.

500-1,000 ejemplos por tipo de nodo es un punto de partida razonable. Los nodos enrutadores necesitan menos ejemplos (200-300 suele ser suficiente para 5-10 categorías). La generación de respuestas se beneficia de más (800-1,500 para calidad de output diversa).

Reemplazo Directo con Ollama

La razón por la que esto funciona con cambios mínimos de código: Ollama expone una API compatible con OpenAI. LangGraph usa la interfaz de modelos de chat de LangChain. Cambiar GPT-4 por un modelo local es un cambio de una línea.

Antes:

from langchain_openai import ChatOpenAI
llm = ChatOpenAI(model="gpt-4o", temperature=0)

Después:

from langchain_ollama import ChatOllama
llm = ChatOllama(model="fine-tuned-router", temperature=0)

Para la arquitectura híbrida, asigna diferentes modelos a diferentes nodos:

router_llm = ChatOllama(model="fine-tuned-router")
tool_llm = ChatOllama(model="fine-tuned-tools")
response_llm = ChatOllama(model="fine-tuned-responder")
reasoning_llm = ChatOpenAI(model="gpt-4o")  # Fallback en la nube

Cada nodo en tu grafo LangGraph recibe el modelo que mejor se adapta a su tarea. La orquestación del grafo es idéntica — solo cambia el backend del LLM.

Impacto en Costos

Hagamos los números para un agente de soporte al cliente manejando 1,000 tareas por día, con un promedio de 8 llamadas LLM por tarea:

Todo GPT-4o

• 8,000 llamadas/día x ~2,000 tokens promedio x ($2.50 + $10)/2M tokens
• Aproximadamente $50-$100/día → $1,500-$3,000/mes

Híbrido (80% Local, 20% GPT-4o)

• 6,400 llamadas/día locales: $0
• 1,600 llamadas/día GPT-4o: $10-$20/día
• GPU en la nube para modelo local: $150-$300/mes
• $450-$900/mes (70% de reducción)

Todo Local (con fallback a la nube para casos verdaderamente novedosos)

• 7,800 llamadas/día locales: $0
• 200 llamadas/día GPT-4o fallback: ~$2.50/día
• GPU en la nube: $150-$300/mes
• $225-$375/mes (85-90% de reducción)

La transición de 100% nube a híbrido toma aproximadamente 3 semanas: 1 semana recopilando trazas, 1 semana entrenando adaptadores, 1 semana probando y desplegando. La transición de híbrido a mayormente-local es incremental — expandes la cobertura del modelo ajustado a medida que recopilas más datos de entrenamiento de las llamadas restantes a la nube.

Evaluación: Asegurando Que el Agente Ajustado Funciona

Antes de desplegar nodos ajustados en producción, ejecuta una evaluación adecuada:

1. Reserva el 20% de tus trazas como datos de prueba. No entrenes con ellos.
2. Ejecuta el modelo ajustado en entradas de prueba y compara los outputs con los de GPT-4. Para nodos enrutadores, mide la precisión. Para nodos de tool-calling, mide el cumplimiento del esquema y la precisión de parámetros. Para nodos de respuesta, mide la similitud semántica y la precisión factual.
3. Ejecuta el grafo completo del agente con nodos ajustados en tareas históricas. Compara las tasas de éxito de extremo a extremo.
4. Despliegue en sombra. Ejecuta tanto el agente GPT-4 como el agente ajustado en tráfico en vivo, pero solo sirve respuestas de GPT-4. Registra las respuestas ajustadas para comparación. Cuando el agente ajustado iguale a GPT-4 en 95%+ de las tareas, haz el cambio.

Métricas objetivo:

• Precisión del enrutador: 97%+ (la mayoría de los equipos alcanzan 98-99%)
• Cumplimiento de esquema en tool calls: 99%+
• Calidad de respuesta (calificación humana): dentro de 0.2 puntos de GPT-4 en una escala de 5 puntos
• Éxito de tarea de extremo a extremo: dentro de 2-3% del agente GPT-4

Cuándo Quedarse con GPT-4

Algunos agentes LangGraph genuinamente necesitan modelos frontier en todo el flujo:

• Agentes que manejan tareas verdaderamente abiertas con tipos de entrada impredecibles
• Agentes que operan en docenas de dominios donde no puedes construir datos de entrenamiento específicos del dominio
• Agentes prototipo en desarrollo temprano donde aún estás descubriendo la estructura de la tarea
• Agentes donde la precisión en la distribución de cola es crítica (diagnóstico médico, análisis legal) y necesitas el modelo más fuerte para cada caso

Para la mayoría de los agentes LangGraph en producción — soporte al cliente, procesamiento de datos, generación de contenido, automatización de flujos — el enfoque híbrido con modelos locales ajustados en el núcleo ofrece mejor consistencia a una fracción del costo.

---

Lectura Adicional

• Agentes de IA Multi-Paso con Modelos Locales — Cómo arquitectar flujos de trabajo de agentes multi-paso que se ejecutan completamente en inferencia local.
• Fine-Tuning para Tool Calling: Cómo Construir Agentes de IA Confiables con Modelos Pequeños — Inmersión profunda en el entrenamiento de modelos para output estructurado de tool-calling.
• Reemplaza GPT-4 con un Modelo Local de Tool-Calling — Guía paso a paso para cambiar APIs en la nube por inferencia local en tu stack de agentes.