Jak ulepszyć prompt: 7 zmian, które podnoszą trafność — z porównaniem przed/po i checklistą 10 punktów 

Prompt to instrukcja, którą dajesz modelowi językowemu. Trafność jej odpowiedzi zależy nie tyle od samego pytania, co od tego, jak je zbudujesz. W praktyce najwięcej zmieniają drobne, powtarzalne modyfikacje: nadanie roli, dorzucenie przykładów, oddzielenie instrukcji od danych, zamiana zakazu na polecenie, przełożenie pytania na koniec.

Poniżej siedem takich zmian. Każdą opisuję z konkretnym przykładem „przed” i „po”, a na końcu zostawiam checklistę dziesięciu punktów, którą możesz przejść przed każdym ważnym promptem. Wszystko opiera się na zaleceniach dokumentacji Anthropic i OpenAI dotyczących pisania promptów oraz na metodach mierzenia jakości odpowiedzi, które stosuję przy wdrożeniach u klientów.

Czym właściwie jest trafność promptu

Zanim poprawisz cokolwiek, musisz umieć powiedzieć, po czym poznasz, że odpowiedź jest dobra. Bez tego dopracowywanie promptu sprowadza się do losowania wariantów i liczenia, który brzmi lepiej. Dokumentacja Anthropic zaczyna od tego wprost: zanim zaczniesz pracę nad promptem, potrzebujesz trzech rzeczy - jasnej definicji kryteriów sukcesu, sposobu na ich empiryczne sprawdzenie i pierwszej wersji promptu, którą chcesz poprawić. Jeśli tego nie masz, najpierw to zrób.

Kryteria sukcesu dobrze się sprawdzają w formie mierzalnych progów. Przykład z dokumentacji: model analizujący nastawję wypowiedzi ma osiągnąć wynik F1 co najmniej 0,85 na zbiorze 10 tysięcy zróżnicowanych wpisów, co daje poprawę o 5% względem obecnego punktu odniesienia. Do tego dokłada się próg toksyczności poniżej 0,1% odpowiedzi w 10 tys. prób oraz czas odpowiedzi poniżej 200 milisekund w 95% przypadków.

Tego typu progi wyglądają surowo, ale są tanie do utrzymania. W praktyce firmowej częściej wystarcza skala od 1 do 5, gdzie 1 oznacza „kompletnie niepoprawnie”, a 5 „idealnie logicznie”, plus jedno pytanie kontrolne, której odpowiedzi nie wolno pominąć. Ten sam mechanizm działa w obie strony: możesz nim oceniać odpowiedź modelu, a możesz nim wymagać samodzielnej kontroli przed zakończeniem zadania.

Zmiana 1: nadaj rolę i wytłumacz, dlaczego to ważne

Model traktuj jak bardzo zdolnego, ale świeżo zatrudnionego pracownika, który nie zna Twoich zwyczajów ani procesów. Nie wie, czym jest „raport miesięczny” w Twojej firmie ani jak go zwykle dostajesz. Im dokładniej opiszesz, czego oczekujesz, tym lepsza odpowiedź. Jedno zdanie robi już różnicę - na przykład „Jesteś asystentem programistycznym specjalizującym się w Pythonie” zawęża zachowanie i ton modelu, zanim napiszesz jeszcze cokolwiek innego.

Druga połowa tej zmiany bywa ważniejsza. Zamiast rozkazu bez powodu podaj przyczynę. Dokumentacja podaje prosty kontrast: „NIGDY nie używaj wielokropka” to instrukcja, którą model wykonuje bez rozumienia powodu; „Twoja odpowiedź będzie czytana na głos przez syntezator mowy, więc nie używaj wielokropka, bo syntezator nie będzie wiedział, jak go wymówić” to ta sama instrukcja z kontekstem. Model jest na tyle inteligentny, żeby uogólnić regułę z wyjaśnienia - i przy okazji zrozumie, dlaczego dane ograniczenie w ogóle istnieje.

Nie każdy prompt potrzebuje obu elementów. Instrukcja bez kontekstu wystarczy przy prostych, powtarzalnych zadaniach. Rozbudowany opis ma sens wtedy, gdy to samo zlecenie wraca co tydzień i za każdym razem ktoś musi tłumaczyć modelowi, o co chodzi.

Zmiana 2: pokaż 3-5 przykładów zamiast opisywać

Przykłady to najbardziej przewidywalne narzędzie do sterowania formatem, tonem i strukturą odpowiedzi. Kilka dobrze zbudowanych przykładów, znanych jako few-shot, poprawia dokładność i powtarzalność wyniku. Dokumentacja podaje konkretną liczbę: 3 do 5 przykładów daje najlepsze efekty.

Trzy przykłady wystarczą, bo chodzi o pokazanie wzorca, a nie o wyczerpanie wszystkich wariantów. Przykłady powinny być trzech rodzajów naraz. Po pierwsze niech powtarzają Twoje realne zadanie, a nie jakiś wyidealizowany scenariusz. Po drugie obejmują przypadki brzegowe, żeby model nie wyuczył się jednego schematu i nie stosował go wszędzie. Po trzecie opakowane są w znaczniki, np. <przykład>, żeby model odróżnił dane od instrukcji.

Przykłady zastępują długie opisy. Zamiast pisać „piszemy potemki w tonie formalnym, bez emotikonów, zawsze zaczynając od zwrotu grzecznościowego, w drugim akapicie podajemy termin”, możesz pokazać jeden gotowy potek i powiedzieć „napisz kolejny w tym samym stylu”. W przypadku dużych dokumentów przykłady działają też jako narzędzie: możesz poprosić model, żeby najpierw wypisał cytaty z dokumentów pasujące do zadania, a dopiero potem wykonał samo zadanie. Dzięki temu skupia się na fragmentach, które naprawdę mają znaczenie.

Dobry zestaw przykładów to też odpowiedź na pytanie „dlaczego to działa”. Model nie musi zgadywać Twojej konwencji - widzi ją w działaniu. Jeśli zaczniesz budować własną bibliotekę, warto trzymać ją w jednym miejscu, tak jak z podstawowymi elementami dobrego promptu.

Zmiana 3: oddziel instrukcję od danych własnymi znacznikami

Gdy w prompcie mieszczą się instrukcje, dane źródłowe i przykłady, model zaczyna je ze sobą mieszać. Rozwiązanie jest techniczne, ale proste: każdy rodzaj treści zawiń w osobny znacznik. Dokumentacja używa w swoich przykładach <instrukcje>, <kontekst> i <wejscie>. Nazwy znaczników powinny być spójne w obrębie całej aplikacji, a zagnieżdżone tam, gdzie dane mają naturalną hierarchię, np. pojedyncze dokumenty w <dokument indeks="1"> wewnątrz <dokumenty>.

Ta zmiana robi największą różnicę przy danych powyżej około 20 tysięcy tokenów, czyli przy dużych dokumentach i wejściach bogatych w treść. Wtedy struktura promptu przestaje być kwestią estetyki, a zaczyna decydować o tym, czy model w ogóle trafi w odpowiedź.

Druga strona tej samej zasady: znaczniki działają też jako wymuszacz formatu wyjścia. Zamiast zakazywać markdownu, możesz napisać „sekcje prozę pisz w znacznikach <akapity_prozy>”. Model traktuje własny tag jako instrukcję struktury, a nie jako prośbę, którą można zignorować.

Zmiana 4: zamień zakaz na polecenie

Negacje trudno egzekwować, bo model musi zgadywać, czego zakaz dotyczy. „Nie używaj markdownu” zostawia otwarte, czy chodzi o listy, tabele, nagłówki, czy pogrubienia. Pozytywna instrukcja zamyka temat: „Twoja odpowiedź ma składać się z płynnych akapitów prozy”. Dokumentacja podaje dokładnie tę parę jako zalecenie.

Ten sam mechanizm działa przy czasownikach. „Czy mógłbyś zasugerować zmiany, które poprawią tę funkcję?” skutkuje sugestiami, bo tak brzmi prośba. „Zmień tę funkcję tak, żeby była szybsza” skutkuje zmianami, bo model czyta to jako polecenie wykonania. To subtelna różnica, ale zmienia wynik z listy propozycji na gotowy kod.

Warto to zapamiętać jako ogólną regułę: jeśli po napisaniu promptu model często „tylko sugeruje”, sprawdź, czy nie napisałeś w nim czasownika, który brzmi jak prośba. Zmiana trzech słów potrafi przełączyć zachowanie.

Zmiana 5: dane na górę, pytanie na koniec

Kolejność ma znaczenie bardziej, niż sugeruje intuicja. Dokumentacja zaleca umieszczać długie dokumenty i dane wejściowe na początku promptu, a zapytanie, instrukcje i przykłady przenieść na koniec. Poprawia to działanie wszystkich modeli. Do tego osobno: umieszczenie pytania na samym końcu poprawiało jakość odpowiedzi nawet o 30% w testach, szczególnie przy złożonych wejściach obejmujących kilka dokumentów.

To najtańsza zmiana z całej listy, bo nic nie dokładasz - tylko przesuwasz. Prompt, który działał, przestaje działać, jeśli pytanie wpadnie w środek danych i model zacznie czytać je jako fragment dokumentu.

Ten sam mechanizm wyjaśnia, dlaczego długie wejścia potrzebują wcześniejszego ustalenia ról. Gdy wiesz, że czekasz na analizę kilku dokumentów, warto od razu zaprojektować prompt pod ten scenariusz, a nie doklejać instrukcji na końcu gotowego szablonu.

Zmiana 6: opisz, jak ma wyglądać wynik i czym się sprawdzi

Model domyślnie odpowiada tak, jak wypada rozmowa. Żeby dostał wynik nadający się do dalszego użycia, trzeba mu powiedzieć, jaki ma mieć kształt. Dokumentacja Anthropic wskazuje tu funkcję structured outputs, zaprojektowaną po to, żeby odpowiedź modelu trzymała się zadanego schematu. Nowsze modele potrafią wiernie dopasować się do rozbudowanej struktury, jeśli się ich o to poprosi, szczególnie gdy dołoży się obsługę ponowień przy niezgodności.

Równolegle warto podać kryterium, według którego model ma sprawdzić własną pracę. W formie „zanim zakończysz, zweryfikuj odpowiedź względem kryterium X” działa to szczególnie dobrze przy zadaniach programistycznych i matematycznych. Jest jednak jeden wyjątek: część najnowszych modeli weryfikuje się sama, a instrukcje weryfikacyjne przeniesione z promptów pisanych pod starsze wersje powodują nadmierną weryfikację, która dokłada tokeny i opóźnienie. W takim wypadku instrukcję usuwa się, zamiast przepisywać.

Tę samą logikę warto stosować do decyzji o myśleniu. Myślenie wieloetapowe poprawia odpowiedzi wymagające rozumowania, ale wnosi opóźnienie. Dokumentacja jest w tym miejscu jednoznaczna: jeśli masz wątpliwość, odpowiadaj wprost.

Zmiana 7: skróć prompt, który już działa

Paradoks promptowania polega na tym, że ta sama dokumentacja, która zaleca dodawać kontekst i przykłady, równocześnie ostrzega przed nadmiernym instruowaniem. Powody są czysto techniczne: narzędzia, które w starszych modelach za rzadko się aktywowały, w nowszych działają bez podpychania. Instrukcje w rodzaju „w razie wątpliwości użyj tego narzędzia” prowadzą do odwrotności, czyli do nadmiernego używania.

Ten sam mechanizm dotyczy gotowych odpowiedzi. Starsze wersje modeli wymagały podpowiedzi zanim zaczęły odpowiadać, i to dlatego powstał zwyczaj wstępnego wypełniania odpowiedzi. Nowsze modele tego nie obsługują - wysłanie takiego żądania kończy się błędem 400. Jeśli Twój prompt zawiera taki mechanizm, nie ma go naprawić lepszym sformułowaniem, trzeba go usunąć.

Praktyczna reguła: po poprawieniu promptu wróć do niego po kilku tygodniach i wytnij zdania, których model i tak nie potrzebuje. Każde usunięte ograniczenie to mniej rzeczy, o które model może się potknąć, i krótszy przebieg.

Porównanie: jeden prompt przed siedmioma zmianami

Zbierzmy to w całości. Zadanie: przygotowanie oferty PDF na podstawie danych z CRM. Wersja wyjściowa brzmi: „Zrób mi ofertę z CRM dla klienta”. Poprawiamy ją po kolei.

Po zmianie 1 dodajemy rolę i powód: „Jesteś asystentem handlowym. Oferta ma być gotowa do wysłania bez redakcji, bo klient czeka na nią do końca dnia”. Po zmianie 2 dorzucamy dwa przykłady ofert z poprzednich miesięcy, opakowane w znaczniki <przykład>. Po zmianie 3 rozdzielamy dane wejściowe od instrukcji: dane z CRM w <dane_crm>, instrukcje w <instrukcje>. Po zmianie 4 zamieniamy zakaz „nie dodawaj nic od siebie” na polecenie „korzystaj wyłącznie z pozycji z sekcji <dane_crm>; jeśli którejś brakuje, wypisz ją w sekcji <braki>”. Po zmianie 5 przenosimy pytanie na sam koniec. Po zmianie 6 opisujemy wynik: „zwróć dokument zgodny ze schematem ofertowym, zawierający pozycje, sumę netto, stawkę VAT i termin ważności”, plus kryterium kontrolne. Po zmianie 7 usuwamy wszystkie instrukcje, które zostały dodane tylko dlatego, że starszy model ich potrzebował.

Efekt jest porównywalny tylko na konkretnym zadaniu, nie na wyczuciu. Dlatego punkt siedmy powinien iść w parze z pomiarem: przy wdrożeniach testuję kilka wariantów promptu na tym samym zestawie danych i porównuję wyniki obiektywnie, zamiast ufać wrażeniu, że nowa wersja „brzmi lepiej”. Sposób doboru próbek opisuję niżej, a szerszy kontekst - jak mierzyć jakość odpowiedzi modelu w firmie - znajdziesz w artykule o halucynacjach i testach na 100 promptach.

Checklista 10 punktów przed wysłaniem promptu

Przejdź tę listę przy każdym promptu, który ma trafić do klienta albo do procesu automatycznego. Kilka punktów to świadomy kompromis - przy jednorazowych pytaniach część z nich to przerost formy nad treścią.

1. Wiem, co oznacza „dobra odpowiedź” w tym zadaniu - mam próg, a nie tylko wrażenie.
2. Model wie, w jakiej roli odpowiada, a instrukcja ma uzasadnienie.
3. Dane i instrukcje rozdzielone znacznikami, a długie wejścia są na górze.
4. Przykłady, jeśli je podałem, pokazują moje realne zadanie i obejmują przypadki brzegowe.
5. Zakazy zastąpione poleceniami, w formie pozytywnej.
6. Czasowniki mówią „zrób”, a nie „zaproponuj”, jeśli oczekuję wykonania.
7. Format wynobu opisany jednoznacznie, najlepiej ze schematem.
8. Pytanie stoi na końcu promptu, po danych i instrukcjach.
9. Nie ma mechanizmów przestarzałych ani nadmiarowych ograniczeń z czasów starszych modeli.
10. Mam sposób sprawdzenia wyniku - i wiem, kiedy lepszy będzie inny model albo inne narzędzie, a nie kolejna iteracja promptu.

Ostatni punkt wymaga uczciwości. Nie każdy problem rozwiązuje się poprawą promptu. Przy obniżaniu kosztów albo czasu odpowiedzi często skuteczniejsze bywa przełączenie na tańszy model, a przy złożonych zadaniach - rozbicie procesu na osobne wywołania po jednym aspekcie. Sama dokumentacja Anthropic zaleca, żeby szukać najprostszego rozwiązania, i wprost zaznacza, że nie zawsze warto budować rozbudowane systemy. Przy własnym wdrożeniu agenta na benchmarku programistycznym więcej czasu zajęło ulepszanie narzędzi niż samego promptu.

Kiedy prompt przestaje wystarczać

Z czasem okazuje się, że jeden prompt obsługuje dwa zupełnie różne typy zapytań i każdemu szkodzi. To nie jest problem długości, tylko dopasowania. Rozwiązanie nazywa się routingiem: wejście jest klasyfikowane i kierowane do specjalizacyjnej gałęzi promptu. Dokumentacja opisuje to wprost - optymalizacja pod jeden typ wejścia pogarsza wyniki dla innych. To powód, dla którego buduję osobne prompty pod typy zapytań zamiast jednego z długą listą wyjątków, zamiast tłumaczyć klientowi, czemu „działa, ale inaczej”.

Dalszym krokiem jest rozłożenie zadania na osobne wywołania, z których każde zajmuje się jednym aspektem, oraz łańcuchowanie, w którym jedno wywołanie przetwarza wynik poprzedniego. Oba wzorce zamieniają trudne zadanie na serię łatwiejszych, kosztem czasu. To decyzja architektoniczna, a nie kwestia lepszego sformułowania.

Takie prompty rzadko żyją w jednym dokumencie. W praktyce trafiają do automatyzacji, gdzie ich treść jest jednym z elementów przepływu. Jeśli dojdzie do miejsca, w którym odpowiedź modelu musi trafić do systemu sprzedażowego albo do raportu, warto przemyśleć całą ścieżkę, nie tylko treść promptu - jak to zrobiłem przy podłączaniu modelu do n8n i automatyzacji ofertowania z CRM.

Trzy techniki warto zapamiętać, nawet jeśli reszty nie ruszysz: trzy do pięciu przykładów, pytanie na końcu promptu i kryterium sukcesu zdefiniowane przed pisaniem instrukcji. Pozostałe mają znaczenie wtedy, gdy prompt zacznie pracować regularnie i bez Twojego nadzoru.