Le prompt tronque en silence

Un modèle local peut produire une réponse sans avoir traité tout le texte que votre application lui a envoyé. Pas forcément d'erreur. Pas forcément d'alerte. Et parfois, rien dans la réponse ne permet de soupçonner qu'une partie du contexte a disparu.

Les outils comme Ollama ou llama.cpp exécutent des modèles dans une fenêtre de contexte dont la capacité dépend du modèle et de sa configuration. Pour un moteur de recherche documentaire, cette limite ne concerne pas seulement les questions posées par les utilisateurs : elle peut aussi affecter les traitements d'arrière-plan qui préparent les documents avant leur recherche.

Nous avions observé ce comportement sur nos propres installations. Nous avons donc voulu mesurer le phénomène à partir du code réel de notre moteur documentaire, puis vérifier ce que le moteur déclarait avoir effectivement traité.

0 / 135 questions dépassent une fenêtre de 4 096 jetons

4 / 40 lots d'ingestion dépassent cette même fenêtre

39 / 40 lots d'ingestion dépassent une fenêtre de 2 048 jetons

1. Une limite qui ne ressemble pas à une panne

Un modèle de langage ne traite pas une quantité illimitée de texte. Il reçoit une séquence de jetons les unités de texte utilisées par le modèle dans une fenêtre de contexte. La taille effective de cette fenêtre dépend notamment du modèle, du moteur d'exécution et de sa configuration.

Dans une application documentaire, le prompt peut réunir les consignes, les passages retrouvés, des métadonnées et parfois un historique. Le volume transmis ne correspond donc pas uniquement à la question visible à l'écran.

Si le prompt dépasse la capacité effectivement utilisée, le comportement dépend de l'implémentation : le moteur peut rejeter la requête, appliquer une troncature ou gérer le contexte d'une autre manière. Dans notre configuration de test, nous avons observé un cas particulièrement difficile à détecter : une réponse était produite alors que le nombre de jetons évalués était nettement inférieur à la taille du prompt construit.

Une requête qui aboutit n'est donc pas, à elle seule, la preuve que tout le contexte prévu a été traité.

2. Ce que nous avons mesuré

Nous avons analysé 175 prompts assemblés par le code réel de notre moteur, à partir de 1 877 passages issus de 308 documents. L'échantillon comprend 135 prompts de question-réponse dont 15 questions de liste ou de synthèse et 40 lots d'ingestion.

Chaque prompt a été compté avec le tokenizer de qwen2.5:7b. Nous avons ensuite soumis à Ollama 0.40.1 des prompts de tailles connues, sous des fenêtres configurées à 2 048 et 4 096 jetons, puis comparé leur taille à ce que le moteur déclarait avoir évalué.

Type de prompt	Nombre	Médiane	Maximum
Questions	135	1 561	3 282
Lots d'ingestion	40	2 939	5 902

Tailles en jetons, mesurées sur les prompts assemblés par notre moteur.

Les prompts de question-réponse restent relativement courts parce que le moteur plafonne le nombre de passages transmis. Les lots d'ingestion sont plus volumineux : ils assemblent jusqu'à dix passages et le début du document afin de générer une phrase qui situe chaque passage dans son contexte.

Cette différence est centrale. Les opérations de fond peuvent manipuler davantage de texte que les questions qui seront ensuite posées à l'assistant.

3. Où se concentre le risque ?

Avec une fenêtre de 4 096 jetons, aucune des 135 questions ne dépasse la limite, mais 4 lots d'ingestion sur 40 la dépassent. Avec une fenêtre de 2 048 jetons, ce sont 39 lots sur 40 qui dépassent cette même limite.

Cela ne signifie pas que tous ces prompts ont nécessairement perdu du texte : le dépassement est un signal de risque, pas encore la preuve d'une troncature. Nous avons donc mené un second test pour observer ce que le moteur déclarait avoir effectivement traité.

4. Ce que le moteur a réellement traité

Nous avons soumis à Ollama 0.40.1 des prompts de tailles connues et relevé le nombre de jetons évalués. Dans les cas testés, le résultat ne correspondait pas simplement à la suppression de l'excédent au-delà de la limite.

Aucune erreur visible. Pourtant, une partie du prompt n'a pas été évaluée.

Dans cette configuration, les prompts dépassant la fenêtre ont été évalués à hauteur d'environ la moitié de la fenêtre configurée. C'est un résultat expérimental propre aux tests effectués, et non une règle générale de fonctionnement des modèles locaux.

Le point important est ailleurs : la longueur du prompt construit ne suffit pas à connaître la quantité de texte effectivement traitée. Il faut observer le comportement du moteur lui-même.

5. Pourquoi l'ingestion mérite une attention particulière

Dans notre moteur, l'ingestion enrichit les passages avec une phrase qui les situe dans leur document d'origine. Le lot peut réunir dix passages et le début du document. Si le prompt dépasse la fenêtre effective et que la fin n'est pas traitée, certains passages peuvent être enrichis sans que le modèle ait lu les éléments correspondants.

Le traitement peut néanmoins continuer. Le corpus risque alors de contenir des enrichissements incomplets, sans que l'application puisse facilement identifier les passages concernés.

Nous n'avons pas encore mesuré l'effet de ce phénomène sur la qualité des réponses finales. Il serait donc incorrect d'affirmer que chaque troncature produit une réponse fausse. Le risque est indirect : une information de contexte absente ou incomplète peut affecter la manière dont un passage sera retrouvé ou interprété plus tard.

C'est ce qui rend le problème intéressant pour les systèmes RAG : une anomalie survenant pendant la préparation du corpus peut avoir des conséquences bien après la requête qui l'a provoquée.

6. Comment rendre le problème détectable

Nos tests conduisent à plusieurs mesures concrètes pour les équipes qui déploient des modèles locaux.

7. Ce que cette étude ne démontre pas

Cette étude mesure un comportement observé dans un environnement précis. Elle ne permet pas d'estimer un taux de troncature valable pour tous les outils d'IA locaux.

Les mesures portent sur un moteur documentaire, un corpus de petite structure aux passages courts, le tokenizer de qwen2.5:7b et Ollama 0.40.1. Les 40 lots d'ingestion proviennent chacun d'un seul document : les observations ne sont donc pas indépendantes. L'historique de conversation et les notes de dossier n'ont pas été comptabilisés, ce qui signifie que les prompts complets d'une application en production pourraient être plus longs.

Enfin, nous n'avons pas encore comparé la qualité des réponses avec et sans troncature. La prochaine étape consiste à mesurer les effets éventuels sur la récupération documentaire, la justesse des réponses et l'utilisation des sources.

Le protocole, les questions, les mesures prompt par prompt et le script de vérification sont publiés avec l'étude.

PROTYPA · Subsidia
Une question, un désaccord ou une mesure à nous proposer ? Répondez à cet email. Nous sommes intéressés par les observations reproductibles sur d'autres versions d'Ollama, llama.cpp et différents modèles locaux.