Explicador en lenguaje claro
RAG o fine-tuning: cómo elegir de verdad
RAG (generación aumentada por recuperación) le da a un modelo congelado los documentos correctos para leer al momento de responder; el fine-tuning cambia los pesos del modelo con nuevos ejemplos de entrenamiento. Usa RAG para hechos que cambian, datos privados y citas. Usa fine-tuning para comportamiento: tono, formato y habilidades estrechas. Muchos sistemas en producción usan ambos.
¿Uso RAG o fine-tuning?
Pregúntate qué te falta. Si al modelo le faltan datos, usa retrieval: deja los documentos fuera del modelo y trae los relevantes al prompt, así corregir un dato es una edición y las respuestas pueden citar su fuente. Si el modelo tiene los datos pero falla en el formato, el tono o la tarea, haz fine-tuning: compra consistencia y prompts más cortos. El conocimiento es retrieval, el comportamiento es fine-tuning. Casi todos necesitan retrieval, y quienes empiezan por fine-tuning suelen terminar haciendo las dos cosas.
Revisado por última vez el
| RAG | Fine-tuning | |
|---|---|---|
| Qué cambia | Lo que el modelo lee al responder | Los pesos del modelo |
| Mejor para | Hechos que cambian, documentos privados, citas | Tono, formato, una habilidad estrecha |
| Costo de actualizar | Agregar o borrar un documento; sin corrida de entrenamiento | Una nueva corrida de entrenamiento y una nueva evaluación |
| Modo de fallo | Se recupera un fragmento equivocado o viejo y la respuesta sale mal con confianza | Pierde habilidad general; difícil auditar qué aprendió |
| Necesita | Un índice, un modelo de embeddings, un eval de recuperación | Ejemplos etiquetados, tiempo de GPU, un set de evaluación |
No te quedes en leerlo. Opera tú mismo el mecanismo en una lección interactiva corta.
Míralo funcionar: RAG: la recuperación como retorno a la similitud →Gratis, sin código, sin registro.
Diez segundos, sin lección: juega con el widget independiente, e insértalo en tu propia página.
¿Cómo funciona cada uno por dentro?
RAG significa generación aumentada por recuperación, y es menos exótico de lo que suena. Partes tus documentos en fragmentos, pasas cada fragmento por un modelo de embeddings y guardas los vectores resultantes en un índice. Cuando llega una pregunta, también la conviertes en embedding, buscas los fragmentos guardados cuyos vectores quedan más cerca y pegas los mejores en el prompt, encima de la pregunta. El modelo responde leyéndolos, igual que si hubieras pegado el texto a mano. Sus pesos nunca cambian. El conocimiento vive fuera del modelo, en documentos que puedes editar, versionar y borrar.
El fine-tuning es más entrenamiento. Juntas cientos o miles de pares de ejemplo, cada uno una entrada más la salida que te habría gustado, y corres un trabajo de entrenamiento que empuja los pesos del modelo hacia esos ejemplos. La receta más común, LoRA, congela los pesos originales y entrena un adaptador pequeño encima, y por eso cabe en una sola GPU alquilada. Lo que cambia es el modelo mismo: cómo redacta, qué formato usa por defecto, qué rechaza. Nada extra se adjunta al momento de preguntar.
Dónde vive el cambio explica casi todas las decisiones prácticas de esta página. El retrieval agrega conocimiento por petición y puede señalar su fuente. El fine-tuning hornea el comportamiento adentro, invisible y siempre activo. La lección interactiva de este sitio te deja girar la manivela del retrieval: convierte una pregunta en embedding, mira aparecer los fragmentos más cercanos y observa cómo cambia la respuesta cuando cambia el contexto pegado.
¿Cuál conviene para cuál problema?
La forma más rápida de elegir es nombrar el fallo que estás viendo. Si el modelo no sabe algo, eso es un hueco de conocimiento, y los huecos de conocimiento son trabajo del retrieval. Si el modelo sabe suficiente pero responde con la forma, el tono o el formato equivocados, eso es un hueco de comportamiento, y el comportamiento es lo que cambia el fine-tuning. Los equipos que se saltan este diagnóstico suelen hacer fine-tuning contra un hueco de conocimiento, que es la forma cara de aprender que los datos no se fijan bien en los pesos.
Un default honesto va primero: antes de cualquiera de los dos, prueba un prompt mejor con dos o tres ejemplos resueltos. El prompting es la palanca más barata y sale en minutos, y es la línea base que igual necesitas para demostrar que RAG o el fine-tuning mejoraron algo.
| Tu objetivo | Usa | Por qué |
|---|---|---|
| Responder preguntas desde tus propios documentos | RAG | Los datos siguen editables y la respuesta puede citar el fragmento que usó |
| Información que cambia cada semana | RAG | Editar un documento actualiza la siguiente respuesta, sin entrenar |
| Citas o trazabilidad | RAG | El retrieval puede mostrar su fuente, los pesos no |
| Un tono propio que se sostenga siempre | Fine-tuning | El estilo vive en los pesos, y los ejemplos lo enseñan mejor que las instrucciones |
| Formato de salida estricto a mucho volumen | Fine-tuning | Un modelo chico ajustado sostiene el formato con un prompt corto |
| Los dos problemas a la vez | Ambos | Ajusta el comportamiento, recupera los datos |
¿Cuánto cuesta cada uno?
La factura de RAG es sobre todo por petición. El arranque es barato: los modelos de embeddings cuestan centavos por millón de tokens a mediados de 2026, así que indexar hasta un conjunto grande de documentos suele salir unos pocos dólares, y el índice de vectores va desde gratis, con pgvector dentro de un Postgres que ya tienes, hasta unos cientos de dólares al mes en un servicio administrado a escala. La parte que crece es la recurrente. Cada petición ahora carga un par de miles de tokens recuperados, así que cada llamada cuesta un poco más y espera un paso de retrieval, para siempre.
El fine-tuning invierte la forma. Pagas al principio y luego cada petición sale más barata, porque el comportamiento ya no necesita un prompt largo. Se reporta que un fine-tune con LoRA de un modelo abierto chico cuesta unos pocos dólares de GPU alquilada por corrida, los servicios alojados cobran el entrenamiento de modelos chicos a bastante menos de US$1 por millón de tokens de entrenamiento a mediados de 2026, y un fine-tune completo de un modelo grande sigue costando miles. El mayor costo inicial rara vez es la GPU. Es escribir cientos de ejemplos limpios, más el set de evals que te dice si la corrida sirvió.
La regla práctica de los análisis de costos de 2026: el fine-tuning empieza a pagarse cuando una tarea estrecha y estable corre a mucho volumen, el caso donde un modelo chico ajustado reemplaza a uno general caro en millones de peticiones. Por debajo de eso, el retrieval gana en costo total casi por defecto.
| Qué pagas | Costo aproximado | Cada cuánto |
|---|---|---|
| Embeddings de 1M de tokens de documentos | US$0.02 a US$0.13 | una vez por versión del documento |
| Alojar el índice de vectores | gratis (pgvector) a cientos al mes | mensual |
| Unos 2.000 tokens recuperados por petición | fracciones de centavo a precios de gama media | cada petición |
| Fine-tune con LoRA de un modelo abierto de 7B | unos pocos dólares de GPU, reportado | por corrida |
| Fine-tuning alojado de un modelo chico | menos de US$1 por millón de tokens de entrenamiento | por corrida |
| Fine-tune completo de un modelo grande | miles de dólares | por corrida |
¿Cuándo se usan los dos?
En producción la pregunta deja de ser una disyuntiva bastante rápido. El patrón maduro estándar es una división del trabajo. Haz fine-tuning de un modelo para el comportamiento: el formato, el vocabulario del dominio, las reglas de rechazo. Luego ponlo detrás de un pipeline de retrieval que aporte los datos al momento de la petición. Los análisis de práctica de 2025 y 2026 describen esta combinación como el default de los despliegues serios, muchas veces con un modelo abierto chico cargando el comportamiento ajustado mientras el retrieval carga el conocimiento.
La investigación apunta en la misma dirección. Un equipo de Microsoft comparó los dos de frente para inyectar conocimiento nuevo y encontró que el retrieval era consistentemente mejor para lograr que un modelo respondiera sobre datos con los que nunca entrenó. Del otro lado, una técnica de Berkeley llamada RAFT, retrieval augmented fine-tuning, ajusta el modelo justamente para ser bueno en RAG: entrena con preguntas emparejadas con documentos recuperados, algunos irrelevantes a propósito, para que el modelo aprenda a citar el fragmento correcto e ignorar los distractores.
Si corres los dos, mantén los trabajos separados en tu cabeza y en tus evals. Una regresión de comportamiento apunta a los pesos ajustados. Un dato equivocado apunta al paso de retrieval. Un sistema donde no puedes saber cuál falló es un sistema que no puedes arreglar.
¿Cómo falla cada uno?
RAG falla en el paso de retrieval, en silencio. Si la búsqueda devuelve los fragmentos equivocados, el modelo responde con fluidez desde un contexto malo, y el fallo se ve exactamente igual que un acierto. El contexto largo suma sus propios problemas: los modelos atienden peor el texto enterrado en medio de un prompt grande, y razonar a través de muchos documentos recuperados sigue siendo débil. La mayoría de los bugs reales de RAG vienen de causas poco glamorosas. Fragmentos mal cortados. Un índice viejo que nadie volvió a indexar. Una pregunta redactada distinto de todos los documentos que la responden.
El fine-tuning falla dentro de los pesos, donde no puedes mirar. El fallo clásico es el olvido catastrófico: entrena fuerte en una tarea estrecha y el modelo empeora de forma medible en el seguimiento de instrucciones y el razonamiento general que antes manejaba. El segundo es quedar desactualizado. Lo que entrenaste queda congelado al momento del entrenamiento, y cambiarlo significa armar datos y correr el trabajo otra vez. Los datos metidos por entrenamiento son el peor caso: poco fiables de recordar, imposibles de citar y caros de quitar.
La defensa es la misma para ambos: un set de evals escrito que corres antes y después de cada cambio. Un bug de retrieval y una regresión por olvido son invisibles en una demo y obvios en un benchmark de cien preguntas tuyas reales.
¿Cuáles son las malas razones para hacer fine-tuning?
El fine-tuning es la opción glamorosa, y por eso atrae a los proyectos equivocados. Estas son las razones que más aparecen y menos se sostienen.
- Enseñarle nuestros documentos al modelo. El fine-tuning enseña sobre todo forma, y los datos que sí se fijan quedan poco fiables, imposibles de citar y congelados. Un modelo que debe responder desde tus documentos debería leerlos al momento de la petición.
- El prompt se nos está haciendo largo. Un prompt largo y estable es para lo que existe el prompt caching. Los proveedores descuentan mucho el prefijo repetido, y eso elimina casi todo el argumento de costo para hornear instrucciones en los pesos.
- Hacer el modelo más inteligente. El fine-tuning especializa, no agrega capacidad. Ajustado a tu tarea, un modelo mejora en tu tarea y suele empeorar un poco en todo lo demás.
- No probamos el prompting en serio. Una página de instrucciones claras con tres ejemplos resueltos es la línea base. Una parte sorprendente de los proyectos de fine-tuning resultan ser un prompt que nadie escribió.
- Tenemos datos de entrenamiento pero no evals. Sin un set de evals no puedes ver el olvido, las regresiones ni si la corrida sirvió. Mide primero, entrena después.
Lo que la gente entiende mal
- El fine-tuning le enseña tus documentos al modelo. Sobre todo le enseña un estilo. Los datos metidos así son difíciles de actualizar e imposibles de citar.
- RAG es la opción barata y el fine-tuning la seria. El retrieval es lo que corre en producción; el fine-tuning es una especialización encima.
- Es uno o el otro. Ajusta el comportamiento con fine-tuning y trae los datos con retrieval. Resuelven problemas distintos y se combinan.
- Un chatbot sobre tus propios datos necesita fine-tuning. Un chatbot sobre documentos es el caso de libro de RAG. El fine-tuning solo entra si el tono o el formato de salida no se sostienen.
Dónde lo ves en productos reales
- Asistentes de soporte que responden desde un centro de ayuda y enlazan el artículo que usaron.
- Asistentes de empresa ajustados a un estilo propio, que igual traen el documento vivo.
- Clasificadores estrechos ajustados para un formato de salida fijo a mucho volumen.
- Asistentes de código que traen tu repositorio al contexto en vez de entrenar con él.
Preguntas frecuentes
- ¿Cuál sale más barato?
- El retrieval cuesta más por petición, porque mandas los documentos recuperados en cada llamada. El fine-tuning cuesta más al principio y luego abarata cada petición al acortar el prompt. Con poco volumen gana el retrieval con claridad; con muchísimo volumen en una tarea estrecha, un modelo chico ajustado puede salir más barato.
- ¿Cómo mantengo las respuestas al día con cada uno?
- Con retrieval actualizas el documento y la siguiente respuesta ya está al día. Con fine-tuning, poner información nueva significa otra corrida de entrenamiento, y por eso nadie lo usa para algo que cambia cada semana.
- ¿Qué conviene probar antes que cualquiera de los dos?
- Un prompt mejor con dos o tres ejemplos, y comprobar que el modelo falla de verdad en lo que crees. Buena parte de los problemas que se achacan a falta de conocimiento resultan ser una instrucción vaga o un paso de retrieval que devolvió el pasaje equivocado.
- ¿Uso RAG o fine-tuning para un chatbot sobre mis propios datos?
- Empieza con RAG. Un chatbot que responde desde tus documentos es el caso de libro del retrieval: los datos siguen editables, las respuestas pueden citar su fuente y no necesitas datos de entrenamiento para lanzar. Suma fine-tuning después, y solo si el tono o el formato de salida del bot no se sostienen con prompting.
- ¿El fine-tuning le agrega conocimiento nuevo a un modelo?
- Poco y de forma poco fiable. Los estudios que compararon los dos de frente, incluido un experimento muy citado de Microsoft, encontraron el retrieval consistentemente mejor para que un modelo responda sobre datos con los que no entrenó. El fine-tuning brilla en comportamiento: formato, tono y forma de la tarea. El conocimiento que debe estar correcto va en documentos que el sistema pueda traer y citar.
- ¿Qué es RAFT, o retrieval augmented fine-tuning?
- Una técnica de investigadores de Berkeley que ajusta un modelo para ser mejor en RAG. Los datos de entrenamiento emparejan cada pregunta con documentos recuperados, algunos irrelevantes a propósito, para que el modelo aprenda a responder desde el fragmento correcto e ignorar los distractores. Es el ejemplo más claro de que los dos enfoques se combinan en vez de competir.
- ¿Cuántos datos de entrenamiento necesito para hacer fine-tuning?
- Menos de lo que casi todos esperan para estilo y formato. Los proveedores han reportado mejoras visibles desde cincuenta a cien ejemplos buenos, y unos cientos a unos miles es un rango común para una tarea estrecha. La calidad domina a la cantidad: un set chico de ejemplos limpios y consistentes le gana a uno grande y descuidado.
Explicadores relacionados
Más en Construir encima, y confiar en ello
Una idea a la vez, en tu correo
Lecciones y explicadores nuevos, escritos como están escritas estas páginas. De vez en cuando, no a diario, y nunca una secuencia de venta.
Primero te enviamos un enlace de confirmación. Puedes darte de baja con un clic, cuando quieras. Privacidad.
Parte de See How AI Works, un curso interactivo gratuito, donde aprendes cómo funciona la IA moderna operándola, no viendo videos.