Calculateur de nombre de chunks
Estimez combien de chunks votre dataset de documents produit pour un pipeline RAG – gratuit et totalement privé dans votre navigateur. Configurez le nombre de documents, la moyenne de mots, la taille de chunk, le chevauchement et la stratégie (taille fixe, fenêtre glissante, phrases, paragraphes, récursive ou sémantique). Obtenez instantanément le nombre total de chunks, le coût d'embedding sur 5 fournisseurs et les estimations de stockage vectoriel.
Estimate how many chunks your dataset produces based on document size, chunk size, overlap, and chunking strategy. See total embedding token counts, embedding costs, and vector storage requirements - instantly in your browser.
Dataset
Splits text into equal-sized chunks. Simple and predictable.
Chunk Parameters
Chunk Count Results
Total Chunks
200
Chunks / Doc
2
Avg Doc Tokens
667
Effective Tokens
462
per chunk
Embedding & Storage Estimates
Tokens to Embed
102,400
chunk_count × chunk_size
Embedding Cost
$0.0020
OpenAI text-embedding-3-small
Vector Storage
1.2 MB
1,536 dims × float32
Strategy Comparison (same dataset & chunk size)
| Strategy | Total Chunks | Embed Cost | vs. Fixed |
|---|---|---|---|
Fixed-Size (no overlap)Selected | 200 | $0.0020 | Baseline |
Sliding Window (with overlap) | 200 | $0.0020 | Baseline |
Sentence-Based | 200 | $0.0020 | Baseline |
Paragraph-Based | 200 | $0.0020 | Baseline |
Recursive Character Split | 200 | $0.0020 | Baseline |
Semantic Chunking | 200 | $0.0020 | Baseline |
Pourquoi le nombre de chunks décide du coût du RAG
Dans un pipeline RAG, le nombre de chunks détermine deux coûts à la fois : la génération des embeddings à l'ingestion et le stockage des vecteurs. Une mauvaise stratégie peut multiplier les deux sans améliorer la qualité de récupération.
Saisissez le nombre de documents, la moyenne de mots, la taille de chunk et le chevauchement pour voir combien de chunks le dataset produira et combien coûtera la vectorisation.
- Chunks = ceil((tokens du document − chevauchement) / (taille de chunk − chevauchement)).
- Le coût d'embedding est payé une fois à l'ingestion, mais se répète si le contenu ou le modèle change.
- Le stockage réel dépasse l'estimation brute à cause des métadonnées et index HNSW.
Choisir la stratégie de découpage
Il n'existe pas de stratégie universellement meilleure. La taille fixe est simple et prévisible ; les approches sémantiques et récursives respectent mieux la structure du document mais donnent des coûts moins prévisibles.
- Taille fixe et fenêtre glissante : simples et faciles à budgéter.
- Par phrases et paragraphes : préservent les unités de sens, comptes un peu irréguliers.
- Récursive et sémantique : meilleure récupération, coût plus élevé et moins prévisible.
Régler taille et chevauchement
Commencez à 512 tokens avec 50 de chevauchement, mesurez la qualité de récupération et ajustez. Augmenter le chevauchement améliore la continuité mais renchérit l'ingestion.
- Estimez le nombre de chunks avec votre taille et votre chevauchement actuels.
- Calculez le coût d'embedding et le stockage vectoriel correspondants.
- Testez une seconde configuration (par ex. 256 tokens) et comparez les deux scénarios.
- Choisissez la configuration qui équilibre récupération, coût et volume de stockage.
Foire aux questions
Un chunk est un passage de texte de longueur fixe ou variable issu du découpage d'un document plus grand. Dans un système RAG (Retrieval-Augmented Generation), les documents sont découpés en chunks, chaque chunk est converti en embedding vectoriel, et les embeddings sont stockés dans une base vectorielle. À la requête, les chunks sémantiquement les plus proches sont récupérés et injectés comme contexte dans le prompt LLM.
Pour le découpage à taille fixe : chunks = ceil((tokens_du_document − chevauchement) / (taille_chunk − chevauchement)). Un document de 1 000 tokens avec des chunks de 512 et 50 tokens de chevauchement donne ceil((1000 − 50) / (512 − 50)) = ceil(950 / 462) = 3 chunks par document. Les stratégies par phrases et paragraphes donnent des comptes légèrement différents selon l'alignement des frontières.
Un point de départ courant est 512 tokens avec 50 tokens de chevauchement pour des documents en prose. Des chunks plus petits (128-256 tokens) améliorent la précision de récupération mais manquent de contexte. Des chunks plus grands (1024+ tokens) offrent un contexte plus riche mais peuvent réduire la pertinence. La taille optimale dépend du type de document, du style de requête et du modèle d'embedding. Évaluez toujours la qualité de récupération empiriquement avec votre contenu.
Les tokens de chevauchement sont partagés entre chunks consécutifs. Avec 512 tokens de taille et 50 de chevauchement, les 50 derniers tokens du chunk N deviennent les 50 premiers du chunk N+1. Cela évite de perdre l'information proche des frontières et améliore la continuité pour les requêtes à cheval sur deux chunks. Le chevauchement augmente proportionnellement le nombre total de chunks et le coût d'embedding.
Coût d'embedding = total_chunks × tokens_par_chunk / 1 000 000 × coût_par_million_de_tokens. Par exemple, 1 000 chunks × 512 tokens = 512 000 tokens à vectoriser. Avec OpenAI text-embedding-3-small (0,020 $/M tokens), cela coûte 0,0102 $. Chaque chunk n'est vectorisé qu'une fois à l'ingestion – une nouvelle vectorisation n'est nécessaire que si le contenu change.
Stockage vectoriel = total_chunks × dimensions_embedding × 4 octets (float32). Pour 10 000 chunks avec OpenAI text-embedding-3-small (1 536 dims) : 10 000 × 1 536 × 4 = ~61,4 Mo de vecteurs bruts. Le stockage réel est plus élevé à cause des métadonnées, des structures d'index (graphes HNSW) et de la réplication. Les modèles quantifiés (int8) réduisent cette estimation de moitié.
Oui. Le calculateur fonctionne entièrement dans votre navigateur. Aucun contenu de document, détail de dataset ou configuration n'est envoyé à un serveur. Tous les calculs – nombre de chunks, coût d'embedding, stockage – sont effectués localement sur votre appareil. Vos données restent 100 % privées, sans inscription.