¿Qué es RAG, en una frase?
El nombre viene de una investigación de 2020. Los autores lo definieron así: un modelo que enlaza el conocimiento entrenado (el «paramétrico») y una memoria externa consultable para producir la respuesta.
En la práctica son tres pasos, en cada pregunta:
1. Tu pregunta se convierte en una búsqueda
El sistema localiza qué fragmentos de documento
son relevantes. (Esto es el "retrieval".)
2. Los resultados entran en el prompt
No el documento entero - unos pocos fragmentos
seleccionados, junto a la pregunta.
3. El modelo responde a partir de ahí
ADEMÁS de su propio conocimiento, tiene delante
tu texto. (Esto es la "augmented generation".)
La clave es el instante posterior al tercer paso: el modelo olvida. Sus pesos no han cambiado. En la siguiente pregunta hay que buscar otra vez, y los fragmentos vuelven a entrar. Esa diferencia la desarrolla el artículo sobre fine-tuning, RAG y prompting con detalle, y la matemática de la búsqueda la explica el texto sobre embeddings y búsqueda vectorial desde cero.
Una precisión conceptual que despista a mucha gente: el RAG original de 2020 era una receta de entrenamiento — el buscador y el generador de texto se ajustaban juntos. Lo que hoy se llama RAG normalmente no incluye entrenamiento alguno: un modelo de embedding ya hecho, un modelo de lenguaje ya hecho y una capa de búsqueda entre los dos.
Lo que RAG no resuelve
Esta es la columna vertebral del artículo, porque aquí es donde fracasan la mayoría de los proyectos.
| ¿Qué cambia? | ¿Cuándo hace falta? | ¿Cuál es su precio? | |
|---|---|---|---|
| RAG | nada en el modelo; mete texto recuperado en el prompt | cuando tiene que saber un dato que cambia, o que solo tienes tú | una capa de búsqueda y tokens de entrada extra en cada pregunta |
| Fine-tuning | los pesos del modelo | cuando tiene que aprender comportamiento, formato, tono | un entrenamiento, y otro entrenamiento por cada dato nuevo |
| Context window largo | nada; metes el material entero | cuando todo el material cabe y no cambia a diario | el precio en tokens de todo el material en cada pregunta |
El error más frecuente es que alguien quiere la segunda columna y construye la primera — o al revés. Cuándo compensa aun así la columna del medio lo mide el post sobre la rentabilidad del fine-tuning con números.
Y hay medición. Un estudio de 2023 probó en tres modelos de siete mil millones de parámetros qué ocurre cuando hay que aprender conocimiento completamente nuevo. La tarea eran 910 preguntas sobre hechos que ninguno de los modelos pudo ver durante el entrenamiento:
| Modelo | Estado base | + fine-tuning | + RAG |
|---|---|---|---|
| Modelo A | 48,1 % | 50,4 % | 87,5 % |
| Modelo B | 35,3 % | 21,9 % | 58,5 % |
| Modelo C | 45,6 % | 51,1 % | 87,6 % |
De ahí se leen dos cosas. Una: RAG ayuda un orden de magnitud más — 39,4 puntos porcentuales en el primer modelo, frente a los 2,3 del fine-tuning. La otra es la segunda fila: ahí el fine-tuning empeoró el resultado en 13,4 puntos. No «ayudó menos» — hizo daño.
Hay un tercer detalle, todavía más incómodo, de esa misma medición: en otra tarea el modelo con fine-tuning y RAG (65,9 %) quedó por debajo del modelo base con RAG (68,1 %). El resumen de los autores: usar el modelo base como generador fue sistemáticamente mejor que limitarse al fine-tuning.
(Preprint, tres modelos de siete mil millones de parámetros — las cifras exactas no se trasladan a los grandes modelos de hoy. La dirección sí.)
¿Cuánto mejora la alucinación?
No hay una única cifra para esto, y quien te dé una probablemente no la ha medido. Lo que sí hay: mediciones específicas por tarea, con definiciones que no se pueden comparar entre sí. Eso ya es información útil.
La mejor de ellas es un estudio revisado por pares que probó 202 preguntas cuidadosamente construidas contra tres herramientas profesionales de investigación jurídica — es decir, no un montaje casero, sino productos RAG caros y hechos a medida.
Primero la definición, porque esa es la parte aprovechable. Según el estudio, una respuesta era alucinada si o bien contenía un error de hecho, o bien estaba mal fundamentada — es decir, cita una fuente que existe pero que no respalda lo que afirma.
Ese segundo caso es el que RAG parece resolver (¡hay cita!) y en realidad no resuelve.
| Herramienta | Respuesta correcta | Alucinada | Incompleta |
|---|---|---|---|
| A | 65 % | 17 % | 18 % |
| B | 41 % | 33 % | 25 % |
| C | 19 % | 17 % | 62 % |
(Los tres valores son las categorías propias del estudio; por el redondeo, las filas no suman exactamente cien en todos los casos.)
La conclusión de los autores: aunque RAG mejora visiblemente, el problema de la alucinación se mantiene en un nivel significativo.
Y un giro que casi todos los resúmenes estropean: junto al 17 % de alucinación de la herramienta C hay que escribir su 62 % de respuestas incompletas — a casi dos tercios de las preguntas no dio respuesta de fondo. Sin la tasa de incompletas las tres cifras no se pueden comparar. Por qué un modelo se inventa cosas lo recorre el texto sobre las causas de la alucinación paso a paso.
La prueba en contra: RAG no te hace más seguro
Mucha gente se salta esta parte, y sin embargo es el hallazgo más sorprendente del tema.
Un estudio de 2025 revisado por pares probó 11 modelos con 5.592 preguntas dañinas, en 16 categorías de riesgo. La pregunta era: ¿un modelo se vuelve más seguro por trabajar solo con los documentos recuperados?
| Medición | Valor |
|---|---|
| Respuestas no seguras de un modelo de ocho mil millones de parámetros sin RAG | 0,3 % |
| El mismo modelo con RAG | 9,2 % |
| Documentos recuperados que ya contenían material dañino | 5,3 % |
| Proporción de salidas no seguras que venían de documentos SEGUROS | 81,8 % |
Un empeoramiento de treinta veces — y cuatro quintas partes de ese empeoramiento no vienen de que el sistema encontrara un documento malo.
La explicación de los autores: el fine-tuning de seguridad enseña al modelo a no procesar ciertas direcciones. En cambio, cuando recibe contexto relevante, deja de percibir el tema como arriesgado y lo procesa.
Dos hallazgos más de la misma fuente: los modelos añaden también su propio conocimiento interno a los documentos recuperados, incluso cuando la instrucción lo prohíbe; y un contexto más largo aumenta la vulnerabilidad. Más una consecuencia operativa: las pruebas de seguridad que funcionaban en un entorno sin RAG dejaron de funcionar al trasladarlas — o sea, tus pruebas actuales no miden tu sistema RAG.
Siete puntos donde se rompe
Un informe de experiencia de 2024 — a partir de tres implantaciones reales, entre ellas un sistema médico de 4.017 documentos y 1.000 preguntas — estableció una taxonomía de fallos. Merece la pena aprendérsela, porque todos los fallos de RAG encajan ahí:
| # | Punto de fallo | Qué ocurre |
|---|---|---|
| 1 | Contenido ausente | La respuesta no está en los documentos y el sistema genera igual |
| 2 | No entró entre los resultados | Está dentro, pero no llega a los primeros puestos |
| 3 | Se cayó del contexto | Entró en los resultados, pero el ensamblado lo descartó |
| 4 | No lo extrajo | Lo tiene delante y el modelo no lo usa — ruido o contradicción |
| 5 | Formato equivocado | Ignora la instrucción de formato |
| 6 | Nivel de detalle equivocado | Respuesta demasiado general o demasiado concreta |
| 7 | Incompleta | Deja fuera algo que sí estaba en el contexto |
El primer punto de fallo es el que importa, porque es el único que ninguna técnica arregla. Si tus documentos no contienen la respuesta, no hay chunking, búsqueda ni modelo que la saque.
Y la frase más importante del informe, la que debería conocer todo el que compra:
«La validación de un sistema RAG solo es viable durante la operación.»
Es decir: no puedes saber durante el desarrollo si va a funcionar bien. No porque el desarrollador sea malo, sino porque el comportamiento del sistema depende de las preguntas reales y de los documentos reales. RAG no es un proyecto, es una operación. Cómo medirlo lo detalla el artículo sobre la evaluación de un sistema RAG punto por punto.
¿Cuándo NO construir un RAG?
Cinco casos, todos con fuente primaria o medición detrás:
1. Si todo el material cabe en el context window. Este es el umbral de fabricante más concreto que existe, y es insólitamente honesto, porque juega en contra de su propia solución más complicada:
«Si tu base de conocimiento es menor de 200.000 tokens (unas 500 páginas de material), puedes meterla entera en el prompt, sin RAG.»
(Las 500 páginas se refieren a texto en inglés. En húngaro la proporción de tokens es peor, así que el umbral queda bastante por debajo de esa cifra — el texto sobre tokens y context window te da una referencia.)
2. Si las preguntas no son de datos. Estilo, formato, tono: eso es fine-tuning, no RAG.
3. Si nadie va a mantenerla. Ya lo has visto: la validación solo es posible durante la operación — y una base de conocimiento caducada es peor de forma medible que una vacía, como muestra el post sobre mantener la base de conocimiento actualizada con datos.
4. Si tus documentos no contienen la respuesta. El primer punto de fallo no tiene arreglo.
5. Si lo planteas como medida de seguridad. Según la medición, sale al revés.
A esto se suma una cifra útil sobre cuánto mejor es RAG que el simple context window largo. Un estudio de 2024 comparó los dos en nueve conjuntos de datos y encontró que en el 63 % de las preguntas las dos soluciones dieron exactamente la misma respuesta, y en el 70 % la diferencia de puntuación se quedó por debajo de diez.
(Medido con modelos de mediados de 2024. La idea del 63 % de coincidencia se traslada, los porcentajes exactos no.)
El coste, donde no lo esperas
[Cálculo propio] Tomemos una base de conocimiento de diez mil documentos, con cinco páginas cada uno — unos 25 millones de tokens, cortados en chunks de 512 tokens, con un 25 % de overlap, 65 mil chunks.
El tamaño de los vectores en bruto:
65.000 chunks × 1.536 dimensiones × 4 bytes = 0,40 GB
El índice de búsqueda, al lado, es insignificante: unos 10 MB para ese mismo tamaño. Con los metadatos y el texto en bruto, de forma realista estamos en torno a 1 GB.
Un gigabyte. Nada más. La tarifa mensual de almacenamiento en los proveedores se mide en décimas de dólar.
Y aquí está lo importante: el mínimo mensual de los planes de entrada va de 16 a 250 dólares. O sea, tu consumo quedará órdenes de magnitud por debajo del mínimo. Tu coste real no es el consumo, sino la cuota mínima — y eso falta en casi todos los cálculos.
El coste único del embedding es igual de sorprendente: generar el embedding de esos 25 millones de tokens cuesta menos de un dólar.
El dinero está en responder. Esas mismas diez mil preguntas al mes cuestan, según el modelo que elijas, entre 26 y 635 dólares. Veinticuatro veces de diferencia, por el mismo trabajo.
De aquí salen tres conclusiones:
- El almacenamiento y el embedding son prácticamente gratis. Quien ahorre ahí busca en el sitio equivocado.
- La elección del modelo es la partida de coste real. Ahí está el multiplicador de veinticuatro.
- Las cuotas mínimas encarecen desproporcionadamente una base pequeña. Un sistema de mil documentos cuesta al mes casi lo mismo que uno de diez mil.
La guía práctica
1. PREGUNTA PRIMERO: ¿DATO O COMPORTAMIENTO?
Dato -> RAG. Estilo, formato, tono ->
fine-tuning. Esa es la decisión, no la técnica.
2. MIDE CUÁNTO OCUPA EL MATERIAL
Por debajo de 200 mil tokens, pégalo entero.
RAG solo por encima.
3. EMPIEZA CON VEINTE PREGUNTAS REALES
Escribe qué van a preguntar Y cuál es la buena
respuesta. Sin eso no tienes con qué medir.
4. COMPRUEBA SI LA RESPUESTA ESTÁ SIQUIERA AHÍ
El fallo más común es que no. Esto se revisa
a mano, no con software.
5. MIDE PRIMERO LA BÚSQUEDA, NO LA RESPUESTA
Si el fragmento bueno no entra en los
resultados, el modelo no puede hacer nada.
6. PLANIFICA UNA OPERACIÓN, NO UN PROYECTO
La validación solo es posible en operación.
Que tenga responsable y revisión mensual.
7. RESUELVE LOS PERMISOS EL PRIMER DÍA
Quién ve qué. Añadirlo después sale mucho más
caro, y en algunos sistemas no se puede.
8. PRESUPUESTA EL MÍNIMO MENSUAL, NO EL CONSUMO
El almacenamiento es calderilla. El mínimo no.
El séptimo punto es el que casi todos descubren tarde. Si el chatbot devuelve también lo que quien pregunta no debería ver, eso no es un fallo, es una brecha de datos — y en varios sistemas la gestión de permisos no se puede activar después.
Malentendidos habituales
- «RAG le enseña mis documentos al modelo.» No. Los pesos del modelo no cambian. El documento le llega en el momento de la pregunta, dentro del prompt, y después de la respuesta ya no está ahí.
- «Si hay una cita, es verdad.» Según la definición de la medición citada, la mitad de la alucinación es justamente citar una fuente real que no respalda la afirmación.
- «Con RAG el sistema será más seguro.» En una medición con 11 modelos la proporción de respuestas no seguras se multiplicó por treinta, y cuatro quintas partes del daño venían de documentos seguros.
- «Se puede probar por adelantado.» Según el informe de experiencia, la validación solo es viable durante la operación.
- «Con una base pequeña sale más barato.» El almacenamiento sí, pero por las cuotas mínimas un sistema de mil documentos cuesta casi lo mismo que uno de diez mil.
- «Basta con un modelo mejor.» Tres de los siete puntos de fallo nacen en la búsqueda y en el chunking — ahí el modelo no ve nada.
Qué llevarte
RAG es la forma más eficaz de que un modelo responda a partir de tus datos: según la medición, con conocimiento nuevo aporta un orden de magnitud más que el fine-tuning, que incluso a veces empeora las cosas.
Pero conviene ver tres cosas con realismo. No es enseñar — el modelo no se vuelve más listo, solo mejor informado, pregunta a pregunta. No lo resuelve todo — la alucinación se quedó entre el 17 % y el 33 % incluso en productos profesionales, y la seguridad empeora de forma medible. Y no es un proyecto, sino una operación — solo se valida mientras funciona.
Por eso el mejor primer paso no es tecnológico: escribe veinte preguntas reales y comprueba a mano si tus documentos contienen la respuesta. Si no la contienen, RAG no va a ayudarte — y eso lo averiguas en una mañana, no en tres meses.
La preparación de los documentos la cubre la guía sobre chunking entera, y el almacenamiento, la introducción a vector database sin jerga.