Programowanie oparte na ocenie

Podczas tworzenia promptów do rzeczywistych aplikacji pojawia się kluczowy kompromis: równoważenie zwięzłości ze skutecznością. Gdy wszystkie czynniki są równe, zwięzły prompt jest szybszy, tańszy i łatwiejszy w utrzymaniu niż dłuższy prompt. Jest to szczególnie ważne w środowiskach internetowych, w których liczy się opóźnienie i limity tokenów. Jeśli jednak prompt jest zbyt krótki, model może nie mieć wystarczającego kontekstu, instrukcji ani przykładów, aby wygenerować wyniki wysokiej jakości.

Rozwój oparty na ocenie (EDD) umożliwia systematyczne monitorowanie i optymalizowanie tego kompromisu. Oferuje powtarzalny proces, który można testować, aby stopniowo i pewnie ulepszać wyniki, wykrywać regresje i z czasem dostosowywać działanie modelu do oczekiwań użytkowników i produktu.

Możesz o tym myśleć jak o programowaniu sterowanym testami (TDD), dostosowanym do niepewności związanej z AI. W przeciwieństwie do deterministycznych testów jednostkowych oceny AI nie mogą być zakodowane na stałe, ponieważ dane wyjściowe, zarówno prawidłowe, jak i nieprawidłowe, mogą przyjmować nieoczekiwane formy.

Ilustracja 1.: w ramach EDD definiujesz problem, inicjujesz wartość bazową, oceniasz i optymalizujesz. Kontynuuj ocenę i optymalizację, aż proces się zakończy.

EDD pomaga też w procesie pozyskiwania danych. Podobnie jak pisanie testów pomaga wyjaśnić działanie funkcji, określanie kryteriów oceny i sprawdzanie wyników modelu zmusza do zmierzenia się z brakiem jasności i stopniowego dodawania szczegółów oraz struktury do zadań otwartych lub nieznanych.

Określ problem

Możesz sformułować swój problem jako umowę dotyczącą interfejsu API, podając typ danych wejściowych, format danych wyjściowych i wszelkie dodatkowe ograniczenia. Na przykład:

  • Typ danych wejściowych: wersja robocza posta na blogu
  • Format wyjściowy: tablica JSON z 3 tytułami postów
  • Ograniczenia: mniej niż 128 znaków, przyjazny ton

Następnie zbierz przykładowe dane wejściowe. Aby zapewnić różnorodność danych, uwzględnij zarówno idealne przykłady, jak i rzeczywiste, nieuporządkowane dane wejściowe. Zastanów się nad różnymi wariantami i przypadkami brzegowymi, np. postami z emotikonami, zagnieżdżoną strukturą i wieloma fragmentami kodu.

Inicjowanie wartości podstawowych

Napisz pierwszego prompta. Możesz zacząć od zero-shot i uwzględnić:

  • Jasne instrukcje
  • Format wyjściowy
  • Obiekt zastępczy zmiennej wejściowej

Podczas oceny i optymalizacji zwiększasz złożoność i pracujesz z innymi komponentami oraz zaawansowanymi technikami promptowania. Najpierw musimy skonfigurować system oceny, aby ukierunkować działania optymalizacyjne we właściwym kierunku.

Tworzenie systemu oceny

W TDD testy zaczynasz pisać, gdy znasz wymagania. W przypadku generatywnej AI nie ma jednoznacznych wyników, z którymi można by porównać wyniki testów, więc musisz włożyć więcej wysiłku w opracowanie pętli oceny.

Aby skutecznie przeprowadzić ocenę, prawdopodobnie potrzebujesz kilku narzędzi pomiarowych.

Określanie danych oceny

Wskaźniki oceny mogą być deterministyczne. Możesz na przykład sprawdzić, czy model zwraca prawidłowy kod JSON lub czy generuje odpowiednią liczbę elementów.

Większość czasu należy jednak poświęcić na identyfikowanie i dopracowywanie subiektywnych lub jakościowych danych, takich jak przejrzystość, przydatność, ton czy kreatywność. Możesz zacząć od ogólnych celów, ale szybko napotkasz bardziej złożone problemy.

Załóżmy na przykład, że generator tytułów nadużywa pewnych zwrotów lub wzorców, co prowadzi do powtarzalnych, mechanicznych wyników. W takim przypadku należy zdefiniować nowe dane, aby zachęcić do stosowania różnorodnych struktur lub słów kluczowych i zniechęcić do nadużywania tych samych. Z czasem podstawowe dane się ustabilizują i będziesz mieć możliwość śledzenia postępów.

W tym procesie mogą pomóc eksperci, którzy wiedzą, jak wygląda dobry wynik w domenie Twojej aplikacji i potrafią dostrzec subtelne tryby awarii. Jeśli na przykład tworzysz asystenta pisania, nawiąż współpracę z producentem treści lub redaktorem, aby mieć pewność, że Twoja ocena jest zgodna z ich światopoglądem.

Wybierz sędziów

Różne kryteria oceny wymagają różnych oceniających:

  • Sprawdzanie na podstawie kodu dobrze sprawdza się w przypadku wyników deterministycznych lub opartych na regułach. Możesz na przykład skanować tytuły pod kątem słów, których chcesz unikać, sprawdzać liczbę znaków lub weryfikować strukturę JSON. Są one szybkie, powtarzalne i idealne w przypadku elementów interfejsu o stałym wyniku, takich jak przyciski czy pola formularza.
  • Opinie użytkowników są niezbędne do oceny bardziej subiektywnych cech, takich jak ton, przejrzystość czy przydatność. Zwłaszcza na początku sprawdzanie wyników modelu samodzielnie (lub z pomocą ekspertów w danej dziedzinie) umożliwia szybkie wprowadzanie zmian. To podejście nie jest jednak skalowalne. Po uruchomieniu aplikacji możesz też zbierać sygnały w aplikacji, np. ocenę w postaci gwiazdek, ale zwykle są one zaszumione i nie mają niuansów potrzebnych do precyzyjnej optymalizacji.
  • LLM jako sędzia to skalowalny sposób oceny subiektywnych kryteriów za pomocą innego modelu AI, który przyznaje punkty lub krytykuje dane wyjściowe. Jest szybsze niż weryfikacja przez człowieka, ale nie jest wolne od wad: w naiwnej implementacji może utrwalać, a nawet wzmacniać uprzedzenia i luki w wiedzy modelu.

Postaw na jakość, a nie na ilość. W klasycznym uczeniu maszynowym i sztucznej inteligencji predykcyjnej powszechną praktyką jest pozyskiwanie adnotacji do danych od wielu osób. W przypadku generatywnej AI osoby z zewnątrz często nie mają kontekstu domeny. Wysokiej jakości ocena z uwzględnieniem kontekstu ma większe znaczenie niż skala.

Oceniaj i optymalizuj

Im szybciej przetestujesz i dopracujesz prompty, tym szybciej uzyskasz coś, co będzie zgodne z oczekiwaniami użytkowników. Musisz wyrobić sobie nawyk ciągłej optymalizacji. Wprowadź ulepszenie, oceń je i spróbuj czegoś innego.

Po wdrożeniu systemu nadal obserwuj i oceniaj zachowania użytkowników oraz systemu AI. Następnie analizuje i przekształca te dane w kroki optymalizacji.

Automatyzacja potoku oceny

Aby zmniejszyć trudności związane z optymalizacją, potrzebujesz infrastruktury operacyjnej, która automatyzuje ocenę, śledzi zmiany i łączy rozwój z wdrożeniem w środowisku produkcyjnym. Jest to często określane jako LLMOps. Istnieją platformy, które mogą pomóc w automatyzacji, ale przed podjęciem decyzji o skorzystaniu z rozwiązania innej firmy warto zaprojektować idealny przepływ pracy.

Oto kilka kluczowych elementów, które warto wziąć pod uwagę:

  • Wersjonowanie: przechowuj prompty, dane oceny i dane wejściowe testów w systemie kontroli wersji. Traktuj je jak kod, aby zapewnić powtarzalność i czytelną historię zmian.
  • Automatyczne oceny wsadowe: używaj przepływów pracy (np. GitHub Actions) do przeprowadzania ocen przy każdej aktualizacji promptu i generowania raportów porównawczych.
  • CI/CD w przypadku promptów: kontroluj wdrożenia za pomocą automatycznych testów, takich jak testy deterministyczne, oceny LLM-ów jako sędziów lub zabezpieczenia, i blokuj scalanie, gdy jakość się pogorszy.
  • Logowanie i dostrzegalność w środowisku produkcyjnym: rejestruj dane wejściowe, wyjściowe, błędy, opóźnienia i wykorzystanie tokenów. Monitoruj odchylenia, nieoczekiwane wzorce lub nagłe wzrosty liczby błędów.
  • Przetwarzanie opinii: zbieranie sygnałów od użytkowników (kciuki, ponowne pisanie, porzucanie) i przekształcanie powtarzających się problemów w nowe przypadki testowe.
  • Śledzenie eksperymentów: śledź wersje promptów, konfiguracje modeli i wyniki oceny.

Wprowadzaj małe, ukierunkowane zmiany

Ulepszanie promptów zwykle zaczyna się od poprawy języka prompta. Może to oznaczać doprecyzowanie instrukcji, wyjaśnienie intencji lub usunięcie niejasności.

Uważaj, aby nie dopasować modelu do danych w nadmiernym stopniu. Częstym błędem jest dodawanie zbyt wąskich reguł w celu rozwiązania problemów z modelem. Jeśli na przykład generator tytułów ciągle tworzy tytuły zaczynające się od The Definitive Guide, możesz mieć ochotę na wyraźne zakazanie tego wyrażenia. Zamiast tego uogólnij problem i dostosuj instrukcję wyższego poziomu. Może to oznaczać, że kładziesz nacisk na oryginalność, różnorodność lub określony styl redakcyjny, dzięki czemu model uczy się podstawowych preferencji, a nie pojedynczego wyjątku.

Innym sposobem jest eksperymentowanie z większą liczbą technik promptowania i łączenie tych działań. Gdy wybierzesz technikę, zadaj sobie pytanie: czy to zadanie najlepiej rozwiązać za pomocą analogii (few-shot), rozumowania krok po kroku (chain-of-thought) czy iteracyjnego udoskonalania (self-reflection)?

Gdy system przejdzie do produkcji, koło zamachowe EDD nie powinno zwalniać. W każdym razie powinna się ona przyspieszyć. Jeśli Twój system przetwarza i rejestruje dane wejściowe użytkowników, powinny one stać się Twoim najcenniejszym źródłem informacji. Dodawaj do pakietu oceny powtarzające się wzorce i stale identyfikuj oraz wdrażaj najlepsze kolejne kroki optymalizacji.

Wnioski

Opracowywanie promptów na podstawie oceny zapewnia uporządkowany sposób radzenia sobie z niepewnością związaną z AI. Dzięki jasnemu zdefiniowaniu problemu, stworzeniu dostosowanego systemu oceny i wprowadzaniu małych, ukierunkowanych ulepszeń tworzysz pętlę opinii, która stale poprawia wyniki modelu.

Zasoby

Jeśli chcesz wdrożyć LLM jako sędziego, zapoznaj się z tymi materiałami:

Jeśli chcesz jeszcze bardziej ulepszyć prompty, dowiedz się więcej o tworzeniu z uwzględnieniem kontekstu. Najlepiej, aby zrobił to inżynier uczenia maszynowego.

Sprawdź swoją wiedzę

Jaki jest główny cel rozwoju opartego na ocenie?

Zastąpienie wszystkich testów przeprowadzanych przez ludzi zautomatyzowanymi testami jednostkowymi.
To nie jest poprawna odpowiedź.
Aby systematycznie monitorować i optymalizować kompromis między zwięzłością a skutecznością promptów za pomocą powtarzalnego procesu.
Świetnie, zgadza się!
Aby zwiększyć czas oczekiwania aplikacji i zapewnić większą dokładność.
To nie jest poprawna odpowiedź.
Aby mieć pewność, że model przechodzi standardowe testy publiczne, takie jak MMLU.
To nie jest poprawna odpowiedź.

Dlaczego do oceny systemu po stronie klienta warto używać większych modeli?

Większe modele najlepiej sprawdzają się w ocenie tonu i kreatywności.
To nie jest poprawna odpowiedź.
Ręcznie oceniają każdy wynik.
To nie jest poprawna odpowiedź.
Świetnie sprawdzają się w weryfikowaniu deterministycznych wyników, np. struktury JSON lub liczby znaków.
Świetnie, zgadza się!

Jakie jest potencjalne zagrożenie związane z używaniem LLM jako sędziego do oceny?

Jest zbyt wolna w porównaniu z weryfikacją manualną.
To nie jest poprawna odpowiedź.
Nie wymaga konfiguracji ani promptów.
To nie jest poprawna odpowiedź.
Może to utrwalać i wzmacniać uprzedzenia oraz luki w wiedzy modelu.
Świetnie, zgadza się!
Nie może przetwarzać danych wyjściowych w postaci tekstu.
To nie jest poprawna odpowiedź.

Który komponent jest częścią zalecanego automatycznego potoku oceny?

Ręczne kopiowanie i wklejanie promptów do arkusza kalkulacyjnego.
To nie jest poprawna odpowiedź.
Wersjonowanie promptów, danych i danych wejściowych testów jako kodu.
Świetnie, zgadza się!
Usuwanie logów w celu zwolnienia miejsca.
To nie jest poprawna odpowiedź.
ignorowanie opinii użytkowników w celu zachowania spójności;
To nie jest poprawna odpowiedź.

Jakie jest główne ograniczenie korzystania z opinii ludzi przy wyborze oceniających do systemu oceny?

Ludzie nie są w stanie ocenić subiektywnych cech, takich jak ton czy przejrzystość.
To nie jest poprawna odpowiedź.
Jest to w zasadzie to samo co „Sprawdzanie na podstawie kodu”.
To nie jest poprawna odpowiedź.
Zapewnia największą ilość danych, ale najniższą jakość.
To nie jest poprawna odpowiedź.
W porównaniu z metodami automatycznymi nie jest to zbyt efektywne.
Świetnie, zgadza się!