KI-Modell verweigert Dokument-Analyse - Test bei 3 Anbietern
Kontexttest zeigte content_filter bei jedem Dokument über ~2000 Token - bei AWS, beim Hersteller und bei Google. Selbst bei einem Text über Pflanzen.

👁 113 Aufrufe
- Das KI-Modell verweigerte nicht wegen schwachem Gedächtnis, sondern weil jedes Dokument über etwa 2000 Token mit content_filter und native_finish_reason: refusal abgelehnt wurde.
- Das Verhalten trat identisch bei drei unabhängigen Anbietern auf - AWS, direkte Hersteller-API und Google - was einen lokalen Konfigurationsfehler ausschließt.
- Das Ersatzmodell fand alle 6 von 6 versteckten Informationen in 2,3-4,9 Sekunden bei identischem Testmaterial, was beweist, dass die Aufgabe grundsätzlich lösbar war.
Wir haben einen Kontexttest für KI-Modelle vorbereitet: ein Dokument mit versteckten Informationen, Fragen dazu und die Prüfung, wie viele das Modell findet. Das Ergebnis war null, also nahmen wir zunächst an, das Modell habe ein schwaches Gedächtnis. Nach einem Blick in die rohe API-Antwort stellte sich heraus, dass das Modell kein einziges Wort gelesen hatte - die Eingabe wurde von der Moderation abgelehnt und kam mit content_filter sowie native_finish_reason: refusal zurück.
Fazit in einem Absatz
Null Treffer in einem Gedächtnistest sind nicht immer ein Beweis für kurzen Kontext. In unserer Messung gab das Modell content_filter und native_finish_reason: refusal für JEDES Dokument über etwa 2000 Token zurück, und das bei drei unabhängigen Anbietern - AWS, Hersteller-API und Google. Die Ablehnung betraf sogar einen Text über Pflanzen, in dem es keinerlei technische Inhalte, Werkzeugnamen oder irgendetwas gab, das als sensibel gelten könnte. Als wir ein Ersatzmodell mit demselben Material und denselben Fragen einsetzten, traf es 6 von 6 versteckten Informationen in 2,3-4,9 s. Die Aufgabe war also machbar, und das frühere Ergebnis maß Moderation, nicht Gedächtnis.
Wie der Kontexttest für KI-Modelle aussah
Das Schema war einfach und absichtlich langweilig. Wir nahmen ein Dokument, flochten sechs konkrete Informationen an verschiedenen Stellen ein - am Anfang, in der Mitte, nahe am Ende - und stellten dann sechs Fragen, je eine pro versteckter Information. Wir zählten Treffer und Antwortzeit. Nichts weiter.
Das Testmaterial begannen wir mit einer kurzen Version und skalierten nach oben. Das ist wichtig, denn genau diese Vorgehensweise ermöglichte es zu sehen, wo die Grenze liegt. Unterhalb von etwa 2000 Token kamen die Antworten normal. Darüber - content_filter, jedes Mal, ohne Ausnahme.
Um den Inhalt als Grund auszuschließen, tauschten wir das Dokument gegen einen Text über Pflanzen aus. Null technische Terminologie, null Code, null irgendetwas Kontroverses. Ablehnung identisch.
Drei Anbieter, dasselbe KI-Kontextlimit
Der erste Gedanke bei einer Ablehnung lautet normalerweise: etwas in der Konfiguration dieses speziellen Endpoints. Deshalb wiederholten wir den Test über drei unabhängige Zugangswege - AWS, direkt beim Modellhersteller und bei Google. Das sind separate Infrastrukturen, separate Panels, separate Sicherheitseinstellungen. Das Verhalten war identisch.
Das ist für uns das stärkste Element der gesamten Messung. Wenn das Problem in unserem Code oder in einer falsch eingestellten Moderationsschwelle läge, würde es sich nicht auf drei Plattformen gleichzeitig wiederholen.
| Element | Vor der Diagnose (verweigerndes Modell) | Nach dem Austausch (Ersatzmodell) |
|---|---|---|
| Treffer bei versteckten Informationen | 0 - keine inhaltliche Antwort | 6 von 6 |
| Antwortzeit | nicht zutreffend - Ablehnung | 2,3-4,9 s |
| Zurückgegebener Status | content_filter, native_finish_reason: refusal |
normaler Abschluss |
| Ablehnungsschwellen | jedes Dokument über ~2000 Token | keine |
| Text über Pflanzen | Ablehnung | verarbeitet |
| Anzahl Anbieter mit diesem Verhalten | 3 von 3 (AWS, Hersteller, Google) | 0 |
Warum „Modell verweigert Antwort“ leicht mit schwachem Gedächtnis verwechselt wird
Die meisten Client-Bibliotheken und Wrapper zeigen leeren Antwortinhalt oder eine kurze Ersatzmeldung. Der Code für den Abschlussgrund ist oft ein Feld tiefer versteckt, und niemand schaut darauf, wenn das Testskript einfach Treffer zählt. In dieser Konstellation sieht ein leerer String genau so aus wie „Modell hat die Information nicht gefunden“.
Der Effekt ist tückisch, weil das Null-Ergebnis zur intuitiven Hypothese passt. Wir erwarten, dass ein langes Dokument das Gedächtnis belastet, also erscheint ein Versagen bei einem langen Dokument als Bestätigung. Dabei messen wir etwas völlig anderes: ob das Material überhaupt durch den Eingabefilter kam.
Das ist unsere Meinung, aber wir vermuten, dass ein Teil der veröffentlichten Vergleiche zum „KI-Kontextlimit“ genau diese Moderation misst. Wir haben dafür keine Daten außer unserer eigenen Messung, also behandeln wir das ausschließlich als Hypothese, nicht als gesicherte Tatsache.
Was sich konkret nach dem Modellaustausch änderte
Nach dem Wechsel zu einem anderen Modell änderten wir nichts anderes. Dasselbe Dokument, dieselben sechs Fragen, dieselbe Reihenfolge, dieselbe Infrastruktur. Treffer: 6 von 6. Zeiten: von 2,3 bis 4,9 s, je nachdem, wie tief im Dokument die gesuchte Information saß.
Die Streuung von 2,3-4,9 s ist ebenfalls eine Information. Sie zeigt, dass das Modell tatsächlich das Material durchgeht und nicht aus dem Mustergedächtnis antwortet. Wenn es Allgemeinplätze antworten würde, wären die Zeiten gleichmäßiger.
Das Wichtigste: Da das zweite Modell die Aufgabe vollständig erledigte, war die Aufgabe machbar. Die frühere Null war keine Bewertung der Testschwierigkeit.
Wann Sie Moderation statt Kontext vermuten sollten
Aus unserer Messung ergeben sich mehrere Warnsignale. Erstes: Das Ergebnis verschlechtert sich nicht allmählich, sondern fällt sprunghaft. Ein echtes Gedächtnisproblem gibt normalerweise einen weichen Übergang - erst geht eine Information verloren, dann eine zweite. Der Eingabefilter schaltet binär um.
Zweites Signal: Die Grenze fällt bei einem runden, niedrigen Wert. Etwa 2000 Token sind entschieden zu wenig, um von einer Erschöpfung des Kontextfensters irgendeines zeitgenössischen Modells zu sprechen. Wenn das Ergebnis so früh einbricht, ist fast sicher nicht der Kontext schuld.
Drittes: Ablehnung bei sicherem Inhalt. Ein Text über Pflanzen ist gerade deshalb gutes Kontrollmaterial, weil es darin nichts zu blockieren gibt. Wenn auch er mit Ablehnung zurückkommt, liegt die Ursache im Umfang oder in der Konfiguration, nicht im Thema.
Wie Sie das bei sich prüfen können
- Protokollieren Sie vollständige rohe API-Antworten, nicht nur das Inhaltsfeld. Sie interessieren sich für Abschlussgründe - in unserem Fall waren das
content_filterundnative_finish_reason: refusal. - Bereiten Sie ein Dokument mit sechs versteckten Informationen vor, die vom Anfang bis zum Ende des Textes verteilt sind. Notieren Sie, wo genau jede sitzt.
- Führen Sie den Test mit einer kurzen Version durch, deutlich unter 2000 Token. Das ist Ihr Referenzpunkt - wenn es hier nicht funktioniert, liegt das Problem im Prompt, nicht in der Länge.
- Erhöhen Sie den Dokumentumfang in Sprüngen und notieren Sie, bei welchem Wert die erste Ablehnung auftritt. Wenn die Grenze scharf und nicht allmählich fällt, denken Sie an einen Filter.
- Setzen Sie thematisch neutrales Material ein - bei uns war das ein Text über Pflanzen. Wenn auch er mit Ablehnung zurückkommt, ist der Inhalt nicht die Ursache.
- Wiederholen Sie bei einem zweiten und dritten Anbieter. Wir prüften AWS, Hersteller-API und Google. Übereinstimmendes Verhalten auf drei Plattformen schließt einen lokalen Konfigurationsfehler aus.
- Tauschen Sie das Modell gegen ein anderes aus, ohne sonst etwas zu ändern. Wenn es alle sechs Informationen trifft, haben Sie den Beweis, dass der Test machbar war und die frühere Null etwas anderes maß.
- Notieren Sie Antwortzeiten separat für jede Frage. Streuung - bei uns 2,3-4,9 s - bestätigt, dass das Modell tatsächlich das Material durchsucht.
Woher diese Zahlen stammen
Alle Werte stammen aus unserer Messung, die vor dem 21.09.2026 durchgeführt wurde. Wir testeten ein Modell über drei unabhängige Zugangswege: AWS, direkte Hersteller-API und Google. Testmaterial: ein Dokument mit sechs versteckten Informationen, nach Umfang skaliert, plus eine Kontrollversion über Pflanzen ohne technische Inhalte. Ablehnungen mit den Codes content_filter und native_finish_reason: refusal traten bei jedem Dokument über etwa 2000 Token bei allen drei Anbietern auf. Das Ersatzmodell traf bei identischem Aufgabensatz 6 von 6 versteckten Informationen in 2,3-4,9 s. Wir nennen keine Modellnamen oder genauen Moderationsschwellen, weil wir keine Bestätigung haben, dass die Einstellungen auf Anbieterseite nach dem Messdatum unverändert blieben. Als Meinung gekennzeichnete Abschnitte sind unsere Schlussfolgerungen, nicht Messergebnisse.
Häufig gestellte Fragen
Warum gibt ein KI-Modell bei langen Dokumenten leere Antworten zurück?
Die Ursache kann ein Eingabefilter sein, nicht ein schwaches Gedächtnis. In diesem Test lieferte das Modell ab etwa 2000 Token den Status content_filter und native_finish_reason: refusal, sodass es das Dokument gar nicht las.
Wie erkenne ich, ob ein KI-Modell mein Dokument wegen Moderation oder wegen Kontextlänge ablehnt?
Ein Moderationsfilter schaltet binär um, ein Gedächtnisproblem zeigt sich als allmählicher Leistungsabfall. Zusätzlich sollte man vollständige rohe API-Antworten protokollieren und auf Abschlussgründe wie content_filter achten, die im Inhaltsfeld nicht sichtbar sind.
Was bedeutet native_finish_reason: refusal in einer API-Antwort?
Dieser Code zeigt an, dass das Modell die Eingabe abgelehnt hat, bevor es sie verarbeitete. Im beschriebenen Test trat er zusammen mit content_filter auf und betraf sogar einen thematisch neutralen Text über Pflanzen ohne technische Inhalte.
Wie kann ich testen, ob mein KI-Modell Dokumente tatsächlich durchsucht oder nur Standardantworten liefert?
Man verteilt sechs konkrete Informationen an verschiedenen Stellen eines Dokuments und misst Treffer sowie Antwortzeit pro Frage. Eine Streuung der Antwortzeiten - im Test 2,3-4,9 Sekunden - zeigt, dass das Modell das Material tatsächlich durchsucht und nicht aus dem Mustergedächtnis antwortet.
More on this from WISSNOX
ki-werkzeuge·Qwen-Image-2.1: Transparente PNG direkt aus dem Modell22,7 Prozent vollständig transparente Pixel und voller Alpha-Bereich 0-255. Wie Sie Transparenz anfordern und worauf Sie bei normalen Bildern achten müssen.

