Model odmawia czytania dokumentu. Zmierzyłem to na trzech dostawcach
Testowałem pamięć modelu na długich dokumentach i dostawałem zero trafień. Okazało się, że model nie zapominał - w ogóle nie dostał materiału do przeczytania. Trzy niezależne API, ten sam błąd.
👁 113 przeczytań
- Model nie czytał dokumentu, bo każdy plik powyżej około 2000 tokenów wracał z kodem content_filter i native_finish_reason: refusal, dając wynik 0 trafień.
- Ten sam dokument przetworzył model zamienny, trafiając 6 na 6 ukrytych informacji w czasie od 2,3 do 4,9 sekundy bez żadnych zmian w prompcie ani infrastrukturze.
- Odmowa wystąpiła identycznie na trzech niezależnych dostawcach - AWS, API producenta i Google - w tym dla neutralnego tekstu o roślinach bez żadnych treści technicznych.
Przygotowałem test kontekstu modeli: dokument z ukrytymi informacjami, pytania o nie, sprawdzenie ile model odnajdzie. Wynik był zerowy, więc przez chwilę uznałem, że model ma słabą pamięć. Po zajrzeniu w surową odpowiedź API okazało się, że model nie przeczytał ani słowa - wejście zostało odrzucone przez moderację i wróciło z content_filter oraz native_finish_reason: refusal.
Wniosek w jednym akapicie
Zero trafień w teście pamięci to nie zawsze dowód na krótki kontekst. W moim pomiarze model zwracał content_filter i native_finish_reason: refusal dla KAŻDEGO dokumentu powyżej około 2000 tokenów, i to na trzech niezależnych dostawcach - AWS, API producenta oraz Google. Odmowa dotyczyła nawet tekstu o roślinach, w którym nie było żadnych treści technicznych, nazw narzędzi ani niczego, co dałoby się uznać za wrażliwe. Kiedy podstawiłem model zamienny na tym samym materiale i tych samych pytaniach, trafił 6 na 6 ukrytych informacji w czasie 2,3-4,9 s. Czyli zadanie było wykonalne, a wcześniejszy wynik mierzył moderację, nie pamięć.
Jak wyglądał test kontekstu modeli
Schemat był prosty i celowo nudny. Brałem dokument, wplatałem w niego sześć konkretnych informacji w różnych miejscach - na początku, w środku, blisko końca - a potem zadawałem sześć pytań, po jednym na każdą ukrytą informację. Liczyłem trafienia i czas odpowiedzi. Nic więcej.
Materiał testowy zaczynałem od wersji krótkiej i skalowałem w górę. To ważne, bo właśnie ta procedura pozwoliła zobaczyć, gdzie leży granica. Poniżej około 2000 tokenów odpowiedzi przychodziły normalnie. Powyżej - content_filter, za każdym razem, bez wyjątku.
Żeby wykluczyć treść jako powód, podmieniłem dokument na tekst o roślinach. Zero terminologii technicznej, zero kodu, zero czegokolwiek kontrowersyjnego. Odmowa identyczna.
Trzy dostawcy, ten sam limit kontekstu AI
Pierwsza myśl przy odmowie brzmi zwykle: coś w konfiguracji tego konkretnego endpointu. Dlatego powtórzyłem test na trzech niezależnych ścieżkach dostępu - AWS, bezpośrednio u producenta modelu i w Google. To osobne infrastruktury, osobne panele, osobne ustawienia bezpieczeństwa. Zachowanie było takie samo.
To dla mnie najmocniejszy element całego pomiaru. Gdyby problem siedział w moim kodzie albo w jednym błędnie ustawionym progu moderacji, nie powtórzyłby się na trzech platformach jednocześnie.
| Element | Przed diagnozą (model odmawiający) | Po podmianie (model zamienny) |
|---|---|---|
| Trafienia w ukryte informacje | 0 - brak odpowiedzi merytorycznej | 6 na 6 |
| Czas odpowiedzi | nie dotyczy - odmowa | 2,3-4,9 s |
| Zwracany status | content_filter, native_finish_reason: refusal | normalne zakończenie |
| Progi odmowy | każdy dokument powyżej ~2000 tokenów | brak |
| Tekst o roślinach | odmowa | przetworzony |
| Liczba dostawców z tym zachowaniem | 3 z 3 (AWS, producent, Google) | 0 |
Dlaczego „model odmawia odpowiedzi” łatwo pomylić ze słabą pamięcią
Większość bibliotek klienckich i nakładek pokazuje pustą treść odpowiedzi albo krótki komunikat zastępczy. Kod powodu zakończenia bywa schowany o jedno pole głębiej i nikt na niego nie patrzy, jeśli skrypt testowy po prostu zlicza trafienia. W takim układzie pusty string wygląda dokładnie jak „model nie znalazł informacji”.
Efekt jest podstępny, bo wynik zerowy pasuje do intuicyjnej hipotezy. Spodziewamy się, że długi dokument obciąża pamięć, więc porażka na długim dokumencie wydaje się potwierdzeniem. A mierzymy coś zupełnie innego: to, czy materiał w ogóle przeszedł przez filtr wejściowy.
To moja opinia, ale sądzę, że część publikowanych porównań „limit kontekstu AI” mierzy właśnie moderację. Nie mam na to danych poza własnym pomiarem, więc traktuję to wyłącznie jako hipotezę, nie ustalony fakt.
Co konkretnie zmieniło się po podmianie modelu
Po zamianie na inny model nie ruszałem niczego innego. Ten sam dokument, te same sześć pytań, ta sama kolejność, ta sama infrastruktura. Trafienia: 6 na 6. Czasy: od 2,3 do 4,9 s, w zależności od tego, jak głęboko w dokumencie siedziała szukana informacja.
Rozrzut 2,3-4,9 s też jest informacją. Pokazuje, że model rzeczywiście przechodzi przez materiał, a nie odpowiada z pamięci wzorca. Gdyby odpowiadał ogólnikami, czasy byłyby bardziej wyrównane.
Najważniejsze: skoro drugi model wykonał zadanie w całości, to zadanie było wykonalne. Wcześniejsze zero nie było oceną trudności testu.
Kiedy podejrzewać moderację, a nie kontekst
Nie przepłacaj za te subskrypcje
Prowadzę sklep z rocznymi dostępami do narzędzi AI - te same konta, o których piszę wyżej, tylko taniej niż w cenniku producenta.
Z mojego pomiaru wynika kilka sygnałów ostrzegawczych. Pierwszy: wynik nie degraduje się stopniowo, tylko spada skokowo. Prawdziwy problem z pamięcią daje zwykle miękkie przejście - najpierw gubi się jedna informacja, potem druga. Filtr wejściowy przełącza się binarnie.
Drugi sygnał: granica wypada przy okrągłej, niskiej wartości. Około 2000 tokenów to zdecydowanie za mało, by mówić o wyczerpaniu okna kontekstowego jakiegokolwiek współczesnego modelu. Jeśli wynik załamuje się tak wcześnie, to prawie na pewno nie kontekst jest winowajcą.
Trzeci: odmowa dla treści bezpiecznej. Tekst o roślinach jest dobrym kontrolnym materiałem właśnie dlatego, że nie ma w nim niczego do zablokowania. Jeśli i on wraca z odmową, przyczyna leży w objętości albo w konfiguracji, nie w temacie.
Jak to sprawdzić u siebie
- Zaloguj pełne surowe odpowiedzi API, nie tylko pole z treścią. Interesują cię kody powodu zakończenia - w moim przypadku były to
content_filterinative_finish_reason: refusal. - Przygotuj jeden dokument z sześcioma ukrytymi informacjami rozłożonymi od początku do końca tekstu. Zapisz, gdzie dokładnie każda siedzi.
- Uruchom test na wersji krótkiej, zdecydowanie poniżej 2000 tokenów. To twój punkt odniesienia - jeśli tu nie działa, problem jest w prompcie, nie w długości.
- Zwiększaj objętość dokumentu skokami i notuj, przy jakiej wartości pojawia się pierwsza odmowa. Jeśli granica wypada ostro, a nie stopniowo, myśl o filtrze.
- Podstaw materiał neutralny tematycznie - u mnie był to tekst o roślinach. Jeśli i on wraca z odmową, treść nie jest przyczyną.
- Powtórz na drugim i trzecim dostawcy. Ja sprawdzałem AWS, API producenta i Google. Zgodność zachowania na trzech platformach wyklucza lokalny błąd konfiguracji.
- Podmień model na inny, nie zmieniając nic więcej. Jeśli trafi wszystkie sześć informacji, masz dowód, że test był wykonalny, a wcześniejsze zero mierzyło coś innego.
- Zapisz czasy odpowiedzi osobno dla każdego pytania. Rozrzut - u mnie 2,3-4,9 s - potwierdza, że model faktycznie przeszukuje materiał.
Skąd te liczby
Wszystkie wartości pochodzą z mojego pomiaru wykonanego przed 21.09.2026. Testowałem jeden model przez trzy niezależne ścieżki dostępu: AWS, bezpośrednie API producenta oraz Google. Materiał testowy: dokument z sześcioma ukrytymi informacjami, skalowany objętościowo, plus wersja kontrolna o roślinach bez treści technicznych. Odmowy z kodami content_filter i native_finish_reason: refusal wystąpiły dla każdego dokumentu powyżej około 2000 tokenów na wszystkich trzech dostawcach. Model zamienny na identycznym zestawie zadań trafił 6 na 6 ukrytych informacji w czasie 2,3-4,9 s. Nie podaję nazw modeli ani dokładnych progów moderacji, bo nie mam potwierdzenia, że ustawienia po stronie dostawców pozostały niezmienione po dacie pomiaru. Fragmenty oznaczone jako opinia to moje wnioski, nie wyniki pomiaru.
Cały tydzień w AI, w jednym mailu
Wybrane premiery, narzędzia i analizy. Raz w tygodniu, prosto do skrzynki.
Zapisz się za darmo →Najczęstsze pytania
Jak odróżnić odmowę moderacji od słabej pamięci kontekstowej modelu?
Moderacja przełącza się binarnie - wynik spada do zera przy konkretnym progu, a nie degraduje stopniowo. Jeśli model gubi wszystkie informacje naraz przy okrągłej wartości około 2000 tokenów, a nie traci ich po jednej, to sygnał wskazujący na filtr wejściowy, nie na wyczerpanie okna kontekstowego.
Co oznacza kod native_finish_reason: refusal w odpowiedzi API?
Oznacza, że model odrzucił wejście przez moderację, zanim w ogóle je przetworzył. Większość bibliotek klienckich zwraca wtedy pusty string w polu z treścią, co wygląda identycznie jak brak trafienia w teście pamięci.
Czy tekst o roślinach może zostać zablokowany przez moderację modelu AI?
Tak - w opisanym pomiarze tekst o roślinach bez terminologii technicznej ani treści kontrowersyjnych wracał z odmową identyczną jak inne dokumenty. Przyczyna leżała w objętości dokumentu przekraczającej około 2000 tokenów, a nie w temacie.
Jak sprawdzić, czy problem z modelem AI leży w moderacji, a nie w długości kontekstu?
Należy zalogować surowe odpowiedzi API i sprawdzić kody powodu zakończenia, takie jak content_filter. Następnie powtórzyć test na co najmniej trzech dostawcach - w opisanym pomiarze były to AWS, API producenta i Google - i podmienić model bez zmiany dokumentu ani pytań, żeby zobaczyć, czy zadanie jest w ogóle wykonalne.
Podobne tematy na Promptowym
