PageIndex de VectifyAI propose une recherche sans embeddings pour les longs documents

PageIndex est l'un des nouveaux prétendants les plus notables pour le rôle de 'RAG sans base de données vectorielle'. Au lieu du schéma familier avec embeddings et chunks, le système construit une table des matières hiérarchique pour le document avec des descriptions brèves des sections, puis demande à un LLM de sélectionner logiquement les nœuds pertinents et les pages associées. L'approche semble nouvelle et pour les longs PDF bien structurés peut fonctionner de manière plus proche de la façon dont un humain lit un document.

La mécanique de PageIndex est relativement simple. Le document est d'abord divisé par pages, après quoi le modèle et le code de support compilent une table des matières étendue — un arbre de sections avec des titres, des plages de pages et des résumés pour chaque nœud. Quand une question arrive, le prompt n'envoie pas tout le document ou un ensemble de chunks de texte aléatoires, mais plutôt cette structure elle-même. Le LLM sélectionne les branches pertinentes de l'arbre, et seules les pages qui y sont attachées sont alors substituées dans la requête finale.

En conséquence, le système fonctionne sans embeddings, sans stockage vectoriel et sans chunking artificiel, qui casse souvent le sens aux limites des fragments. C'est pourquoi il y a tant d'intérêt autour de PageIndex. Sur les longs rapports financiers, les documents juridiques, les manuels techniques et les matériels pédagogiques, une telle approche semble naturelle : les humains commencent généralement aussi par une table des matières plutôt que de parcourir le texte par morceaux.

Dans le référentiel du projet, les développeurs de VectifyAI positionnent directement le système comme une récupération basée sur le raisonnement et affirment que sur FinanceBench il a atteint une précision de 98,7%. Pour les équipes qui travaillent avec un seul grand document ou une petite collection de PDF complexes, cela semble être une forte alternative au pipeline RAG conventionnel, surtout si vous voulez une recherche plus interprétable avec des références claires aux sections et aux pages.

Mais la question principale n'est pas de savoir si la recherche vectorielle peut être remplacée par PageIndex, mais où cette approche atteint ses limites. La critique ici est plutôt pragmatique. Premièrement, la table des matières doit également être stockée quelque part, surtout s'il y a plus d'un document, donc parler d'« complètement sans index » est légèrement trompeur.

Deuxièmement, pour les grandes collections, il n'y a pas encore de stratégie convaincante de sélection de documents : les métadonnées, la recherche par mots-clés, TF-IDF et BM25 ne disparaissent pas et restent souvent un filtre initial bon marché. Troisièmement, la récupération par raisonnement est presque inévitablement plus coûteuse en tokens et plus lente en temps de réponse. Si un bon RAG vectoriel offre déjà environ 90% de qualité, les points de pourcentage supplémentaires de précision peuvent coûter plusieurs fois plus cher — et pour tout produit, ce n'est pas un échange raisonnable.

La pratique montre aussi des limitations. Dans les analyses, on note que PageIndex a eu de mauvaises performances avec un texte littéraire sans structure explicite : si un document n'a pas de sections ou de titres, il n'y a simplement rien pour construire une 'table des matières intelligente'. Les résultats ont été meilleurs avec un texte académique car il a une hiérarchie appropriée de sections. Vous pouvez exécuter le système localement via le référentiel ouvert : installez les dépendances, définissez une clé API pour un LLM compatible via LiteLLM, et exécutez un PDF ou markdown via run_pageindex.py.

Mais il y a des nuances ici aussi : l'auteur avertit séparément de la version de LiteLLM, déconseille d'installer le package pageindex cloud de pip pour le travail local, et décrit comment sur les modèles locaux faibles la qualité de l'arbre se dégrade notablement, et le processus lui-même peut prendre des dizaines de minutes même sur un document relativement petit.

Qu'est-ce que cela signifie en pratique ? PageIndex ne ressemble pas à un tueur de recherche vectorielle, mais ressemble à une nouvelle couche utile dans l'architecture RAG. La façon la plus logique de le considérer est non pas comme un remplacement direct, mais comme un outil spécialisé pour les longs documents structurés où l'explicabilité, la précision de la navigation et le traitement page par page comptent.

Le scénario le plus réaliste est hybride : d'abord une recherche bon marché par métadonnées ou vecteurs, puis PageIndex pour une sélection précise des sections. Un tel compromis reflète mieux la réalité : il n'y a pas encore de remplacement universel au RAG vectoriel, mais les approches document-first comme PageIndex ont déjà leur propre niche bien définie.