Prawdziwa praca zaczyna się przed promptem.
Warsztat promptowy, który zaczął się za późno
Warsztat został zarezerwowany, aby ulepszyć prompty. Tak brzmiał tytuł w kalendarzu, z wesołą ikonką różdżki, której ktoś później żałował. Grupa menedżerów, analityków, operatorów i inżynierów siedziała wokół stołu ze wspólnym dokumentem. Aktualny prompt był na ekranie. Prosił model językowy o przejrzenie próśb klientów, wskazanie właściwej polityki, przygotowanie odpowiedzi i oznaczenie ryzyka. Był uprzejmy, uporządkowany i znacznie dłuższy, niż ktokolwiek chciał przyznać. Nie był jednak głównym problemem.
Pierwszy przypadek testowy dotyczył klienta proszącego o wyjątek po opóźnionej dostawie. Model wygenerował przyzwoitą odpowiedź. Potem ktoś z operacji powiedział, że polityka źródłowa na ekranie nie jest już tą, której zespół używa w piątki, ponieważ tymczasowa reguła przewoźnika została przedłużona dwukrotnie, ale nigdy nie scalono jej z główną stroną polityki. Ktoś z działu prawnego stwierdził, że wyjątki powyżej określonej kwoty wymagają zatwierdzenia, ale próg zależy od kategorii produktu. Finanse zapytały, gdzie rejestrowane są uznania w dobrej wierze. Wsparcie powiedziało, że ton modelu jest w porządku, ale klient zadzwoni ponownie, ponieważ odpowiedź nie wspominała o brakującym zdarzeniu śledzenia. Prompt siedział tam, wyglądając niewinnie.
Żadnego z tych problemów nie rozwiązałby lepszy akapit instrukcji. Model nie mógł wywnioskować, która strona polityki jest wiążąca. Nie mógł wiedzieć, że tymczasowa reguła stała się rzeczywistością operacyjną. Nie mógł zdecydować, kto ma uprawnienia do zatwierdzania. Nie mógł dostrzec, że brakujące zdarzenie śledzenia było prawdziwą przyczyną kolejnego kontaktu. Prompt miał rekompensować niejasną pracę. To częsty błąd. Ludzie przychodzą na warsztat z koszykiem niejednoznaczności procesowych i proszą model, aby był wobec nich elegancki.
Prawdziwa praca dzieje się przed promptem. To praca polegająca na nazwaniu zadania, zdefiniowaniu granic, wyborze źródeł, ustaleniu autorytetu, przygotowaniu przykładów, określeniu ścieżek awarii, ukształtowaniu wyniku, mierzeniu jakości i umożliwieniu korekty. Prompty mają znaczenie. Zły prompt może sprawić, że dobre przygotowanie będzie nieporadne. Ale piękny prompt na niejasnej operacji to po prostu dobrze napisane zamieszanie. Model może brzmieć lepiej. Praca nie stanie się bezpieczniejsza, tańsza ani bardziej zrozumiała przez przypadek.
Prompt to nie mapa procesu
Prompt może powiedzieć modelowi, jak ma się zachowywać w danym kontekście. Nie stworzy jednak kontekstu, jeśli organizacja go nie przygotowała. Może prosić o zwięzłość, strukturę, pokorę i cytowania. Może opisać rolę. Może określić format. Może ostrzec model, żeby nie zgadywał. To wszystko jest przydatne. Jest to jednak niewiele w porównaniu z pytaniami o proces, które decydują o tym, czy system AI pomaga, czy tylko pewnie mówi w pobliżu pracy.
Czym jest zadanie. Czy to klasyfikacja, ekstrakcja, streszczenie, tworzenie szkicu, kierowanie, rekomendacja, weryfikacja czy działanie. Która część jest zautomatyzowana. Która część pozostaje ludzka. Jaki stan się zmienia, jeśli wynik zostanie zaakceptowany. Kogo to dotyczy. Które rekordy są zmieniane. Która polityka ma zastosowanie. Jakie dowody są obowiązkowe. Co się dzieje, gdy dowodów brakuje. Które błędy są do zaakceptowania. Które błędy wyrządzają szkodę. Te pytania decydują o kształcie systemu. Prompt, który nie opiera się na jasnych odpowiedziach, staje się grzecznym zgadywaniem z identyfikatorem na klapie.
Wiele nieudanych pilotaży AI zaczyna się od promptu, ponieważ prompt jest najbardziej widocznym uchwytem. Wydaje się kreatywny i natychmiastowy. Można go edytować na spotkaniu. Można wypróbować nową wersję, zanim kawa wystygnie. Projektowanie procesu jest wolniejsze. Czyszczenie danych jest wolniejsze. Mapowanie uprawnień jest wolniejsze. Budowanie zestawów ewaluacyjnych jest wolniejsze. Niestety, wolniejsze nie znaczy opcjonalne. Części pominięte przed promptem wracają później jako halucynacje, przeróbki, nieufność, wyjątki od polityki i duży arkusz kalkulacyjny o nazwie problemy.
Lepsza kolejność nie jest efektowna. Zapisz pracę. Przejdź przez prawdziwe przypadki. Zidentyfikuj systemy źródłowe. Zaznacz, które pola decydują o wynikach. Oddziel zasady od osądu. Zdecyduj, gdzie wchodzą ludzie. Zdefiniuj kontrakty wyjściowe. Zbuduj przykłady. Ustal, kiedy następuje odmowa. Przetestuj z ludźmi, którzy będą żyć z rezultatem. Dopiero wtedy prompt staje się użyteczną dźwignią. Wcześniej jest ozdobną kierownicą na biurku.
Zadanie potrzebuje granicy wystarczająco ostrej, by ją przetestować
Praca z AI często zaczyna się od czasowników zbyt ogólnych. Pomoc w obsłudze klienta. Wsparcie przeglądu prawnego. Usprawnienie planowania. Wsparcie zakupów. Uczynienie raportowania mądrzejszym. To ambicje, nie zadania. Modelu nie można oceniać względem ambicji. Można go oceniać względem zadania z danymi wejściowymi, wyjściowymi, ograniczeniami, kryteriami sukcesu i ścieżkami porażki. Węższy opis może wydawać się mniej ekscytujący. Jest też pierwszym momentem, w którym praca staje się możliwa do zbudowania.
Ostra granica zadania mówi, co system może widzieć i co może zmieniać. Mówi, czy model czyta materiał źródłowy, tworzy szkic, wyodrębnia pola strukturalne, rekomenduje działanie czy wywołuje narzędzie. Mówi, które wyniki są ostateczne, które doradcze, a które muszą być sprawdzone. Mówi, czego system odmawia. Mówi, kiedy model powinien poprosić o więcej dowodów, zamiast dokończyć odpowiedź. Mówi, co jest poza zakresem, ponieważ poza zakresem ambitne pilotaże zamieniają się w raporty incydentów.
Granice umożliwiają ewaluację. Jeśli zadaniem jest przygotowanie szkicu odpowiedzi na podstawie tych źródeł i tej polityki, jakość można przetestować. Jeśli zadaniem jest poprawa jakości usług za pomocą AI, każdy wynik można przedstawić jako postęp, jeśli ma się wystarczająco dużo slajdów. Granica chroni też użytkowników przed przypadkową eskalacją. Narzędzie, które zaczyna od szkicowania, może zyskać przycisk wysyłania. Klasyfikator może stać się routerem. Router może stać się decyzją. Bez nazwanej granicy ten dryf wygląda jak wdrożenie. Z granicą staje się prośbą o zmianę.
Granica powinna być zapisana językiem operacyjnym, a nie tylko technicznym. Powinien ją rozumieć lider wsparcia. Powinien ją rozumieć dział prawny. Powinien ją rozumieć właściciel danych. Inżynier powinien móc ją przetestować. Jeśli granica istnieje tylko w prompcie, jest krucha. Prompty są ważne, ale nie są dokumentami polityki, na których można się oprzeć. Są bardziej jak instrukcje dla bardzo utalentowanego pracownika tymczasowego, który nigdy nie widział schematu organizacyjnego.
Źródła to nie stos dokumentów
Wiele zespołów podczas pracy nad promptami odkrywa, że nie wie, które źródła są wiarygodne. Mają strony z politykami, pliki PDF, instrukcje mailowe, materiały szkoleniowe, przestarzałe podręczniki, wiadomości na czacie, makra do zgłoszeń, arkusze kalkulacyjne i pamięć operatorki, do której wszyscy dzwonią, bo wie, jak to naprawdę działa. Model ma potem odpowiadać na podstawie bazy wiedzy. Jakiej wiedzy. Jakiej bazy. To sformułowanie potrafi ukrywać naprawdę wiele.
Przygotowanie źródeł nie jest efektowne, dlatego często bywa odkładane na później. Wymaga ustalenia, który dokument wygrywa, gdy źródła są sprzeczne, jak sprawdza się aktualność, jak wygasają tymczasowe zasady, jak reprezentowane są wyjątki, jak wyklucza się materiały poufne, jak zachowuje się wersje źródeł i jak identyfikatory cytowań przetrwają w odpowiedzi modelu. To nie papierologia. To różnica między wyszukiwaniem a grzebaniem w stosie.
Sztuczna inteligencja sprawia, że dyscyplina źródłowa jest ważniejsza, bo model potrafi sprawić, że słabe praktyki źródłowe wyglądają na akceptowalne. Potrafi skleić fragmenty w płynną prozę. Potrafi wygładzić sprzeczności. Potrafi wyprodukować prawdopodobną odpowiedź z nieaktualnego materiału. Wynik wyszukiwania z widocznymi lukami wydaje się niekompletny. Wygenerowana odpowiedź z tymi samymi lukami może wydawać się kompletna. Im lepsza proza, tym ważniejsze jest pochodzenie informacji. Pewność nie powinna być sposobem na pranie słabego łańcucha źródeł.
Dobre przygotowanie źródeł zmniejsza też złożoność promptu. Prompt pełen ostrzeżeń o sprzecznych politykach, nieaktualnych dokumentach, brakujących polach i szczególnych wyjątkach to często objaw zaniedbań na wcześniejszym etapie. Jeśli warstwa wyszukiwania już filtruje według wiarygodności i aktualności, prompt może być krótszy. Jeśli źródło niesie ustrukturyzowane metadane, model nie musi ich wnioskować z tytułów akapitów. Jeśli wyjątki są reprezentowane jako reguły, model nie musi zamieniać się w detektywa z limitem tokenów. Najlepszym ulepszeniem promptu bywa czasem lepszy indeks.
Przykłady to małe elementy zarządzania
Przykłady są zwykle traktowane jako pomoc szkoleniowa, ale są też formą zarządzania. Dobry przykład pokazuje, co w danej sytuacji oznacza jakość. Uwidacznia, jak organizacja radzi sobie z niepewnością, brakiem dowodów, sprzecznymi zasadami, delikatnym tonem, eskalacją i odmową. Mówi modelowi i zespołowi, jak wygląda dobra odpowiedź, ale też dobra odmowa odpowiedzi. To istotne, ponieważ wiele poważnych systemów zawodzi właśnie wtedy, gdy odpowiadają, choć powinny się zatrzymać.
Tworzenie przykładów wymusza decyzje, których unika abstrakcyjna dyskusja. Weź dwadzieścia prawdziwych przypadków. Oznacz prawidłowy wynik. Oznacz dopuszczalne alternatywy. Oznacz niedopuszczalne skróty. Wyjaśnij, dlaczego. Dołącz przypadki graniczne, przy których doświadczeni pracownicy się wahali. Dołącz też przypadki zwykłe, bo systemy szkolone wyłącznie na dramacie uczą się złych manier. Poproś ekspertów dziedzinowych o wyrażenie sprzeciwu i zapisz ten sprzeciw. To wolniejsze niż proszenie modelu o ostrożność. Tworzy też wspólny język ostrożności.
Przykłady powinny obejmować przypadki negatywne. Brak źródła. Konflikt źródeł. Użytkownik bez uprawnień. Prośba niezgodna z celem. Klient prosi o coś, co brzmi prosto, ale uruchamia zasady. Model powinien się nauczyć, kiedy odmówić, eskalować, zapytać albo zwrócić ustrukturyzowaną niepewność. Jeśli przykłady pokazują tylko udane odpowiedzi, prompt będzie skłaniał się ku dokończeniu. Dokończenie nie zawsze jest sukcesem. Czasem najlepsza odpowiedź to niewystarczający dowód, co trudno uczcić w demie, ale bywa przydatne w działającym systemie.
Przykłady to także początek ewaluacji. Mogą stać się zestawami testowymi, przypadkami regresji, materiałem do szkolenia recenzentów i próbkami do monitorowania. Gdy dojdzie do incydentu, poprawiony przypadek może stać się nowym przykładem. To daje systemowi pamięć. Bez przykładów zmiany w promptach stają się zmianami nastroju. Ktoś mówi, że odpowiedź wydaje się lepsza. Ktoś inny, że gorsza. Model uśmiecha się pośrodku, niewzruszony dowodami.
Kształt wyniku to decyzja operacyjna
Dyskusje o promptach często poświęcają zbyt wiele uwagi tonowi, a zbyt mało kształtowi wyniku. Ton ma znaczenie, zwłaszcza w komunikacji z klientem lub publicznej. Ale to kształt wyniku decyduje, czy odpowiedź można sprawdzić, skierować, zapisać, zatwierdzić, zakwestionować lub wykorzystać w innym systemie. Akapit może być przyjemny. Ustrukturyzowany wynik może być operacyjny. Poważna praca nad AI często wymaga obu: czytelnej prozy dla ludzi i pól, które maszyny mogą zweryfikować.
Struktura wyjścia obejmuje wymagane pola, odniesienia do źródeł, poziom pewności lub niepewności, powody odmowy, flagi eskalacji, dotknięte rekordy, proponowane działania oraz stan zatwierdzenia przez człowieka. Określa, czy model może pozostawić pole puste. Określa, czy musi przytoczyć identyfikator polityki. Określa, czy może wymyślać kategorie, czy musi wybierać z kontrolowanej listy. Określa, co się dzieje, gdy dane wejściowe są niejednoznaczne. Te wybory nie są kosmetyką promptu. Są projektowaniem przepływu pracy.
Strukturalne wyjście utrzymuje też model w jego roli. Jeśli system wymaga osobnego pola na dowody, niepoparte twierdzenia stają się widoczne. Jeśli wymaga typu działania z dozwolonej listy, kreatywne użycie narzędzi staje się trudniejsze. Jeśli wymaga jawnego określenia niepewności, recenzenci mogą dokonać triażu. Jeśli wymaga podania powodu odmowy, zablokowane przypadki można analizować. Prompt może o to prosić, ale otaczający system powinien to weryfikować. Grzeczna prośba to nie kontrola. To sugestia z formatowaniem.
Jest też strona ludzka. Ludzie potrzebują wyników dopasowanych do rytmu ich pracy. Prawnik może potrzebować klauzul źródłowych i notatek o ryzyku. Pracownik wsparcia może potrzebować gotowego do wysłania do klienta szkicu oraz wewnętrznych kodów powodów. Planista może potrzebować rekomendacji trasy i ograniczenia, które ją wymusiło. Menedżer może potrzebować zagregowanych powodów, a nie indywidualnych opisów. Jeśli struktura wyjścia ignoruje użytkownika, prompt może być technicznie poprawny, ale operacyjnie irytujący. To częste osiągnięcie, ale nie przydatne.
Autorytetu nie można sugerować pomocnością
Pomocny model budzi zaufanie. To dobrze, dopóki pomocność nie zostanie pomylona z autorytetem. Jeśli model przygotowuje odpowiedź, kto może ją wysłać. Jeśli rekomenduje zwrot pieniędzy, kto może go zatwierdzić. Jeśli klasyfikuje ryzyko, kto może działać na podstawie tej klasyfikacji. Jeśli wyodrębnia pole, kto je poprawia. Jeśli nie może znaleźć dowodów, kto decyduje, czy kontynuować. Na te pytania trzeba odpowiedzieć przed promptem, bo prompt nie może nadać instytucjonalnego autorytetu.
Projektowanie autorytetu obejmuje role, progi, kolejki przeglądu, prawa do nadpisania, ścieżki eskalacji i zapisy audytowe. Odróżnia sugestię od decyzji. Odróżnia decyzję zautomatyzowaną od decyzji człowieka wspieranej automatyzacją. Określa, kiedy człowiek musi zobaczyć materiał źródłowy, a nie tylko tekst modelu. Określa, kiedy wywołanie narzędzia jest dozwolone, a kiedy zablokowane. Określa, kto ponosi odpowiedzialność za szkodę, opóźnienie, korektę i komunikację. Model może pomagać w ramach tego projektu. Nie powinien być tym projektem.
To szczególnie ważne, gdy AI jest dodawane do istniejących przepływów pracy. Istniejący autorytet może być nieformalny. Senior zatwierdza wyjątki, bo wszyscy wiedzą, że trzeba go zapytać. Lider zespołu interpretuje politykę, bo widział przypadki brzegowe. Arkusz kalkulacyjny zawiera tymczasową regułę, bo system nie może. Gdy pojawia się AI, nieformalny autorytet staje się kruchy. Model może przyspieszyć starą niejednoznaczność szybciej, niż ludzie zdążą ją wychwycić. Praca przed promptem polega na tym, by autorytet był na tyle jawny, że skalowanie nie będzie po prostu skalowaniem zamieszania.
Warto powiedzieć, że autorytet nie jest wrogiem szybkości. Jasny autorytet często przyspiesza pracę, bo ludzie wiedzą, co może się przesunąć bez dyskusji, co musi się zatrzymać i kto może decydować. Niejasny autorytet wydaje się elastyczny, dopóki nie spotka się z wolumenem. Wtedy każdy trudny przypadek staje się małym kryzysem konstytucyjnym, a wątki czatu pełnią rolę orzecznictwa. To nie jest polecany system prawny.
Ewaluacja to nie sprawdzanie wrażeń
Wiele iteracji promptów ocenia się na wyczucie. Ta wersja brzmi lepiej. Tamta jest bardziej zwięzła. Ta jest mniej nachalna. Te oceny bywają przydatne, ale nie wystarczają. Operacje AI wymagają ewaluacji, która wynika z zadania. Czy model użył właściwego źródła. Czy pominął wymagane pola. Czy odmówił, gdy brakowało dowodów. Czy eskalował przypadki wysokiego ryzyka. Czy zachował identyfikatory polityk. Czy ludzie go nadpisali. Czy klienci zadawali mniej pytań uzupełniających. Czy zespoły downstream widziały mniej poprawek.
Ewaluacja powinna obejmować przypadki typowe, skrajne, adwersarialne, nieaktualne źródła, brakujące dane, sprzeczne polityki oraz przykłady dopuszczalnej odmowy. Powinna być powtarzalna. Powinna odróżniać błąd modelu od błędu źródła, błędu promptu, błędu interfejsu i błędu procesu. W przeciwnym razie każdy problem staje się problemem promptu, bo prompt to część, którą wszyscy widzą. Widoczna część nie zawsze jest winna. Dotyczy to zarówno oprogramowania, jak i spotkań.
Ewaluacja decyduje też o tym, kiedy przestać. Bez zestawu testowego i kryteriów wydania praca nad promptem może trwać w nieskończoność, bo język zawsze można ulepszyć. Zawsze znajdzie się kolejny przymiotnik, kolejna instrukcja, kolejny przykład, kolejna poprawka formatowania. Pytanie nie brzmi, czy prompt jest doskonały. Pytanie brzmi, czy system wykonuje zadanie w uzgodnionych granicach ryzyka, kosztów i jakości. Perfekcja jest kiepskim menedżerem wydań. Nie nosi pagera.
Praca po prompcie zaczyna się przed wydaniem
Ścieżki korekty powinny być zaprojektowane, zanim pierwszy użytkownik produkcyjny zgłosi problem. Jak użytkownik oznacza błędną odpowiedź. Dokąd trafia to oznaczenie. Kto je przegląda. Czy zmienia się źródło. Czy zmienia się bank przykładów. Czy zmienia się prompt. Czy zmienia się reguła. Czy zmienia się próg. Czy człowiek otrzymuje informację zwrotną. Czy poprawiony przypadek staje się testem regresyjnym. Jeśli korekta nie jest zaprojektowana, informacja zwrotna staje się stertą. Na stertach uczenie się zapada w długą drzemkę.
Monitorowanie również powinno być ustalone przed wydaniem. Śledź nie tylko opóźnienia i koszty, ale także wskaźniki odmów, wskaźniki braku źródeł, powody nadpisań, obciążenie eskalacjami, poprawki downstream, tematy skarg, nieaktualne cytowania i dryf w strukturze zadań. Jakość odpowiedzi modelu to tylko jedna część jakości operacyjnej. System może dobrze odpowiadać i nadal kierować zbyt dużo pracy do ludzi. Może odpowiadać szybko i nadal zwiększać liczbę korekt. Może zmniejszać liczbę zgłoszeń i nadal tworzyć trudniejsze zgłoszenia. Monitorowanie powinno widzieć pracę, nie tylko tokeny.
Praca przygotowawcza przed promptem tak naprawdę nigdy się nie kończy. Pojawiają się nowe polityki. Zmieniają się systemy źródłowe. Użytkownicy znajdują skróty. Zmienia się model. Zmienia się biznes. Prompt, który działał w maju, we wrześniu może być już nieaktualny, bo praca przesunęła się pod nim. Nie oznacza to, że wszystko jest kruche. Oznacza to, że operacje AI wymagają właściciela. Ktoś musi utrzymywać definicję zadania, źródła, przykłady, ewaluację, autorytet i naprawy. W przeciwnym razie prompt stanie się skamieliną z nienaganną gramatyką.
Lekcja
Prawdziwa praca dzieje się przed promptem, ponieważ promptowanie to widoczna krawędź większego systemu operacyjnego. Model potrzebuje zadania, które może wykonać, źródeł, którym może ufać, granic, których nie może przekroczyć, wyników, które można sprawdzić, przykładów kodujących osąd, autorytetu mówiącego ludziom i narzędziom, co mogą robić, oraz ewaluacji odróżniającej poprawę od ładniejszej prozy. Bez tego prompt dźwiga odpowiedzialności, których nie jest w stanie udźwignąć.
To spojrzenie nie umniejsza promptowania. Czyni je bardziej wartościowym. Prompt w przygotowanej operacji może być krótki, jasny, testowalny i łatwy w utrzymaniu. Może skupiać model zamiast kompensować niejednoznaczność. Może ewoluować wraz z przykładami i dowodami. Można go zmieniać z pewnością, bo zespół wie, co oznacza dobro. To lepsze niż mistyka promptów, która w większości produkuje dłuższe prompty i cichsze wątpliwości.
Zanim zapytasz, jak promptować model, zapytaj, jaką pracę organizacja już wykonała dla modelu. Czy zadanie jest nazwane. Czy źródła są wiarygodne. Czy przykłady są oznaczone. Czy wyniki są ustrukturyzowane. Czy autorytet jest jawny. Czy awaria jest bezpieczna. Czy ewaluacja jest realna. Czy naprawa jest zaprojektowana. Jeśli te odpowiedzi są słabe, zacznij tam. Najbardziej przydatnym promptem w pokoju może być ten, który sprawi, że wszyscy przyznają, iż to nie od promptu zaczyna się praca.