Twój Agent AI nie potrzebuje manifestu. Potrzebuje konkretnej, jednoznacznej specyfikacji. Oto jak ją napisać.

Niedawno przepisaliśmy prompt systemowy naszego Recepcjonisty AI. Poprzednia wersja miała 450 wierszy, była pięknie ustrukturyzowana i pełna starannie przemyślanych zasad – i pochłaniała tyle okna kontekstowego (context window), że agentowi brakowało miejsca na faktyczne słuchanie dzwoniącego! Aby pomóc Ci uniknąć tych samych problemów, przygotowaliśmy ten wpis – część 1 teraz, a część 2 wkrótce. Dowiesz się z niego, jak przestać pisać poezję, a zacząć tworzyć skuteczne instrukcje. Zapraszamy do lektury!

Błąd, który na początku popełniają wszyscy

Nie jesteśmy jedynymi, którzy popełnili ten błąd. Prawie każdy klient 3CX edytujący swój pierwszy prompt systemowy robi to samo: traktuje go jak dokument polityki firmy, kontrakt prawny lub – co gorsza – zadanie z kreatywnego pisania.

Oto pułapka: ponieważ prompty pisze się po angielsku, ludzie zapominają, że w rzeczywistości piszą kod. Tworzą całe akapity. Dodają przymiotniki. Definiują terminy, które model już rozumie. Powtarzają tę samą instrukcję pięć razy, bo wydaje im się to ważne.

Model nie czyta prozy tak jak człowiek. Każde słowo w Twoim prompcie kosztuje kontekst, uwagę i – często – spójność. Długi prompt wcale nie jest „staranniejszy”. Zazwyczaj jest po prostu gorszy.

Ten poradnik to zbiór wniosków, które wyciągnęliśmy podczas poprawiania własnych instrukcji. Jeśli edytujesz prompt systemowy Agenta AI 3CX, przeczytaj go, zanim klikniesz „Save”.

Pułapka języka angielskiego

Gdy prompt engineering oznaczał pisanie dla API w surowym formacie JSON, ludzie szanowali go jako dyscyplinę techniczną. Teraz, gdy instrukcje są w języku angielskim, ludzie piszą je tak, jak wiadomość na Slacku do nowego pracownika.

Spójrz na ten fragment ze starej wersji naszego własnego promptu:

„The caller’s reason is required before handoff, but it must not be used to identify, narrow, rank, disambiguate, replace, or override the requested destination.”

(Powód dzwoniącego jest wymagany przed przekazaniem połączenia, ale nie może być używany do identyfikacji, zawężania, klasyfikowania, rozstrzygania, zastępowania ani nadpisywania żądanego miejsca docelowego).

To zdanie jest poprawne gramatycznie, przemyślane i… prawie niemożliwe dla modelu do konsekwentnego przestrzegania podczas prawdziwej rozmowy. Sześć bliskoznacznych terminów. Dwa zdania składowe. Negacja owinięta wokół wymagania. Przy trzeciej wymianie zdań model zinterpretuje je inaczej niż przy pierwszej.

Oto jak brzmi to teraz:

„Do not use information search to decide who should receive a call.”

(Nie używaj wyszukiwania informacji do decydowania o tym, kto powinien odebrać połączenie).

Jedno zdanie. Jedna instrukcja. Zero dwuznaczności. Takie samo działanie.

Zasada pierwsza: Angielski to interfejs, a nie gatunek literacki. Nadal piszesz instrukcje. Krótkie, oznajmujące, sprawdzalne. Jeśli zdanie brzmi jak fragment regulaminu usługi, usuń je i spróbuj jeszcze raz.

Przestań definiować oczywistości

W starym prompcie mieliśmy taką „perełkę”:

„A handoff is any permitted next step executed via one of the actions listed below.”

(Przekazanie to każdy dozwolony kolejny krok wykonywany za pomocą jednej z poniższych akcji).

Model wie, co to jest przekazanie połączenia (handoff). Wie też, co znaczy „transfer”, „poczta głosowa” i „e-mail”. Definiowanie potocznych terminów to nawyk zapożyczony z pisania instrukcji dla ludzi. W prompcie to tylko marnowanie tokenów i tworzenie pola do błędnej interpretacji.

To samo dotyczy uroczystych nagłówków sekcji. W starym prompcie mieliśmy:

  • Mandatory Enforcement (Obowiązkowe egzekwowanie)
  • Priority Order (Kolejność priorytetów)
  • Base Schema (Schemat bazowy)
  • Action Selection Rules (Zasady wyboru akcji)

Brzmią one, jakby pochodziły z dokumentacji technicznej RFC. Nie wnoszą jednak żadnego działania. Nowy prompt używa nagłówków takich jak: Styl, Routing, Agresja – krótkich etykiet, które opisują, czego dotyczy dana sekcja, a nie jak poważnie ma brzmieć.

Zasada druga: Jeśli dana linijka nie zmienia tego, co robi model – usuń ją.

Napisz to tylko raz

Jedną z największych patologii długich promptów jest ta sama reguła pojawiająca się w czterech różnych miejscach. W naszej starej wersji zasada „nie przekazuj połączenia, jeśli cel jest niejednoznaczny” pojawiała się z niewielkimi zmianami w sekcjach:

  • Destination Ambiguity Rule (Zasada niejednoznaczności celu)
  • Handoff Action Gate (Bramka akcji przekazania)
  • Directory Rules (Zasady katalogu)
  • Confidential Output Contract (Kontrakt poufnych danych wyjściowych)

Każde powtórzenie brzmiało nieco inaczej. Każde używało innego słownictwa. Człowiek czytający te fragmenty widzi cztery wersje tej samej idei i rozumie intencję. Model widzi cztery różne zasady – a gdy nie są one idealnie zgodne, musi wybrać jedną z nich. Czasem przy trzecim połączeniu wybierze inaczej niż przy pierwszym.

Zasada trzecia: Każda reguła należy do dokładnie jednego miejsca. Jeśli czujesz potrzebę wzmocnienia zasady przez powtórzenie jej w nowej sekcji, nie potrzebujesz nowej sekcji. Potrzebujesz jaśniejszej pierwszej wersji.

Przestań mnożyć zakazy

Oto przykład:

„Do not pick the first result, best result, available result, or most relevant result.”

(Nie wybieraj pierwszego wyniku, najlepszego wyniku, dostępnego wyniku ani najbardziej trafnego wyniku).

To cztery negatywne instrukcje, podczas gdy wystarczyłaby jedna pozytywna. To, co ta reguła faktycznie oznacza, to:

„If lookup returns multiple matches, ask the caller to clarify.”

(Jeśli wyszukiwanie zwróci wiele pasujących wyników, poproś dzwoniącego o doprecyzowanie).

Pozytywne instrukcje mówią modelowi, co ma robić. Negatywne mówią mu, czego unikać, co pozostawia otwarte pytanie: „co zrobić w zamian?”. W takim przypadku model sam wymyśli odpowiedź.

Zasada czwarta: Preferuj instrukcje pozytywne. Używaj „nie rób” (do not) tylko wtedy, gdy nie istnieje żaden pozytywny odpowiednik.

Uważaj na sprzeczności

To „cichy zabójca” każdego promptu.

Nasz stary prompt zawierał dwie sekcje, które rozpatrywane łącznie były niespójne:

  • Routing by Reason: gdy dzwoniący poda powód, przeszukaj książkę adresową, aby ustalić cel połączenia.
  • Routing by Requested Destination: gdy dzwoniący prosi o konkretną osobę lub dział, nie używaj podanego powodu do routingu.

Obie zasady są prawdziwe i sensowne. Jednak umieszczone w długim prompcie, z nakładającymi się przykładami i wzmacniającymi podregułami, sprawiają, że model gubi się w tym, która z nich ma zastosowanie. Ta dezorientacja objawia się jako niespójne zachowanie, którego klientowi nigdy nie udaje się powtórzyć na żądanie.

Użyj narzędzia OpenAI Tokenizer, aby zobaczyć, jak model faktycznie dzieli Twój prompt na tokeny. Następnie przeczytaj prompt tak, jakbyś nic nie wiedział o swojej firmie – po kolei, bez żadnego kontekstu. Jeśli dwie zasady mogą mieć zastosowanie w tej samej sytuacji i prowadzić do różnych działań, masz do czynienia ze sprzecznością – nawet jeśli potrafisz logicznie wyjaśnić, dlaczego się nie wykluczają.

Zasada piąta: prompt jest spójny wtedy, gdy żadne dwie reguły nie mogą być jednocześnie zastosowane i sprzeczne ze sobą. Nie wtedy, gdy potrafisz logicznie uzasadnić różnicę między nimi.

W ciągu najbliższych kilku dni opublikujemy Część 2 tej serii, w której przyjrzymy się bliżej temu, co model może, a czego nie może zrobić, oraz podamy wskazówki dla początkujących twórców promptów. Bądźcie czujni!

Dołącz do dyskusji

Zapraszamy do dyskusji o 3CX na naszych dedykowanych forach dla Partnerów i Klientów. Obserwuj nas na X oraz LinkedIn, aby być na bieżąco z nowościami i premierami funkcji.