Cuando NO Hacer Fine-Tuning: 5 Casos Donde RAG, Prompting o APIs Son Mejores

Ertas es una plataforma de fine-tuning. La construimos porque el fine-tuning resuelve problemas reales que el prompting y RAG no pueden. Pero tambien hemos visto equipos pasar semanas haciendo fine-tuning de modelos para tareas donde un enfoque mas simple habria funcionado mejor. Eso es tiempo y dinero desperdiciado, y erosiona la confianza en el fine-tuning como tecnica.

Preferimos que tengas exito con el enfoque correcto a que fracases con fine-tuning. Asi que aqui hay cinco casos donde no deberias hacer fine-tuning -- y que hacer en su lugar.

Caso 1: Tu Base de Conocimiento Cambia Frecuentemente

El escenario: Estas construyendo un bot de soporte al cliente para una empresa de e-commerce. El catalogo de productos, precios, politicas de devolucion e informacion de envio cambian semanalmente. Quieres que el modelo de respuestas precisas y actualizadas.

Por que el fine-tuning esta mal aqui: El fine-tuning incorpora conocimiento en el modelo al momento del entrenamiento. Cuando entrenas con tu catalogo de productos actual, el modelo aprende que el "UltraWidget Pro" cuesta $299 y se envia en 3-5 dias habiles. La proxima semana, el precio baja a $249 y el envio cambia a 2-3 dias. Tu modelo fine-tuned sigue diciendo $299 y 3-5 dias.

Para mantener el modelo actualizado, necesitarias reentrenar cada vez que algo cambie. Con ciclos de actualizacion semanales, eso significa reentrenamiento semanal -- cada ciclo costando tiempo de computo, requiriendo preparacion de datos y arriesgando regresion en otros comportamientos. La economia no funciona.

Que hacer en su lugar: RAG. La generacion aumentada por recuperacion recupera documentos relevantes de tu base de conocimiento en el momento de la consulta. Cuando cambian los precios, actualizas los documentos en tu base de datos vectorial. El modelo ve la informacion actual en cada solicitud sin ningun reentrenamiento.

Actualiza tu indice vectorial en minutos. Reentrena un modelo en horas. Para informacion que cambia rapidamente, la eleccion es obvia.

La excepcion: Si necesitas que el modelo tenga un estilo de comunicacion especifico o siga patrones de respuesta particulares mientras usa RAG para el conocimiento, puedes combinar ambos. Fine-tuning para comportamiento, RAG para hechos. Esta es frecuentemente la mejor arquitectura -- pero el fine-tuning solo no es la respuesta cuando el conocimiento es volatil.

Caso 2: Necesitas que el Modelo Cite Fuentes

El escenario: Estas construyendo un asistente de investigacion para una consultora. Los analistas hacen preguntas y necesitan respuestas respaldadas por informes, estudios o documentos internos especificos. Cada afirmacion debe ser rastreable a una fuente.

Por que el fine-tuning esta mal aqui: Un modelo fine-tuned absorbe informacion en sus pesos. Puede decirte lo que "sabe," pero no puede decirte donde lo aprendio. No hay mecanismo para que un modelo fine-tuned senale un documento especifico, numero de pagina o pasaje que respalde su salida.

Podrias intentar incluir referencias de fuentes en los datos de entrenamiento (entrenar al modelo para producir afirmaciones con citas), pero esto es fragil. El modelo aprende a generar citas de apariencia plausible, no reales. Fabricara titulos de documentos y numeros de pagina con la misma confianza que tiene para los reales.

Que hacer en su lugar: RAG con metadatos de recuperacion. Un sistema RAG recupera fragmentos especificos de texto de documentos identificados. Cada fragmento lleva metadatos -- titulo del documento, numero de pagina, seccion, fecha. El modelo genera una respuesta basada en los fragmentos recuperados, y puedes mostrar los metadatos de la fuente junto a la respuesta.

Esto te da trazabilidad genuina. Las citas son reales porque provienen del sistema de recuperacion, no de la generacion del modelo. Para industrias con alto cumplimiento -- legal, financiera, medica, consultoria -- esto no es opcional.

El matiz: El fine-tuning puede mejorar como el modelo usa el contexto recuperado. Un modelo fine-tuned podria ser mejor sintetizando informacion de multiples documentos recuperados y produciendo respuestas coherentes. Pero la capacidad de citacion misma debe provenir de la arquitectura de recuperacion, no del fine-tuning.

Caso 3: Solo lo Necesitas para Tareas Ocasionales Puntuales

El escenario: Tu agencia construye soluciones de IA personalizadas. Tienes un cliente que necesita una migracion unica de 5,000 descripciones de productos de un formato a otro. Es un trabajo por lotes que se ejecutara una vez y estara listo.

Por que el fine-tuning esta mal aqui: El fine-tuning tiene un costo fijo inicial: preparacion de datos (2-8 horas de trabajo), computo de entrenamiento ($5-50) y tiempo de evaluacion (1-2 horas). Para una tarea que ejecutaras una vez, esta inversion frecuentemente excede el costo de simplemente usar una API.

A $0.01-0.03 por solicitud, procesar 5,000 elementos a traves de una API de frontera cuesta $50-150. Hacer fine-tuning del modelo, desplegarlo y procesar los mismos 5,000 elementos cuesta aproximadamente lo mismo en total -- pero toma significativamente mas tiempo calendario. Y el modelo fine-tuned no tiene valor residual si no vas a usarlo de nuevo.

Que hacer en su lugar: Usar una API con un prompt bien elaborado. Para trabajos por lotes unicos, el enfoque de API es mas rapido de configurar, mas facil de iterar y cuesta aproximadamente lo mismo. Escribe un buen system prompt, pruebalo en 50 ejemplos, ajusta y luego procesa el lote completo.

El umbral: El fine-tuning empieza a tener sentido economico cuando esperas procesar 50+ solicitudes por dia de manera continua. Por debajo de eso, el ahorro de costo por solicitud no compensa el costo fijo del entrenamiento. El calculo cambia si la consistencia es critica para el negocio (ver la excepcion del Caso 5), pero para la mayoria de las tareas puntuales, una API es la herramienta correcta.

Caso 4: Tu Tarea Requiere Conocimiento Amplio del Mundo

El escenario: Quieres un modelo que pueda responder preguntas generales sobre historia, ciencia, eventos actuales y cultura para una plataforma educativa. Necesita manejar preguntas desde nivel elemental hasta nivel de posgrado en docenas de materias.

Por que el fine-tuning esta mal aqui: El fine-tuning especializa un modelo. Lo hace mejor en tu tarea especifica al especializar sus pesos hacia tu distribucion de entrenamiento. Esta especializacion tiene un costo -- el modelo se vuelve menos capaz en cosas fuera de la distribucion de entrenamiento.

Si haces fine-tuning de un modelo 7B con preguntas de historia, mejora en historia pero puede empeorar ligeramente en ciencia. Si haces fine-tuning en ambas, necesitas un dataset de entrenamiento enorme y diverso para evitar degradar cualquier dominio individual. En ese punto, esencialmente estas rehaciendo el pre-entrenamiento del modelo, lo cual no es practico.

El conocimiento amplio del mundo es para lo que fueron construidos los grandes modelos de frontera. Un modelo de 400B+ parametros entrenado en billones de tokens tiene la capacidad de contener vasto conocimiento en todos los dominios. Un modelo 7B fine-tuned con 5,000 ejemplos no compite en amplitud.

Que hacer en su lugar: Usar un modelo de frontera grande via API. GPT-4o, Claude 3.5 Sonnet o Gemini 1.5 Pro ya tienen el conocimiento amplio que tu tarea requiere. Usalos directamente con prompting apropiado.

La preocupacion de costo: Las APIs de frontera son caras a escala. Si alcanzas un volumen donde los costos de API se vuelven insostenibles, considera un enfoque hibrido: usa RAG para recuperar conocimiento relevante y servirlo a un modelo mas pequeno. Esto te da la cobertura amplia de tu base de conocimiento con la eficiencia de costo de un modelo mas pequeno -- sin el efecto de especializacion del fine-tuning.

Caso 5: No Has Intentado Buena Ingenieria de Prompts Primero

El escenario: Tienes una tarea. Escribiste un prompt basico. La salida no es buena. Concluyes que necesitas hacer fine-tuning.

Por que el fine-tuning esta mal aqui: Este es el error mas comun que vemos. Los equipos saltan al fine-tuning despues de escribir un system prompt de 200 palabras y probarlo en 10 ejemplos. No han intentado:

Ejemplos few-shot en el prompt. Agregar 3-5 ejemplos de alta calidad de entrada-salida al system prompt puede mejorar dramaticamente la calidad de salida. Esto toma 30 minutos, no 30 horas.
Prompting de cadena de pensamiento. Para tareas de razonamiento, pedir al modelo que "piense paso a paso" antes de producir la respuesta final mejora la precision en 10-30% en muchos benchmarks.
Instrucciones de salida estructurada. Especificar explicitamente el formato de salida, incluyendo nombres de campos y tipos, frecuentemente resuelve problemas de formato sin fine-tuning.
Refinamiento iterativo de prompts. Probar en 50+ ejemplos diversos, identificar patrones de falla y abordarlos con modificaciones de prompt dirigidas. La mayoria de los equipos se rinden despues de 3-4 iteraciones cuando 10-15 iteraciones habrian resuelto el problema.
Seleccion de modelo. A veces el problema no es el prompt sino el modelo. Probar un modelo base diferente (o uno mas grande) puede resolver el problema inmediatamente.

La buena ingenieria de prompts es mas rapida y barata de iterar que el fine-tuning. Un cambio de prompt toma segundos en probar. Un cambio de fine-tuning toma horas. Siempre agota la optimizacion de prompts antes de invertir en entrenamiento.

Cuando la ingenieria de prompts esta genuinamente agotada: Tienes un system prompt de 1,500+ tokens con 5+ ejemplos few-shot. Has probado en 100+ entradas. Has iterado el prompt 15+ veces. La precision se ha estancado. El modelo es inconsistente entre ejecuciones identicas. En este punto, tienes evidencia solida de que la tarea excede lo que el prompting puede entregar -- y tu prompt se convierte en el punto de partida para generar datos de fine-tuning. Lee nuestro playbook de migracion para el proceso exacto.

El Diagrama de Decision

Cuando estes evaluando si hacer fine-tuning, recorre estas preguntas en orden:

Has optimizado tu prompt a fondo? Si no, haz eso primero. Costo: horas. Potencial ventaja: resuelve el problema completamente.
Tu tarea requiere conocimiento que se actualiza frecuentemente? Si es asi, usa RAG. El fine-tuning incorpora conocimiento obsoleto.
Necesitas citas de fuentes? Si es asi, necesitas un componente de recuperacion. El fine-tuning solo no puede proporcionar citas genuinas.
Es una tarea unica o de bajo volumen? Si es menor a 50 solicitudes/dia sin necesidad continua, usa una API. El costo fijo del fine-tuning no se justifica.
La tarea requiere conocimiento amplio en muchos dominios? Si es asi, usa un modelo de frontera grande. El fine-tuning especializa la capacidad.
Tu tarea es estrecha, de alto volumen y requiere comportamiento consistente? Si es si a las tres, haz fine-tuning. Esto es donde el fine-tuning sobresale.

Si llegas a la pregunta 6, el fine-tuning probablemente es la eleccion correcta. La tarea es lo suficientemente estrecha para entrenarse bien, de suficiente alto volumen para justificar la inversion y exige la consistencia que solo el comportamiento aprendido (no el comportamiento promteado) puede proporcionar.

Cuando Combinar Enfoques

Los cinco casos anteriores describen cuando el fine-tuning solo es la respuesta equivocada. Pero el fine-tuning combinado con otros enfoques es frecuentemente la mejor respuesta:

RAG + Modelo Fine-Tuned. Usa RAG para recuperacion de conocimiento y un modelo fine-tuned para generacion de respuestas. El modelo aprende tu estilo de respuesta especifico, formato y tono a traves del fine-tuning. Obtiene conocimiento actual y citable del sistema de recuperacion. Esta es la arquitectura que la mayoria de las agencias deberian estar evaluando para sistemas de produccion.

Un modelo Llama 8B fine-tuned con RAG frecuentemente supera a un modelo de frontera con RAG en tareas especificas de dominio -- porque el modelo fine-tuned entiende mejor como usar el contexto recuperado para tu dominio particular.

Fine-Tuning + Ingenieria de Prompts. Incluso los modelos fine-tuned se benefician de system prompts. Un modelo fine-tuned con un system prompt corto (200 tokens) que proporciona contexto especifico de la sesion (preferencias del usuario, fecha actual, variante de tarea) supera al mismo modelo sin prompt. El fine-tuning maneja la base del comportamiento; el prompt maneja la personalizacion por solicitud.

Fine-Tuning + Fallback API. Para tareas que son 90% estrechas y 10% amplias, haz fine-tuning para el 90% y enruta el 10% restante a una API de frontera. Usa un clasificador (que puede ser en si mismo un modelo pequeno fine-tuned) para determinar que camino debe tomar cada solicitud. Esto te da la eficiencia de costo del fine-tuning para el caso comun y la capacidad de un modelo de frontera para casos extremos.

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.

View early bird pricing or join the waitlist →

La Evaluacion Honesta

El fine-tuning es una tecnica poderosa. Produce modelos mas rapidos, mas baratos y mas consistentes para tareas estrechas. Permite despliegues que preservan la privacidad manteniendo datos fuera de servidores de terceros. Crea fosos tecnicos genuinos para agencias.

Pero no siempre es la herramienta correcta. Los equipos que tienen exito con IA son los que emparejan la tecnica con el problema -- no los que aplican su tecnica favorita a cada problema.

Si tu situacion coincide con uno de los cinco casos anteriores, ahorra tiempo y usa el enfoque mas simple. Si has revisado los cinco y tu tarea genuinamente requiere fine-tuning, construimos Ertas para hacer ese proceso lo mas directo posible.

Lectura relacionada: