Podręcznik uczestnika z objaśnieniami, przykładami i ćwiczeniami do samodzielnej nauki do Modułu 4
7. Integracja i porównanie wariantów RAG
Integracja polega na połączeniu sprawdzonych funkcji i zachowaniu śladu całej próby. Porównanie wariantów ma sens, kiedy wiadomo, co zmieniono i na jakiej podstawie oceniono rezultat. Dobra odpowiedź w jednym przykładzie nie jest jeszcze miarą jakości całego systemu.
1. Funkcja koordynująca
def ask_rag(
question,
top_k=DEFAULT_TOP_K,
similarity_threshold=DEFAULT_SIMILARITY_THRESHOLD,
*,
prompt_version=None,
) -> dict:
...
To schemat sygnatury do analizy. ask_rag() waliduje pytanie i parametry, tworzy embedding pytania, pobiera i normalizuje ranking, wybiera kontekst, buduje prompt oraz wywołuje LLM. Wynik łączy przez build_rag_result(). Przy błędzie zachowuje jego kategorię, a przy braku kontekstu kończy pracę przed generacją.
Pełny zapis próby obejmuje m.in. result_id, case_id, index_id, tryb, parametry, pełny prompt, kontekst i informacje o wywołaniach. case_id nazywa scenariusz, np. Q2 albo top_k_3. result_id identyfikuje konkretną realizację. Kolejne wykonanie tego samego scenariusza dostaje nowy identyfikator wyniku.
2. Cztery warianty kontekstu
Pytanie jest takie samo jak w R3: co zrobić przed edycją konfiguracji i po jej zmianie? A zawiera samo pytanie. B, C i D mają wspólną instrukcję odpowiedzi wyłącznie z kontekstu, zachowania warunków, wskazywania braków i cytowania źródeł.
| Wariant | Kontekst | Co porównujesz |
|---|---|---|
| A | Brak dokumentów. | Odpowiedź ogólną bez lokalnej podstawy. |
| B | F2 jako S1 i F1 jako S2. | Pokrycie obu części pytania. |
| C | Tylko F1 jako S1. | Reakcję na brak czynności przed edycją. |
| D | Jeden celowo nieaktualny tekst jako S1. | Wierność błędnemu materiałowi oraz aktualność. |
Archiwalna instrukcja demonstracyjna v0.1. Przed edycją konfiguracji nie twórz kopii. Po zmianie pliku nie uruchamiaj ponownie usługi i nie sprawdzaj jej stanu.
Metadane: wersja 0.1, status obsolete, identyfikator FIXTURE-D-OBSOLETE-01. Tekstu nie dodajemy do właściwego indeksu. Aktualną podstawą porównania pozostają F1 i F2 w wersji 1.4.
Porównanie A/B zmienia zarówno dostęp do dokumentów, jak i instrukcję. Może pokazywać różnicę między dwoma sposobami pracy, ale nie izoluje wyłącznie wpływu kontekstu. B/C/D zachowuje tę samą instrukcję i pozwala skupić się na zawartości przekazanego materiału.
3. Odpowiedzi demonstracyjne
Zwykle warto zabezpieczyć bieżące ustawienia, zastosować zmianę i sprawdzić działanie. Nie otrzymałem lokalnej instrukcji, więc nie potwierdzam konkretnych poleceń DocAssist.
Przed edycją zachowaj kopię pliku konfiguracyjnego [S1]. Po zmianie uruchom sudo systemctl restart docassist-api, następnie systemctl is-active docassist-api; prawidłowy wynik to active [S2]. W razie nieudanego uruchomienia przywróć zatwierdzoną kopię i zgłoś problem administratorowi [S1].
Kontekst nie określa czynności przed edycją. Po zmianie konfiguracji uruchom sudo systemctl restart docassist-api, a następnie systemctl is-active docassist-api; prawidłowy wynik to active [S1].
Przed edycją nie twórz kopii. Po zmianie pliku nie uruchamiaj ponownie usługi i nie sprawdzaj jej stanu [S1].
D jest wierne przekazanemu błędnemu tekstowi i zawiera istniejącą etykietę. Jednocześnie przeczy aktualnym F1 i F2. To dwa różne kryteria: zgodność z bieżącym kontekstem oraz poprawność względem właściwej dokumentacji. Metadana obsolete jest sygnałem do kontroli wyboru źródła; samo jej zapisanie nie gwarantuje, że model odrzuci tekst.
4. Zmiany parametrów i zapis eksperymentu
Najpierw zachowaj wynik odniesienia. Następnie zmieniaj top_k, próg lub wersję promptu przy stałych pozostałych warunkach. Zapisuj pełne wyniki, także odmowy i błędy. Porównanie samej długości lub płynności tekstu nie pokaże, czy model pominął warunek albo użył nieaktualnej podstawy.
Wyniki zapisuje się w rag_experiments.jsonl, po jednym obiekcie JSON w wierszu. Własną ocenę wiążesz z result_id, a wnioski rozwijasz w raport_z_eksperymentu.md. Poniższy rekord jest skróconym przykładem dydaktycznym zapisu decyzji programu, a nie kompletnym logiem notebooka.
{"result_id":"przyklad-01","case_id":"prog_090",
"status":"insufficient_context","reason":"below_threshold",
"top_k":3,"similarity_threshold":0.90,"answer":""}
W JSONL powyższy obiekt zapisujesz w jednym fizycznym wierszu; w książce podzielono go dla czytelności. Do odtwarzalności rzeczywistej próby potrzebujesz ponadto wejścia, identyfikatora indeksu, modeli, parametrów generacji i kontekstu. Dane demonstracyjne powinny pozostać wyraźnie oznaczone.
Ćwiczenie 6. Porównaj i zaplanuj poprawę
Oceń odpowiedzi A–D na podstawie tekstów i założeń podanych w książce.
- Dla każdego wariantu opisz zgodność z otrzymanym kontekstem, pokrycie obu części pytania, cytowania i zgodność z aktualną dokumentacją. Przy A zaznacz brak źródła zamiast wymyślać wynik zgodności z kontekstem.
- Wskaż twierdzenie z D, które jest wierne jego kontekstowi, ale sprzeczne z F1 lub F2. Zaproponuj zmianę na etapie wyboru źródeł.
- Dla rankingu z R4 porównaj top_k=1 i top_k=3 przy wyłączonym progu. Jaki brak w pierwszym wariancie może wynikać z samego retrievalu?
- Zaplanuj porównanie rag_minimal, rag_constrained i rag_v1. Określ stałe warunki, kryteria oraz sposób zapisania wyników.
- Napisz wniosek w trzech zdaniach: obserwacja, jej podstawa i ograniczenie. Nie formułuj oceny jakości modelu na podstawie przygotowanych odpowiedzi.
Czy wniosek wynika z danych, a zmiana parametrów ma wskazaną przyczynę i punkt odniesienia?
Jeżeli pracujesz również na komputerze, wykorzystaj kartę R6 oraz notebook M12_M4_R6_kompletny_rag_start.ipynb.
Notebook zapisuje 19 prób: pięć pytań, A–D, trzy wartości top_k, cztery progi oraz trzy wersje promptu. Wykorzystuje rzeczywiste wywołania albo ich jawnie oznaczone odtworzenia. Liczby i odpowiedzi z ćwiczeń książkowych nie są kluczem do nowych wyników modelu. Własny indeks uruchamiaj w dodatkowym notebooku M12_M4_R6_wlasny_indeks.ipynb z własnymi pytaniami.