Por qué NO uso RAG (y qué hago en su lugar con Claude Code)

Cada vez que cuento cómo tengo montado mi sistema de documentación con Claude Code, me llega la misma pregunta por DMs, comentarios y emails.

"Rubén, ¿por qué no usas RAG?" "Rubén, ¿por qué no montas una base de datos vectorial?" "Rubén, si descubrieras las bases de datos vectoriales te explotaría la cabeza."

Pues mira, las conozco. Las he usado bastante. Y justamente por eso no las uso para esto.

¿Qué es RAG y por qué todo el mundo te lo vende?

Antes de entrar en faena, explicación rápida para los que no sois programadores. RAG son las siglas de Retrieval Augmented Generation. Suena técnico, pero la idea es sencilla.

Tienes mucha documentación y quieres que una IA la use. Troceas esos documentos en pedacitos (chunks) y los conviertes en "vectores" que se guardan en una base de datos especial. Cuando le haces una pregunta a la IA, el sistema busca los trozos más parecidos a tu pregunta y se los pasa a la IA para que conteste.

Es lo que se llama búsqueda semántica. No busca por palabra exacta como hace Google. Busca por significado. Le preguntas "¿cómo arreglo esto?" y el sistema va a por trozos que hablen del problema aunque no usen esas palabras.

Y funciona de la hostia. Para lo que funciona.

Porque ahí está la clave. Y esto es lo que casi nadie te cuenta cuando te vende su solución de RAG o su curso de agentes.

¿Por qué el contexto completo casi siempre gana?

Yo tengo carpetas y carpetas de documentación. Tengo toda mi voz y tono en un documento. Tengo las reglas de cada skill. Tengo los clusters de contenido, el LORE, las referencias culturales, las reglas de coherencia. Todo escrito.

Si yo meto todo eso en una base de datos vectorial, cuando una skill necesita tirar de mi tono, lo que va a pasar es que el sistema va a buscar un par de trozos que le parezcan relevantes y me los va a devolver. Un chunk por aquí, otro por allá. Y ya está.

El problema es que mi tono no es un conjunto de trozos aislados. Mi tono es un documento entero que hay que entender en su conjunto. Cada regla conecta con otra. Las muletillas se explican con las expresiones prohibidas. El humor se calibra con la vulnerabilidad.

Si tú le traes cuatro chunks sueltos a la IA, te escribe algo que parece mi tono pero no lo es. Te escribe un Frankenstein. Y yo no quiero un Frankenstein. Yo quiero que la IA lea TODO el documento, lo entienda entero, y luego escriba.

No me vale con que tenga una pequeña parte que el sistema ha decidido que es importante. Yo necesito que tenga el contexto completo.

¿Cuándo sí tiene sentido RAG?

Ojo, que no estoy diciendo que las bases de datos vectoriales sean malas. Te lo digo por experiencia: son la hostia para lo que son.

RAG funciona genial cuando:

• Tienes muchísima información que no cabe en ninguna ventana de contexto, ni aunque le metas un millón de tokens.
• Cada respuesta depende solo de una parte concreta de esa información. Un chatbot de soporte técnico que te busca el artículo relevante, por ejemplo.
• No necesitas comprensión global, necesitas recuperación puntual. "¿Cómo reinicio el router?" → trae el trozo que habla de reiniciar el router. Fin.

En ese escenario, RAG es incluso más eficiente que cualquier otra cosa. No tiene sentido meter 10.000 páginas en una ventana de contexto cuando lo que necesitas es una respuesta que está en dos párrafos.

Pero mi caso no es ese. Y probablemente el tuyo tampoco, si lo que haces es parecido a lo mío.

El momento en el que todo cambió: ventanas de contexto gigantes

Hace un par de años esto era otra historia. Las ventanas de contexto eran pequeñitas. Meter documentación entera era imposible. Los tokens se disparaban. Trabajar así no era viable.

Por eso nacieron las bases de datos vectoriales tal y como las conocemos. No era un capricho. Era la única forma de trabajar con documentación extensa.

Pero ahora Claude Code puede tirar hasta un millón de tokens. Una barbaridad. Y aun así, a veces ni eso es suficiente. Prefieres guardarte esa ventana para pensar, razonar, escribir. No para cargar información que luego no vas a usar entera.

Y aquí es donde entra la jugada que me cambió todo.

Los subagentes son el verdadero trick

Cuando apareció toda la parte de subagentes y agent teams, fue la hostia. Y es aquí donde, para mí, la conversación sobre RAG pierde casi toda la relevancia.

El juego cambia. En lugar de meter toda la documentación en una base vectorial, tú mandas a subagentes a revisar partes concretas. Un orquestador principal coordina. Cada subagente tiene cargado en SU ventana de contexto una parte específica de la documentación. Entera. Completa. Sin trocear. Es una de las piezas clave de cómo funciona un consejo directivo de IA cuando lo quieres bien hecho.

Cuando el orquestador necesita algo de esa parte, le pregunta al subagente. El subagente responde con contexto completo de lo que ha leído. Y si el orquestador necesita profundizar, le sigue preguntando al mismo subagente, que ya tiene todo cargado en su cabeza.

¿El gasto de tokens? Mínimo. Porque ese subagente ya pagó el coste de cargar la documentación una vez, y desde ese momento responde casi gratis.

¿La diferencia con RAG? Que tú no estás recibiendo un chunk aislado decidido por una búsqueda semántica. Tú estás recibiendo la respuesta de alguien que se ha leído TODO el documento y te está contestando con ese contexto.

No es similar. No tiene nada que ver.

El ejemplo que me convenció del todo

Tengo una formación que son casi diez horas de contenido. Una locura. Pasar toda esa transcripción a una ventana de contexto, antes, era imposible. Y tampoco tenía sentido meterla en una base vectorial si yo quería preguntar algo como: "oye, ¿tiene sentido mover esta lección al módulo 3?".

Si hago eso con RAG, el sistema me busca esa lección y me dice "pues trata sobre X". Pero no te sabe decir dónde moverla. O peor: se la inventa. No tiene el contexto global de la formación para entender qué se da en cada parte y cómo se conecta todo.

Con subagentes sí. Un subagente carga el módulo 1 entero, otro el 2, y así. El orquestador les pregunta, monta el mapa completo, y te contesta: "con este contexto, tiene sentido moverla aquí por esto, esto y esto". Eso es lo que hace que funcione. Si prefieres el formato vídeo lo tienes aquí.

¿Significa esto que RAG está muerto? Ni de broma

Lo de siempre: no es blanco o negro. Cada herramienta funciona para lo que funciona.

RAG tiene todo el sentido del mundo para chatbots de atención al cliente, para motores de búsqueda internos, para aplicaciones donde necesitas recuperación rápida sobre bases de conocimiento enormes. Ahí es la mejor opción, sin discusión.

Pero cuando lo que necesitas es que la IA comprenda un cuerpo de documentación, lo tenga cargado entero, y trabaje sobre esa comprensión para generar algo nuevo, los subagentes con contexto completo le dan mil vueltas. Y lo mismo pasa con todo esto de los prompts y los límites de la IA: el contexto manda más que el prompt más bonito del mundo.

Lo otro es lo que yo llamo prostituir la herramienta: sacarla de su contexto natural para hacer cosas para las que no está diseñada, montando infraestructuras raras y flujos complejos simplemente porque está de moda. Habiendo una solución más fácil, no tiene sentido.

Si estás empezando a montar sistemas con IA y estás dudando entre una cosa y otra, hazte la pregunta clave: ¿necesito que la IA entienda todo, o necesito que recupere partes concretas? Si es lo primero, contexto completo. Si es lo segundo, RAG. Y si aún no te has decidido entre modelos, aquí tienes por qué dejé ChatGPT por Claude y cuándo uso cada uno.

Y si lo que quieres es ver cómo tengo yo montado todo esto, con agentes y subagentes orquestando mi documentación desde cero, te interesa esto más que cualquier tutorial genérico de RAG.

He montado mi Claude Code en un servidor al que le hablo desde Telegram. Aquí te dejo el setup entero.

Ver mi setup de Claude Code