La mayoria de los equipos tratan fine-tuning y RAG como alternativas. No lo son. Resuelven problemas distintos, cuestan diferente, y a veces necesitas ambos. Este es el framework de decision que uso en produccion.
Celestino Salim
Senior Software Engineer | AI Systems | Product Engineering
La mayoría de prototipos RAG cuestan $2-5 por consulta. Con 10,000 consultas diarias eso es $1.5M al año. Reduje costos de retrieval en un 99% en producción. Esta es la guía práctica.
"Deberia 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 si esta mal planteada.
Fine-tuning y RAG no son alternativas. Son herramientas distintas que resuelven problemas distintos. Preguntar "fine-tuning o RAG?" es como preguntar "deberia usar una base de datos o un API?" La respuesta depende de lo que realmente estas intentando hacer.
He puesto en produccion sistemas usando solo fine-tuning, solo RAG, ambos juntos, y ninguno. La decision correcta nunca es sobre preferencia tecnologica. Es sobre que problema estas resolviendo, como son tus datos, y cuanto quieres gastar.
Fine-tuning cambia como responde el modelo. No agrega conocimiento nuevo. Deja que lo repita porque es lo mas malinterpretado en IA aplicada: fine-tuning no le ensena hechos nuevos al modelo.
Lo que hace es modificar el comportamiento del modelo. Tono, formato, patrones de razonamiento, convenciones de un dominio especifico. Cuando hice fine-tuning de un modelo para una empresa de tecnologia legal, el modelo no aprendio jurisprudencia nueva. Aprendio a escribir como abogado -- argumentos estructurados, formato de citas correcto, conclusiones con reservas.
Piensalo como una contratacion. Contratas a alguien con inteligencia general y luego lo entrenas en la guia de estilo de tu empresa. No aprende tus datos propietarios de repente. Aprende a comunicarse como tu 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 ensenarle hechos especificos 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 informacion en el momento de la consulta. No cambia como se comporta el modelo. Cambia lo que el modelo sabe cuando responde una pregunta especifica.
La mecanica: 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.
Construi un sistema RAG para una fintech que necesitaba responder preguntas sobre su manual de cumplimiento regulatorio de 2,000 paginas. El comportamiento del modelo no necesitaba cambiar. Ya sabia como resumir y explicar. Solo necesitaba acceso a la informacion 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 radiologo, RAG no va a arreglar eso. Vas a obtener respuestas estilo chatbot que casualmente referencian documentos de radiologia.
Este es el framework que uso. Toma unos cinco minutos trabajarlo, y me ha salvado de sobre-disenar mas veces de las que puedo contar.
| Lo que Necesitas | Solucion | Ejemplo | |---|---|---| | Comportamiento o formato de dominio | Fine-tune | Escritos legales en formato judicial | | Acceso a datos actuales o privados | RAG | Q&A sobre documentacion interna | | Comportamiento y conocimiento | Fine-tune + RAG | Asistente medico con expedientes | | Ninguno (tarea general, datos publicos) | Prompt engineering | Chatbot de soporte al cliente |
La cuarta fila es la que la gente se salta. Prompt engineering cubre aproximadamente el 80% de los casos de uso que veo en produccion. 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 util."
Si prompt engineering te lleva al 85% de calidad y tus usuarios estan contentos, lancalo. Siempre puedes agregar fine-tuning o RAG despues cuando tengas datos reales de uso diciendote donde falla la calidad.
Aqui es donde la mayoria de los posts agitan las manos. Deja que te de numeros reales con precios de 2026 para que puedas armar un caso de negocio.
Entrenamiento (unico por version de modelo):
Eso es sorprendentemente barato. El costo oculto esta en la curacion del dataset. Pase 40 horas construyendo un dataset de calidad para un proyecto reciente. A tarifas de ingenieria, 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 pequeno para igualar la calidad de uno grande, podrias ahorrar 5-10x en inferencia. Esa matematica funciona a escala.
RAG tiene cuatro componentes de costo. Todos son continuos.
Generacion de embeddings:
Base de datos vectorial:
Latencia de recuperacion:
Inferencia del LLM con contexto:
Costo total de RAG a 10,000 consultas/dia: $300-$2,500/mes dependiendo de tus decisiones de arquitectura. Cubri como reducir esto en mi post sobre optimizacion de costos de RAG.
Para un sistema manejando 10,000 consultas por dia:
| 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 (actualizacion de indices) | Alto |
Fine-tuning tiene mayor costo inicial pero menor costo continuo. RAG tiene menor costo inicial pero overhead continuo de infra y mantenimiento. El hibrido es el mas caro de construir y mantener -- usalo solo cuando genuinamente necesites tanto cambio de comportamiento como acceso a conocimiento.
A veces realmente necesitas ambos. Construi un sistema hibrido para una empresa de salud que necesitaba un modelo que: (a) escribiera notas clinicas en un formato especifico con terminologia medica apropiada, y (b) referenciara expedientes de pacientes y protocolos de tratamiento.
Fine-tuning manejo el comportamiento: formato de notas consistente, lenguaje medico apropiado, secciones de evaluacion estructuradas. RAG manejo el conocimiento: historial del paciente, medicamentos actuales, guias clinicas relevantes.
El flujo se ve asi:
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 traves de un prompt template. Ya sabe como formatear notas clinicas. El pipeline de RAG le da los datos especificos del paciente para referenciar. Cada componente hace lo que sabe hacer bien.
Si estas construyendo un sistema hibrido, construye RAG primero. Te explico por que:
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 resolvia el mismo problema con una decima parte del esfuerzo.
Esta es la seccion mas util de este post, y la que nadie quiere escuchar.
Prompt engineering maneja la mayoria de los casos de uso. No el 50%. No el 60%. Estimo que el 80% de los sistemas de IA en produccion que he revisado funcionarian bien solo con prompt engineering bien pensado.
Esto es lo que significa "prompt engineering bien pensado":
Un sistema de prompts bien disenado cuesta $0 en infraestructura, toma dias en vez de meses para construir, y puede iterarse sin reentrenar nada. El tradeoff es mayor costo de tokens por consulta (prompts mas largos) y menos consistencia en casos limite.
Antes de empezar a construir fine-tuning o RAG:
Recientemente asesore un sistema para una empresa de e-commerce. Querian 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 construccion: 3 meses. Costo mensual estimado: $4,000.
Lo que realmente lanzamos:
Tiempo de construccion: 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 ingenieria y $3,200 por mes al preguntar "realmente necesitamos esto?" antes de construir.
La decision no es fine-tuning vs RAG. La decision es: que problema estoy resolviendo, y cual es la arquitectura mas simple que lo resuelve?
Empieza con prompt engineering. Agrega RAG si necesitas conocimiento externo. Agrega fine-tuning si necesitas cambio de comportamiento que los prompts no pueden lograr. Construye el hibrido solo cuando hayas probado que necesitas ambos.
La mejor arquitectura es la que no sobre-construyes. Lanza lo mas simple que funcione, midelo en produccion, y agrega complejidad solo cuando los datos te lo digan.