Calculateur de taille de chunk
Trouvez gratuitement la taille de chunk et le chevauchement optimaux pour votre pipeline RAG. Configurez la taille du corpus, le type de contenu, le modèle d'embedding et la fenêtre de contexte du LLM pour obtenir des scores de qualité, une analyse du budget de contexte et des projections de coût d'embedding – totalement privé, sans inscription.
Find the optimal chunk size for your RAG pipeline. Configure document size, content type, embedding model, and LLM context window to get recommended chunk settings, quality scores, and cost projections.
Document Corpus
Blog posts, documentation, books, reports
Chunk Configuration
= 51 overlap tokens per chunk boundary
Model Configuration
Query Context Budget
Configuration Quality
Chunk: 512 tokens
Overlap: 10% (51 tokens)
Chunks / Doc
109
Total Chunks
10,900
Max Chunks in Ctx
247
Context Used
3%
Query Context Breakdown
Indexing Cost (one-time)
$0.1116
10,900 chunks × 512 tokens
Query Input Cost / Call
$0.0102
4,060 tokens on GPT-4o
Chunk Size Comparison
Your overlap: 10% fixed| Chunk Size | Chunks/Doc | Total Chunks | Embed Cost | Ctx Fits? | Quality |
|---|---|---|---|---|---|
128 tokens | 435 | 43,500 | $0.1114 | ✓ Yes | Good |
256 tokens | 218 | 21,800 | $0.1116 | ✓ Yes | Excellent |
512 tokens Current | 109 | 10,900 | $0.1116 | ✓ Yes | Excellent |
768 tokens | 73 | 7,300 | $0.1121 | ✓ Yes | Fair |
1024 tokens | 55 | 5,500 | $0.1126 | ✓ Yes | Good |
1500 tokens | 37 | 3,700 | $0.1110 | ✓ Yes | Fair |
2048 tokens | 28 | 2,800 | $0.1147 | ✓ Yes | Poor |
Comment la taille de chunk change qualité et coût
Des chunks plus petits améliorent la précision de récupération, car le vecteur représente un concept plus précis, mais apportent moins de contexte au modèle. Des chunks plus grands font l'inverse : plus de contexte par chunk, moins de précision et un coût de contexte plus élevé par requête.
Configurez la taille du corpus et le modèle d'embedding pour voir évoluer le score de qualité, le coût d'indexation et la consommation par requête.
- Prose générale : 512 tokens avec 10-15 % de chevauchement est un bon départ.
- Questions-réponses : 256 tokens ; documents juridiques : 800-1 024 tokens.
- Code : 256-512 tokens alignés sur les fonctions, avec 5-10 % de chevauchement.
Budget de contexte et nombre de chunks
La fenêtre de contexte du LLM doit accueillir le prompt système, les chunks récupérés et la réponse attendue. Récupérer plus de chunks que la fenêtre ne peut en contenir ne fait que consommer du budget.
- Commencez par récupérer 3-5 chunks et ajustez selon la taille choisie.
- Avec des chunks de 256 tokens, vous pouvez en récupérer 8-10 sans saturer le contexte.
- Surveillez la limite d'entrée du modèle d'embedding : la dépasser tronque le texte silencieusement.
Itérer jusqu'à votre configuration
La configuration optimale dépend de votre corpus et de vos vraies requêtes. Considérez le calculateur comme un point de départ et validez par des tests de récupération de bout en bout.
- Choisissez une taille de chunk initiale selon le type de contenu.
- Calculez le nombre de chunks, le coût d'indexation et la consommation par requête.
- Comparez deux ou trois configurations et observez le score de qualité relatif.
- Validez la meilleure avec de vraies requêtes avant d'indexer tout le corpus.
Foire aux questions
Dans un pipeline RAG, les documents sont découpés en segments plus petits appelés chunks avant d'être vectorisés et stockés dans une base vectorielle. La taille de chunk – mesurée en tokens – détermine la quantité de texte par segment. Elle compte car elle influence directement la précision de récupération, la richesse du contexte, le coût d'embedding et la consommation de contexte du LLM par requête.
Pour de la prose anglaise générale, 512 tokens avec 10-15 % de chevauchement est un point de départ très répandu. Les documents de questions-réponses gagnent à utiliser des chunks de 256 tokens. Les documents juridiques fonctionnent mieux avec 800-1 024 tokens. Le code source devrait utiliser 256-512 tokens alignés sur les frontières de fonctions. Validez toujours par des tests de récupération de bout en bout.
Le chevauchement répète les N derniers tokens d'un chunk au début du suivant pour éviter que le contexte soit coupé aux frontières. Un chevauchement de 10-20 % de la taille du chunk est standard pour la prose. Un chevauchement très faible risque des artefacts de bord ; un chevauchement très élevé gonfle votre base vectorielle. Le code utilise plutôt 5-10 %.
Chaque modèle d'embedding a une limite maximale de tokens en entrée. OpenAI text-embedding-3-small supporte jusqu'à 8 191 tokens par entrée, tandis que Cohere embed-english-v3 plafonne à 512. Le calculateur affiche un avertissement si la taille de chunk configurée dépasse la limite du modèle d'embedding sélectionné.
Un point de départ courant est 3-5 chunks. Avec des chunks plus petits (256 tokens), vous pouvez en récupérer davantage (8-10) sans saturer le contexte. Utilisez la visualisation du budget de contexte pour vérifier que prompt système + chunks récupérés + réserve de réponse tiennent dans la fenêtre de contexte du LLM.
Coût d'embedding = nombre total de chunks × taille du chunk en tokens × coût par token du modèle. Par exemple, 10 000 chunks de 512 tokens avec OpenAI text-embedding-3-small (0,020 $/1 M tokens) = environ 0,10 $. C'est un coût d'indexation unique – la réindexation n'est nécessaire que si les documents changent ou si vous changez de modèle d'embedding.
Oui sur les deux points. Le calculateur est 100 % gratuit, sans compte. Tous les calculs s'exécutent entièrement dans votre navigateur : aucune configuration ni donnée de coût n'est envoyée à un serveur. La conception de votre pipeline RAG reste totalement privée sur votre appareil.