PageIndex remplace le pipeline RAG en naviguant la structure documentaire via un Reasoning Tree, améliorant pertinence et traçabilité (résultats déclarés jusqu’à 98,7 % de précision). Lisez la suite pour comprendre pourquoi et comment le déployer rapidement en notebook.
Pourquoi RAG classique échoue sur les documents ?
Réponse directe : Parce que le découpage arbitraire, la similarité vecteur et l’opacité des retrievers détruisent le contexte et la pertinence.
-
Découpage arbitraire des documents.
Le découpage (chunking) segmente un document selon une taille de token fixe sans respecter la structure logique (sections, tableaux, clauses).
Exemple concret : Un contrat dont une clause est scindée en deux chunks, avec la condition dans un chunk et l’exception dans l’autre.
Formez-vous à l'automatisation No Code !
Gagnez un temps précieux avec le No Code : Nos formations No Code vous apprennent à automatiser vos opérations internes, à structurer et gérer vos données efficacement avec n8n, Make et Airtable. Exploitez l’IA pour générer et partager du contenu professionnel en quelques clics, sans une ligne de code. Optimisez votre productivité en simplifiant vos workflows et en centralisant vos informations.
Conséquences en production : Réponses contradictoires ou incomplètes, perte de causalité juridique et erreurs critiques lors de recommandations automatisées.
-
Similarité vecteur inadaptée au format et à la logique.
Les embeddings capturent souvent le sens global mais lissent les détails structurels (valeurs numériques, relations tabulaires, références croisées).
Exemple concret : Un tableau financier dont les lignes importantes sont jugées moins similaires qu’une phrase explicative voisine.
Conséquences en production : Informations chiffrées mal récupérées, réponses floues sur des valeurs précises, perte de fiabilité pour les décisions basées sur données.
-
Opacité et non-transparence des retrievers.
Les retrievers (composants qui sélectionnent les passages) offrent peu d’explications sur pourquoi un chunk a été choisi et masquent les biais liés au scoring.
Exemple concret : Une référence croisée attendue n’est jamais retournée parce que son embedding était moins « populaire ».
Conséquences en production : Difficulté à diagnostiquer les erreurs, tests fragiles, perte de confiance des utilisateurs et coûts d’investigation élevés.
-
Dilution du contexte et augmentation du bruit avec le nombre de chunks.
Ajouter plus de chunks pour couvrir un document augmente proportionnellement le risque d’injecter du contenu non pertinent et de dépasser la fenêtre contextuelle du modèle.
Exemple concret : Un chatbot reçoit 20 chunks et mélange une définition contextuelle avec une note de bas de page sans lien.
Conséquences en production : Dégradation de la précision, hallucinations, latence accrue et coût d’API qui grimpe sans gain de qualité.
| Problème | Mécanisme | Impact | Indicateur à surveiller |
| Découpage arbitraire | Segmentation par taille, ignorance de la structure | Perte de cohérence et réponses incomplètes | Taux d’erreurs sur questions contextuelles |
| Similarité vecteur limitée | Aplatit détails structurels et chiffres | Mauvaise récupération de valeurs précises | Précision sur requêtes chiffrées |
| Opacité des retrievers | Scoring non explicité, biais cachés | Diagnostique difficile, confiance réduite | Temps moyen de débogage |
| Dilution du contexte / bruit | Multiplication des chunks augmente le bruit | Hallucinations et latence; bruit augmente avec le nombre de chunks | Variation de la qualité au fur et à mesure de l’ajout de chunks |
Qu’est‑ce que PageIndex et en quoi diffère‑t‑il de RAG ?
PageIndex construit un Reasoning Tree qui reflète la structure du document et guide la recherche par navigation raisonnée au lieu de s’appuyer sur des similarités vectorielles.
Reasoning Tree : structure hiérarchique pensée pour représenter logiquement le contenu d’un document afin de permettre une recherche par parcours raisonné, pas seulement par proximité sémantique.
Définition claire du Reasoning Tree et de ses niveaux :
- Document : Racine contenant le contexte global, métadonnées et objectifs documentaires.
- Section : Bloc thématique majeur qui regroupe plusieurs sous‑parties et définit des axes de recherche.
- Sous‑section : Détail d’une section, permettant d’isoler des concepts précis ou des procédures.
- Paragraphe : Feuilles du tree, unité textuelle fine sur laquelle porte la réponse ou l’extraction précise.
Phases : construction (indexation structurée) et recherche/navigation :
- Construction : Analyse du document pour détecter titres, chapitres, balises et relations logiques, puis création des nœuds et liens du Reasoning Tree (indexation structurée).
- Recherche/Navigation : Parcours guidé du tree à partir de la requête, exploration sélective des nœuds pertinents et combinaison d’informations par remontée contextuelle.
Avantages par rapport au RAG (Retrieval-Augmented Generation) basé sur vecteurs :
- Préservation du contexte : Navigation dans la hiérarchie conserve la portée et la continuité logique, réduisant les réponses hors‑sujet causées par la similarité locale.
- Explicabilité : Chaque réponse se rattache à un chemin précis du tree, facilitant l’audit et la traçabilité des sources.
- Meilleure pertinence sur documents structurés : Tests et expérimentations internes montrent des gains substantiels, avec des scores atteignant jusqu’à 98,7 % de précision sur certains jeux de données fortement structurés ; toutefois ces chiffres dépendent du corpus, de la granularité et des métriques utilisées, et ne garantissent pas la même performance sur textes non structurés.
Cas d’usage adaptés : voici des exemples concrets où PageIndex excelle :
- Contrats — Recherche de clauses, traçabilité des obligations et comparaison de versions.
- Manuels — Navigation par procédures, étapes et troubleshooting.
- Rapports financiers — Extraction de postes, suivi des hypothèses et explicabilité des chiffres.
Comment fonctionne la recherche par arbre (Tree Search) ?
La recherche par arbre parcourt et évalue les nœuds du Reasoning Tree pour localiser la zone la plus pertinente avant d’extraire le texte.
Les heuristiques de navigation déterminent l’ordre de visite des nœuds.
- Pertinence estimée : Prioriser les nœuds dont le résumé ou le score indique une forte correspondance sémantique avec la question.
- Incertitude du LLM : Explorer davantage lorsque le modèle indique faible confiance ou réponses contradictoires.
- Profondeur vs largeur : Favoriser la descente (deep) lorsqu’un chemin semble cohérent, sinon élargir (breadth) pour couvrir d’autres axes.
- Coût / Latence : Pondérer l’exploration selon le budget calcul et le temps de réponse acceptable.
- Guidage par LLM : Utiliser le LLM pour évaluer ou classer les enfants d’un nœud en fournissant contexte + instruction de scoring.
Flux d’interrogation opérationnel : Question → Décision de navigation (LLM score) → Exploration des nœuds sélectionnés → Sélection finale et extraction.
Exemple pas à pas.
- Question utilisateur : « Quelle est la procédure de remboursement pour un produit défectueux ? »
- Étape 1 (Root) : LLM évalue les enfants : Politique générale, Support produit, FAQ.
- Étape 2 : Sélection de « Politique générale » puis évaluation de ses sous-nœuds.
- Étape 3 : Descente vers « Remboursement » → « Délai & Conditions » → Extraction du passage pertinent.
| Étape | Action | Sortie attendue |
| 1 | Scoring des enfants du root | Liste triée avec scores |
| 2 | Exploration ciblée | Extraits courts et métadonnées |
| 3 | Sélection finale | Texte source à extraire + justification |
Prompts LLM suggérés pour décision de navigation :
Évaluez ces 5 titres de nœuds par pertinence (0-1) pour la question : "Quelle est la procédure de remboursement pour un produit défectueux ?" Donnez score et brève raison.Pour une trace explicable, conserver pour chaque visite de nœud : identifiant du nœud, score donné, raison textuelle fournie par le LLM, horodatage et extraction finale.
Comparaison rapide avec la recherche vectorielle : l’arbre offre un raisonnement séquentiel explicable et économe en requêtes pour documents hiérarchiques, tandis que la recherche vectorielle excelle sur la récupération brute et la similarité globale mais fournit moins de logique pas-à-pas et de traçabilité fine.
Comment PageIndex génère la réponse finale ?
Après identification du nœud pertinent, on extrait le texte contextuel associé puis on laisse le LLM formuler la réponse en contexte (phase d’extraction + génération).
Méthode d’extraction et préservation du contexte. Les extraits sont récupérés avec leur métadonnée de provenance : identifiant de document, identifiant de nœud, offsets de début/fin, score de similarité, et timestamp. Les contenus structurés (tables, listes, figures) sont conservés sous forme sérialisée pour éviter la perte de sens. Les références croisées sont ajoutées comme pointeurs : si un paragraphe A mentionne la table T, l’extrait inclut « Voir Table:T (doc:123, node:7) ». Pour préserver le flux sémantique, on capture aussi les nœuds voisins (±N nœuds) et on applique un trimming intelligent pour rester dans la fenêtre contextuelle du LLM.
Construction du prompt de génération pour le LLM. Le prompt contient trois blocs essentiels : 1) Contexte — l’extrait complet avec métadonnées et références croisées. 2) Instruction — la tâche explicite (réponse factuelle, synthèse, comparaison). 3) Contraintes de format — longueur max, ton, structure de sortie (bullet points, JSON, citations en fin de réponse). Ajouter des exemples de sortie (few-shot) quand le format est strict. Toujours inclure une section « Provenance » demandant au LLM de citer les identifiants des nœuds utilisés.
Fonction utilitaire ask() Fonction orchestratrice qui pilote la navigation dans l’index, l’extraction et la génération. Elle gère la sélection du nœud, l’assemblage du contexte, la construction du prompt et l’appel LLM, puis exécute un post‑traitement (normalisation, attribution de score, mapping des citations). Je privilégie la traçabilité : chaque réponse renvoie au minimum 1–3 identifiants source.
| Étape | Entrée | Sortie | Exemple concret (courte pseudo‑commande) |
| Recherche | Question utilisateur | Liste de nœuds triés par score | |
| Extraction | node_id + window | Texte + métadatas (doc,id,offsets,refs) | |
| Construction du prompt | Extraits + instruction + contraintes | Prompt final prêt pour LLM | |
| Génération | Prompt | Réponse brute + scores | |
| Post‑traitement | Réponse brute + métadatas | Réponse finale + citations + métriques | |
Comment déployer PageIndex dans un notebook Jupyter pour produire des réponses ?
Je fournis ici la procédure minimale et opérationnelle pour déployer PageIndex dans un notebook Jupyter et produire des réponses exploitables : installez le package, configurez l’API LLM (ex. OpenAI), soumettez le document, attendez la construction de l’arbre, effectuez la recherche, extrayez le texte et appelez ask().
| Installation | |
| Imports & Configuration (variables d’environnement) | |
| Initialisation client | |
Séquence complète exécutée dans un notebook : submit document → get tree → tree.search → fetch text → ask().
| Soumettre le document | |
| Récupérer l’arbre | |
| Recherche dans l’arbre | |
| Récupérer le texte des nœuds | |
| Appeler ask() pour réponse agrégée | |
Checklist mise en production et points d’attention :
- Surveiller la latence : Mesurer temps de submit → build → search et mettre en cache les arbres fréquemment consultés.
- Contrôler les coûts LLM : Pister le nombre de tokens par ask() et utiliser des prompts ou LLMs moins coûteux pour la recherche initiale.
- Documents volumineux : Chunking préalable, indexation incrémentale et limits sur depth/branching de l’arbre.
- Traçabilité : Logger chaque décision de navigation (nœuds visités, scores, prompts envoyés) pour audit et debugging.
- Sécurité & conformité : Chiffrer documents au repos, anonymiser extraits si nécessaire.
| Commande | Rôle |
| pip install pageindex | Installer la librairie |
| client.submit_document(…) | Indexer et construire l’arbre |
| tree.search(…) | Localiser nœuds pertinents |
| client.fetch_text(…) | Extraire contenu textuel |
| client.ask(…) | Consolider le contexte et générer la réponse |
Prêt à adopter PageIndex pour vos documents ?
PageIndex s’appuie sur un index arborescent et une recherche raisonnée pour préserver le contexte, offrir de l’explicabilité et améliorer la pertinence sur documents structurés — des faiblesses majeures du RAG traditionnel. La méthode réduit le bruit introduit par le chunking et facilite la traçabilité des décisions. Si vous gérez des contrats, manuels ou rapports et que vous voulez des réponses plus fiables et auditables, PageIndex est une alternative concrète qui vous fera gagner en précision et en confiance opérationnelle.
FAQ
A propos de l’auteur
Je suis Franck Scandolera, expert & formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code (n8n) et intégration de l’IA en entreprise. Responsable de l’agence webAnalyste et de l’organisme de formation Formations Analytics, j’ai accompagné des clients comme Logis Hôtel, Yelloh Village, BazarChic, Fédération Française de Football et Texdecor sur des sujets de tracking, analytics et automatisation. Disponible pour aider votre entreprise => contactez moi.