Qué es RAG y por qué importa
Retrieval Augmented Generation, conocido por sus siglas RAG, es el patrón arquitectónico que permite a un modelo de lenguaje grande responder preguntas utilizando información que no forma parte de sus datos de entrenamiento. La idea central es directa: antes de generar una respuesta, el sistema recupera los fragmentos de información más relevantes de una base de conocimiento externa y los incluye en el contexto que recibe el modelo.
El problema que RAG resuelve es fundamental en cualquier aplicación empresarial de LLMs. Los modelos tienen una fecha de corte de conocimiento; no saben qué pasó después de su entrenamiento. Tampoco tienen acceso a la documentación interna de tu organización, tus tickets de soporte, tus contratos o cualquier dato propietario. RAG conecta el poder generativo del modelo con el conocimiento específico y actualizado que tu aplicación necesita.
El diagrama conceptual del patrón tiene cuatro componentes. El usuario formula una pregunta. El sistema convierte esa pregunta en una representación vectorial (embedding) y busca los fragmentos más similares en un índice vectorial. Los fragmentos recuperados se combinan con la pregunta original en un prompt enriquecido. El LLM genera una respuesta fundamentada en ese contexto específico, no solo en su conocimiento de entrenamiento.
Cómo funciona la búsqueda vectorial
El componente técnico central de RAG es el índice vectorial. Durante la fase de indexación, cada documento del corpus se divide en fragmentos (chunks) y cada fragmento se convierte en un vector numérico de alta dimensión mediante un modelo de embeddings. Azure OpenAI ofrece text-embedding-3-large y text-embedding-3-small para este propósito, con dimensiones de 3.072 y 1.536 respectivamente.
En tiempo de consulta, la pregunta del usuario también se convierte en un vector usando el mismo modelo de embeddings. El índice vectorial calcula la similitud entre el vector de la consulta y todos los vectores del corpus, normalmente usando similitud coseno, y devuelve los k fragmentos más similares. En Azure AI Search, este proceso se implementa a través de campos de tipo Edm.Single colección, con HNSW (Hierarchical Navigable Small World) como algoritmo de indexación aproximada para mantener la latencia en rangos aceptables a escala.
La elección del tamaño de chunk es una de las decisiones de arquitectura más importantes y menos triviales. Chunks demasiado pequeños pierden contexto y producen fragmentos sin sentido propio. Chunks demasiado grandes incluyen información irrelevante que confunde al modelo. El rango entre 256 y 512 tokens suele funcionar bien para documentación técnica, pero la configuración óptima depende del tipo de contenido y del caso de uso específico.
La evolución hacia la búsqueda híbrida
La búsqueda puramente vectorial tiene una limitación bien documentada: falla con acrónimos, nombres propios, códigos de error y términos técnicos muy específicos. Si alguien busca “error AADSTS70011”, la búsqueda vectorial puede no encontrar el documento correcto porque el embedding del acrónimo no captura su significado semántico de la misma manera que lo hace una búsqueda de texto exacto.
La solución es combinar búsqueda vectorial con BM25, el algoritmo clásico de recuperación de información basado en frecuencia de términos. BM25 es excelente precisamente donde los vectores fallan: coincidencias exactas, términos raros, nombres propios. La combinación de ambas técnicas se denomina búsqueda híbrida.
Azure AI Search implementa búsqueda híbrida de forma nativa desde 2024. La consulta incluye tanto el campo vectorial como la consulta de texto, y los resultados se fusionan usando Reciprocal Rank Fusion (RRF). RRF combina los rankings de ambas búsquedas dando más peso a los documentos que aparecen en posiciones altas en ambas listas, independientemente de sus puntuaciones absolutas. El resultado es una lista fusionada más robusta que cualquiera de las dos búsquedas por separado.
El reranking como capa final de calidad
Incluso con búsqueda híbrida, el ranking inicial puede incluir falsos positivos: documentos que contienen las palabras correctas o tienen embeddings similares pero que en realidad no son relevantes para la consulta específica. El reranking es la capa que elimina ese ruido.
El reranker de Azure AI Search es un modelo de cross-encoding entrenado específicamente para evaluar la relevancia entre una consulta y un documento completo. A diferencia del proceso de recuperación inicial, que usa representaciones independientes de consulta y documento, el reranker los evalúa juntos en el mismo contexto. Esto permite detectar sutilezas de relevancia que los embeddings independientes no pueden capturar.
En la práctica, el reranker recibe los k resultados del fusionador RRF, normalmente entre 20 y 50 documentos, y devuelve los n más relevantes, normalmente entre 3 y 10. Este proceso añade una latencia de entre 50 y 200 milisegundos típicamente, pero el impacto en la calidad de los resultados justifica ampliamente el coste en la mayoría de los casos de uso.
Límites reales de RAG clásico en producción
Después de diseñar y operar sistemas RAG en producción durante los últimos dos años, los límites más relevantes que aparecen de forma consistente son los siguientes.
El primero es el problema del conocimiento distribuido en sistemas multi-agente. Cuando varios agentes necesitan acceder a la misma base de conocimiento, la tentación es darle a cada uno su propio índice. Esto funciona al principio, pero genera inconsistencias progresivas: cada índice tiene su propia versión de la verdad, y cuando se actualiza uno, los demás no se actualizan automáticamente.
El segundo límite es la consulta compleja multi-aspecto. Una pregunta como “¿qué artículos del blog hablan de RAG y fueron publicados después de que Azure AI Search introdujera búsqueda híbrida y tienen más de 1500 palabras?” no es una consulta vectorial; es una combinación de búsqueda semántica, filtro temporal, filtro de longitud y posiblemente traversal de grafo. La búsqueda vectorial estándar no resuelve esto bien.
El tercer límite es la información que no está en ningún índice estático. Si el usuario pregunta por las últimas novedades de Azure AI Search anunciadas esta semana, ningún índice vectorial actualizado semanalmente puede responder. Se necesita acceso a información en tiempo real.
Estos tres límites son precisamente los que RAG 2.0 y arquitecturas como Foundry IQ de Azure AI Search están diseñadas para resolver. El artículo RAG 2.0 y Foundry IQ: la capa de conocimiento centralizada describe en detalle esta evolución y la arquitectura que la hace posible.
Conclusión
RAG sigue siendo el patrón fundamental para conectar LLMs con conocimiento específico. La búsqueda híbrida con reranking es hoy el punto de partida mínimo para cualquier sistema en producción. Pero los límites del RAG clásico — conocimiento distribuido, consultas complejas, información en tiempo real — empujan hacia arquitecturas más sofisticadas que mantienen el principio de RAG pero añaden capas de razonamiento, centralización y recuperación agéntica. La dirección es clara y las herramientas ya están disponibles en Azure.