RAG —Retrieval-Augmented Generation, recuperación aumentada de generación— es un patrón que combina, en palabras del trabajo original de Lewis y otros en NeurIPS 2020, «memoria paramétrica y no paramétrica preentrenadas para generación de lenguaje»: lo que el modelo aprendió en su entrenamiento más un índice externo que se consulta en el momento. Un sistema RAG tiene dos mitades: una que indexa —trocear los documentos, calcular embeddings y guardarlos— y otra que responde —buscar los fragmentos pertinentes y pasárselos al modelo con la pregunta—. La calidad final depende mucho más de la recuperación que del modelo: si el fragmento correcto no llega al contexto, ningún modelo lo adivina.
Ver índice de contenidos
Qué es RAG y de dónde viene
El término viene de un trabajo académico concreto: «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks», de Patrick Lewis y otros, presentado en NeurIPS 2020. Su aporte conceptual es la distinción entre dos tipos de memoria, y entenderla ahorra mucha confusión:
- Memoria paramétrica: lo que el modelo aprendió durante el entrenamiento y quedó codificado en sus parámetros. Es rápida, está siempre disponible y no se puede consultar ni corregir de forma directa.
- Memoria no paramétrica: un índice externo que se consulta en el momento. En el trabajo original era «un índice vectorial denso de Wikipedia, accedido con un recuperador neuronal preentrenado». Se puede actualizar, auditar y citar.
Trasladado a lo que hoy se construye: en lugar de esperar que el modelo sepa el contenido de tu manual interno, se busca el fragmento pertinente y se le entrega con la pregunta. El modelo deja de ser la fuente del conocimiento y pasa a ser el que redacta a partir de un material que le diste.
Por qué eso cambia el problema
Tres consecuencias prácticas de mover el conocimiento fuera del modelo. Se actualiza sin reentrenar: cambió el documento, se reindexa y listo. Se puede citar: la respuesta puede señalar de qué fragmento salió, y eso es verificable. Y se puede controlar el acceso: si una persona no tiene permiso sobre un documento, ese documento no entra en su búsqueda.
Cuándo conviene y cuándo no
RAG se volvió la respuesta por defecto a cualquier problema con modelos de lenguaje, y no lo es. La pregunta que ordena la decisión es qué es lo que falta:
| Lo que falta | Qué conviene | Por qué |
|---|---|---|
| Conocimiento que el modelo no vio, o que cambia seguido | RAG | Actualizar es reindexar un documento, no reentrenar un modelo |
| Necesidad de citar la fuente de cada afirmación | RAG | Es la única de las tres opciones que deja rastro verificable |
| Un formato de salida muy específico o un estilo propio | Ajuste fino | Es comportamiento, no conocimiento: no se arregla trayendo texto |
| Una tarea repetitiva con estructura fija y muchos ejemplos | Ajuste fino | Sale más barato y más rápido en el momento de responder |
| El modelo divaga o no entendió el pedido | Mejor prompt | La mitad de los proyectos de RAG empiezan resolviendo esto |
| Los documentos son pocos y chicos | Pasarlos enteros | Si todo entra en el contexto, el índice agrega complejidad sin aportar |
El último caso merece énfasis porque se pasa por alto: con ventanas de contexto grandes, una decena de documentos cortos puede entrar completa en el pedido. Ahí RAG no aporta nada y suma cuatro componentes que pueden fallar. Conviene medir antes de construir.
Las dos mitades
Todo sistema RAG, por sofisticado que sea, tiene estas dos mitades. La primera, indexar, corre una vez por documento y cada vez que ese documento cambia:
- Leer y extraer el textoDe PDF, HTML, planillas o lo que haya. Esta etapa se subestima siempre y es donde se pierde más información.
- TrocearCortar en fragmentos que sigan siendo comprensibles por sí solos.
- Calcular embeddingsUn vector por fragmento, con el mismo modelo que después se va a usar para las preguntas.
- GuardarEl vector, el texto y los metadatos: documento, sección, fecha, permisos.
La segunda mitad, responder, corre en cada pregunta: convertir la pregunta en embedding, buscar los fragmentos más cercanos, reordenarlos, armar el prompt con los que sobrevivieron y generar la respuesta. Y acá está el punto que decide si el proyecto sirve: la calidad final depende mucho más de la recuperación que del modelo. Cambiar a un modelo mejor no arregla un índice que devuelve fragmentos equivocados.
Trocear: la decisión que más pesa
Si hay una decisión que define la calidad de un RAG, es esta. Y no tiene una respuesta numérica universal: tiene un criterio. El fragmento tiene que ser la unidad más chica que siga siendo comprensible por sí sola.
Los dos fracasos son simétricos. Fragmentos demasiado chicos pierden el contexto que los hace interpretables: «no aplica en ese caso» no significa nada sin el párrafo anterior. Fragmentos demasiado grandes mezclan temas, así que compiten mal en la búsqueda —el vector promedia significados— y desperdician contexto cuando llegan.
Tres reglas que rinden más que ajustar el tamaño:
- Cortar por la estructura, no por cantidad de caracteres. Títulos, secciones, artículos, filas de una tabla. El documento ya trae marcada la unidad de sentido: usala.
- Repetir el encabezado en cada fragmento. Agregar al texto del fragmento la ruta de títulos que lo contiene —«Manual de personal › Licencias › Vacaciones»— mejora la recuperación sin costo, porque le devuelve el contexto que el corte le quitó.
- Guardar metadatos desde el principio. Documento, sección, fecha de modificación y permisos. Agregarlos después implica reindexar todo.
# Un fragmento no es solo texto: es texto con su procedencia
fragmento = {
"texto": "Manual de personal > Licencias > Vacaciones\n"
"El personal con menos de cinco años de antigüedad...",
"documento": "manual-personal-v7.pdf",
"seccion": "3.2 Vacaciones",
"modificado": "2026-03-14",
"visible_para": ["empleados"], # se filtra ANTES de buscar
}Embeddings y búsqueda
Un embedding es la representación de un texto como una lista de números, calculada de manera que textos con significado parecido queden cerca en ese espacio. Eso es lo que permite que la pregunta «¿cuántos días de vacaciones tengo?» recupere un párrafo que habla de «licencia anual ordinaria» sin compartir una sola palabra.
La contracara es igual de importante y suele descubrirse tarde: la búsqueda por significado falla justo donde la textual acierta. Códigos de producto, números de expediente, nombres propios poco frecuentes, versiones exactas. Para «error E-4471» la búsqueda vectorial devuelve párrafos que hablan genéricamente de errores, y la textual devuelve el que dice E-4471.
De ahí la recomendación práctica: búsqueda híbrida, que combina las dos y fusiona los resultados. Es la mejora de mayor impacto por unidad de esfuerzo en casi cualquier RAG real.
Después de recuperar, hay un paso más que rinde: el reordenamiento. La búsqueda vectorial es rápida pero aproximada, así que conviene traer más candidatos de los necesarios —digamos veinte— y reordenarlos con un criterio más costoso y más preciso para quedarse con los cinco mejores. Menos fragmentos y más pertinentes es siempre mejor que muchos y mediocres, porque cada fragmento irrelevante que entra al contexto es una oportunidad de que el modelo se apoye en lo que no debía.
# Un embedding local, sin que el documento salga del equipo
# La documentación de Ollama incluye embeddings para búsqueda semántica y RAG
ollama pull embeddinggemma
ollama run embeddinggemma "El personal con menos de cinco años..."
# La salida es un arreglo JSON de números: eso es el vector que se guardaAnclar la respuesta
Recuperar bien es la mitad. La otra mitad es que el modelo use el material que le diste y no su memoria. Eso se pide de forma explícita, y la estructura del prompt importa:
Respondé la pregunta usando ÚNICAMENTE los fragmentos de abajo.
Si la respuesta no está en los fragmentos, decí exactamente:
"No encontré esa información en la documentación disponible."
Después de cada afirmación, indicá entre corchetes el número de fragmento.
No uses conocimiento propio ni completes lo que falte.
<fragmentos>
[1] (manual-personal-v7.pdf, 3.2 Vacaciones, 2026-03-14)
El personal con menos de cinco años de antigüedad...
[2] (convenio-2026.pdf, Art. 14, 2026-01-08)
Las licencias se computan en días corridos...
</fragmentos>
Pregunta: ¿cuántos días de vacaciones tengo con tres años de antigüedad?Cuatro elementos de ese prompt hacen el trabajo. La instrucción exclusiva —únicamente los fragmentos—; la salida de escape, una frase exacta para cuando no está, que es lo que evita que invente; la obligación de citar, que además vuelve auditable la respuesta; y los delimitadores que separan el material de la instrucción.
Si los documentos indexados los puede escribir cualquiera —tickets, correos, comentarios—, entonces el contenido recuperado puede traer instrucciones dirigidas al modelo. Es inyección de prompts por la vía del índice, y no se resuelve filtrando palabras. Se resuelve no dándole al sistema permisos que no necesita para responder una pregunta.
Cómo saber si funciona
Un RAG que «anda bien en las pruebas que hice» no dice nada, porque las pruebas que uno hace a mano son las que uno imagina. Lo que hace falta es un conjunto de preguntas reales con su respuesta esperada, y medir las dos mitades por separado:
- Recuperación: ¿el fragmento que contiene la respuesta apareció entre los recuperados? Se mide sin involucrar al modelo generador, y es donde suele estar el problema.
- Fundamentación: ¿lo que respondió está efectivamente respaldado por los fragmentos que recibió? Acá se mide si mezcló conocimiento propio.
La razón para separarlas es de diagnóstico. Si la recuperación falla, no tiene sentido tocar el prompt: hay que trabajar en el troceado, la búsqueda o el reordenamiento. Si la recuperación funciona y la respuesta sigue mal, el problema está en el prompt o en el modelo.
Permisos y privacidad
«Documentos propios» casi siempre significa documentos que no todos pueden ver, y ahí aparece el error de diseño más caro de este tipo de sistemas: construir el índice sin permisos y filtrar después.
El principio es simple y hay que aplicarlo desde el primer día: el filtro de permisos va antes de la búsqueda, no después. Si se recupera todo y se descarta lo que la persona no debería ver, cualquier error de implementación —o un cambio en el prompt— convierte el buscador interno en una fuga de información. Peor todavía: si el fragmento entró al contexto, ya salió del sistema, aunque la respuesta final no lo mencione.
Las otras dos decisiones de privacidad:
- Qué sale del equipo. Dos componentes ven el contenido completo: el modelo de embeddings, que procesa todos los documentos al indexar, y el modelo que redacta. Si los documentos son sensibles, los dos pueden correr localmente —ver modelos locales con Ollama—, a costa de capacidad.
- Qué queda registrado. Las preguntas de la gente son datos, y en un buscador interno pueden ser muy delicados. Vale decidir qué se guarda y por cuánto tiempo antes de encender el registro completo.
Errores frecuentes
- Empezar por la base vectorial. La elección de la base es la decisión menos importante del proyecto; el troceado es la más importante.
- Cortar cada 500 caracteres y seguir. Parte oraciones y separa cada afirmación de la condición que la limita.
- Usar solo búsqueda vectorial. Los códigos, nombres propios y números exactos se pierden. La híbrida es la mejora más rentable.
- Usar modelos de embedding distintos para indexar y para preguntar. Los vectores no son comparables: la búsqueda devuelve ruido.
- Meter veinte fragmentos «para que tenga contexto». Cada fragmento irrelevante es una oportunidad de que se apoye en lo que no debía.
- No pedir citas. Sin cita no hay forma de verificar la respuesta ni de diagnosticar la falla.
- Filtrar permisos después de buscar. Si el fragmento llegó al contexto, ya salió del sistema.
- Olvidar reindexar. Un índice desactualizado responde con seguridad total lo que decía el documento del año pasado.
Preguntas frecuentes
¿Qué es RAG y de dónde sale el nombre?
RAG es la sigla de Retrieval-Augmented Generation, recuperación aumentada de generación, y viene de un trabajo de Lewis y otros publicado en NeurIPS 2020. La idea que introduce es combinar dos tipos de memoria: la paramétrica, que es lo que el modelo aprendió durante su entrenamiento y quedó guardado en sus parámetros, y la no paramétrica, que en ese trabajo era un índice vectorial denso consultado por un recuperador. Trasladado a la práctica actual: en lugar de esperar que el modelo sepa algo, se busca el fragmento pertinente en tus documentos y se le pasa junto con la pregunta.
¿Conviene RAG o ajustar el modelo?
Depende de qué falta. Si falta conocimiento —datos que el modelo no vio, o que cambian seguido— la respuesta suele ser RAG, porque actualizar el índice es reindexar un documento y no reentrenar nada. Si lo que falta es comportamiento —un formato de salida muy específico, un estilo, una tarea con estructura fija— ahí el ajuste fino rinde más. La regla que funciona: RAG para lo que el modelo no sabe, ajuste para lo que el modelo no hace como querés. Y muchas veces la respuesta correcta es ninguna de las dos, sino un prompt mejor.
¿De qué tamaño conviene cortar los fragmentos?
No hay un número universal, y quien te dé uno sin preguntar por tus documentos está adivinando. Lo que sí hay es un criterio: el fragmento tiene que ser la unidad más chica que siga siendo comprensible por sí sola. Si al leerlo aislado no se entiende de qué habla, es demasiado chico; si trae tres temas distintos, es demasiado grande y va a competir con otros en la búsqueda. Conviene cortar por la estructura del documento —títulos, secciones, artículos— antes que por cantidad de caracteres, y medir el resultado con preguntas reales.
¿Qué es un embedding y por qué sirve para buscar?
Un embedding es la representación de un texto como una lista de números, calculada por un modelo de manera que textos con significado parecido queden cerca en ese espacio. Eso permite buscar por sentido y no por palabras: la pregunta «¿cuántos días de vacaciones tengo?» puede recuperar un párrafo que habla de «licencia anual ordinaria» sin compartir ni una palabra. La contracara es que la búsqueda por significado falla justo donde la textual acierta, con códigos de producto, nombres propios y números exactos, y por eso conviene combinar las dos.
¿Por qué el sistema responde cosas que no están en los documentos?
Por dos causas distintas que conviene separar antes de intentar arreglarlas. Una es de recuperación: el fragmento correcto nunca llegó al contexto, así que el modelo completó con lo que tenía. La otra es de fundamentación: el fragmento correcto llegó y el modelo igual mezcló su conocimiento previo. La forma de distinguirlas es mirar qué se recuperó en el caso que falló. Y la defensa mínima es instruir explícitamente que responda solo con el material provisto, que diga que no sabe cuando no está, y que cite de qué fragmento salió cada afirmación.
¿Se puede armar un RAG sin mandar los documentos a un proveedor externo?
Sí, y para documentos internos suele ser el punto de partida más sensato. Las dos piezas que ven el contenido son el modelo de embeddings, que lo procesa entero al indexar, y el modelo de lenguaje que redacta la respuesta. Las dos pueden correr localmente: la documentación de Ollama incluye la generación de embeddings pensada explícitamente para búsqueda semántica y RAG. El compromiso es de capacidad: un modelo local chico redacta peor que uno grande remoto, y hay que medir si esa diferencia importa para tu caso.
Fuentes
Documentación oficial, literatura académica y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.
Aportes de la comunidad Underc0de
- Underc0de, blog. LangSmith: vulnerabilidad crítica permite robo de claves API y datos en LangChain, 19 de junio de 2025. Un recordatorio de que las piezas del andamiaje de RAG son software con vulnerabilidades como cualquier otro.
- Underc0de, foro. Sección Inteligencia artificial. Discusiones de la comunidad sobre modelos y herramientas.
Literatura y documentación oficial
- Lewis, P. y otros. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020. El trabajo que introduce el término y la distinción entre memoria paramétrica y no paramétrica, citada textualmente.
- Ollama. Embeddings. Generación de embeddings para búsqueda semántica, recuperación y RAG.
- Ollama. CLI Reference. Los comandos usados en los ejemplos de esta guía.