Kimi K3 : un million de tokens ne suffit pas à remplacer RAG ?

UN MILLION DE TOKENS, UNE PROMESSE ALLÉCHANTE

Quand Kimi K3 est sorti en juillet avec un contexte d'un million de tokens, une question s'est imposée : peut-on enfin se passer de RAG (Retrieval Augmented Generation) ?

Le calcul semble simple. Une sélection de 33 articles publiés sur deux ans représente 127 068 tokens, soit 12 % de la fenêtre de Kimi K3. Pourquoi ne pas tout coller dans le prompt au lieu de découper en morceaux, calculer des embeddings et s’inquiéter de la qualité de la récupération ?

Mais entre « ça rentre » et « ça marche mieux », il y a un monde. C’est précisément ce que l’auteur a voulu mesurer dans une expérience contrôlée. Le résultat ? Une surprise qui remet en question bien des idées reçues.

UNE EXPÉRIENCE CONTRÔLÉE, UNE SEULE VARIABLE

Pour éviter tout biais, l’expérience repose sur trois piliers :

• • 12 questions identiques pour les deux méthodes (RAG et long_context)
• • Un même modèle (Kimi K3)
• • Un même prompt système pour garantir que les différences viennent uniquement de la stratégie de récupération

Le prompt système est crucial : il impose au modèle d’utiliser uniquement le texte fourni, de citer la source de chaque fait, et d’avouer son ignorance plutôt que de deviner. Une consigne simple, mais qui change tout.

LE CORPUS : 33 ARTICLES, DEUX VERSIONS D’UN MÊME SUJET

Le corpus est composé de 32 fichiers contenant 33 articles écrits par l’auteur entre 2022 et 2024, publiés sur Medium et Towards Data Science. Au total, 127 068 tokens, mesurés avec tiktoken et cl100k_base.

Deux sujets apparaissent deux fois : une version sur Medium, une autre sur Towards Data Science. Cette duplication n’est pas un hasard, mais un choix délibéré pour tester la capacité du modèle à gérer les répétitions.

L’auteur a découvert cette duplication pendant l’évaluation : deux articles s’étaient retrouvés dans le même fichier, et les deux modèles (RAG et long_context) l’ont signalé indépendamment.

DEUX STRATÉGIES, DEUX APPROCHES RADICALEMENT DIFFÉRENTES

La première stratégie, RAG, suit la méthode classique :

• • Les articles sont découpés en 788 chunks de 900 caractères, avec un chevauchement de 150 caractères
• • Chaque chunk est transformé en embedding avec le modèle all-MiniLM-L6-v2
• • Les cinq chunks les plus pertinents sont envoyés au modèle avec la question
• • Résultat : environ 1 200 tokens par requête

La deuxième stratégie, long_context, envoie l’intégralité des 32 articles avec chaque question. Résultat : 127 346 tokens par requête, soit cent fois plus que RAG.

L’ORDRE DU CORPUS ET DE LA QUESTION : UNE QUESTION DE COÛT

Un détail technique change tout : le corpus doit toujours venir avant la question dans le prompt. Pourquoi ? Parce que le prefix caching (mise en cache du préfixe) ne fonctionne que si le début du message reste identique d’une requête à l’autre.

Exemple concret : imaginez un collègue à qui vous remettez un dossier épais avec une question différente à chaque fois. La première fois, il doit tout lire. Les fois suivantes, il se souvient déjà du contenu. C’est exactement ce que fait le fournisseur en arrière-plan. Mais si vous changez ne serait-ce qu’un mot au début, tout est à refaire.

Résultat : le coût varie entre 0,30 $ et 3,00 $ par million de tokens en entrée. Sans cette astuce, chaque requête coûterait huit fois plus cher.

# Le contexte vient toujours avant la question. L'ordre compte : # le prefix caching ne fonctionne que si le début du message reste identique # d'un appel à l'autre. messages = [     {"role": "system", "content": config.SYSTEM_PROMPT},     {"role": "user", "content": f"{context}\n\n---\n\nQuestion: {question}"}, ]

12 QUESTIONS, TROIS NIVEAUX DE DIFFICULTÉ

Les 12 questions sont réparties en trois groupes de quatre, chacun testant une compétence différente du modèle :

Groupe A : Faits uniques (A1-A4)

La réponse se trouve dans un seul article, à un seul endroit précis. Exemple : « Quel modèle d’embedding as-tu utilisé dans ton expérience sur la taille des chunks, et pourquoi ? »

Groupe B : Sources croisées (B1-B4)

La réponse nécessite de croiser deux ou trois articles. Exemple : « Quand recommandes-tu RAG et quand recommandes-tu le fine-tuning ? Inclus les endroits où tu te contredis. »

Groupe C : Corpus entier (C1-C4)

La réponse exige que le modèle ait vu l’intégralité du corpus. Exemple : « Combien de tes articles contiennent un lien vers un dépôt GitHub, et lesquels ? »

Pour le groupe C, le résultat était prévisible : cinq chunks ne peuvent pas répondre à une question couvrant 32 articles. Mais l’intérêt de ce groupe n’est pas de savoir si RAG échoue, mais comment il échoue. Le modèle avouera-t-il honnêtement son ignorance, ou inventera-t-il une réponse convaincante ?

L’ÉVALUATION : UNE NOTE À L’AVEUGLE POUR ÉVITER LES BIAIS

Plutôt que de s’auto-évaluer, l’auteur a utilisé une méthode plus fiable : une feuille de notation automatisée (makegradingsheet.py).

Chaque paire de réponses (une de RAG, une de long_context) est mélangée et présentée sous forme de A1-X et A1-Y, sans indication de la méthode utilisée. La clé de correspondance reste dans un fichier séparé, fermé jusqu’à la fin.

Cependant, l’évaluation n’était pas totalement aveugle : certaines réponses se trahissaient avec des phrases comme « d’après les chunks de texte que j’ai reçus ». Une formulation impossible pour long_context, qui ne travaille qu’avec le corpus complet. L’auteur a donc dû faire attention à ne pas se laisser influencer.

Les réponses sont notées sur trois critères, de 0 à 2 points :

• • Correctness (exactitude) : la réponse est-elle factuellement correcte ?
• • Completeness (complétude) : la réponse est-elle complète et précise ?
• • Grounding (sources) : la réponse provient-elle bien du corpus fourni, et non des connaissances internes du modèle ?

La différence entre correctness et grounding est cruciale. Une réponse peut être correcte sans être ancrée dans le corpus. C’est exactement ce que l’expérience voulait tester.

TROIS PIÈGES QUI ONT FAILLIS L’EXPÉRIENCE

L’expérience a révélé trois problèmes majeurs, plus instructifs que les résultats eux-mêmes :

1. Le budget de réponse épuisé par la réflexion

Kimi K3 est un modèle de raisonnement : il génère des étapes de réflexion internes avant de produire la réponse finale. Ces tokens de réflexion comptent contre le même budget que la réponse visible.

Dans la première tentative, l’auteur avait fixé maxcompletiontokens à 800. Pour les questions difficiles, le modèle a utilisé les 800 tokens à réfléchir, laissant rien pour la réponse. Résultat : 12 réponses vides sur 24, et 3 autres interrompues en plein milieu d’un mot.

La solution ? Augmenter la limite à 4 000 tokens. Mais même ainsi, une question (C2) a échoué : le modèle a réfléchi pendant 3 997 tokens et n’a rien produit. Après une seconde tentative, la même question a été résolue en 884 tokens de réflexion.

Leçon apprise : dans un modèle de raisonnement, maxcompletiontokens ne limite pas la longueur de la réponse, mais le budget de réflexion. Si ce budget est épuisé, la réponse est vide, même si le modèle semble avoir fonctionné normalement.

@property
def truncated(self) -> bool:
    """Le modèle a épuisé son budget de réponse avant de finir sa réponse."""
    return self.finish_reason == "length" or not self.answer.strip()

2. Le cache de préfixe qui ne fonctionne pas toujours

Le prefix caching est censé réduire les coûts en réutilisant les tokens déjà lus. Pourtant, dans l’expérience, il n’a fonctionné que 3 fois sur 8 appels. Pire : après cinq jours, même une seule question supplémentaire n’a pas bénéficié du cache.

Résultat : un appel avec cache coûte 0,0466 $, sans cache 0,3916 $. Soit huit fois plus cher.

Leçon apprise : avec long_context, le vrai défi n’est pas le prix par token, mais la limite quotidienne et la fiabilité du cache. Deux éléments absents des grilles tarifaires.

3. Des coûts imprévisibles

L’auteur avait estimé le coût en supposant que le cache fonctionnerait à chaque appel. Résultat : la facture réelle était 30 % plus élevée que l’estimation optimiste. Une différence qui peut faire basculer un projet rentable en gouffre financier.

LES RÉSULTATS : UNE SURPRISE DE TAILLE

Après l’évaluation, l’auteur a ouvert la clé de correspondance. Les résultats ont été totalement inattendus.

Long_context a obtenu la note maximale (2/2) sur les 12 questions, dans les trois groupes et sur les trois critères. Un sans-faute.

RAG, en revanche, a échoué sur la complétude. Ses réponses étaient souvent incomplètes ou trop vagues, même si elles étaient correctes et bien sourcées.

Le détail par critère est révélateur :

• • Grounding : RAG et long_context sont à égalité (2,00/2)
• • Correctness : RAG est juste en dessous (1,92/2)
• • Completeness : RAG obtient seulement 0,83/2

En clair : RAG n’a rien inventé et n’a presque rien dit de faux. Mais ses réponses étaient souvent incomplètes ou imprécises.

Exemple frappant avec la question C1 : « Combien de tes articles contiennent un lien vers un dépôt GitHub, et lesquels ? »

Réponse de RAG :

« D’après les chunks de texte fournis, aucun des extraits ne contient de lien vers un dépôt GitHub. […] Attention : il s’agit de chunks récupérés et non des articles complets, donc il est possible qu’un lien GitHub existe ailleurs dans le texte d’un de ces articles. »

Réponse de long_context :

« 13 articles contiennent un lien vers un dépôt GitHub avec le code de l’article » suivi d’une liste avec une citation à l’appui pour chaque article.

Autre exemple avec la question C2 : « Quels sont les Outils les plus mentionnés dans tes articles ? »

Réponse de RAG :

« Je ne peux pas répondre de manière définitive. Je n’ai que des chunks incomplets de cinq articles (002, 010, 012, 016, 027), pas le texte complet de tes articles. Ton corpus contient clairement plus que ces cinq. Compter les mentions dans des chunks incomplets d’un sous-ensemble ne te dirait pas ce qui est le plus fréquent dans tous tes articles, donc je ne vais pas deviner une top cinq. »

Réponse de long_context :

Une liste complète des outils les plus cités, avec des citations précises.

Ces réponses montrent que RAG sait reconnaître ses limites, mais ne peut pas toujours fournir une réponse complète. Long_context, lui, a accès à l’intégralité du corpus et peut répondre précisément.

COÛT, TEMPS ET LATENCE : LE VERDICT EST CRU

Les différences de coût et de temps sont sans appel :

« Long_context coûte seize fois plus cher et prend trois fois plus de temps que RAG. »

Sur les faits uniques (A1-A4) : les deux méthodes sont proches. RAG est légèrement plus rapide sur A1 à A3, mais long_context est même un peu plus rapide sur A4.

Sur les sources croisées (B1-B4) : long_context prend deux à trois fois plus de temps.

Sur les questions corpus entier (C1-C4) : l’écart se creuse. La question C3 prend 273,7 secondes pour long_context contre 46,3 secondes pour RAG.

Pourquoi ? Parce que long_context pense deux à dix fois plus que RAG. Le temps ne vient pas de la lecture du contexte, mais de son analyse.

Exemple extrême : la question C2. Long_context a pensé pendant 3 997 tokens avant d’échouer, puis a réussi en 884 tokens lors d’une seconde tentative. RAG, lui, a résolu la question en quelques secondes.

QUAND UTILISER LONG_CONTEXT, QUAND UTILISER RAG ?

Les résultats sont clairs : long_context excelle en qualité, mais RAG reste imbattable sur coût et temps.

Utilisez long_context si :

• • Votre corpus est petit (moins de 100 000 tokens)
• • Vous avez besoin de réponses complètes et précises
• • Vous pouvez accepter un coût élevé et une latence importante
• • Vous voulez des réponses totalement sourcées dans le corpus

Utilisez RAG si :

• • Votre corpus est volumineux (plusieurs millions de tokens)
• • Vous avez besoin de réponses rapides et peu coûteuses
• • Vous pouvez accepter des réponses partielles ou approximatives
• • Vous ne craignez pas que le modèle invente des détails

Attention : RAG ne convient pas si vous avez besoin de réponses corpus-entier. Dans ce cas, long_context est indispensable, même si le coût est élevé.

CE QU’IL FAUT RETENIR

Cette expérience démontre que Kimi K3 avec un million de tokens ne remplace pas RAG, mais le complète. Voici les leçons clés :

« Un million de tokens ne suffit pas à tout savoir. La méthode compte plus que la taille. »

1. La taille du contexte ne garantit pas la qualité

Longcontext a obtenu un sans-faute, mais à quel prix ? Seize fois plus cher et trois fois plus lent que RAG. Pour un corpus de 127 000 tokens, longcontext est trop coûteux pour un usage quotidien.

2. RAG a des limites, mais elles sont prévisibles

RAG ne peut pas répondre à des questions corpus-entier, mais il avoue honnêtement son ignorance plutôt que d’inventer. C’est une sécurité précieuse.

3. Le cache de préfixe est imprévisible

Ne comptez pas dessus pour réduire vos coûts. Dans l’expérience, il n’a fonctionné que 33 % du temps, et même une pause de cinq jours a suffi à le vider.

4. Les modèles de raisonnement ont des budgets cachés

Un maxcompletiontokens de 800 peut sembler généreux, mais si le modèle utilise tout ce budget pour réfléchir, il ne restera rien pour la réponse.

5. Le prompt système est crucial

Sans la consigne « Si le texte ne contient pas la réponse, avoue-le au lieu de deviner », RAG aurait pu inventer des réponses plausibles mais fausses. Une instruction simple change tout.

En résumé : long_context est une avancée majeure pour la qualité, mais RAG reste indispensable pour l’efficacité. Le choix dépend de vos priorités.

POUR ALLER PLUS LOIN

Si ce sujet vous intéresse, voici quelques pistes pour approfondir :

• • Lire le code complet de l’expérience sur GitHub
• • Explorer les benchmarks de modèles avec grands contextes (comme Kimi K3, Claude 3.5 Sonnet, GPT-4o)
• • Tester RAG avec différents modèles d’embeddings et stratégies de récupération
• • Comprendre le fonctionnement des tokens et du prefix caching
• • Étudier les limites des modèles de raisonnement et leur impact sur les coûts