Jak dzielić umowy, polityki i długie dokumenty, nie gubiąc warunków

Jak odpowiedź odrywa się od swoich warunków

Dokumenty biznesowe umieszczają regułę w jednym miejscu, a jej ograniczenia w innym. Klauzula płatności mówi, że faktury są płatne w 30 dni, a następna, że nie dotyczy to kwot spornych. Polityka urlopowa używa pojęcia uprawniony pracownik, zdefiniowanego dwie strony wcześniej. Tabela cen zawiera liczby, których waluta i data obowiązywania stoją w wierszu nagłówka na poprzedniej stronie.

Jeśli pociąć taki dokument na równe kawałki, wyszukiwanie może zwrócić regułę bez wyjątku. Model odpowiada wtedy pewnie i myli się dokładnie w tym przypadku, o który pytał użytkownik. Nakładanie się chunków pomaga, gdy zdanie zostało przecięte na granicy. Definicji sprzed dwóch stron nie przywróci.

Dziel według struktury, którą dokument już ma

Wytyczne Microsoftu dotyczące chunkingu wiążą metodę ze stopniem ustrukturyzowania dokumentu. Teksty prawne i specyfikacje mają strukturę domyślną, czyli numerowane akapity bez znaczników, i dla nich zalecane są własny kod albo własne modele; chunki stałej wielkości z nakładaniem pasują do tekstu nieustrukturyzowanego, takiego jak maile i notatki. Wybór metody nazywają też decyzją półtrwałą, bo późniejsza zmiana wpływa na wszystko, co jest dalej w łańcuchu.

• Umowy: jeden chunk na numerowaną klauzulę, z podpunktami razem
• Polityki: jeden chunk na sekcję z nagłówkiem, dalszy podział tylko na podnagłówkach
• Procedury: każda procedura w całości, jeśli się mieści, bo krok wyrwany z kolejności jest niebezpieczny
• Tabele: wiersze albo grupy wierszy z powtórzonym nagłówkiem w każdym chunku

Przenieś kontekst do każdego chunka

Klauzula w rodzaju „termin z punktu 4.2 nie ma zastosowania” sama w sobie nic nie znaczy. Dodaj na początku to, czego potrzebowałby czytelnik: tytuł dokumentu, ścieżkę nagłówków, wersję albo datę obowiązywania i definicje pojęć użytych w chunku. Anthropic przetestował w 2024 roku pokrewny pomysł: model generował krótki kontekst dla każdego chunka, dopisywany przed embeddingiem i indeksowaniem słów kluczowych. W tych eksperymentach odsetek błędów w pierwszej dwudziestce spadł o 35 procent z kontekstowymi embeddingami i o 49 procent po dodaniu kontekstowego wyszukiwania po słowach kluczowych. Te liczby opisują zbiory danych Anthropic, a nie twoje.

Odwołania krzyżowe wymagają drugiego mechanizmu. Gdy pobrana klauzula odsyła do innej, aplikacja może dociągnąć tę drugą albo wyszukiwać małe chunki i przekazywać modelowi całą sekcję nadrzędną.

Wybór strategii przez eksperyment

Zbierz pytania, których poprawna odpowiedź zależy od warunku, wyjątku albo definicji, i oznacz zarówno fragment z odpowiedzią, jak i fragment z warunkiem. Zdefiniuj dwie lub trzy strategie i uruchom każdą na tych samych pytaniach z tym samym budżetem tokenów na pobrany tekst, dopasowując liczbę chunków do ich rozmiaru. LlamaIndex zaznacza, że mniejsze chunki mogą wymagać większego top-k, żeby pobrać dość materiału. Jeśli wolisz ustalić stałą liczbę chunków, podawaj, ile kontekstu i jaki koszt każda strategia przekazuje wtedy do modelu, bo większe chunki wnoszą do promptu więcej tekstu.

Chunking experiment: supplier contracts (hypothetical numbers)
40 labelled questions; every run passes about 4,000 tokens of
retrieved text to the prompt, so k is adjusted to the chunk size

Strategy                               k    Answer passage   Answer + its
                                            in prompt        condition in prompt
A  fixed size, small chunks           12    33 / 40          19 / 40
B  one chunk per numbered clause       8    34 / 40          27 / 40
C  clause + heading path + defined     7    36 / 40          33 / 40
   terms prepended to each chunk

Decision: C for contracts. Re-run when the template or embedding model changes.

Liczby w przykładzie są zmyślone. Porównaj dwie ostatnie kolumny: wszystkie trzy strategie zwykle wprowadzają regułę do promptu, a różnica wychodzi dopiero wtedy, gdy wymagany jest także warunek. Zestaw testowy bez pytań zależnych od warunków oceniłby je niemal tak samo.

Koszty i miejsca, w których chunking według struktury zawodzi

Każdy typ dokumentu z własnym parserem to kod do utrzymania, a Microsoft wymienia liczbę odrębnych implementacji chunkingu jako czynnik kosztowy. Zeskanowane dokumenty z niepewnymi nagłówkami, klauzule dłuższe, niż przyjmuje model embeddingów, i wzory zmieniające numerację między wersjami osłabiają to podejście. Generowanie kontekstu dla każdego chunka modelem dodaje koszt przy ingestii. A ponieważ chunki i embeddingi zależą od siebie, zmiana strategii albo modelu embeddingów oznacza ponowne indeksowanie.

Rozsądna ścieżka: zacznij od domyślnego splittera swojego frameworka jako udokumentowanego punktu odniesienia, dodaj chunking według struktury dla dwóch lub trzech typów dokumentów, których dotyczą najważniejsze pytania, i zachowaj eksperyment, żeby dało się go powtórzyć po zmianie wzorów.