RAG vs fine-tuning vs contexto: cuándo usar cada uno
DominicodeUn cliente me mostró su arquitectura hace unos meses. Había pasado seis semanas haciendo fine-tuning de un modelo para que respondiera preguntas sobre la documentación interna de su empresa.
Seis semanas. Un dataset de 4.000 pares de pregunta-respuesta construidos a mano. Costes de entrenamiento en GPU. Y al final, el sistema seguía inventándose respuestas cuando la pregunta tocaba un documento que no estaba en el training data.
Le pregunté por qué no había usado RAG. Me dijo que pensó que fine-tuning era "la solución profesional". Que RAG era para hacer demos rápidas.
Esa diferencia entre RAG y fine-tuning se malentiende constantemente, y el malentendido sale caro. Pero hay algo peor: casi nadie considera la tercera opción, que es la más barata de las tres y resuelve más casos de los que parece.
¿Cuál es la diferencia entre RAG, fine-tuning y contexto?
La diferencia entre RAG y fine-tuning es qué problema resuelve cada uno: RAG le da al modelo información que no tiene, fine-tuning le cambia la forma de comportarse. Y hay una tercera vía que va antes de las dos: pegar el material en el contexto de la petición. Esta es la tabla que conviene tener delante en una reunión de presupuesto.
| Qué es | Cuándo | Coste | Dónde se rompe | |
|---|---|---|---|---|
| Contexto | Se lo pegas tú en la petición | Poco material, uso puntual | Bajo, pero lo pagas en cada llamada | No cabe, o se pierde lo del medio |
| RAG | Lo busca en tus documentos al preguntar | Mucho material, y que cambia | Medio, sobre todo el pipeline | Si busca mal, responde mal |
| Fine-tuning | Ajustas el modelo con ejemplos | Formato y tono muy propios, o clasificar y extraer en tu dominio | Alto, y se repite con cada modelo nuevo | No sirve para meter datos |
La regla, en una línea: contexto para lo puntual, RAG para lo que sabes, fine-tuning para cómo lo dices.
Si alguien propone fine-tuning para que el modelo conozca vuestros datos, hay una conversación pendiente antes de firmar nada.
El error conceptual que lo complica todo
La mayoría de developers que se acercan a este problema lo enmarcan mal desde el principio.
Piensan en términos de "qué técnica es más potente". Y ahí ya van por el camino equivocado.
La pregunta correcta no es cuál es más potente. Es: ¿qué problema tienes exactamente?
Si tu modelo no sabe cosas que necesita saber — información privada, documentos internos, datos recientes — tienes un problema de conocimiento. Contexto o RAG lo resuelven.
Si tu modelo sabe las cosas pero no las comunica como necesitas — tono diferente, formato específico, comportamiento distinto al por defecto — tienes un problema de comportamiento. Fine-tuning lo resuelve.
Son problemas distintos. Las soluciones no son intercambiables. Y aquí está la frase que ahorra más dinero de todo este terreno:
El fine-tuning enseña comportamiento, no información.
Si le haces fine-tuning con el catálogo de productos, no acabas con un modelo que se sepa el catálogo. Acabas con uno que habla como tu catálogo e inventa referencias con el estilo exacto de las tuyas. Bastante peor que no hacer nada, porque las invenciones son más creíbles.
Contexto: la opción que deberías agotar primero
Es la que se salta todo el mundo, y en muchos proyectos es la única que hacía falta.
Contexto es, literalmente, pegar la información en la petición. El manual, el fragmento de código, las tres facturas de ejemplo. Sin infraestructura, sin pipeline, sin base de datos vectorial. Es lo que la literatura llama in-context learning y lo que en la práctica se acaba llamando prompt stuffing.
Sus dos límites reales:
No cabe todo. La ventana de contexto es el número máximo de tokens que entran en una sola petición, sumando lo que envías y lo que el modelo genera. Los modelos actuales manejan ventanas grandes, pero grande no es infinito y el coste sube con lo que metes.
Se paga en cada llamada. No es una inversión que amortices: es un peaje por petición. Mil consultas al día con el mismo manual de 20.000 tokens delante son veinte millones de tokens al día de material repetido.
Ese segundo problema tiene solución y casi nadie la aplica, así que le dedico una sección propia más abajo.
Y una confusión que conviene cortar aquí: la ventana de contexto no es memoria. Una ventana enorme te deja meter mucho de una vez. Memoria es que algo sobreviva a cerrar la sesión. Son cosas distintas y una no da la otra. Cuando un proveedor te venda un asistente "con memoria", la pregunta útil no es si la tiene, sino qué guarda, dónde y durante cuánto tiempo.
Qué es RAG (Retrieval-Augmented Generation) y cuándo usarlo
RAG no modifica el modelo. El modelo base sigue siendo exactamente el mismo.
Lo que hace es intervenir en el momento en que llega una pregunta. Antes de pasársela al modelo, busca en una base de datos vectorial los fragmentos de tus documentos más relevantes para esa consulta, y los inyecta en el prompt. El modelo entonces responde con acceso real a esa información.
Usuario pregunta: "¿Cuál es la política de devoluciones?"
↓
Sistema RAG busca en vectorDB
↓
Encuentra: chunk del doc "politica-devoluciones-2026.pdf"
↓
Prompt al modelo: "Contexto: [chunk]. Pregunta: ¿Cuál es...?"
↓
Modelo responde con información real
La ventaja clave: tus documentos pueden cambiar mañana. Actualizas la base vectorial. El modelo ya tiene acceso a la nueva información. Sin reentrenar nada.
Visto así, RAG es contexto automatizado: en vez de pegar tú el fragmento correcto, un buscador lo elige por ti en cada petición. Por eso la pregunta de diseño en RAG no es qué modelo usas, es si tu buscador encuentra lo que hace falta.
Si quieres verlo montado con código, tengo el paso a paso en implementación de RAG en Angular, y las estrategias de búsqueda híbrida en RAG avanzado. Y si estás eligiendo el modelo para el componente generativo, este análisis sobre el mejor modelo LLM local en 2026 te ayuda a no sobreingenierizar la infraestructura.
Esto es lo que lo hace ideal para documentación interna, bases de conocimiento, FAQs, soporte técnico — cualquier caso donde la información cambia y necesitas que el modelo cite fuentes reales en lugar de fabricar respuestas.
El límite de RAG está en que no cambia cómo se comporta el modelo. Si necesitas que responda en un tono muy específico, siga un formato exacto, o haga razonamientos que el modelo base no hace bien de forma natural, RAG no te ayuda. Solo le das más información. No lo entrenas.
Qué es fine-tuning de LLMs y cuándo tiene sentido aplicarlo
Fine-tuning sí modifica el modelo. Tomas un modelo base preentrenado y lo sigues entrenando con tu propio dataset, ajustando sus pesos para que aprenda los patrones que te interesan.
El resultado es un modelo diferente. Uno que ha interiorizado un estilo, un formato, un tipo de razonamiento específico. No necesitas darle instrucciones en el prompt porque ya las tiene grabadas en sus pesos.
# Sin fine-tuning: necesitas el prompt completo
prompt = """Eres un asistente técnico especializado en Kubernetes.
Responde siempre con: 1) causa del problema, 2) solución paso a paso,
3) cómo prevenirlo. Usa terminología técnica precisa. No añadas
disclaimers. El tono es directo, de senior a senior.
Problema: Mi pod no arranca después de actualizar la imagen..."""
# Con fine-tuning: el modelo ya sabe cómo comportarse
prompt = "Problema: Mi pod no arranca después de actualizar la imagen..."
El modelo fine-tuneado responde directamente en el formato correcto porque ese comportamiento está en sus pesos. No porque se lo estés recordando en cada llamada.
Lo que fine-tuning no resuelve: inyectar conocimiento factual nuevo. Si entrenas el modelo en el estilo de tu empresa pero no en los documentos de tu empresa, seguirá sin saber qué contienen esos documentos. Habrá aprendido a comunicarse como tú quieres, pero no a responder con información real que no tenía.
Y no es entrenar desde cero. Eso cuesta una fortuna y lo hacen muy pocas organizaciones en el planeta. Esto es un retoque sobre un modelo existente.
La noticia que cambia el cálculo: OpenAI está cerrando su fine-tuning
Si tomaste esta decisión antes de mayo de 2026, vuelve a tomarla. El tablero ha cambiado.
OpenAI está retirando su plataforma de fine-tuning self-serve. Lo dice en su propia página de deprecations, con fechas:
| Fecha | Qué pasa |
|---|---|
| 7 de mayo de 2026 | Las organizaciones que nunca habían hecho fine-tuning ya no pueden empezar |
| 2 de julio de 2026 | Y tampoco las que llevan 60 días sin ejecutar inferencia sobre un modelo fine-tuneado |
| 6 de enero de 2027 | Los clientes activos dejan de poder crear jobs de fine-tuning |
La inferencia sobre modelos ya fine-tuneados sigue funcionando hasta que se deprecie el modelo base. Y en la guía de fine-tuning la propia OpenAI dice que la plataforma "no es accesible para usuarios nuevos", con una lista de modelos soportados que se ha quedado en la familia gpt-4.1 más gpt-4o para visión y o4-mini para refuerzo.
Lo interesante es a dónde te manda su propia documentación: al ciclo de evals más prompt engineering. Contexto relevante, instrucciones claras, ejemplos few-shot y, textualmente, "start with gpt-5.6 for new work". Es decir, la primera columna de la tabla de arriba, ejecutada sobre el modelo más nuevo que tengas a mano.
Y un matiz antes de que alguien lo lea como "el fine-tuning ya no sirve": la misma guía sigue listando como caso válido entrenar un modelo más pequeño, más barato y más rápido para una tarea concreta donde uno grande no sale a cuenta. Eso es exactamente el Caso 4 de más abajo.
Qué significa esto en la práctica:
- Si estabas planteándote fine-tuning en OpenAI y no lo has hecho nunca, esa puerta ya está cerrada. No es una decisión pendiente.
- El fine-tuning sigue existiendo fuera de OpenAI — modelos abiertos con LoRA o QLoRA, y otros proveedores.
- Pero cuando el proveedor más grande te dice que uses un modelo mejor con mejores prompts en lugar de ajustar uno peor, merece la pena escuchar el argumento antes de montar un pipeline de entrenamiento.
No es que el fine-tuning haya dejado de servir. Es que el rango de casos donde gana se ha estrechado, y los modelos base han absorbido buena parte de lo que antes justificaba entrenarlos.
RAG vs fine-tuning: la matriz de decisión con cuatro casos reales
Hay cuatro combinaciones que aparecen una y otra vez en proyectos reales.
Caso 1: Chatbot sobre documentación interna
Necesitas que el modelo responda preguntas sobre tus PDFs, wikis, Notion, Confluence. La información cambia regularmente. El tono puede ser el del modelo base.
Solución: RAG. Indexas los documentos en una vectorDB (pgvector, Pinecone, Weaviate), configuras el pipeline de retrieval, y el modelo responde con fuentes reales.
Pero antes de montarlo: si son cuatro documentos que caben en el contexto y cambian una vez al trimestre, empieza por contexto y ahórrate el pipeline. RAG paga cuando el material no cabe o cambia a diario.
Caso 2: Generador de código en el estilo de tu empresa
Quieres que el modelo genere código que siga tus convenciones internas, use tus abstracciones propias, evite los patrones que prohíbes.
Solución clásica: fine-tuning. Pero prueba primero con un documento de convenciones en el contexto y tres o cuatro ejemplos antes/después. Los modelos actuales siguen instrucciones de formato mucho mejor que los de hace dos años.
Veredicto hoy: contexto primero. Fine-tuning solo si el prompt con convenciones y ejemplos falla de forma medible, no porque el resultado te parezca mejorable.
Caso 3: Asistente de soporte que responde sobre tus productos Y en tu tono
Quieres las dos cosas: información factual que cambia, y un comportamiento de comunicación muy específico.
Solución: RAG para la información, y el comportamiento en el prompt de sistema. Si tras iterar el prompt el formato sigue siendo inconsistente y tienes miles de ejemplos buenos, entonces fine-tuning para la parte de comportamiento. En ese orden, no al revés.
Caso 4: Clasificador de texto o extractor de entidades
Necesitas clasificar tickets, extraer entidades de contratos, tareas de NLP muy específicas.
Aquí es donde fine-tuning sigue defendiéndose mejor: para clasificación y extracción, un modelo pequeño ajustado a tu dominio suele salir más barato en inferencia que uno grande con prompts largos, y más consistente. Es el caso con mejor retorno de los cuatro.
Los costes reales
Contexto:
- Desarrollo: prácticamente nulo. Es construir un prompt.
- Inferencia: pagas los tokens de entrada en cada petición, así que el coste escala con el volumen, no con el tamaño del proyecto.
- Mantenimiento: cambiar el texto.
- Problema principal: el material repetido se paga una y otra vez — salvo que uses caché.
RAG:
- Configurar el pipeline de chunking, embedding y retrieval: días de desarrollo, no semanas.
- Inferencia: coste del modelo base más las llamadas a la vectorDB, que son baratas.
- Mantenimiento: actualizar la base vectorial cuando cambian los documentos, y es automatizable.
- Problema principal: la calidad del retrieval. Si buscas mal, el modelo responde mal aunque los documentos sean perfectos.
Fine-tuning:
- Construir el dataset de entrenamiento: semanas. Es el cuello de botella real, no la GPU.
- Entrenamiento: la estructura del coste es por tokens procesados o por horas de GPU según proveedor. Los precios concretos cambian cada pocos meses, así que consúltalos en el proveedor el día que decidas: cualquier cifra que leas en un post de hace medio año está mal.
- Inferencia: más cara que el mismo modelo sin ajustar. En un proveedor gestionado el modelo fine-tuneado tiene su propia tarifa por token, más alta que la del base, sin que tú hostees nada; con modelos abiertos lo pagas en infraestructura. Por los dos caminos, más que el punto de partida.
- Problema principal: te ancla a una versión. Cada modelo nuevo obliga a repetir el proceso entero mientras el resto del mundo avanza gratis.
Ese último punto es el que más se subestima. El coste del fine-tuning no es el entrenamiento: es quedarte fuera de la siguiente generación de modelos.
La caché de contexto: la palanca que casi nadie activa
Si tienes un sistema que atiende mil consultas al día y en cada una envía las mismas instrucciones, el mismo manual y los mismos ejemplos, estás pagando por procesar ese material mil veces.
La caché de contexto guarda el trabajo ya hecho sobre la parte que se repite y lo reutiliza. La parte repetida sale bastante más barata a partir de la segunda vez.
La condición es exigente y es donde falla todo el mundo: lo repetido tiene que ir siempre al principio y sin variar ni un carácter.
✅ CACHEABLE
[instrucciones fijas][manual fijo][ejemplos fijos][consulta variable]
❌ NO CACHEABLE
[fecha y hora][instrucciones fijas][manual fijo][consulta variable]
↑ un timestamp al principio invalida el bloque entero
Meter la fecha, un identificador de sesión o el nombre del usuario al comienzo del bloque fijo lo invalida todo. Y nadie te avisa: simplemente sigues pagando el precio completo.
Hay además un suelo del que casi no se habla: por debajo de unos cientos o unos miles de tokens —el umbral cambia por proveedor y por modelo— la caché no se activa. Tampoco salta un error. Se procesa a precio completo y a otra cosa.
Las condiciones exactas —qué se cachea, cuánto dura, cuánto descuenta— son distintas en cada proveedor y cambian cada pocos meses. Contrasta antes de contar con el ahorro.
Si tu factura de IA empieza a crecer, esta es la primera pregunta que hay que hacer en la reunión, antes de discutir de modelos: ¿estamos aprovechando la caché de contexto?
Qué pasa cuando las combinas
La combinación que se ve en sistemas de producción serios sigue un patrón concreto. Y es parte de una arquitectura más amplia — si quieres entender cómo el LLM encaja con el resto del sistema, el post sobre qué es un agent harness lo explica con detalle.
- Contexto para las instrucciones y el comportamiento, con la parte fija cacheada
- RAG para la información factual que cambia
- Fine-tuning solo si el comportamiento sigue siendo inconsistente después de agotar las dos anteriores
Un ejemplo real: un asistente jurídico. El prompt de sistema fija el formato del análisis y la terminología, y va cacheado porque no cambia. RAG conectado a la base de legislación actualizada y a los expedientes del despacho. Fine-tuning, en este caso, ni aparece: el modelo base ya redacta en registro jurídico si se le pide bien.
Esa es la arquitectura que más veo en productos de IA que funcionan. No es glamorosa. En el curso Construye con IA: de la idea al producto con Claude Code trabajo estas decisiones desde la fase de especificación — antes de escribir una línea de código — para que no llegues a la semana seis arrepintiéndote de la técnica que elegiste.
El árbol de decisión que uso en consultoría
Cuando alguien me pregunta qué usar, estas son las preguntas en orden:
1. ¿Cabe el material en el contexto y cambia poco?
- Sí → contexto, y cachea la parte fija. Ya está, no montes nada más.
- No cabe, o cambia a diario → siguiente pregunta.
2. ¿El problema es que el modelo no tiene la información, o que no se comporta como quieres?
- No tiene la información → RAG
- No se comporta bien → siguiente pregunta
3. ¿Has iterado el prompt de sistema en serio, con ejemplos few-shot?
- No → hazlo antes. Es gratis y resuelve más de lo que la gente espera.
- Sí, y sigue inconsistente → siguiente pregunta
4. ¿Tienes miles de ejemplos de calidad y un problema bien definido que no va a cambiar?
- No → sigue con prompting. Fine-tuning sin dataset bueno es dinero quemado.
- Sí → fine-tuning es defendible, siempre que el proveedor te deje.
La mayoría de los casos que veo en producción se resuelven en los dos primeros escalones. Fine-tuning es potente, pero exige un problema muy bien definido, datos de calidad y tiempo para construirlos.
Tabla comparativa detallada: RAG vs fine-tuning
| RAG | Fine-tuning | |
|---|---|---|
| Problema que resuelve | El modelo no tiene la información | El modelo no se comporta como quieres |
| Modifica el modelo | No | Sí |
| Cuándo usar | Datos dinámicos, documentos, bases de conocimiento | Estilo, formato, clasificación de dominio |
| Coste de inicio | Medio (pipeline) | Alto (dataset + entrenamiento) |
| Mantenimiento | Fácil (actualizar vectorDB) | Costoso (reentrenar cuando cambia el problema) |
| Tiempo hasta producción | Días | Semanas |
| Te ancla a un modelo | No | Sí |
| Combinar con el otro | Sí | Sí |
| Disponible en OpenAI (julio 2026) | Sí | Cerrado a usuarios nuevos; los activos, hasta el 6 de enero de 2027 |
Guarda esta tabla. Te va a ahorrar más de una conversación.
Y si te ha servido ordenar estas tres piezas, hay un mapa con las otras ciento diecinueve: conceptos de IA colocados por zonas, con las conexiones dibujadas, en una hoja para imprimir. Está aquí, gratis — funciona especialmente bien para pasársela a la gente de producto que aprueba estos presupuestos.
Preguntas frecuentes
¿Cuál es la diferencia entre RAG y fine-tuning?
RAG no toca el modelo: busca fragmentos relevantes en tus documentos y los inyecta en el prompt antes de generar, así que resuelve problemas de conocimiento y se actualiza cambiando un documento. Fine-tuning sí modifica el modelo, ajustando sus pesos con tus ejemplos, y resuelve problemas de comportamiento — tono, formato, criterio de clasificación. La confusión más cara del sector es usar fine-tuning para meter información: no acabas con un modelo que sepa tus datos, sino con uno que inventa datos con tu estilo.
¿Cuándo usar fine-tuning de verdad?
Cuando se cumplen las cuatro condiciones a la vez: el problema es de comportamiento y no de información, ya has iterado el prompt de sistema con ejemplos few-shot y sigue inconsistente, tienes miles de ejemplos de calidad, y la tarea está lo bastante definida como para que no cambie en unos meses. El caso con mejor retorno es la clasificación o extracción de dominio, donde un modelo pequeño ajustado sale más barato en inferencia que uno grande con prompts largos.
¿Es verdad que OpenAI está cerrando el fine-tuning?
Sí, la plataforma self-serve. Según su página de deprecations, desde el 7 de mayo de 2026 las organizaciones que no habían hecho fine-tuning antes ya no pueden crear jobs, y el 6 de enero de 2027 dejarán de poder hacerlo también los clientes activos. La inferencia sobre modelos ya ajustados sigue hasta que se deprecie el modelo base. OpenAI redirige en su lugar a su ciclo de evals y prompt engineering —contexto relevante, instrucciones claras, ejemplos few-shot— y a empezar por su modelo más reciente. El fine-tuning sigue disponible fuera de OpenAI, con modelos abiertos y otros proveedores.
¿Qué es la caché de contexto y cuánto ahorra?
Es guardar el trabajo de procesamiento ya hecho sobre la parte del prompt que se repite en todas las peticiones —instrucciones, manuales, ejemplos— para no volver a pagarla entera cada vez. El requisito es que ese bloque vaya al principio y sea idéntico carácter por carácter: meter un timestamp o un ID de sesión delante lo invalida y sigues pagando el precio completo sin que nadie te avise. Cuánto descuenta y cuánto dura la caché varía por proveedor y cambia cada pocos meses, así que conviene comprobarlo en la documentación antes de meter el ahorro en un presupuesto.
¿Qué sale más barato, RAG o fine-tuning?
RAG, casi siempre, y por dos motivos distintos: el arranque son días de pipeline frente a semanas de dataset, y no te ancla a una versión del modelo, así que no repites el gasto con cada generación nueva. Fine-tuning solo gana en coste cuando la tarea es de clasificación o extracción y puedes servir un modelo pequeño en lugar de uno grande con prompts largos. Antes de comparar las dos, mira si tu prompt fijo es cacheable: en sistemas con mucho volumen esa palanca sola suele mover más la factura que la elección de técnica.
¿Cuánto cuesta hacer fine-tuning?
Tiene tres partidas y solo una no caduca. El dataset son semanas de trabajo humano y es el cuello de botella real. El entrenamiento se factura por tokens procesados o por horas de GPU según el proveedor. La inferencia va a una tarifa más alta que la del modelo base. Cualquier cifra concreta que leas en un post de hace medio año está mal, así que consulta el pricing del proveedor el día que decidas — pero cuenta con que la partida del dataset no la abarata nadie.
¿Cambia algo con los modelos de razonamiento?
Bastante, y en la dirección de necesitar menos fine-tuning. Siguen instrucciones complejas mucho mejor que las generaciones anteriores, así que se comen buena parte de los casos de comportamiento que antes justificaban entrenar un modelo. Lo que no cambia es el acceso a la información: un modelo de razonamiento no conoce tus documentos privados ni lo que pasó esta semana. Para eso RAG sigue siendo la única vía.
¿Puedo usar RAG con cualquier LLM?
Sí. RAG es agnóstico al modelo: funciona con cualquiera que acepte un prompt de texto, sea de OpenAI, Anthropic, Google o un modelo abierto que corras tú. Lo único que necesita es una ventana de contexto suficiente para recibir los fragmentos recuperados junto con la pregunta, y los modelos actuales van sobrados para eso en la mayoría de casos.
¿La ventana de contexto es lo mismo que memoria?
No, y se confunden constantemente. La ventana de contexto es cuánto cabe en una sola petición. Memoria es que algo sobreviva a cerrar la sesión, y eso no está dentro del modelo: es un almacén externo que alguien montó, más una decisión sobre qué merece la pena guardar y recuperar. Una ventana enorme no te da memoria, y por eso un asistente puede seguirte el hilo durante media hora y no conocerte de nada al día siguiente.
¿RAG siempre alucina menos que el modelo base?
Reduce las alucinaciones sobre hechos concretos de tus documentos, porque el modelo tiene el texto real delante. Pero no elimina las que vienen de razonamientos o inferencias mal hechas: si el modelo falla razonando, RAG no le ayuda, porque eso es un problema de capacidad y no de conocimiento. Recuperar bien y responder bien son dos cosas distintas.
¿Qué vectorDB conviene para empezar?
pgvector si ya usas PostgreSQL, porque no añade infraestructura nueva, o un servicio gestionado como Pinecone si prefieres no operar nada. Weaviate y Chroma son buenas opciones open-source para auto-hosting. Evita sobreingenierizar esto al principio: pgvector resuelve la mayoría de los casos sin complejidad extra, y su documentación oficial cubre la instalación en unos minutos.
Si quieres ver estos patrones aplicados en proyectos reales con código y arquitectura completa, en Dominicode Labs trabajamos este tipo de decisiones técnicas con la comunidad. Proyectos reales, problemas reales, decisiones que puedes aplicar esta semana.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.