11 min de lectura
La mayoría de los equipos tratan fine-tuning y RAG como alternativas. No lo son. Son dos puntos en un espectro de context engineering que también incluye contexto largo con caching y destilación. Este es el framework de decisión que uso en producción.
Celestino Salim
Senior Software Engineer
El comportamiento de un modelo en cualquier momento es una función de todo lo que hay en su ventana de contexto. Decidir qué entra en esa ventana, instrucciones, retrieval, memoria y herramientas, no es escribir prompts. Es arquitectura, y merece el mismo rigor.
"¿Debería hacer fine-tuning o usar RAG?" Escucho esta pregunta cada semana. De ingenieros en startups, de arquitectos en empresas grandes, de CTOs intentando lanzar funcionalidades de IA. Y casi siempre, la pregunta en sí está mal planteada.
Fine-tuning y RAG no son alternativas. Son herramientas distintas que resuelven problemas distintos. Preguntar "¿fine-tuning o RAG?" es como preguntar "¿debería usar una base de datos o un API?" La respuesta depende de lo que realmente estás intentando hacer.
He puesto en producción sistemas usando solo fine-tuning, solo RAG, ambos juntos, y ninguno. La decisión correcta nunca es sobre preferencia tecnológica. Es sobre qué problema estás resolviendo, cómo son tus datos, y cuánto quieres gastar.
El encuadre más limpio que he encontrado: esto no es un duelo entre dos técnicas. Es un espectro de context engineering con cuatro puntos, ordenados por cuánta maquinaria asumes. La pregunta siempre es "qué debería saber o hacer el modelo al momento de responder, y cual es la forma más barata de lograrlo."
Los dos puntos del medio se llevan toda la atención, y por eso el resto de este post pasa la mayor parte del tiempo ahí. Pero los bordes son donde viven las victorias fáciles: el primer punto borra infraestructura que estabas por construir, y el último rescata márgenes en sistemas que ya funcionan.
Fine-tuning cambia cómo responde el modelo. No agrega conocimiento nuevo. Deja que lo repita porque es lo más malinterpretado en IA aplicada: fine-tuning no le enseña hechos nuevos al modelo.
Lo que hace es modificar el comportamiento del modelo. Tono, formato, patrones de razonamiento, convenciones de un dominio específico. Cuando hice fine-tuning de un modelo para una empresa de tecnología legal, el modelo no aprendió jurisprudencia nueva. Aprendió a escribir como abogado -- argumentos estructurados, formato de citas correcto, conclusiones con reservas.
Piénsalo como una contratación. Contratas a alguien con inteligencia general y luego lo entrenas en la guía de estilo de tu empresa. No aprende tus datos propietarios de repente. Aprende a comunicarse como tú esperas.
No puede darle al modelo acceso a tu base de datos propietaria. No puede hacer que el modelo conozca eventos posteriores a su corte de entrenamiento. No puede enseñarle hechos específicos de forma confiable -- los estudios muestran que los modelos con fine-tuning siguen alucinando detalles factuales a tasas similares a los modelos base. El comportamiento cambia. El conocimiento no.
RAG le da al modelo acceso a información en el momento de la consulta. No cambia cómo se comporta el modelo. Cambia lo que el modelo sabe cuando responde una pregunta específica.
La mecánica: un usuario hace una pregunta, buscas en una base de conocimiento contexto relevante, metes ese contexto en el prompt junto con la pregunta, y el modelo genera una respuesta basada en los documentos recuperados.
Construí un sistema RAG para una fintech que necesitaba responder preguntas sobre su manual de cumplimiento regulatorio de 2,000 páginas. El comportamiento del modelo no necesitaba cambiar. Ya sabía cómo resumir y explicar. Solo necesitaba acceso a la información correcta en el momento correcto.
No puede cambiar la personalidad del modelo, su formato de salida, ni su estilo de razonamiento. Si el modelo base escribe como un chatbot y necesitas que escriba como un radiólogo, RAG no va a arreglar eso. Vas a obtener respuestas estilo chatbot que casualmente referencian documentos de radiología.
Este es el framework que uso. Toma unos cinco minutos trabajarlo, y me ha salvado de sobre-diseñar más veces de las que puedo contar.
| Lo que Necesitas | Solución | Ejemplo | |---|---|---| | Conocimiento que cabe en la ventana y cambia poco | Contexto largo + caching | Q&A sobre un manual de producto | | Comportamiento o formato de dominio | Fine-tune | Escritos legales en formato judicial | | Acceso a datos grandes, actuales o privados | RAG | Q&A sobre documentación interna | | Comportamiento y conocimiento | Fine-tune + RAG | Asistente médico con expedientes | | Calidad de modelo grande a costo de modelo pequeño | Destilación | Clasificación de alto volumen | | Nada de lo anterior (tarea general, datos públicos) | Prompt engineering | Chatbot de soporte al cliente |
La última fila es la que la gente se salta. Prompt engineering cubre aproximadamente el 80% de los casos de uso que veo en producción. Antes de recurrir a fine-tuning o RAG, dedica una semana seria a prompt engineering. Me refiero a prompts estructurados con ejemplos, chain-of-thought, schemas de salida. No "eres un asistente útil."
Si prompt engineering te lleva al 85% de calidad y tus usuarios están contentos, lánzalo. Siempre puedes agregar fine-tuning o RAG después cuando tengas datos reales de uso diciéndote dónde falla la calidad.
Aquí es donde la mayoría de los posts agitan las manos. Deja que te dé números reales con precios de 2026 para que puedas armar un caso de negocio.
Entrenamiento (único por versión de modelo):
Eso es sorprendentemente barato. El costo oculto está en la curación del dataset. Pasé 40 horas construyendo un dataset de calidad para un proyecto reciente. A tarifas de ingeniería, eso son $6,000-$10,000 de mano de obra por los datos, y $5 por el entrenamiento real.
Inferencia (continuo):
La inferencia con fine-tuning cuesta aproximadamente 1.5x el modelo base. Pero si hiciste fine-tuning de un modelo pequeño para igualar la calidad de uno grande, podrías ahorrar 5-10x en inferencia. Esa matemática funciona a escala.
RAG tiene cuatro componentes de costo. Todos son continuos.
Generación de embeddings:
Base de datos vectorial:
Latencia de recuperación:
Inferencia del LLM con contexto:
Costo total de RAG a 10,000 consultas/día: $300-$2,500/mes dependiendo de tus decisiones de arquitectura. Cubrí cómo reducir esto en mi post sobre optimización de costos de RAG.
Para un sistema manejando 10,000 consultas por día:
| Componente | Solo Fine-Tune | Solo RAG | Ambos | |---|---|---|---| | Costo de setup | $5K-$15K (datos + entrenamiento) | $1K-$5K (pipeline) | $10K-$20K | | Infra mensual | $0 | $100-$300 | $100-$300 | | Inferencia mensual | $400-$1,200 | $600-$2,500 | $500-$1,500 | | Mantenimiento | Bajo (reentrenar trimestral) | Medio (actualización de índices) | Alto |
Fine-tuning tiene mayor costo inicial pero menor costo continuo. RAG tiene menor costo inicial pero overhead continuo de infra y mantenimiento. El híbrido es el más caro de construir y mantener -- úsalo solo cuando genuinamente necesites tanto cambio de comportamiento como acceso a conocimiento.
A veces realmente necesitas ambos. Construí un sistema híbrido para una empresa de salud que necesitaba un modelo que: (a) escribiera notas clínicas en un formato específico con terminología médica apropiada, y (b) referenciara expedientes de pacientes y protocolos de tratamiento.
Fine-tuning manejó el comportamiento: formato de notas consistente, lenguaje médico apropiado, secciones de evaluación estructuradas. RAG manejó el conocimiento: historial del paciente, medicamentos actuales, guías clínicas relevantes.
El flujo se ve así:
Consulta del Usuario
|
v
[Embedding Model] --> [Vector DB Search]
| |
| Contexto Recuperado
| |
v v
[LLM con Fine-Tuning] <-- [Prompt Template]
|
v
Respuesta Formateada
El modelo con fine-tuning recibe el contexto recuperado a través de un prompt template. Ya sabe cómo formatear notas clínicas. El pipeline de RAG le da los datos específicos del paciente para referenciar. Cada componente hace lo que sabe hacer bien.
Si estás construyendo un sistema híbrido, construye RAG primero. Te explico por qué:
He visto equipos pasar meses haciendo fine-tuning de un modelo solo para descubrir que un prompt template bien estructurado con ejemplos recuperados por RAG resolvía el mismo problema con una décima parte del esfuerzo.
Esta es la sección más útil de este post, y la que nadie quiere escuchar.
Prompt engineering maneja la mayoría de los casos de uso. No el 50%. No el 60%. Estimo que el 80% de los sistemas de IA en producción que he revisado funcionarían bien solo con prompt engineering bien pensado.
Esto es lo que significa "prompt engineering bien pensado":
Un sistema de prompts bien diseñado cuesta $0 en infraestructura, toma días en vez de meses para construir, y puede iterarse sin reentrenar nada. El tradeoff es mayor costo de tokens por consulta (prompts más largos) y menos consistencia en casos límite.
Antes de empezar a construir fine-tuning o RAG:
Recientemente asesoré un sistema para una empresa de e-commerce. Querían una IA que pudiera:
Su plan inicial era hacer fine-tuning de GPT-4o con su voz de marca y construir un sistema RAG para datos de productos. Tiempo estimado de construcción: 3 meses. Costo mensual estimado: $4,000.
Lo que realmente lanzamos:
Tiempo de construcción: 3 semanas. Costo mensual: $800. La voz de marca era suficientemente consistente con ejemplos few-shot como para que fine-tuning no valiera la carga de mantenimiento. Ahorramos dos meses de tiempo de ingeniería y $3,200 por mes al preguntar "¿realmente necesitamos esto?" antes de construir.
La decisión no es fine-tuning vs RAG. La decisión es: ¿qué problema estoy resolviendo, y cuál es el punto más barato del espectro de context engineering que lo resuelve?
Empieza con prompt engineering. Si el conocimiento cabe en la ventana y cambia poco, prueba contexto largo con caching antes de construir nada. Agrega RAG cuando el corpus supere la ventana o necesite citas. Agrega fine-tuning si necesitas cambio de comportamiento que los prompts no pueden lograr. Destila cuando el sistema funciona pero la economía no. Construye el híbrido solo cuando hayas probado que necesitas comportamiento y conocimiento a la vez.
Esta es una instancia de un argumento más grande que desarrollo en Context Engineering Es Diseño de Sistemas: decidir qué sabe el modelo al momento de responder es un problema de arquitectura, y cada punto de este espectro es solo una respuesta distinta a esa pregunta.
La mejor arquitectura es la que no sobre-construyes. Lanza lo más simple que funcione, mídelo en producción, y agrega complejidad solo cuando los datos te lo digan.