BookinglyTech News
Inteligencia artificial

RAG sin vectores: navegar la estructura del documento en lugar de trocearlo

Un desarrollador propone sustituir la búsqueda por similitud vectorial por un recorrido del árbol de secciones, con un LLM decidiendo por dónde bajar. No hay producto ni versión detrás.

2 min de lecturaDev.to0 vistas

Un desarrollador ha puesto por escrito una idea que lleva tiempo circulando entre equipos que trabajan con recuperación aumentada: dejar de trocear el documento y buscar por similitud vectorial, y en su lugar recorrer su estructura como quien hojea un libro. Lo llama RAG sin vectores. No hay versión, ni producto, ni repositorio que lo implemente; es un texto de blog, y el autor lo aprovecha para promocionar su propia herramienta de revisión de código.

El punto de partida es el RAG que casi todo el mundo despliega: partir el documento en fragmentos, convertir cada uno en un embedding, guardarlos en una base de datos vectorial y recuperar el más cercano a la consulta. Funciona en bastantes casos, pero el autor señala tres grietas. La primera es que el troceado separa información que va junta: un número puede acabar desligado de la frase que lo explica. La segunda es que similitud no es lo mismo que relevancia, y el fragmento semánticamente más parecido no tiene por qué ser el que responde. La tercera es que la puntuación de similitud no dice por qué se eligió ese fragmento, algo que pesa cuando hace falta trazabilidad.

Del índice al razonamiento

La propuesta cambia el mecanismo de recuperación por completo. En vez de aplanar el documento en trozos sueltos, se modela como una jerarquía: capítulos, secciones, subsecciones. Cada rama de ese árbol lleva un resumen corto de lo que contiene. Sobre esa estructura trabaja un LLM que razona paso a paso dónde puede estar la respuesta y va bajando por la rama correcta. Cuando llega al final, el sistema sabe de qué página o sección salió el dato, así que la respuesta se puede rastrear hasta su origen.

El cambio de fondo está en de dónde sale el coste. Un pipeline vectorial gasta sobre todo en infraestructura: almacenar y consultar vectores. Aquí el gasto se desplaza a la inferencia, porque hay un modelo razonando en cada consulta. El propio autor reconoce dos límites: los enfoques que dependen de la estructura sufren con datos que no la tienen, y no plantea sustituir la búsqueda vectorial, sino combinarla según el caso.

Conviene leerlo con la expectativa ajustada. No hay implementación de referencia, ni comparativa, ni un solo número de latencia o precisión: son ideas y nombres para piezas que otros equipos ya están montando por su cuenta. Sirve, eso sí, para ordenar el vocabulario de un patrón que va a aparecer cada vez más en sistemas que trabajan con documentación larga y regulada, donde el motivo de una recuperación importa tanto como el texto recuperado. Lo que no hay, de momento, es nada que desplegar.