Pierwsza wersja działała — dopóki nie zaczęła rozmawiać z ludźmi
Asystent na mojej stronie ma pomóc przedsiębiorcy opisać problem przed kontaktem. Nie powinien udawać człowieka, obiecywać ceny ani urządzać przesłuchania złożonego z technicznych pytań.
Pierwsze testy szybko ujawniły drobne błędy. Raz model mówił o mnie w pierwszej osobie. Innym razem zadawał trzy pytania naraz. Potrafił też zbyt wcześnie przejść do podsumowania albo dopytywać o technologię, choć klient opisywał po prostu bałagan w zamówieniach.
Na każdy przypadek dopisywałem kolejną zasadę. Wkrótce instrukcja miała kilkanaście zakazów, wyjątków i warunków.
Każdy z osobna brzmiał rozsądnie. Razem pogarszały rozmowę.
Objawy przeładowanej instrukcji
Model zaczął bardziej pilnować przepisów niż słuchać rozmówcy. Odpowiedzi były poprawne, ale sztywne. Gdy klient odbiegał od przewidzianej ścieżki, asystent próbował wepchnąć go z powrotem do swojego planu.
Pojawił się też konflikt celów. Miał być krótki, ale dokładny. Miał nie zgadywać, lecz jednocześnie proponować następny krok. Miał zbierać kontakt, ale nie naciskać. Im więcej takich zdań dodawałem bez ustalenia pierwszeństwa, tym mniej przewidywalny był wynik.
To częsty błąd przy pracy z modelami językowymi: zła odpowiedź wygląda jak brak jednej reguły. Tymczasem przyczyną może być nadmiar reguł albo niewłaściwy podział odpowiedzialności.
Zmiana modelu nie naprawiła projektu rozmowy
Sprawdziłem inny model. Liczyłem, że lepiej poradzi sobie z długą instrukcją i zachowa więcej swobody. Część odpowiedzi rzeczywiście brzmiała naturalniej, ale powstały nowe problemy: model dopowiadał fakty, których klient nie podał, albo kończył rozmowę w chwili, w której powinien jeszcze poczekać na odpowiedź.
To był ważny sygnał. Problem nie leżał wyłącznie w wyborze narzędzia. Sam projekt mieszał ze sobą zbyt wiele zadań.
Wróciłem do poprzedniej wersji i uprościłem całość.
Co działa lepiej
Twarde ograniczenia należą do kodu
Limit długości wiadomości, liczba rozmów z jednego adresu, czas ważności sesji i zapis danych nie powinny zależeć od dobrej woli modelu. Program sprawdza je sam.
Podobnie wygląda zakończenie rozmowy. Model może zasugerować, że materiał jest pełny, ale to aplikacja usuwa znacznik techniczny, zapisuje stan i pokazuje klientowi dalszą drogę.
Rozmowa potrzebuje kilku jasnych zasad
Po uproszczeniu zostały najważniejsze reguły:
- przedstaw się jako asystent Artura, nie jako Artur,
- zadawaj jedno pytanie naraz,
- pytaj o działanie firmy, zanim przejdziesz do technologii,
- nie podawaj ceny ani terminu bez analizy człowieka,
- nie pytaj drugi raz o informację, która już padła,
- zakończ, gdy materiał wystarcza do wybrania następnego kroku.
To nadal konkretna instrukcja. Różnica polega na tym, że opisuje cel rozmowy, a nie próbuje przewidzieć każde możliwe zdanie klienta.
Podsumowanie to osobne zadanie
Model prowadzący rozmowę nie musi jednocześnie tworzyć raportu po każdej odpowiedzi. Dopiero na końcu drugi krok układa dane w stałe pola: problem, obecny sposób pracy, osoby, systemy, ryzyka i oczekiwany wynik.
Oddzielenie rozmowy od porządkowania sprawiło, że oba zadania stały się prostsze.
Lepiej opisać niepewność niż wszystkiego zakazać
Zamiast zabraniać jakiejkolwiek sugestii, asystent może powiedzieć: „To jedna z możliwych dróg; Artur oceni ją po poznaniu danych i ograniczeń”. Klient dostaje użyteczny kierunek, ale nie bierze luźnej hipotezy za ofertę.
Jak testuję rozmowę
Nie wystarcza pytanie „czy odpowiedź brzmi dobrze”. Sprawdzam całe scenariusze:
- właściciel opisuje problem bez nazw technologii,
- osoba techniczna podaje dużo szczegółów od pierwszego zdania,
- klient zmienia temat w połowie,
- ważna informacja pojawia się dopiero pod koniec,
- ktoś podaje adres e-mail wcześniej lub nie podaje go wcale,
- zapytanie w ogóle nie dotyczy usług.
Patrzę, czy asystent nie powtarza pytań, nie dopowiada faktów i kończy z podsumowaniem, na podstawie którego naprawdę można podjąć decyzję.
Najważniejszy wniosek
Projektowanie rozmowy z AI nie polega na znalezieniu jednego magicznego polecenia. To połączenie jasnego celu, ograniczeń zapisanych w programie, krótkiej instrukcji i prób na rzeczywistych sposobach wypowiadania się.
Czasem najlepszą poprawką jest usunięcie pięciu wcześniejszych poprawek.