Model może działać poprawnie, dokument zawiera właściwą informację, a system RAG nadal jej nie znajduje. Wtedy problem często pojawia się wcześniej niż na etapie generowania odpowiedzi – podczas przygotowania treści do wyszukiwania.
Chunking RAG określa, jakie fragmenty dokumentu stają się jednostkami retrievalu. Embeddingi pozwalają porównywać ich znaczenie z zapytaniem. Obie decyzje wpływają na kontekst, który trafi do modelu.
Dlaczego wielkość fragmentu ma znaczenie?
Zbyt duży fragment może obejmować kilka tematów naraz. Jego reprezentacja staje się mniej precyzyjna, a wyszukiwanie ma trudniejsze zadanie.
Zbyt mały fragment tworzy odwrotny problem. System może znaleźć właściwe zdanie, ale bez informacji potrzebnych do jego zrozumienia. „Termin wynosi 30 dni” niewiele mówi, jeśli poza fragmentem została informacja, czego ten termin dotyczy.
Nie istnieje więc jedna właściwa wielkość fragmentu RAG dla wszystkich źródeł.
Czy dzielić dokument po liczbie znaków?
Stała liczba znaków lub tokenów jest prostym punktem startowym, ale nie uwzględnia struktury materiału.
W dokumentacji technicznej granicą może być sekcja lub nagłówek. W umowie — paragraf albo klauzula. W e-mailu znaczenie może mieć oddzielenie aktualnej wiadomości od cytowanej historii.
Dobry chunking powinien więc odpowiadać strukturze źródła, a nie wyłącznie jednemu globalnemu parametrowi.
Po co overlap i metadane?
Nakładanie fragmentów pomaga zachować kontekst na granicy dwóch chunków. Zbyt duży overlap zwiększa jednak liczbę danych i może powodować zwracanie kilku niemal identycznych wyników.
Przy fragmencie warto też zachować metadane: źródło, sekcję, datę czy wersję. Pozwalają później filtrować wyniki i ustalić pochodzenie informacji.
Co naprawdę robi embedding?
Embedding zamienia treść na reprezentację liczbową, która pozwala porównywać podobieństwo znaczeniowe. Dzięki temu system może odnaleźć fragment powiązany z pytaniem nawet wtedy, gdy nie używa dokładnie tych samych słów.
Różne modele embeddingowe mogą inaczej reprezentować tę samą treść. W rozwiązaniu opartym na similarity search zapytanie powinno być osadzane zgodnie z modelem użytym do reprezentacji indeksowanych fragmentów.
Podmiana modelu embeddingowego nie jest więc neutralną zmianą konfiguracji. W praktyce zwykle oznacza wygenerowanie nowych embeddingów dla dokumentów i przebudowę odpowiedniej części indeksu.
Jak sprawdzić, czy chunking działa?
Najlepiej na rzeczywistych pytaniach.
Warto sprawdzić, czy właściwy fragment pojawia się w wynikach, czy zawiera wystarczający kontekst i czy lista nie jest zdominowana przez kilka prawie identycznych chunków.
Jeżeli informacja istnieje w dokumentach, ale system regularnie jej nie znajduje, nie warto od razu zmieniać LLM. Problem może leżeć właśnie w chunkingu albo embeddingach.
Jak Prognetics podchodzi do chunkingu i embeddingów?
W Prognetics nie dobieramy parametrów RAG w oderwaniu od danych. Najpierw trzeba zobaczyć strukturę źródeł i pytania, na które system RAG ma odpowiadać. Dopiero potem można testować granulację fragmentów i sposób reprezentacji.
Celem nie jest zbudowanie największego indeksu. Celem jest retrieval, który dostarcza modelowi właściwy kontekst.
Od czego zacząć?
Warto przygotować reprezentatywne dokumenty, zestaw rzeczywistych pytań i fragmenty uznane za prawidłowe źródła odpowiedzi. To pozwala oceniać chunking RAG na wyniku, a nie na samych parametrach.
