Empaqueteur de Contexte IA

Divisez code, documents ou transcriptions longs en fragments numérotés adaptés au modèle pour Claude, GPT, Gemini ou Llama. Tokens et coût estimés.

Vous avez des commentaires ? Signalez des bugs, suggérez des fonctionnalités ou partagez vos idées — nous lisons tout

Qu'est-ce que l'Empaqueteur de Contexte IA?

Lorsque vous avez besoin qu'un LLM raisonne sur un document, une base de code ou une transcription longue qui dépasse votre fenêtre de chat, vous avez deux choix: mettre à niveau votre modèle ou diviser l'entrée en fragments conscients du contexte et les alimenter séquentiellement. Cet outil fait le second — rapide, gratuit et dans votre navigateur. Collez ou téléchargez du texte, choisissez votre modèle cible (Claude, GPT-4o, GPT-5, Gemini, Llama ou une limite personnalisée), et l'empaqueteur émet des blocs numérotés '## Fragment i sur N' dimensionnés pour tenir confortablement sous la fenêtre de contexte du modèle.

Caractéristiques Principales

Préréglages pour Claude (200K et 1M), GPT-4o (128K), GPT-5 (256K), Gemini 2.5 (2M), Llama 3.3 (128K)
Limite de tokens personnalisée pour tout autre modèle ou déploiement Llama/Mistral local
Diviseur intelligent qui respecte les titres markdown, puis paragraphes, puis lignes, avant de recourir aux coupes dures
Chevauchement configurable (0-50%) pour que les fragments consécutifs partagent le contexte final — améliore la cohérence
Estimation de tokens en direct (~3,7 caractères/token, l'heuristique documentée OpenAI précise à ±10% pour code et anglais)
Aperçu du coût d'entrée utilisant les prix actuels par million de tokens
Copie en un clic par fragment avec en-tête markdown '## Fragment i sur N' auto-généré
Charge jusqu'à 50MB depuis un fichier local — txt, md, json, csv, log, html, css, js, ts, py, go et plus

Empaqueteur de Contexte IA — Divisez code, documents ou transcriptions longs en fragments numérotés adaptés au modèle pour Claude, GPT, Gemini ou Lla — **Empaqueteur de Contexte IA**

Comment l'Utiliser

Collez votre texte long dans la boîte source (ou cliquez sur Charger Fichier pour téléverser depuis le disque)
Choisissez le modèle cible — la taille de fragment est par défaut 25% du contexte max du modèle
Ajustez la taille si vous voulez des prompts plus petits et plus ciblés (fragments plus petits = plus de tours mais meilleur rappel)
Définissez le chevauchement à 5-15% pour la prose, 0% pour le code (le chevauchement peut confondre sur entrée structurée)
Choisissez une stratégie — Intelligent fonctionne pour 95% des entrées; utilisez Lignes pour les logs, Paragraphes pour la prose
Cliquez sur Empaqueter, puis copiez chacun dans l'ordre et collez dans votre modèle avec un bref contexte

Questions Fréquentes

Chaque modèle utilise un tokeniseur différent: GPT-4/5 utilise cl100k_base, GPT-3.5 utilisait p50k, Claude utilise le tokeniseur propriétaire d'Anthropic, Gemini utilise SentencePiece, et Llama 3 utilise son propre vocabulaire 128K. Exécuter chaque tokeniseur côté client signifierait envoyer plus de 5MB de WebAssembly. L'heuristique de ~3,7 caractères/token est ce qu'OpenAI publie dans la documentation et est précise à ±10% pour le texte anglais et le code typique — assez bon pour la planification de taille où vous laissez habituellement 10-20% de marge.

Règle empirique: 0% pour code ou données structurées (XML, JSON, CSV), 5-10% pour documents techniques, 15-25% pour prose, transcriptions et notes de réunion. Le chevauchement aide le modèle à maintenir la continuité à travers les frontières de fragments. Mais trop de chevauchement coûte des tokens ET dit au modèle des choses contradictoires s'il voit le même passage deux fois avec un contexte différent. 10% est une valeur par défaut sensée.

Meilleure pratique: envoyez d'abord un message 'système' décrivant ce qui vient, puis les fragments dans l'ordre. Exemple: 'Je vais vous envoyer une base de code longue divisée en 8 fragments. Lisez chacun et ne répondez OK qu'après chacun. Quand je dis TERMINÉ, résumez l'architecture.' Puis collez chaque fragment textuellement (l'en-tête ## Fragment i sur N dit au modèle où il est). Après le dernier, envoyez votre vraie question.

Principalement oui. Il divise sur les titres markdown (#, ##, ###) en premier, puis paragraphes de ligne vide, puis lignes individuelles, puis coupes dures uniquement en dernier recours. Le code clos dans ``` ne sera pas divisé au milieu du bloc à moins qu'un bloc unique ne dépasse la taille du fragment — auquel cas il tombe en division ligne par ligne. Pour les fonctions uniques très longues, envisagez de prétraiter avec un outil comme ts-prune ou astgrep pour extraire les sous-graphes pertinents.

Le coût affiché est UNIQUEMENT le coût d'ENTRÉE — envoyer votre texte dans le modèle une fois. Cela n'INCLUT PAS: (1) les tokens de sortie du modèle (typiquement 3-10× plus chers que l'entrée), (2) les envois répétés si vous renvoyez des fragments pour des questions de suivi, (3) les remises de cache de prompt (Claude et OpenAI offrent maintenant 50-90% de remise sur préfixe caché), ou (4) les remises d'API batch (50% si vous pouvez attendre 24h).

Oui, mais avec mises en garde. Pour les embeddings (text-embedding-3, voyage-3, etc.) les tailles de fragment sont typiquement 500-1500 tokens — beaucoup plus petites que l'empaquetage de contexte de chat. Définissez la taille à 1000 et le chevauchement à 100 (10%) pour un pipeline RAG standard. Le diviseur intelligent conscient des paragraphes est bien adapté car la récupération RAG fonctionne mieux lorsque chaque fragment représente une unité sémantique cohérente.

50MB de texte brut via le sélecteur de fichiers, soit environ 13 millions de tokens — bien au-delà du contexte de tout modèle actuel. Le navigateur gère jusqu'à ~100MB de texte dans un textarea sans figer sur matériel moderne. Si vous avez des entrées plus grandes (bases de code entières, fichiers log de plusieurs GB), prétraitez avec grep/ripgrep ou un script côté serveur pour extraire la tranche pertinente avant de charger.

Voir aussi