Iteracja promptów: jak testować i ulepszać prompt

Pierwsza wersja promptu to szkic. Często daje coś bliskiego temu, czego chcesz, a lukę między "blisko" a "dobrze" zamyka iteracja: celowa zmiana promptu, ponowne uruchomienie na tym samym wejściu i sprawdzenie, czy zmiana pomogła. Robiona niedbale, iteracja zamienia się w losowe przeformułowywanie, aż jeden szczęśliwy wynik wygląda dobrze. Robiona jako mały eksperyment daje prompt, który działa na następnych stu wejściach, a nie tylko na tym jednym przetestowanym.

Metoda ma pięć kroków: ustal, jak wygląda dobry wynik, trzymaj stałe wejścia testowe, zmieniaj jedną rzecz naraz, porównuj wyniki i wiedz, kiedy przestać.

Ustal, jak wygląda dobra odpowiedź

Zanim cokolwiek zmienisz, zapisz, co wynik musi robić, w postaci sprawdzeń z odpowiedzią tak albo nie. "Dobrej wiadomości commita" nie da się sprawdzić. Tego już tak:

1. Linia tematu ma mniej niż 50 znaków.
2. Stosuje format Conventional Commits (fix:, feat: i tak dalej).
3. Treść mówi, dlaczego zmiana była potrzebna, a nie to, co już pokazuje diff.
4. Wspomina numer zgłoszenia, jeśli taki jest.

Kryteria pełnią dwie funkcje. Mówią ci, co dodać do promptu, bo każde z nich to często brakujące polecenie. I powstrzymują cię przed ocenianiem wyników po tym, jak przyjemnie brzmią, a to najprostszy sposób, żeby zaakceptować pewną siebie, ale błędną odpowiedź.

Trzymaj mały zestaw wejść testowych

Wybierz od trzech do dziesięciu wejść i nie zmieniaj ich w trakcie pracy. Uwzględnij typowe przypadki, kilka niewygodnych (puste pole, bardzo długie wejście, język, którego prompt się nie spodziewa) i każde wejście, które wcześniej zawiodło. Prompt dostrojony do jednego przykładu zwykle pasuje do tego przykładu i zawodzi na następnym.

Zapisz prompt jako szablon z miejscem na wejście, żeby każda wersja działała na dokładnie tym samym materiale.

Zmieniaj jedną rzecz naraz

Gdy zmieniasz jednocześnie rolę, format i przykłady, a wynik się poprawia, nie wiesz, która zmiana to sprawiła, i możesz zachować dwie bezużyteczne poprawki. Zmień jedną rzecz, uruchom, porównaj. Poniższe zakładki to trzy wersje jednego promptu, każda różni się od poprzedniej jedną zmianą.

Wersja 1Wersja 2Wersja 3

EditCopy

Napisz wiadomość commita dla tego diffa.- if len(password) > 8: + if len(password) >= 8: return True

Try it

Example replyReplies vary between models and runs.

Aktualizacja walidacji długości hasła

Ten commit aktualizuje logikę walidacji hasła, zmieniając operator porównania z > na >=. W efekcie hasła mające dokładnie 8 znaków będą teraz uznawane za poprawne. Ta zmiana poprawia dokładność walidacji i zapewnia lepsze doświadczenie użytkownikom zakładającym konta.

Wersja 1 nie spełnia kryteriów 2 i 3: temat nie ma prefiksu typu, a treść opowiada diff większą liczbą słów. Wersja 2 dodaje wymagania dotyczące formatu i spełnia kryteria 1 i 2, ale jej treść nadal opisuje diff. Oczywistą kolejną poprawką byłoby następne polecenie ("wyjaśnij dlaczego"), ale model nie wyjaśni powodu, którego nigdy nie dostał. Wersja 3 dodaje zamiast tego brakujący kontekst i treść oraz odwołanie do zgłoszenia pojawiają się bez proszenia. To najczęstsza lekcja z iteracji: gdy polecenie nie naprawia wyniku, promptowi zwykle brakuje informacji, a nie nacisku.

Porównuj wyniki obok siebie

Uruchom każdą wersję na każdym wejściu testowym, i to więcej niż raz, bo modele czatowe losują słowa i dwa uruchomienia tego samego promptu się różnią. Postaw wyniki obok siebie i sprawdzaj je według kryteriów, a nie według tego, jak pamiętasz poprzednie uruchomienie.

Przy precyzyjnych kryteriach pierwszą ocenę może wykonać drugie wywołanie modelu. Wklej wyniki do promptu oceniającego z wypisanymi kryteriami:

Oceń wyniki według stałych kryteriów

EditCopy

Fill inkryteria

Sprawdź każdy z poniższych wyników pod kątem kryteriów. Dla każdego kryterium odpowiedz zaliczone albo niezaliczone z krótkim uzasadnieniem cytującym wynik. Oceniaj tylko wymienione kryteria. Nie nagradzaj długości ani stylu. Kryteria: 1. Linia tematu poniżej 50 znaków. 2. Zgodność z Conventional Commits. 3. Treść mówi, dlaczego zmiana była potrzebna, a nie to, co pokazuje diff. 4. Wspomina numer zgłoszenia. Wynik A: """ fix: akceptuj hasła mające dokładnie 8 znaków Zmień sprawdzenie długości z > na >=, żeby hasła mające dokładnie 8 znaków przechodziły walidację. """ Wynik B: """ fix: akceptuj hasła mające dokładnie 8 znaków Strona rejestracji wymaga co najmniej 8 znaków, ale sprawdzenie odrzucało hasła o dokładnie takiej długości, więc użytkownicy postępujący zgodnie z instrukcją nie mogli się zarejestrować. Fixes #412 """ Odpowiedz w formie tabeli z jednym wierszem na kryterium.

Try it

Example replyReplies vary between models and runs.

Kryterium	Wynik A	Wynik B
1. Temat poniżej 50 znaków	Zaliczone: temat ma 45 znaków	Zaliczone: ten sam temat, 45 znaków
2. Conventional Commits	Zaliczone: zaczyna się od "fix:"	Zaliczone: zaczyna się od "fix:"
3. Treść wyjaśnia dlaczego	Niezaliczone: "Zmień sprawdzenie długości z > na >=" powtarza diff	Zaliczone: "użytkownicy postępujący zgodnie z instrukcją nie mogli się zarejestrować"
4. Wspomina zgłoszenie	Niezaliczone: brak numeru zgłoszenia	Zaliczone: "Fixes #412"

Traktuj model oceniający jak asystenta, a nie sędziego. Zheng i współautorzy w pracy z 2023 roku "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" udokumentowali skłonności modeli oceniających, w tym preferowanie dłuższych odpowiedzi i odpowiedzi na określonej pozycji. Dbaj o to, żeby kryteria dało się sprawdzić, proś o cytowane dowody, zamieniaj kolejność A i B przy porównywaniu dwóch wyników i część wyników przeczytaj sam. Sprawdzenia takie jak liczenie znaków są pewniejsze jako linia kodu niż jako osąd modelu.

Poprawiaj prompt, a nie rozmowę

W czacie kusi, żeby poprawiać odpowiedź kolejnymi wiadomościami: "krócej", "nie, wspomnij zgłoszenie", "użyj innego formatu". To daje jeden dobry wynik i zostawia prompt tak słaby, jaki był. Gdy poprawka działa, przenieś ją do promptu i uruchom prompt od nowa. Następnym razem, gdy będziesz potrzebować wyniku, wkleisz jedną wiadomość, zamiast powtarzać pięć.

Zachowuj stare wersje z jednolinijkową notką o tym, co się zmieniło i co to naprawiło. Wystarczy zwykły plik tekstowy. Gdy późniejsza poprawka coś pogorszy, możesz wrócić, zamiast próbować sobie przypomnieć, co było wcześniej w prompcie.

Porównanie w kodzie

Gdy prompt działa przez API, krótki skrypt może przygotować widok porównawczy dla każdej wersji i każdego wejścia testowego. Ten korzysta z OpenAI Python SDK i zapisuje plik markdown, który można przeczytać od góry do dołu.

from openai import OpenAI

client = OpenAI()
MODEL = "your-model-id"  # e.g. from your provider's model list

# each prompt file contains {input} where the test diff goes
PROMPTS = {
    "v2": open("prompts/commit_v2.txt").read(),
    "v3": open("prompts/commit_v3.txt").read(),
}
TESTS = [open(f"tests/diff_{i}.txt").read() for i in range(1, 6)]

with open("results.md", "w") as out:
    for i, test in enumerate(TESTS, 1):
        out.write(f"## Test {i}\n\n")
        for name, template in PROMPTS.items():
            for run in (1, 2):
                response = client.chat.completions.create(
                    model=MODEL,
                    messages=[{"role": "user", "content": template.replace("{input}", test)}],
                )
                out.write(f"### {name}, run {run}\n\n{response.choices[0].message.content}\n\n")

Kiedy przestać

Przestań, gdy każde kryterium jest spełnione na każdym wejściu testowym w kilku uruchomieniach. Dodawanie czegoś więcej po tym momencie głównie wydłuża prompt, a każde dodatkowe polecenie to kolejna rzecz, która może kłócić się z pozostałymi.

Przestań też, gdy zmiany zaczynają wymieniać jedne błędy na inne: jedna poprawka naprawia test 2 i psuje test 4, następna to odwraca. Taki wzorzec oznacza, że od promptu oczekuje się czegoś, czego jedno polecenie nie jest w stanie ustalić. Zwykłe wyjścia to pokazanie formatu na kilku przykładach (few-shot prompting), podzielenie pracy na kroki za pomocą prompt chaining albo przeniesienie deterministycznych części, takich jak liczenie znaków czy sprawdzanie formatu, do kodu, który sprawdza wynik. Jeśli brakuje ci pomysłów, może pomóc meta prompting: daj modelowi prompt, wejście i zły wynik i zapytaj, która część promptu najpewniej go spowodowała.