RAG (Retrieval-Augmented Generation): respuestas con tus propios documentos
RAG busca fragmentos relevantes de tus documentos y se los pasa al modelo para que responda con ellos. Cómo funciona, cuándo usarlo y qué puede fallar.
¿Qué es RAG?
RAG combina dos piezas. Un recuperador busca en tu base de documentos los fragmentos más relacionados con la pregunta, normalmente comparando embeddings. Un generador, el LLM, escribe la respuesta usando la pregunta y esos fragmentos como contexto.
El proceso tiene tres pasos: recuperar, aumentar el prompt con lo recuperado y generar. Si la búsqueda trae los textos correctos, el modelo tiene a la mano lo que necesita. Si trae textos irrelevantes, el modelo responde con lo que tiene, y puede inventar.
La idea fue descrita en 2020 por Lewis y colaboradores (Facebook AI Research, University College London y NYU), que combinaron un modelo generativo preentrenado (su memoria paramétrica) con un índice denso de pasajes de Wikipedia (su memoria no paramétrica) al que se accede con un recuperador neuronal. Reportaron mejores resultados en tres tareas de preguntas y respuestas de dominio abierto que los modelos que solo usaban su memoria paramétrica. El artículo también probó dos variantes: una que usa los mismos pasajes para toda la respuesta y otra que puede usar pasajes distintos en cada palabra generada.
¿Cómo funciona paso a paso?
Un sistema RAG tiene dos momentos, y conviene distinguirlos porque fallan de forma distinta.
Antes de que alguien pregunte (indexación):
- Se reúnen los documentos: guías, artículos, tickets, manuales.
- Se dividen en fragmentos o chunks, por ejemplo uno por sección o por párrafo.
- Cada fragmento se convierte en un vector con un modelo de embeddings y se guarda en un índice, a menudo una base de datos vectorial.
Cuando alguien pregunta (consulta):
- La pregunta se convierte en un vector con el mismo modelo.
- El sistema busca los fragmentos más cercanos, lo que se parece a una búsqueda semántica. Muchos sistemas combinan esto con búsqueda por palabras clave (como BM25), porque los nombres propios, códigos y siglas se encuentran mejor por coincidencia exacta.
- Opcionalmente, un paso de reranking reordena los candidatos para dejar los más útiles arriba.
- Los mejores fragmentos se pegan en el prompt junto con la pregunta y las instrucciones.
- El modelo genera la respuesta, idealmente citando de qué fragmento salió cada dato.
Lo importante para quien diseña: cada paso es un lugar donde algo puede salir mal y donde la interfaz puede ser honesta con la persona.
¿Por qué le importa a un diseñador?
Porque RAG define qué puede responder tu producto y cómo lo demuestra:
- Fuentes visibles. Como la respuesta se apoya en fragmentos concretos, puedes mostrar de dónde sale cada afirmación. Eso aumenta la verificabilidad. Más en citas y fuentes en respuestas de IA.
- Límites explícitos. Si la búsqueda no encuentra nada, el producto debe decirlo. “No encontré esto en tus documentos” es una respuesta válida y necesaria.
- Actualización sin reentrenar. Cambiar un documento cambia la respuesta. Eso es útil para contenidos vivos, como una guía de estilo o un catálogo. Para cambiar el tono o el comportamiento del modelo, en cambio, se compara con fine-tuning y prompting.
- Latencia y costo. Buscar y luego generar agrega pasos. Esto se nota en la interfaz; conviene mostrar un estado de búsqueda distinto al de escritura.
¿Cuándo NO conviene RAG?
Cuando la tarea no depende de documentos: escribir un texto creativo, traducir una frase o razonar sobre un problema general. También cuando los documentos son tan pocos que caben enteros en la ventana de contexto. Anthropic lo dice sin rodeos en su publicación sobre recuperación contextual: si tu base de conocimiento tiene menos de 200.000 tokens (unas 500 páginas), puedes incluirla completa en el prompt, sin necesidad de RAG, y el prompt caching abarata y acelera esa opción. Y cuando la información necesita ser exacta y estructurada, como saldos o inventarios, es mejor consultar la base de datos directamente.
¿Qué puede fallar?
Muchos fallos de RAG empiezan en la recuperación:
- Chunks mal cortados. Un fragmento que corta una frase o separa un título de su contenido pierde sentido.
- Falta de contexto en el fragmento. Un párrafo que dice “esto no aplica en móvil” no sabe a qué se refiere. Anthropic describe la recuperación contextual, que añade a cada fragmento una breve explicación de su contexto antes de indexarlo. Según su publicación, combinar embeddings contextuales con BM25 contextual redujo 49 % la tasa de fallos al recuperar los 20 mejores fragmentos (de 5,7 % a 2,9 %), y agregar reranking la redujo 67 % en sus pruebas. Son resultados de sus propios conjuntos de datos: sirven como orden de magnitud, no como promesa para tu caso.
- Búsqueda sin reranking. A veces el fragmento correcto está en los resultados, pero no en el primer lugar.
- Documentos contradictorios. El modelo puede mezclar versiones viejas y nuevas.
- Manipulación de fuentes. Si cualquiera puede escribir en la base de documentos, puede influir en las respuestas.
- Respuestas que se salen de las fuentes. Aun con buenos fragmentos, el modelo puede añadir datos que ninguno contiene. RAG reduce las alucinaciones, no las elimina.
¿Cómo saber si funciona?
Mide dos cosas por separado, porque una respuesta mala puede tener dos causas distintas:
- ¿Llegó el fragmento correcto? Arma una lista de preguntas reales y, para cada una, marca qué documento debería aparecer. Luego revisa si aparece entre los primeros resultados. Si no aparece, el problema está en la búsqueda y ningún cambio de prompt lo arreglará.
- ¿Usó bien lo que recibió? Con el fragmento correcto a la vista, revisa si la respuesta se mantiene fiel a él, si cita bien y si admite cuando falta información.
Esa lista de preguntas con respuesta esperada es un golden dataset, y las revisiones periódicas son parte de lo que se llama evals. Vuelve a correrla cada vez que cambies el modelo, la forma de cortar los documentos o el contenido de la base.
Ejemplo
Ejemplo ilustrativo: un equipo de diseño construye un asistente sobre su guía de componentes. Cuando un diseñador pregunta “¿cuál es el espaciado para tarjetas en móvil?”, el sistema busca y devuelve dos fragmentos: uno de la guía vigente y otro de una versión de 2022. La respuesta cita el vigente, pero el diseñador ve también la fuente vieja y entiende por qué hay dos cifras. El producto muestra fecha y versión junto a cada cita. Ese detalle de interfaz evita que una respuesta correcta pierda credibilidad.
Errores comunes
- Lanzar RAG sin evaluar la recuperación por separado.
- Indexar documentos sin fecha ni versión.
- Mostrar la respuesta sin fuentes porque “queda más limpio”.
- Esperar que RAG reemplace cualquier necesidad de buen diseño de documentos.
- Pensar que más fragmentos siempre mejoran la respuesta. Más ruido puede empeorarla.
- Usar RAG por costumbre cuando todo el material cabe en la ventana de contexto.