Podręcznik uczestnika z objaśnieniami, przykładami i ćwiczeniami do samodzielnej nauki do Modułu 2

Site: SEZAM - System Edukacyjnych Zasobów Akademickich i Multimedialnych
Course: Lokalne chatboty, agenci i systemy RAG z własną bazą wiedzy
Book: Podręcznik uczestnika z objaśnieniami, przykładami i ćwiczeniami do samodzielnej nauki do Modułu 2
Printed by: Gość
Date: Tuesday, 3 November 2026, 6:42 AM

1. Jak korzystać z podręcznika

Ten podręcznik prowadzi od plików źródłowych do uporządkowanego zbioru fragmentów, który można przekazać do dalszych eksperymentów z RAG. Najważniejszym wynikiem Modułu 2 jest tekst o zachowanym znaczeniu, z rozpoznawalnym źródłem i udokumentowaną oceną jakości.

Co zrobisz w tym module

W Module 1 sprawdzaliśmy, czy odpowiedź ma podstawę w udostępnionym kontekście. Teraz cofamy się o jeden etap: przygotowujemy materiał, z którego przyszły system będzie ten kontekst wybierał. Błąd w dokumencie, utracony warunek lub nieaktualna wersja mogą przejść przez kolejne etapy i trafić do odpowiedzi. Sam model nie naprawi niezauważonej pomyłki w bazie.

Po lekturze umiesz uzasadnić wybór źródeł, rozpoznać błędy odczytu, zaplanować ostrożne czyszczenie, porównać sposoby podziału tekstu, przypisać metadane oraz zdecydować, które fragmenty można przekazać dalej. Uczysz się także opisywać ograniczenia: czego baza nie zawiera i czego jeszcze nie sprawdzono.

Zakres Modułu 2. Nie tworzymy tu embeddingów, indeksu wektorowego ani odpowiedzi modelu. Nie potrzebujesz Ollamy, klucza API ani karty graficznej. OCR jest tematem rozszerzającym; w podstawowych ćwiczeniach nie rozpoznajemy automatycznie tekstu ze skanów.

Jak pracować offline

Czytaj rozdziały R1–R6 po kolei. W każdym znajdziesz wyjaśnienie, przykład, ćwiczenie i pytania kontrolne. Wszystkie fragmenty potrzebne do rozwiązania ćwiczeń są w książce. Odpowiedzi możesz zapisać na papierze lub w dowolnym edytorze. Internet i pliki z pakietu ćwiczeniowego nie są konieczne do wykonania zadań opisanych tutaj.

Najpierw rozwiąż zadanie samodzielnie. Następnie porównaj tok rozumowania z częścią „Odpowiedzi do ćwiczeń”. W zadaniach projektowych dopuszczalne są różne rozwiązania, jeżeli zachowują znaczenie źródła, pozwalają je wskazać i mają jasne uzasadnienie. Słownik na końcu pomaga wrócić do pojęć.

Część Pytanie przewodnie Rezultat nauki
R1. Dokumenty źródłowe Co powinno znaleźć się w bazie? Zakres i decyzje o źródłach
R2. Wczytywanie Czy odczyt odpowiada oryginałowi? Tekst surowy z lokalizatorem
R3. Czyszczenie Co usunąć, a co koniecznie zachować? Tekst oczyszczony i rejestr zmian
R4. Fragmenty Gdzie kończy się samodzielna informacja? Fragmenty z zachowanym kontekstem
R5. Metadane Skąd pochodzi ten fragment? Wspólny schemat i identyfikatory
R6. Kontrola jakości Co można przekazać do kolejnego modułu? Zbiór przyjęty i raport ograniczeń

Wspólny przykład: fikcyjny DocAssist

Pracujemy nad bazą dla wewnętrznego asystenta wspierającego operatorów fikcyjnej aplikacji DocAssist. Ma pomagać w odczytywaniu bieżących zasad wsparcia i instrukcji. Nie wykonuje poleceń administracyjnych. Występujące w książce komendy są tekstem do analizy, a parametry stanowiska odnoszą się wyłącznie do fikcyjnego przykładu.

Korpus Modułu 2 obejmuje instrukcję TXT, regulamin Markdown, dwustronicową dokumentację PDF i stronę pomocy HTML, wszystkie w wersji dokumentu 1.4. Piąty plik to archiwalny regulamin 1.3. Statusy i wersje są podane w materiałach ćwiczeniowych. Dat obowiązywania nie znamy i nie będziemy ich wymyślać.

Ciągłość między modułami. DocAssist pozostaje przykładem dydaktycznym, ale korpus M2 jest osobnym zestawem. Regulamin 1.4 w M2 podaje dyżur 08:00–16:00. Nie uzupełnia to wstecz odpowiedzi w ćwiczeniu M1, w którym udostępniony regulamin nie zawierał godzin. Odpowiedź zawsze ocenia się względem źródeł danego zadania.

Książka i ćwiczenia komputerowe

Książka wyjaśnia decyzje i pozwala ćwiczyć bez komputera. Karty pracy M12_M2_R1_karta_pracy.docx–M12_M2_R6_karta_pracy.docx oraz notebooki z pakietu Student umożliwiają wykonanie całego procesu na plikach. Ćwiczenia offline nie wymagają przepisywania kodu i nie zastępują wyników notebooków, jeśli prowadzący wymaga ich oddania.

Proponowane 165 minut pracy z notebookami to czas ćwiczeń komputerowych, bez lektury, prezentacji i instalacji. Nie jest to limit czasu czytania książki ani dodatkowy warunek zaliczenia.

Zasada, która łączy wszystkie rozdziały

Zachowaj drogę od fragmentu do oryginału. Przechowuj osobno źródło, wynik odczytu, tekst oczyszczony, fragmenty oraz oceny. Jeżeli wynik budzi wątpliwości, wróć do wcześniejszego etapu. Dobra baza wiedzy pozwala wyjaśnić nie tylko, co zawiera, lecz także dlaczego dana treść została dopuszczona.

Przygotowanie dokumentów i bazy wiedzy
ENHANCER+ · Politechnika Warszawska · materiał do samodzielnej nauki offline

2. Dokumenty źródłowe i zakres bazy wiedzy

Budowanie bazy wiedzy zaczyna się od decyzji o celu i źródłach. Folder pełen dokumentów nie jest jeszcze dobrze dobranym korpusem. Włączenie większej liczby plików może zwiększyć pokrycie pytań, ale może też dodać nieaktualne zasady, sprzeczności i treści spoza zadania.

1. Najpierw pytania, potem pliki

Wyobraź sobie użytkownika, który pyta o restart usługi, godziny dyżuru albo sposób zgłoszenia błędu. Baza powinna dostarczyć materiał do takich odpowiedzi. Nie musi zawierać całej dokumentacji organizacji. Opis zakresu powinien wskazywać odbiorcę, rodzaje pytań, dopuszczone źródła i świadomie wyłączone obszary.

Dla naszego przykładu zakres może brzmieć: „Baza wspiera pracowników w interpretowaniu aktualnych instrukcji DocAssist i zasad wsparcia. Korzysta z zatwierdzonych materiałów 1.4. Nie obsługuje historii zmian, nie wykonuje działań administracyjnych i nie ustala terminów, których źródła nie podają”. Takie zdanie pomaga później rozstrzygać przypadki sporne.

Pytania kontrolne powinny pojawić się już teraz, przed czyszczeniem i fragmentacją:

  1. P1: Jak ponownie uruchomić usługę po zmianie konfiguracji i sprawdzić rezultat?
  2. P2: Kiedy operator przyjmuje zgłoszenia i jaki jest wyjątek poza dyżurem?
  3. P3: Jakie wymagania stanowiska podaje dokumentacja DocAssist?
  4. P4: Co zrobić przy błędzie połączenia?
  5. P5: Jaki jest gwarantowany czas rozwiązania zgłoszenia?

P5 jest celowo pytaniem o informację, której wartości nie podano. Baza może być poprawnie przygotowana i nadal nie pozwalać na podanie takiego czasu. To istotne ograniczenie, które trzeba ujawnić.

2. Co oceniać w źródle

Przydatność oznacza związek z pytaniami użytkownika. Aktualność wymaga sprawdzenia wersji i statusu. Pochodzenie pozwala wskazać autora lub właściciela dokumentu. Czytelność dotyczy możliwości poprawnego odczytania treści. Dopuszczenie do użycia wynika z zasad dostępu i celu bazy. Plik może spełniać część tych warunków, a mimo to wymagać wyjaśnienia.

Nie uznawaj pliku za aktualny tylko dlatego, że ma nowszą datę zapisu na dysku. Kopiowanie może zmienić tę datę. Także numer w nazwie pliku nie wystarcza, gdy w treści widnieje inna wersja. W naszym zestawie decyzja jest prostsza: inwentarz i dokumenty jawnie wskazują 1.4 jako wersję obowiązującą, a 1.3 jako archiwalną.

3. Inwentarz naszego korpusu

Poniższa tabela opisuje cały zestaw potrzebny do podjęcia decyzji. Wszystkie dokumenty mają fikcyjnego autora „Zespół dokumentacji DocAssist”. Przyjmujemy dydaktycznie dostęp wewnętrzny (internal). Nie stanowi to automatycznie pozwolenia na opublikowanie podobnych, rzeczywistych dokumentów poza organizacją.

Plik i identyfikator Zawartość Wersja i status
instrukcja.txt · DOC-INSTR Restart po zmianie konfiguracji, kontrola stanu, kopia konfiguracji 1.4 · active
regulamin.md · DOC-REG Dyżur 08:00–16:00, wyjątek awaryjny, treść zgłoszenia 1.4 · active
docassist.pdf · DOC-PDF Wymagania stanowiska i diagnostyka, 2 strony 1.4 · active
pomoc.html · DOC-HELP Błąd połączenia i kontrolny tekst ze znakami specjalnymi 1.4 · active
regulamin_v1_3.md · DOC-OLD Dawny dyżur 09:00–15:00, dokument zastąpiony przez 1.4 1.3 · archived

Inwentarz jest rejestrem, więc może zawierać także źródła odrzucone. Dzięki zapisowi „pominąć, ponieważ wersja jest archiwalna, a zakres nie obejmuje historii” kolejna osoba rozumie przyczynę. Odrzucenie z korpusu nie oznacza usunięcia oryginału z archiwum.

4. Dwie wersje to nie zwykły duplikat

Gdy oba regulaminy trafią do tej samej bazy bez rozróżnienia, przyszły system może znaleźć godziny 08:00–16:00 albo 09:00–15:00. Obie odpowiedzi miałyby tekstowe oparcie w jakimś pliku, lecz tylko jedna odpowiada zakresowi bieżącego asystenta. To błąd doboru źródeł, którego nie naprawia starannie napisany prompt.

Inaczej postąpilibyśmy przy asystencie historii zmian: obie wersje mogłyby być potrzebne, ale pytanie i filtrowanie musiałyby uwzględniać okres lub wersję. Zakres wpływa zatem na dobór danych. Nie istnieje jedna lista źródeł dobra dla każdego zastosowania.

Ważne. Pole access_level opisuje zamierzone uprawnienia. Samo zapisanie internal w metadanych nie blokuje nikomu dostępu. Rzeczywiste ograniczenia musi później egzekwować aplikacja.

5. Ćwiczenie 1 — zbuduj zakres i uzasadnij wybór

Na podstawie pięciu pozycji z tabeli:

  1. Zapisz w dwóch zdaniach odbiorcę, cel i dwa wyłączenia bazy.
  2. Dla każdego pliku wybierz: użyć, pominąć lub wyjaśnić. Dodaj jedno zdanie uzasadnienia.
  3. Wskaż pliki najbardziej przydatne dla P1, P2, P3 i P4. Dla P5 zapisz, czego nie wolno obiecać.
  4. Oceń dodatkowy pomysł: „Dodajmy rozwiązane karty pracy i odpowiedzi z końca książki, żeby asystent lepiej znał ćwiczenia”. Czy to materiał źródłowy dla określonego celu?
  5. Zapisz, co zrobisz, jeśli dokument ma nieznaną datę obowiązywania.

Wynik: krótki opis zakresu, pięć decyzji i lista ograniczeń. Porównaj go z kluczem po wykonaniu zadania.

Sprawdź rozumienie

Czy potrafisz wyjaśnić różnicę między plikiem zachowanym w archiwum a plikiem dopuszczonym do bieżącej bazy? Dlaczego brak odpowiedzi na P5 nie musi oznaczać błędu odczytu? Jak zmieniłby się wybór źródeł dla asystenta historycznego?

Przejście do praktyki: w R1 zapisujesz inwentarz_zrodel.json, zakres_bazy.md i pytania.json. Wybrane źródła stają się wejściem R2.

Przygotowanie dokumentów i bazy wiedzy
ENHANCER+ · Politechnika Warszawska · materiał do samodzielnej nauki offline

3. Wczytywanie treści z różnych formatów

Wczytanie pliku nie jest tym samym co poprawne odczytanie jego znaczenia. Program może zakończyć pracę bez błędu, a wynik nadal może mieć pomieszaną kolejność, pominięte zdanie albo elementy menu w środku instrukcji. Dlatego odczyt trzeba porównać z oryginałem.

1. Cztery formaty, różne pułapki

TXT przechowuje tekst bez rozbudowanego układu. Trzeba poprawnie rozpoznać kodowanie i zachować znaki oraz istotne przejścia do nowego wiersza. Markdown dodaje oznaczenia nagłówków, list i bloków kodu. Usunięcie wszystkich znaków #, - i wcięć bez rozpoznania ich roli może zniszczyć strukturę lub treść polecenia.

PDF opisuje wygląd stron. Tekst widoczny dla człowieka może zostać wyodrębniony w innej kolejności, z nagłówkami i stopkami albo ze słowami podzielonymi na końcu wiersza. Skan strony może nie mieć warstwy tekstowej. Pusty wynik ekstrakcji nie dowodzi wówczas, że dokument jest pusty; oznacza potrzebę rozpoznania typu PDF i ewentualnego OCR, a potem kontroli jego wyniku.

HTML zawiera treść oraz strukturę strony. Nawigacja, stopka i skrypty nie powinny automatycznie stać się wiedzą asystenta. W kontrolowanym przykładzie treść znajduje się w elemencie main. Na innej stronie należałoby sprawdzić jej rzeczywistą budowę, a nie zakładać, że ten sam wybór zawsze wystarczy.

Format Co chcemy zachować Co sprawdzamy w pierwszej kolejności
TXT Zdania, komendy i kolejność kroków Polskie litery, końce wierszy
MD Nagłówki, listy, kod i treść Granice sekcji i dosłowne znaki
PDF Treść oraz rzeczywisty numer strony Kolejność, tabele, dzielenie słów, brak tekstu
HTML Główną treść z nagłówkami Menu, stopkę, skrypty i granice akapitów

2. Zapisuj odczyt jako osobny etap

Po ekstrakcji zachowujemy tekst surowy (raw_text), identyfikator dokumentu, identyfikator rekordu i lokalizator. W naszym zestawie TXT, MD i HTML dają po jednym rekordzie, a PDF dwa — po jednym na stronę. Cztery wybrane pliki dają więc pięć rekordów. Liczba dokumentów, rekordów i późniejszych fragmentów nie musi być taka sama.

Numer strony powinien wskazywać rzeczywistą stronę PDF liczoną od 1. Dla TXT, MD i HTML nie przypisujemy stron udających paginację: wpisujemy null. Sekcja dokumentu może pomóc w odnalezieniu treści, lecz nie staje się z tego powodu stroną PDF. Surowy tekst przechowujemy przed czyszczeniem, aby móc porównać efekt kolejnych operacji.

3. Przykład HTML: widok strony a wiedza

W pomoc.html występują następujące elementy. Cytaty poniżej dostarczają wszystkich danych potrzebnych do ćwiczenia.

Nawigacja: Start | Kontakt | Następna strona.

Treść główna — sekcja „Błąd połączenia”:

Gdy aplikacja zgłasza brak połączenia, sprawdź stan usługi i adres w konfiguracji. Jeżeli usługa działa, zapisz dokładny komunikat i przekaż go administratorowi. Nie zmieniaj uprawnień plików bez ustalenia przyczyny.

Treść główna — sekcja „Kontrola znaków”:

Tekst kontrolny: Zażółć gęślą jaźń. Zachowaj nazwy docassist-api i --no-pager oraz jednostki: 25°C, ±5%, ≤10 ms.

Stopka: Stopka techniczna strony. Skrypt: const menu='Nawigacja';

Dobry odczyt zachowuje oba nagłówki i oba akapity treści głównej. Menu, stopka techniczna i kod skryptu są w tym przykładzie elementami otoczenia strony. Usunięcie tagów przez proste sklejenie tekstu bez separatorów mogłoby połączyć koniec nagłówka z początkiem zdania. Po odczycie sprawdzamy zatem także granice tekstu.

4. Przykład PDF: wynik wymaga porównania

W dwustronicowym docassist.pdf strona 1 opisuje wymagania stanowiska: minimum 8 GB RAM i 2 GB wolnego miejsca. Strona 2 omawia diagnostykę, w tym timeout_seconds o wartości 30 s. To parametry fikcyjnej aplikacji, nie zalecenia sprzętowe dla lokalnego modelu językowego ani gwarantowany czas obsługi zgłoszenia.

Na stronach występuje powtarzany nagłówek „Dokumentacja techniczna DocAssist | materiał ćwiczeniowy” i stopka „Strona 1 z 2” lub „Strona 2 z 2”. W tekście strony 1 występuje również podział konfigu- na końcu wiersza i racji na początku następnego. Odczyt może poprawnie zachować wszystkie te znaki, mimo że później część z nich trzeba będzie świadomie oczyścić.

Rozpoznaj etap błędu. Jeżeli odczyt nie zawiera zdania widocznego w oryginale, najpierw napraw ekstrakcję. Jeżeli je zawiera, ale razem ze stopką, rozważ regułę czyszczenia. Czyszczenie nie odzyska treści, której nigdy nie odczytano.

5. Ćwiczenie 2 — oceń odczyt

Dla sekcji „Błąd połączenia” porównaj dwa wyniki z oryginałem przytoczonym wyżej:

Wynik A: „Start | Kontakt | Następna strona. Gdy aplikacja zgłasza brak połączenia, sprawdź stan usługi i adres w konfiguracji. Jeżeli usługa działa, zapisz dokładny komunikat i przekaż go administratorowi. Nie zmieniaj uprawnień plików bez ustalenia przyczyny. Stopka techniczna strony”.

Wynik B: „Gdy aplikacja zgłasza brak połączenia, sprawdź stan usługi i adres w konfiguracji. Jeżeli usługa działa, zmień uprawnienia plików”.

  1. Wskaż szum w A. Czy zasadnicza treść sekcji została zachowana?
  2. Opisz zmianę znaczenia i brakującą treść w B. Czy samo usunięcie szumu naprawi ten wynik?
  3. Zapisz oczekiwany zestaw lokalizatorów dla odczytu czterech aktywnych plików, gdy PDF dzielimy na strony. Ile rekordów powstanie?
  4. Co należy zrobić, gdy skan PDF daje pusty tekst? Czy można go od razu oznaczyć jako poprawnie przetworzony?
  5. Wybierz cztery ciągi z sekcji „Kontrola znaków”, które wykorzystasz do sprawdzenia odczytu znaków i jednostek.

Wynik: krótka ocena dwóch odczytów oraz plan kontroli formatów i lokalizatorów.

Sprawdź rozumienie

Dlaczego brak wyjątku programu nie wystarcza do uznania odczytu za poprawny? Czy stronę 2 PDF można zastąpić drugim akapitem TXT? Co zyskujesz, zachowując tekst surowy przed czyszczeniem?

Przejście do praktyki: R2 tworzy documents_extracted.json i kontrola_odczytu.json. Wątpliwości o utraconej treści rozstrzygnij przed R3.

Przygotowanie dokumentów i bazy wiedzy
ENHANCER+ · Politechnika Warszawska · materiał do samodzielnej nauki offline

4. Czyszczenie i normalizacja tekstu

Czyszczenie ma usunąć zakłócenia powstałe przy zapisie lub odczycie, a nie przeredagować dokument według domysłów. Najgroźniejszy wynik to tekst, który wygląda czytelniej, lecz znaczy coś innego. Dlatego każda reguła powinna mieć określony cel, zakres i sposób kontroli.

1. Co normalizujemy

Można ujednolicić kodowanie znaków, końce wierszy i wybrane odstępy. Normalizacja Unicode NFC sprowadza równoważne zapisy niektórych znaków do wspólnej reprezentacji; nie tłumaczy tekstu, nie usuwa polskich liter ani nie rozpoznaje sensu zdań. Zamiana twardej spacji na zwykłą może ułatwić przeszukiwanie. Usunięcie niewidocznego miękkiego łącznika może zlikwidować ślad łamania wyrazu.

To inne operacje niż usuwanie zwykłego znaku -. Łącznik w nazwie docassist-api, dwa łączniki w opcji --no-pager oraz łącznik na końcu podzielonego słowa mają różne funkcje. Reguła „usuń wszystkie myślniki” zniszczy poprawne nazwy i komendy.

Podobnie nie wolno automatycznie usuwać wszystkich cyfr, znaków interpunkcyjnych ani słów typu „nie”. W tym module wartości 8 GB, 2 GB i 30 s są wiedzą. Negacja w „Nie zmieniaj uprawnień…” jest warunkiem poprawnego działania, a nie zbędnym słowem.

2. Oddziel szum od istotnej struktury

Powtarzany nagłówek PDF i stopka strony mogą być szumem, jeżeli ich funkcję rozpoznano na oryginale. Nagłówek sekcji „Dyżur operatora” pomaga natomiast zinterpretować treść i powinien pozostać. Wcięcia i nowe wiersze mogą wyznaczać listę kroków lub kod. Globalne sklejenie wszystkich wierszy spłaszczyłoby tę strukturę.

Zamiast jednej agresywnej operacji wybierz serię małych zmian. Zapisz dla każdej: co zamieniono, w których rekordach, dlaczego i jak porównano wynik z wejściem. Gdy reguła działa dla konkretnej stopki, nie rozszerzaj jej bez kontroli na wszystkie linie zawierające słowo „strona”.

Operacja Rozsądny zakres Ryzyko wymagające kontroli
Ujednolicenie końców wierszy Techniczne różnice zapisu Zlanie akapitów lub kodu
Zamiana twardej spacji Zachowanie odstępu między wyrazami Utrata czytelności przy usunięciu zamiast zamiany
Usunięcie rozpoznanej stopki PDF Dokładnie zidentyfikowany wzorzec Usunięcie zdania o numerze strony
Połączenie dzielonego wyrazu Potwierdzone łamanie wiersza Zmiana poprawnej nazwy lub komendy
Ograniczenie pustych wierszy Nadmiarowe odstępy Utrata granic sekcji lub list

3. Przykład „przed” i „po”

Poniższy mały przykład dydaktyczny łączy typowe elementy z korpusu. Ciąg konfigu- jest urwany na końcu wiersza. Dwie komendy muszą pozostać w kolejności. To tekst do analizy, nie polecenie do wykonania na komputerze.

Przed czyszczeniem:

Dokumentacja techniczna DocAssist | materiał ćwiczeniowy
Po zmianie konfigu-
racji wykonaj kolejno:
1. sudo systemctl restart docassist-api
2. systemctl is-active docassist-api
Prawidłowy wynik: active.
Nie wykonuj restartu bez zmiany konfiguracji.
Strona 1 z 2

Po kontrolowanym czyszczeniu:

Po zmianie konfiguracji wykonaj kolejno:
1. sudo systemctl restart docassist-api
2. systemctl is-active docassist-api
Prawidłowy wynik: active.
Nie wykonuj restartu bez zmiany konfiguracji.

Usunięto wyłącznie znany nagłówek i stopkę oraz połączono potwierdzony wyraz „konfiguracji”. Zachowano warunek, negację, kolejność kroków, nazwy usługi i oczekiwany wynik. Numer strony znika z tekstu przeznaczonego do wyszukiwania, ale pozostaje w metadanych. Źródło i tekst surowy są nadal dostępne.

4. Jak udowodnić, że czyszczenie pomogło

Porównaj pary raw_text i clean_text dla tych samych rekordów. Sprawdź przykłady z każdego formatu oraz wszystkie nietypowe zmiany. Sam spadek liczby znaków nie mierzy jakości: wynik może być krótszy, bo usunięto instrukcję razem ze stopką.

Przy przeglądzie szukaj zachowania: liczb z jednostkami, nazw, negacji, warunków, wyjątków, kolejności kroków i nagłówków. Rejestr zmian pozwala cofnąć się do przyczyny. Jeżeli musisz wyjaśnić podział wyrazu lub treść po OCR, sprawdź oryginał i zanotuj interwencję; nie ukrywaj jej pod ogólną nazwą „normalizacja”.

Ważne. Nieznanej treści nie dopisujemy. Fragment „Gwarantowany czas: …” nie staje się „30 s” dlatego, że taka wartość występuje w innym miejscu jako parametr diagnostyczny.

5. Ćwiczenie 3 — wybierz bezpieczne reguły

Dla przykładu „przed czyszczeniem” rozważ pięć propozycji:

  • A: usuń każdą linię zawierającą cyfrę;
  • B: usuń dokładnie rozpoznany nagłówek i stopkę, zachowując stronę w metadanych;
  • C: połącz potwierdzone konfigu- + koniec wiersza + racji w „konfiguracji”;
  • D: usuń wszystkie łączniki i wszystkie wystąpienia słowa „Nie”;
  • E: zachowaj osobne kroki oraz polskie znaki, liczby, jednostki i nazwy.

  • Zaznacz reguły dopuszczalne i odrzucone. Dla każdej odrzuconej wskaż konkretną szkodę.

  • Zapisz własny wynik czyszczenia. Porównaj go z przykładem „po”, zwracając uwagę na znaczenie, nie tylko wygląd.
  • Sporządź trzy wpisy do rejestru: operacja, powód, kontrola wyniku.
  • Wypisz pięć elementów znaczenia, które muszą przetrwać. Uwzględnij także co najmniej jedną liczbę z jednostką z R2.

Wynik: decyzje o regułach, tekst po zmianie i krótki rejestr operacji.

Sprawdź rozumienie

Czym różni się usunięcie stopki z tekstu od utraty numeru strony w metadanych? Dlaczego docassistapi nie jest poprawnym zamiennikiem docassist-api? Kiedy należy wrócić do oryginału zamiast dopisać brakujący tekst?

Przejście do praktyki: R3 zapisuje documents_cleaned.json i ocena_czyszczenia.json. W zadaniu komputerowym obowiązuje ręczne sprawdzenie minimum trzech rekordów; dla tak małego korpusu warto przejrzeć wszystkie pięć.

Przygotowanie dokumentów i bazy wiedzy
ENHANCER+ · Politechnika Warszawska · materiał do samodzielnej nauki offline

5. Podział dokumentów na fragmenty

Fragment jest jednostką, którą przyszły system może odnaleźć i przekazać jako kontekst. Powinien być wystarczająco mały, aby dotyczył konkretnego tematu, oraz wystarczająco pełny, aby zachować warunki i wyjątki. Granica fragmentu jest decyzją o znaczeniu, nie tylko o liczbie znaków.

1. Dlaczego nie cały plik i nie każde zdanie

Bardzo duży fragment może łączyć restart, dyżur i diagnostykę, przez co zawiera dużo treści niepotrzebnej do danego pytania. Bardzo mały może obejmować samo „Prawidłowy wynik: active”, bez informacji, jaki test ma go dać. W obu sytuacjach tekst jest autentyczny, ale ma ograniczoną użyteczność jako samodzielny kontekst.

Przy ocenie granicy zapytaj: o czym jest ten fragment, czy wiadomo, kiedy instrukcja ma zastosowanie, czy zachowano kolejność kroków i czy wyjątek nie został oddzielony od reguły. Nagłówek sekcji często pomaga, ale nie naprawia brakującego warunku.

2. Trzy strategie do porównania

Podział według znaków działa również wtedy, gdy dokument nie ma wyraźnej struktury. Może jednak przeciąć wyraz, zdanie lub procedurę. Parametr określa liczbę znaków, a nie tokenów modelu. Nie należy traktować tych jednostek jako równoważnych.

Podział według akapitów respektuje granice typograficzne. Jest użyteczny, gdy akapit odpowiada jednej myśli, ale nie wtedy, gdy wynik odczytu sztucznie utworzył nowy akapit po każdym wierszu. Rozmiary fragmentów mogą być bardzo nierówne.

Podział według sekcji korzysta z nagłówków i zwykle lepiej zachowuje temat. Długa sekcja nadal wymaga podziału, a krótkie wprowadzenie z samym tytułem, autorem i wersją może nie dostarczać samodzielnej wiedzy. Taki fragment należy ocenić, nie przyjmować automatycznie.

Strategia Mocna strona Typowy punkt kontroli
Znaki Przewidywalny limit długości Przecięte zdanie, warunek lub komenda
Akapity Naturalne granice części tekstu Nierówna długość, sztuczne akapity
Sekcje Wspólny temat i nagłówek Zbyt długa sekcja lub pusty wstęp

3. Nakładanie fragmentów ma konkretny cel

Overlap, czyli nakładanie, powtarza końcowy odcinek jednego fragmentu na początku następnego. Może pomóc zachować ciągłość, ale nie gwarantuje przeniesienia całego warunku lub wyjątku. Powtarzany tekst zwiększa też objętość zbioru i może powodować podobne wyniki wyszukiwania.

W wariancie znakowym o rozmiarze 420 znaków i overlapie 60 kolejne pełne okno zaczyna się zwykle 360 znaków po poprzednim. To przykład ustawienia do porównania, a nie zalecenie dla każdego dokumentu. Wymagamy 0 ≤ overlap < chunk_size. Przy strategii sekcyjnej o rozmiarze 900 i overlapie 150 nakładanie dotyczy podziału zbyt długich części zgodnie z zastosowanym algorytmem; nie oznacza automatycznego łączenia sąsiednich stron PDF.

Nie zmieniaj jednocześnie wszystkich parametrów, jeśli chcesz zrozumieć skutek. Porównaj kilka fragmentów odpowiadających na te same pytania. Zapisz zarówno liczbę i długości fragmentów, jak i przykłady granic dobrych oraz błędnych.

4. Źródło do ćwiczenia: dyżur operatora

Oto pełna treść sekcji „Dyżur operatora” z aktualnego regulamin.md 1.4:

Operator przyjmuje zgłoszenia w dni robocze od 08:00 do 16:00. Poza tymi godzinami zgłoszenie czeka do następnego dyżuru. Wyjątek: awarię uniemożliwiającą pracę całego zespołu zgłoś dyżurnemu administratorowi zgodnie z wewnętrzną procedurą eskalacji.

Rozważ dwa podziały tego samego tekstu:

Wariant A, fragment 1: „Operator przyjmuje zgłoszenia w dni robocze od 08:00 do 16:00. Poza tymi godzinami zgłoszenie czeka do następnego dyżuru”.

Wariant A, fragment 2: „Wyjątek: awarię uniemożliwiającą pracę całego zespołu zgłoś dyżurnemu administratorowi zgodnie z wewnętrzną procedurą eskalacji”.

Wariant B: jeden fragment obejmujący nagłówek „Dyżur operatora” i cały przytoczony akapit.

Wariant A może doprowadzić do odnalezienia samej reguły, bez wyjątku. Wariant B zachowuje krótką, spójną jednostkę tematyczną. Nadal nie zawiera szczegółowej procedury eskalacji, której tekst źródłowy nie przytacza. Nie wolno ich dopowiadać.

5. Ćwiczenie 4 — zaproponuj granice

  1. Wybierz wariant A lub B dla pytania: „Cały zespół nie może pracować po 16:00. Co wynika z regulaminu?”. Uzasadnij wybór.
  2. Wyjaśnij, dlaczego samo dodanie 20 znaków overlapu do wariantu A nie dowodzi zachowania całego wyjątku.
  3. W R3 znajdź procedurę restartu. Wskaż, jakie elementy powinny trafić do jednego fragmentu lub do kontekstu, który przyszły system odtworzy razem. Czy samo active wystarcza?
  4. Zaproponuj strategię początkową dla krótkiego regulaminu z nagłówkami oraz dla tekstu bez nagłówków. Wymień po jednym ryzyku do ręcznej kontroli.
  5. Zapisz dwa kryteria jakości niezwiązane z liczbą fragmentów. Wyjaśnij różnicę między 420 znakami a 420 tokenami.

Wynik: wybrane granice, uzasadnienie strategii i kryteria porównania. Nie musisz ręcznie liczyć znaków.

Sprawdź rozumienie

Czy mała liczba fragmentów dowodzi dobrej jakości? Dlaczego nakładanie może pomóc i jednocześnie zwiększać powtórzenia? Co zrobisz, jeżeli procedura przechodzi na drugą stronę PDF, a program dzieli każdą stronę oddzielnie?

W ostatniej sytuacji trzeba rozpoznać brak kontekstu i zaprojektować jego zachowanie: np. zmienić etap przygotowania lub sposób łączenia treści w przyszłym systemie. Nie wystarczy oznaczyć niepełnego fragmentu jako dobry. Kod ćwiczeniowy M2 nie łączy stron PDF automatycznie.

Przejście do praktyki: R4 zapisuje chunks.json, strategia.json i porownanie_strategii.json. Parametry są udokumentowaną decyzją uczestnika, nie uniwersalną receptą.

Przygotowanie dokumentów i bazy wiedzy
ENHANCER+ · Politechnika Warszawska · materiał do samodzielnej nauki offline

6. Metadane i identyfikacja źródeł

Metadane opisują pochodzenie i stan fragmentu. Dzięki nim można odszukać źródło, rozróżnić wersje, sprawdzić lokalizację oraz wyjaśnić decyzję o dopuszczeniu. Poprawny tekst bez metadanych utrudnia weryfikację, a kompletne metadane nie zamieniają błędnego tekstu w wiarygodną wiedzę.

1. Cztery pola rekordu końcowego

W materiałach M2 rekord końcowy ma pola vector_index, chunk_id, text i metadata. Nazwa vector_index przygotowuje spójny format na kolejne etapy kursu; w Module 2 nie oznacza jeszcze utworzonego wektora. To liczba porządkowa w zapisanym zbiorze.

Pole Znaczenie Czego z nim nie mylić
vector_index Kolejność w danym zbiorze, od 0 Trwały identyfikator źródła
chunk_id Jednoznaczny identyfikator fragmentu Pozycja po filtrowaniu
text Treść fragmentu do dalszej pracy Surowy dokument lub opis oceny
metadata Pochodzenie, lokalizacja, parametry i ocena Automatyczna gwarancja poprawności

document_id identyfikuje dokument w przyjętym rejestrze, a record_id rekord powstały przy odczycie, np. stronę PDF. chunk_index opisuje lokalną kolejność fragmentów według zastosowanego procesu. Dokładny sposób nadawania identyfikatorów trzeba stosować konsekwentnie i zapisywać. W naszym przykładzie aktualny i archiwalny regulamin mają różne identyfikatory dokumentu; nie łączymy ich po samym tytule.

2. Co opisuje dokument, a co fragment

Metadane dokumentu obejmują m.in. nazwę pliku (source), tytuł, typ, wersję, status i ścieżkę. Metadane fragmentu wskazują sekcję, stronę, zakres znaków i parametry podziału. Później dochodzi ocena jakości qa_status.

Wersja 1.4 oznacza tu wersję dokumentu, nie wersję modelu językowego. status: active mówi o obowiązywaniu dokumentu, a qa_status: accepted o przyjęciu konkretnego fragmentu po kontroli. Dokument aktywny może dać fragment odrzucony, np. złożony wyłącznie ze stopki. Oba pola odpowiadają na różne pytania.

3. Strony i zakresy znaków bez zgadywania

Dla PDF w naszym zestawie page_start i page_end są rzeczywistymi numerami stron. Jeżeli fragment pochodzi z jednej strony, oba mają tę samą wartość. Pole page_number pozostaje zgodne z page_start. Dla TXT, MD i HTML wszystkie te pola mają wartość null. Wersja drukowana strony internetowej nie uprawnia do przypisywania jej numeracji oryginalnemu HTML.

start_char i end_char odnoszą się do tekstu oczyszczonego danego rekordu, a nie do bajtów pliku PDF. Stosujemy przedział od początku włącznie do końca wyłącznie. Przykładowo tekst „Dyżur” ma pięć znaków, więc zajmuje zakres [0, 5) w rekordzie zawierającym tylko to słowo. Po zmianie czyszczenia stare zakresy mogą przestać wskazywać właściwą treść i trzeba je wyznaczyć ponownie.

Nieznane daty pozostają null. To poprawna, jawna informacja o braku danych, a nie zachęta do wpisania daty dzisiejszej. W Pythonie odpowiednikiem null jest None. Tekst "null" w cudzysłowie jest zwykłym napisem i nie oznacza braku wartości.

4. Przykład schematu

Poniższy skrócony rekord służy objaśnieniu pól. Pokazuje pięcioznakowy tekst „Dyżur”, więc sam nie jest dobrym fragmentem wiedzy i ma ocenę review. To przykład dydaktyczny, nie rekord skopiowany z gotowej bazy.

{
  "vector_index": 0,
  "chunk_id": "PRZYKLAD-REG-001",
  "text": "Dyżur",
  "metadata": {
    "document_id": "DOC-REG",
    "record_id": "PRZYKLAD-REG-REKORD",
    "source": "regulamin.md",
    "title": "Regulamin wsparcia DocAssist",
    "document_type": "regulamin",
    "version": "1.4",
    "status": "active",
    "updated_at": null,
    "valid_from": null,
    "valid_to": null,
    "access_level": "internal",
    "path": "dane/zrodla/regulamin.md",
    "section": "Dyżur operatora",
    "page_number": null,
    "page_start": null,
    "page_end": null,
    "chunk_index": 0,
    "start_char": 0,
    "end_char": 5,
    "chunking_strategy": "sections",
    "chunk_size": 900,
    "overlap": 150,
    "qa_status": "review"
  }
}

W zapisie końcowym używamy section. Jeżeli etap pośredni nazwał nagłówek section_title, należy go świadomie odwzorować do wspólnego schematu. Pozostawienie dwóch różnie wypełnionych pól rodzi niejasność, z którego powinny korzystać następne narzędzia.

5. Identyfikatory podczas filtrowania

Załóżmy, że zbiór zawiera fragmenty A, B i C o indeksach 0, 1 i 2. Fragment B zostaje odrzucony. W pliku dopuszczonym do dalszej pracy A ma indeks 0, a C indeks 1. Identyfikatory chunk_id A i C pozostają bez zmian. Dzięki temu raport oceny nadal wskazuje ten sam fragment, mimo zmiany jego miejsca w zbiorze.

To zasada dla filtrowania istniejących fragmentów. Po ponownym czyszczeniu lub podziale należy na nowo ustalić powiązania i przeprowadzić kontrolę; nie zakładaj, że stare identyfikatory, zakresy i oceny pasują do zmienionego tekstu.

6. Ćwiczenie 5 — napraw metadane

Rozważ celowo błędny opis: fragment pochodzi z regulamin.md 1.4, ale ma source: docassist.pdf, page_number: 7, page_start: null, version: 1.3, updated_at: dzisiaj i status: accepted. Tytuł sekcji zapisano tylko w section_title. Nie znamy daty aktualizacji.

  1. Popraw każde z tych pól. Nie wymyślaj danych, których nie podano.
  2. Wyjaśnij, gdzie powinna trafić ocena jakości i dlaczego nie można nadać jej wyłącznie na podstawie nazwy źródła.
  3. W zbiorze D, E, F indeksy wynoszą 0, 1, 2. Po odrzuceniu D wypisz identyfikatory i indeksy E oraz F w zbiorze gotowym.
  4. Wyjaśnij, co oznacza access_level: internal i czego samo to pole nie zapewnia.

Wynik: lista poprawek z uzasadnieniem i poprawna kolejność po filtrowaniu.

Sprawdź rozumienie

Czy active i accepted mogą opisywać różne aspekty tego samego rekordu? Co pozwala odnaleźć stronę źródła, a co pozycję w tekście oczyszczonym? Dlaczego wartość null bywa bardziej wiarygodna niż pozornie kompletna data?

Przejście do praktyki: R5 zapisuje fragments_with_metadata.json i kontrola_metadanych.json. R6 wykorzysta je do walidacji i ręcznej oceny.

Przygotowanie dokumentów i bazy wiedzy
ENHANCER+ · Politechnika Warszawska · materiał do samodzielnej nauki offline

7. Organizacja i kontrola jakości bazy wiedzy

Kontrola jakości zamyka proces przygotowania danych i dostarcza podstaw do decyzji o dalszej pracy. Łączy sprawdzenie struktury plików, przegląd znaczenia fragmentów oraz ocenę pokrycia pytań. Żaden z tych elementów samodzielnie nie wystarcza.

1. Zachowaj etapy i możliwość powrotu

Oddziel źródła od wyników. Tekst surowy, tekst oczyszczony, fragmenty i oceny powinny mieć własne pliki. W pakiecie komputerowym wyniki trafiają do Student/wyniki/<RUN_ID>/R1 aż do R6. Ten sam identyfikator przebiegu łączy kolejne etapy. Nowy RUN_ID oznacza nowy przebieg i wymaga przygotowania poprzednich wyników; nie służy do dowolnego przeskakiwania do końca.

JSON zapisuje cały obiekt lub listę w jednym dokumencie. JSONL zapisuje po jednym kompletnym obiekcie JSON w każdym wierszu. W pliku JSONL nie dodajemy zewnętrznych nawiasów listy ani przecinków między rekordami. Dzięki temu następny etap może czytać rekordy kolejno. Oba formaty nadal wymagają poprawnych pól i wartości.

Końcowe pliki pełnią różne role:

Plik Co zawiera Po co go zachować
knowledge_base_all.jsonl Wszystkie ocenione fragmenty Ślad decyzji, także odrzuceń
knowledge_base_ready.jsonl Wyłącznie fragmenty accepted Wejście do kolejnego etapu
qa_report.json Wyniki kontroli i decyzje Możliwość sprawdzenia szczegółów
qa_summary.md Uzasadnienie i ograniczenia Czytelne przekazanie wyniku człowiekowi

2. Trzy warstwy kontroli

Kontrola techniczna sprawdza m.in. poprawny zapis, wymagane pola, unikalne identyfikatory, niepusty tekst, dozwolone wartości, logiczne zakresy znaków i stron oraz zgodność źródeł z inwentarzem. Dwustronicowy PDF nie może być źródłem strony 7. Po filtrowaniu indeksy w gotowym zbiorze powinny tworzyć ciąg od 0 bez luk.

Kontrola treści porównuje fragment z oryginałem. Sprawdza, czy zachował warunki, wyjątki, liczby, jednostki i kolejność. Wykrywa również fragmenty z samym tytułem, stopką lub urwanym wynikiem testu. Takie teksty mogą być poprawnym JSON-em i jednocześnie nie być użyteczną wiedzą.

Kontrola zakresu zestawia pytania P1–P5 z dopuszczonymi fragmentami. Dla każdego pytania zapisuje pełne pokrycie, częściowe pokrycie albo brak potrzebnej informacji oraz wskazuje dowody. Nie jest to jeszcze test wyszukiwania: ręczne znalezienie odpowiedzi w bazie nie dowodzi, że przyszły retriever wybierze właściwy fragment.

3. Decyzje o fragmentach

accepted oznacza, że fragment został sprawdzony i dopuszczony. review oznacza nierozstrzygniętą wątpliwość wymagającą działania. rejected oznacza świadome wyłączenie z gotowego zbioru wraz z powodem. Oceny nie należy nadawać wyłącznie na podstawie długości tekstu lub aktywnego statusu dokumentu.

W małym korpusie przejrzyj wszystkie fragmenty. Dla większego można zaplanować próbkę, np. co najmniej większą z liczb: 10 lub 5% zbioru zaokrąglone w górę, nie więcej niż cały zbiór. Do tego trzeba objąć kontrolą wszystkie ostrzeżenia, reprezentację formatów, granice procedur, wyjątki i inne miejsca podwyższonego ryzyka. Taka reguła organizuje przegląd, lecz nie dowodzi statystycznie bezbłędności całej bazy.

4. Co oznacza GO do kolejnego modułu

W notebookach M2 techniczny warunek GO wymaga rozstrzygnięcia ocen, braku fragmentów oczekujących na przegląd i co najmniej jednego fragmentu dopuszczonego. Błędy blokujące nie mogą pozostawać w fragmentach przyjętych. To jednak nie potwierdza pełnego pokrycia potrzeb użytkownika, jakości przyszłego wyszukiwania ani poprawności odpowiedzi modelu.

Ostateczne przekazanie powinno zawierać cel eksperymentu, zakres, liczbę przyjętych i odrzuconych fragmentów oraz znane braki. Jeśli brak dotyczy obowiązkowej funkcji, wróć do źródeł. Jeżeli jest świadomą granicą zakresu, opisz ją w raporcie. Nie zmieniaj oceny tylko po to, aby uzyskać napis GO.

W przykładowym rozwiązaniu komputerowym do tego pakietu cztery aktywne dokumenty dają pięć rekordów odczytu i piętnaście fragmentów. Dziesięć przyjęto, pięć wstępnych fragmentów bez samodzielnej wiedzy odrzucono. P1–P4 mają pokrycie, a dla P5 brak wartości gwarantowanego czasu. Regulamin mówi wprost, że takiego czasu nie podaje. Liczby opisują konkretny przebieg i parametry; nie są oczekiwanym wynikiem każdego poprawnego podziału.

Ważne. Wartość timeout_seconds = 30 s opisuje parametr diagnostyczny. Nie jest odpowiedzią na pytanie o gwarantowany czas rozwiązania zgłoszenia. Dopasowanie samego słowa „czas” nie daje jeszcze właściwej podstawy odpowiedzi.

5. Ćwiczenie 6 — przeprowadź audyt

Poniższy miniaturowy zbiór został przygotowany wyłącznie do ćwiczenia offline; nie jest kopią wyników notebooka. Zakładamy unikalne identyfikatory A–E i poprawny format pól poza jawnie wskazanymi problemami. Indeksy początkowe to kolejno 0–4.

ID Treść lub opis fragmentu Pochodzenie i problem
A Cała sekcja „Dyżur operatora” z R4, wraz z wyjątkiem regulamin.md 1.4, active, strony null; treść sprawdzona
B Dyżur 09:00–15:00 regulamin_v1_3.md 1.3, archived; poza bieżącym zakresem
C „Prawidłowy wynik: active.” instrukcja.txt 1.4; brak opisu testu i warunku
D Minimum 8 GB RAM i 2 GB wolnego miejsca docassist.pdf 1.4; wszystkie pola strony błędnie mają wartość 7
E Pusty tekst pomoc.html 1.4; ekstrakcja fragmentu nie dostarczyła treści

Do naprawy C dysponujesz następującą pełną sekcją z instrukcja.txt 1.4:

Ponowne uruchomienie usługi
Po zmianie pliku /etc/docassist/config.yaml wykonaj kolejno:
1. Uruchom ponownie usługę: sudo systemctl restart docassist-api
2. Sprawdź stan: systemctl is-active docassist-api
Prawidłowy wynik: active.
Uwaga: wykonaj ponowne uruchomienie tylko po zmianie konfiguracji.

Dla D wiesz z R2, że wymagania znajdują się na stronie 1 dwustronicowego PDF. Dla E masz w R2 pełną treść pomocy, ale założeniem pierwszego przeglądu jest odrzucenie pustego fragmentu; poprawę ekstrakcji zapiszesz jako oddzielne działanie.

  1. Nadaj A–E ocenę accepted, review lub rejected i podaj powód. Nie akceptuj fragmentu wymagającego naprawy.
  2. Zdecyduj, czy w tej chwili można ogłosić GO. Wymień działania potrzebne przy C i D.
  3. Załóż, że wrócono do wcześniejszych etapów, poprawiono C oraz D, przeliczono potrzebne zakresy i ponownie je sprawdzono. A, C i D są przyjęte, B i E odrzucone. Nadaj indeksom przyjętego zbioru kolejne wartości. W tym ćwiczeniu zachowaj etykiety A, C i D; w rzeczywistym przebiegu identyfikatory po ponownej fragmentacji nadaje proces.
  4. Oceń pokrycie P1–P5. Który brak wymaga uzupełnienia dla wcześniej zdefiniowanego zakresu, a którego nie wolno uzupełnić domysłem?
  5. Napisz trzyzdaniowe podsumowanie dla osoby rozpoczynającej M3: stan techniczny, brak merytoryczny i następne działanie.

Wynik: pięć ocen, plan naprawy, indeksy zbioru gotowego i raport ograniczeń.

Sprawdź rozumienie

Czy fragment odrzucony musi zniknąć także z raportu? Czym różni się brak danych w źródle od utraty treści przy przetwarzaniu? Co należy ponowić po wymianie regulaminu na nową wersję?

Po zmianie źródeł ponownie oceń zakres i wykonaj zależne etapy odczytu, czyszczenia, podziału, metadanych i kontroli. W kolejnych modułach będzie trzeba także odświeżyć powiązane embeddingi oraz indeks; stare wyniki nie stają się aktualne automatycznie.

Przygotowanie dokumentów i bazy wiedzy
ENHANCER+ · Politechnika Warszawska · materiał do samodzielnej nauki offline

8. Podsumowanie Modułu 2

Rezultatem modułu jest uporządkowana, sprawdzona baza tekstowa z możliwym do odtworzenia pochodzeniem. Do dalszej pracy przekazujesz fragmenty dopuszczone wraz z opisem ograniczeń. Sama obecność pliku JSONL nie świadczy jeszcze o jakości danych.

Mapa całego procesu

Źródła → odczyt → czyszczenie → fragmenty → metadane → ocena → zbiór gotowy.

W praktyce proces zawiera powroty. Niewłaściwa strona w metadanych kieruje do odczytu, urwany warunek do podziału, a sprzeczne godziny dyżuru do doboru wersji źródeł. Naprawiaj przyczynę we właściwym etapie, aby błąd nie wrócił przy następnym uruchomieniu.

Etap Pytanie kontrolne Główny wynik ćwiczenia komputerowego
R1 Czy źródła odpowiadają celowi i są dopuszczone? inwentarz_zrodel.json, zakres_bazy.md
R2 Czy odczyt odpowiada oryginałowi? documents_extracted.json
R3 Czy zachowano znaczenie? documents_cleaned.json
R4 Czy fragment ma potrzebny kontekst? chunks.json, strategia.json
R5 Czy można wskazać pochodzenie? fragments_with_metadata.json
R6 Czy oceny są rozstrzygnięte i braki opisane? knowledge_base_ready.jsonl, qa_report.json

Lista kontrolna przed przekazaniem do M3

  1. Zakres i pytania są zapisane, a wersje źródeł świadomie wybrane.
  2. Oryginały pozostają dostępne; tekst surowy i oczyszczony można porównać.
  3. Odczyt sprawdzono dla wszystkich użytych formatów, w tym stron PDF.
  4. Czyszczenie zachowało nazwy, liczby, jednostki, negacje, warunki i kolejność.
  5. Granice fragmentów nie ukrywają wyjątków ani nie rozbijają niezbędnego kontekstu.
  6. Identyfikatory są jednoznaczne, metadane zgodne, a brakujące daty i strony nie zostały wymyślone.
  7. W gotowym zbiorze są wyłącznie accepted; indeksy zaczynają się od 0 bez luk.
  8. Raport zachowuje również odrzucenia i ich powody.
  9. Pokrycie pytań sprawdzono ręcznie i opisano braki, w tym P5.
  10. Decyzja GO lub NO-GO ma uzasadnienie odnoszące się do celu następnego eksperymentu.

Gdy pracujesz również w notebookach

Rozpakuj pakiet Student i zacznij od START.md oraz testu środowiska. Następnie wykonuj R1–R6 w kolejności, z tym samym RUN_ID. Domyślny identyfikator przykładowego przebiegu to projekt_01. Ochrona NADPISZ = False ogranicza przypadkowe nadpisanie wyników. Nie usuwaj jej bez sprawdzenia, jakie pliki mają zostać zastąpione.

Pola oznaczone „UZUPEŁNIJ” wymagają własnej analizy, nawet jeśli kod wykonał się poprawnie. Przykładowy punkt wznowienia prowadzącego może służyć do demonstracji lub naprawy przebiegu, ale trzeba jawnie oznaczyć jego pochodzenie. Rozwiązania i odpowiedzi do ćwiczeń są materiałami dydaktycznymi, a nie źródłami wiedzy DocAssist do włączenia do korpusu.

Co zabierasz do kolejnego modułu

Masz przygotowany tekst, pochodzenie i ocenę. W dalszej pracy można zbadać tworzenie reprezentacji wektorowych, wyszukiwanie i odpowiedzi oparte na znalezionych fragmentach. Dopiero te eksperymenty pokażą, jak wybór rozmiaru fragmentów wpływa na konkretne wyszukiwanie. Nie przenoś na przyszły system gwarancji, których nie sprawdzono w M2.

Podstawa treści i materiały uzupełniające

Książkę opracowano na podstawie prezentacji kursowej M12-M2-v4.pptx, plików z pakietu M2 oraz układu podręcznika Modułu 1. Zakresy slajdów v4: R1 8–24, R2 27–45, R3 48–68, R4 71–95, R5 98–116, R6 119–141. Przykłady oznaczone jako dydaktyczne upraszczają zadanie i nie udają rzeczywistych wyników uruchomienia.

Do wykonania ćwiczeń w książce wystarcza jej treść. Dla osób rozszerzających pracę dostępna jest dokumentacja autorów narzędzi: odczyt tekstu z PDF w pypdf oraz przetwarzanie HTML w Beautiful Soup. Odsyłacze wymagają internetu, lecz nie są wymaganymi krokami tej lektury.

Samoocena po lekturze

Spróbuj bez zaglądania do rozdziałów wyjaśnić komuś, dlaczego 08:00–16:00 i 09:00–15:00 nie mogą być równorzędnymi odpowiedziami bieżącego asystenta, dlaczego sam napis active jest słabym fragmentem oraz dlaczego wartość 30 s nie odpowiada na P5. Jeżeli umiesz wskazać źródło problemu i etap naprawy, rozumiesz główne zależności w module.

Przygotowanie dokumentów i bazy wiedzy
ENHANCER+ · Politechnika Warszawska · materiał do samodzielnej nauki offline

9. Odpowiedzi do ćwiczeń

Porównuj przede wszystkim uzasadnienia. Część decyzji projektowych ma kilka poprawnych wariantów, ale żaden nie może opierać się na wymyślonej treści, pominiętej negacji lub nieprawdziwym źródle. Poniższe odpowiedzi dotyczą ćwiczeń offline z tej książki.

Ćwiczenie 1 — zakres i źródła

Przykładowy zakres: „Baza wspiera pracowników w interpretowaniu aktualnych instrukcji i zasad wsparcia DocAssist. Obejmuje dokumenty 1.4, nie obsługuje historii zmian i nie ustala nieudokumentowanych terminów rozwiązania zgłoszeń”. Można dodać, że asystent nie wykonuje poleceń administracyjnych.

Do bieżącego korpusu przyjmujemy instrukcja.txt, regulamin.md, docassist.pdf i pomoc.html: ich tematy odpowiadają zadaniu, a wersja 1.4 ma status active. regulamin_v1_3.md pomijamy jako archived i zastąpiony. Zachowujemy go w inwentarzu z uzasadnieniem oraz w archiwum źródeł. Nie musi być usunięty z dysku.

Pytanie Najbardziej bezpośrednie źródło Na co uważać
P1 instrukcja.txt Warunek zmiany konfiguracji, dwa kroki i wynik
P2 regulamin.md 1.4 Dyżur oraz wyjątek awaryjny
P3 docassist.pdf, strona 1 Jednostki i fikcyjny zakres parametrów
P4 pomoc.html Przekazanie komunikatu i zakaz pochopnej zmiany uprawnień
P5 regulamin.md, „Treść zgłoszenia” Dokument nie podaje wartości gwarantowanego czasu

P5 nie wolno rozwiązać obietnicą 30 sekund, 24 godzin ani innego terminu. Poprawna odpowiedź wskazuje brak takiej wartości w źródle. Karty pracy, klucz i gotowe oceny nie należą do korpusu opisanego asystenta: dotyczą nauki przygotowania danych. Nieznaną datę zapisujemy jako null; jeżeli jej brak uniemożliwia decyzję o obowiązywaniu rzeczywistego źródła, kierujemy dokument do wyjaśnienia. W tym ćwiczeniu status i zastąpienie wersji są podane jawnie.

Ćwiczenie 2 — odczyt

W A szum stanowią nawigacja i stopka. Treść sekcji „Błąd połączenia”, w tym warunek działania usługi i negacja, jest zachowana. Należy oddzielić treść główną oraz zachować jej nagłówek. Nie wystarczy jednak ocenić w ten sposób całego pliku: drugą sekcję „Kontrola znaków” także trzeba odczytać i sprawdzić.

B gubi zapis dokładnego komunikatu i przekazanie go administratorowi. Co gorsza, nakazuje zmianę uprawnień w miejsce zakazu zmieniania ich bez ustalenia przyczyny. Tego wyniku nie naprawi kosmetyczne czyszczenie. Trzeba wrócić do odczytu i porównać go z oryginałem.

Powstaje pięć rekordów: TXT ze stroną null, MD ze stroną null, PDF strona 1, PDF strona 2 oraz HTML ze stroną null. Każdy zachowuje źródło i własny identyfikator rekordu. Dla skanu z pustym wynikiem rozpoznajemy brak warstwy tekstowej i planujemy OCR albo inny kontrolowany odczyt, a następnie sprawdzamy wynik. Nie uznajemy pustego tekstu za sukces.

Przykładowe ciągi do kontroli: „Zażółć gęślą jaźń”, docassist-api, --no-pager, 25°C. Warto dodać ±5% oraz ≤10 ms, ponieważ sprawdzają znaki i jednostki, które mogą zmienić znaczenie po uszkodzeniu.

Ćwiczenie 3 — czyszczenie

Dopuszczalne są B, C i E, przy opisanych warunkach kontroli. A usunęłaby oba ponumerowane kroki, a w innych tekstach także wiersze z parametrami. D zniszczyłaby docassist-api i usunęła negację. Wariant „wykonuj restart bez zmiany konfiguracji” byłby odwróceniem sensu źródła.

Wynik powinien odpowiadać blokowi „po” z R3. Dopuszczalne są drobne różnice układu, o ile zachowują kolejność i znaczenie. Przykładowy rejestr:

Operacja Powód Kontrola
Usunięto rozpoznany nagłówek Powtarzany element strony Porównanie z oryginałem; nagłówek sekcji pozostał
Usunięto „Strona 1 z 2” Stopka techniczna Numer 1 nadal w metadanych
Połączono „konfigu-” i „racji” Potwierdzone łamanie wyrazu Nazwa usługi i komendy nie zostały zmienione

Muszą przetrwać m.in. warunek zmiany konfiguracji, negacja, kolejność restart–sprawdzenie, nazwa docassist-api i wynik active. Spośród danych R2 należy zachować np. 8 GB lub 30 s wraz z informacją, co oznaczają. Same liczby bez jednostek i kontekstu nie są wystarczające.

Ćwiczenie 4 — granice fragmentów

Wariant B jest lepszy dla pytania o awarię całego zespołu po 16:00, ponieważ zawiera regułę i wyjątek razem. Z regulaminu wynika zgłoszenie takiej awarii dyżurnemu administratorowi zgodnie z wewnętrzną procedurą. Szczegółów tej procedury nie podano, więc nie można ich odtworzyć z wyobraźni.

Dwadzieścia znaków overlapu nie jest semantyczną gwarancją. Trzeba obejrzeć rzeczywisty tekst na granicy i sprawdzić, czy zachował cały warunek. Liczba znaków nie mówi, czy przeniesiono początek wyjątku, całą treść wyjątku czy jedynie końcówkę słowa.

Dla restartu potrzebujemy warunku zmiany konfiguracji, obu kroków, kolejności i wyniku active; sam wynik nie wskazuje, co wykonano. Dobrym początkiem dla krótkiego regulaminu są sekcje, z kontrolą oddzielenia wyjątków i długich sekcji. Dla tekstu bez nagłówków można zacząć od akapitów, a gdy struktura jest niewiarygodna — od znaków z nakładaniem i ręczną oceną granic.

Kryteria jakości to np. zachowanie warunku i wyjątku oraz samodzielna zrozumiałość fragmentu. Można też oceniać możliwość wskazania źródła, obecność szumu i nadmierne powtórzenia. Znak jest jednostką zapisu tekstu, a token zależy od sposobu tokenizacji stosowanego przez model; 420 znaków nie oznacza 420 tokenów.

Ćwiczenie 5 — metadane

source powinno mieć wartość regulamin.md, a version — 1.4. page_number, page_start i page_end powinny mieć wartość null, bo źródłem jest Markdown. updated_at również ma wartość null, ponieważ daty nie znamy. Nie wpisujemy dosłownego słowa „dzisiaj” ani bieżącej daty jako rzekomego faktu źródłowego.

status przyjmuje active, zgodnie z opisem dokumentu. Ocena jakości należy do metadata.qa_status. Bez sprawdzenia treści nie można uzasadnić accepted; rekord wymaga przeglądu. Nagłówek przenosimy z pola pośredniego section_title do końcowego section, zachowując wartość „Dyżur operatora”.

Po odrzuceniu D identyfikatory E i F pozostają takie same, a vector_index wynosi odpowiednio 0 i 1. Pole access_level: internal opisuje zamierzony zakres dostępu. Nie jest mechanizmem uwierzytelniania ani kontroli uprawnień; aplikacja musi takie ograniczenia rzeczywiście egzekwować.

Ćwiczenie 6 — audyt i decyzja

ID Pierwsza ocena Uzasadnienie lub działanie
A accepted Aktualna, sprawdzona reguła wraz z wyjątkiem
B rejected Archiwalna wersja poza zakresem bieżącego asystenta
C review Sam wynik nie wyjaśnia testu; wróć do podziału i pełnej sekcji
D review Strona 7 nie istnieje; sprawdź źródło i popraw wszystkie pola strony na 1
E rejected Pusty tekst nie jest fragmentem wiedzy; zaplanuj poprawę odczytu

Dopuszczalne jest odrzucenie C zamiast pozostawienia go do naprawy, pod warunkiem opisania utraty pokrycia P1 i zaplanowania nowego, pełnego fragmentu. Nie jest poprawne przyjęcie go wyłącznie dlatego, że słowo active występuje w instrukcji.

W pierwszym przeglądzie NO-GO: pozostają nierozstrzygnięte C i D. Dla C trzeba odzyskać pełną procedurę z warunkiem, krokami i wynikiem, a następnie przeliczyć zależne pola. Dla D trzeba poprawić pochodzenie strony i zweryfikować zgodność treści. Po opisanej w zadaniu naprawie przyjęte etykiety A, C i D mają indeksy 0, 1 i 2.

P1, P2 i P3 są wtedy pokryte. P4 nadal nie ma pokrycia, ponieważ pusty E odrzucono i nie dodano poprawnego fragmentu „Błąd połączenia”. P5 nie ma wartości gwarantowanego czasu w korpusie. To dwa różne braki: P4 wymaga naprawy przetwarzania istniejącej treści, a P5 wymaga jawnego komunikatu o braku danych, bez zmyślania wartości.

Przykładowe podsumowanie: „Zbiór po naprawie zawiera trzy przyjęte fragmenty i nie ma ocen oczekujących. Nie pokrywa jeszcze błędu połączenia P4, a źródła nie określają wartości gwarantowanego czasu dla P5. Przed przekazaniem bazy do eksperymentu obejmującego cały zadeklarowany zakres poprawimy odczyt pomocy i ponowimy zależne etapy oraz audyt”.

Warunek techniczny GO może być już spełniony, ale pełny zadeklarowany zakres wymaga uzupełnienia P4. Dopuszczenie do eksperymentu ograniczonego do P1–P3 wymagałoby jawnego zawężenia celu. Nie należy utożsamiać komunikatu programu z pełną oceną gotowości merytorycznej.

Przygotowanie dokumentów i bazy wiedzy
ENHANCER+ · Politechnika Warszawska · materiał do samodzielnej nauki offline

10. Słownik pojęć

Pojęcia są uporządkowane według przebiegu pracy. Definicje odnoszą się do sposobu użycia terminów w tym module. Słownik można czytać niezależnie lub wykorzystać do powtórki po ćwiczeniach.

Źródła i odczyt

Pojęcie Znaczenie w Module 2
Baza wiedzy Uporządkowany zbiór treści przeznaczonych do określonego zastosowania. Na tym etapie ma postać tekstów, fragmentów, metadanych i ocen.
Korpus Wybrany zestaw dokumentów źródłowych używany w procesie przygotowania danych.
Zakres bazy Opis odbiorców, obsługiwanych pytań, źródeł i wyłączeń.
Inwentarz źródeł Rejestr dokumentów z pochodzeniem, wersją, statusem i decyzją o użyciu. Może zawierać także źródła pominięte.
Wersja dokumentu Oznaczenie wydania treści źródłowej; nie jest wersją modelu.
Status dokumentu Informacja o stanie dokumentu, np. active, archived lub draft.
Ekstrakcja Wyodrębnianie tekstu i jego struktury z pliku. Poprawne wykonanie programu nie gwarantuje kompletności wyniku.
OCR Rozpoznawanie tekstu z obrazu. Wynik może zawierać pomyłki i wymaga porównania z obrazem źródłowym.
Tekst surowy Wynik odczytu przed czyszczeniem, przechowywany jako punkt odniesienia.
Rekord odczytu Jednostka zapisana po ekstrakcji, np. jedna strona PDF lub cały plik TXT w tym zestawie.

Czyszczenie i fragmentacja

Pojęcie Znaczenie w Module 2
Normalizacja Ujednolicanie reprezentacji tekstu według jawnych reguł, z zachowaniem znaczenia.
Unicode NFC Forma normalizacji zapisu znaków; nie usuwa polskich liter ani nie poprawia treści merytorycznej.
Szum Elementy nieprzydatne dla celu bazy, np. rozpoznana stopka techniczna. Ocenę trzeba odnieść do kontekstu.
Tekst oczyszczony Wynik kontrolowanych zmian, zachowujący treść źródła i powiązanie z tekstem surowym.
Rejestr operacji Zapis zmian, ich przyczyn i sposobu kontroli.
Fragment / chunk Jednostka tekstu przygotowana do dalszego wyszukiwania i budowania kontekstu.
Fragmentacja / chunking Podział tekstu według ustalonej strategii, np. znaków, akapitów lub sekcji.
Chunk size Parametr wielkości fragmentu. W porównywanych ustawieniach M2 jest wyrażany w znakach.
Overlap Powtórzony odcinek na styku sąsiednich fragmentów. Pomaga zachować ciągłość, ale nie gwarantuje pełnego kontekstu.
Token Jednostka przetwarzania tekstu przez model, zależna od tokenizera. Nie jest równoznaczna ze znakiem ani zawsze ze słowem.

Pochodzenie i jakość

Pojęcie Znaczenie w Module 2
Metadane Dane opisujące pochodzenie, lokalizację, parametry przygotowania i ocenę fragmentu.
Lokalizator Informacja pozwalająca odszukać treść, np. strona PDF i sekcja; zakres znaków odnosi się do wskazanego rekordu tekstu.
document_id / record_id Identyfikatory odpowiednio dokumentu oraz jednostki powstałej przy odczycie.
chunk_id Identyfikator fragmentu, zachowywany przy filtrowaniu istniejącego zbioru.
vector_index Kolejny numer rekordu w danym zbiorze; w M2 nie oznacza utworzonego embeddingu.
null Jawny brak wartości w JSON. Odpowiednik None w Pythonie; różni się od napisu „null”.
JSON / JSONL Formaty zapisu danych: JSON opisuje jeden dokument danych, a JSONL zapisuje osobny obiekt JSON w każdym wierszu w przyjętym tu schemacie.
Walidacja Sprawdzanie zgodności danych z regułami, np. pól, typów, identyfikatorów i zakresów.
qa_status Ocena fragmentu: accepted, review lub rejected. Nie zastępuje statusu dokumentu.
Pokrycie pytania Ocena, czy źródła i przyjęte fragmenty zawierają informację potrzebną do odpowiedzi. Nie jest wynikiem pomiaru retrievera.
GO / NO-GO Uzasadniona decyzja o dopuszczeniu do określonego następnego etapu lub o konieczności poprawy.
RAG Podejście łączące wyszukiwanie treści ze wspomaganym nią generowaniem odpowiedzi. M2 przygotowuje jego dane wejściowe.
Embedding Numeryczna reprezentacja treści, wykorzystywana m.in. do porównywania podobieństwa; nie tworzymy jej w tym module.
Retriever Element przyszłego systemu wybierający fragmenty dla pytania. Jego skuteczność trzeba sprawdzić w osobnym eksperymencie.

Przygotowanie dokumentów i bazy wiedzy
ENHANCER+ · Politechnika Warszawska · materiał do samodzielnej nauki offline