Modele językowe (LLM Basics) – Lab 0

---

Projekt nie wymaga trenowania LLM, usługi bazodanowej w chmurze, rozbudowanego interfejsu ani wielu agentów. Lokalny indeks FAISS z metadanymi dokumentów wystarcza jako indeks wektorowy. Oceniany jest działający przepływ oraz to, czy potrafisz wykazać jego ograniczenia.

Dwa przepływy, jeden projekt

Obie części mogą działać w jednym repozytorium jako osobne skrypty lub funkcje. Nie musisz podłączać narzędzi agenta do endpointu RAG. Podczas prezentacji pokaż, gdzie w każdym przepływie program sprawdza dane, a gdzie model może zaproponować jedynie wynik lub działanie.

Przepływ	Co się dzieje?	Przykład z zajęć
Agent z narzędziami	Model proponuje nazwę narzędzia i argumenty. Program sprawdza je w rejestrze, wykonuje dozwoloną funkcję, przekazuje ograniczony wynik modelowi i odbiera odpowiedź.	calculate lub read_note, dispatcher z 04A i pętla z 04B. Gemini używa natywnego wywołania funkcji; model lokalny podejmuje decyzję w walidowanym JSON.
Mini-RAG	Program dzieli dokumenty na fragmenty, wyszukuje je i przekazuje wybrane fragmenty modelowi. Odpowiedź zawiera identyfikatory źródeł albo informację, że brak podstaw do odpowiedzi.	Embeddingi i FAISS z 05A, BM25/RRF z 05B, usługa z 06A oraz ocena i POST /ask z 06B.

Fałszywy model lub FakeDriver pomaga przetestować program bez API. Nie zastępuje wymaganego uruchomienia prawdziwego małego modelu lokalnego w co najmniej jednym scenariuszu.

Wymagania podstawowe do zaliczenia

• Model i odpowiedź strukturalna: działający tryb API (Gemini lub OpenAI) oraz lokalny LLM za spójnym interfejsem; co najmniej jedno zadanie zwracające JSON sprawdzany schematem. Opcja OpenAI zakomentowana w laboratorium nie musi być uruchamiana, jeśli działa Gemini.
• Narzędzia: co najmniej dwie dozwolone funkcje, ich jawny rejestr, sprawdzenie nazwy i argumentów, pętla „propozycja → wykonanie → odpowiedź” oraz ograniczenie liczby kroków i długości wyniku. W trybie API pokaż natywne wywołanie funkcji; w lokalnym wystarczy walidowana decyzja JSON przekazana do tego samego dispatchera.
• Mini-RAG: dokumenty podzielone na fragmenty z identyfikatorami źródeł, embeddingi, indeks wektorowy (np. FAISS), wyszukiwanie top-k, ograniczony kontekst dla LLM, odpowiedź ze źródłami i zachowanie dla pytania bez odpowiedzi. Porównaj wyszukiwanie wektorowe z BM25 lub hybrydą z 05B.
• Granice działania: bezpieczny odczyt plików z dozwolonego katalogu, walidacja formatu odpowiedzi, limity kroków, danych i czasu żądań do API; sprawdzenie próby wstrzyknięcia instrukcji do dokumentu. Samo wyszukanie podejrzanych słów nie jest gwarancją bezpieczeństwa.
• Sprawdzenie wyników: ustalony z góry zestaw co najmniej 12 różnych przypadków, metryki wyszukania i działania usługi, raport z błędami i wnioskami oraz test regresyjny dla znalezionego błędu.
• Uruchomienie: dostępny dla prowadzącego sposób zadania pytania, np. CLI i/lub POST /ask, instrukcja od pustego środowiska do wyniku, plik zależności, .env.template bez sekretów oraz proste logi statusu i czasu.
• Warunek formalny: zrzut ekranu potwierdzający ukończenie całego kursu IBM SkillsBuild „UMCS – Large Language Models”. Nie jest punktowany w tabeli; jest osobnym warunkiem zaliczenia.

Co dokładnie znaczy „limit czasu” w kodzie z zajęć?

W 04B max_tool_seconds sprawdza czas po zakończeniu funkcji. Jeśli funkcja się zawiesi, ten warunek jej nie przerwie. Dwa krótkie narzędzia z 04A mają dodatkowe ograniczenia: kalkulator przyjmuje sprawdzone argumenty, a odczyt notatki ma limit znaków i katalog. Dla żądania do Gemini ustawialiśmy limit klienta HTTP. Jeżeli dodasz narzędzie zewnętrzne, które może się blokować, zapewnij rzeczywiste przerwanie lub odizolowanie jego wykonania po limicie. W README nazwij zakres każdego limitu uczciwie.

Punktacja podstawowa – 100 punktów

Punkty dostajesz za działanie, które można uruchomić i sprawdzić w kodzie, testach lub raporcie. W nawiasach podano podział punktów wewnątrz obszaru.

Obszar	Pkt	Co pokażesz?
1. Adapter modelu i pomiar	10	API oraz rzeczywisty model lokalny za wspólnym kontraktem (5); konfiguracja bez sekretów w kodzie (2); pomiar czasu, tokenów, jeśli dostawca je podaje, i krótki wniosek z porównania (3).
2. Prompt i wynik strukturalny	10	Oddzielenie instrukcji aplikacji od treści użytkownika i dokumentów (2); schemat JSON/Pydantic dla jednego zadania (4); walidacja wyniku i czytelna obsługa niepoprawnego formatu (4).
3. Narzędzia i pętla agenta	20	Rejestr dozwolonych nazw i dispatcher (4); typy, zakresy i wymagane pola argumentów (4); propozycja modelu → wykonanie → odpowiedź końcowa w trybie API i lokalnym (4); bezpieczna ścieżka oraz limity kroków i rozmiaru wyniku (5); kategorie błędów, pomiar czasu i właściwy limit żądania zewnętrznego (3).
4. Wyszukiwanie	15	Embeddingi z indeksem wektorowym, np. FAISS (4); fragmenty z doc_id, chunk_id i źródłem (3); wyszukiwanie top-k (3); porównanie z BM25 lub RRF na tych samych danych (2); poprawnie policzony Recall@k lub MRR z wcześniej ustalonego zbioru pytań (3).
5. Mini-RAG	15	Kontekst z wybranych fragmentów z limitem długości (4); odpowiedź z identyfikatorami źródeł (4); uczciwe „brak podstaw” przy pytaniu bez odpowiedzi (3); kontrola, czy cytowane ID należą do przekazanego kontekstu (2); działający przepływ od pytania do odpowiedzi (2).
6. Ewaluacja i granice bezpieczeństwa	15	Co najmniej 12 przypadków z ustalonym oczekiwaniem (4); metryki wyszukania, formatu, błędów i czasu (4); testy ścieżki, wstrzyknięcia w dokumencie i odpowiedzi spoza schematu wraz z opisem granic zabezpieczeń (4); raport oraz przynajmniej jeden test regresyjny (3).
7. Dostępność i odtwarzalność	10	Działające CLI, POST /ask lub prosta aplikacja (3); logi statusu, nazwy narzędzia i czasu bez sekretów i treści prywatnych dokumentów (2); README, .env.template i plik zależności (3); czytelny układ projektu i testowalne funkcje (2).
8. Demo i opis przepływu	5	Pokaz trzech przypadków: kalkulator, pytanie do RAG i próba niedozwolonego działania (2); krótki diagram lub opis przepływu narzędzi i RAG (2); uzasadnienie jednej decyzji albo opisanego ograniczenia (1).
Razem	100	Premie mogą podnieść wynik do 100, lecz nie ponad 100.

Endpoint /ask z 06B obsługuje RAG. Nie musi przyjmować parametru use_functions ani wykonywać narzędzi agenta. Agenta można pokazać osobno przez CLI. Lokalny FAISS jest wystarczający; osobny serwer „vector database” nie daje punktów sam z siebie.

Zestaw testów: co i jak mierzyć?

Przygotuj co najmniej 12 różnych przypadków ze znanym oczekiwaniem. Poniższe grupy pokazują zakres. Ten sam przypadek może sprawdzać dwie rzeczy, ale w pliku testowym musi być łącznie co najmniej 12 różnych wejść i oczekiwanych rezultatów.

Grupa	Przykłady (co najmniej 4)	Co zapisać?
Format	poprawny JSON, brak wymaganego pola, dodatkowe pole, odpowiedź poza schematem	Ile odpowiedzi spełnia schemat; mianownik to liczba prób.
Narzędzia	poprawne obliczenie, nieznana nazwa, argument poza zakresem, przekroczony budżet lub zgłoszony timeout	Status i kategorię błędu, bez surowego tracebacka dla użytkownika.
Wyszukiwanie i RAG	dwa pytania z odpowiedzią, pytanie bez odpowiedzi, błędne lub nieistniejące źródło	Recall@k/MRR tylko tam, gdzie istnieją relewantne dokumenty; osobno abstencję i poprawność cytowanych ID.
Próby obejścia	../../.env, instrukcja ukryta w znalezionym fragmencie, żądanie niedozwolonego narzędzia, próba wymuszenia odpowiedzi bez źródła	Czy doszło do rzeczywistego odczytu, wykonania albo nieuprawnionej odpowiedzi.

Dla Recall@k oznacz poprawne dokumenty przed uruchomieniem wyszukiwarki. Jeśli w pierwszych k wynikach znalazł się jeden z dwóch poprawnych dokumentów, recall tego pytania wynosi 1/2. Przy pytaniu bez poprawnego dokumentu nie dzielimy przez zero: oceniamy je osobno jako przypadek „brak odpowiedzi”. Poprawne ID cytatu potwierdza pochodzenie fragmentu, lecz samo nie dowodzi, że treść wspiera każde zdanie odpowiedzi – sprawdź ręcznie kilka odpowiedzi.

Heurystyka wykrywająca słowa „ignore previous instructions” może pomóc znaleźć podejrzany tekst, ale da fałszywe alarmy i przegapi parafrazę. Twarda blokada wynika z uprawnień programu: nazwa spoza rejestru i ścieżka poza katalogiem nie mogą zostać wykonane, nawet jeśli model o to poprosi.

Błędy krytyczne i poprawa

Stwierdzony problem	Skutek, dopóki występuje	Dowód po poprawie
Model może wykonać dowolną nazwę funkcji albo ominąć walidację argumentów.	0 pkt za obszar 3; wynik końcowy najwyżej 54 pkt.	Negatywny test nazwy i argumentów oraz wywołanie wyłącznie przez dispatcher.
Odczyt pliku spoza dozwolonego katalogu lub inne nieautoryzowane działanie rzeczywiście się udaje.	Wynik końcowy najwyżej 54 pkt.	Test dla ../../.env i, gdy dotyczy, dowiązania symbolicznego; kontrola rzeczywistej ścieżki i uprawnień.
Prawdziwy klucz API lub inny sekret znajduje się w oddawanym repozytorium albo logach.	Projekt czeka na usunięcie problemu przed oceną.	Unieważnienie klucza, nowy klucz poza repozytorium, usunięcie sekretu z oddawanej historii i kontrola logów.
Nie da się uruchomić projektu zgodnie z README.	Nie przyznaje się punktów za elementy, których nie da się sprawdzić.	Działająca komenda odtworzenia oraz zapis wyników testów.

Limit 54 punktów oznacza brak zaliczenia do czasu usunięcia krytycznej podatności; po poprawie i ponownym sprawdzeniu można ocenić projekt normalnie. Nie odejmujemy drugi raz punktów za ten sam brak. Instrukcja systemowa nie jest automatycznie sekretem: w próbach red-team liczy się skutek, np. odczyt chronionego pliku lub wykonanie niedozwolonej operacji. Niewprowadzenie limitów czasu lub pomiaru skutkuje utratą odpowiednich punktów z tabeli; test zgłoszonego TimeoutError nie dowodzi, że kod potrafi przerwać zawieszoną funkcję.

Premie – najwyżej +10, wynik końcowy najwyżej 100

Rozszerzenie	Premia	Warunek przyznania
Reranking	do +5	Wynik i czas porównane z wyszukiwaniem bazowym na tym samym zestawie pytań; opis co najmniej jednego pogorszonego przypadku.
Automatyczny red-team runner	do +5	Powtarzalne przypadki, zbiorczy raport statusów i zapis śladu bez sekretów.

Laboratoria 07A i 07B są dodatkowymi tematami kursu. Karta ryzyka z 07A i przepływ wielu ról z 07B nie są obowiązkowymi elementami tego projektu. Możesz opisać ryzyko lub porównać warianty z własnej inicjatywy, ale podstawowa tabela nie wymaga osobnego systemu wieloagentowego.

Korzystanie z generatorów kodu

• Możesz używać AI do przygotowania szkieletu, testów i wariantów implementacji.
• Sprawdzasz wygenerowany kod i potrafisz wyjaśnić, jak waliduje argumenty, wybiera fragmenty i kończy pętlę agenta.
• W raporcie krótko napisz, gdzie użyłeś AI i które wyniki zweryfikowałeś samodzielnie.
• Na prezentacji możesz zostać poproszony o zmianę limitu, dodanie testu albo diagnozę błędu.
• Nie przesyłaj generatorowi kluczy i cudzych danych, których nie wolno udostępniać.

Z czego korzystasz po kolejnych laboratoriach?

Część	Co przyda się w projekcie?	Przykładowy dowód
01A-01B	Środowisko, backend API/lokalny i pomiar generacji.	Konfiguracja obu trybów i zapis czasu.
02A-02B	Podstawy działania transformera i dekodowania potrzebne do interpretacji ograniczeń.	Wyjaśnienie jednej decyzji w raporcie lub prezentacji; osobny notebook nie jest wymagany.
03A-03B	Kontrakt promptu, JSON, Pydantic i walidacja.	Przypadki poprawnego i błędnego wyniku strukturalnego.
04A-04B	Rejestr REGISTRY, dispatch(), decyzja lokalnego modelu, natywne wywołanie funkcji Gemini i budżet pętli.	Testy narzędzi, ślad wywołania i bezpieczne zakończenie.
05A-05B	Embeddingi, FAISS, fragmenty, BM25/RRF i wcześniej ustalony zestaw pytań.	Ranking oraz Recall@k/MRR z opisanym mianownikiem.
06A-06B	Odpowiedź ze źródłami, abstencja, ewaluacja, testy granic i endpoint RAG.	Raport end-to-end, odpowiedź /ask i test regresyjny.
07A-07B	Odpowiedzialna AI i przepływy wielu ról jako osobne tematy.	Ćwiczenia na zajęciach; bez obowiązkowego artefaktu projektowego.

Co oddać?

• Repozytorium z kodem, demonstracyjnym zbiorem dokumentów, zestawem pytań i testami.
• README.md z kolejnością instalacji, konfiguracji, uruchomienia obu trybów LLM, agenta oraz interfejsu RAG; działające przykładowe pytania i oczekiwane statusy.
• .env.template bez wartości kluczy oraz requirements.txt lub plik zależności z odtwarzalnymi wersjami.
• Raport wyszukania i RAG (CSV/JSON/Markdown), krótkie wnioski, co najmniej jeden test regresyjny oraz proste logi lub podsumowanie liczby sukcesów i błędów.
• Krótki diagram albo opis przepływu i demo: obliczenie, odpowiedź z dokumentu, odrzucona próba.
• Zrzut ekranu potwierdzający ukończenie kursu IBM SkillsBuild „UMCS – Large Language Models”.

Progi ocen

Najpierw sprawdzamy warunek IBM SkillsBuild i to, czy da się zweryfikować wymagania podstawowe. Następnie liczymy punkty, premie i ewentualny limit wyniku za nierozwiązaną podatność krytyczną. Premie nie zastępują warunków formalnych.

Ocena	Punkty i warunek
5,0 (bardzo dobry)	90-100 pkt i brak nierozwiązanego błędu krytycznego.
4,5 (dobry plus)	85-89 pkt.
4,0 (dobry)	75-84 pkt.
3,5 (dostateczny plus)	65-74 pkt.
3,0 (dostateczny)	55-64 pkt, wymagania podstawowe można sprawdzić, brak nierozwiązanego błędu krytycznego.
2,0 (niedostateczny)	Poniżej 55 pkt albo niespełniony warunek formalny; nierozwiązany błąd krytyczny ogranicza wynik do 54 pkt.

---