RAG: dale a la IA el conocimiento privado de tu empresa

Uno de los límites más frustrantes de los modelos de lenguaje generales es que no saben nada de tu empresa. No conocen tu catálogo de productos, no han leído tus procedimientos internos, no tienen acceso a tu base de datos de clientes ni a los informes de tu equipo de ventas. Puedes intentar incluir toda esa información en el prompt, pero los modelos tienen límites de contexto y los documentos empresariales pueden ser enormes. La solución que ha emergido como estándar de facto en la industria para resolver este problema se llama RAG: Retrieval-Augmented Generation.

RAG es un patrón arquitectónico que combina la capacidad de recuperación de información de los motores de búsqueda semántica con la capacidad de razonamiento y generación de lenguaje de los LLMs. En lugar de incluir todo el conocimiento en el prompt, el sistema recupera dinámicamente solo los fragmentos más relevantes para la pregunta concreta que se está haciendo y se los pasa al modelo junto con la pregunta. El resultado es un sistema que puede responder preguntas sobre cualquier corpus documental, por grande que sea, con las garantías de que las respuestas están fundamentadas en fuentes reales y citables.

Este artículo es una guía práctica para diseñar e implementar pipelines RAG robustos en entornos empresariales. No es una introducción teórica: asumimos que el lector tiene una comprensión básica de qué son los embeddings y los modelos de lenguaje, y que quiere saber cómo construir un sistema que funcione bien en producción, no solo en un cuaderno de Jupyter.

Cómo funciona RAG: el flujo completo

Un pipeline RAG tiene dos fases diferenciadas. La primera es la fase de indexación, que ocurre offline: los documentos de la empresa se cargan, se fragmentan en chunks de tamaño manejable, cada chunk se convierte en un vector numérico mediante un modelo de embeddings, y estos vectores se almacenan en una base de datos vectorial junto con el texto original y los metadatos asociados (fuente, fecha, departamento, etc.). Esta fase puede tardar minutos u horas dependiendo del volumen documental, y debe repetirse cada vez que los documentos cambian.

La segunda fase es la de inferencia, que ocurre en tiempo real cuando el usuario hace una pregunta: la pregunta se convierte en un vector con el mismo modelo de embeddings usado en la indexación, se buscan en la base de datos vectorial los chunks más similares semánticamente a la pregunta (los k-nearest neighbors en el espacio vectorial), los chunks recuperados se incluyen en el prompt del LLM junto con la pregunta original, y el modelo genera una respuesta que está fundamentada en esos fragmentos específicos.

Elección del modelo de embeddings

El modelo de embeddings determina la calidad de la recuperación: si los embeddings no capturan bien la semántica del dominio, el sistema recuperará fragmentos irrelevantes y el LLM generará respuestas incorrectas. Para contenido en español, es importante usar modelos que hayan sido entrenados con datos en español o que sean genuinamente multilingüe. text-embedding-3-large de OpenAI y text-embedding-ada-002 son buenas opciones para contenido empresarial general. Para casos de uso que requieren mantener los datos en infraestructura propia, modelos open source como multilingual-e5-large o bge-m3 de BGE ofrecen un rendimiento excelente con despliegue local.

Un factor frecuentemente ignorado es el tamaño del contexto del modelo de embeddings: algunos modelos truncan los textos a 512 tokens, lo que puede ser insuficiente para fragmentos de documentos legales o técnicos. Verificar esta limitación antes de elegir el modelo puede ahorrar muchos problemas de calidad en producción.

Estrategias de fragmentación de documentos

La fragmentación (chunking) es uno de los factores que más impacto tiene en la calidad del sistema RAG y también uno de los más descuidados. La estrategia más simple, dividir el texto en fragmentos de tamaño fijo con algo de solapamiento, funciona razonablemente bien para textos uniformes pero falla con documentos estructurados como manuales técnicos, contratos o informes financieros, donde la información está organizada en secciones con significado propio.

Una estrategia más sofisticada es la fragmentación semántica: en lugar de dividir por número de tokens, se divide en unidades de significado (párrafos, secciones, elementos de lista). Para documentos con estructura explícita (HTML, Markdown, PDF con marcadores), se puede usar esa estructura como guía de fragmentación. Otra técnica avanzada es el small-to-big retrieval: se indexan chunks pequeños para precisión en la recuperación pero se pasa al modelo el chunk grande que los contiene para que tenga suficiente contexto para responder correctamente.

• Fragmentación por tamaño fijo: simple, funciona para texto prosa uniforme, chunk de 512-1024 tokens con solapamiento del 10-20%.
• Fragmentación por estructura: respeta párrafos, secciones y listas; mejor para documentos con estructura explícita.
• Fragmentación semántica: agrupa frases similares temáticamente usando modelos de embeddings ligeros.
• Small-to-big retrieval: indexa chunks pequeños pero recupera el documento padre completo para el contexto del LLM.
• Fragmentación por documento: un embedding por documento completo, útil cuando los documentos son cortos y autónomos.
• Fragmentación jerárquica: crea embeddings a nivel de párrafo y de sección, recupera en cascada de lo general a lo específico.

Bases de datos vectoriales: opciones y criterios de selección

El mercado de bases de datos vectoriales ha crecido enormemente y elegir la correcta para tu caso de uso requiere evaluar varios criterios. Para proyectos que comienzan, Chroma es la opción más sencilla de poner en marcha: es open source, se puede usar en modo embebido sin servidor y tiene una API Python muy limpia. Weaviate y Qdrant son alternativas open source con mejores capacidades para producción: clustering, persistencia robusta, filtrado híbrido (vectorial + metadatos) y APIs REST y gRPC bien documentadas.

Para organizaciones que ya tienen infraestructura en la nube, las opciones gestionadas simplifican operaciones significativamente: Pinecone es la más conocida y madura, con garantías de SLA adecuadas para producción; pgvector es una extensión de PostgreSQL que permite añadir capacidades vectoriales a una base de datos relacional existente, lo que es muy atractivo para equipos que quieren minimizar el número de sistemas; Azure AI Search y Amazon OpenSearch con vector search integrado son buenas opciones para organizaciones ya comprometidas con esas nubes.

Búsqueda híbrida: combinando semántica y palabras clave

La búsqueda semántica basada en vectores es excelente para preguntas conceptuales (qué dice nuestra política sobre el trabajo en remoto) pero puede fallar para preguntas que requieren coincidencia exacta de términos específicos (cuál es el número de contrato C-2024-1573). La búsqueda por palabras clave (BM25) es el complemento perfecto: es precisa para términos exactos y números pero ciega ante variaciones semánticas.

La búsqueda híbrida combina ambos enfoques: recupera candidatos por ambos métodos y luego aplica un algoritmo de re-ranking para ordenar los resultados según su relevancia combinada. Weaviate, Qdrant y Azure AI Search soportan nativamente la búsqueda híbrida. Para implementaciones personalizadas, el algoritmo RRF (Reciprocal Rank Fusion) es un método sencillo y efectivo para combinar los rankings de ambos métodos. En la mayoría de los casos de uso empresariales, la búsqueda híbrida supera significativamente a cualquiera de los dos métodos por separado.

Re-ranking para mejorar la precisión

La recuperación inicial (sea semántica, por palabras clave o híbrida) devuelve un conjunto de candidatos, típicamente entre 10 y 50 chunks. El re-ranking es un paso adicional que aplica un modelo más potente para reordenar esos candidatos según su relevancia específica para la pregunta. Los modelos de re-ranking (cross-encoders) evalúan el par (pregunta, fragmento) juntos, lo que les permite capturar dependencias semánticas más sutiles que los embeddings, que procesan pregunta y fragmento por separado.

Cohere Rerank es el servicio más utilizado para este propósito y ha demostrado mejoras consistentes de entre el 15% y el 30% en precisión de recuperación en benchmarks empresariales. Modelos open source como bge-reranker-large ofrecen rendimiento comparable para despliegue local. El coste computacional del re-ranking es mayor que el de la recuperación vectorial, pero dado que se aplica solo al conjunto reducido de candidatos, sigue siendo manejable en la mayoría de los escenarios.

Gestión de documentos multilingüe y formatos diversos

Las empresas reales trabajan con documentos en múltiples formatos: PDF, Word, Excel, PowerPoint, emails, páginas web internas, registros de bases de datos relacionales. Construir un pipeline robusto de ingestión que maneje todos estos formatos de forma fiable es uno de los mayores desafíos prácticos de los proyectos RAG. Herramientas como Unstructured.io o LlamaParse están especializadas en la extracción de contenido de documentos complejos, incluyendo tablas, imágenes con texto y estructuras de múltiples columnas que los extractores de PDF genéricos no manejan bien.

Para documentos multilingüe, es importante usar modelos de embeddings genuinamente multilingüe y ser cuidadoso con la fragmentación: un chunk que empieza en español y termina en inglés confundirá tanto al modelo de embeddings como al LLM. Una práctica recomendada es detectar el idioma de cada documento en el momento de la ingestión y almacenarlo como metadato, de forma que el sistema pueda filtrar por idioma cuando sea relevante.

Metadatos y filtrado: precisión sin sacrificar flexibilidad

Los embeddings solos no siempre son suficientes para recuperar los fragmentos correctos. Imagina un sistema RAG sobre la documentación de una empresa que tiene sucursales en varios países: una pregunta sobre la política de vacaciones puede recuperar fragmentos de la política de Francia cuando el usuario está preguntando sobre España. Los metadatos resuelven este problema: si cada chunk tiene almacenado el país, el departamento y la fecha de vigencia, el sistema puede filtrar los resultados de la búsqueda vectorial para que solo incluyan los chunks relevantes para el contexto del usuario.

Un diseño de metadatos bien pensado desde el principio tiene un impacto enorme en la precisión del sistema. Los metadatos más útiles suelen ser: fuente del documento (URL, nombre de archivo, departamento propietario), fecha de creación y última actualización, tipo de documento (procedimiento, política, contrato, informe), ámbito de aplicación (geografía, unidad de negocio, rol) y estado de vigencia (activo, obsoleto, borrador). Actualizar estos metadatos cuando los documentos cambian es tan importante como actualizar los embeddings.

Evaluación de la calidad del sistema RAG

Medir la calidad de un sistema RAG requiere evaluar dos dimensiones separadas: la calidad de la recuperación (¿están los fragmentos correctos entre los recuperados?) y la calidad de la generación (¿la respuesta generada es correcta, completa y fiel a las fuentes?). Para la primera dimensión, las métricas estándar son precision, recall y nDCG (Normalized Discounted Cumulative Gain), que requieren un conjunto de preguntas con los documentos de referencia correctos.

Para la segunda dimensión, frameworks como RAGAS (RAG Assessment) permiten evaluar automáticamente métricas como la faithfulness (¿la respuesta está soportada por los fragmentos recuperados?), la answer relevancy (¿la respuesta responde a la pregunta?) y el context recall (¿los fragmentos recuperados contienen la información necesaria para responder?). Construir un conjunto de evaluación con al menos 50-100 preguntas representativas de los casos de uso reales es una inversión que paga dividendos en toda la vida del proyecto.

RAG avanzado: técnicas para casos de uso exigentes

Los sistemas RAG básicos funcionan bien para consultas directas sobre documentos texto. Para casos de uso más exigentes, existen técnicas avanzadas que vale la pena conocer. HyDE (Hypothetical Document Embeddings) mejora la recuperación para preguntas abstractas: en lugar de buscar por el embedding de la pregunta, se le pide al LLM que genere un documento hipotético que respondería la pregunta, y se usa el embedding de ese documento para la búsqueda. El razonamiento es que el documento hipotético está más cerca en el espacio vectorial de los documentos reales que la pregunta original.

Query expansion y query decomposition son técnicas complementarias: la primera enriquece la pregunta con sinónimos y reformulaciones para mejorar el recall; la segunda descompone preguntas complejas en subpreguntas más sencillas, recupera información para cada una por separado y sintetiza los resultados. Para documentos que contienen tablas y datos estructurados, Text-to-SQL o Text-to-Pandas permiten al LLM generar consultas que se ejecutan directamente sobre los datos, en lugar de buscar fragmentos de texto que describen esos datos.

Un sistema RAG bien diseñado no es solo un buscador más sofisticado: es la diferencia entre una IA que contesta con generalidades y una IA que conoce en profundidad tu empresa, tu sector y tus documentos, y puede razonar sobre ellos con precisión y transparencia.

Gobernanza y control de acceso en sistemas RAG empresariales

Un aspecto crítico que los tutoriales técnicos suelen ignorar es la gobernanza del acceso a la información. En una empresa, no todos los empleados tienen acceso a todos los documentos: los contratos con clientes son confidenciales, los informes de recursos humanos están restringidos, los documentos estratégicos solo deben ser accesibles para la dirección. El sistema RAG debe respetar estos permisos: un usuario no debe poder obtener información de un documento al que no tiene acceso, aunque sea a través de una pregunta en lenguaje natural.

Implementar esto correctamente requiere integrar el sistema RAG con el sistema de identidad y permisos de la organización (Active Directory, Azure AD, Okta) y filtrar los resultados de búsqueda según los permisos del usuario autenticado. Cada chunk en la base de datos vectorial debe tener metadatos que indiquen quién puede acceder a él, y el sistema de recuperación debe aplicar estos filtros antes de pasar los resultados al LLM. Ignorar este requisito en el diseño y añadirlo a posteriori es mucho más costoso y arriesgado.

De prototipo a producción: lo que cambia

El salto de un prototipo RAG a un sistema en producción implica resolver una serie de problemas que no aparecen en el desarrollo: la actualización incremental del índice cuando los documentos cambian (sin necesidad de reindexar todo el corpus), la gestión de versiones de documentos (qué pasa cuando una política interna se actualiza, ¿el sistema debe responder con la versión vigente o puede confundirse con versiones antiguas?), la escalabilidad bajo carga concurrente y la monitorización de la deriva de calidad a lo largo del tiempo.

Para equipos que quieren un punto de partida sólido para producción, plataformas como Azure AI Search con Azure OpenAI, Amazon Kendra o Google Vertex AI Search ofrecen soluciones gestionadas que resuelven muchos de estos problemas operativos fuera de la caja. La desventaja es el coste y la menor flexibilidad para personalización. Para equipos con capacidad de ingeniería, una arquitectura propia construida con Qdrant, LangChain y un modelo como Claude 3.5 Sonnet o GPT-4o puede ofrecer mejores resultados con mayor control, a cambio de mayor esfuerzo de operación.