Prompt engineering dla zaawansowanych — techniki, które realnie podnoszą jakość

Zanim zaczniesz: podstawy muszą siedzieć

Ten tekst zakłada, że znasz strukturę dobrego promptu (cel, kontekst, format, przykład) z poradnika podstaw i kompletnego przewodnika po prompt engineeringu. Techniki poniżej to dźwignie, które przy dobrych podstawach dają największy wzrost jakości — a przy złych tylko maskują problem.

1. Few-shot: pokazuj, nie opisuj

Zamiast rozbudowywać opis wymagań, pokaż 2–5 wzorcowych par wejście→wyjście. Model uogólnia z przykładów zaskakująco wiernie — styl, długość, strukturę, poziom szczegółu.

Praktyka: dobieraj przykłady różnorodne (w tym jeden brzegowy), utrzymuj identyczny format wszystkich par i pilnuj jakości — model skopiuje także Twoje błędy. Few-shot to najtańsza technika o największym zwrocie przy zadaniach powtarzalnych: klasyfikacji, ekstrakcji danych, pisaniu w określonym stylu.

2. Rozumowanie krok po kroku — tam, gdzie jest co rozumować

Przy zadaniach logicznych, obliczeniowych i wieloetapowych poproś model, by najpierw rozpisał tok rozumowania, a dopiero potem podał wynik (technika chain-of-thought). W nowszych modelach z trybami „rozszerzonego myślenia” jawne wymuszanie bywa zbędne — ale nadal warto oddzielać w odpowiedzi analizę od konkluzji, bo łatwiej wychwycisz, gdzie rozumowanie skręciło.

Pułapka: przy zadaniach czysto kreatywnych lub trywialnych wymuszony łańcuch kroków potrafi usztywnić odpowiedź i podnieść koszty bez zysku jakości.

3. Dekompozycja: jeden prompt ≠ jedno wielkie zadanie

Złożone zadanie („przeanalizuj raport, wyciągnij ryzyka, napisz rekomendacje i mail do zarządu”) rozbij na sekwencję promptów, gdzie wynik jednego jest wejściem następnego. Zyskujesz kontrolę jakości między etapami i możliwość poprawienia jednego ogniwa bez psucia reszty. To dokładnie ta sama zasada, na której opierają się agenci AI i pipeline’y multi-agent — tyle że sterujesz nią ręcznie.

4. Ustrukturyzowane wyjście

Gdy wynik ma trafić do dalszego przetwarzania (arkusz, kod, automatyzacja w Zapierze), wymuś format: podaj schemat JSON z nazwami i typami pól albo szablon tabeli, dodaj „zwróć wyłącznie JSON, bez komentarzy” i jeden przykład poprawnego wyjścia. W API korzystaj z natywnych trybów structured output / function calling — są pewniejsze niż sama prośba w prompcie.

5. Role, ograniczenia i anty-instrukcje

Rola („jesteś redaktorem technicznym…”) ustawia rejestr i kryteria oceny, ale działa najlepiej w parze z ograniczeniami: co ma być pominięte, czego nie wolno zakładać, jak traktować braki danych („jeśli czegoś nie wiesz — napisz NIE WIEM, nie zgaduj”). Ta ostatnia anty-instrukcja to najprostszy hamulec na halucynacje w zadaniach faktograficznych.

6. Samokrytyka i drugi przebieg

Poproś model o ocenę własnej odpowiedzi względem listy kryteriów i poprawienie jej: „sprawdź wynik pod kątem X, Y, Z; wypisz problemy; podaj wersję poprawioną”. Dwa przebiegi kosztują więcej, ale przy tekstach ważnych (oferty, dokumentacja, analizy) różnica bywa wyraźna. W wariancie mocniejszym krytykę robi osobny prompt z rolą recenzenta — zalążek wzorca wykonawca–krytyk.

7. Parametry: temperatura ma znaczenie

Jeśli korzystasz z API, dopasuj temperaturę do zadania: nisko dla ekstrakcji, klasyfikacji i kodu (powtarzalność), wyżej dla brainstormingu i wariantów kreatywnych. Trzymanie jednej wartości „na wszystko” to cichy zabójca jakości.

Jak testować techniki jak inżynier

Załóż mały zestaw ewaluacyjny: 20–50 realnych wejść + oczekiwane wyniki. Każdą zmianę promptu przepuszczaj przez cały zestaw i porównuj wyniki (może być ręcznie w arkuszu). Dwie zasady: zmieniaj jedną rzecz naraz i zapisuj wersje promptów jak kod. Bez ewaluacji prompt engineering to anegdoty; z nią — inżynieria.

Gdy prompt ustabilizuje się na tyle, że korzysta z niego cały zespół, naturalnym następnym krokiem jest przeniesienie go do skilla w pliku SKILL.md — wersjonowanego w repozytorium i wczytywanego przez agenta dopiero wtedy, gdy jest potrzebny.