Kiedy po raz pierwszy wdrażaliśmy LLM w środowisku produkcyjnym u klienta z branży wytwórczej, minęły trzy tygodnie, zanim zrozumieliśmy, dlaczego model czasem odpowiada po angielsku zamiast po polsku, dlaczego ignoruje formatowanie i dlaczego w jednym na dziesięć przypadków wymyśla liczbę z powietrza. Wszystkie trzy problemy miały to samo rozwiązanie: systemowe podejście do promptów — nie intuicja, nie metoda prób i błędów, lecz sprawdzona struktura.
Prompt engineering jest dziś jedną z najczęściej wymienianych, a zarazem najsłabiej rozumianych dyscyplin w projektach AI. Kiedy pytamy dyrektorów technicznych, czego od niego oczekują, większość mówi „lepszych odpowiedzi". To prawda — ale tylko do pewnego stopnia. Ten artykuł rozkłada na czynniki pierwsze, co prompt engineering realnie potrafi, gdzie leżą jego granice i co należy do innego zestawu narzędzi.
Czym naprawdę jest prompt engineering
Prompt engineering to systematyczne projektowanie i wersjonowanie danych wejściowych dla modelu językowego w celu uzyskania spójnych, przewidywalnych i mierzalnych wyników. Kluczowe słowo to spójnych — nie „czasem świetnie".
W systemie produkcyjnym nie wystarczy, że prompt działa w 80 % przypadków. Jeśli wdrożysz go do obsługi klienta, te 20 % niepowodzeń klienci zapamiętają. Jeśli wdrożysz go do przetwarzania faktur, 20 % błędów to katastrofa. Prompt engineering jest więc mniej o kreatywności, a bardziej o dyscyplinie inżynierskiej: dokumentowanie, wersjonowanie, testowanie, mierzenie.
Co działa — sprawdzone wzorce
1. Jasna instrukcja z explicite określonym formatem wyjściowym
Największy jednostkowy wpływ na jakość wyniku ma to, jak precyzyjnie model wie, co ma produkować. Ogólnikowa instrukcja „streść ten dokument" daje ogólnikowe wyniki. Konkretna instrukcja działa dramatycznie lepiej:
- Powiedz modelowi, kto jest docelowym odbiorcą wyniku
- Zdefiniuj dokładny format: liczbę punktów, maksymalną długość, czy wynik ma zawierać podsumowanie, czy nie
- Przy danych strukturalnych zawsze używaj structured outputs i trybu JSON — model związany schematem halucynuje znacznie rzadziej niż model z wolnym wyjściem tekstowym
U klientów obserwowaliśmy, że samo przejście od „wyodrębnij dane z faktury" do „zwróć obiekt JSON z polami: dostawca (string), NIP (string 10 cyfr), kwota (liczba), data (ISO 8601)" zmniejszyło błędy ekstrakcji o kilkadziesiąt procent.
2. Przykłady few-shot — kiedy i jak je stosować
Few-shot prompting (kilka przykładów wejście-wyjście bezpośrednio w prompcie) to jedno z najbardziej niezawodnych narzędzi, ale tylko wtedy, gdy przykłady są reprezentatywne. Zasady:
- 1.Przykłady muszą obejmować edge case'y, nie tylko happy path
- 2.Format przykładów musi być spójny — jeśli raz użyjesz „Wejście:", a innym razem „Input:", model to zauważy
- 3.Liczba przykładów zależy od złożoności zadania — do prostej klasyfikacji wystarczą 2–3, do wieloetapowego wnioskowania 5–7
- 4.Przykłady wybieraj z realnych danych, nie wymyślonych — syntetyczne przykłady mają często inne właściwości statystyczne niż dane produkcyjne
Few-shot jest szczególnie silny przy formatowaniu i zadaniach o wyraźnej wzorcowej strukturze. Jest mniej skuteczny przy wiedzy, gdzie modelowi brakuje kontekstu domenowego — tam odpowiedzią jest RAG lub fine-tuning.
3. Rola i persona
Explicite przypisanie roli działa — nie dlatego, że model „uwierzy", iż jest kimś innym, lecz dlatego, że rola przesuwa rozkład prawdopodobieństwa wyników ku bardziej trafnym wzorcom. „Jesteś starszym prawnikiem specjalizującym się w polskim prawie pracy" aktywuje inne wzorce językowe niż „Jesteś asystentem".
Ważne: rola definiuje ton i słownictwo, ale nie zastąpi wiedzy. Model z rolą „ekspert ds. dyrektyw ATEX" nadal może halucynować, jeśli dane treningowe o tych dyrektywach są niewystarczające. Rola jest filtrem językowym, nie bazą wiedzy.
4. Łańcuchowanie kroków (Chain-of-Thought)
Przy złożonych zadaniach analitycznych — porównywanie, wieloetapowe obliczenia, decydowanie według warunków — explicite instrukcja „postępuj krok po kroku" lub podział na wiele sub-promptów znacząco poprawia niezawodność. Modele popełniają mniej błędów, gdy mogą „myśleć na głos" przed ostateczną odpowiedzią.
W praktyce oznacza to: nie proś modelu o wniosek wprost. Pozwól mu najpierw rozłożyć problem, zidentyfikować istotne czynniki, a dopiero potem sformułować wniosek. Wynik jest bardziej niezawodny, a przy okazji łatwiejszy do weryfikacji — widzisz, jak model doszedł do konkluzji.
5. Instrukcje negatywne — czego nie robić
Większość promptów mówi modelowi, co ma robić. Równie ważne jest powiedzenie, czego nie ma robić. „Nigdy nie zaczynaj odpowiedzi od frazy 'Oczywiście!'", „Nie używaj anglicyzmów tam, gdzie istnieje polski odpowiednik", „Jeśli nie możesz odpowiedzieć na podstawie dostarczonego kontekstu, powiedz to explicite — nie dopowiadaj." Instrukcje negatywne ograniczają występowanie konkretnych, powtarzających się błędów.
Co nie działa — mity
Mit 1: „Proszę" i nagrody poprawiają wyniki
Krótka odpowiedź: nie. Zachęty w stylu „za każdą prawidłową odpowiedź otrzymasz 100 dolarów" ani uprzejme „proszę, pomóż mi z..." nie mają mierzalnego wpływu na jakość wyjścia produkcyjnego. Model nie reaguje na manipulację społeczną ani emocje — reaguje na wzorce statystyczne z danych treningowych. Czas spędzony na „motywowaniu" modelu to czas stracony.
Mit 2: Dłuższy prompt = lepszy wynik
Długość i jakość to dwie różne rzeczy. Widzieliśmy systemowe prompty z tysiącami tokenów, które działały gorzej niż pięciolinijkowe. Problem polega na tym, że modele mają tendencję do „gubienia" instrukcji w środku bardzo długiego kontekstu — efekt zwany „lost in the middle". Struktura i jasność są ważniejsze od objętości. Jeśli twój prompt rośnie, to raczej symptom, że próbujesz promptem rozwiązać problem należący do projektu systemu.
Mit 3: Dobry prompt zastępuje eval
To prawdopodobnie najniebezpieczniejszy mit. Prompt bez ewaluacji to hipoteza, nie rozwiązanie. W praktyce widzimy zespoły, które spędzają tydzień na dopracowywaniu promptu, wdrażają go na produkcję i po miesiącu odkrywają, że 15 % wyników jest nieprawidłowych — bo nigdy systematycznie nie mierzyły.
Eval — automatyczna ocena wyników na zbiorze testowym — jest warunkiem koniecznym wdrożenia produkcyjnego, nie opcjonalnym dodatkiem. Więcej o tym, jak mierzyć jakość aplikacji LLM.
Mit 4: Prompt engineering to trwałe rozwiązanie
Prompt jest kruchym artefaktem. Gdy dostawca wyda nową wersję modelu, twój prompt może zachowywać się inaczej — nawet jeśli go nie zmieniałeś. Widzieliśmy przypadki, gdzie aktualizacja modelu poprawiała ogólną jakość, ale psuła konkretne instrukcje formatowania „przyklejone" do zachowania starszej wersji.
Prompt engineering to praca iteracyjna, nie jednorazowa. Jeśli nie uświadomisz sobie tego przed wdrożeniem, uświadomisz sobie to po nim.
Mit 5: System prompt to bezpieczny pojemnik na wrażliwe informacje
System prompt jest dla modelu instrukcją, nie sejfem. Prompt extraction (wydobywanie zawartości system promptu) to dobrze udokumentowany atak — istnieją techniki, którymi atakujący może wyciągnąć zawartość system promptu przez normalne interfejsy użytkownika. Do system promptu nigdy nie należą: hasła, klucze API, wewnętrzne cenniki, dane osobowe pracowników ani żadna informacja, której ujawnienie byłoby problemem. System prompt to miejsce na instrukcje dotyczące zachowania, nie na sekrety.
Prompt jako kod — wersjonowanie i zarządzanie
W zespołach, z którymi współpracujemy, stale pojawia się ten sam problem: prompt jest zapisany w kodzie jako zahardkodowany string, nikt nie wie, kto go ostatnio zmienił i dlaczego, a gdy coś się psuje, nie ma historii, do której można wrócić.
Prompt to kod. Obowiązują te same zasady:
- Wersjonowanie w git — każda zmiana promptu to commit ze znaczącym commit message
- Semantic versioning — major wersja przy zmianie wpływającej na zachowanie wyjścia; minor przy uzupełnieniu; patch przy poprawce ortograficznej
- Zbiór testowy — do każdej wersji promptu istnieje zestaw przypadków testowych z oczekiwanymi wynikami; zmiana promptu przechodzi tylko wtedy, gdy testy są zielone
- Rejestr promptów — centralne miejsce (może to być prosty YAML w repozytorium lub narzędzie jak
Langfuse), gdzie widać, który prompt jest gdzie wdrożony, w jakiej wersji i kto jest właścicielem
Narzędzia takie jak Promptfoo umożliwiają automatyczne testowanie promptów w pipeline CI/CD — każdy pull request z modyfikacją promptu automatycznie uruchamia zbiór testowy przed mergem. To praktyka, którą rekomendujemy każdemu zespołowi mającemu więcej niż jeden aktywny prompt na produkcji.
Kiedy prompt nie wystarcza — i co zamiast niego
Prompt engineering to potężne narzędzie w wąskim paśmie problemów. Jest słaby tam, gdzie:
Brakuje wiedzy — model nie wie tego, co powinien wiedzieć, bo nie ma tego w danych treningowych. Prompt nie może dodać wiedzy. Rozwiązanie: RAG (retrieval-augmented generation) dla wsparcia faktograficznego lub fine-tuning dla głębokiej adaptacji domenowej.
Brakuje spójnego formatu — wynik ma zawsze być zgodny z dokładnym schematem. Prompt może pomóc, ale bardziej niezawodnym rozwiązaniem są structured outputs (schemat JSON związany z modelem). Więcej w artykule o structured outputs i trybie JSON.
Brakuje bezpieczeństwa — jeśli system przetwarza niezaufane dane wejściowe (np. wiadomości od klientów, zewnętrzne dokumenty), prompt injection to realne ryzyko. Sam prompt nie jest w stanie zapobiec własnemu nadpisaniu. Potrzebujesz architektonicznych guardrails — walidacji wejść, allowlist akcji, sandboxingu. Więcej szczegółów w artykule o prompt injection i jailbreakach.
Brakuje pomiaru — jeśli nie wiesz, czy prompt działa, prompt engineering to tylko zgadywanie. Bez evalu nie ufaj nawet doskonałemu promptowi.
Praktyczne wersjonowanie promptów — jak zacząć
Dla zespołów, które nie mają jeszcze systematycznego zarządzania promptami, rekomendujemy prosty proces:
- 1.Utwórz katalog
prompts/w repozytorium z jednym plikiem YAML na prompt - 2.Każdy YAML zawiera:
name,version,description,system_prompt,user_prompt_template,model,temperature,test_cases - 3.Zmiany przez pull request — review promptu tak samo jak review kodu
- 4.Przed wdrożeniem nowej wersji: uruchom zbiór testowy na bieżącej i nowej wersji, porównaj metryki
- 5.Po wdrożeniu: monitoruj wyniki na produkcji; anomalie (nagły wzrost błędów, zmieniona długość wyników) to sygnał regresji
To nie jest overkill — to minimum. Zespoły, które tego nie robią, odkrywają problemy na produkcji zamiast na testach.
Prompt engineering a modele — co się zmienia wraz z modelem
Ważna kwestia, którą często się ignoruje: różne modele reagują na ten sam prompt inaczej. Prompt zoptymalizowany pod jeden model może działać znacznie gorzej na innym. Kilka konkretnych wzorców:
- Instruction following: nowsze frontier modele (klasa Claude, GPT-4) są znacznie lepsze w przestrzeganiu explicite podanych instrukcji niż starsze lub mniejsze modele
- Wrażliwość na few-shot: niektóre modele silnie reagują na przykłady few-shot, inne słabiej — zależy to od rozmiaru i procedury treningowej
- Jakość językowa: język polski ma relatywnie mniej danych treningowych niż angielski; frontier modele radzą sobie z nim dobrze, mniejsze modele open-weight mogą degradować — zawsze testuj w docelowym języku
- Temperature: przy deterministycznych zadaniach (ekstrakcja, klasyfikacja) ustaw
temperature=0lub bardzo nisko — wyniki będą bardziej spójne; przy generatywnych zadaniach (pisanie) nieco wyżej
Gdy zmieniasz model, zawsze uruchamiaj istniejący zbiór testowy. Nie zakładaj, że prompt „działa tak samo".
Najczęstsze pytania
Czy warto inwestować czas w prompt engineering, czy lepiej od razu przejść do fine-tuningu?
Prompt engineering to pierwszy krok, fine-tuning to kolejny — nie alternatywa. Jeśli masz dobrze zaprojektowany prompt i nadal nie jesteś zadowolony z wyników mimo przykładów few-shot i struktury, zbadaj, czy problem nie leży w brakującej wiedzy domenowej (rozwiązanie: RAG) albo w spójności stylu wyjścia (rozwiązanie: fine-tuning). Fine-tuning bez dobrze zaprojektowanego promptu i bez evalu to zmarnowany czas i pieniądze.
Czy mogę użyć prompt engineeringu, żeby model nigdy nie odpowiadał na określone tematy?
Nie niezawodnie. Zabezpieczenia oparte wyłącznie na prompcie (instrukcja „nigdy nie odpowiadaj na X") można obejść — to główny wniosek z badań nad prompt injection i jailbreakingiem. W systemach produkcyjnych konieczne są środki architektoniczne: filtrowanie wejść przed przekazaniem do modelu, walidacja wyjść przed wyświetleniem, monitoring. Instrukcja w prompcie to pierwsza warstwa, nie jedyna.
Skąd wiem, że mój prompt jest dobry?
Jedynie przez pomiar. Zdefiniuj zbiór przypadków testowych (co najmniej 20–50 dla prostego zadania, więcej dla złożonych) z oczekiwanymi wynikami lub kryteriami oceny. Uruchom prompt na zbiorze testowym i zmierz odpowiednią metrykę (dokładność, formatowanie, poprawność językowa, poprawność faktyczna). Bez liczby „dobry prompt" to tylko odczucie.
Ile tokenów powinien mieć system prompt?
Nie ma uniwersalnej odpowiedzi, ale w praktyce widzimy, że efektywne system prompty mieszczą się zwykle w zakresie 200–800 tokenów. Krótsze są niewystarczająco precyzyjne, dłuższe zaczynają cierpieć na efekt „lost in the middle" — model traci orientację w instrukcjach umieszczonych w środku. Jeśli twój prompt przekracza tysiąc tokenów bez wyraźnego powodu, pora go zrefaktorować lub przemyśleć, czy część informacji nie powinna trafić do kontekstu RAG zamiast do system promptu.
Czy te same zasady obowiązują dla modeli open-weight wdrożonych lokalnie?
Większość zasad obowiązuje, ale z ważnym zastrzeżeniem: mniejsze modele open-weight (parametry 7B–13B) są mniej odporne na przestrzeganie instrukcji niż modele frontier. Przykłady few-shot są ważniejsze, formatowanie promptu musi być bardziej precyzyjne, a zbiór testowy trzeba dostosować do konkretnej rodziny modeli. Prompt zaprojektowany dla modeli frontier może nie działać tak samo na Mistral 7B czy podobnie dużych modelach open-weight — nawet po starannej optymalizacji. Język polski stanowi dodatkowe wyzwanie dla mniejszych modeli — testuj zawsze w języku produkcyjnym.
*Prompt engineering to rzemiosło, nie magia — a jak każde rzemiosło można się go nauczyć, usystematyzować i mierzyć. Jeśli planujesz wdrożenie LLM na produkcję i nie wiesz, od czego zacząć, chętnie ocenimy twój konkretny przypadek i pomożemy ustawić fundamenty, na których można budować.*