Enrutamiento de modelos en producción: cuándo usar fine-tuned vs API vs RAG

La mayoría de los sistemas de IA en producción no deberían usar un solo enfoque para cada solicitud. El fine-tuning, RAG y las APIs en la nube tienen diferentes perfiles de costo, características de calidad y casos de uso ideales. Los equipos que construyen funciones de IA rentables usan los tres — enrutando cada solicitud al enfoque que mejor la maneja.

Esto no se trata de elegir un ganador. Se trata de construir un sistema de enrutamiento que vincule cada solicitud con la herramienta correcta para ese trabajo específico.

Los tres enfoques, explicados claramente

Modelos ajustados: Un modelo de lenguaje pequeño (7B-14B parámetros) entrenado con los datos de tu tarea específica. El modelo ha internalizado los patrones, formatos y criterios de calidad para tu caso de uso. Se ejecuta localmente o en tu infraestructura. Costo: infraestructura fija, casi cero por solicitud. Mejor para: tareas de alto volumen, bien definidas y repetitivas.

RAG (Generación Aumentada por Recuperación): Un modelo aumentado con un sistema de recuperación que extrae documentos o datos relevantes antes de generar una respuesta. El modelo no necesita memorizar todo — busca lo que necesita. Costo: moderado (costos de embeddings + costos de inferencia). Mejor para: tareas que requieren acceso a bases de conocimiento grandes y cambiantes.

API en la nube (modelos frontera): GPT-4o, Claude Opus, Gemini Pro. Los modelos más grandes y capaces disponibles, accesibles vía API. Costo: precio por token, el costo más alto por solicitud. Mejor para: razonamiento complejo, tareas creativas y cualquier cosa donde la capacidad bruta del modelo importa más.

Cada uno tiene fortalezas claras y limitaciones claras. Mapeémoslas.

La matriz de decisión

Aquí está el marco para decisiones de enrutamiento:

Esta matriz te da el punto de partida. Pero los sistemas de producción necesitan un enrutamiento más granular que una tabla estática.

Cómo se complementan fine-tuned, RAG y API

Los tres enfoques no son competidores. Resuelven diferentes partes del mismo problema.

Ejemplo: un producto SaaS de soporte al cliente

Este producto tiene un asistente de IA que ayuda a los agentes de soporte a responder tickets. Diferentes tipos de solicitudes necesitan diferentes enfoques:

Nivel 1 — Modelo ajustado (60% de las solicitudes):

• Clasificar prioridad y categoría del ticket
• Generar respuestas de acuse de recibo con plantilla
• Extraer detalles del cliente del texto del ticket
• Sugerir tono de respuesta basado en sentimiento
• Dar formato a las respuestas para coincidir con la voz de marca

Estas son tareas de alto volumen y bien definidas. Un modelo 7B ajustado las maneja con más del 95% de precisión porque los patrones son consistentes. Costo: efectivamente cero por solicitud.

Nivel 2 — RAG (25% de las solicitudes):

• Responder preguntas sobre funciones del producto usando la base de conocimiento
• Encontrar artículos de ayuda relevantes para vincular en las respuestas
• Buscar configuración específica del cliente o detalles de cuenta
• Referenciar cambios recientes de políticas o actualizaciones del producto

Estas tareas requieren acceso a información que cambia — tu base de conocimiento se actualiza semanalmente, las cuentas de clientes cambian diariamente. El fine-tuning no puede seguir el ritmo de esta velocidad de cambio. RAG recupera la información actual y genera respuestas fundamentadas en ella.

Nivel 3 — API en la nube (15% de las solicitudes):

• Manejar quejas de clientes escaladas y complejas que necesitan razonamiento matizado
• Redactar respuestas para casos extremos inusuales que el modelo no ha visto
• Analizar hilos de conversación largos (más de 10 mensajes) para resumir contexto
• Generar soluciones creativas para problemas no estándar

Estas solicitudes son infrecuentes pero requieren la profundidad de razonamiento que un modelo frontera proporciona. También son las solicitudes donde la calidad importa más — una queja de cliente escalada no es el lugar para ahorrar AU$0.03 en inferencia.

Implementar el enrutador

La capa de enrutamiento no necesita ser compleja. Aquí hay tres patrones de implementación, de simple a sofisticado:

Patrón 1: enrutamiento basado en endpoint

Mapea tus endpoints de API directamente a enfoques:

/api/classify     → modelo ajustado
/api/search-kb    → pipeline RAG
/api/draft-reply  → modelo ajustado (estándar) o API en la nube (escalado)
/api/analyze      → API en la nube

Esto funciona cuando tus tipos de tarea están claramente separados por endpoint. La mayoría de los productos SaaS pueden categorizar sus funciones de IA limpiamente de esta manera.

Patrón 2: enrutamiento basado en atributos

Enruta basándote en atributos de la solicitud:

if request.token_count < 500 and request.task_type in SIMPLE_TASKS:
    route_to_fine_tuned()
elif request.requires_knowledge_lookup:
    route_to_rag()
elif request.token_count > 2000 or request.task_type in COMPLEX_TASKS:
    route_to_cloud_api()
else:
    route_to_fine_tuned()  # por defecto a la opción más barata

El valor predeterminado es siempre el modelo ajustado — más barato y rápido. Las solicitudes solo escalan a enfoques más caros cuando se cumplen condiciones específicas.

Patrón 3: enrutamiento en cascada

Prueba el enfoque más barato primero. Si no pasa las verificaciones de calidad, escala:

1. Ejecuta la solicitud a través del modelo ajustado
2. Verifica la puntuación de confianza / calidad de salida
3. Si confianza > umbral: devuelve la respuesta
4. Si se necesita búsqueda de conocimiento: ejecuta a través del pipeline RAG, devuelve respuesta
5. Si aún tiene baja confianza: ejecuta a través de la API en la nube, devuelve respuesta

Esto maximiza el ahorro de costos asegurando que cada solicitud pruebe primero la ruta más barata. La compensación es la latencia — una solicitud que pasa por los tres niveles toma 3-5x más que una que se resuelve en el nivel 1. Usa esto para cargas de trabajo asíncronas donde la latencia es menos crítica.

Análisis de costos: enrutamiento vs enfoque único

Modelemos un producto SaaS que procesa 300,000 solicitudes de IA por mes:

Enfoque único: API en la nube para todo

Enfoque único: RAG para todo

RAG reduce los costos ligeramente al proporcionar contexto relevante (se necesitan prompts más cortos), pero aún pagas por token por el paso de generación.

Enrutado: 60% fine-tuned, 25% RAG, 15% API en la nube

El enfoque enrutado ahorra AU$4,750/mes (53%) frente a solo API en la nube. En 12 meses, eso son AU$57,000 en ahorros.

Pero el beneficio real es la curva de escalado. Con 600,000 solicitudes/mes:

• Solo API en la nube: AU$18,000/mes
• Enrutado: AU$5,800/mes (la infraestructura de fine-tuned permanece fija, solo las porciones de API y RAG escalan)

Cuándo RAG supera al fine-tuning

RAG es la opción correcta cuando:

Tu base de conocimiento cambia más rápido de lo que puedes reentrenar. El fine-tuning captura conocimiento estático. Si tu documentación de producto, precios, políticas o datos de clientes cambian semanalmente, el modelo ajustado se queda atrás inmediatamente. RAG siempre recupera información actual.

Tu corpus es demasiado grande para entrenar en un modelo. Un modelo 7B ajustado puede absorber quizás 5,000-10,000 patrones de documentos efectivamente. Si necesitas referenciar 100,000 artículos de soporte, especificaciones de productos o documentos legales, RAG con una base de datos vectorial es el único enfoque práctico.

Los usuarios preguntan sobre documentos específicos. "¿Qué dice la sección 3.2 de nuestro contrato?" es un problema de recuperación, no de generación. El fine-tuning no puede memorizar documentos específicos de manera confiable. RAG recupera la sección exacta y genera una respuesta fundamentada en ella.

Necesitas citas y trazabilidad. RAG naturalmente proporciona documentos fuente para sus respuestas. Los modelos ajustados generan desde patrones aprendidos — no pueden señalar el documento específico que informó su respuesta.

Cuándo el fine-tuning supera a RAG

El fine-tuning gana cuando:

La tarea es sobre cómo responder, no con qué responder. Clasificación, formato, coincidencia de tono, extracción de entidades — estas son tareas de comportamiento. El modelo necesita aprender un patrón, no buscar información. RAG agrega sobrecarga de recuperación innecesaria para estas tareas.

La latencia importa. Un modelo ajustado en hardware local responde en 50-200ms. Un pipeline RAG agrega 100-500ms para la recuperación antes de que la generación siquiera comience. Para funciones en tiempo real — autocompletado, sugerencias en línea, clasificación en vivo — el paso de recuperación es demasiado lento.

El volumen es alto y las tareas son repetitivas. Si procesas 500,000 solicitudes de clasificación por mes, cada una con el mismo patrón, un modelo ajustado las maneja a costo fijo. RAG agregaría 500,000 búsquedas de embeddings y 500,000 búsquedas vectoriales — sobrecarga innecesaria para una tarea que no necesita conocimiento dinámico.

Quieres cero costo por solicitud. Un modelo ajustado en hardware propio tiene cero costo marginal por solicitud. RAG, incluso con un modelo local para generación, aún tiene costos de embedding y recuperación por solicitud (aunque estos son pequeños).

Cuándo genuinamente necesitas la API en la nube

Sé honesto sobre cuándo necesitas capacidades frontera:

Razonamiento de contexto largo. Procesar un documento de 50 páginas para responder una pregunta específica sobre la relación entre las secciones 12 y 47 es una tarea donde un modelo de más de 200B parámetros con ventana de contexto de 128K genuinamente supera a un modelo 7B.

Tareas novedosas zero-shot. Cuando tu IA encuentra un tipo de solicitud para el que no fue entrenada, las capacidades amplias de un modelo frontera lo manejan mejor que un especialista ajustado que nunca ha visto el patrón.

Flujos de trabajo agénticos con uso de herramientas. Flujos de trabajo complejos de múltiples pasos — investigar una respuesta entre múltiples fuentes, razonar sobre los hallazgos, formular un plan, ejecutarlo — aún se benefician de la profundidad del modelo frontera. Esto cambiará a medida que los modelos más pequeños mejoren en llamadas a herramientas, pero hoy la brecha es real.

Solicitudes de baja frecuencia y alta importancia. Si un tipo de solicitud es raro (menor a 100/mes) y de alto riesgo (orientado al cliente, legal, financiero), el costo de AU$0.05-0.10 por solicitud de un modelo frontera vale la pena como seguro de calidad.

Construir la capa de enrutamiento unificada

Tu capa de enrutamiento debería presentar una interfaz única a tu aplicación:

Aplicación → Capa de enrutamiento → [Fine-tuned | RAG | API en la nube] → Respuesta

La aplicación no sabe ni le importa qué backend manejó la solicitud. Envía una solicitud con metadatos (tipo de tarea, prioridad, nivel de usuario) y recibe una respuesta en un formato consistente.

Requisitos de implementación:

• Formato de respuesta consistente entre los tres backends (normalizar durante el enrutamiento)
• Registro por solicitud de qué backend se usó, latencia, conteo de tokens y costo
• Lógica de respaldo — si el backend principal falla o agota el tiempo, enrutar al siguiente nivel
• Soporte para pruebas A/B — capacidad de enrutar un porcentaje del tráfico a un backend diferente para comparación
• Dashboards de costos — costo agregado por backend, por tipo de tarea, por nivel de usuario

Estos datos de registro son lo que impulsa la optimización de tu enrutamiento. Después de 30 días de datos de producción, verás exactamente qué tipos de tarea están siendo sobre-atendidos (backend caro, alta calidad no necesaria) y cuáles están siendo sub-atendidos (backend barato, problemas de calidad).

El ciclo de iteración

El enrutamiento no es una configuración que se establece y se olvida. Mejora con el tiempo:

1. Mes 1: Enruta de manera conservadora — más tráfico a la API en la nube de lo necesario. Recopila datos de calidad.
2. Mes 2: Analiza los datos de calidad. Mueve tipos de tarea que los modelos ajustados manejan bien de la API en la nube a local.
3. Mes 3: Agrega nuevos tipos de tarea a los datos de entrenamiento del fine-tuning. Reentrena. Expande el enrutamiento local.
4. Mes 6: La mayoría de las tareas estables y de alto volumen en modelos ajustados. RAG para tareas dependientes de conocimiento. API en la nube para casos extremos y nuevas funciones.
5. Continuo: Cada ciclo de reentrenamiento mueve más tráfico al nivel más barato.

El estado final para un producto SaaS maduro es típicamente 60-80% fine-tuned, 15-25% RAG, 5-15% API en la nube. Llegar ahí toma 3-6 meses de iteración, pero cada mes reduce costos y mejora la precisión del enrutamiento.

---

Lectura adicional

• Fine-tuning vs RAG — Comparación detallada de los dos enfoques
• Fine-tuned vs RAG para proyectos de clientes — Orientación práctica para elegir entre ellos
• Fine-tuning de SLM para procesamiento de documentos — Cuándo el fine-tuning funciona para cargas de trabajo con muchos documentos