Od Zero-Shot do samokonsystencji: praktyczna ścieżka technik promptowania

Gdy aplikacja ustali już, co model ma zobaczyć, jakie dokumenty mają zostać pobraane, co ma zostać skrócone, a co ma zostać pominięte, pojawia się inne wyzwanie: sformułowanie właściwej prośby. Żaden jeden sposób instruktywowania nie sprawdza się we wszystkich przypadkach. Rozsądnym nawykiem jest rozpoczęcie od najprostszej możliwej instrukcji i dodawanie przykładów lub struktury krok po kroku tylko wtedy, gdy zadanie wymaga tego faktycznie.

Poniższy przykład dotyczy asystenta obsługi klienta.

Rozpoczęcie bez żadnych przykładów

Prośba typu zero-shot opisuje zadanie, ale nie pokazuje, jak powinien wyglądać dobry wynik. W przypadku asystenta obsługi klienta może to być jednozdaniowa prośba o streszczenie skargi, z samą skargą umieszczoną poniżej:

Summarize the following customer complaint in one sentence.
<complaint>
The package arrived three days late and the box was damaged.
</complaint>

Model otrzymuje zadanie i nic więcej. Właśnie ta prostota jest powodem, by najpierw go wypróbować. Wszystko, co dodaje się do promptu, ma swoją cenę: przykłady zużywają kontekst, dodatkowe instrukcje zwiększają złożoność, a każdy element dodatkowy to kolejne miejsce, gdzie mogą się zderzyć dwie zasady. Jeśli bezpośrednia instrukcja już daje wiarygodny wynik, skomplikowane ramy są lekarstwem na chorobę, której nikt nie ma.

Na co odpowiada dobra instrukcja

Dobrze sformułowane opisanie zadania określa cztery kwestie: działanie do wykonania, materiały, z których należy czerpać, obowiązujące ograniczenia oraz kształt, jaki powinien mieć odpowiedź. Pełniejsza wersja promptu wygląda tak:

Task:
Summarize the customer complaint.

Source:
<complaint>
The package arrived three days late and the box was damaged.
</complaint>

Constraints:
- Use only the information in the complaint.
- Do not infer the cause of the damage.
- Use one sentence.

Output:
Return only the summary.

Jest bardziej rozwlekły niż zwykłe polecenie „Streszcz to”, ale każdy dodany wers jest szansą na uniknięcie domysłów. Model nie musi już zastanawiać się, czy należy spekulować na temat przyczyn, jak długo kontynuować, czy komentarze są dozwolone. Wskazówki dostarczane przez producentów dużych modeli wskazują tę samą drogę: należy określić, jaki jest zadanie, jaki powinien być wynik, jakie obowiązują ograniczenia i jaki kontekst ma znaczenie, zamiast liczyć na to, że model to sam wywnioskuje. Mówiąc prościej, każdy wymóg, który jest ważny dla aplikacji, powinien zostać spisany.

Konkretne cele są lepsze od miłych

„Bądź pomocny” nie daje modelowi prawie żadnego celu do osiągnięcia. „Podaj nazwę problemu opisanego przez klienta i podsumuj go w jednym zdaniu” dostarcza mu konkretnego celu. Porównaj dwa polecenia dla narzędzia wsparcia – słabsze mówi o pomocy klientowi, natomiast silniejsze wymaga wskazania problemu autoryzacyjnego opisanego przez klienta oraz co najwyżej trzech kroków naprawczych opartych na dostarczonej dokumentacji.

To ma znaczenie, ponieważ model może kontynuować zadanie na wiele prawdopodobnych sposobów. Niejasny cel pozostawia możliwość, że model wybierze interpretację różną od intencji programisty, natomiast precyzyjny cel zmniejsza tę możliwość.

Ograniczenia powinny znajdować się wewnątrz zadania

Należy jasno zaznaczyć, że asystent nigdy nie powinien wymyślać rozwiązania, którego brakuje w dokumentacji. To jest zasada produktu, więc w instrukcji musi to zostać podane: należy korzystać wyłącznie z dostarczonej dokumentacji, a jeśli nie obejmuje ona danego pytania, należy stwierdzić, że dostępnych informacji jest niewystarczająco. Porównaj to z wymogiem „Bądź dokładny”, który określa pożądany wynik, ale nie podaje wskazówek, co robić w przypadku niepewności.

To wzorzec można uogólnić. Nie wystarczy opisać tylko idealnego wyniku; należy opisać, co model powinien zrobić, gdy nie można bezpiecznie osiągnąć tego wyniku. Jest to tym ważniejsze później, przy wywoływaniu narzędzi i generowaniu strukturyzowanych wyników.

Gdzie zero-shot wystarcza

Zwykłe instrukcje sprawdzają się, gdy zadanie jest proste, jego opis łatwy do sformułowania, model już zna rodzaj zadania, zasady wyjściowe są proste, a dane wejściowe nie zawierają nietypowych przypadków granicznych. Prośba o wersję produktu w wiadomości, podając jedynie numer wersji, to jeden z takich zadań. Tłumaczenie zdania na francuski to kolejne. Dodawanie pięciu przykładów w tym samym czasie niewiele daje.

Dlatego pierwsza zasada optymalizacji promptów jest co dziwne konserwatywna: zacznij od podejścia zero-shot i dodawaj dodatkowe narzędzia dopiero wtedy, gdy ocena pokaże taką potrzebę.

Sposoby, w których zero-shot zawodzi

Powtarzają się kilka typów niepowodzeń.

Ambiwalencja. Zapytanie „Ulepsz to” rodzi pytanie: krótsze, bardziej przekonujące, dokładniejsze, bardziej formalne? Model musi zgadywać. Porównaj to z prośbą o przepisanie odpowiedzi obsługi klienta tak, by była zwięzła, profesjonalna i zrozumiała dla klienta niebędącego specjalistą, przy jednoczesnym zachowaniu wszystkich faktów. W tym przypadku wymagania są znacznie bardziej precyzyjne.

Brak kontekstu. Model nie może polegać na faktach, których mu nigdy nie dostarczono ani których nie może uzyskać. Zapytaj go, dlaczego autoryzacja klienta nie powiodła się, nie podając komunikatu o błędzie ani szczegółów systemowych – żadna modyfikacja tekstu nie dostarczy brakujących informacji. Rozwiązaniem jest tutaj lepszy kontekst, a nie lepsze instrukcje. To oczywisty punkt, a zarazem rzeczywista granica inżynierii promptów.

Konfliktujące wymagania. Zapytanie wymagające kompletnego wyjaśnienia dokładnie w dziesięciu słowach nakłada dwie rzeczy, których nie da się dobrze wykonać jednocześnie. Dobry projekt instrukcji zapobiega takim konfliktom, zamiast polegać na modelu, by ten rozwiązywał każdy z nich.

Niewyrażone założenia. Programista, który pisze „Streszcz skargę”, może mieć na myśli „wymień tylko fakty podane przez klienta”. Model może natomiast zwrócić płynne streszczenie z rozsądnymi wnioskami włączonymi do niego. Jeśli ta różnica ma znaczenie, instrukcja musi to jasno określić. Założenia istotne dla systemu powinny stać się wyraźnymi, czytelnymi dla maszyny wymaganiami.

Dodawanie przykładów

Gdy zwykłe instrukcje okazują się niewystarczające, stosuje się technikę promptingu typu few-shot: umieszczenie przykładów zakończonych pomyślnie zadań w kontekście. Klasyfikator, który dzieli wiadomości na kategorie billingowe, techniczne i dotyczące konta, może pokazać kilka oznaczonych wiadomości przed rzeczywistą:

Task:
Classify the customer message as BILLING, TECHNICAL, or ACCOUNT.

Example 1:
"My invoice contains an unexpected charge."
→ BILLING

Example 2:
"The application crashes when I upload a file."
→ TECHNICAL

Example 3:
"I cannot reset my password."
→ ACCOUNT

Now classify:
"I was charged twice for my subscription."

Na podstawie tych demonstracji model wywnioskowuje odpowiednią mapę. Nazywa się to uczeniem w kontekście, ponieważ model zmienia swoje zachowanie w odpowiedzi na aktualną prośbę, korzystając z przykładów znajdujących się w jego „oknie”, przy czym jego podstawowe parametry pozostają niezmienione. W istocie przykłady mówią: „Tak wygląda to zadanie w praktyce” i mogą przekazać szczegóły, które trudno jest opisać w prozie.

Demonstracje uczą samego zadania, a nie tylko jego formatu

Wielu programistów traktuje przykłady typu few-shot jako narzędzie do formatowania. Jednak one robią coś więcej. Weźmy na przykład parę „aplikacja działa wolno” z etykietą TECHNICAL – pokazuje to format wyjścia, ale także to, jak ta aplikacja rozumie kategorię TECHNICAL. Przykłady kształtują zrozumienie modelu samego zadania.

Dlatego złe przykłady są ryzykowne. Niejednolite etykiety, przypadkowe uprzedzenia lub przypadki krawędziowe, które są sprzeczne z zasadami, mogą zostać ponownie skopiowane przez model.

Wybór przykładów do włączenia

Przy dostępnych 10 000 historycznych zgłoszeń umieszczenie ich wszystkich w instrukcji jest nieracjonalne, więc trzeba wybrać ich podzbiór. Losowy wybór to naiwny podejście. Lepszym rozwiązaniem jest celowe uwzględnienie reprezentatywnych przypadków:

Example 1: straightforward billing issue
Example 2: straightforward technical issue
Example 3: ambiguous issue
Example 4: boundary case
Example 5: short, poorly written request

To, co stanowi dobrą selekcję, zależy od zadania. W przypadku klasyfikacji konieczne jest przedstawienie głównych klas oraz ich granic. Zadanie formatowania wymaga przykładów pokazujących wymaganą strukturę. Zadania wymagające intensywnego rozumowania korzystają z przykładów, które pokazują, jak rozłożyć problem na części lub go sprawdzić. We wszystkich przypadkach przykład zasługuje na swoje miejsce dzięki informacjom, które zawiera, a nie dlatego, że jest dostępny.

Ile?

Więcej nie oznacza automatycznie lepiej. Jeśli jeden starannie wybrany przykład sprawia, że zachowanie jest oczywiste, trzydzieści kolejnych może dodać tysiące tokenów bez żadnej korzyści i może wprowadzić sprzeczne wzorce. Dlatego też promptowanie z użyciem niewielkiej liczby przykładów boryka się z tą samą kwestią ograniczeń kontekstowych co wszystko inne, a odpowiednią liczbę trzeba ustalić poprzez testy.

Tutaj inżynieria promptów zaczyna przypominać prace eksperymentalne. Pytanie przestaje dotyczyć tego, czy prompt brzmi lepiej, a staje się pytaniem, czy ta wersja radzi sobie lepiej w reprezentatywnych przypadkach testowych. Ta zmiana staje się kluczowa, gdy pojawia się ocena.

Różnorodność przykładów

Jeśli każda demonstracja to krótki, klarowny, dobrze napisany zapytanie, model może nauczyć się wąskiego wzorca, którego nie stosują rzeczywiści użytkownicy. Rzeczywiste wiadomości wyglądają tak:

"can't login"
"I've been locked out since yesterday"
"Password reset isn't sending me anything"
"login broken after changing phone"

Wszystkie one opisują powiązane problemy za pomocą zupełnie różnych słów. Dobry zbiór przykładów odzwierciedla różnorodność, jakiej oczekuje aplikacja. To nie oznacza dodawania przykładów losowo; oznacza celowe uwzględnienie istotnych różnic.

Pokazywanie, czego unikać

W niektórych zadaniach korzystne jest połączenie dobrego wyniku z złym, aby model mógł dostrzec granicę. W przypadku wsparcia wiadomość o opóźnionej dostawie paczki mogłaby zawierać zarówno akceptowalny podsumowanie, jak i błędne:

Input:
"The customer says the package arrived late."
Good output:
"The customer reports that the package arrived late."
Bad output:
"The courier lost the package."
Reason:
The customer did not state that the courier lost it.

Zły przykład wskazuje na granicę: nie należy wyciągać wniosków na podstawie faktów, których nie potwierdza dane wejściowe. Jednak przykłady negatywne wymagają ostrożności – ten oznaczony jako błędny może przypadkowo nauczyć właśnie tego zachowania, którego miał zapobiec, szczególnie gdy różnica jest subtelna. Aplikacja powinna sprawdzić, czy negatywne przykłady poprawiają wyniki, a nie po prostu zakładać, że tak będzie.

Przykłady dotyczące struktury

Gdy trudno jest opisać układ wyniku, przykład sprawdza się doskonale. Załóżmy, że asystent powinien odpowiedzieć trzema oznaczonymi liniami dotyczącymi problemu, dowodów i działań:

Issue: ...
Evidence: ...
Action: ...

Jedna praktyczna demonstracja od razu ucieleśnia ten układ:

Input:
"The login token expired after 30 days."
Output:
Issue: Expired authentication token
Evidence: Token expiration is reported after 30 days
Action: Regenerate the authentication token

Poprawia zarówno wzorzec treści, jak i jej prezentację. Przykłady nie zawsze są jednak właściwą odpowiedzią. Jeśli oprogramowanie wymaga JSON czytelnego przez maszyny o gwarantowanej poprawności, funkcja wyjściowa ograniczona schematem może być bardziej niezawodna niż pokazanie modelowi przykładu.

Utrzymywanie spójności przykładów

Wskazówki typu few-shot źle reagują na sprzeczności. Rozważmy dwa przykłady z tym samym wprowadzeniem – „Nie mogę się zalogować” – oznaczone jako ACCOUNT w jednym przypadku, a TECHNICAL w drugim:

Example 1:
"Can't log in" → ACCOUNT
Example 2:
"Can't log in" → TECHNICAL

Model nie ma żadnego spójnego sposobu, by określić, który z mapowań jest zamierzony. Nawet subtelne niezgodności szkodzą. Jeśli niektóre przykłady używają etykiety BILLING, a inne frazy „Billing issue”, przestrzeń wyników staje się niejasna. Etykiety, formatowanie, terminologia, poziom szczegółowości oraz sposób radzenia sobie z przypadkami krawędziowymi powinny być identyczne we wszystkich przykładach. Demonstracje stanowią część specyfikacji i zasługują na takie samo uwzględnienie.

Uczenie się w ramach okna

Uczenie się w kontekście to ogólna idea stojąca za techniką promptowania typu few-shot: przykłady znajdują się w bieżącym kontekście, a zachowanie modelu zmienia się w zależności od tej interakcji. Nie oznacza to, że model trwale je przyswoił. Jeśli aplikacja wysyła jeden przykład z etykietą, a następnie wiadomość od użytkownika o niemożności dostępu do konta:

Example:
"Password reset email never arrived." → ACCOUNT
User:
"I can't access my account."

Model może wykorzystać tę demonstrację do realizacji tego zapytania. Jego parametry nie są aktualizowane, a przykład nie trafia do jego trwałej pamięci. Odzwierciedla to wcześniejszy podział na kontekst i pamięć. Metody, które faktycznie zmieniają parametry, takie jak doprecyzowanie na podstawie dodatkowych danych treningowych, stanowią odrębny mechanizm, a porównywanie ich z techniką promptingu pojawia się znacznie później. Na razie prompting typu few-shot należy postrzegać przede wszystkim jako tymczasowe warunkowanie zadania poprzez kontekst.

Wybór między nimi

Skuteczny proces decyzyjny zaczyna się od określenia, w jaki sposób wynik jest błędny. Niejednoznaczne zadanie wymaga jaśniejszego sformułowania, a brakujące informacje – lepszego kontekstu. Przykłady mogą okazać się pomocne w przypadku subtelnych konwencji, których model nie dostrzega. Jeśli zadanie wymaga dokładnych obliczeń arytmetycznych lub dostępu do bazy danych, dodatkowy opis w promptingu może być zupełnie niewłaściwym rozwiązaniem.

Ostatni przypadek prowadzi na trudniejszy teren. Niektóre zadania są zbyt skomplikowane, by można je było skutecznie wykonać przy użyciu jednej instrukcji i jednej odpowiedzi. Trzeba je podzielić na mniejsze operacje, sprawdzić lub powiązać z zewnętrznymi obliczeniami. Po osiągnięciu pewnego punktu wyzwaniem nie jest już znalezienie idealnego zdania, lecz zaprojektowanie małej procedury, której model ma się trzymać.

Wyobraźmy sobie zgłoszenie, w którym klient nie może wejść po zmianie hasła, a asystent ma przejrzeć historię, określić prawdopodobną przyczynę i napisać odpowiedź. Wygląda to jak jedno zadanie. W praktyce kryje się za tym kilka: ustalenie, co się stało, znalezienie odpowiednich dowodów, oddzielenie faktów od założeń, rozważenie możliwych przyczyn, podjęcie decyzji o tym, co można bezpiecznie zalecić, sprawdzenie tej rekomendacji oraz napisanie ostatecznej odpowiedzi. Zrozumienie tego jest kluczem do dekompozycji zadania.

Dzielenie jednego zadania na kilka

Dekompozycja polega na zastąpieniu jednego skomplikowanego zadań kilkoma mniejszymi, które mają wyraźne granice. Zamiast prosić o wszystko naraz, aplikacja może sformułować żądanie w postaci etapów:

Task:
Analyze this customer support case.

Step 1:
Extract the relevant facts.

Step 2:
Identify the customer's actual problem.

Step 3:
List plausible causes supported by the evidence.

Step 4:
Select the safest supported resolution.

Step 5:
Draft the customer-facing response.

Model nie musi dosłownie mieć słowa „Krok”. Ważne jest to, że niejasny cel przekształca się w sekwencję zarządzalnych operacji. Jest to szczególnie pomocne, gdy poszczególne elementy mają różną naturę: wyodrębnianie faktów to zadanie informacyjne, wybór diagnozy to rozumowanie, a pisanie wiadomości to komunikacja. Zgrupowanie ich w jedną, nierozróżnioną instrukcję utrudnia kierowanie procesem i jego ocenę.

System rozłożony na części oferuje również więcej możliwości testowania. Jeśli ostateczna odpowiedź jest błędna, można sprawdzić, czy doszło do błędu przy wyodrębnianiu faktów, diagnozie lub pisaniu odpowiedzi. Zmiana sposobu myślenia polega na tym, że prompt można budować jak łańcuch operacji, a nie tylko pisać jako pytanie.

Najpierw zaplanuj, potem działaj

Powiązana technika polega na tym, że model musi najpierw opracować plan przed wykonaniem złożonego zadania. Pomaga to, gdy model musi zdecydować, jakie operacje są potrzebne, zanim będzie mógł udzielić odpowiedzi. Asystent może zacząć od określenia celu oraz uporządkowanego planu:

Goal:
Resolve the customer's login problem using only supported evidence.
Plan:
1. Read the latest customer message.
2. Check the relevant conversation history.
3. Identify authentication-related evidence.
4. Compare the evidence with the known troubleshooting guidance.
5. Produce a response that does not claim unsupported facts.

Planowanie oddziela decyzję o tym, jak coś rozwiązać, od samego rozwiązywania tego problemu. To rozdzielenie staje się jeszcze ważniejsze, gdy w grę wchodzą narzędzia, ponieważ model może musieć ustalić, że najpierw powinien przeszukać bazę wiedzy, sprawdzić zapis w kontach lub przeprowadzić obliczenia. Wskazówki mogą przygotować strukturę pracy przed jej rozpoczęciem.

Istnieje to koszt. Dekompozycja zwiększa długość komend, a gdy każdy etap jest osobną próbą wywołania modelu, powstają dodatkowe wywołania modelu oraz opóźnienia. Proces składający się z pięciu etapów może kosztować znacznie więcej niż jedno wywołanie. Opłaca się to wtedy, gdy dodatkowa kontrola i niezawodność usprawiedliwiają taki koszt, a nie dlatego, że większa liczba etapów jest z natury lepsza.

Generuj, oceniaj, poprawiaj

Kolejny skuteczny mechanizm pozwala modelowi ponownie przejrzeć swój własny projekt odpowiedzi. Pierwsza odpowiedź nie jest traktowana jako ostateczna; druga faza polega na jej sprawdzeniu według określonych kryteriów. W przypadku systemu wsparcia oznacza to stworzenie projektu odpowiedzi, a następnie jego sprawdzenie pod kątem listy określonych problemów:

First:
Draft the response.

Then:
Check the draft for:
- unsupported claims,
- missing evidence,
- incorrect troubleshooting steps,
- promises the support team cannot make,
- failure to answer the customer's actual question.

Finally:
Revise the response to correct any problems.

To działa, ponieważ tworzenie i ocenianie to różne zadania. Generowanie oznacza budowanie czegoś wiarygodnego. Przeglądanie istniejącej odpowiedzi pozwala modelowi szukać naruszeń określonej listy kontrolnej. Określenie kryteriów jest zazwyczaj skuteczniejsze niż prośba o intensywniejsze myślenie.

To podejście można stosować na różnych poziomach złożoności: wersja robocza, przegląd, ostateczna odpowiedź, lub w przypadku bardziej zorganizowanego zadania – wyodrębnienie danych, weryfikacja tego wyodrębnienia, klasyfikacja, weryfikacja klasyfikacji, generowanie. Druga forma jest łatwiejsza do debugowania, ponieważ każdy etap ma określone zasady.

Jeden ograniczenie jest istotne. Model poproszony o samokrytykę nie staje się dzięki temu niezależnym źródłem prawdy. Jeśli początkowa odpowiedź opiera się na błędnym założeniu, krytyk może je podzielać. Samokrytyka może poprawić spójność, ale nie gwarantuje poprawności, a przy decyzjach o dużym znaczeniu warto sprawdzić ją w odniesieniu do czegoś spoza modelu: bazy danych, znanej zasady, obliczenia, pobraanego dokumentu lub kodu deterministycznego.

Wskazówki ujawniające strukturę rozumowania

Badania nad wskazówkami typu chain-of-thought wykazały, że pokazanie modelowi przykładów z pośrednimi krokami rozumowania może poprawić wyniki w niektórych problemach wieloetapowych, przy czym odnotowano poprawy w testach arytmetycznych, opartych na zdrowym rozsądku oraz symbolicznych. Lekcja wynikająca z tych badań jest szersza niż ta krótka fraza. Złożone zadanie może odnieść korzyść, gdy wskazówka uwzględnia jego pośrednią strukturę:

Identify the relevant facts.
Determine which facts support each possible conclusion.
Eliminate conclusions that require unsupported assumptions.
Select the conclusion supported by the evidence.

To jest promptowanie oparte na rozumowaniu: kształtowanie zadania w taki sposób, aby pośrednie decyzje były wystarczająco jasne, by skierować model ku wymaganemu wynikowi. Nie zobowiązuje to aplikacji produkcyjnej do pokazywania użytkownikowi wewnętrznej logiki modelu. Często lepsza interfejs prosi o wynik weryfikacji, a nie długie wyjaśnienie. Aplikacja może wymagać zwięzłego wewnętrznego zapisu, takiego jak ten poniżej, a następnie oddzielnie wygenerować krótką odpowiedź dla klienta:

classification: password_reset_issue
evidence_supported: true
recommended_action: resend_reset_link
confidence: high

Struktura rozumowania i wyjaśnienie skierowane do klienta to odrębne wymagania. Trzymanie ich oddzielnie pomaga również uniknąć powszechnego błędu, polegającego na założeniu, że bardziej widoczne uzasadnienie sprawia, iż odpowiedź jest bardziej wiarygodna. Kroki pośrednie również mogą zawierać błędy. Badania nad techniką chain-of-thought pokazały, że właściwości demonstracji, takie jak ich istotność i kolejność, mają ogromne znaczenie, dlatego samo dodawanie długich uzasadnień nie jest uniwersalnym rozwiązaniem.

Kilka prób, a następnie głosowanie

Proces generowania jest probabilistyczny, więc jeden problem może dać różne odpowiedzi przy różnych próbach. Samokonsystencja wykorzystuje to, przeprowadzając próbki z wielu ścieżek rozumowania i wybierając odpowiedź, którą popiera większość z nich, zamiast polegać na jednej wybranej ścieżce.

Załóżmy, że system wsparcia nie jest pewien, czy dany przypadek dotyczy problemu z resetowaniem hasła, czy blokady konta. Zamiast przyjąć jedną klasifikację, mógłby wygenerować kilka analiz i porównać uzyskane wyniki.

Zgoda wciąż nie jest równoznaczna z prawdą. Jeśli model stale błędnie interpretuje sytuację, wiele niezależnych analiz może doprowadzić do tego samego błędnego wyniku. Spójność jest dowodem stabilności, a nie dowodem poprawności. Ponadto wymaga więcej obliczeń i powoduje opóźnienia, co sprawia, że jest atrakcyjna tylko w przypadku zadań na tyle trudnych, że zysk w postaci większej niezawodności usprawiedliwia poniesione koszty.

Gdzie prompty powinny przekazać kontrolę kodowi

Tutaj leży granica pomiędzy coraz bardziej skomplikowanymi poleceniami a dobrą architekturą systemu. Wyobraźmy sobie prośbę o podsumowanie faktury zawierającej 17 pozycji po cenie 1500 ₹ każda. Model prawdopodobnie potrafi obliczyć tę sumę, ale gdy liczy się dokładna wartość finansowa, nie ma powodu, by zmuszać go do symulowania operacji arytmetycznych za pomocą coraz dłuższych instrukcji. Kalkulator lub zwykły program mnoży w sposób deterministyczny.

Ta sama logika odnosi się do innych zadań:

• Dane konta powinny pochodzić z zapytania do bazy danych, a nie z pamięci modelu.
• Bieżące fakty powinny być pobierane, a nie przywoływane z okresu szkolenia.
• Operacje arytmetyczne należą do kalkulatora lub programu.
• Weryfikacja schematu to zadanie parsera i walidatora.
• Uprawnienia dotyczą kodu aplikacji oraz reguł kontroli dostępu.
• Krytyczne reguły biznesowe powinny być kodowane w sposób deterministyczny, o ile to możliwe.

Istnieje przydatna zasada: używaj promptowania, aby kierować zachowaniem modelu językowego, a także stosuj oprogramowanie deterministyczne, gdy zadanie faktycznie wymaga deterministycznych obliczeń lub egzekucji.

Działania zewnętrzne dodatkowo uwyraźniają ten punkt. ReAct, dobrze znane podejście badawcze, łączy rozumowanie z działaniami, dzięki czemu model może korzystać z zewnętrznych źródeł lub środowisk zamiast polegać wyłącznie na wiedzy wewnętrznej, i pokazało, że taka interakcja może łatwiej radzić sobie z problemami takimi jak halucynacje i propagacja błędów w niektórych zadaniami.

To jest most prowadzący do tego, co następuje. System wsparcia zaczął się jako prośba, a teraz przypomina mały program. Gdy weryfikacja wymaga bazy danych, bazy wiedzy, API lub innej zewnętrznej funkcjonalności, model nie pracuje już wyłącznie z tekstem, a problem przenosi się na inżynierię kontekstu: trzeba zdecydować nie tylko, jakie instrukcje napisać, ale także jakie informacje powinien otrzymać model.