9. Odpowiedzi i wskazówki do ćwiczeń

ENHANCER+ · Moduł 6 · Ewaluacja RAG · Rozdział

Najpierw wykonaj zadania samodzielnie. Poniższe odpowiedzi wyjaśniają kryteria rozumowania. Przy ocenach semantycznych dopuszczalne są różnice liczbowe, jeśli wynikają z jasno opisanej rubryki i konkretnych dowodów. Nie przenoś ocen przykładu na nową odpowiedź bez jej przeczytania.

R1. Plan i warunek krytyczny

Dla pytania o zgłoszenie awarii celem jest uzyskanie listy informacji potrzebnych operatorowi. Kompletność obejmuje wersję systemu, czas, komunikat błędu, wykonane kroki i oczekiwany wynik. Zakaz umieszczania haseł i kluczy jest innym wymaganiem: odpowiedź może podawać pełną listę i mimo to zawierać niebezpieczny dodatek. Dlatego zapisz zakaz jako osobny warunek kontraktu, z odpowiednią regułą krytycznego niepowodzenia.

save_baseline powinno zaakceptować pierwszy zapis i identyczne ponowienie. Przy tej samej ścieżce i top_k zmienionym z 3 na 5 powinno zgłosić wyjątek. Plik bazy pozostaje niezmieniony. Jeżeli chcesz inny tryb albo konfigurację początkową, utwórz osobny katalog eksperymentu.

R2. Parafraza zgłoszenia

Przykładowe nowe pytanie brzmi: „Co mam przygotować, zanim zgłoszę problem z DocAssist?”. Oczekiwanym narzędziem jest answer_from_documents; oczekiwane fakty wynikają z DOC-REG, sekcji „Treść zgłoszenia”. Dokładny tytuł sekcji oraz chunk_id odczytaj z dodatku źródłowego, ponieważ są częścią kontraktu danych.

Twierdzeniem zabronionym może być „dołącz hasło do konta”. Nie dopisuj gwarantowanego czasu rozwiązania, bo regulamin go nie podaje. Nowe sformułowanie nie musi mieć zapisanego embeddingu ani odpowiedzi selektora, więc wykonanie może wymagać Ollama. Sam poprawny walidator nie dowodzi dostępności checkpointu.

Jeżeli dokument nie wspiera planowanego faktu, zmień oczekiwanie przed testem albo świadomie utwórz test braku wiedzy. Nie oczekuj zewnętrznej procedury tylko dlatego, że jest znana z innego modułu.

R3. Fragmenty i grupy

Kontrolowany przykład ma grupy A oraz B, po jednym wymaganym fragmencie. Ranking A, X, Y daje Hit@1=true, Hit@3=true, any_group=true, all_groups=false i group_coverage=0,5. Ranking A, X, Y, B, Z przy top_k=5 daje pełne pokrycie grup. Dodatkowe pozycje mogą zwiększać szum, dlatego poprawa pokrycia nie rozstrzyga oceny całego kontekstu.

Jeśli jedna grupa wymaga jednocześnie A1 i A2, obecność samego A1 daje Hit@k=true, ale jeszcze nie spełnia grupy. To celowo inne pytania metryczne. Gdy lista oczekiwanych grup jest pusta, wyniki Hit@k i pokrycia to N/D. Nie licz takich przypadków jako nietrafionych wyszukiwań.

W rzeczywistym T004 przy top_k=3 brakuje DOC-INSTR-dd6055d675-0003. Przy top_k=5 fragment pojawia się. Poprawny wniosek dotyczy pokrycia w określonym indeksie. Nie można jeszcze napisać, że wariant generuje lepszą odpowiedź.

R4. Odpowiedź częściowa i narzędzie

Demonstracyjne zdanie „Po zmianie konfiguracji uruchom ponownie usługę” ma podstawę w źródle, ale nie spełnia T101. Brak kontroli stanu, interpretacji active, kopii po niepowodzeniu i zgłoszenia administratorowi. Krytyczne pominięcie kopii wymaga critical_error=true i verdict=fail. Poprawność wypowiedzianego zdania nie jest tym samym co kompletność procedury.

W historycznej turze 2 M5 resolver prawidłowo rozwinął zaimek. Bezpośredni dowód problemu jest później: decyzja i wykonane narzędzie wskazują show_last_sources zamiast RAG odpowiadającego na pytanie. Najwcześniejszy potwierdzony etap to tool_selection. Nie ma podstaw, aby przypisywać ten konkretny błąd chunkingowi.

Dla T007 poprawna odmowa jest wynikiem pozytywnym, o ile treść i brak wykonania zgadzają się z kontraktem. Dla T008 prośba o doprecyzowanie przy pustej historii także może być pozytywna. Nie przyznawaj im automatycznie zera za brak procedury.

R5. Hipotezy i eksperyment

Hipotezę „właściwy fragment leży poniżej top_k” sprawdzasz szerszym rankingiem przy stałym pytaniu i indeksie. Jeśli go tam nadal nie ma, trzeba zbadać inne przyczyny. Hipotezę o formacie cytowań sprawdzasz na nowej generacji po jednej zmianie instrukcji, oceniając także znaczenie źródeł. Hipotezę o selektorze sprawdzasz na całym scenariuszu, kontrolując historię i rzeczywistą decyzję.

Offline można wykonać porównanie top_k 3/5 na zapisanych embeddingach. Nie można z tego wywnioskować nowej jakości generowania ani stabilności modelu. Przy trzech ocenach 2, 1, 2 minimum wynosi 1, mediana 2. Jeden błąd krytyczny w trzech próbach nie znika dlatego, że dwie pozostałe zakończyły się dobrze.

Regresja powinna wskazywać konkretne kryterium i wynik. Jeżeli wzrosło pokrycie, ale pogorszył się szum, nie zapisuj po prostu „lepiej”. Przedstaw oba skutki i zastosuj wcześniej ustaloną regułę decyzji.

R6. Wnioski o właściwym zakresie

Przykład o wyszukiwaniu: „W odtworzonym T004 wymagany fragment nie wystąpił w top-3, lecz był obecny po rozszerzeniu do top-5 przy tym samym indeksie”. Dowód powinien wskazywać dwa result_id i plik porównania. Nie zastępuj ich samym test_id.

Przykład o zachowaniu: „W zapisanej turze T007 aplikacja odmówiła wykonania restartu”. Powiąż go z wynikiem i ręczną oceną. Przykład ograniczenia: „Nie wykonano pełnej nowej serii Ollama, więc raport nie ocenia stabilności odpowiedzi T101”. Taki wniosek nie potrzebuje wymyślonego result_id; jego podstawą jest plan i lista wykonanych prób.

Macierz powinna pomagać czytelnikowi, a nie udawać dowód samą obecnością identyfikatora. Jeżeli nie ma zgodnej recenzji albo wynik pochodzi z innego kontraktu, najpierw uzupełnij materiał, potem formułuj wniosek.

Lokalne chatboty, agenci i systemy RAG z własną bazą wiedzy · Moduł 6 · Wydanie 29.09.2026