10 enfoques de RAG que de verdad funcionan en producción: de lo básico a GraphRAG

Un desarrollador en Habr ha reunido una lista práctica de enfoques de RAG que se usan realmente en producción, a partir de su experiencia personal y del análisis de casos de otros equipos durante el último año de crecimiento activo del stack de LLM.

De dónde parte todo el mundo

El RAG ingenuo (naive RAG) es el punto de partida de la mayoría de los proyectos. El esquema es sencillo: los documentos se dividen en chunks y se indexan mediante embeddings. Al hacer una consulta, se recuperan los más cercanos por distancia coseno y se pasan al LLM como contexto. Funciona con bases de conocimiento pequeñas, preguntas simples y documentos homogéneos.

Los problemas aparecen a escala: los documentos largos encajan mal en chunks de tamaño fijo, las preguntas complejas requieren varios fragmentos a la vez y la formulación del usuario a menudo no coincide con el estilo de los documentos. Aquí entran en juego los enfoques avanzados.

Búsqueda híbrida y reranking

La búsqueda híbrida es la primera mejora que casi siempre compensa. Combinar vectores densos (búsqueda semántica) con BM25 (búsqueda por palabras clave) aporta de forma consistente entre un 15 % y un 30 % más de precisión que la búsqueda solo con embeddings. Los vectores densos captan la similitud de significado; los dispersos, las coincidencias exactas de términos, siglas y nombres.

Añadir un reranker cross-encoder sobre los 20 primeros resultados mejora la calidad otro 10–15 %. El reranker es un modelo más pesado, pero solo trabaja con el conjunto final de candidatos, así que la latencia sigue siendo aceptable para producción.

Técnicas a nivel de consulta

Algunos problemas de RAG se resuelven mejor antes de la búsqueda, reformulando o ampliando la consulta.

• HyDE: el LLM genera un documento hipotético con la respuesta y se usa su vector para buscar. Ayuda sobre todo cuando el estilo de la pregunta y el de los documentos difieren mucho.
• Multi-query: a partir de una pregunta se generan de 3 a 5 paráfrasis y la búsqueda se ejecuta en paralelo con todas. Reduce la dependencia de la formulación exacta del usuario.
• Step-back prompting: antes de buscar, el LLM generaliza la consulta a un nivel de abstracción superior. Es útil cuando una pregunta concreta es demasiado de nicho para una buena recuperación.
• Parent Document Retriever: se indexan chunks pequeños (alta precisión), pero al contexto se pasa el documento padre completo. Un buen equilibrio entre precisión y cobertura.
• Contextual compression: el LLM extrae del chunk recuperado solo la parte relevante. Ahorra tokens y reduce el ruido en el contexto.

Artillería pesada

Cuando las técnicas simples no bastan, entran en juego enfoques de arquitectura más compleja.

RAPTOR construye un árbol jerárquico de documentos: agrupa los chunks en clústeres, resume cada clúster y luego vuelve a agrupar los resúmenes. Al consultar, la búsqueda se hace en el nivel de abstracción adecuado. Funciona bien con documentos largos, como manuales técnicos, informes financieros y libros con distintos grados de detalle.

GraphRAG de Microsoft construye un grafo de conocimiento: extrae entidades y relaciones del texto y crea resúmenes de comunidades para distintos clústeres temáticos. Supera con claridad al RAG estándar en preguntas analíticas y comparativas ("cómo se relaciona X con Y", "qué ha cambiado desde A") y en tareas que exigen sintetizar información de todo el corpus.

Self-RAG y Corrective RAG llevan el sistema a un modo agéntico: el modelo decide por sí mismo si hace falta buscar, evalúa la relevancia de lo encontrado y, si es necesario, reformula la consulta. Añade latencia y complejidad, pero mejora de forma notable la calidad en tareas de varios pasos y ambiguas.

Qué significa esto

El camino práctico: empezar con búsqueda híbrida más reranking, que resuelve la mayoría de los problemas con un coste mínimo. Después, añadir multi-query o HyDE para consultas variadas. GraphRAG y Self-RAG solo deben incorporarse cuando las técnicas más simples no funcionan, porque exigen un esfuerzo considerable de desarrollo y mantenimiento. Para la mayoría de los productos B2B, bastan los dos primeros pasos.