Simple Enough Blog logo
  • Home 
  • Projets 
  • Tags 

  •  Langage
    • English
    • Français
  1.   Blogs
  1. Accueil
  2. Blogs
  3. 1000 le nombre magique dans le monde des LLM

1000 le nombre magique dans le monde des LLM

Posté le 26 mars 2025 • 4 min de lecture • 676 mots
LLM   OpenIA   Helene  
LLM   OpenIA   Helene  
Partager via
Simple Enough Blog
Lien copié dans le presse-papier

Travailler efficacement avec des modèles de langage de grande taille (LLMs) implique plus qu'un simple prompt. Lorsqu'on construit un pipeline RAG (Retrieval-Augmented Generation) ou qu'on intègre des documents dans un système basé sur des LLMs, le découpage du texte en chunks devient un levier de performance critique.

Sur cette page
I. Taille des chunks : pourquoi ~1000 tokens ?   II. Pourquoi découper même avec des LLMs à long contexte ?   III. Pertinence contextuelle : filtrer plutôt que tout injecter   IV. Le chevauchement : un levier souvent sous-estimé   V. Récapitulatif des bonnes pratiques   VI. Exemple avec LangChain   Conclusion  
1000 le nombre magique dans le monde des LLM
Photo par Helene Hemmerter

I. Taille des chunks : pourquoi ~1000 tokens ?  

La valeur par défaut de 1000 tokens par chunk n’est pas arbitraire :

  • Un chunk de cette taille contient généralement assez d’information pour être sémantiquement cohérent, sans être trop lourd.
  • Il reste compatible avec les fenêtres contextuelles des LLMs modernes (4k, 8k, 32k voire 1M tokens).
  • Il évite de diluer la compréhension ou de casser des unités de sens.

Certains cas nécessitent des tailles différentes :

  • Documents très denses en information : chunk plus petit (300-500 tokens),
  • Documents structurés (code, tableaux) : chunk plus grand possible si les blocs sont cohérents.

Il est important de noter que la découpe n’est pas toujours strictement exacte. En effet, les outils cherchent à préserver la cohérence sémantique du contenu en priorisant les découpes sur des séparateurs logiques (paragraphe, phrase, mot). Certains morceaux peuvent dépasser légèrement la limite fixée, par exemple atteindre 1080 tokens, si cela permet de ne pas casser une phrase ou une idée en plein milieu. Cette tolérance est volontaire : elle permet de générer des morceaux plus naturels, plus compréhensibles et plus efficaces en contexte pour les modèles de langage. En revanche, cela reste maîtrisé, et les variations dépassent rarement quelques dizaines de tokens.


II. Pourquoi découper même avec des LLMs à long contexte ?  

Des modèles comme GPT-4 Turbo ou Gemini 1.5 peuvent accepter jusqu’à 1 million de tokens en entrée. Cela ne signifie pas qu’il est judicieux d’y injecter un document entier non filtré.

Deux raisons majeures :

  1. Coût : plus de tokens = coût plus élevé (surtout avec les modèles commerciaux).
  2. Qualité : plus le contexte est bruité, plus la réponse du modèle est dégradée. C’est la règle classique du “garbage in, garbage out”.

Un bon découpage permet donc de réduire la charge et d’augmenter la précision.


III. Pertinence contextuelle : filtrer plutôt que tout injecter  

Il est préférable de fournir moins d’information, mais plus ciblée, en sélectionnant les chunks les plus pertinents pour la question posée.

Cela suppose généralement :

  • Une vectorisation des chunks (via embeddings),
  • Une phase de retrieval (ex. FAISS, Weaviate, Qdrant).Quand une question est posée, elle est transformée en vecteur, puis comparée à tous les chunks pour obtenir une liste classée par similarité.
  • Une sélection finale (top-k) avant injection dans la fenêtre contextuelle du modèle. Au lieu de garder tous les résultats, on prend uniquement les k meilleurs chunks (les plus similaires à la question). C’est ce qu’on appelle le top-k retrieval. Exemple : k = 5 → on garde les 5 chunks les plus pertinents.

IV. Le chevauchement : un levier souvent sous-estimé  

Lorsque le découpage est fait sans chevauchement (chunk_overlap = 0), les chunks n’ont aucun lien direct entre eux. Cela peut poser problème si une information cruciale se trouve à la frontière entre deux morceaux.

Dans ce cas, un overlap de 200 tokens est souvent recommandé. Il permet :

  • De préserver la continuité sémantique entre les chunks,
  • D’éviter les effets de bord lors du découpage,
  • D’améliorer la qualité des réponses générées, en donnant accès à un contexte plus riche.

Cette configuration est supportée dans tous les outils de prétraitement modernes comme LangChain, LlamaIndex, ou Haystack.


V. Récapitulatif des bonnes pratiques  

ÉlémentRecommandation par défaut
Taille du chunk~1000 tokens (avec tolérance contrôlée)
Filtrage avant injectionOui, via vector search ou hybrid search
Chevauchement200 tokens
Pertinence contextuellePrioritaire sur la quantité
Fenêtre contextuelleUtiliser uniquement la partie utile

VI. Exemple avec LangChain  

from langchain.text_splitter import RecursiveCharacterTextSplitter

text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000, # découpe en morceaux de 1000 caractères 
    chunk_overlap=200, # chaque chunk partage 200 caractères 
    separators=["\n\n", "\n", ".", "!", "?", ",", " ", ""], # permet de découper de façon plus intelligente en respectant la structure du texte (paragraphes, phrases, etc.)
    length_function=len  # pour compter les caractères  
)

Conclusion  

Les bonnes pratiques ont un usage général. Il vous faudra adapter ces indications à votre projet.

Découper intelligemment, filtrer agressivement, et chevaucher prudemment. Ce sont des leviers techniques simples mais puissants pour améliorer la performance et la robustesse de vos intégrations LLM.

 Comment bien compter les tokens ?
Introduction aux ELB 
  • I. Taille des chunks : pourquoi ~1000 tokens ?  
  • II. Pourquoi découper même avec des LLMs à long contexte ?  
  • III. Pertinence contextuelle : filtrer plutôt que tout injecter  
  • IV. Le chevauchement : un levier souvent sous-estimé  
  • V. Récapitulatif des bonnes pratiques  
  • VI. Exemple avec LangChain  
  • Conclusion  
Suivez-nous

Nous travaillons avec vous !

   
Copyright © 2026 Simple Enough Blog Tous droits réservés. | Propulsé par Hinode.
Simple Enough Blog
Code copié dans le presse-papier