A maioria dos pipelines RAG se parecem: chunkar o documento, embedar cada chunk, armazenar os vetores, e na hora da consulta embedar a pergunta e recuperar os top-k chunks mais similares em cosseno. PageIndex está fazendo algo diferente. Em vez de vetores, ele constrói um índice em árvore hierárquica que espelha o sumário do documento — cada nó tem um título, um resumo e um ponteiro para o texto completo da seção. A recuperação não é uma busca de similaridade. É o LLM lendo a árvore e raciocinando sobre quais nós descer, e então buscando o texto completo só nos que combinam.
A aposta arquitetônica é que "similaridade é um proxy fraco para relevância" quando suas consultas ficam complexas. Se você pergunta a um relatório financeiro "por que os autores escolheram self-attention em vez de recorrência, e quais são os trade-offs de complexidade", a busca vetorial precisa achar chunks cujo embedding se pareça com a pergunta — e isso pode perder o raciocínio entre seções por completo. O exemplo do PageIndex caminha por isso no paper original do Transformer: o LLM olha a árvore, identifica que a seção de motivação E a seção de análise de complexidade são ambas relevantes, busca ambas, e ancora a resposta nos lugares certos. Esse tipo de síntese multi-seção é onde o RAG vetorial falha silenciosamente e o usuário recebe uma resposta errada com confiança.
O trade-off honesto é custo e estrutura. Cada rodada de recuperação requer que o LLM leia o resumo da árvore e raciocine sobre quais nós abrir — isso é uma chamada LLM por consulta, em cima da chamada de geração. Busca vetorial é essencialmente grátis por consulta uma vez que o índice é construído; PageIndex transforma a recuperação em si numa invocação de modelo. Se seus documentos são PDFs planos raspados da web sem hierarquia clara, a árvore não vai ajudar. Se suas consultas são lookups simples ("qual é o período de garantia?"), o overhead de raciocínio é desperdiçado. O artigo do PageIndex não mostra números de benchmark contra baselines vetoriais no FinanceBench, não discute latência nem como o índice lida com atualizações de documentos, e não compara custo por consulta. Essas são as perguntas que qualquer avaliação séria precisa.
Para desenvolvedores trabalhando em documentos longos estruturados — declarações financeiras, contratos legais, papers de pesquisa, manuais técnicos — PageIndex merece um teste real contra seu setup vetorial existente. A interpretabilidade sozinha tem valor: quando a recuperação falha, você pode ver a cadeia de raciocínio que escolheu os nós errados, em vez de encarar scores de cosseno opacos. Para todo o resto fazendo chatbot sobre docs de ajuda, o stack de embeddings existente provavelmente ainda é a resposta certa. A fronteira realmente interessante aqui não é "vetores contra raciocínio" como guerra de religião, mas saber qual forma de documento e qual padrão de consulta justificam qual arquitetura. PageIndex é uma forma; vetores são outra.