\nParent-enfant<\/td>\n Pr\u00e9cision de la recherche + contexte de lecture<\/td>\n Deux niveaux \u00e0 g\u00e9rer<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nLe voir tourner<\/h2>\nUne m\u00eame page, plusieurs d\u00e9coupages<\/h3>\n Question concr\u00e8te : combien de morceaux donne la page Wikip\u00e9dia de la Coupe du monde de cricket 2023 (plus de 8 000 mots), selon la m\u00e9thode ? On commence par le d\u00e9coupage par caract\u00e8re. Le code coupe sur les sauts de ligne, vise 1 000 caract\u00e8res par fragment, avec 200 caract\u00e8res de chevauchement. Rep\u00e8re html_data_transformed[0].page_content<\/code> : c’est le texte de la page, d\u00e9j\u00e0 nettoy\u00e9 de ses balises HTML.<\/p>\nfrom langchain.text_splitters import CharacterTextSplitter\n\ntext_splitter = CharacterTextSplitter(\n separator="\\n", # caractere utilise pour le decoupage\n chunk_size=1000, # nombre de caracteres par chunk\n chunk_overlap=200, # nombre de caracteres de chevauchement\n)\nchunks = text_splitter.create_documents(\n [html_data_transformed[0].page_content]\n)\nprint(f"Nombre de chunks crees : {len(chunks)}")\n<\/code><\/pre>\nR\u00e9sultat : 67 fragments, et l’on peut v\u00e9rifier que les 200 derniers caract\u00e8res de l’un recoupent bien les 200 premiers du suivant.<\/p>\n
Changeons de m\u00e9thode : un d\u00e9coupage par sections HTML donne 231 fragments. Si on les red\u00e9coupe ensuite \u00e0 taille fixe, on obtient 285 fragments finaux. Cette combinaison est pr\u00e9sent\u00e9e comme courante et souvent b\u00e9n\u00e9fique, avec un principe d’\u00e9quilibre : plus de fragments, c’est une information plus pr\u00e9cise pour le mod\u00e8le, mais au risque de perdre la coh\u00e9rence d’ensemble.<\/p>\n
\n\ud83d\udccc \u00c0 retenir<\/strong> Sur la m\u00eame page : 67 fragments avec une coupe par caract\u00e8re, 285 avec sections puis taille fixe. Le nombre de fragments n’est pas un d\u00e9tail technique, c’est le r\u00e9sultat direct de ta strat\u00e9gie.<\/p>\n<\/blockquote>\nNe jamais couper un mot en deux<\/h3>\n Autre corpus, autre question : un article sur les brevets d’Einstein, d\u00e9coup\u00e9 en fen\u00eatres glissantes de 500 caract\u00e8res avec 40 caract\u00e8res de recouvrement. Le livre \u00e9crit sa propre fonction, dont la logique garantit qu’on ne coupe jamais au milieu d’un mot.<\/p>\n
Dans le code, text<\/code> est l’article complet, chunk_size<\/code> la taille vis\u00e9e et overlap<\/code> le recouvrement. Avec split_on_whitespace_only=True<\/code>, on ne coupe que sur des espaces ; sinon, on d\u00e9coupe brutalement par index.<\/p>\ndef chunk_text(text, chunk_size, overlap, split_on_whitespace_only=True):\n chunks = []\n index = 0\n while index < len(text):\n if split_on_whitespace_only:\n prev_whitespace = 0\n left_index = index - overlap\n while left_index >= 0:\n if text[left_index] == " ":\n prev_whitespace = left_index\n break\n left_index -= 1\n next_whitespace = text.find(" ", index + chunk_size)\n if next_whitespace == -1:\n next_whitespace = len(text)\n chunk = text[prev_whitespace:next_whitespace].strip()\n chunks.append(chunk)\n index = next_whitespace + 1\n else:\n start = max(0, index - overlap + 1)\n end = min(index + chunk_size + overlap, len(text))\n chunk = text[start:end].strip()\n chunks.append(chunk)\n index += chunk_size\n return chunks\n\nchunks = chunk_text(text, 500, 40)\nprint(len(chunks)) # 89 chunks in total\n<\/code><\/pre>\nL’article donne 89 fragments. Ce nombre est ensuite confirm\u00e9 par le calcul des embeddings : chaque fragment devient un vecteur de 1536 dimensions, et l’on retrouve exactement autant de vecteurs que de fragments.<\/p>\n
D\u00e9couper d’abord selon les titres<\/h3>\n Plut\u00f4t qu’une taille arbitraire, on peut s’appuyer sur la structure. L’article d’Einstein a des sections num\u00e9rot\u00e9es ; une expression r\u00e9guli\u00e8re rep\u00e8re chaque titre (un chiffre, un point, quelques mots) et coupe juste avant.<\/p>\n
import re\ndef split_text_by_titles(text):\n # A regular expression pattern for titles that\n # match lines starting with one or more digits, an optional uppercase letter,\n # followed by a dot, a space, and then up to 60 characters\n title_pattern = re.compile(r"(\\n\\d+[A-Z]?\\. {1,3}.{0,60}\\n)", re.DOTALL)\n titles = title_pattern.findall(text)\n # Split the text at these titles\n sections = re.split(title_pattern, text)\n sections_with_titles = []\n # Append the first section\n sections_with_titles.append(sections[0])\n # Iterate over the rest of the sections\n for i in range(1, len(titles) + 1):\n section_text = sections[i * 2 - 1].strip() + "\\n" + sections[i * 2].strip()\n sections_with_titles.append(section_text)\n return sections_with_titles\n\nsections = split_text_by_titles(text)\nprint(f"Number of sections: {len(sections)}")\n# Number of sections: 9\n<\/code><\/pre>\nOn obtient neuf sections : quatre principales, quatre sous-sections d\u00e9crivant des brevets, et le r\u00e9sum\u00e9 initial. Mais une mesure en tokens r\u00e9v\u00e8le un probl\u00e8me : la plupart des sections restent sous les 600 tokens, une taille raisonnable pour la plupart des prompts, alors que l’une d’elles d\u00e9passe les 4 000 tokens et risquerait de provoquer une erreur de d\u00e9passement de contexte.<\/p>\n
Le d\u00e9coupage par structure ne suffit donc pas toujours : il faut ensuite red\u00e9couper les sections trop longues, exactement comme dans l’exemple de la page Wikip\u00e9dia.<\/p>\n
Chercher petit, lire grand : le parent document retriever<\/h3>\n C’est ici que la strat\u00e9gie parent-enfant prend tout son sens. Le document parent est d\u00e9coup\u00e9 en enfants plus petits, chacun embedd\u00e9 s\u00e9par\u00e9ment ; mais c’est le parent entier qui est retourn\u00e9 une fois la correspondance trouv\u00e9e, pour garder tout le contexte utile au mod\u00e8le.<\/p>\n\n\n\n\t\t\t\n\t\t\t\tLe sch\u00e9ma montre deux fa\u00e7ons d’embedder autre chose que le texte \u00e0 rendre. \u00c0 droite, celle qui nous int\u00e9resse : on cherche sur les enfants, on renvoie le parent. \u00c0 gauche, sa cousine, o\u00f9 l’on embedde les questions auxquelles un document peut r\u00e9pondre plut\u00f4t que le document lui-m\u00eame.<\/figcaption><\/figure>\n\n\nDans l’exemple, les sections trop longues sont red\u00e9coup\u00e9es en parents d’au plus 2 000 caract\u00e8res, avec la fonction chunk_text<\/code> vue plus haut ; sections<\/code> est la liste obtenue \u00e0 l’\u00e9tape pr\u00e9c\u00e9dente.<\/p>\nparent_chunks = []\nfor s in sections:\n parent_chunks.extend(chunk_text(s, 2000, 40))\n<\/code><\/pre>\nChaque parent est ensuite d\u00e9coup\u00e9 en enfants de 500 caract\u00e8res, embedd\u00e9s et import\u00e9s dans un graphe o\u00f9 le PDF est reli\u00e9 \u00e0 ses parents, eux-m\u00eames reli\u00e9s \u00e0 leurs enfants.<\/p>\n\n\n\n\t\t\t\n\t\t\t\tRep\u00e8re la couleur ou l’\u00e9tiquette \u00ab embed. \u00bb : seuls les enfants portent un embedding. Les parents ne servent qu’\u00e0 fournir le texte \u00e0 lire une fois l’enfant retrouv\u00e9.<\/figcaption><\/figure>\n\n\n\u00c0 la question, la recherche vectorielle part des enfants, mais en demandant volontairement quatre fois plus de r\u00e9sultats que n\u00e9cessaire : plusieurs enfants pertinents peuvent appartenir au m\u00eame parent, il faut donc une marge avant de d\u00e9dupliquer et de ne garder que les k<\/code> meilleurs parents.<\/p>\nCALL db.index.vector.queryNodes($index_name, $k * 4, $question_embedding)\nYIELD node, score\nMATCH (node)<-[:HAS_CHILD]-(parent)\nWITH parent, max(score) AS score\nRETURN parent.text AS text, score\nORDER BY score DESC\nLIMIT toInteger($k)\n<\/code><\/pre>\nRetiens la ligne max(score)<\/code> : chaque parent est class\u00e9 selon son enfant le plus proche de la question, et non selon une moyenne dilu\u00e9e. C’est la traduction concr\u00e8te de \u00ab chercher petit, lire grand \u00bb.<\/p>\nQuelle taille choisir ? Un exemple chiffr\u00e9<\/h3>\n Le livre sur GraphRAG rapporte une exp\u00e9rience de chercheurs de MS GraphRAG qui comparent plusieurs tailles de fragments. Attention au contexte : la mesure porte sur l’extraction d’entit\u00e9s, pas sur la r\u00e9cup\u00e9ration d’une r\u00e9ponse.<\/p>\n\n\n\n\t\t\t\n\t\t\t\tSur le graphique, la courbe des fragments de 600 tokens domine celles de 1 200 et de 2 400 tokens, avec un \u00e9cart d’environ 24 000 entit\u00e9s d\u00e9tect\u00e9es contre environ 10 500 au plus haut. Les petits fragments retrouvent davantage d’entit\u00e9s. Ce r\u00e9sultat ne se transpose pas m\u00e9caniquement \u00e0 ton cas, mais il confirme le sens de l’arbitrage : plus petit veut dire plus pr\u00e9cis.<\/figcaption><\/figure>\n\n\nLire les r\u00e9sultats : comment savoir si ton d\u00e9coupage est le bon<\/h2>\n Choisir sans mesurer, c’est deviner. Le livre distingue deux m\u00e9triques de r\u00e9cup\u00e9ration que tu connais peut-\u00eatre : la pr\u00e9cision (parmi les documents r\u00e9cup\u00e9r\u00e9s, combien \u00e9taient pertinents ?) et le rappel (parmi tous les documents pertinents, combien ont \u00e9t\u00e9 r\u00e9cup\u00e9r\u00e9s ?). En RAG, la pr\u00e9cision@k est la plus parlante, puisque seuls les tout premiers r\u00e9sultats servent \u00e0 l’augmentation.<\/p>\n\n\n\n\t\t\t\n\t\t\t\tSur le sch\u00e9ma, la pr\u00e9cision est la part de l’intersection dans \u00ab r\u00e9cup\u00e9r\u00e9s \u00bb, le rappel sa part dans \u00ab pertinents \u00bb. Un rappel parfait est trivial : il suffit de tout r\u00e9cup\u00e9rer. C’est pourquoi on ne le regarde jamais seul.<\/figcaption><\/figure>\n\n\nPour ton objectif \u00ab du premier coup \u00bb, une troisi\u00e8me mesure est d\u00e9cisive : le rang de r\u00e9ciprocit\u00e9 moyen (MRR), qui moyenne sur un ensemble de requ\u00eates l’inverse du rang du premier document pertinent. Il dit \u00e0 quelle vitesse le syst\u00e8me trouve un r\u00e9sultat pertinent, mais ignore tout ce qui suit ce premier r\u00e9sultat.<\/p>\n
\n\ud83d\udca1 Intuition<\/strong> Une bonne r\u00e9ponse en position 1 vaut plus qu’une bonne r\u00e9ponse en position 5 : c’est exactement ce que capture le MRR. Compare deux d\u00e9coupages sur les m\u00eames questions et garde celui dont le MRR est le meilleur.<\/p>\n<\/blockquote>\nS\u00e9pare aussi les deux sources d’erreur. Sur un banc d’essai, le livre GraphRAG obtient une exactitude de 0,7774, un rappel de contexte de 0,7941 et une fid\u00e9lit\u00e9 de 0,9657 : le mod\u00e8le invente rarement, mais la r\u00e9cup\u00e9ration ne capture pas toujours toute l’information. Quand le rappel est le maillon faible, c’est le d\u00e9coupage et la r\u00e9cup\u00e9ration qu’il faut travailler, pas le mod\u00e8le.<\/p>\n
Enfin, garde un jeu de questions qui \u00e9volue : il devient une sp\u00e9cification vivante de ce que l’agent doit savoir g\u00e9rer, et permet de d\u00e9tecter les r\u00e9gressions quand tu changes de d\u00e9coupage.<\/p>\n
Pi\u00e8ges et limites<\/h2>\n Le contexte de l’agent est un budget.<\/strong> Un contexte non pertinent ou mal structur\u00e9 distrait le mod\u00e8le ou d\u00e9passe les budgets de jetons sans b\u00e9n\u00e9fice ; il vaut mieux ne retrouver que les informations les plus utiles plut\u00f4t que d’ajouter de gros blocs de texte. Plus tes fragments sont cibl\u00e9s, mieux ce budget est employ\u00e9.<\/p>\nUn fragment peut m\u00e9langer des sources.<\/strong> Des fragments partageant des mots-cl\u00e9s comme \u00ab payment \u00bb ou \u00ab terms \u00bb mais appartenant \u00e0 des contrats diff\u00e9rents peuvent se m\u00e9langer, et conduire le mod\u00e8le \u00e0 une r\u00e9ponse fragment\u00e9e, voire trompeuse. Le filtrage par m\u00e9tadonn\u00e9es (horodatage, auteur, cat\u00e9gorie) restreint la recherche aux fragments pertinents avant m\u00eame de la lancer.<\/p>\n\n\u26a0\ufe0f Pi\u00e8ge<\/strong> Un d\u00e9coupage parfait ne r\u00e9pond pas \u00e0 toutes les questions. Une question qui demande de filtrer, trier ou compter (\u00ab combien de contrats actifs avec tel client ? \u00bb) \u00e9choue avec de simples embeddings de texte, con\u00e7us pour retrouver du contenu proche, pas pour agr\u00e9ger.<\/p>\n<\/blockquote>\nCertaines questions r\u00e9sistent au d\u00e9coupage.<\/strong> Les requ\u00eates \u00e0 raisonnement multi-\u00e9tapes, les requ\u00eates vagues (difficiles \u00e0 faire correspondre \u00e0 des fragments pr\u00e9cis), les requ\u00eates longues ou complexes et les requ\u00eates implicites restent des points faibles r\u00e9currents. Le chunking n’y change pas grand-chose ; il faut plut\u00f4t agir sur la requ\u00eate ou le raisonnement.<\/p>\nUne taille, un mod\u00e8le.<\/strong> Certains mod\u00e8les d’embeddings fonctionnent mieux avec des fragments d’une taille pr\u00e9cise, et le mod\u00e8le doit rester strictement le m\u00eame tout au long de l’application : en changer implique de recalculer tout l’index.<\/p>\nLes enrichissements se paient.<\/strong> Le r\u00e9sum\u00e9 ajout\u00e9 \u00e0 chaque fragment et les techniques de pr\u00e9-r\u00e9cup\u00e9ration introduisent un surco\u00fbt de calcul, de latence et de stockage \u00e0 mettre en balance avec le gain attendu.<\/p>\nEt les tr\u00e8s grandes fen\u00eatres de contexte ?<\/strong> Elles permettent, pour des bases modestes, de transmettre tout le document sans d\u00e9coupage. Mais les \u00e9tudes cit\u00e9es montrent un co\u00fbt de calcul nettement sup\u00e9rieur, et rien ne garantit qu’un mod\u00e8le rep\u00e8re l’unique \u00e9l\u00e9ment pertinent dans une telle fen\u00eatre. Le consensus d\u00e9crit est qu’une architecture hybride garde sa valeur.<\/p>\n\n\n\n\t\t\t\n\t\t\t\tSuis le flux : le mod\u00e8le re\u00e7oit d’abord les fragments r\u00e9cup\u00e9r\u00e9s et d\u00e9cide lui-m\u00eame s’ils suffisent. Sinon seulement, le document complet lui est transmis. On garde ainsi le co\u00fbt r\u00e9duit du RAG et la s\u00e9curit\u00e9 du contexte long.<\/figcaption><\/figure>\n\n\n
![\"Trois](\"https:\/\/www.ranksignal.fr\/wp-content\/uploads\/2026\/09\/b1_ch03_processus_chunking-scaled.png\")