Inżynieria promptów w produkcji: jak testować zmiany?
Tłumaczenie automatyczne
Ten artykuł został automatycznie przetłumaczony z angielskiego oryginału.
Zdefiniuj poprawne wyniki, zbierz reprezentatywne przypadki i porównaj jedną zmianę promptu ze stałym wariantem bazowym. Popraw instrukcję, przykłady lub dostarczony kontekst zgodnie z zaobserwowanym błędem. Zachowaj oddzielny zbiór testowy, aby sprawdzić, czy zmiana działa również poza przykładami użytymi do jej opracowania.
Prompt produkcyjny musi obsługiwać niekompletne, niejednoznaczne i nieprawidłowe dane wejściowe, a także zwykłe zapytania.
Zamień błędy w przypadki testowe
Załóżmy, że model wyodrębnia pola z faktur. Uwzględnij zwykłe faktury, brakujące wartości, nieznane układy, sprzeczne daty i dokumenty, które nie są fakturami. Zanim zmienisz prompt, określ, jak system powinien obsłużyć każdy przypadek.
| Błąd | Zmiana do porównania | Kontrola |
|---|---|---|
| Brak wymaganego pola | Doprecyzuj pole i dodaj odpowiedni przykład | Pole jest obecne, gdy potwierdza je źródło |
| Zmyślona wartość | Określ zachowanie przy braku wartości i dostarcz dowody | Pole bez potwierdzenia pozostaje puste |
| Nie można sparsować odpowiedzi | Użyj obsługiwanego schematu wyjściowego | Parser akceptuje całą odpowiedź |
| Poprawna wartość z niewłaściwego źródła | Zachowaj tożsamość źródła w kontekście | Wartość pochodzi ze wskazanego dokumentu |
Dane wyjściowe ograniczone schematem mogą rozwiązać problemy ze składnią. Dokumentacja ustrukturyzowanych danych wyjściowych vLLM opisuje obsługiwane ograniczenia. Poprawny obiekt JSON nadal może zawierać błędną datę lub niepotwierdzone twierdzenie, dlatego waliduj wartości oddzielnie.
Zachowaj możliwość interpretacji porównania
Podczas testowania zmiany promptu utrzymuj stałe: wersję modelu, ustawienia dekodowania, dane źródłowe, definicje narzędzi i limity wyników. Zapisuj jakość, kategorie błędów, liczbę tokenów i opóźnienie. Powtarzaj przypadki niedeterministyczne dostatecznie często, aby sprawdzić, czy poprawa się utrzymuje.
Przykłady few-shot powinny obejmować rzeczywiste zróżnicowanie, w tym niekompletne lub niejednoznaczne dane wejściowe. Dodawaj je w odpowiedzi na zmierzony problem, zamiast zakładać, że więcej przykładów zawsze pomaga. Pozycja w kontekście również może mieć znaczenie: Lost in the Middle wykazało nierównomierne wykorzystanie dowodów w zależności od ich pozycji w testowanych modelach i zadaniach.
Stosuj jawne etapy, gdy ułatwiają wyizolowanie błędu, ale uwzględnij dodatkowe wywołania i interfejsy w porównaniu. Egzekwuj uprawnienia i inne obowiązkowe reguły aplikacji w kodzie; sam komunikat systemowy nie może ich zagwarantować.
Sekcja o promptach produkcyjnych w przewodniku po inżynierii LLM wyjaśnia główne techniki i ich ograniczenia.