Instrukcje dla modelu językowego — jak pisać, żeby działał powtarzalnie

Ten sam model z dwiema różnymi instrukcjami potrafi dawać wyniki dobre i bezużyteczne. W firmowym wdrożeniu instrukcja nie jest więc jednorazowym poleceniem wpisanym do okna czatu, tylko częścią systemu — powinna być pisana starannie, testowana przed każdą zmianą i przechowywana z historią wersji, tak jak kod. Różnica między instrukcją, która działa w demonstracji, a taką, która działa na tysiącach realnych przypadków, leży w szczegółach, o których łatwo zapomnieć.

Autor: zespół Convert Studio — software house z Kielc i Krakowa, projektujemy aplikacje webowe, sklepy i wdrożenia AI dla firm.

Dlaczego instrukcja ma takie znaczenie

Model językowy nie zna Twojej firmy, klientów ani oczekiwań. Wszystko, co wie o zadaniu, pochodzi z instrukcji i z danych dołączonych do zapytania. Instrukcja ogólnikowa daje wyniki ogólnikowe, instrukcja sprzeczna — wyniki losowe, bo model przy każdym wywołaniu rozstrzyga sprzeczność inaczej.

W rozmowie z człowiekiem niejasne polecenie kończy się pytaniem doprecyzowującym. Model zwykle nie pyta — przyjmuje najbardziej prawdopodobną interpretację i działa. Dlatego wszystko, co dla Ciebie oczywiste, trzeba napisać wprost.

Struktura dobrej instrukcji

Zadanie opisane konkretnie

Najczęstszy błąd to opis celu zamiast opisu zadania. „Pomóż klientowi" nie mówi, co model ma zrobić. „Na podstawie dołączonych fragmentów regulaminu odpowiedz na pytanie klienta w maksymalnie trzech zdaniach, podając numer punktu regulaminu, z którego pochodzi odpowiedź" — mówi.

• Określ długość — liczbą zdań, punktów albo słów, a nie przymiotnikiem „krótko".
• Wskaż źródło, z którego model ma korzystać, i zakaż korzystania z innych.
• Nazwij odbiorcę — ton odpowiedzi dla klienta końcowego i dla działu księgowości powinien się różnić.
• Opisz zakres — czego model nie obsługuje i co wtedy robi.
• Używaj słów, których używa firma, a nie synonimów — model powtórzy terminologię z instrukcji.

Format wyniku — warunek automatyzacji

Jeśli wynik ma trafić do innego systemu, a nie tylko do przeczytania przez człowieka, jego format musi być przewidywalny co do znaku. Odpowiedź „Kategoria: reklamacja." w jednym wywołaniu i „To zgłoszenie dotyczy reklamacji" w drugim uniemożliwia automatyczne przetworzenie.

• Podaj dokładny wzór odpowiedzi, a przy danych strukturalnych — listę pól z typami i dopuszczalnymi wartościami.
• Wymień dozwolone wartości zamiast opisywać je słowami. Lista sześciu kategorii jest jednoznaczna, opis „kategoria tematyczna" nie.
• Zakaż dodatków — komentarzy, powitań, podsumowań — jeśli wynik ma być przetwarzany maszynowo.
• Waliduj wynik po stronie kodu. Nawet najlepsza instrukcja nie gwarantuje formatu w stu procentach; odpowiedź niezgodna ze wzorem powinna być odrzucona i ponowiona.

Postępowanie przy braku danych

To najważniejszy i najczęściej pomijany element. Model zapytany o coś, czego nie ma w dostarczonych materiałach, domyślnie spróbuje odpowiedzieć — wiarygodnie brzmiącym zmyśleniem.

Instrukcja musi to wprost regulować: „Jeśli odpowiedź nie wynika z dołączonych fragmentów, napisz, że nie znalazłeś informacji, i zaproponuj kontakt z działem obsługi. Nie odpowiadaj na podstawie ogólnej wiedzy." Warto też określić, co zrobić przy danych częściowych albo sprzecznych — bo i te sytuacje wystąpią.

Szerzej o tym, skąd biorą się zmyślone odpowiedzi i jak je wykrywać, piszemy w materiale o halucynacjach modelu.

Przykłady — najsilniejsze narzędzie

Kilka par „wejście i oczekiwany wynik" działa zwykle skuteczniej niż akapit opisu. Model łatwiej naśladuje wzorzec, niż interpretuje regułę.

• Wybieraj realne przypadki z Twojej firmy, nie wymyślone.
• Pokaż przypadek graniczny — taki, przy którym łatwo się pomylić.
• Pokaż przypadek „nie wiem" — przykład, w którym poprawną odpowiedzią jest przyznanie się do braku danych.
• Unikaj przykładów zbyt podobnych — model zacznie kopiować ich treść zamiast wzorca.
• Pilnuj spójności — przykład sprzeczny z zasadami w instrukcji wygra z zasadami.

Błędy, które psują powtarzalność

• Sprzeczne zasady. „Odpowiadaj zwięźle" i „wyjaśnij dokładnie" w jednej instrukcji dają losowy wynik.
• Zasady bez priorytetu. Gdy dwie reguły się kłócą, model musi wiedzieć, która wygrywa.
• Instrukcja rozrastająca się przez dopiski. Każdy problem naprawiony zdaniem doklejonym na końcu — po roku powstaje dokument, którego nikt nie rozumie.
• Negacje bez alternatywy. „Nie pisz o cenach" działa gorzej niż „Przy pytaniu o cenę odpowiedz, że wycena jest przygotowywana indywidualnie".
• Wielkie litery i wykrzykniki zamiast jasnego uzasadnienia. Wyjaśnienie, dlaczego reguła istnieje, pomaga modelowi stosować ją w przypadkach nieopisanych wprost.
• Brak zestawu testowego. Bez niego każda zmiana jest eksperymentem na produkcji.

Testowanie zmian

Instrukcja w systemie produkcyjnym powinna być traktowana jak kod: zmiany tylko po sprawdzeniu, z historią wersji i możliwością powrotu.

Ta ostatnia praktyka sprawia, że system z czasem staje się coraz odporniejszy: błąd raz naprawiony nie może wrócić niezauważony przy kolejnej zmianie.

Utrzymanie instrukcji w czasie

Instrukcja starzeje się razem z firmą. Zmienia się oferta, procedury, nazwy działów, a także sam model — nowa wersja u dostawcy potrafi reagować na te same słowa inaczej.

• Przechowuj instrukcje w repozytorium, a nie w panelu administracyjnym bez historii zmian.
• Opisuj powód każdej zmiany — za pół roku nikt nie będzie pamiętał, po co dopisano dane zdanie.
• Uruchamiaj zestaw testowy przy zmianie wersji modelu, nawet jeśli instrukcja się nie zmieniła.
• Przeglądaj instrukcję okresowo i usuwaj zasady, które straciły aktualność.
• Wydzielaj zmienne dane — listę kategorii, godziny pracy, nazwy produktów — do osobnej konfiguracji, żeby ich zmiana nie wymagała edycji całej instrukcji.

Długa czy krótka instrukcja

Nie istnieje optymalna długość. Instrukcja powinna być tak długa, jak trzeba, żeby zadanie było jednoznaczne, i ani zdania dłuższa. Warto jednak pamiętać o dwóch konsekwencjach długości.

Po pierwsze koszt: instrukcja doklejana jest do każdego zapytania, więc każde zbędne zdanie mnoży się przez liczbę wywołań — opisaliśmy to w materiale o kosztach modeli językowych. Po drugie czytelność dla zespołu: instrukcję, której nikt nie jest w stanie przeczytać w całości, trudno utrzymywać i łatwo zepsuć przy kolejnej zmianie.

Jedna instrukcja czy kilka

Gdy system obsługuje kilka różnych zadań, kusi napisanie jednej rozbudowanej instrukcji obejmującej wszystko. To zwykle błąd. Każda dodatkowa reguła dotycząca innego zadania rozprasza uwagę modelu i zwiększa ryzyko, że zastosuje zasadę z niewłaściwego kontekstu.

Lepiej sprawdza się podział: osobna, krótka instrukcja dla klasyfikacji, osobna dla odpowiedzi klientowi, osobna dla wyciągania danych. Kod wybiera właściwą na podstawie rodzaju zadania. Każdą z nich łatwiej przetestować, zmienić i zrozumieć — a zmiana w jednej nie psuje pozostałych.

Taki podział ułatwia też pracę kilku osobom jednocześnie, bo każda może odpowiadać za swoją część systemu bez ryzyka kolizji.

Podsumowanie

Powtarzalność systemu opartego na modelu językowym zależy od instrukcji w stopniu, który zaskakuje osoby zaczynające wdrożenie. Dobra instrukcja opisuje zadanie konkretnie, określa format wyniku co do znaku, mówi, co zrobić przy braku danych, i zawiera kilka realnych przykładów — w tym przykład poprawnego „nie wiem".

Zanim zaczniesz poprawiać instrukcję, przygotuj zestaw kilkudziesięciu realnych przypadków z oczekiwanymi wynikami. Bez niego każda zmiana jest zgadywaniem, a z nim — mierzalną decyzją. Szerzej o wdrożeniach, w których instrukcja jest częścią większego systemu, piszemy na stronie agent AI i AI w firmie.