Chunking dokumentów pod retrieval: rozmiar, overlap i miejsce cięcia

O jakości retrievalu rozstrzyga się na długo przed tym, zanim model zobaczy prompt. Rozstrzyga się w chwili podziału dokumentu. Chunk to najmniejsza rzecz, jaką retriever może oddać, a więc też najmniejsza rzecz, na jaką odpowiedź może wskazać. W systemach, które oglądamy, wracają dwa te same problemy: chunki za małe, żeby cokolwiek znaczyć samodzielnie, i chunki za duże, żeby precyzyjnie rankować się względem konkretnego pytania. Embedding ściska fragment do jednego wektora, więc trzy tematy wciśnięte w jeden chunk rozmywają ten wektor w coś, co słabo pasuje do wszystkiego i dobrze do niczego. Cięcie to też decyzja o cytowaniu. Użytkownicy klikają w źródło. Zła granica wrzuca ich w niewłaściwy akapit.

Czym naprawdę steruje rozmiar chunku

Rozmiar to wymiana recall za precyzję. Większe chunki niosą więcej kontekstu na trafienie, mniejsze rankują się ostrzej. Prawdziwym sufitem nie jest limit tokenów modelu embeddingowego - jest nim to, ile niepowiązanego tekstu godzisz się uśrednić w jednym wektorze. Licz też to, co dalej: liczba chunków razy rozmiar chunku musi zmieścić się w promptcie odpowiedzi i zostawić zapas. Regulaminy, specyfikacje produktów, zgłoszenia supportowe, umowy. Każde chce innego celu.

• Odpowiedzi, które cytują nagłówek, ale nigdy zasady pod nim.
• Ta sama długa strona zwracana na każde pytanie, cokolwiek padło.
• Chunki, na podstawie których sam tekst nie pozwoliłby człowiekowi odpowiedzieć.

Wskazówka: zanim cokolwiek zaczniesz stroić, przeczytaj dziesięć losowych chunków z własnego korpusu. Większość problemów z rozmiarem widać bez żadnego benchmarku.

Overlap: co naprawia i ile kosztuje

Overlap chroni fakty, które leżą w poprzek granicy, na przykład definicję oderwaną od zdania, które jej używa. Traktuj to jak ubezpieczenie od złych punktów cięcia, a nie jak zamiennik dobrych. Koszty są konkretne: indeks rośnie, prawie identyczne fragmenty biją się o te same miejsca, a zwracany zestaw zaczyna się powtarzać. Kiedy overlap idzie w górę, deduplikacja na etapie retrievalu przestaje być opcjonalna. Inaczej model czyta to samo zdanie dwa razy i po cichu wypada mu inne źródło, które wniosłoby coś nowego. Tam, gdzie struktura jest mocna, z wyraźnymi nagłówkami i numerowanymi punktami, overlap może zejść niemal do zera. W nieustrukturyzowanych transkrypcjach albo skanowanej prozie zarabia na siebie.

Gdzie ciąć: struktura wygrywa z liczeniem znaków

Korzystaj z granic, które autor już napisał. Nasza kolejność, od najmocniejszej:

1. Sekcje i nagłówki dokumentu.
2. Akapity.
3. Zdania.
4. Twardy limit znaków albo tokenów, tylko w ostateczności.

Nigdy nie tnij w środku tabeli, bloku kodu, elementu listy ani numerowanego punktu. Traktuj je jako niepodzielne i pozwól im przekroczyć cel. Nagłówek ma wędrować razem z chunkiem, który wprowadza, żeby fragment bronił się bez kontekstu. Zostaw też ślad nawigacyjny: tytuł dokumentu, ścieżkę sekcji, numer strony albo punktu, datę obowiązywania tam, gdzie są wersje. Semantyczny podział po odległości embeddingów brzmi elegancko, ale jest wolny i w praktyce odkrywa na nowo podziały na akapity, które już miałeś.

Wskazówka: przed embeddingiem dopisz na początku każdego chunku krótką linię z tytułem dokumentu i ścieżką sekcji. Recall wyraźnie skacze przy pytaniach, które nazywają dokument zamiast opisywać, co w nim jest.

Metadane, rodzice i cięcie, którego nie musisz wybierać

Retrieval typu small-to-big omija większość sporu o rozmiar. Indeksujesz małe chunki do rankowania, a gdy chunk wygra, podajesz modelowi otaczającą go sekcję nadrzędną. Precyzja i kontekst przestają ze sobą konkurować, bo każde obsługuje inny obiekt. Zapisuj stabilne id chunku, id rodzica, ścieżkę źródła i pozycję, żeby asystent mógł wskazać dokładne miejsce, którego użył, zamiast machać ręką w stronę ogólnej okolicy. Filtry po metadanych - produkt, język, dział, wersja dokumentu - zawężają przestrzeń szukania, zanim w ogóle ruszy liczenie podobieństwa. We wdrożeniach na infrastrukturze klienta trzymaj chunker deterministyczny: reindeks musi dać identyczne id, inaczej każde zapisane odwołanie się psuje.

Jak testować strategię chunkingu zamiast się o nią spierać

Zbuduj mały zestaw pytań z tego, o co naprawdę pytają użytkownicy, i ręcznie zaznacz fragment, który ma na każde odpowiadać. Zanim ocenisz brzmienie wygenerowanej odpowiedzi, sprawdź, czy ten fragment w ogóle pojawił się w zwróconym zestawie. Nietrafiony retrieval i nietrafione sformułowanie wymagają innych poprawek. Jedna zmienna na przebieg.

1. Zamroź zestaw pytań.
2. Przeindeksuj z jedną zmianą: rozmiar, potem overlap, potem reguła cięcia, potem metadane.
3. Zapisz trafienia retrievalu.
4. Czytaj porażki, nie średnią.
5. Zachowaj notatki z porażek.

Te nieudane przypadki to jedyny pewny drogowskaz, jaki masz, gdy w korpusie ląduje nowy typ dokumentu.

FAQ

Czy istnieje rozmiar chunku dobry dla każdego korpusu?

Nie. Cel wynika ze struktury dokumentów i stylu pytań, więc zacznij od naturalnych sekcji i koryguj na podstawie porażek, które faktycznie widzisz, a nie liczby pożyczonej z cudzego systemu.

Czy overlap jest potrzebny, jeśli tnę po nagłówkach?

Zwykle dużo mniejszy, bo granica strukturalna pokrywa się już z granicą tematu. Zostaw mały overlap dla długich sekcji, które ciągną się bez żadnej wewnętrznej struktury.

Czy przy zmianie strategii trzeba przechunkować wszystko?

Tak, dla spójności. Mieszany chunking sprawia, że wyniki podobieństwa są nieporównywalne w obrębie indeksu, więc zaplanuj reindeks jako rutynową operację, a nie sytuację awaryjną.

Co zrobilibyśmy najpierw

Kolejność decyzji, do której ciągle wracamy: uszanuj własną strukturę dokumentu, dobierz rozmiar do zadawanych pytań, dodaj overlap tylko tam, gdzie granice naprawdę są niepewne. Przeprowadź metadane i kontekst rodzica przez cały pipeline, żeby odpowiedź mogła pokazać, skąd dokładnie pochodzi. Wracaj do chunkingu za każdym razem, gdy korpus zmienia charakter - to parametr, a nie ustawienie startowe, które raz się ustala i zapomina. W większości systemów retrievalu najtańszą dostępną poprawą jest lepsze cięcie, a nie większy model.