Prompt engineering to praktyka formułowania poleceń (promptów) dla dużych modeli językowych w taki sposób, by wynik był poprawny, zgodny z oczekiwanym formatem i powtarzalny przy kolejnych wywołaniach. W zastosowaniach operacyjnych rzadziej chodzi o pojedynczą rozmowę z czatem, a częściej o polecenie wykonywane setki razy dziennie w zautomatyzowanym procesie, którego wynik trafia do innego systemu.
Z czego składa się dobre polecenie
- Kontekst – czego dotyczy zadanie, jakie dokumenty model otrzymuje i kto korzysta z wyniku.
- Precyzyjne zadanie – co dokładnie ma zostać zrobione, łącznie z sytuacjami nietypowymi, np. „jeśli pole jest nieczytelne, zwróć pustą wartość”.
- Przykłady (few-shot) – kilka par „dokument wejściowy – oczekiwany wynik”, które pokazują format i sposób interpretacji, np. jak traktować rabaty czy pozycje zbiorcze.
- Ustrukturyzowany format wyjścia – zamiast swobodnego tekstu dane w formacie JSON według zdefiniowanego schematu. Wiele interfejsów modeli pozwala wymusić zgodność odpowiedzi ze schematem (structured output), co ułatwia walidację i import.
- Ograniczenia – czego model nie powinien robić, np. uzupełniać brakujących danych domysłami.
Dobre polecenie nie usuwa ryzyka halucynacji. Wynik trzeba walidować regułami biznesowymi, a gdy model potrzebuje wiedzy firmowej, łączy się go ze źródłami danych, np. w architekturze RAG.
Przykład
Magazyn otrzymuje od dostawców dokumenty WZ jako skany PDF w kilkunastu układach graficznych. Pracownik przepisywał do systemu numer dokumentu, datę, dostawcę oraz pozycje z indeksami i ilościami. W rozwiązaniu opartym na modelu językowym polecenie zawiera opis pól, trzy przykładowe dokumenty z oczekiwanym wynikiem, schemat JSON i regułę, że ilości zapisuje się wyłącznie jako liczby, bez jednostek. Wynik przechodzi walidację: indeks musi istnieć w kartotece, a suma ilości zgadzać się z awizacją. Dokumenty, które nie przejdą kontroli, trafiają do weryfikacji przez pracownika. Ten sam wzorzec stosuje się do faktur kosztowych, gdzie dodatkowo sprawdza się zgodność kwot netto, VAT i brutto.
Najczęstsze błędy
- Ogólnikowe polecenia bez przykładów i schematu wyniku. Model zwraca dane w zmiennym formacie, którego nie da się automatycznie zaimportować.
- Wdrożenie po teście na kilku dokumentach. Potrzebny jest zestaw testowy obejmujący różne układy, skany słabej jakości i przypadki brzegowe.
- Brak kontroli wersji poleceń. Zmiana jednego zdania może poprawić wynik dla jednego typu dokumentu i pogorszyć dla innego, dlatego polecenia warto wersjonować i testować regresyjnie.
Od czego zacząć
- Wybrać powtarzalny dokument o dużym wolumenie i zebrać 50–100 przykładów z poprawnymi wynikami.
- Zdefiniować schemat danych wyjściowych i reguły walidacji.
- Zmierzyć trafność na zestawie testowym, zanim rozwiązanie trafi do codziennej pracy.