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

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

Dobra demonstracja potwierdza, że pewna ścieżka zadziałała w określonej sytuacji. Plan ewaluacji określa, jakie sytuacje sprawdzisz, po czym rozpoznasz błąd i jak szeroki wniosek możesz wyciągnąć. Plan zapisujesz przed oglądaniem odpowiedzi, aby nie dopasowywać kryteriów do uzyskanych rezultatów.

Od potrzeby użytkownika do warunku testu

Użytkownik DocAssist chce znaleźć lokalną procedurę i jej źródło. Wynik musi więc być poprawny wobec dokumentacji, obejmować wymagane warunki i wskazywać fragment pozwalający skontrolować treść. Sama płynność językowa nie wystarczy. Jeśli użytkownik prosi o wykonanie restartu, poprawne zachowanie jest inne: aplikacja odmawia wykonania i może wyjaśnić granicę swoich możliwości.

Rozłóż jakość na warstwy. Wyszukiwanie znajduje fragmenty. Filtr i składanie kontekstu wybierają materiał dla modelu. Generowanie tworzy tekst. Warstwa rozmowy ustala znaczenie zaimków i właściwe źródła poprzedniej odpowiedzi. Warstwa narzędzi wybiera i wykonuje dozwoloną funkcję. Niepowodzenie całej tury może mieć początek w dowolnym z tych miejsc.

Cel, kryterium, metryka i próg

Cel opisuje potrzebę, np. „operator ma poznać procedurę po nieudanym uruchomieniu”. Kryterium mówi, co oceniasz, np. kompletność. Metryka nadaje wynikowi mierzalną postać, np. ocena 0–2 albo pokrycie wymaganych grup. Próg akceptacji mówi, jaki wynik uznasz za wystarczający. Ustal również warunki krytyczne, które przesądzają o niezaliczeniu niezależnie od innych ocen.

Przykładowy plan może wymagać poprawnego statusu i narzędzia, wszystkich obowiązkowych faktów, braku twierdzeń zabronionych i poprawnych źródeł. To propozycja dla tego projektu, nie regulamin oceniania kursu. Nie wybieraj progu dopiero wtedy, gdy zobaczysz średnią.

Przykład planu do zapisania

Cel: sprawdzić, czy DocAssist odpowiada zgodnie z korpusem M3–M5.
Zakres: wyszukiwanie, kontekst, odpowiedź, źródła, rozmowa i narzędzia.
Poza zakresem: wykonywanie operacji systemowych, wdrożenie produkcyjne.
Baza: top_k=3, brak progu score, rag_v1, parametry pakietowe.
Zestaw: 24 przypadki / 13 kategorii / 26 tur.
Offline: podzbiory R3 i R4, jawnie oddzielone od importu M5.
Ocena: rubryki 0–2; ND tylko dla kryteriów niewłaściwych dla przypadku.
Krytyczny warunek T101: przywrócenie zatwierdzonej kopii po niepowodzeniu.
Decyzja: krytyczne naruszenie daje fail; brak dowodu daje inconclusive.
Stabilność modelu: trzy nowe wykonania Ollama, komplet wyników i ocen.

Uzupełnij evaluation_plan.md w swoim WORK/evaluation, korzystając z szablonu pakietowego. Dopisz autora, zakres faktycznie wykonywanych prób, sposób rozstrzygania ocen spornych i warunki wyboru konfiguracji końcowej. Jeśli nie możesz wykonać części prób, zaplanuj sposób opisania tego ograniczenia.

Zbuduj ochronę konfiguracji bazowej

configure(ROOT, mode=...) odczytuje indeks i sprawdza środowisko. Funkcja zwraca faktyczne parametry obsługiwane przez pakiet. Twoja funkcja zapisuje je raz. Identyczny ponowny zapis jest dozwolony, a inna konfiguracja w tym samym pliku zostaje odrzucona.

R1 · Do pliku kod/moj_m6.py · zastąp całą definicję

def save_baseline(path, config):
    check_config(config)
    path = Path(path)
    if path.exists():
        if read_json(path) != config:
            raise ValueError('Istnieje inna baza. Rozpocznij osobny eksperyment.')
        return read_json(path)
    save_json(path, config)
    return deepcopy(config)

Notebook warsztatu · przykład wywołania

w.save_baseline(E / 'baseline_config.json', config)
ref.initialize_document(ROOT, 'evaluation_plan.md',
                        E / 'evaluation_plan.md')
print('Uzupełnij plan przed ocenianiem wyników.')

Sprawdzenie tej funkcji nie wymaga modelu. Zapisz bazę, utwórz kopię ze zmienionym top_k i spróbuj zapisać ją pod tą samą nazwą. Oczekujesz wyjątku, a plik powinien nadal zawierać pierwotną wartość. Wariant eksperymentalny zapiszesz później jako candidate_config.json.

Ćwiczenie R1

Napisz cel i regułę decyzji dla pytania o treść zgłoszenia awarii. Oddziel kryterium kompletności od warunku zakazującego umieszczania haseł w zgłoszeniu. Następnie uzupełnij save_baseline i uruchom kontrolę R1.

Sprawdź się: potrafisz powiedzieć, co oznacza pass, fail i inconclusive, zanim zobaczysz odpowiedź. W bazie nie wpisujesz wartości z przykładowego slajdu, lecz odczytujesz rzeczywiste ustawienia.

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