Le modèle refuse de lire le document : test chez trois fournisseurs
Un test de contexte a révélé un content_filter systématique pour tout document dépassant ~2000 tokens chez AWS, le producteur et Google. Même un texte sur les plantes.
👁 119 lectures
Nous avons préparé un test de contexte pour modèles : un document contenant des informations cachées, des questions à leur sujet, puis vérification du nombre d’informations retrouvées. Le résultat était zéro, nous avons donc d’abord pensé que le modèle avait une mémoire faible. Après examen de la réponse brute de l’API, il s’est avéré que le modèle n’avait pas lu un seul mot - l’entrée avait été rejetée par la modération et était revenue avec content_filter et native_finish_reason: refusal.
Conclusion en un paragraphe
Zéro résultat dans un test de mémoire n’est pas toujours la preuve d’un contexte court. Dans notre mesure, le modèle renvoyait content_filter et native_finish_reason: refusal pour CHAQUE document dépassant environ 2000 tokens, et ce chez trois fournisseurs indépendants - AWS, l’API du producteur et Google. Le refus concernait même un texte sur les plantes, sans aucun contenu technique, nom d’outil ou quoi que ce soit pouvant être considéré comme sensible. Lorsque nous avons substitué un modèle de remplacement sur le même matériel et les mêmes questions, il a trouvé 6 informations cachées sur 6 en 2,3-4,9 s. La tâche était donc réalisable, et le résultat précédent mesurait la modération, pas la mémoire.
Comment s’est déroulé le test de contexte
Le schéma était simple et volontairement ennuyeux. Nous prenions un document, y insérions six informations spécifiques à différents endroits - au début, au milieu, près de la fin - puis posions six questions, une par information cachée. Nous comptions les résultats et le temps de réponse. Rien de plus.
Nous commencions le matériel de test par une version courte et augmentions progressivement. C’est important, car cette procédure a permis de voir où se situe la limite. En dessous d’environ 2000 tokens, les réponses arrivaient normalement. Au-dessus - content_filter, à chaque fois, sans exception.
Pour exclure le contenu comme cause, nous avons remplacé le document par un texte sur les plantes. Zéro terminologie technique, zéro code, rien de controversé. Refus identique.
Trois fournisseurs, même limite de contexte IA
La première pensée face à un refus est généralement : quelque chose dans la configuration de ce point d’accès spécifique. Nous avons donc répété le test sur trois chemins d’accès indépendants - AWS, directement chez le producteur du modèle et chez Google. Ce sont des infrastructures séparées, des panneaux séparés, des paramètres de sécurité séparés. Le comportement était identique.
C’est pour nous l’élément le plus fort de toute la mesure. Si le problème résidait dans notre code ou dans un seuil de modération mal configuré, il ne se serait pas reproduit sur trois plateformes simultanément.
| Élément | Avant diagnostic (modèle refusant) | Après substitution (modèle de remplacement) |
|---|---|---|
| Résultats sur informations cachées | 0 - pas de réponse de fond | 6 sur 6 |
| Temps de réponse | sans objet - refus | 2,3-4,9 s |
| Statut renvoyé | content_filter, native_finish_reason: refusal |
fin normale |
| Seuils de refus | chaque document au-dessus de ~2000 tokens | aucun |
| Texte sur les plantes | refus | traité |
| Nombre de fournisseurs avec ce comportement | 3 sur 3 (AWS, producteur, Google) | 0 |
Pourquoi un refus du modèle se confond facilement avec une mémoire faible
La plupart des bibliothèques clientes et surcouches affichent un contenu de réponse vide ou un court message de remplacement. Le code de raison de fin est souvent caché un champ plus profond et personne ne le regarde si le script de test se contente de compter les résultats. Dans cette configuration, une chaîne vide ressemble exactement à « le modèle n’a pas trouvé l’information ».
L’effet est trompeur, car un résultat nul correspond à l’hypothèse intuitive. Nous nous attendons à ce qu’un long document charge la mémoire, donc un échec sur un long document semble confirmer cela. Or nous mesurons quelque chose de complètement différent : si le matériel est passé par le filtre d’entrée.
C’est notre opinion, mais nous pensons qu’une partie des comparaisons publiées sur les « limites de contexte IA » mesurent justement la modération. Nous n’avons pas de données là-dessus au-delà de notre propre mesure, donc nous traitons cela uniquement comme une hypothèse, pas comme un fait établi.
Ce qui a concrètement changé après substitution du modèle
Après le changement pour un autre modèle, nous n’avons touché à rien d’autre. Même document, mêmes six questions, même ordre, même infrastructure. Résultats : 6 sur 6. Temps : de 2,3 à 4,9 s, selon la profondeur de l’information recherchée dans le document.
La dispersion 2,3-4,9 s est aussi une information. Elle montre que le modèle parcourt réellement le matériel, et ne répond pas de mémoire à partir d’un modèle. S’il répondait par des généralités, les temps seraient plus uniformes.
Le plus important : puisque le second modèle a accompli la tâche entièrement, la tâche était réalisable. Le zéro précédent n’était pas une évaluation de la difficulté du test.
Quand suspecter la modération plutôt que le contexte
De notre mesure ressortent plusieurs signaux d’alerte. Premier : le résultat ne se dégrade pas progressivement, mais chute brutalement. Un vrai problème de mémoire donne généralement une transition douce - d’abord une information est perdue, puis une deuxième. Le filtre d’entrée bascule de manière binaire.
Deuxième signal : la limite tombe à une valeur ronde et basse. Environ 2000 tokens, c’est nettement trop peu pour parler d’épuisement de la fenêtre de contexte de n’importe quel modèle contemporain. Si le résultat s’effondre si tôt, ce n’est presque certainement pas le contexte qui est en cause.
Troisième : refus pour du contenu sûr. Un texte sur les plantes est un bon matériel de contrôle justement parce qu’il n’y a rien à bloquer. Si lui aussi revient avec un refus, la cause réside dans le volume ou dans la configuration, pas dans le sujet.
Comment vérifier chez vous
- Enregistrez les réponses API brutes complètes, pas seulement le champ de contenu. Ce qui vous intéresse, ce sont les codes de raison de fin - dans notre cas, c’étaient
content_filteretnative_finish_reason: refusal. - Préparez un document avec six informations cachées réparties du début à la fin du texte. Notez où exactement chacune se trouve.
- Lancez le test sur une version courte, nettement en dessous de 2000 tokens. C’est votre point de référence - si ça ne fonctionne pas ici, le problème est dans le prompt, pas dans la longueur.
- Augmentez le volume du document par paliers et notez à quelle valeur apparaît le premier refus. Si la limite tombe brutalement et non progressivement, pensez au filtre.
- Substituez un matériel thématiquement neutre - chez nous, c’était un texte sur les plantes. Si lui aussi revient avec un refus, le contenu n’est pas la cause.
- Répétez chez un deuxième et un troisième fournisseur. Nous avons vérifié AWS, l’API du producteur et Google. La concordance du comportement sur trois plateformes exclut une erreur de configuration locale.
- Remplacez le modèle par un autre, sans rien changer d’autre. S’il trouve les six informations, vous avez la preuve que le test était réalisable, et que le zéro précédent mesurait autre chose.
- Enregistrez les temps de réponse séparément pour chaque question. La dispersion - chez nous 2,3-4,9 s - confirme que le modèle parcourt réellement le matériel.
D’où viennent ces chiffres
Toutes les valeurs proviennent de notre mesure effectuée avant le 21.09.2026. Nous avons testé un modèle via trois chemins d’accès indépendants : AWS, l’API directe du producteur et Google. Matériel de test : document avec six informations cachées, mis à l’échelle en volume, plus une version de contrôle sur les plantes sans contenu technique. Les refus avec codes content_filter et native_finish_reason: refusal sont survenus pour chaque document dépassant environ 2000 tokens chez les trois fournisseurs. Le modèle de remplacement sur le même ensemble de tâches a trouvé 6 informations cachées sur 6 en 2,3-4,9 s. Nous ne donnons pas les noms des modèles ni les seuils exacts de modération, car nous n’avons pas confirmation que les paramètres côté fournisseurs sont restés inchangés après la date de mesure. Les passages marqués comme opinion sont nos conclusions, pas des résultats de mesure.
More on this from PROMPTIF
outils d'ia·PNG transparent avec Qwen-Image-2.1 : test du canal alpha22,7 % de pixels totalement transparents et une plage alpha complète de 0 à 255. Comment demander la transparence et ce qu'il faut surveiller.