AI-model weigert documenten te lezen: test bij drie providers
Contexttest toonde content_filter bij elk document boven ~2000 tokens op AWS, bij de maker en in Google. Zelfs voor tekst over planten.
👁 115 keer gelezen
We bereidden een contexttest voor AI-modellen voor: een document met verborgen informatie, vragen erover, en controle hoeveel het model terugvindt. Het resultaat was nul, dus even dachten we dat het model een zwak geheugen had. Na inspectie van de ruwe API-respons bleek dat het model geen woord had gelezen - de input was afgewezen door moderatie en kwam terug met content_filter en native_finish_reason: refusal.
Conclusie in één alinea
Nul treffers in een geheugentest is niet altijd bewijs van een korte context. In onze meting gaf het model content_filter en native_finish_reason: refusal voor ELK document boven ongeveer 2000 tokens, en dat bij drie onafhankelijke providers - AWS, de API van de maker en Google. De weigering gold zelfs voor tekst over planten, zonder technische inhoud, toolnamen of iets dat als gevoelig beschouwd zou kunnen worden. Toen we een vervangend model gebruikten op hetzelfde materiaal en dezelfde vragen, scoorde het 6 van de 6 verborgen informatie-items in 2,3-4,9 s. De taak was dus uitvoerbaar, en het eerdere resultaat mat moderatie, niet geheugen.
Hoe de contexttest voor AI-modellen eruitzag
Het schema was eenvoudig en opzettelijk saai. We namen een document, verwerkten er zes concrete informatie-items in op verschillende plekken - aan het begin, in het midden, tegen het einde - en stelden vervolgens zes vragen, één per verborgen item. We telden treffers en responstijd. Niets meer.
Het testmateriaal begon met een korte versie en schaalde omhoog. Dat is belangrijk, want juist deze procedure liet zien waar de grens ligt. Onder ongeveer 2000 tokens kwamen antwoorden normaal binnen. Erboven - content_filter, elke keer, zonder uitzondering.
Om de inhoud als oorzaak uit te sluiten, verwisselden we het document voor tekst over planten. Geen technische terminologie, geen code, niets controversieels. Identieke weigering.
Drie providers, dezelfde AI-contextlimiet
De eerste gedachte bij een weigering is meestal: iets in de configuratie van dat specifieke endpoint. Daarom herhaalden we de test via drie onafhankelijke toegangswegen - AWS, rechtstreeks bij de maker van het model en in Google. Dat zijn aparte infrastructuren, aparte dashboards, aparte beveiligingsinstellingen. Het gedrag was identiek.
Dit is voor ons het sterkste element van de hele meting. Als het probleem in onze code zat of in één verkeerd ingestelde moderatiedrempel, zou het zich niet op drie platforms tegelijk herhalen.
| Element | Voor diagnose (weigerend model) | Na vervanging (vervangend model) |
|---|---|---|
| Treffers in verborgen informatie | 0 - geen inhoudelijk antwoord | 6 van 6 |
| Responstijd | niet van toepassing - weigering | 2,3-4,9 s |
| Geretourneerde status | content_filter, native_finish_reason: refusal |
normale afronding |
| Weigeringsdrempels | elk document boven ~2000 tokens | geen |
| Tekst over planten | weigering | verwerkt |
| Aantal providers met dit gedrag | 3 van 3 (AWS, maker, Google) | 0 |
Waarom “model weigert te antwoorden” makkelijk verward wordt met zwak geheugen
De meeste clientbibliotheken en wrappers tonen lege responsinhoud of een korte vervangingsboodschap. De code voor de afrondingsreden zit vaak één veld dieper en niemand kijkt ernaar als het testscript simpelweg treffers telt. In zo’n opzet ziet een lege string er precies uit als “model vond geen informatie”.
Het effect is verraderlijk, want een nulresultaat past bij de intuïtieve hypothese. We verwachten dat een lang document het geheugen belast, dus falen op een lang document lijkt een bevestiging. En we meten iets totaal anders: of het materiaal überhaupt door het invoerfilter kwam.
Dit is onze mening, maar we denken dat een deel van de gepubliceerde vergelijkingen over “AI-contextlimiet” juist moderatie meet. We hebben hier geen data voor buiten onze eigen meting, dus we behandelen dit uitsluitend als hypothese, niet als vaststaand feit.
Wat er concreet veranderde na modelvervanging
Na vervanging door een ander model veranderden we niets anders. Hetzelfde document, dezelfde zes vragen, dezelfde volgorde, dezelfde infrastructuur. Treffers: 6 van 6. Tijden: van 2,3 tot 4,9 s, afhankelijk van hoe diep in het document de gezochte informatie zat.
De spreiding van 2,3-4,9 s is ook informatie. Het toont dat het model daadwerkelijk door het materiaal gaat, en niet uit patroongeheugen antwoordt. Als het algemene antwoorden zou geven, zouden de tijden meer gelijk zijn.
Het belangrijkste: aangezien het tweede model de taak volledig uitvoerde, was de taak uitvoerbaar. De eerdere nul was geen beoordeling van de testmoeilijkheid.
Wanneer je moderatie moet vermoeden, niet context
Uit onze meting komen enkele waarschuwingssignalen. Eerste: het resultaat degradeert niet geleidelijk, maar valt plotseling. Een echt geheugenprobleem geeft meestal een zachte overgang - eerst raakt één informatie-item kwijt, dan een tweede. Een invoerfilter schakelt binair.
Tweede signaal: de grens valt bij een ronde, lage waarde. Ongeveer 2000 tokens is veel te weinig om te spreken van uitputting van het contextvenster van welk hedendaags model dan ook. Als het resultaat zo vroeg instort, is context vrijwel zeker niet de boosdoener.
Derde: weigering voor veilige inhoud. Tekst over planten is juist daarom goed controlemateriaal, omdat er niets in zit om te blokkeren. Als ook die met een weigering terugkomt, ligt de oorzaak in de omvang of in de configuratie, niet in het onderwerp.
Hoe je dit zelf controleert
- Log volledige ruwe API-responsen, niet alleen het inhoudsveld. Je bent geïnteresseerd in afrondingsredencodes - in ons geval waren dat
content_filterennative_finish_reason: refusal. - Bereid één document voor met zes verborgen informatie-items verspreid van begin tot eind. Noteer waar precies elk item zit.
- Voer de test uit op een korte versie, ruim onder 2000 tokens. Dit is je referentiepunt - als het hier niet werkt, zit het probleem in de prompt, niet in de lengte.
- Vergroot de documentomvang in stappen en noteer bij welke waarde de eerste weigering verschijnt. Als de grens scherp valt en niet geleidelijk, denk dan aan een filter.
- Vervang het materiaal door thematisch neutraal materiaal - bij ons was dat tekst over planten. Als ook die met een weigering terugkomt, is de inhoud niet de oorzaak.
- Herhaal bij een tweede en derde provider. Wij controleerden AWS, de API van de maker en Google. Overeenstemming in gedrag op drie platforms sluit een lokale configuratiefout uit.
- Vervang het model door een ander, zonder iets anders te veranderen. Als het alle zes informatie-items treft, heb je bewijs dat de test uitvoerbaar was en de eerdere nul iets anders mat.
- Noteer responstijden apart voor elke vraag. Spreiding - bij ons 2,3-4,9 s - bevestigt dat het model daadwerkelijk het materiaal doorzoekt.
Waar deze cijfers vandaan komen
Alle waarden komen uit onze meting uitgevoerd vóór 21.09.2026. We testten één model via drie onafhankelijke toegangswegen: AWS, directe API van de maker en Google. Testmateriaal: document met zes verborgen informatie-items, geschaald in omvang, plus een controleversie over planten zonder technische inhoud. Weigeringen met codes content_filter en native_finish_reason: refusal traden op voor elk document boven ongeveer 2000 tokens bij alle drie providers. Het vervangende model scoorde op een identieke set taken 6 van 6 verborgen informatie-items in 2,3-4,9 s. We geven geen modelnamen of exacte moderatiedrempels, omdat we geen bevestiging hebben dat de instellingen aan de kant van de providers onveranderd bleven na de meetdatum. Fragmenten gemarkeerd als mening zijn onze conclusies, geen meetresultaten.
More on this from HELDER
benchmarks·Grok 4.7 vs Fable 5.1 vs GPT-5.6 Sol: kosten per puntFable wint 4 van de 7 benchmarks, maar kost 8× meer op output. Eén punt voorsprong in coderen kost ongeveer 3 USD per taak. Beslissingstabel.