Por qué no uso RAG ni bases de datos vectoriales en IA

Te dejo el vídeo arriba, pero aquí lo tienes escrito y con calma, que este va un poco más técnico de lo normal.

Cada vez que enseño cómo tengo montado mi sistema de documentación, mis agentes y toda la historia con Claude Code, la misma pregunta: "¿Por qué no usas RAG? ¿Por qué no montas una base de datos vectorial?". Y luego llegan los de siempre con el "si descubrieras las bases de datos vectoriales te explotaría la cabeza".

Pues no. Las conozco, las he usado bastante. Y justo por eso, para lo que hago yo, no las uso. No porque no sepa, sino porque no tienen sentido aquí.

Deja que me explique antes de que bajes a los comentarios a insultarme.

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

RAG es coger tu documentación, partirla en trozos (los famosos chunks), convertir esos trozos en vectores y meterlos en una base de datos. Cuando le preguntas algo a la IA, hace una búsqueda semántica y se trae el trozo (o los trozos) que más se parecen a tu pregunta.

Es rápido. Es barato en tokens. Y para muchísimas cosas funciona de maravilla.

¿De dónde viene todo esto? De un problema muy real de hace nada: las ventanas de contexto eran pequeñas. No cabía mucha información. Y si trabajabas por API, el consumo de tokens se te disparaba. Así que en vez de meterle todo, le metías solo el trozo que hacía falta para responder. Lógico.

El problema es que la gente lo ha convertido en la respuesta por defecto para todo. Y no lo es.

La pregunta que decide todo: ¿cuánta información necesitas de verdad?

No me voy a meter en mil vainas técnicas, pero si te quedas con una cosa que sea esta: lo que decide si usas una base de datos vectorial o no es cuánta información necesitas y por qué.

Y esto es clave con absolutamente todo.

Cuando trabajas con una base de datos vectorial, te traes un chunk concreto. Uno o varios. Los que la búsqueda semántica ha decidido que encajan con tu pregunta. El resto de la información, la que no ha entrado en ese trozo, la pierdes.

Para muchas cosas da igual. Para otras, la lías.

Te lo enseño con mi proyecto. Yo tengo un montón de carpetas con documentación de cómo tengo montada cada cosa. Y no es documentación suelta. No es algo que pueda coger, trocear en chunks y mandar a una base de datos vectorial, porque perdería toda la potencia que me da trabajar así.

Por qué el contexto completo gana cuando necesitas comprensión

Imagínate mi documento de tono. Es cómo funciono yo escribiendo, cómo suena lo que hago.

Si yo tuviera ese documento troceado en una base de datos vectorial, lo que no podría hacer es traérmelo entero. Y cuando tengo una skill que necesita tirar de mi tono, necesito que se lo lea todo. Entero. Que lo entienda a la perfección. No me vale con una parte que la búsqueda semántica ha decidido que era la relevante, porque cada parte de ese documento importa. No necesito un trozo. Necesito el contexto completo.

Y esto pasa con un montón de archivos.

La clave de trabajar con skills es que cada skill decide a qué documentos ataca. Qué carpetas mira, qué información recoge, de dónde. Cada skill está acotada a una parte de la documentación. No es que una skill toque todo, porque eso sería terrible. Es que sabe exactamente qué mirar.

Por eso, por mucho que esto crezca, no pasa nada. Aunque tuviera 100.000 documentos, daría igual. Porque en cada skill ya le estoy diciendo qué contexto base tiene que tener y a qué archivos puede mirar. Ahí está toda la gracia.

¿Y dónde entran los subagentes?

Aquí es donde la cosa se dispara. Antes montar esto era una barbaridad, precisamente por las ventanas de contexto pequeñas. Ahora Claude Code puede tirar hasta un millón de tokens, que es una bestialidad. Pero aun así, a veces no llega, porque hay que mirar demasiadas cosas.

Y yo prefiero guardarme esa ventana de contexto para hacer el trabajo, no para almacenar información y entenderla.

Ahí es donde entran los subagentes. En vez de traerme un chunk, mando subagentes a revisar partes de la documentación. Cada uno entiende su parte entera, con todo su contexto. Y están conectados a un agente orquestador, que es quien recibe la información de cada uno.

El orquestador les va pidiendo: "Tú, dime de qué va tu parte. Tú, dime de la tuya". Cada uno le chuta sus datos. Y lo bueno es que esos subagentes siguen abiertos: si en un momento el orquestador necesita algo más concreto, se lo pregunta al subagente y este se lo devuelve, ya con un gasto de tokens mínimo, porque ese subagente ya tiene cargado en su contexto todo lo que tiene que tener.

Y me dirás: "Rubén, pero esto suena igual que RAG". No es igual para nada.

En una tienes comprensión de todo el contexto. En la otra consultas un trozo por búsqueda semántica y te pierdes el resto de la información que también te podría dar la respuesta. Es la diferencia entre entender algo y buscar una frase suelta.

Un ejemplo que ya conté por aquí. Le pasé la transcripción de uno de mis cursos, que tiene casi diez horas de contenido. Una locura. Eso, en las ventanas de contexto de antes, era imposible.

Y si yo le pregunto si tiene sentido mover una lección de sitio, con RAG la lío. Me busca esa lección, me dice de qué trata y ya. O se inventa dónde moverla, porque no tiene la información completa de toda la formación como para entender qué se da en cada parte y por qué. Con contexto completo, en cambio, me dice: "Con todo lo que sé de esta formación, yo creo que esta lección va mejor aquí por esto, esto y esto". Eso solo lo hace si lo entiende todo.

¿Cuándo sí tiene sentido usar RAG?

No es blanco ni negro. Las bases de datos vectoriales tienen sentido, pero para otras cosas.

Cuando trabajas con un chatbot que tiene que dar una respuesta y ya, sobre una información concreta, es suficiente con una base de datos vectorial. Es incluso lo más eficiente, con mucha diferencia. Si lo que necesitas es consultar un dato y hacer algo con él, no le des mil vueltas.

RAG brilla ahí: rapidez, búsquedas, chatbots, mil cosas más. Funciona genial.

El problema es sacarlo de su contexto. Cuando coges una herramienta y la sacas de para lo que está pensada (lo que yo llamo prostituir una herramienta), sí, eres capaz de hacer cosas para las que no está diseñada. Pero si hay una solución más fácil, no tiene sentido volverse loco montando infraestructuras raras con flujos complejos para algo que no lo pide.

Que una tecnología exista o esté de moda no significa que sea buena para todo. Significa que funciona para lo que funciona. Y hay que usarla para eso.

Si quieres el otro lado de esto, te dejé montado el sistema de subagentes de Claude Code paso a paso y por qué el contexto es lo que más cambia tus resultados. Con esas dos piezas se entiende mejor por dónde va todo lo de la automatización y los agentes con IA.

Las herramientas que uso

Nada raro, la verdad:

• Claude Code: es donde tengo montado todo el sistema de documentación, skills y subagentes.
• Gemini CLI: alternativa a Claude Code. Todo lo que hago se puede migrar aquí.
• Codex: otra alternativa, misma idea, distinta casa.
• grep: la búsqueda de toda la vida en los archivos. Sí, en vez de búsqueda vectorial, grep. Y funciona.

Lo importante no es la herramienta concreta. Es entender qué necesitas antes de decidir con qué lo montas.

Si quieres ver cómo tengo montado todo este sistema por dentro (sin ser técnico, para cualquiera), lo cuento entero en YO S.A.: cómo gestiono la documentación, empezando por herramientas baratas y saltando luego a Claude Code, Gemini CLI o Codex, como prefieras.