Jak sprawdzono tę notatkę. Przed publikacją została zaatakowana, najpierw pod kątem obalenia, przez osiem zewnętrznych instancji recenzenckich z czterech rodzin modeli (Moonshot Kimi, xAI Grok, DeepSeek, Alibaba Qwen), z których każda przeliczyła każdą liczbę od nowa z plików dostawcy. Co złamały i jak to naprawiono, znajduje się w §5. Towarzysz techniczny, z metodą, pełnymi zestawieniami i ograniczeniami, to Field Note 1. Protokoły instancji i zahaszowane archiwum danych znajdują się w naszym repozytorium raportów i są dostępne na żądanie.
W jedną minutę. Firma o nazwie TypeSafe AI wypuściła Jeva, model AI, który nigdy nie pisze zdania. Zadajcie mu pytanie ze stałym zestawem odpowiedzi, a zwróci jedną odpowiedź plus prawdopodobieństwo dla każdej opcji. Dla modelu tej klasy możliwości to nowość, i zaostrza pytanie, którego klasyfikatory nigdy nam nie narzuciły: jak sprawdzić świadka, który nie potrafi się wytłumaczyć? Odpowiedzią TypeSafe jest ocenianie Jeva wobec uśrednionej opinii dwóch innych modeli AI. Otworzyliśmy dwadzieścia przypadków, które TypeSafe publikuje dla zilustrowania swojego benchmarku, i stwierdziliśmy, że w ośmiu z dziewiętnastu, w których obaj oceniający odpowiedzieli, te dwa modele różniły się między sobą co do właściwej odpowiedzi. Ta notatka wyjaśnia, dlaczego ma to znaczenie daleko poza jedną firmą.
1. Model, który nie mówi
Przez trzy lata, gdy czołowy model AI dawał nam odpowiedź, dawał nam słowa. Mogliśmy je przeczytać, spierać się z nimi i przyłapać model na tym, że sam sobie przeczy. Mniejsze klasyfikatory zawsze zwracały nagie etykiety; nowością jest model o czołowych możliwościach, który nie zwraca nic poza nimi. TypeSafe AI, firma z San Francisco niemająca związku z językiem programowania TypeScript, wypuściła model, który nie robi nic z powyższych rzeczy. Nazywa się Jev, a TypeSafe przedstawia go jako pierwszy z nowej kategorii, „System One models”, od szybkiego, intuicyjnego myślenia opisanego przez Daniela Kahnemana w Pułapkach myślenia. O myśleniu szybkim i wolnym.
Oto jak działa Jev. Dajecie mu materiał, powiedzmy zgłoszenie serwisowe klienta. Dajecie mu zestaw typowanych pytań: czy ten klient prosi o zwrot pieniędzy? (tak lub nie, z prawdopodobieństwem). Który zespół ma się tym zająć? (jeden z listy). Jak bardzo klient jest sfrustrowany, od 0 do 4? (ocena). Jev zwraca odpowiedzi, każdą z rozkładem prawdopodobieństwa, w ułamku sekundy. Żadnej prozy, żadnego wyjaśnienia, żadnego kodu. Wasze oprogramowanie działa bezpośrednio na odpowiedziach.
Do automatyzacji rutynowych decyzji jest to atrakcyjne i nie jesteśmy tu po to, by twierdzić inaczej. Usunięcie swobodnego tekstu eliminuje całą klasę awarii, a prawdopodobieństwo, na którym można ustawić próg, jest programowi bardziej przydatne niż akapit. Interesuje nas efekt uboczny. Model, który jedynie wybiera z waszej listy, nigdy nie powie wam, że listy czegoś brakuje. Ludzki recenzent albo model, który pisze, może powiedzieć: „zadaliście złe pytanie”. Jev nie może. Może zasugerować, że żadna opcja nie pasuje dobrze, bo jego prawdopodobieństwa rozłożą się zamiast się skupić, i dokumentacja TypeSafe sama to mówi. Ale nigdy nie nazwie opcji, o której zapomnieliście. Cokolwiek zostawiliście poza zestawem pytań, zostaje poza nim, dla każdego świadka, który na nie odpowiada.
Podchodzimy do tego z nietypowej strony. Nasz dokument roboczy traktuje wyjścia AI tak, jak badacze traktują dawne rękopisy: jako świadectwo świadków, którzy mogą dzielić źródła, przepisywać od siebie nawzajem i popełniać te same błędy z tych samych powodów. W tej ramie Jev jest świadkiem, który przestał pisać.
2. Kto ocenia oceniającego?
Każdy model AI dostaje wynik benchmarku. Pytanie, które warto zadać wobec każdego wyniku, brzmi: porównany z czym? Przy zadaniu matematycznym odpowiedź jest łatwa: z poprawną liczbą. Przy „czy ten alert bezpieczeństwa należy eskalować?” nie ma klucza odpowiedzi. Ktoś musi zdecydować, jaka była właściwa odpowiedź.
TypeSafe publikuje swój benchmark pod adresem evals.typesafe.ai. Sekcja metodologii wyjaśnia, jak
rozstrzygnięto:
“Instead of debating the correctness of the harness and labels, we assume that the code is correct, and measure against the current smartest large models. For this eval, the reference labels are generated via an average of the responses of GPT-6 Astra and Claude Fable 5.1, both at high thinking, answering every question in the harness. All other models are evaluated using the provider’s default reasoning settings.”
Nasze tłumaczenie: zamiast dyskutować o poprawności uprzęży i etykiet, zakładamy, że kod jest poprawny, i mierzymy wobec obecnie najzdolniejszych dużych modeli; dla tej ewaluacji etykiety odniesienia są generowane jako średnia odpowiedzi GPT-6 Astra i Claude Fable 5.1, obu w trybie wysokiego rozumowania.
Mówiąc wprost: „właściwą odpowiedzią” na każde pytanie jest to, co dwa czołowe modele AI, GPT-6 Astra od OpenAI i Claude Fable 5.1 od Anthropic, powiedziały średnio. Trafność Jeva to częstość, z jaką zgadza się z tą średnią. Trafność wszystkich pozostałych również.
TypeSafe otwarcie przyznaje się do oczywistego problemu. Wpis premierowy mówi, że to “biases answers towards OpenAI and Anthropic’s models. We likely underestimate the relative performance of our model and DeepSeek’s models” (przechyla odpowiedzi ku modelom OpenAI i Anthropic i prawdopodobnie zaniża względną wydajność własnego modelu oraz modeli DeepSeek). To uczciwe zastrzeżenie. Ale jest głębszy problem, którego nie nazywa.
Gdy dwa modele AI oba się mylą, zwykle mylą się w ten sam sposób. Badanie z 2025 r. obejmujące ponad 350 modeli wykazało, że gdy dwa modele oba chybią pytania, dają tę samą błędną odpowiedź znacznie częściej, niż przewidywałby przypadek. Efekt nasila się, w miarę jak modele stają się zdolniejsze, i utrzymuje się w różnych firmach i architekturach (Kim, Garg, Peng i Garg, ICML 2025). Uśrednienie dwóch sędziów tłumi błędy, które popełniają osobno; na poziomie ostatecznej decyzji po prostu opowiada się po stronie jednego z nich, jak pokazujemy niżej. Nic nie robi z błędami, które popełniają wspólnie, a na szczycie stawki to właśnie wspólne błędy są tymi dużymi.
Średnia dwóch czołowych modeli nie jest zatem neutralnym arbitrem. Jest ich wspólną opinią awansowaną do rangi prawdy odniesienia. Model, który kopiuje ich wspólny błąd, jest punktowany jako poprawny. Model, który ma rację, gdy oba się mylą, jest punktowany jako porażka. Nazwaliśmy to pułapką konsensusu, gdy pisaliśmy o benchmarkach w sierpniu. Benchmark TypeSafe jest najwyraźniejszym ujawnionym przykładem, jaki widzieliśmy. Jedna uwaga o uczciwości dotycząca nas samych: badanie zmierzyło to na dwóch publicznych rankingach i zadaniu rekrutacyjnym. To, że to samo dzieje się wewnątrz benchmarku przepływów pracy pozbawionego niezależnej prawdy, jest naszym wnioskiem, a nie ustaleniem badania.
3. Otworzyliśmy przypadki. Oto co znaleźliśmy.
Panel ocenia dziewięć modeli w czterech przepływach pracy: alerty bezpieczeństwa, nadzór nad agentami wsparcia, przetwarzanie faktur i obsługa klienta, łącznie 711 przypadków. Jev ląduje w środku stawki: 67,8 % zgodności z odniesieniem średnio, wobec 74,1 % dla najlepszego modelu. Plasuje się poniżej czołowych modeli OpenAI i Anthropic, o dziesiątą punktu za GPT-5.6 Terra, na równi z Claude Sonnet 5 i powyżej obu modeli DeepSeek. Jeśli przyszliście z pytaniem, czy Jev „halucynuje”, wpis premierowy TypeSafe jest szczery i w tej sprawie: te 0 %, które wykreśla, są, jego własnymi słowami, “not empirical. Schema matching is guaranteed, thus we can confidently add 0% into the plots” (nie empiryczne; zgodność ze schematem jest gwarantowana). Jev nie może zwrócić źle uformowanej odpowiedzi. To co innego niż zwrócenie poprawnej.
Część, która nas obchodzi, jest mniejsza i bardziej odkrywcza. TypeSafe publikuje także dwadzieścia opracowanych przypadków, pięć na przepływ, wybranych dla zilustrowania pięciu sytuacji: każdy z trzech porównywanych modeli odbiega po kolei od dwóch pozostałych, wszystkie trzy chybiają odniesienia, i wszystkie trzy się zgadzają. Dla dziewiętnastu z tych przypadków publikuje to, co powiedział każdy z dwóch modeli oceniających, pytanie po pytaniu, a nie tylko ich średnią; w jednym z dziewiętnastu większość odpowiedzi uzupełniających drugiego oceniającego brakuje w pliku, a w dwóch z czterech przepływów sama średnia nie jest publikowana w ogóle. To więcej przejrzystości, niż oferuje większość benchmarków, i to pozwoliło nam policzyć.
Obaj oceniający różnili się między sobą co do ostatecznej decyzji w 8 z 19 przypadków. Porównaliśmy pełną listę działań, do których doszedł każdy z oceniających; w kilku przypadkach lista jednego była listą drugiego plus dodatkowe kroki, i to również liczymy jako różnicę. Pytanie po pytaniu dali odmienne odpowiedzi 31 razy na 356 pytań, na które odpowiedzieli obaj oceniający, a wszystkie znajdują się w zarchiwizowanych plikach; w sześciu kolejnych przypadkach jeden z nich nie udzielił żadnej odpowiedzi. Tych dwadzieścia przypadków TypeSafe wybrał ręcznie, by pokazać różnice wśród modeli ocenianych, więc nie jest to pomiar tego, jak często oceniający różnią się na wszystkich 711. To jest to, co TypeSafe postanowił opublikować, odczytane z drugiej strony.
Każdy bez wyjątku przypadek, który TypeSafe oznacza jako „wszystkie trzy chybiają odniesienia”, to
przypadek, w którym również obaj oceniający różnili się między sobą. Weźmy przykład z
bezpieczeństwa. Jeden oceniający powiedział ISOLATE HOST. Drugi powiedział REVOKE SESSIONS.
Średnia wyszła ISOLATE HOST. Wszystkie trzy oceniane modele powiedziały QUARANTINE FILE. Trzy
modele zostały więc oznaczone jako błędne wobec odpowiedzi, której jeden z dwóch modeli piszących
klucz również nie udzielił. Aby być ścisłym co do tego, co to pokazuje: te trzy modele zostałyby
oznaczone jako błędne przy ocenie każdego z dwóch oceniających, jest to więc sporny klucz, a nie
ukarana poprawna odpowiedź. Nikt nie potrafi powiedzieć, który oceniający miał rację: te przepływy
pracy nie mają niezależnego klucza, o co właśnie chodzi. Dwa z czterech przypadków oznaczonych jako
„wszystkie trzy się zgadzają” tną w drugą stronę. W jednym obaj oceniający podzielili się między
ISOLATE HOST a ESCALATE TIER2, średnia wybrała ESCALATE TIER2, a wszystkie trzy oceniane modele
powiedziały to samo, tak że zgodzenie się z jednym oceniającym przeciwko drugiemu policzono jako
poprawne. Wszędzie tam, gdzie TypeSafe publikuje średnią, równa się ona odpowiedzi jednego albo
drugiego oceniającego, nigdy trzeciej. To nie przypadek: uśrednione prawdopodobieństwa przechodzą
przez te same reguły decyzyjne co odpowiedzi dowolnego modelu, więc średnia musi wylądować na jakimś
działaniu, a w każdym opublikowanym przypadku ląduje po stronie jednego z oceniających.
Jeden z oceniających był po części zastępcą. W przepływie bezpieczeństwa plik opisujący drugiego
oceniającego brzmi, słowo w słowo: “Claude Fable 5.1 high, one question per request; Claude Opus 5
high on the 88 documents Fable refused or failed”. Tak więc dla dokumentów, których Fable nie chciał
lub nie mógł obsłużyć, wkroczył inny model Anthropic, Claude Opus 5. Plik liczy 240 przypadków w tym
przepływie, ale nie mówi, jak dokumenty odpowiadają przypadkom, więc nie zamienimy tych 88 na
procent. Wynika z tego jedno: jeden oceniający dla jednego przepływu jest mieszanką, której receptura
nie została ujawniona poza liczbą dokumentów. Plik odnotowuje zastępcę; ranking go nie wspomina. A
ponieważ plik nie mówi, na których dokumentach Fable zawiódł, nie potrafimy ustalić, czy owo
REVOKE SESSIONS powyżej pochodziło od Fable’a, czy od Opusa 5.
Własne odpowiedzi Jeva również są opublikowane i nie przechylają się w żadną stronę. W 31 pytaniach, w których obaj oceniający się różnili, Jev stanął po stronie Astry 14 razy, po stronie drugiego oceniającego 14 razy, a po niczyjej 3 razy. Dla oceny od 0 do 4 własną konwencją TypeSafe jest średnia ważona prawdopodobieństwem, a nie sam najbardziej prawdopodobny poziom; punktowane w ten sposób, jedna odpowiedź się odwraca i wychodzi 13 do 15. Tak czy owak, na tej maleńkiej, wyselekcjonowanej próbce nie ma śladu, by Jev przechylał się ku któremukolwiek z modeli, których średnia go ocenia. Ale ostrożnie z tym, co to pokazuje. Równy podział to tak właśnie wygląda „brak faworyta”. Jest to również, jak zauważył jeden z naszych zewnętrznych recenzentów, to, jak wyglądałby model wytrenowany, by podążać za średnią tych dwóch. To zliczenie nie potrafi rozróżnić tych dwóch historii. Zatrzymajcie tę myśl do następnej sekcji.
Nic z tego nie czyni Jeva lepszym ani gorszym, niż mówi panel. Pokazuje, że definicja „poprawności” w tym benchmarku jest sporna wewnątrz jego własnych danych, w sposób, który TypeSafe uczynił widocznym, a którego jego nagłówkowa liczba nie pokazuje.
4. Gdzie Jev nauczył się oceniać?
Nasz program badawczy zadaje każdemu modelowi pytanie: skąd wzięły się jego nawyki? Czy był trenowany na wyjściu innego modelu? Czy dzieli bazę z konkurentem? Dla modeli, które piszą, zaskakująco mocna wskazówka tkwi w samym pisaniu: rozkłady wyborów słów są na tyle charakterystyczne, że pozwalają odróżnić pięć dużych systemów AI z trafnością 97 % (Sun i in., ICML 2025). To maszynowy odpowiednik rozpoznawania kopisty po ręce.
Jev nic nie pisze, więc ta wskazówka znika. Pozostają dwie trudniejsze metody: celowo wszczepione znaczniki oraz porównanie modelu z wcześniejszą wersją jego samego, by zobaczyć, od którego nauczyciela się uczył. Żadna z nich nie jest dostępna komuś z zewnątrz. Własne wprowadzenie TypeSafe mówi, że ich modele wychodzą od zwykłych wstępnie wytrenowanych modeli językowych i dodają nowy etap treningu, “Reinforcement learning for calibrated decisions”. TypeSafe porusza kwestię pochodzenia swoich danych treningowych, w odpowiedzi z sekcji pytań i odpowiedzi wpisu premierowego, której nie pokazuje żadne tekstowe odwzorowanie strony i którą jeden z naszych recenzentów znalazł w skryptowym ładunku strony: “We make all the data ourselves” (całe dane robimy sami). To wyklucza trening na danych klientów. Nie nazywa modelu bazowego, nie nazywa nauczyciela i nie mówi, czy dane wykonane samodzielnie mogą nieść odpowiedzi innych modeli. Ta sama sekcja mówi, że Jev jest “neither small nor an LLM” (ani mały, ani LLM), co źle współgra z opisem, we wprowadzeniu, trzeciej drogi adaptacji wstępnie wytrenowanych modeli językowych; TypeSafe nie godzi ze sobą tych dwóch rzeczy, a my nie potrafimy. Wedle naszych własnych reguł pochodzenie Jeva jest zatem programem badawczym, a nie wynikiem, i to cieńszym niż dla modeli, które piszą.
Pozostaje hipoteza, którą chcemy sformułować ostrożnie. Gdyby Jev został wytrenowany tak, by pasować do tego samego rodzaju średniej z dwóch modeli, jakiej używa jego benchmark, to panel recenzencki, który dodałby Jeva jako „czwartą niezależną opinię”, w rzeczywistości dodawałby potomka dwóch opinii, które już miał, a każda procedura licząca go jako niezależnego byłaby zwiedziona, nie wiedząc o tym. Dwie rzeczy mają tu znaczenie, żadna rozstrzygająco. Jev jest w środku stawki na panelu, gdzie po modelu wytrenowanym do kopiowania oceniających można by oczekiwać większej zgodności z nimi; ale zdolność i zgodność są tam splecione, więc to słaby dowód. A na 31 spornych pytaniach Jev podzielił się czternaście do czternastu między dwóch oceniających (trzynaście do piętnastu przy własnej punktacji TypeSafe dla jednego typu odpowiedzi). Jest to zgodne z brakiem faworyta i równie zgodne z podążaniem za średnią tej pary, więc niczego nie rozstrzyga. Uznajemy tę hipotezę za możliwą i mówimy, co by ją rozstrzygnęło: ujawnienie przez TypeSafe, skąd wzięły się jego odpowiedzi treningowe, albo porównanie, które zestawi bliskość Jeva do średniej obu oceniających z innymi zdolnymi modelami, które nie były na nich trenowane, mierzone na wszystkich 711 przypadkach, a nie na 20, które możemy zobaczyć. Sama bliskość by nie rozstrzygnęła: każdy zdolny model ma skłonność lądować pomiędzy dwoma zdolnymi oceniającymi.
5. Nasz własny udział w tym
Ta notatka została zredagowana z Claude Fable 5.1, jednym z dwóch modeli, których średnią TypeSafe traktuje jako prawdę. Wcześniejsza analiza, z której korzystaliśmy, pochodziła od modelu OpenAI, drugiej połowy tej średniej. Obaj autorzy są, innymi słowy, stronami tego, co oceniali. Dlatego, zanim ta notatka została napisana, kazaliśmy zaatakować leżącą u jej podstaw ocenę recenzentowi z trzeciej firmy, Kimi od Moonshot. Poprawił trzy nasze cytaty i złamał dziewiętnaście naszych wniosków, w tym twierdzenie pierwszej wersji, że Jev „zgadza się najmniej” z konsensusem. Nie zgadza się; jest w środku stawki. Druga instancja Kimi przeliczyła następnie od nowa każdą liczbę powyżej z surowych plików i je potwierdziła, a z kolei złamała pierwszą wersję tej notatki: zamieniła „88 dokumentów” TypeSafe na udział w 240 przypadkach, dwie jednostki, których pliki nie zrównują, i napisała, że jeden oceniający „oceniał sam siebie”, czego dane nie potwierdzają. Obie rzeczy zniknęły. Trzecia instancja, Grok od xAI, przeliczyła liczby po raz trzeci i pokazała, że nasz przykład z bezpieczeństwa dowodził mniej, niż sugerowaliśmy, że umieszczenie faktu o zastępcy obok pozycji Opusa 5 zapraszało do wniosku, którego się wypieraliśmy, oraz że jedna z naszych liczb zależy od wyboru sposobu punktacji. Czwarta, z DeepSeek, przeliczyła je ponownie i przyłapała nas na traktowaniu równego podziału jako dowodu przeciwko hipotezie, od której nie potrafi go odróżnić. Piąta, kolejna instancja Kimi, znalazła odpowiedź z sekcji pytań i odpowiedzi o danych treningowych, którą czterej czytelnicy strony, w tym nasz, zgłosili jako nieobecną. Szósta, Qwen od Alibaby, uruchomiona przez autora, a nie przez nas, potwierdziła każdą liczbę i była czwartą, która powiedziała, że akapit o zastępcy nadal insynuuje; czyta się teraz jako zwykłe ujawnienie. Wszystko jest poprawione powyżej. Notatka o skorelowanych sędziach napisana przez skorelowanego sędziego warta jest dokładnie tyle, ile jej zewnętrzna kontrola.
17 września dwóch kolejnych recenzentów, instancja Codex od OpenAI i instancja Kimi od Moonshot, zbadało nasz plan bezpośredniego przetestowania Jeva i pokazało, że test, który proponowaliśmy w §4, nie mógłby rozstrzygnąć tej kwestii sam z siebie. Zdanie w §4 mówi teraz, czego by do tego potrzebowało.
Czego nie mówimy
Nie mówimy, że typowane decyzje to zły pomysł; do kierowania i triażu są prawdopodobnie dobrym. Nie mówimy, że benchmark TypeSafe jest nieuczciwy; ujawnia więcej niż większość, a wszystko powyższe jest policzone z tego, co ujawnia. Nie mówimy, że Jev był trenowany na odpowiedziach swoich oceniających; jedyny test, jaki mogliśmy przeprowadzić, nie potrafi tego powiedzieć. Mówimy trzy rzeczy. Benchmark, którego prawdą jest średnia z dwóch świadków, dziedziczy wszystko, w czym ci świadkowie mylą się wspólnie. Własne opublikowane przypadki TypeSafe pokazują dwóch świadków niezgadzających się co do odpowiedzi w ośmiu na dziewiętnaście. A klasa modeli, która nie potrafi pisać, odebrała nam dowód, którym inaczej posłużylibyśmy się, by zapytać, skąd wziął się jej osąd.
Dlaczego nas to obchodzi
CounterProof przegląda kod pisany przez AI tak, jak zrobiłby to przeciwnik. Naszą regułą roboczą jest, że ustalenie rozstrzyga się przez uruchomienie kodu, nigdy przez głosowanie wśród modeli. Nowa klasa modeli decyzyjnych będzie oceniana i trenowana wobec konsensusu modeli, ponieważ konsensus jest tani, a prawdziwe etykiety wyników są drogie. Cała nasza metoda jest tą drogą alternatywą: zamrożone przypadki, odtworzenia, które możecie uruchomić, i etykiety, które biorą się z tego, co kod faktycznie zrobił, a nie z tego, co dwa modele zgodziły się, że zrobi. Jeśli modele o typowanych decyzjach staną się warstwą, przez którą działają agenci AI, to pytanie o to, czyj osąd niesie ta warstwa, stanie się pytaniem o pochodzenie na całą dekadę. Jedyna uczciwa odpowiedź przyjdzie ze sprawdzania wobec wyników. To jest ta praca.
Zapis techniczny. Metoda, schemat, pełna tabela zliczeń, na co okaz pozwala, a na co nie, oraz ograniczenia: Field Note 1, Consensus as oracle: TypeSafe’s Jev benchmark as a type specimen, na naszej stronie badawczej.
Ujawnienie, z którego niczego nie wywodzimy. Claude Opus 5, zastępca dla części klucza odpowiedzi przepływu bezpieczeństwa, jest zarazem jednym z dziewięciu ocenianych modeli. Plik nie mówi, które dokumenty podstawiono, a odpowiedź zastępcy i tak musi wygrać średnią z Astrą, zanim stanie się kluczem. Nie wyciągamy z tego żadnego wniosku o wyniku jakiegokolwiek modelu, a czterej zewnętrzni recenzenci powiedzieli nam, że umieszczenie tego faktu wewnątrz powyższej argumentacji i tak do niego zapraszało; dlatego stoi tutaj.
Źródła. Wpis premierowy TypeSafe, dokumentacja (introduction,
introduction/machine-learning-primer, confidence, System One concepts, HTTP API, primitives/choice) i
evals.typesafe.ai, czytane 16 września 2026 r.; pięć stron i cztery pliki przypadków
(*-cases.js) serwowane przez tę stronę, zarchiwizowane z sumami SHA-256 w naszym repozytorium
raportów. Kim, Garg, Peng i Garg, Correlated Errors in Large Language Models, ICML 2025,
arXiv:2506.07962. Sun, Yin, Xu, Kolter i Liu, Idiosyncrasies in Large Language Models, ICML 2025,
arXiv:2502.12150. Rawat i in., Reference-Based Distillation Detection in LLMs, arXiv:2607.09692.
Soons, Agentic Stemmatics, v1.29, doi:10.5281/zenodo.22790100. Zliczenia w §3 obejmują wyłącznie
dwadzieścia opublikowanych przypadków; ostateczne decyzje porównywano jako nieuporządkowane zbiory
działań; jeden przypadek niesie odpowiedź tylko jednego oceniającego i jest wyłączony z ośmiu na
dziewiętnaście.