Cómo funciona RAG
Un sistema RAG tiene dos partes.
Antes de que nadie pregunte: la indexación
Los documentos se recogen de donde están, como un repositorio documental, una wiki o un sistema de tickets. Se dividen en fragmentos, normalmente de no más de unos cientos de tokens cada uno. Cada fragmento se convierte en un embedding, una lista de números que capta su significado, y se almacena en un índice de búsqueda, a menudo junto a un índice de palabras clave.
Cuando alguien pregunta: recuperación y generación
La pregunta se busca en el índice. Los pasajes que mejor encajan se recuperan, a menudo reordenados por un segundo modelo, y se colocan en el prompt con la pregunta y con instrucciones como "responde solo a partir de estos pasajes y cítalos". El modelo redacta la respuesta, y la aplicación muestra las fuentes a su lado.
Opciones de arquitectura RAG
| Opción | Cómo funciona | Dónde encaja |
|---|---|---|
| Búsqueda vectorial | Encuentra pasajes de significado cercano a la pregunta, mediante embeddings | Preguntas formuladas de forma distinta a los documentos. Puede pasar por alto términos exactos como códigos y nombres |
| Búsqueda híbrida | Ejecuta a la vez la búsqueda por palabras clave (BM25) y la vectorial y fusiona los resultados | Una buena opción por defecto para el contenido de empresa, que mezcla prosa con códigos, nombres y números |
| Reordenación (re-ranking) | Un segundo modelo reordena los primeros resultados por relevancia | Colecciones grandes en las que la primera búsqueda devuelve muchos resultados casi correctos |
| Recuperación contextual | Añade a cada fragmento una breve descripción de su documento antes de indexarlo | Fragmentos que pierden su sentido fuera de contexto, como una cláusula o una fila de una tabla |
| Contexto largo | Coloca documentos enteros en la ventana de contexto del modelo en lugar de buscar | Conjuntos de documentos pequeños y estables. Cuesta más por pregunta |
En las pruebas de Anthropic, los embeddings contextuales combinados con la búsqueda por palabras clave BM25 y la reordenación redujeron en un 67 % la tasa en la que el pasaje correcto faltaba entre los 20 primeros resultados. Azure AI Search, por ejemplo, ejecuta en paralelo consultas por palabras clave y vectoriales y las fusiona con Reciprocal Rank Fusion, una forma habitual de construir la búsqueda híbrida.
Antes de construir un índice, compruebe lo que ya ofrece su plataforma de IA. Claude, por ejemplo, puede trabajar con fuentes conectadas como Google Drive o Microsoft 365 mediante conectores, lo que a menudo basta para un primer paso.
Límites de RAG y cómo gestionarlos
- Pasajes que se escapan. Al dividir los documentos, un pasaje puede quedar separado del contexto que le da sentido, y los embeddings pueden pasar por alto coincidencias exactas que la búsqueda por palabras clave sí encuentra. La búsqueda híbrida y la recuperación contextual reducen ambos problemas.
- Contenido desactualizado. Un índice es una copia. Cuando los documentos cambian, hay que actualizarlos junto con sus embeddings, idealmente de forma automática y en segundo plano.
- Permisos. El índice debe respetar quién puede ver qué, para que una persona solo recupere los pasajes que tiene permiso para leer.
- Respuestas que van más allá de las fuentes. RAG reduce las respuestas inventadas, pero no las elimina. Las instrucciones de responder solo a partir de los pasajes, las citas que la gente puede comprobar y un simple "no lo sé" cuando no se encuentra nada pertinente mantienen la honestidad de las respuestas.
- Demasiado contexto. Los modelos pueden perder la información situada en medio de un prompt largo, así que menos pasajes y mejores suelen dar mejor resultado que muchos.
La forma de saber si un sistema RAG funciona es probarlo: un conjunto de preguntas reales con respuestas y fuentes conocidas, en el que se miden tanto la recuperación como la calidad de la respuesta, antes y después de cada cambio.
RAG, fine-tuning y contexto largo
| Enfoque | Qué cambia | Úselo para |
|---|---|---|
| RAG | Lo que el modelo puede ver cuando responde | Conocimiento que cambia, es extenso o necesita citas |
| Fine-tuning (ajuste fino) | Cómo se comporta el modelo, mediante entrenamiento adicional | Un estilo, un formato o una tarea constantes, no datos que cambian |
| Contexto largo | Cuánto lee el modelo en una sola solicitud | Unos pocos documentos cada vez, como un contrato o un informe |
Se combinan bien: un modelo puede ajustarse para un formato, usar RAG para el conocimiento y leer un documento entero cuando se adjunta uno.
Dónde usan RAG las empresas
- Políticas y RR. HH.: respuestas sobre permisos, gastos o normas de seguridad, con un enlace a la política.
- Atención al cliente: respuestas redactadas a partir de la base de conocimiento y de tickets anteriores, para que las envíe una persona.
- Legal y cumplimiento: investigación en contratos, cláusulas y normativa, con cada pasaje citado.
- Documentación técnica: respuestas para ingenieros y equipos de campo a partir de manuales y especificaciones.
- Ventas: datos de producto y textos de propuestas anteriores, para una oportunidad concreta.
Fuentes
- Lewis et al.: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020
- Anthropic: Introducing Contextual Retrieval, 19 de septiembre de 2024
- Microsoft: Hybrid search in Azure AI Search
- AWS: What is retrieval-augmented generation?
- Liu et al.: Lost in the Middle: How Language Models Use Long Contexts