La mayoría de los pipelines RAG se ven igual: chunkar el documento, embeddear cada chunk, guardar los vectores, y al momento de la consulta embeddear la pregunta y recuperar los top-k chunks más similares en coseno. PageIndex está haciendo algo diferente. En lugar de vectores, construye un índice de árbol jerárquico que refleja la tabla de contenidos del documento — cada nodo tiene un título, un resumen y un puntero al texto completo de la sección. La recuperación no es una búsqueda de similaridad. Es el LLM leyendo el árbol y razonando sobre qué nodos descender, para después buscar el texto completo solo en los que coinciden.
La apuesta arquitectónica es que "la similaridad es un proxy débil de la relevancia" una vez que tus consultas se vuelven complejas. Si le preguntas a un reporte financiero "¿por qué los autores eligieron self-attention sobre recurrencia, y cuáles son los compromisos de complejidad?", la búsqueda vectorial tiene que encontrar chunks cuyo embedding se parezca a la pregunta — y eso puede perder completamente el razonamiento entre secciones. El ejemplo de PageIndex camina por esto sobre el paper original del Transformer: el LLM mira el árbol, identifica que la sección de motivación Y la sección de análisis de complejidad son ambas relevantes, busca ambas, y ancla la respuesta en los lugares correctos. Ese tipo de síntesis multi-sección es donde el RAG vectorial falla en silencio y el usuario recibe una respuesta incorrecta con confianza.
El compromiso honesto es costo y estructura. Cada ronda de recuperación requiere que el LLM lea el resumen del árbol y razone sobre qué nodos abrir — eso es una llamada LLM por consulta, encima de la llamada de generación. La búsqueda vectorial es esencialmente gratis por consulta una vez construido el índice; PageIndex convierte la recuperación misma en una invocación de modelo. Si tus documentos son PDFs planos rascados de la web sin jerarquía clara, el árbol no va a ayudar. Si tus consultas son búsquedas simples ("¿cuál es el período de garantía?"), el overhead de razonamiento se desperdicia. El artículo de PageIndex no muestra números de benchmark contra baselines vectoriales en FinanceBench, no discute latencia ni cómo el índice maneja actualizaciones de documentos, y no compara costo por consulta. Esas son las preguntas que cualquier evaluación seria necesita.
Para desarrolladores trabajando con documentos largos estructurados — declaraciones financieras, contratos legales, papers de investigación, manuales técnicos — PageIndex merece una prueba real contra tu setup vectorial existente. La interpretabilidad por sí sola tiene valor: cuando la recuperación falla, puedes ver la cadena de razonamiento que eligió los nodos equivocados, en lugar de mirar scores de coseno opacos. Para todos los demás haciendo chatbot sobre docs de ayuda, el stack de embeddings existente es probablemente todavía la respuesta correcta. La frontera realmente interesante aquí no es "vectores contra razonamiento" como guerra de religión, sino saber qué forma de documento y qué patrón de consulta justifican qué arquitectura. PageIndex es una forma; los vectores son otra.