¿Qué es RAG y qué puede aportar a tu empresa?

Pregúntale a un modelo frontera estándar algo sobre tu empresa y responderá con seguridad. Contará algo torcido la historia del cliente mencionado, se dejará la política que actualizaste el trimestre pasado y no citará ninguna fuente verificable. Ese es el modo de fallo que RAG está diseñado para arreglar y, en los últimos dieciocho meses, se ha convertido en la arquitectura sobre la que se construye todo despliegue creíble de IA empresarial. Aquí va qué es, dónde se sitúa respecto a la ventana de contexto de 1M de tokens y a MCP, y qué cambia si patrocinas el trabajo este trimestre.

La forma del problema

Marina Danilevsky, de IBM Research, cuenta una historia útil sobre sus hijos preguntándole qué planeta tiene más lunas. Respondió Júpiter, con 88. Estaba segura. Había leído sobre ello. Tampoco tenía la fuente a mano y su respuesta estaba treinta años desfasada. La respuesta correcta es Saturno, con 146. El modelo en la mano de tu consejero delegado tiene los mismos dos problemas, aplicados a tu negocio.

Contestará con seguridad a una pregunta sobre tu pipeline de ventas con conocimiento absorbido de texto público de internet que no contiene tu pipeline de ventas. Le dirá a un agente de atención al cliente la política de reembolsos equivocada con la misma fluidez con que recitaría la correcta. Y no puede explicarte por qué respondió como lo hizo, porque no puede mostrar la fuente.

Para una conversación personal sobre lunas, el coste es una pequeña vergüenza. Para una IA desplegada a escala en atención al cliente, ventas, finanzas o compliance, el coste es el tipo de incidente que acaba en un registro de riesgos. La confianza del modelo no es el fallo. Que la confianza no esté anclada a nada, sí.

Qué es RAG

RAG son las siglas de Retrieval-Augmented Generation (Generación Aumentada por Recuperación). En palabras llanas: antes de responder, el modelo va y lee el documento relevante, y luego responde a partir de lo que dice el documento. El modelo pasa de adivino a lector y escritor.

La forma es sencilla. Un usuario hace una pregunta. El sistema recupera los fragmentos de tus documentos más relevantes para esa pregunta. El modelo recibe la pregunta del usuario, más los fragmentos recuperados, más una instrucción que dice «responde a la pregunta usando estos fragmentos, cítales, y si los fragmentos no contienen la respuesta, dilo». La respuesta tiene ahora tres propiedades que el modelo sin modificar no podía darte: está fundamentada en tu contenido real, está al día según la última vez que actualizaste tu contenido, y puede mostrar su trabajo.

Sinceramente, es la misma disciplina que aplicaría un analista cuidadoso a un informe para el consejo. Leer primero la fuente, luego escribir. La novedad es que el modelo puede hacerlo a la velocidad y escala de una API.

Por qué el modelo estándar no basta por sí solo

Los modelos frontera se entrenan con algo parecido al internet público más una porción curada de código y contenido con licencia. Son sobresalientes en razonamiento general, tareas de lenguaje y conocimiento común. No se entrenan con tus contratos, tu lista de clientes, tu base de datos de proveedores, tus notas de reuniones, tu Confluence, tu SharePoint o tu manual de operaciones. La mayor parte de lo que hace específico tu negocio vive en sitios que el modelo nunca ha leído.

Por eso «solo tenemos que dar acceso a ChatGPT a nuestra gente» es el modo de fallo más común del despliegue de IA empresarial que veo ahora mismo. Quienes lo prueban descubren en una semana que el modelo es brillante en escritura general y poco fiable en cualquier cosa que implique la situación propia de la empresa. Pierden confianza. El piloto se atasca. El mismo patrón se repite en el lado orientado al cliente: un chatbot construido sobre el modelo sin modificar da respuestas plausiblemente redactadas que el equipo de soporte tiene que deshacer, y el experimento se archiva.

RAG es la arquitectura que cierra ese hueco. El modelo sigue haciendo el razonamiento y la escritura. Tus documentos aportan el fundamento.

El aspecto de la pila RAG de 2026

La versión de RAG que la mayoría se imagina es la de 2023: trocear los documentos, embeber cada fragmento como vector, almacenar los vectores en una base de datos, recuperar los mejores K por similitud del coseno y pegarlos delante del modelo. El benchmark CRAG de Meta de principios de 2024 mostró que el pipeline ingenuo solo respondía correctamente alrededor del 63 % de las preguntas fácticas. El estado del arte actual ha avanzado, e importa porque el hueco entre el pipeline del 63 % y el del 90 % o más es la diferencia entre una demo vergonzosa y un sistema en producción.

Tres de las cosas que han cambiado en los últimos 18 meses merecen que un consejero delegado las conozca por su nombre:

Contextual Retrieval. Anthropic publicó esta técnica en septiembre de 2024. La idea es sencilla: antes de embeber cada fragmento, un modelo lee el documento entero y escribe una nota corta específica del fragmento que sitúa ese fragmento concreto en el panorama general. Así, un párrafo de la página 47 de un contrato se marca con algo como «esto es de la cláusula de renovación de proveedor de la renovación de Acme de 2024, donde se definen los términos de extensión automática» en lugar de flotar aislado. Las cifras que comunicó Anthropic mostraban caídas del 49 al 67 % en las tasas de fallo de recuperación. La técnica se adopta ya como base.

GraphRAG. Microsoft lo liberó como código abierto en 2024. El RAG estándar puede responder a «¿Qué dice la cláusula 4 del contrato de Acme?» porque el fragmento relevante está a una recuperación de distancia. Le cuesta con «¿Cuáles son los patrones habituales de rescisión en todos nuestros contratos de proveedores?» porque esa pregunta exige razonar sobre todo el corpus a la vez. GraphRAG construye un grafo de entidades y relaciones junto a la base de datos de vectores, de modo que el modelo puede preguntar al grafo «lista todos los contratos que mencionan Acme» y luego leer los fragmentos. Es la diferencia entre una caja de búsqueda y un analista.

Agentic RAG. En lugar de una sola pasada de recuperación, el modelo ejecuta un bucle. Busca, mira lo que ha vuelto, decide si la evidencia es suficiente, reescribe la consulta si no lo es e itera. Es el patrón que usan la mayoría de despliegues en producción en 2026, porque maneja el caso real y sucio en el que la primera consulta es demasiado vaga o los documentos están repartidos entre varias fuentes.

Está también la cuestión de cómo se busca. El valor por defecto de 2026 es la «búsqueda híbrida»: combinar la búsqueda clásica por palabras clave con la búsqueda semántica por vectores y fusionar los resultados. Los vectores densos por sí solos se pierden los casos en los que el usuario usa un término específico que existe literal en el documento. La búsqueda por palabras clave sola se pierde sinónimos y paráfrasis. Combinarlas supera a cualquiera de las dos por un margen amplio en todos los benchmarks que he visto.

Sé que esto es técnico para un artículo estratégico. La cuestión no es que necesites entender la implementación. La cuestión es que «RAG» ya no es una sola cosa. Cuando un proveedor dice que lo ofrece, la pregunta correcta es qué versión, y sobre qué pila.

La pregunta honesta: ¿necesitas siquiera RAG en 2026?

Esta es la parte donde la conversación ha cambiado en los últimos doce meses, y donde la mayoría de artículos escritos antes de mayo de 2026 están ya desfasados.

Claude Sonnet 4.6, Opus 4.6 y Gemini 3.1 Pro soportan ahora ventanas de contexto de 1M de tokens; la familia GPT-5 se sitúa en 400K. Eso significa que el modelo puede retener una pequeña biblioteca de documentos en memoria de trabajo en un solo prompt. Para algunos casos de uso (síntesis entre documentos, análisis comparativo, resumir un corpus lo bastante pequeño) puedes simplemente pasar los documentos y saltarte la capa de recuperación por completo.

Al mismo tiempo, MCP, el Model Context Protocol que Anthropic liberó en noviembre de 2024, se ha convertido en la forma estándar de que los agentes de IA hablen con sistemas en vivo. Si quieres que el modelo conozca tu inventario actual, tus tickets de Jira en vivo, el saldo bancario de hoy, no los vectorizas: le das al modelo un servidor MCP que consulta la API en vivo. Es más bien «el agente hace una consulta a la base de datos» que «el agente recupera un fragmento vectorial».

Así que la pregunta en 2026 no es «¿deberíamos hacer RAG?». Es «para cada tipo de pregunta que mi gente o mis clientes puedan hacerle al modelo, ¿cuál es la forma correcta de fundamentarla?». La decisión es, a grandes rasgos:

• RAG cuando la fuente es texto no estructurado que cambia despacio. Políticas, contratos, wikis, informes históricos, material formativo, copy de marketing.
• MCP / uso de herramientas cuando la fuente es un sistema en vivo. CRM, ERP, ticketing, finanzas, cualquier cosa donde «actual» importe.
• Contexto largo cuando el corpus es lo bastante pequeño para caber y necesitas que el modelo razoné sobre el conjunto a la vez. Un puñado de documentos de 100 páginas que quieres comparar lado a lado.

La mayoría de empresas necesitará los tres. La habilidad consiste en casar la pregunta con el mecanismo de fundamentación adecuado, lo cual es más una decisión de diseño que tecnológica. Sigo comprobando que los equipos directivos que interiorizan esto dejan de tener conversaciones improductivas de «RAG vs fine-tuning» y empiezan a plantear la pregunta mejor: «¿cuál es la fuente de verdad para esta respuesta y cómo conectamos el modelo a ella?».

El artículo anterior de Converly sobre construir un pequeño índice de investigación de contenido para Claude defiende que, para corpus muy pequeños, la solución más ligera vence a una infraestructura RAG pesada. Ambas cosas pueden ser ciertas. Las preguntas de corpus pequeño pueden saltarse RAG; las de escala empresarial lo necesitan.

Qué cuesta ponerlo en marcha en tu empresa

Un despliegue RAG en condiciones tiene cuatro capas, y un comprador senior debería saber qué hay en cada una antes de aprobar la construcción:

La base de datos vectorial es donde viven los fragmentos de documento en su forma embebida. Los valores por defecto empresariales de 2026 son Pinecone para escala serverless gestionada, Weaviate para autohospedaje, pgvector si tu equipo quiere mantener los embeddings junto a tu Postgres existente y Turbopuffer para latencia ultrabaja. Ninguna es exótica. Ninguna te encierra.

El modelo de embeddings es lo que convierte un fragmento de texto en un vector. text-embedding-3-large de OpenAI es la base. Voyage y Cohere suelen ganar en compras empresariales porque tienen mejores resultados en contextos legal, médico y multilingüe.

La capa de recuperación en 2026 es híbrida por defecto: búsqueda vectorial densa más búsqueda por palabras clave BM25, fusionadas. No es una pieza de ingeniería complicada. Tampoco es, una vez más, un sitio donde asumir riesgo.

El re-ranker es un modelo pequeño que se ejecuta tras la recuperación inicial y reordena los 50 mejores candidatos para encontrar los 5 mejores. Rerank-v3 de Cohere y un puñado de alternativas abiertas ganan aquí. La mejora de calidad que aporta un re-ranker es siempre lo bastante grande como para que yo no pusiera en producción una pipeline RAG sin uno.

Lo que pilla desprevenidos a los equipos no es ninguna de las cuatro. Es el paso de parsing, antes de que los documentos lleguen siquiera a la pipeline. PDFs con tablas multicolumna, documentos escaneados, archivos de Word con objetos incrustados, contratos con notas al pie: todos rompen a los troceadores ingenuos. La razón más frecuente por la que las pipelines RAG alucinan en producción es que los documentos quedaron destrozados en el paso de parsing y el modelo está leyendo basura. Si aciertas el parsing, ya has resuelto la mayor parte del problema.

Lo segundo es el control de acceso. Si tu base de datos vectorial contiene tus registros de RR. HH. y un empleado le pregunta al chatbot por el salario de un compañero, necesitas control de acceso a nivel de fila en el almacén vectorial. Suena obvio. Es el tipo de obvio que se pasa por alto cuando un equipo pequeño lanza una demo interna y «demo interna pequeña» se convierte en «la cosa que usa toda la empresa». Construye el modelo de acceso en la arquitectura desde la primera semana.

Dónde aporta, y dónde no

Gartner calcula que en 2026 más del 70 % de las iniciativas de IA generativa empresarial requieren una pipeline RAG estructurada para ser defendibles frente al EU AI Act y marcos similares. Las empresas que la tratan como infraestructura y no como truco de magia están viendo cifras reales.

Vanguard y Morgan Stanley son los operadores citados con más frecuencia en este espacio. La plataforma de IA generativa con RAG de Vanguard está integrada en el flujo de los asesores financieros y se usa para producir resúmenes de contenido personalizados para clientes, con la calidad de recuperación medida contra juicios de relevancia anotados por humanos en lugar de una métrica bruta de coste de API. El sistema de gestión del conocimiento de Morgan Stanley, construido sobre infraestructura de OpenAI con una capa RAG sobre más de 100.000 documentos de investigación internos, se lanzó en marzo de 2023, lo usan a diario decenas de miles de gestores de patrimonios y se ha extendido a AskResearchGPT para la división Institutional Securities. El patrón que permite que ambos funcionen es que los casos de uso son acotados: un tipo de pregunta bien definido, planteado en gran volumen, contra un conjunto de fuentes bien curado. RAG premia el foco.

Los despliegues sin foco son la razón por la que hasta el 95 % de los pilotos de IA generativa, según el estudio «GenAI Divide» del MIT Project NANDA publicado en julio de 2025, no entregan un ROI medible a los seis meses. No porque la tecnología no funcione. Porque la pregunta «¿qué queremos que este modelo responda por nuestra empresa?» nunca se llegó a formular. No se puede construir un sistema de recuperación útil para un corpus indefinido en nombre de un usuario indefinido. El modelo es la parte fácil.

La forma en que se lo describo a los clientes es que RAG no es lo que deberías comprar. RAG es lo que construyes porque has decidido que una pregunta concreta, planteada con un volumen concreto, contra un conjunto de fuentes concreto, merece respuesta a velocidad de máquina. Acerta la pregunta y la arquitectura sigue. Acerta la arquitectura sin la pregunta y has puesto en producción infraestructura que no hace nada.

Qué significa esto para tu empresa

Si patrocinas este trabajo y quieres una sola regla que sobreviva a la traducción de vuelta al equipo operativo, aquí está. El modelo es un lector brillante y un escritor brillante. Nunca ha leído tu empresa. RAG es la arquitectura que cierra ese hueco y, a fecha de 2026, está lo bastante maduro como para que la ingeniería no sea la parte difícil: la parte difícil es elegir la pregunta correcta a la que aplicarlo.

Esa elección es decisión del equipo directivo. ¿Qué pregunta simple pero cara, en atención al cliente, finanzas, ventas, compliance u operaciones, está respondiendo mal tu empresa ahora mismo porque la respuesta correcta está encerrada en documentos que nadie puede buscar a velocidad? Esa es la pregunta para la que sirve RAG. Elige una. Constrúyela bien. Mídela contra una cifra de negocio, no contra un recuento de tokens.

Si quieres un recorrido estructurado por la empresa que saque a la luz esas preguntas y las ordene según dónde es más alcanzable la captura de valor este trimestre, para eso está la auditoría de IA de Converly. Es el mismo patrón que tratamos en el artículo sobre cómo se ve la IA desde la silla del consejero delegado, aplicado concretamente a la capa de acceso a datos. El Audit produce un informe que el equipo directivo puede aprobar, y el encargo de construcción que sigue pone en producción la pipeline RAG contra el problema descrito, con tu gente aprendiendo a operarla sobre el sistema en vivo.

La tecnología ya no es el cuello de botella. No lo es desde hace tiempo. El cuello de botella es que el equipo directivo decida qué pregunta se le debería permitir responder al modelo por la empresa, y luego dar al equipo pequeño el respaldo para ponerlo en producción.

Solo educativo, no es asesoramiento financiero. Hecho para el público de compradores senior de Converly. Para el relato de implementación sobre una alternativa de corpus pequeño, ver RAG Without RAG: How to Make a Content Research Index for Claude.

¿Quieres un recorrido estructurado por las preguntas de tu empresa? Habla con nosotros sobre el AI Audit.