Dzielisz umowę co tysiąc znaków i jedna klauzula ląduje w dwóch fragmentach. Pierwszy mówi o ograniczeniu odpowiedzialności, drugi o wyjątku. Model odpowiada tylko z pierwszego, bo wygląda na kompletny. Problem nie leży w długości kontekstu, tylko w utracie relacji.
Chunking powinien zachowywać znaczenie i źródło. Nie ma jednej idealnej liczby znaków. Sekcja, tabela i definicja wymagają innego podejścia niż luźny akapit.
Zacznij od pytania i typu dokumentu
Zapisz, czy użytkownik szuka definicji, procedury, liczby, wyjątku czy porównania. Fragment powinien zawierać odpowiedź i warunek potrzebny do interpretacji. Nie dziel dokumentu przed rozpoznaniem zadania.
Przy umowie zachowaj definicje i odniesienia. Przy FAQ zachowaj pytanie z odpowiedzią. Przy tabeli zachowaj nagłówek i wiersze. Jedna reguła dla wszystkiego zaczyna gubić sens.
Oceń, czy potrzebujesz pełnego dokumentu dla niektórych pytań. Chunking nie zastępuje analizy całości przy konflikcie i zależnościach.
Dziel według struktury
Użyj nagłówków, sekcji, stron i logicznych tematów. Zachowaj hierarchię, żeby fragment wiedział, do której części należy. Sam akapit bez sekcji może zmieniać rolę.
Nie przecinaj listy warunków lub tabeli tylko dla równej długości. Możesz mieć krótkie i długie fragmenty zgodne ze znaczeniem. Równe bloki wyglądają ładnie w bazie, a niekoniecznie czyta się je dobrze.
Przy złożonym dokumencie przygotuj mapę przed dzieleniem. Zaznacz definicje, załączniki i odniesienia. Model może pomóc, ale właściciel potwierdza strukturę.
Metadane należą do fragmentu
Zapisz identyfikator dokumentu, wersję, sekcję, stronę, właściciela, status i uprawnienia. Sam tekst nie wystarcza do odbioru. Użytkownik powinien móc wrócić do oryginału.
Fragment dziedziczy ograniczenia źródła. Nie przypisuj nowych na podstawie treści. Przy usunięciu dokumentu wszystkie fragmenty wymagają obsługi.
Przy wersji roboczej i zatwierdzonej zachowaj status. Nie mieszaj ich w odpowiedzi jako równych źródeł. To jest decyzja procesu, nie formatowania.
Warunek i definicja muszą być obok
Przy klauzuli z odniesieniem do definicji dołącz ją lub zachowaj relację. Model nie powinien odpowiadać z pojęciem bez znaczenia. Link do innej sekcji nie wystarcza, jeżeli nie zostanie pobrana.
Przy „z zastrzeżeniem sekcji X” zachowaj sekcję X jako zależność. Możesz pobrać ją przy zapytaniu lub połączyć w jeden pakiet. Test powinien obejmować takie przypadki.
Nie duplikuj całej definicji przy każdym fragmencie bez potrzeby. Zwiększa to kontekst i wersje do aktualizacji. Relacja pozwala pobierać zależne źródła kontrolowanie.
Tabele są osobnym formatem
Zachowaj nagłówki, wiersze i jednostki. Nie dziel tabeli w listę zdań bez relacji. Możesz użyć strukturalnych rekordów zamiast samych fragmentów tekstu.
Przy dużej tabeli dziel według grup i zachowaj nagłówek przy każdej partii. Pusta komórka ma znaczenie. Model nie powinien przesuwać wartości dla pełności.
Przy obliczeniach zachowaj składniki i formułę. Fragment z samą sumą nie pozwala sprawdzić źródła. Przewodnik o analizie tabel i wykresów AI opisuje odbiór.
Długość zależy od odpowiedzi
Krótkie pytanie faktograficzne może wymagać małego fragmentu. Złożona procedura potrzebuje kilku powiązanych sekcji. Nie wybieraj stałej liczby bez testu.
Zbyt małe fragmenty gubią kontekst i tworzą dużo podobnych wyników. Zbyt duże dodają niepotrzebne fakty i konflikty. Oceń, co trafia do modelu i jak jest używane.
Przy długim dokumencie możesz mieć osobne pakiety dla pytań ogólnych i szczegółowych. Nie musisz wybierać jednego formatu dla każdej intencji.
Overlap nie naprawia złego podziału
Nakładka pomaga zachować ciągłość przy granicy, ale nie zastępuje struktury. Nie dziel losowo i nie licz na to, że zdanie powtórzone w dwóch miejscach zawsze uratuje sens.
Zachowaj identyfikator relacji między fragmentami. Duplikaty w wynikach powinny być deduplikowane przed modelem. Inaczej ta sama treść zajmuje kontekst i zwiększa pewność bez nowego dowodu.
Przy warunkach i definicjach stosuj relacje zamiast ślepej nakładki. To bardziej jawne i łatwiejsze do odbioru.
Wersja i usuwanie fragmentów
Przy nowej wersji aktualizuj wszystkie powiązane fragmenty i indeksy. Stare wersje nie powinny odpowiadać na bieżące pytania. Zachowaj historię zgodnie z procesem.
Przy usunięciu źródła usuń lub oznacz pochodne i cache. Test wyszukiwania charakterystycznej frazy powinien zwracać zero. Nie wystarczy usunięcie pliku.
Przy uprawnieniach zmieniaj je niezależnie od treści. Dokument może pozostać identyczny, ale rola traci dostęp. Indeks musi to obsłużyć.
Test wyszukiwania po chunkach
Przygotuj pytania o fakt z jednej sekcji, warunek z dwóch, tabelę i definicję z innej. Sprawdź, czy pobierane są wszystkie wymagane fragmenty. Nie oceniaj tylko ostatecznej odpowiedzi.
Dodaj przypadki, gdzie najbliższy fragment jest niekompletny. Proces powinien pobierać zależności lub zatrzymać się. Nie wybieraj odpowiedzi za wszelką cenę.
Przy pytaniu bez odpowiedzi sprawdź brak. Mały fragment podobny tematycznie nie powinien tworzyć nowej reguły.
Przykład: klauzula z wyjątkiem
W hipotetycznym przykładzie fragment A mówi o limicie odpowiedzialności, a B zawiera wyjątek dla konkretnego zdarzenia. Model odpowiada tylko z A i przedstawia limit jako ogólny. Przyczyna może leżeć w podziale, pobieraniu fragmentów lub generowaniu. Sprawdź, co trafiło do modelu, zanim przypiszesz błąd jednej warstwie.
Załóżmy, że po dodaniu relacji proces pobiera B i odpowiedź opisuje limit oraz wyjątek z wersją. Test na przygotowanym przypadku powinien sprawdzić, czy oba fragmenty rzeczywiście trafiły do modelu.
Nie wystarczy zwiększenie długości fragmentu dla wszystkiego. Relacja jest bardziej precyzyjna i ogranicza zbędny tekst.
Przykład: instrukcja z krokiem i warunkiem
Kroki są w jednej sekcji, wymagania wstępne w innej. Model instruuje kliknięcie bez roli i wersji. Wynik jest niebezpieczny. Chunking powinien zachowywać warunki przy zadaniu.
Dodaj pakiet z warunkami i odbiorem. Nie przenoś tylko numerowanych kroków. SOP wymaga kontekstu opisanego w przewodniku o SOP z nagrania procesu.
Test obejmuje rolę bez uprawnień i brak warunku. Proces powinien zatrzymać się, a nie tylko odpowiadać z listą.
Oceń, co trafia do kontekstu
Zapisz pobrane fragmenty i ich kolejność. Czy zawierają źródło, warunek, wersję i uprawnienia? Odpowiedź modelu nie wystarcza do diagnozy.
Przy dużej liczbie duplikatów ogranicz je przed generowaniem. To zmniejsza koszt i konflikty. Nie przenoś całej bazy dla bezpieczeństwa odpowiedzi.
Przy błędzie zapisz, czy problem dotyczy podziału, wyszukiwania, wersji czy generowania. Nie zmieniaj długości chunków jako pierwszego kroku.
Kiedy pełny dokument jest lepszy
Przy umowie z wieloma zależnościami, małym SOP lub analizie konfliktu pełny dokument może być lepszy. Chunking nie jest obowiązkowy przy każdym zadaniu. Wybierz go według pytania i wielkości źródła.
Przy krótkiej bazie możesz przekazywać całość z wersją i odbiorem. Nie twórz indeksu dla samej technologii. Prosty proces bywa dokładniejszy.
Przy długim dokumencie rozważ etapy: mapa, zależności, pytania i odbiór. Model nie musi odpowiadać na wszystko w jednym kroku.
Jak oceniać jakość podziału przed indeksowaniem
Wybierz kilka dokumentów i sprawdź granice ręcznie. Czy każdy fragment ma sens bez dodatkowego tłumaczenia? Czy zawiera rolę i wersję? Nie oceniaj tylko liczby znaków i równych bloków.
Zaznacz miejsca, w których odpowiedź wymaga dwóch źródeł. Dodaj relacje przed indeksowaniem. Jeżeli za dużo fragmentów wymaga całej reszty dokumentu, może chunking nie jest właściwy dla tego typu.
Po pierwszym wyszukiwaniu porównaj oczekiwane pakiety z rzeczywistymi. Zmień strukturę zanim indeksujesz całą bazę. To ogranicza koszt ponownej pracy.
Kiedy zwiększyć lub zmniejszyć fragmenty
Przy nadmiarze podobnych wyników sprawdź ich przyczynę i rozważ mniejsze fragmenty lub usuwanie duplikatów. Jeżeli ginie warunek lub definicja, sprawdź większy fragment albo powiązanie źródeł. Porównaj warianty na tym samym zestawie pytań. Różne sekcje mogą wymagać różnych rozmiarów.
Przy tabeli zachowaj strukturę zamiast długości. Przy opisie możesz mieć krótsze fragmenty. Decyzja zależy od pytania, nie od uniwersalnego przepisu.
Po zmianie porównaj ten sam zestaw zapytań i wersję źródeł. Nie przypisuj poprawy nowemu modelowi, jeżeli zmienił się także podział.
Odbiór przez osobę znającą dokument
Poproś właściciela o ocenę kilku fragmentów i relacji. Może wskazać, że warunek został oddzielony lub sekcja jest niejednoznaczna. Model nie powinien decydować o podziale samodzielnie bez odbioru.
Zapisz reguły dla nowego typu dokumentu i test. Nie przenoś starych ustaleń bez oceny. Każdy format ma inne zależności.
Przy zmianie właściciela źródła przekaż mapę podziału i relacji. Nowa osoba powinna wiedzieć, które fragmenty wymagają kontekstu i jak sprawdzić oryginał. Nie przenoś tylko indeksu bez struktury.
Przy nowym dokumencie zachowaj wersję źródłową i sprawdź, czy stara reguła podziału jest właściwa. Nagłówki mogą wyglądać podobnie i mieć inne znaczenie. Nie przenoś schematu bez testu.
Jeżeli odpowiedź wymaga pełnego dokumentu, ogranicz liczbę fragmentów przekazywanych razem. Proces powinien wiedzieć, kiedy zatrzymać i pobrać zależności. Nie buduj odpowiedzi z przypadkowych kawałków.
Przy zakończeniu indeksowania usuń robocze kopie i stare wersje zgodnie z retencją. Fragmenty nie powinny żyć dłużej niż źródło bez decyzji właściciela.
Przy zmianie właściciela przekaż reguły podziału i przypadki. Nowa osoba powinna umieć wskazać, dlaczego fragment zawiera warunek i jak prowadzi do źródła. Nie przenoś samej długości chunków.
Jeżeli nowy typ dokumentu ma inne zależności, przygotuj osobną mapę. Nie dziel go według starego formatu bez oceny. Struktura i odbiór są ważniejsze niż automatyczna jednolitość.
Przy kolejnych aktualizacjach porównaj stare i nowe pakiety. Zachowaj źródło i wersję przy każdym. Raport powinien pokazywać, czy problem dotyczy podziału, pobierania czy generowania.
Przy odbiorze nowego typu przygotuj jeden przypadek z warunkiem i jeden z tabelą. Nie testuj tylko luźnego akapitu. Utrata relacji może zmienić znaczenie odpowiedzi.
Zapisz właściciela struktury i wersję mapy. Po zmianie dokumentu powtórz zależne pytania zamiast indeksowania wszystkiego bez odbioru.
Przy odbiorze końcowym sprawdź, czy każdy fragment ma właściwy dokument i uprawnienia. Podobny tekst z innego źródła nie powinien być przypisany temu samemu właścicielowi.
Zachowaj mapę zależności i datę. Nowy zespół powinien umieć złożyć odpowiedź z fragmentów bez zgadywania brakującego warunku.
Przy odbiorze końcowym sprawdź jeden przypadek z pełną ścieżką od pytania do źródła. Każdy fragment powinien prowadzić do właściwej wersji i uprawnienia. Sam wynik podobny nie wystarcza.
Zapisz ograniczenia podziału i moment, kiedy potrzebny jest pełny dokument. Decyzja o chunkingu ma być procesem, a nie ustawieniem na zawsze.
Aeneia Audit pomaga zmapować strukturę źródeł i odpowiedzialność. Przy architekturze pomocna jest architektura wiedzy Aeneia Signal.
Weź fragment z warunkiem oraz sąsiadującą z nim tabelę i sprawdź, czy po podziale odpowiedź zachowuje ich związek. Odnośnik do źródła powinien pozwalać wrócić do pełnego kontekstu. Jeśli sama długość fragmentu rozdziela wyjątek od reguły, zmień sposób podziału i ponów próbę na tym samym dokumencie.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
