Co niszczy jedno podsumowanie: kompresja korpusu przed odpowiadaniem z niego, zmierzona wobec znanego klucza odpowiedzi

Kiedy baza dokumentów przerasta każde okno kontekstowe, standardowym lekarstwem jest podsumować ją raz i odpowiadać z podsumowań. Ta ablacja mierzy, ile kosztuje jedno takie przejście — wobec ukrytego klucza odpowiedzi — i pokazuje, że jedno zdanie dodane do instrukcji podsumowującego przesuwa dokładność bardziej niż cała rozpiętość między architekturami ugruntowania zmierzona na tym samym korpusie w badaniu towarzyszącym.

---

Streszczenie

Gdy baza dokumentów przekracza każde dostępne okno kontekstowe, standardowym lekarstwem jest jej skompresowanie — podsumować każdy dokument raz, a potem odpowiadać na wszystkie pytania z podsumowań. Profil kosztowy jest atrakcyjny, a ryzyko rzadko kwantyfikowane: podsumowanie to stratne kodowanie wybrane bez znajomości pytania. To badanie mierzy, co niszczy pojedyncze przejście kompresji, na dwunastodokumentowym korpusie (~11,5 tys. tokenów) wymagań oprogramowania wielokrotnie zmienianych, odwracanych i odrzucanych, dla którego istnieje ukryty klucz odpowiedzi. Dwa style podsumowania — niezależny od pytania i zachowujący decyzje — uruchomiono na dwóch modelach o różnej sile, na dwudziestu pytaniach w trzech powtórzeniach: 240 odpowiedzi plus 48 jednorazowych wywołań podsumowujących.

Kompresja do 30–34% tekstu pierwotnego zachowała niemal każdy fakt, od którego zależy odpowiedź wzorcowa, a podsumowanie zachowujące decyzje dokładnie dorównało kontekstowi całego korpusu na modelu silniejszym — 20/20 poprawnych, przy 29% tokenów promptu. Jedno zdanie instrukcji dla podsumowującego przesunęło dokładność z 15/20 na 20/20 — więcej niż cała rozpiętość między architekturami ugruntowania zmierzona na tym samym korpusie w badaniu towarzyszącym. Dwa wyniki przeczą oczekiwaniom. Kompresja odwraca porządek trudności zestawu pytań: proste fakty podane dosłownie, odpowiadane poprawnie przez każdą architekturę w badaniu towarzyszącym, spadają do 1/3 w trzech z czterech ramion z podsumowaniami, podczas gdy zastąpienie — zaprojektowana trudność korpusu — utrzymuje 7/7 w stylu zachowującym decyzje. A degradacja idzie wyłącznie w stronę odmowy: zero odpowiedzi nieaktualnych i zero zmyślonych w 80 ocenionych odpowiedziach, na korpusie zbudowanym specjalnie po to, by wywołać jedne i drugie. Podsumowanie generyczne zgubiło nazwę integracji i jej próg liczbowy, wiernie zachowując narrację o tym, co posiedzenie postanowiło.

Słowa kluczowe: podsumowanie, kompresja kontekstu, generowanie wspomagane wyszukiwaniem, utrata informacji, projektowanie benchmarków, metodologia ewaluacji.

---

1. Wprowadzenie

1.1 Problem

Hierarchiczne podsumowanie w stylu map-reduce jest tym, co zostaje, gdy korpus nie mieści się ani w oknie kontekstowym, ani w stałym budżecie wyszukiwania. Jego ekonomia jest kusząca: zapłać raz za dokument, a potem obsługuj każde pytanie ułamkiem tokenów. Jego ryzyko jest oczywiste w abstrakcji i rzadko mierzone w praktyce, bo pomiar wymaga korpusu, którego poprawne odpowiedzi są znane niezależnie od skompresowanego tekstu.

Taki właśnie warunek tworzy to badanie. Korpus zbudowano tak, by odpowiedziami były wartości zmieniane dwa–trzy razy oraz role znoszone i przywracane w zawężonym zakresie — dokładnie ten materiał, który podsumowujący spłaszcza do „ustalono parametry sesji” i „doprecyzowano model ról”. Ponieważ istnieje ukryty klucz odpowiedzi, strata jest widoczna wobec wzorca, a nie tylko podejrzewana.

Badanie celowo nie traktuje podsumowania jako kandydata na architekturę. Na korpusie zajmującym 6% okna kontekstowego kompresowanie czegoś, co i tak się mieści, może tylko tracić; przegrana w takich warunkach nie mówiłaby nic o reżimie, w którym podsumowanie faktycznie się wdraża. Uruchomiono je tu jako ablację, żeby ustalić, ile kosztuje jeden poziom kompresji, zanim ktokolwiek zacznie rozumować o kilku.

1.2 Pytania badawcze

• RQ1. Czy jedno przejście podsumowania zachowuje fakty, od których zależą odpowiedzi wzorcowe?
• RQ2. Czy zachowanie faktów w podsumowaniu przewiduje dokładność odpowiedzi, czy też obie wielkości się rozjeżdżają?
• RQ3. Jaka część ewentualnej straty wynika z instrukcji dla podsumowującego, a nie z samej kompresji?
• RQ4. Gdy kompresja gubi fakt, model odmawia czy zmyśla?

1.3 Założenia projektowe

---

2. Materiał i metody

2.1 Korpus i pytania

Dwanaście dokumentów — jedna bazowa specyfikacja wymagań i jedenaście protokołów komitetu sterującego obejmujących pięć miesięcy — łącznie 11 537 tokenów. Skonsolidowany stan końcowy wymagań nie występuje w żadnym pojedynczym dokumencie i musi zostać wyprowadzony z chronologii.

Dwadzieścia pytań w pięciu kategoriach, każde z odpowiedzią wzorcową:

2.2 Style podsumowania

Styl generyczny to warunek realistyczny — potok podsumowuje, zanim ktokolwiek o cokolwiek zapytał. Styl zachowujący decyzje to górna granica osiągalna samym promptem.

2.3 Ramiona

Każde ramię podaje dwanaście podsumowań jednego stylu, sklejonych, jako cały kontekst. Prompt systemowy odpowiadania jest ten sam, którego użyto dla kontekstu całego korpusu w badaniu towarzyszącym, bez zmian. Punkty odniesienia wzięto z tamtego badania, a nie uruchomiono ponownie.

2.4 Miary

Poprawność, nieaktualność, zmyślenie, tokeny promptu i odpowiedzi oraz opóźnienie — jak w badaniu towarzyszącym — plus jedna miara wprowadzona tutaj:

Zachowanie faktów. Dla każdego z dziesięciu faktów, od których zależy odpowiedź wzorcowa, sprawdzenie, czy fakt w ogóle pojawia się w tekście podsumowania. Liczone na podsumowaniach, przed zadaniem jakiegokolwiek pytania, a więc niezależnie od zachowania modelu odpowiadającego. To najwcześniejsze dostępne ostrzeżenie, że potok kompresji się zepsuł, i nic nie kosztuje.

Recall wyszukiwania jest dla tych ramion niezdefiniowany: każdy dokument jest obecny w postaci skompresowanej, więc pokrycie z konstrukcji wynosi 1,00, a interesującą wielkością jest wierność, a nie pokrycie.

2.5 Zabezpieczenia trafności

1. Sonda kontekstu przed każdym przebiegiem: token-kanarek umieszczony na początku kontekstu i odesłany z powrotem, by wykluczyć ciche obcięcie.
2. Buforowanie u dostawcy wyłączone, weryfikowane przy każdym wywołaniu.
3. Buforowanie podsumowań, tak by wszystkie trzy powtórzenia pytania czytały kontekst identyczny bajt po bajcie.
4. Zapas budżetu wyjściowego 2000 tokenów — po tym, jak wcześniejsze badanie na tym korpusie ustaliło, że niski limit głodzi budżet rozumowania i daje puste odpowiedzi na najtrudniejszych pozycjach.
5. Kontrola fałszywie negatywnych w zachowaniu faktów. Pierwsze przejście zgłosiło jako utracone dwa fakty, które były obecne w innym brzmieniu — wtrącenie w nawiasie wewnątrz frazy pokonało wzorzec. Każdą raportowaną stratę potwierdzono odczytem podsumowania, zanim ją zaliczono.
6. Kontrola determinizmu. Żadna para pytanie–ramię nie dała odpowiedzi identycznej bajt po bajcie we wszystkich trzech powtórzeniach w żadnym ramieniu, co potwierdza prawdziwą wariancję próbkowania, a nie cache.

2.6 Protokół oceny

Jeden wiersz na pytanie i ramię — pierwsze powtórzenie — oceniany wobec odpowiedzi wzorcowej i dokumentów źródłowych, z niezależnym punktowaniem poprawności, nieaktualności i zmyślenia. Osiemdziesiąt ocenionych odpowiedzi.

---

3. Przegląd przebiegów

Łącznie 288 wywołań, bez błędów, bez pustych odpowiedzi.

---

4. Wyniki

4.1 Osiągnięta kompresja i koszt budowy

Budowa to jednorazowy koszt dwunastu wywołań, amortyzowany na każdym kolejnym pytaniu.

4.2 Zachowanie faktów, mierzone na podsumowaniach

Dziesięć faktów, od których zależą odpowiedzi wzorcowe, sprawdzonych w tekście podsumowań przed zadaniem jakiegokolwiek pytania:

Jeden rozstrzygający fakt utracony na model w stylu generycznym; żaden w stylu zachowującym decyzje. W tej mierze strata jest problemem promptu, a nie nieodłącznym kosztem kompresji.

Identyfikatory wypadają gorzej niż decyzje. To samo sprawdzenie dla nazw i liczb, którymi czytelnik odpytywałby korpus:

Podsumowanie generyczne zachowuje narrację o tym, co posiedzenie postanowiło, i odrzuca nazwę rzeczy, której decyzja dotyczyła.

4.3 Dokładność

4.4 Tryby awarii

Wszystkie siedemnaście ocenionych porażek to odmowy albo dające się obronić odpowiedzi częściowe. Trzy pokazują łańcuch przyczynowy od brakującego faktu do odpowiedzi.

• Fakt utracony, model odmawia. Generyczne podsumowanie silniejszego modelu zgubiło konwencję nazewnictwa; wszystkie trzy powtórzenia odpowiadają, że dokumenty jej nie określają, odnotowując jedynie, że utworzenie grup przypisano jako działanie do wykonania. Poprawne zachowanie na niepoprawnym wejściu.
• Fakt utracony, precyzja utracona, prawda zachowana. Generyczne podsumowanie słabszego modelu zgubiło nazwę pola klucza głównego; odpowiedź opisuje go jako uniwersalnie unikalny identyfikator nadawany przez nadrzędny hub danych — właściwe pojęcie bez identyfikatora, który wzorzec nazywa.
• Nazwa utracona, pytanie staje się nieodpowiadalne. Generyczne podsumowanie silniejszego modelu nie zawiera ani nazwy dostawcy, ani progu; odpowiedź stwierdza, że żaden system o tej nazwie nie jest wspomniany. Próg przetrwał w korpusie i jest przez kompresję nieosiągalny.

4.5 Koszt i opóźnienie

Podsumowanie kosztuje 29–41% tokenów promptu pełnego kontekstu i jest od niego wolniejsze mimo krótszego promptu. Najbardziej prawdopodobne odczytanie jest takie, że gęsty, skompresowany kontekst wymaga więcej rozumowania na odpowiedź niż rozwlekły, bo model ma mniej redundancji do pracy; to badanie nie odróżni tego wyjaśnienia od zwykłej wariancji, przy p95 równym 19 s wobec mediany 5 s.

---

5. Synteza

---

6. Kryteria wyboru

Podsumuj-potem-odpowiadaj warto rozważyć, gdy korpus nie mieści się w oknie, liczba zapytań jest dość duża, by zamortyzować budowę, a pytania dotyczą tego, co postanowiono, a nie nazwanych bytów i progów liczbowych.

Należy tego unikać albo łączyć z wyszukiwaniem, gdy pytania przywołują identyfikatory — nazwy produktów, identyfikatory systemów, progi — bo to właśnie one padają pierwsze pod kompresją. Hybryda, w której podsumowania dają orientację, a przebieg wyszukiwania dostarcza dosłownych szczegółów, wynika wprost z wyników o zachowaniu faktów i nie była tu testowana.

Cokolwiek się wybierze, prompt kompresji jest decyzją projektową pierwszej kategorii. Przesunął pięć odpowiedzi na dwadzieścia na modelu silniejszym. Powinien być wersjonowany, przeglądany i testowany regresyjnie jak każdy inny komponent, i musi nazywać klasy bytów, o które później padną pytania.

Oprzyrząduj zachowanie faktów. Sprawdzenie, czy zestaw znanych krytycznych napisów przetrwał kompresję, jest automatyczne, nie wymaga oceniającego ani wywołań odpowiadania i przewidziałoby każdą porażkę w tym badaniu. W potoku produkcyjnym to najtańszy dostępny kanarek.

---

7. Ograniczenia

• Jeden poziom kompresji. Podsumowanie hierarchiczne kumuluje straty na kolejnych poziomach; tu mierzony jest wyłącznie pierwszy poziom i wyniku nie należy ekstrapolować na potok podsumowujący podsumowania.
• Podsumowujący i odpowiadający to ten sam model. Typowy kształt produkcyjny — tani podsumowujący zasilający silniejszego odpowiadającego — nie był testowany i, na podstawie tych danych, odziedziczyłby zachowanie faktów słabszego modelu, a nie czytanie silniejszego.
• Dziesięć ręcznie wybranych faktów. Miara zachowania obejmuje fakty, od których zależą odpowiedzi wzorcowe; nie jest ogólną miarą wierności, a wyniki dokładności pokazują porażki poza jej zasięgiem.
• Dwadzieścia pytań, jedno oceniane powtórzenie na pytanie i ramię. Różnice pięciu odpowiedzi wykraczają poza prawdopodobny szum; dwuodpowiedziowa różnica między stylami słabszego modelu — nie.
• Podsumowania budowane raz. Prawdziwe potoki podsumowują ponownie, gdy dokumenty się zmieniają; dryf między przebudowami nie był mierzony.
• Jeden korpus syntetyczny, jedna dziedzina, wyłącznie angielski i korpus, który wygodnie mieści się w oknie — reżim, dla którego ta ablacja istnieje, jest tym, którego nie da się w niej bezpośrednio przetestować.

---

8. Rozszerzenia

1. Ramię hybrydowe: podsumowania dla orientacji plus przebieg wyszukiwania dla dosłownych szczegółów. Oba profile awarii są komplementarne, co jest najmocniejszym dostępnym argumentem, że połączenie bije każde z osobna.
2. Tani podsumowujący, silny odpowiadający — kształt produkcyjny — by ustalić, czy zachowanie faktów jest własnością samego podsumowującego.
3. Podsumowanie hierarchiczne na korpusie faktycznie przekraczającym okno, z pomiarem zachowania faktów poziom po poziomie: reżim, dla którego to badanie istnieje.
4. Zachowanie faktów jako miara ciągła po automatycznie wyekstrahowanym zbiorze bytów i liczb, a nie po dziesięciu ręcznie wybranych faktach, tak by mogła działać bez nadzoru w potoku.
5. Przegląd współczynnika kompresji. Wszystko tutaj siedzi przy ~30% oryginału; krzywa między 10% a 60% jest tym miejscem, gdzie wybiera się punkt pracy.

---

9. Wnioski

1. Kompresję dało się przeżyć i była tańsza, niż oczekiwano. Podsumowanie zachowujące decyzje przy 34% tekstu pierwotnego dokładnie dorównało kontekstowi całego korpusu na modelu silniejszym, za 29% tokenów promptu.
2. Prompt podsumowania jest główną decyzją projektową potoku. Jedno zdanie instrukcji przesunęło pięć odpowiedzi na dwadzieścia — więcej niż cała rozpiętość architektoniczna zmierzona na tym samym korpusie — a jest to parametr, którego porównania wyszukiwania z pełnym kontekstem nigdy nie zmieniają.
3. Kompresja niszczy identyfikatory, zanim zniszczy decyzje. Narracja o tym, co posiedzenie rozstrzygnęło, przetrwa; nazwa systemu i jego próg — nie. Zestawy pytań badające wyłącznie „co postanowiono” tego nie wykryją.
4. Trudność jest własnością potoku, a nie pytania. Kategoria, którą każda architektura uznała za trywialną, jest tą, na której podsumowanie zawodzi, a kategoria, którą korpus miał uczynić trudną, jest tą, z którą sobie radzi. Benchmark z ustalonym potokiem tego nie zobaczy.
5. Tryb awarii jest łagodny. Zero odpowiedzi nieaktualnych i zero zmyślonych w osiemdziesięciu ocenionych odpowiedziach, na korpusie zbudowanym po to, by wywołać jedne i drugie: gdy faktu nie ma, te modele to mówią. Ta własność sprawia, że stratny potok jest znośny w produkcji, i należy ją weryfikować, a nie zakładać, dla każdego modelu stawianego w tej roli.