Semantic chunking en RAG quand faut-il le préférer au split ?

Le semantic chunking devient utile quand vos réponses RAG ratent le sens, pas juste les mots. Le modèle n’est pas toujours le problème. Souvent, c’est le découpage. Je vais montrer quand garder un split simple, quand passer au sémantique, et comment arbitrer entre précision, contexte et coût.

Pourquoi le chunking change les réponses RAG ?

Le chunking change les réponses RAG parce qu’il change ce que le moteur de recherche peut retrouver. Et si le bon passage n’est pas retrouvé, le modèle peut être excellent, il répondra avec ce qu’on lui donne. RAG veut dire Retrieval Augmented Generation, c’est simplement une génération augmentée par recherche dans vos documents. Le découpage arrive avant la réponse, au moment où on indexe les contenus, puis au moment où on récupère les morceaux les plus proches de la question.

Je vois souvent le même piège chez des clients. Ils changent de modèle, ils testent un LLM plus gros, donc un modèle de langage plus puissant, mais leurs documents sont découpés n’importe comment. Résultat, les réponses restent moyennes. Le problème n’est pas toujours dans le cerveau du modèle. Il est parfois dans ce qu’on lui met sous les yeux.

Le chunking joue surtout sur trois points très concrets.

• La précision de récupération. Quand un chunk est trop large, il mélange trop de sujets. Dans un manuel produit, un bloc qui contient l’installation, les erreurs réseau et la maintenance peut ressortir pour une question sur le Wi-Fi, mais le passage utile est noyé. Le moteur retrouve le bon quartier, pas forcément la bonne porte.
• La conservation du contexte. Quand un chunk est trop petit, il coupe le sens. Dans un contrat légal, une phrase peut dire “Le client peut résilier sous 30 jours”, mais l’exception est dans la phrase suivante. Si elle est dans un autre chunk non récupéré, le modèle répond faux avec confiance. C’est là que ça devient dangereux.
• Le coût en tokens. Quand les chunks sont énormes, chaque morceau récupéré consomme beaucoup de contexte côté LLM. Les tokens, ce sont les unités de texte que le modèle lit et génère. Dans un rapport annuel, récupérer trois gros blocs de 2 000 mots pour une question sur le chiffre d’affaires Europe, c’est cher, lent, et souvent inutile.

Il n’y a pas de taille magique. Un manuel produit aime souvent des blocs courts et opérationnels. Un rapport annuel supporte parfois des sections plus larges. Un contrat légal demande de garder les clauses, les conditions et les exceptions ensemble. Le bon découpage dépend du contenu et de l’usage attendu.

Découvrez égalementAgentic AI en entreprise comment l'évaluer sans risque réel ?

C’est exactement là que le semantic chunking devient intéressant. Quand les frontières fixes coupent une idée au mauvais endroit, on peut découper selon le sens plutôt que selon un nombre arbitraire de caractères.

C’est quoi le semantic chunking ?

Le semantic chunking, c’est simplement une façon de découper un texte selon le sens, pas selon une taille fixe. Au lieu de dire “je coupe tous les 500 tokens”, on essaie de garder ensemble ce qui va ensemble.

L’objectif, c’est de préserver des unités sémantiques. Une idée complète, une section, un paragraphe, une question avec sa réponse, ou un enchaînement logique qui perdrait son intérêt si on le coupait au milieu. Les chunks peuvent donc avoir des tailles différentes, et c’est normal. Toutes les idées n’ont pas la même longueur. Une définition peut tenir en trois lignes, une procédure métier peut demander deux pages.

Le fixed-size splitting, lui, découpe selon une règle simple. Par exemple 800 tokens avec 100 tokens de chevauchement. C’est prévisible, rapide, facile à tester, facile à industrialiser. Franchement, dans beaucoup de cas, ça marche très bien. Le souci, c’est qu’il ne comprend pas ce qu’il coupe. Il peut séparer une explication de son exemple, une condition de son exception, ou une question de sa réponse.

Le semantic chunking essaie d’éviter ça. Il cherche des ruptures thématiques. Par exemple, quand la similarité entre deux segments baisse fortement. La similarité, ici, c’est une mesure qui indique si deux morceaux parlent à peu près du même sujet. Il peut aussi s’appuyer sur la structure du document, comme les titres, les paragraphes, les listes, les changements de section. Quand le sujet change, on coupe. Quand l’idée continue, on garde ensemble.

Découvrez égalementEU AI Act et analytics que doit changer votre business ?

J’ai vu pas mal de projets RAG où on accusait l’embedding ou le modèle, alors que le vrai souci venait du découpage. La réponse était bien dans la base, mais séparée du contexte qui permettait de la comprendre. Le modèle récupérait un bout propre, mais incomplet. Et derrière, forcément, il répondait à côté.

Quelles méthodes de chunking choisir ?

Je choisis rarement une méthode de chunking au hasard. Le bon choix dépend surtout de trois choses : la structure du contenu, le niveau de précision attendu et le coût acceptable. Un token, pour faire simple, c’est un petit morceau de texte utilisé par le modèle. Ça peut être un mot, un bout de mot, ou une ponctuation.

La méthode la plus simple, c’est le fixed-size chunking. On découpe le texte tous les X tokens ou caractères. C’est rapide, prévisible, facile à tester. J’aime bien ça pour des contenus homogènes, pas trop subtils. Le problème, c’est qu’on peut couper une idée en plein milieu. Une définition commence dans un chunk, l’exemple arrive dans le suivant, et le RAG perd une partie du sens.

Un cran au-dessus, il y a le recursive character splitting. La méthode cherche d’abord des séparateurs naturels : titres, paragraphes, phrases. Si le bloc reste trop gros, elle descend vers des unités plus petites. LangChain documente bien cette logique avec le RecursiveCharacterTextSplitter, qui est souvent une base pragmatique. Franchement, dans beaucoup de projets, c’est le premier réglage sérieux que je teste.

Quand le contenu est déjà organisé, je préfère souvent le structure-aware splitting. Là, on exploite les titres, les sections, le Markdown, les pages de documentation, les docs API. Pour de la documentation technique, c’est très efficace. Une endpoint API, ses paramètres, ses erreurs possibles et ses exemples doivent rester ensemble. Sinon, le modèle répond avec des bouts de vérité.

Découvrez égalementQuels outils d’observabilité IA choisir pour vos LLM ?

Pour des textes moins propres, le embedding-based semantic chunking devient intéressant. Un embedding, c’est une représentation numérique du sens d’un texte. La méthode compare la proximité entre segments successifs et détecte les changements de sujet. LlamaIndex propose par exemple une logique avec SemanticSplitterNodeParser. C’est plus coûteux à traiter, parce qu’il faut calculer ces embeddings, mais sur des comptes rendus, des rapports ou des contenus longs peu structurés, ça peut vraiment mieux tenir le sens.

Il reste le contextual chunking. L’idée est simple : on ajoute du contexte pertinent autour d’un chunk pour éviter de perdre la relation avec les sections voisines. Je l’utilise souvent sur les zones sensibles, comme des obligations contractuelles ou des procédures métier.

En production, je vois rarement une seule méthode pure. On combine. Structure-aware d’abord, recursive ensuite, puis enrichissement contextuel là où le risque d’ambiguïté est fort.

Quand le semantic chunking bat le split fixe ?

Le semantic chunking bat le split fixe quand le sens du document ne suit pas une longueur régulière. C’est le point clé. Si votre contenu avance par blocs d’idées, avec des passages courts, des détails longs, des exceptions au milieu, couper tous les 500 ou 1 000 tokens revient souvent à couper au mauvais endroit.

Je le vois surtout dans les documents rédigés naturellement. Rapports, contrats, articles longs, comptes rendus, contenus métier, bases de connaissance internes. Tout ce qui n’a pas été écrit comme une fiche produit bien rangée. Dans ces cas-là, le chunk doit suivre l’idée, pas la règle de longueur.

• Contenus non homogènes : Quand certaines sections font trois lignes et d’autres trois pages, le split fixe crée soit des morceaux trop pauvres, soit des morceaux qui mélangent plusieurs sujets. Le semantic chunking garde plus facilement une section courte entière, et découpe une longue section là où le sujet change vraiment.
• Documents avec nuances : Quand les exceptions, conditions ou limites sont aussi importantes que la règle principale, il faut éviter de séparer la règle de son contexte. Dans un contrat, une clause sans son exception peut faire dire n’importe quoi au modèle.
• Questions complexes : Quand la réponse dépend de plusieurs phrases liées, un chunk trop mécanique peut récupérer seulement la moitié du raisonnement. Le modèle a alors un passage correct, mais incomplet. C’est souvent là que les hallucinations arrivent.
• Recherche sémantique exigeante : Quand on veut retrouver une idée complète plutôt qu’un fragment de texte, le semantic chunking aide beaucoup. La recherche vectorielle, c’est-à-dire la recherche par proximité de sens via embeddings, fonctionne mieux quand chaque morceau porte une intention claire.

Je ne le surutilise pas pour autant. Pour des FAQ très courtes, des fiches structurées, des catalogues propres ou des contenus très réguliers, un split fixe ou récursif peut largement suffire. Le split récursif essaie simplement de couper intelligemment avec des séparateurs comme les titres, paragraphes ou phrases, avant de tomber sur une taille maximale.

Il y a aussi un coût. Le semantic chunking basé embeddings ajoute du calcul au moment de l’indexation, parfois plus de paramètres à maintenir, plus de tests, plus de surprises quand les documents changent. Le but n’est pas de faire plus sophistiqué. Le but, c’est de récupérer de meilleurs passages.

Sur un projet client, on a réduit pas mal de réponses hors contexte juste en passant d’un découpage fixe à une logique plus sémantique, sans changer de modèle. C’est souvent ça le vrai arbitrage à garder en tête : coût, précision, contexte.

Comment arbitrer précision contexte et coût ?

J’arbitre le chunking en testant la qualité de récupération, pas en regardant seulement la taille moyenne des chunks. Un chunk de 300 tokens peut être parfait sur un document et mauvais sur un autre. Ce qui compte, c’est simple : Quand l’utilisateur pose une question, est-ce que le système remonte le bon passage, avec assez de contexte, sans exploser le coût ?

Je pars souvent d’un échantillon de questions réelles. Pas 500 questions au début. Même 20 ou 30 suffisent pour voir les problèmes. Je compare ensuite plusieurs stratégies : split récursif classique, découpage basé sur la structure du document, semantic chunking, parfois avec overlap. Puis je regarde les passages récupérés avant même de juger la réponse finale du LLM. C’est là qu’on voit la vérité. Le modèle peut parfois sauver une mauvaise récupération, mais en production ça finit toujours par casser.

Les critères que je regarde sont assez concrets :

• Le passage récupéré contient-il l’information utile ? Si la bonne réponse est dans le document mais pas dans le top 3 ou top 5 récupéré, le chunking ou l’indexation pose problème.
• Le chunk apporte-t-il assez de contexte pour ne pas faire dire n’importe quoi au modèle ? Une phrase isolée peut être exacte, mais trompeuse sans la section autour.
• Combien de tokens partent dans le contexte à chaque requête ? Les tokens, ce sont les morceaux de texte envoyés au modèle. Plus on en envoie, plus ça coûte cher et plus la latence monte.
• La méthode tient-elle en production avec le volume de documents ? Un découpage sémantique peut être très bon, mais trop lent ou trop cher à recalculer sur des milliers de fichiers.
• Le découpage reste-t-il stable quand les documents changent ? Si chaque petite modification recrée des chunks très différents, le suivi, le cache et l’évaluation deviennent pénibles.

Dans la vraie vie, la bonne stratégie est souvent hybride. Je commence avec un split récursif ou structure-aware si les documents sont propres. Structure-aware veut dire qu’on respecte les titres, paragraphes, sections, tableaux, plutôt que de couper au hasard. Je passe au semantic chunking quand les contenus sont longs, irréguliers ou ambigus. Et quand les réponses dépendent de plusieurs sections, j’ajoute du contexte autour du chunk récupéré. Un client avait des procédures qualité comme ça : Le bon extrait remontait, mais la condition d’application était deux paragraphes avant. Sans contexte autour, le modèle répondait trop vite, et faux.

Ma règle pragmatique, c’est celle-ci :

• Documents propres : Recursive splitting ou structure-aware splitting.
• Documents longs et mal structurés : Semantic chunking.
• Réponses avec dépendances entre sections : Chunk récupéré plus contexte voisin.
• Budget serré : Chunks plus courts, top-k limité, évaluation régulière.
• Besoin de fiabilité : Test sur questions réelles avant optimisation fine.

Checklist rapide :

• La bonne information remonte-t-elle dans les premiers résultats ?
• Le contexte suffit-il pour répondre sans interpréter ?
• Le nombre de tokens reste-t-il acceptable ?
• Le découpage peut-il être recalculé facilement en production ?
• La stratégie reste-t-elle stable quand les documents évoluent ?

Alors on découpe comment maintenant ?

Je retiens une chose simple. Le chunking n’est pas un détail technique qu’on règle à la fin. C’est une décision de conception du RAG. Un split fixe peut très bien marcher sur des contenus courts, réguliers et propres. Dès que le texte devient long, nuancé ou mal structuré, le semantic chunking aide à récupérer des passages plus cohérents. Il coûte plus cher à préparer, oui, mais il évite souvent de compenser avec un modèle plus gros. Le vrai sujet, c’est de tester sur vos questions réelles. Vous gagnez des réponses plus fiables, avec moins de bruit et un meilleur usage de vos tokens.

FAQ

• Qu’est-ce que le semantic chunking en RAG ?

  Le semantic chunking consiste à découper les documents selon le sens plutôt que selon une taille fixe. L’idée est de garder ensemble les phrases, paragraphes ou sections qui portent la même idée, pour que le système RAG récupère des passages plus cohérents.

• Pourquoi le fixed-size splitting peut poser problème ?

  Le fixed-size splitting est simple et rapide, mais il découpe selon un nombre de tokens ou de caractères. Il peut donc couper une explication, séparer une condition de sa règle, ou mélanger plusieurs sujets dans un même chunk. Sur des contenus irréguliers, ça se voit vite dans la qualité des réponses.

• Le semantic chunking est-il toujours meilleur ?

  Pas forcément. Sur des contenus courts, très structurés ou répétitifs, un split fixe ou récursif peut suffire. Le semantic chunking devient intéressant quand les documents sont longs, non homogènes, riches en nuances ou quand les réponses demandent de conserver le fil logique d’une section.

• Quel est le principal compromis du semantic chunking ?

  Le compromis principal, c’est le coût et la complexité. Une approche basée sur les embeddings demande plus de traitement à l’indexation. En échange, elle peut améliorer la précision de récupération et éviter d’envoyer trop de bruit au modèle.

• Comment savoir quelle stratégie de chunking choisir ?

  Je pars de vraies questions utilisateurs, je teste plusieurs découpages et je regarde les passages récupérés. Si les bons passages sortent avec assez de contexte et sans exploser les tokens, la stratégie est bonne. Sinon, je change la taille, la méthode ou j’ajoute du contexte autour des chunks.

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. J’accompagne des équipes qui veulent rendre leurs données, leurs outils IA et leurs automatisations vraiment exploitables, pas juste jolies en démo. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez cadrer un projet RAG, IA ou automatisation proprement, contactez-moi.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.