Chunking hiérarchique et récupération parent-enfant
Modèle architectural de recherche où la correspondance vectorielle s'effectue sur des fragments enfants courts et précis (Child Chunks), tandis que le bloc parent complet (Parent Document) est injecté dans le contexte du modèle.
1. Vue d'ensemble du concept et problème systémique
Chaque ingénieur ayant construit des systèmes RAG a été confronté à un dilemme insoluble :
- L'utilisateur demande : "Quelle est la politique de timeout pour les connexions Redis ?".
- La base vectorielle trouve la ligne :
timeout: 3000. - Si l'on transmet uniquement cette ligne au modèle (un chunk trop petit), le modèle ignore à quoi elle se rapporte : s'agit-il de Redis, PostgreSQL ou d'un serveur HTTP ?
- Si l'on découpe la documentation en énormes blocs de 1500 mots, le vecteur sémantique devient une "bouillie", et la ligne recherchée ne figure même pas dans le top-5 des résultats.
Le Hierarchical Chunking (Parent-Child Retrieval) dénoue ce nœud gordien : une haute résolution vectorielle pour la recherche + un contexte riche et large pour la génération.
2. Taxonomie architecturale et modèle mental
┌─────────────────────────────────────────────────────────────┐
│ CARTE HIÉRARCHIQUE PARENT-ENFANT │
├─────────────────────────────────────────────────────────────┤
│ 1. DOCUMENT PARENT (Section Markdown complète / Corps de │
│ fonction) : │
│ ID Parent : `parent_auth_flow_42` (800 tokens) │
│ • Description complète du cycle de vie des sessions et │
│ de la gestion des erreurs │
├─────────────────────────────────────────────────────────────┤
│ │ │
│ ▼ Divisé en enfants granulaires │
├─────────────────────────────────────────────────────────────┤
│ 2. MORCEAUX ENFANTS (Indexés dans la base de données │
│ vectorielle) : │
│ • Enfant 1 (120 tok) : [ Paramètres de création des │
│ cookies ] │
│ • Enfant 2 (140 tok) : [ Rotation des jetons & TTL Redis]│
│ ◄─── CORRESPONDANCE ! │
│ • Enfant 3 (100 tok) : [ Gestion des erreurs & retours │
│ 401 ] │
├─────────────────────────────────────────────────────────────┤
│ │ │
│ ▼ Résolution du lien `parent_id` │
├─────────────────────────────────────────────────────────────┤
│ 3. CONTEXTE INJECTÉ POUR LE MODÈLE : │
│ Le modèle reçoit le DOCUMENT PARENT ENTIER │
│ `parent_auth_flow_42` │
│ ➔ Zéro fragmentation du contexte, réponse limpide ! │
└─────────────────────────────────────────────────────────────┘
3. Scénarios d'ingénierie concrets en production
01. Documentation technique API avec multiples endpoints
Le chunk parent couvre l'intégralité de l'endpoint : description, arguments, codes de réponse et exemple de code. Les chunks enfants contiennent séparément la description de chaque paramètre. L'utilisateur interroge sur un paramètre rare, mais le modèle reçoit tout le contexte de l'endpoint et rédige une requête d'intégration correcte.
02. Analyse de contrats judiciaires ou d'accords juridiques
Le chunk enfant identifie une clause pénale spécifique, mais c'est l'intégralité de la section contractuelle correspondante, incluant toutes les conditions de force majeure associées, qui est injectée dans le prompt du modèle.
4. Pièges courants, erreurs typiques et sécurité
- Duplication des blocs parents (Parent Deduplication) : Si trois chunks enfants distincts issus du même bloc parent apparaissent dans le top-3 des résultats, un pipeline naïf pourrait insérer trois fois le même texte dans le prompt. Il est impératif d'effectuer une déduplication basée sur le
parent_id. - Augmentation de la consommation de tokens : Puisque le modèle reçoit un texte plus volumineux, la taille moyenne du contexte augmente. Régulez le nombre de parents uniques retournés (par exemple, pas plus de 3 blocs parents par requête).
5. Conclusion stratégique pour l'ingénieur de 2026
Le RAG hiérarchique est la manière la plus élégante de surmonter le dilemme de la taille des chunks sans recourir à des architectures graphiques excessivement complexes. La séparation entre l'espace d'indexation vectorielle et l'espace de lecture du modèle constitue la règle d'or d'une recherche d'information de qualité.
FAQ: Chunking hiérarchique et récupération parent-enfant
Termes associés
Stratégies de découpage (Chunking)
Méthodologie de décomposition de documents volumineux et de bases de code en fragments autonomes sur le plan informationnel (chunks) pour la génération d'embeddings vectoriels et une recherche précise dans les systèmes RAG.
RAG (Retrieval-Augmented Generation)
Modèle architectural d'IA d'entreprise qui enrichit dynamiquement la fenêtre contextuelle du modèle avec des connaissances vérifiées et pertinentes issues de sources externes (bases vectorielles, graphes, index en texte intégral) avant la génération de la réponse finale.
Reclassement (Cross-Encoder Reranking)
Méthodologie de recherche en deux étapes pour les systèmes RAG : sélection rapide des candidats initiaux (Bi-Encoder / BM25) suivie d'un reclassement précis via un modèle cross-encoder entièrement connecté (Cross-Encoder / Cohere Rerank / BGE-Reranker).
AST Chunking for Codebases
Méthodologie de découpage intelligent des fichiers de code pour la recherche vectorielle, basée exclusivement sur les limites syntaxiques du langage de programmation (Tree-sitter), plutôt que sur un découpage par nombre fixe de lignes ou de caractères.