RAG sin vectores: cómo busca información un chatbot y si necesitas una base de datos vectorial

Durante dos años, la respuesta a «¿cómo hago que un chatbot responda con mis datos?» fue siempre la misma: trocea tus documentos en fragmentos, conviertes cada uno en números y guardas esos números en una base de datos vectorial. A mediados de 2026, una oleada de publicaciones declaró muerto ese paso. «RAG sin vectores.» «Ya no necesitas una base de datos vectorial.» «El RAG ha muerto.»

Nos dedicamos a construir chatbots con IA, así que leímos los trabajos de verdad, echamos las cuentas y miramos más allá de los titulares —lo mismo que hicimos al analizar PixelRAG—. Esta es la versión honesta para quien tiene que decidir qué construir: qué es una base de datos vectorial, cómo busca información un chatbot en realidad, qué es eso del «RAG sin vectores» y la pregunta práctica que hay debajo de todo el ruido: ¿la necesitas tú? Con las cifras reales, no las virales.

Qué es una base de datos vectorial (y qué son los embeddings)

Empecemos por la pieza que todo el mundo quiere quitar, porque para saber si sobra hay que saber qué hace. Un embedding es una forma de convertir texto en un punto en el espacio. El modelo lee «chaqueta impermeable» y devuelve una lista larga de números —pongamos 1.536— que fijan esa frase en una coordenada concreta. «Chubasquero» cae cerca porque significa algo parecido; «motor diésel» cae lejos. Todo el truco es que cerca en ese espacio ≈ cerca en significado.

Una base de datos vectorial (Pinecone, Weaviate, Qdrant, o pgvector sobre PostgreSQL, entre otras) es un almacén optimizado para guardar millones de esos puntos y, dado uno nuevo, devolver los más cercanos en milisegundos. Eso es todo. Es una herramienta muy buena para un trabajo concreto: emparejar por significado, de forma difusa, sobre un montón de texto cuando no sabes las palabras exactas que va a teclear el usuario.

También es donde vive buena parte del coste, la complejidad y los fallos del RAG: un troceo que parte una tabla por la mitad, un índice que hay que mantener sincronizado y la suposición de fondo de que parecido es igual a relevante. Y de ahí nace el argumento del «sin vectores». En muchos casos reales, buscar lo más parecido no lleva a la respuesta correcta, así que montar y mantener toda esa infraestructura no compensa.

Cómo busca información un chatbot con IA (RAG en 60 segundos)

Este es el proceso estándar que mueve a la inmensa mayoría de chatbots con IA de hoy, el nuestro incluido:

1. Trocear. Tus documentos —un PDF, una web, un catálogo— se parten en fragmentos de texto, los llamados chunks.
2. Convertir a vector (embedding). Cada fragmento pasa por un modelo que lo convierte en una lista de números que captura su significado. Dos fragmentos sobre la misma idea acaban con números parecidos, aunque usen palabras distintas.
3. Guardar. Esos vectores van a una base de datos vectorial pensada para encontrar vecinos cercanos deprisa.
4. Recuperar. Cuando un cliente pregunta algo, su pregunta también se convierte en vector, y la base devuelve los fragmentos cuyos vectores están más cerca.
5. Generar. Esos fragmentos se le pasan al modelo de lenguaje, que redacta la respuesta apoyándose en ellos.

La base de datos vectorial vive en los pasos 3 y 4. Existe para responder rápido a una pregunta: ¿cuáles de mis miles de fragmentos se parecen más, en significado, a esta consulta? Los enfoques sin vectores sostienen que «el que más se parece» es muchas veces la pregunta equivocada, y que un modelo de lenguaje, si le das la estructura del documento o una herramienta de búsqueda, encuentra mejor la parte que de verdad importa.

Búsqueda semántica vs búsqueda por palabras clave

Esta es la línea de fractura de todo el debate, así que merece un ejemplo sencillo. Misma base de conocimiento, misma pregunta, dos maneras de encontrar la respuesta:

Ninguna es mejor en absoluto. La semántica brilla cuando las palabras del usuario no coinciden con las de tu documento. La búsqueda por palabras clave o estructurada brilla cuando la respuesta depende de un valor exacto: un precio, una talla, una referencia, una fecha. El error de estos dos años fue tratar los vectores como la opción por defecto para todo, incluidas preguntas donde un simple filtro habría sido más rápido, más barato y más preciso.

Qué es el RAG sin vectores

RAG sin vectores es recuperar sin base de datos vectorial. En vez de convertir tus documentos en vectores y buscar por parecido matemático, el sistema usa la propia estructura del documento —o una búsqueda por palabras clave— y deja que un modelo de lenguaje razone cuál es la parte que de verdad importa.

El ejemplo estrella es PageIndex, de VectifyAI. Construye un índice en árbol tipo «tabla de contenidos» a partir de un documento largo y, cuando llega una pregunta, un modelo recorre ese árbol como una persona hojea un informe —«esto es un balance financiero, la respuesta estará en la sección de liquidez, hacia la página 40»— y saca la sección correcta. Sin trocear, sin embeddings, sin base vectorial. Su lema resume la idea: parecido no es lo mismo que relevante.

Hay una segunda variante aún más simple: darle a un agente de IA una herramienta de búsqueda por palabras clave (la búsqueda de texto de toda la vida) y dejar que busque, lea, afine y vuelva a buscar en bucle. Así navegan el código los agentes de programación como Claude Code o Cursor: buscan texto, no crean embeddings. Un trabajo reciente de investigadores de Amazon le puso número (lo vemos más abajo).

¿Ha muerto el RAG? Qué dice de verdad el debate

Respuesta corta: no. Lo que se cuestiona no es «apoyar un modelo en tus datos» —eso es más relevante que nunca—, sino una implementación concreta: trocearlo todo, convertirlo en vectores y buscar por parecido. Tres hilos alimentaron la ola del «RAG ha muerto», y cada uno dice algo más estrecho que el titular:

• Ventanas de contexto más grandes. Los modelos aceptan entradas enormes, así que para una base de conocimiento pequeña a veces puedes pegarlo todo y saltarte la recuperación. Esto se rompe a escala y sale caro, y choca con el punto siguiente.
• Degradación de contexto. La investigación de Chroma mostró que la precisión del modelo empeora según crece la entrada, mucho antes de llenar la ventana. O sea que pegarlo todo no sale gratis: el modelo responde peor cuanto más le metes. Por eso la degradación de contexto, bien mirada, es un argumento para recuperar mejor la información, no para dejar de recuperarla.
• Búsqueda agéntica. Si le das a un modelo capaz una herramienta de búsqueda y le dejas consultar en bucle, muchas veces gana a una única búsqueda por vectores. Aquí está la sustancia real del RAG sin vectores.

Así que lo honesto no es «el RAG ha muerto», sino «se acaba la época de meter una base vectorial por reflejo a todo». La recuperación está viva; lo que se apaga es el monocultivo de un solo método.

Cómo funciona el RAG sin vectores por dentro

Tomemos PageIndex como ejemplo concreto. En vez de trocear y convertir a vectores, hace esto:

1. Construir un árbol. Genera un índice jerárquico tipo tabla de contenidos del documento —secciones, subsecciones, anclas de página— que refleja cómo está organizado de verdad.
2. Razonar sobre el árbol. Cuando llega una pregunta, un modelo hace una búsqueda por el árbol: mira la estructura y decide qué rama tiene probablemente la respuesta, navegando como quien ojea un informe, en vez de comparar vectores.
3. Recuperar la sección relevante. Saca la sección a la que ha llegado razonando, y el modelo responde a partir de ahí.

La variante de agente con palabras clave se salta incluso el árbol: el agente lanza búsquedas de texto, lee los resultados y afina su consulta hasta tener lo que necesita. El mismo bucle que usa una persona con un buscador.

¿Necesitas una base de datos vectorial? Guía de decisión

Olvida la ideología. Repasa estas y cuenta dónde caes:

• Mayoría de síes: la base vectorial se sigue ganando su sitio. La búsqueda semántica sobre un corpus grande y desordenado es exactamente su terreno. Consérvala.
• A medias: probablemente quieres un enfoque híbrido —búsqueda por palabras clave o estructurada para lo exacto, vectores para lo difuso—. La mayoría de sistemas serios ya combinan ambos.
• Mayoría de noes: si tus datos tienen estructura clara (documentos bien organizados) o tus preguntas dependen de valores exactos (catálogos, registros, filtros), el enfoque sin vectores —un árbol de razonamiento o una búsqueda estructurada— puede ser más simple, más barato y más preciso.

Con vectores vs sin vectores: tabla honesta

La fila que más pesa es la última: el RAG con vectores es una cantidad conocida; el sin vectores es prometedor pero joven, y casi todas sus cifras ganadoras vienen de quien lo vende. No es motivo para ignorarlo, sino para probarlo contra tus propios datos en vez de contra un titular.

Qué significa esto para el chatbot de tu empresa

Aquí está la parte que el debate suele saltarse: la mayoría de chatbots de empresa nunca necesitaron búsqueda vectorial pura. Un chatbot de tienda que responde «chaquetas impermeables de menos de 80 € en talla L» no es un problema de parecido: es un filtro. La respuesta correcta es una búsqueda estructurada sobre tu catálogo (precio, talla, stock), no el vector más cercano a la frase. Lo desarrollamos en nuestra guía sobre por qué tu chatbot no encuentra productos.

En Bravos AI ya usamos un enfoque híbrido: búsqueda estructurada, tipo base de datos, para catálogos y preguntas de valor exacto, y recuperación semántica para el texto libre como preguntas frecuentes, políticas y descripciones de servicios. La conversación «sin vectores» no nos pilló por sorpresa, porque la lección de fondo —ajusta el método de búsqueda a la pregunta, no fuerces vectores para todo— es como debería haberse construido un buen sistema desde el principio. Si tu chatbot responde sobre todo sobre un catálogo o registros estructurados, la base vectorial nunca fue lo importante.

El veredicto, en una línea

El RAG sin vectores es una corrección real y útil a dos años de abusar de las bases vectoriales, no la muerte del RAG. Para documentos estructurados y preguntas de valor exacto puede ser más simple, más barato y más preciso; para corpus grandes, difusos y de significado, una base vectorial se sigue ganando su sitio. La pregunta correcta nunca fue «vectores sí o no», sino «qué recuperación encaja con esta pregunta». Si alguien te dice que un método gana siempre, está vendiendo, no haciendo ingeniería.

Preguntas frecuentes

¿Qué es el RAG sin vectores en pocas palabras?

Es la generación aumentada por recuperación (RAG) sin base de datos vectorial. En vez de convertir tus documentos en embeddings y buscar por parecido, el sistema usa la estructura del documento (un árbol de razonamiento, como PageIndex) o una búsqueda por palabras clave, y deja que un modelo de lenguaje razone qué parte es de verdad relevante. El lema es «parecido no es lo mismo que relevante».

¿Necesito todavía una base de datos vectorial para RAG en 2026?

Depende de tus preguntas. Para corpus grandes y sin estructura donde los usuarios preguntan de forma difusa y por significado, sí: la búsqueda por vectores es justo para lo que está pensada. Para documentos bien estructurados o preguntas que dependen de valores exactos (catálogos, registros, filtros), puede que no, y un enfoque sin vectores o híbrido sale más simple y barato. Muchos sistemas en producción usan los dos.

¿Qué es una base de datos vectorial?

Es un almacén optimizado para guardar millones de embeddings (representaciones numéricas del significado del texto) y, dada una consulta, devolver los más parecidos en milisegundos. Es la pieza que permite la búsqueda semántica en el RAG clásico. Ejemplos: Pinecone, Weaviate, Qdrant o pgvector sobre PostgreSQL.

¿Ha muerto el RAG?

No. Apoyar un modelo en tus propios datos es más relevante que nunca. Lo que se apaga es el reflejo de trocear y convertir todo en vectores por defecto. La recuperación está viva; lo que se cuestiona es el método único para todo.

¿Qué es PageIndex?

PageIndex (de VectifyAI) es un sistema de RAG sin vectores, basado en razonamiento. Construye un árbol jerárquico tipo tabla de contenidos a partir de un documento y usa un modelo de lenguaje para navegarlo, sin embeddings, sin trocear y sin base vectorial. Sus autores declaran un 98,7% de acierto en el benchmark FinanceBench, una cifra del propio fabricante, así que conviene comprobarla contra tus datos.

RAG sin vectores vs RAG con vectores, ¿cuál es mejor?

Ninguno gana en absoluto. El RAG con vectores es maduro, rápido y fuerte en emparejar por significado sobre corpus grandes. El sin vectores es más nuevo y fuerte en documentos estructurados y preguntas de valor exacto, con infraestructura más simple pero más coste de razonamiento por consulta. Para la mayoría de empresas, lo mejor es un enfoque híbrido que mande cada pregunta al método que le encaja.

Fuentes

• PageIndex (VectifyAI): github.com/VectifyAI/PageIndex — RAG sin vectores, basado en razonamiento; 98,7% en FinanceBench (cifra del fabricante).
• «Keyword search is all you need»: Subramanian et al., arXiv:2602.23368 — la búsqueda agéntica por palabras clave alcanza más del 90% del rendimiento del RAG tradicional sin base vectorial.
• Context Rot (Chroma): research.trychroma.com/context-rot — la precisión del modelo empeora según crece el contexto.