Po dwudziestu poprawkach LLM-em twój dokument to nie jest już twój dokument. Microsoft mierzy 25-50%.

Każdy prawnik, który pracuje z LLM-em nad pismem dłużej niż jedną sesję, zna ten układ. Jest pierwsza wersja dokumentu - umowa o świadczenie usług, pismo procesowe, opinia. Wkleja się do Claude'a lub ChatGPT, prosi o poprawkę: "dodaj klauzulę indemnification", "skróć stan faktyczny do dwóch akapitów", "uzupełnij argument z art. 805 KC". Model zwraca poprawioną wersję. Prawnik ją kopiuje, czyta, wraca z kolejną prośbą: "teraz dodaj punkt o jurysdykcji", "przerób sekcję 4 na bardziej formalny ton", "dopisz dwa zdania o odsetkach". Po dwudziestu turach takiej pracy dokument wygląda inaczej. Pytanie, którego dotąd nikt empirycznie nie postawił: o ile inaczej.

Zespół Microsoft Research odpowiada w preprintcie z 17 kwietnia 2026: średnio dokument traci pięćdziesiąt procent zawartości. Najlepsze dostępne modele (Gemini 3.1 Pro, Claude 4.6 Opus, GPT 5.4) tracą dwadzieścia pięć procent. To nie jest błąd jednego modelu lub jednej generacji - to systemowa właściwość delegacji edycji dokumentu LLM-owi w długim horyzoncie. I to nie pomaga zwrócenie modelowi narzędzi (search-and-replace, code execution, file edits) - z toolami jest gorzej, średnio o sześć punktów procentowych.

O czym jest ten materiał

Trzydzieści jeden stron głównego artykułu plus obszerny appendix. Empiryczna praca eksperymentalna z dwoma głównymi wkładami:

• DELEGATE-52 - benchmark trzystu dziesięciu środowisk pracy (work environments) w pięćdziesięciu dwóch domenach zawodowych. Domeny obejmują kodowanie, krystalografię, genealogię, notację muzyczną, edycję LaTeX, dokumenty prawne, finansowe, naukowe, kreatywne. Każde środowisko zawiera prawdziwe dokumenty (3-5 tysięcy tokenów), niepowiązany kontekst dystraktora (8-12 tysięcy tokenów) i pięć do dziesięciu zadań edycyjnych typu "user might ask LLM to carry out".
• Round-trip relay simulation - metoda symulacji długiego horyzontu interakcji bez potrzeby annotation lub reference solutions. Każde zadanie ma parę: forward edit (dodaj klauzulę X) + backward edit (usuń klauzulę X). Po n round-tripów (n par forward+backward) dokument powinien teoretycznie wrócić do oryginału. Reconstruction Score RS@k mierzy similarity między oryginałem a stanem po k interakcjach.

Dziewiętnaście modeli przetestowanych: rodzina GPT (4o, 4.1, 5 Nano, 5 Mini, 5 Chat, 5, 5.1, 5.4, o1, o3), Claude (4.6 Sonnet, 4.6 Opus), Gemini (3 Flash, 3.1 Pro), Mistral Large 3, xAI Grok 4, OSS 120B, Kimi K2.5, Mistral Large 3. Pełna mapa od modeli budżetowych po frontier. Dwadzieścia interakcji jako standardowy horyzont - krótszy niż realistyczna sesja prawnika nad pismem trwająca dni, ale dłuższy niż benchmarki "krótkie".

Recenzja właściwa

Główny wynik. Wszystkie modele degradują.

Tabela 1 paperu jest w tej recenzji najważniejszym dowodem. Wszystkie dziewiętnaście modeli zaczynają z wysokimi RS@2 (od 30 do 92) i kończą w RS@20 znacznie niżej. Średnia degradacja przez wszystkie modele: pięćdziesiąt punktów procentowych. To znaczy, że dokument po dwudziestu turach edycji jest podobny do oryginału w pięćdziesięciu procentach treści.

Modele frontierowe radzą sobie lepiej, ale nie świetnie. Gemini 3.1 Pro kończy z RS@20 około 60-65 (degradacja 25 punktów od początkowej). Claude 4.6 Opus i GPT 5.4 w podobnym przedziale. Frontier models = mniej niż 25% utraty zawartości. Modele słabsze (GPT 5 Nano, GPT 4o, OSS 120B) - degradacja 70-90 punktów, co znaczy, że dokument po dwudziestu turach to zasadniczo nie jest już ten sam dokument.

Tabela 2 (per-domain breakdown) pokazuje rozkład jeszcze ostrzejszy. Najlepszy model (Gemini 3.1 Pro) jest gotowy do delegowanej pracy w jedenastu z pięćdziesięciu dwóch domen. "Gotowy" w terminologii autorów oznacza zachowanie zawartości na poziomie, który pozwoliłby praktykom branży zaakceptować pracę. W reszcie czterdziestu jeden domen - nie. Bezpośrednia konsekwencja: nie ma jeszcze takiego modelu, który możemy bezpiecznie pozostawić samego z dokumentem na dwadzieścia tur edycji we wszystkich obszarach pracy zawodowej. Może w niektórych - ale to wymaga doboru modelu pod konkretną domenę.

Ustalenie przeciwintuicyjne. Tools nie pomagają.

Hipoteza, którą każdy ML engineer testuje pierwszą, brzmi: dajmy modelowi narzędzia. Niech zamiast regenerować całe pliki, robi targeted modifications - search-and-replace, plik-do-pliku edit, code execution. Powinno zmniejszyć ryzyko inadvertent corruption.

Autorzy zaimplementowali podstawową agentic harness (Yao et al., 2022) z file reading, writing i code execution tools. Cztery testowane modele radzą sobie gorzej z toolami niż bez. Dodatkowa degradacja: średnio sześć punktów procentowych do końca symulacji. Najlepiej radzący sobie GPT 5.4 traci tylko trzy dodatkowe punkty (71,5 vs 68,3). Pozostałe trzy modele tracą więcej.

Powód: koszt kontekstowy. Agent wywołuje 8-12 tooli na zadanie, zużywając 2-5 razy więcej tokenów wejściowych niż wersja bez tooli. Long-context performance LLM-ów jest znanym problemem - im więcej kontekstu, tym gorsza rekonstrukcja. Autorzy zaznaczają, że to nie był optimized SOTA agent - przyszłe prace mogą zbudować lepszą harness. Ale wniosek dla praktyki dziś: "daj agenta z toolami zamiast LLM-a w trybie chat" nie rozwiązuje problemu degradacji, a w naiwnej implementacji go pogłębia.

Inne ustalenia istotne dla pracy nad dokumentem prawnym

Document Size Effect (sekcja 4.3). Większy dokument = większa degradacja. To intuicyjne, ale empirycznie potwierdzone. Dla kancelarii to znaczy, że umowa o zasadach świadczenia usług na trzydziestu stronach jest bardziej narażona niż jednostronicowy aneks. Ekstrapolacja na nasze realne dokumenty (umowy 50-200 stron, dossier 500+ stron) - degradacja będzie wyższa niż w benchmarku, gdzie autorzy testowali na 3-5 tysiącach tokenów (kilka stron).

Length of Interaction (sekcja 4.4). Degradacja narasta z każdą iteracją - nie liniowo, ale logarytmicznie. Pierwsze pięć tur kosztuje najmniej. Tury 5-15 to środek, gdzie utrata jest istotna. Tury 15-20 to plateau dla niektórych modeli, ale wciąż akumulacja błędów. Wniosek: krótkie sesje są bezpieczniejsze niż długie, niezależnie od sumarycznej liczby zmian. Dziesięć poprawek w dwóch oddzielnych sesjach z fresh context jest mniej destrukcyjne niż dziesięć poprawek w jednej sesji rolling.

Distractor Effect (sekcja 4.5). Niepowiązany kontekst (8-12 tysięcy tokenów dystraktora) pogarsza wynik. To znaczy, że "wklej do okna umowę i jeszcze trzy inne dokumenty referencyjne, niech model je weźmie pod uwagę" jest gorsze niż "wklej tylko umowę". Każdy dodatkowy plik w kontekście to ryzyko, że model pomyli, którą zmianę gdzie zastosować, lub że "wyciągnie" fragment z dystraktora do dokumentu głównego.

Short interaction nie jest predykcyjna dla long-horizon (sekcja 6 Implications). Modele, które wyglądają świetnie po dwóch turach, nie są wcale najlepsze po dwudziestu. Benchmarki krótkoterminowe (typu "dokończ ten fragment" lub "popraw tę linię") są mylące dla użytkownika, który będzie z modelem pracował godzinami. To uzasadnienie istnienia DELEGATE-52 i argument przeciw ocenom dostawcy LegalTech opartym wyłącznie na krótkich demos.

Verification Stack v3 (propozycja MateMatic) - po Laban et al. 2026

W tomie BW/031 (Levy) MateMatic opisał Verification Stack v1 jako jakościowy protokół weryfikacji wyników AI. W tomie BW/034 (Kumaran) wprowadziliśmy v2, mechanistyczną - z regułami architektonicznymi opartymi na choice-supportive bias i hypersensitivity to contradiction. Po Laban et al. 2026 proponujemy Verification Stack v3 (interpretacja MateMatic, nie ustalenie autorów), która dodaje wymiar czasowy: jak organizować iteracyjną pracę z LLM nad dokumentem żeby nie tracić zawartości.

Reguła czasowa #1. Limituj liczbę iteracji nad jednym dokumentem do pięciu, maksymalnie siedmiu, w jednej sesji. Powód: degradacja jest najmniejsza w pierwszych pięciu turach (Tabela 1). Po piątej turze wracaj do oryginału - nie do ostatniej wersji modelu, tylko do dokumentu jako prawnik go napisał - i zaczynaj nową sesję.

Reguła czasowa #2. Po każdej sesji robotaj diff między ostatnim outputem modelu a oryginałem. Word, LaTeX, Google Docs - każdy ma diff. Sprawdzaj nie tylko "czy zmiany, o które prosiłem, zostały wprowadzone", ale "czy gdzieś indziej coś zniknęło". Reguła pozytywna ("dodaj klauzulę") jest łatwa do weryfikacji. Reguła negatywna ("nic poza klauzulą się nie zmieni") wymaga aktywnego sprawdzenia, bo model będzie korygował także rzeczy, których o korektę nie prosiłeś.

Reguła czasowa #3. W jednej sesji LLM-em pracuj nad jednym dokumentem. Nie wklejaj umowy razem z trzema referencyjnymi orzeczeniami i dwiema notatkami klienta. Distractor Effect z paperu - im więcej w kontekście, tym gorzej. Jeśli potrzebujesz informacji z innego dokumentu, zrób to manualnie: skopiuj odpowiedni fragment do prompta tekstem.

Reguła architektoniczna #1. Nie używaj agentic harness ze standardowymi toolami (file edit, search-and-replace) jako rozwiązania na degradację. Eksperyment Microsoft pokazuje, że to nie pomaga - co najmniej w naiwnej implementacji. Jeśli kupujesz LegalTech reklamujący "nasz agent z toolami sprawdza dokument" - poproś o long-horizon evaluation, nie krótki demo.

Reguła architektoniczna #2. Wybór modelu pod konkretną domenę pracy ma znaczenie - "11 z 52 domen" znaczy, że dla niektórych zadań Gemini 3.1 Pro zda egzamin, dla innych nie. Kancelaria, która rzetelnie ewaluuje LegalTech, powinna mieć własny mini-benchmark - powiedzmy dwadzieścia round-trip edits na typowej umowie - i mierzyć różne modele, nie tylko porównywać z marketing decks.

Co z tego dla audytu dostawców LegalTech

Po BW/034 (Kumaran) dodaliśmy do checklisty audytu dostawcy dwa pytania: czy model widzi swoją wcześniejszą odpowiedź przy walidacji; czy moduł weryfikacji widzi pełną odpowiedź pierwszego modelu. Po Laban dodajemy trzecie i czwarte:

Pytanie audytowe #3. Czy aplikacja LegalTech ma testy long-horizon na DELEGATE-52 lub własnym benchmarku z minimum dwudziestoma round-trip edits? Jeśli demo trwa pięć minut z trzema poprawkami, to jest insufficient evidence. Poproś o twarde dane: średnia reconstruction score po dwudziestu interakcjach na umowach o porównywalnej do twoich długości.

Pytanie audytowe #4. Jeśli aplikacja używa tooli (search-and-replace, file edit, code execution) jako głównego mechanizmu modyfikacji dokumentu - jaka jest ich own ablation analysis pokazująca, że ta architektura nie pogarsza wyników w stosunku do prostego LLM-call-and-replace? Microsoft Research pokazał, że basic agentic harness pogarsza wyniki o sześć punktów. Jeśli dostawca nie ma odpowiedzi - czerwona flaga.

Czego paper nie pokrywa

Single-turn interaction. Symulacje używają single-turn sessions, gdzie każda instrukcja w pełni specyfikuje zadanie. W praktyce prawnik underspecyfikuje - "popraw to" - i iteruje przez clarification. Wielotura prawdopodobnie pogarsza degradację (autorzy explicite: "would likely amplify degradation"). To znaczy, że nasze realne sesje z prawnikiem mówiącym "no jakoś nie, spróbuj jeszcze raz, ale lepiej" są jeszcze gorsze niż 50% z paperu.

Practical constraints. Document size 3-5k tokens. Distractor 8-12k. Relay length 20. Wszystkie te parametry są poniżej typowej kancelaryjnej skali pracy. Kancelaria pracuje na umowach 30-200 stron (10-60k tokenów), z dossier sprawowym 100-500 stron, w sesjach trwających dni nie godziny. Autorzy potwierdzają: zwiększenie tych parametrów pogarsza wyniki.

Conceptual constraints. Framework wymaga (a) backtranslation - czyli, że każdy edit ma reverse, (b) parsowalności domeny do oceny strukturalnej. Dla umowy strukturalna ocena jest możliwa (sekcje, klauzule, definicje); dla creative writing trudniejsza. Domena Fiction jest jako jedna z pięćdziesięciu dwóch (specjalna metoda ewaluacji). Memo prawne lub opinia, gdzie argumentacja jest płynna, mieszczą się gdzieś między strukturą umowy a kreatywnością fiction - wnioski przekładają się ostrożnie.

Brak modeli specjalistycznych LegalTech. Paper testuje modele ogólnego przeznaczenia. Polskie modele (Bielik), polskie fine-tune'y na orzecznictwie, dedykowane systemy LegalTech (Gaius-Lex, Legora) - nieprzetestowane. Można przypuszczać, że domain-specific tuning pomaga, ale nie jest to udowodnione przez ten paper.

Co z tego wynika

Laban, Schnabel i Neville dostarczają kancelarii prawnej trzech rzeczy. Po pierwsze, twardą liczbę: 50% zawartości dokumentu jest tracone po dwudziestu iteracjach LLM-em. To nie jest "AI czasem się myli", to mierzalna stratność systemowa. Po drugie, mapę gotowości: najlepszy model frontierowy jest ready dla 11 z 52 domen, więc pytanie nie brzmi "który model najlepszy", tylko "który model dla mojej domeny pracy". Po trzecie, anti-pattern dla dostawców LegalTech: agentic tools jako mechanizm rozwiązania problemu degradacji to architektura o nieuzasadnionym założeniu, którą trzeba audytować, nie kupować na słowo.

Dla kogo ten materiał. Dla compliance officera kancelarii, który układa politykę użycia AI - reguły czasowe Verification Stack v3 (limit 5-7 iteracji, fresh context, sprawdzanie diff) są bezpośrednio aplikowalne, bez infrastruktury. Dla partnera audytującego dostawcę LegalTech - pytania #3 i #4 to dwa konkretne kryteria, które rozstrzygają, czy oferta ma empiryczne podstawy. Dla każdego adwokata pracującego z LLM-em nad pismem dłużej niż jedną sesję - konkluzja, że "wracam do ostatniej wersji modelu i ciągnę dalej" jest droga obarczona wbudowaną stratnością.

Dla kogo nie. Dla nikogo, kto chciałby, żeby benchmark był jednorazową rzeczą do odhaczenia. DELEGATE-52 jest publicznie udostępniony - autorzy explicite chcą, żeby służył do monitorowania gotowości AI w czasie. Nowa generacja modeli pojawi się za sześć miesięcy. Empiryczne pytanie czy degradacja spadła z 50% do 30%, czy została na miejscu, jest do zadania na nowo.