VectifyAI/PageIndex es un proyecto RAG interesante. No parte de “crear otra base de datos vectorial”, sino que primero organiza documentos largos en una estructura de árbol similar a una tabla de contenidos, y luego deja que un LLM haga recuperación basada en razonamiento siguiendo ese árbol.
Proyecto: VectifyAI/PageIndex
En el momento de preparar este artículo, la página de GitHub muestra unas 31.8k stars y 2.7k forks, con licencia MIT. El README lo define como Vectorless, Reasoning-based RAG: RAG sin base vectorial y basado en razonamiento.
Qué problema intenta resolver
El flujo común del RAG tradicional es: dividir en chunks, vectorizar, escribir en una base de datos vectorial y recuperar fragmentos mediante búsqueda por similitud. Es un enfoque simple, general y maduro, pero en documentos profesionales largos suele encontrar varios problemas:
- La similitud no equivale a relevancia real.
- La estructura del documento se rompe por el chunking, y se pierden relaciones entre secciones.
- Los resultados de recuperación tienen poca explicabilidad; cuesta explicar por qué se eligió ese fragmento.
- En informes financieros, documentos regulatorios, textos legales o manuales técnicos, las preguntas suelen requerir razonamiento entre secciones.
La idea de PageIndex es la inversa: primero organizar el documento como un árbol semántico, y después hacer que el modelo busque como una persona que lee el índice, entra en capítulos y localiza información por niveles.
Flujo básico de PageIndex
El README divide la recuperación de PageIndex en dos pasos:
- Generar para el documento un índice en árbol parecido a
Table-of-Contents. - Hacer reasoning-based retrieval mediante búsqueda en árbol.
Este árbol no es un simple directorio de archivos, sino una estructura documental pensada para LLMs. Los nodos pueden incluir títulos, rangos de páginas, resúmenes, nodos hijos y otros datos. Así, al responder una pregunta, el modelo no tiene que enfrentarse de entrada a una gran cantidad de chunks sueltos; primero puede decidir a qué sección entrar y luego seguir buscando hacia abajo.
Este enfoque encaja mejor con documentos bien estructurados pero muy largos, como:
- Informes financieros y SEC filings.
- Material regulatorio y documentos de cumplimiento.
- Libros académicos y papers.
- Documentos legales.
- Manuales técnicos y documentación de producto.
- PDFs grandes que superan la ventana de contexto del modelo.
Diferencias con el RAG vectorial tradicional
Los principales puntos de PageIndex se pueden resumir en cinco.
Primero, no necesita Vector DB. Usa estructura documental y razonamiento del LLM para localizar contenido, en lugar de depender solo de búsqueda por similitud vectorial.
Segundo, no usa chunking tradicional. Los documentos se organizan por secciones naturales, no por fragmentos de longitud fija.
Tercero, ofrece mejor explicabilidad. La ruta de recuperación puede asociarse con páginas, secciones y nodos del árbol, lo que es más fácil de rastrear que “este texto fue encontrado por similitud vectorial”.
Cuarto, la recuperación es sensible al contexto. La pregunta, el historial de conversación y el conocimiento del dominio pueden influir en la ruta de búsqueda por árbol.
Quinto, se parece más a cómo los expertos humanos leen documentos. Normalmente no cortamos un documento entero en trozos para calcular similitud; primero revisamos el índice, ubicamos capítulos y luego leemos detalles.
Esto no significa que las bases vectoriales no tengan valor. Una forma más precisa de verlo es que PageIndex encaja en escenarios donde “la similitud semántica no basta y se necesita estructura más razonamiento” para recuperar información en documentos largos.
Cómo ejecutarlo localmente
El README ofrece una ruta de autoalojamiento local. Primero instala dependencias:
|
|
Después crea un archivo .env en la raíz del proyecto y escribe la LLM API key. El proyecto admite múltiples modelos mediante LiteLLM:
|
|
Genera la estructura PageIndex para un PDF:
|
|
También puede procesar Markdown:
|
|
Parámetros opcionales habituales:
|
|
El README también advierte que la versión local de código abierto usa parsing PDF estándar. Para PDFs complejos, el servicio cloud del proyecto ofrece OCR mejorado, construcción de árbol y flujo de recuperación.
Ejemplo de Agentic Vectorless RAG
El proyecto también incluye un ejemplo de agentic vectorless RAG usando PageIndex autoalojado y OpenAI Agents SDK. Instala la dependencia opcional y ejecútalo:
|
|
El valor de este ejemplo está en que lleva PageIndex de “generar un árbol documental” a “permitir que un Agent use el árbol para recuperar información”. Si estás construyendo una base de conocimiento empresarial, Q&A sobre informes financieros, preguntas regulatorias o un Agent de documentación técnica, vale más la pena correr este ejemplo que limitarse a leer el README.
Servicio cloud, MCP y API
PageIndex no es solo un GitHub repo. La página del proyecto también ofrece varias entradas:
- Autoalojamiento: ejecutar el código abierto en local, adecuado para pruebas y despliegues controlados.
- Chat Platform: una plataforma de análisis documental estilo ChatGPT.
- MCP / API: útil para integrarse con Agents existentes o flujos de automatización.
- Enterprise: orientado a despliegues privados u on-premises.
Esto muestra que su posición no es la de una simple demo. Busca convertir la “recuperación documental basada en razonamiento” en una infraestructura de inteligencia documental integrable.
Escenarios adecuados
PageIndex encaja bien con tareas como:
- Preguntas y respuestas sobre PDFs largos.
- Análisis de informes financieros, informes anuales, prospectos y documentos regulatorios.
- Recuperación en documentos legales y de cumplimiento.
- Q&A sobre manuales técnicos.
- Recuperación en libros o papers con múltiples secciones.
- Bases de conocimiento empresariales que necesitan rutas de recuperación explicables.
- Proporcionar contexto documental estructurado a Agents.
Si tu material es corto, tiene poca estructura o es simplemente un FAQ común, embedding + vector DB tradicional puede ser suficiente. Las ventajas de PageIndex aparecen con más claridad en documentos largos, estructura fuerte, dominios profesionales y preguntas que requieren razonamiento.
Aspectos a tener en cuenta
Primero, PageIndex sigue dependiendo de LLMs. La construcción del árbol, los resúmenes y la calidad de recuperación se ven afectados por la capacidad del modelo, los prompts y la calidad del parsing documental.
Segundo, la versión local usa parsing PDF estándar. Documentos escaneados complejos, PDFs con muchas tablas y gráficos, o materiales con maquetación desordenada pueden requerir OCR y preprocesamiento más potente.
Tercero, sin base vectorial no significa coste cero. Construir el árbol también consume llamadas al modelo y tiempo, especialmente en colecciones documentales grandes.
Cuarto, PageIndex se parece más a un marco de indexación estructural y recuperación por razonamiento. No reemplaza directamente todas las pilas RAG. En producción, también puede combinarse con recuperación vectorial, búsqueda por palabras clave, control de permisos, caché y sistemas de auditoría.
Resumen
Lo interesante de PageIndex es que desplaza el foco del RAG desde la “recuperación por similitud textual” hacia “estructura documental + razonamiento LLM”. Para documentos largos y profesionales, esta dirección merece atención.
Si estás construyendo Q&A documental empresarial, análisis de informes financieros, recuperación regulatoria o Agents para manuales técnicos, PageIndex puede servir como referencia de una nueva arquitectura RAG: primero dar estructura al documento y luego dejar que el modelo razone sobre esa estructura, en lugar de trocear todo desde el principio y meterlo en una base vectorial.
Referencias: