Un pipeline de RAG tiene tres etapas: indexación, recuperación y generación. Durante la indexación, tomas tus documentos — PDFs, páginas web, registros de bases de datos, lo que sea — los divides en fragmentos, pasas cada fragmento por un modelo de embeddings para obtener un vector, y almacenas esos vectores en una base de datos vectorial como Qdrant, Pinecone o Weaviate. Durante la recuperación, la consulta del usuario se embebe con el mismo modelo, y la base de datos vectorial devuelve los top-k fragmentos más similares (típicamente 3–10). Durante la generación, esos fragmentos se insertan en el prompt del modelo como contexto, y el modelo genera una respuesta fundamentada en ese material. El viaje completo — embeber la consulta, buscar, ensamblar el prompt, generar — típicamente toma 1–3 segundos.
El chunking es donde la mayoría de los sistemas RAG tienen éxito o fracasan, y es más sutil de lo que parece. Cortar fragmentos demasiado pequeños y pierdes contexto; demasiado grandes y desperdicias precioso espacio de ventana de contexto en texto irrelevante. Un punto de partida común es 500–1000 tokens por fragmento con 10–20% de solapamiento entre fragmentos adyacentes (para no perder información que cruza un límite). Pero el chunking ingenuo de tamaño fijo a menudo corta oraciones por la mitad o separa un encabezado de su contenido. Enfoques más sofisticados usan la estructura del documento — dividiendo por encabezados, saltos de párrafo o cambios semánticos — para crear fragmentos que sean autocontenidos y significativos. El RecursiveCharacterTextSplitter de LangChain y el SentenceSplitter de LlamaIndex ambos intentan manejar esto, pero los mejores resultados usualmente vienen de entender tus documentos específicos y escribir lógica de división personalizada.
El paso de recuperación tiene más opciones de las que la gente se imagina. La búsqueda pura por similitud vectorial (búsqueda de vecino más cercano en espacio de embeddings) es el predeterminado, pero tiene dificultades con coincidencias exactas de palabras clave, nombres propios e identificadores de código. Por eso la búsqueda híbrida se ha convertido en el estándar en sistemas de producción: ejecutas tanto una búsqueda vectorial como una búsqueda tradicional por palabras clave (BM25), luego combinas los resultados usando fusión de rango recíproco o un re-ranker aprendido. Qdrant, Weaviate y Elasticsearch soportan búsqueda híbrida de forma nativa. El re-ranking — tomar los top 20–50 resultados de la recuperación y puntuarlos con un modelo cross-encoder — añade latencia pero mejora dramáticamente la relevancia. Cohere Rerank y modelos cross-encoder de Hugging Face son las opciones comunes aquí.
Un concepto erróneo común es que RAG elimina las alucinaciones. Las reduce significativamente, pero un modelo aún puede alucinar detalles que no están en los fragmentos recuperados, especialmente si los fragmentos están tangencialmente relacionados con la consulta en lugar de responderla directamente. Los buenos sistemas RAG mitigan esto incluyendo instrucciones de citación de fuentes en el prompt (“solo responde basado en el contexto proporcionado, cita tus fuentes”), filtrando fragmentos de baja relevancia (estableciendo un umbral mínimo de similitud en lugar de siempre devolver top-k), y permitiendo al modelo decir “No tengo suficiente información” cuando el contexto recuperado genuinamente no responde la pregunta. Algunos equipos añaden un paso de verificación donde una segunda llamada al modelo verifica si la respuesta está realmente respaldada por las fuentes.
RAG fue introducido en un paper de 2020 por Facebook AI Research (ahora Meta AI), pero no se convirtió en un patrón de producción mainstream hasta 2023 cuando las bases de datos vectoriales y las APIs de embeddings maduraron lo suficiente para hacerlo práctico. El patrón ha evolucionado desde entonces en varias direcciones: GraphRAG usa grafos de conocimiento en lugar de (o junto con) búsqueda vectorial para mejor manejo de preguntas relacionales. RAG agéntico le da al modelo la capacidad de reformular consultas, buscar en múltiples fuentes e iterar en la recuperación en lugar de hacer una sola búsqueda. Y la expansión de ventanas de contexto — los modelos ahora manejan más de 100K tokens — ha llevado a algunos equipos a saltarse RAG completamente para bases de conocimiento más pequeñas, simplemente metiendo todo en el prompt. Ese enfoque funciona para unos pocos cientos de páginas de documentos pero falla a escala, que es donde RAG sigue siendo esencial.