La plupart des pipelines RAG se ressemblent : chunker le document, embedder chaque chunk, stocker les vecteurs, pis au moment de la requête embedder la question et récupérer les top-k chunks les plus proches en cosinus. PageIndex fait autre chose. Au lieu des vecteurs, il bâtit un index en arbre hiérarchique qui suit la table des matières du document — chaque nœud a un titre, un résumé pis un pointeur vers le texte complet de la section. La récupération, c'est pas une recherche de similarité. C'est le LLM qui lit l'arbre pis raisonne sur les nœuds à explorer, pour ensuite chercher le texte complet juste dans ceux qui matchent.
Le pari architectural, c'est que « la similarité est une faible approximation de la pertinence » dès que tes requêtes deviennent complexes. Si tu demandes à un rapport financier « pourquoi les auteurs ont choisi le self-attention au lieu de la récurrence, pis quels sont les compromis de complexité », la recherche vectorielle doit trouver des chunks dont l'embedding ressemble à la question — pis ça peut complètement manquer le raisonnement entre sections. L'exemple de PageIndex marche sur le papier original Transformer : le LLM regarde l'arbre, identifie que la section motivation ET la section analyse de complexité sont pertinentes toutes les deux, va chercher les deux, pis ancre la réponse aux bons endroits. C'est ce genre de synthèse multi-sections où le RAG vectoriel échoue en silence pis l'utilisateur reçoit juste une mauvaise réponse confiante.
Le compromis honnête, c'est le coût pis la structure. Chaque tour de récupération demande au LLM de lire le résumé de l'arbre pis de raisonner sur quels nœuds ouvrir — ça fait un appel LLM par requête, par-dessus l'appel de génération. La recherche vectorielle est essentiellement gratuite par requête une fois l'index construit ; PageIndex transforme la récupération elle-même en invocation de modèle. Si tes documents sont des PDF plats grattés du web sans hiérarchie claire, l'arbre va pas aider. Si tes requêtes sont des recherches simples (« quelle est la durée de garantie »), le surcoût de raisonnement est gaspillé. L'article de PageIndex montre pas de chiffres de benchmark contre des baselines vectorielles sur FinanceBench, parle pas de latence ni de comment l'index gère les mises à jour de documents, pis compare pas le coût par requête. C'est les questions que toute évaluation sérieuse doit poser.
Pour les développeurs qui travaillent sur des longs documents structurés — déclarations financières, contrats juridiques, articles de recherche, manuels techniques — PageIndex mérite un vrai test contre ton setup vectoriel existant. L'interprétabilité à elle seule a de la valeur : quand la récupération échoue, tu peux voir la chaîne de raisonnement qui a choisi les mauvais nœuds, au lieu de fixer des scores cosinus opaques. Pour tout le monde qui fait du chatbot par-dessus de la doc d'aide, le stack d'embeddings existant est probablement encore la bonne réponse. La vraie frontière intéressante ici, c'est pas « vecteurs contre raisonnement » comme guerre de religion, mais savoir quelle forme de document pis quel motif de requête justifient quelle architecture. PageIndex est une forme ; les vecteurs en sont une autre.