Sytuacja
CVing to scaleup HR tech z Mediolanu. Chcieli, żeby kandydat mógł zgłosić się do pracy w całości na WhatsAppie: klika „Aplikuj przez WhatsApp” w ogłoszeniu, odpowiada na kilka pytań, potwierdza email, wysyła CV i zgłoszenie trafia do firmy. W praktyce to model, który rozmawia z każdym, przetwarza dane osobowe i zapisuje w bazie produkcyjnej. Prowadziłem projekt od badania potrzeb po produkcję w chmurze klienta.
Co zrobiłem
Moją pierwszą decyzją było usunięcie platformy konwersacyjnej przewidzianej w pierwotnym planie. To, co liczyło się dla CVing, było schowane za abstrakcjami, których nie kontrolowałem: stała wiedza o tym, kto pisze, kolejność zapisu danych i sposób wychodzenia z błędu. Napisałem własny orkiestrator.
Druga decyzja: prompt opisuje zachowanie, kod egzekwuje reguły. Każde działanie dostępne agentowi samo sprawdza, czy ma potrzebny dowód, niezależnie od tego, co mówi model. Potem przyszedł pierwszy incydent na produkcji. Kolejne dwa tygodnie spędziłem na zamykaniu każdej luki, którą pokazał.
Co się zmieniło
Podczas incydentu część kandydatów utknęła na weryfikacji emaila. Asystent mówił, żeby sprawdzić skrzynkę, a żaden mail nie wychodził. Usunąłem problem serią poprawek. Prawie każda odbierała modelowi decyzję, której nigdy nie powinien był podejmować. System działa na produkcji w chmurze CVing. Wrażliwe działanie nie zależy już od tego, czy model dobrze zrozumiał sytuację.
Czego się nauczyłem
Jedno z działań agenta łączyło istniejący email z numerem WhatsApp osoby, która pisała. Na papierze była to obsługa konta. W praktyce otwierało dostęp do tego konta. Zbyt pomocny model albo specjalnie przygotowaną wiadomość powstrzymywał tylko prompt. Nazwa działania mówiła, do czego służy, ale ukrywała, co pozwala zobaczyć i zrobić. Dziś to działanie uruchamia się tylko wtedy, gdy osoba właśnie udowodniła, że ma dostęp do tego samego emaila. W każdym agencie, którego projektuję, klasyfikuję działania według dostępu, jaki przyznają.
Podczas pierwszego incydentu na produkcji kod weryfikacyjny wygasał, gdy rozmowa nadal zbierała pozostałe dane. System CVing go odrzucał, nasz wciąż uznawał go za ważny. Asystent kazał kandydatowi sprawdzać skrzynkę, do której nic nie przychodziło. Na stronie logowanie jest na początku. W rozmowie każde kolejne pytanie zużywa czas ważności weryfikacji. Od tamtej pory proszę o kod na końcu, tuż przed wysłaniem zgłoszenia. Kiedy system po drugiej stronie mówi „nie”, nasz mu wierzy.
Prompt prosił model o rozpoznanie kodu weryfikacyjnego po jego formie. Na produkcji imię zawierające cyfry mogło przejść jako kod. Oddaliśmy ocenie modelu regułę, którą dwie linie kodu sprawdzają zawsze tak samo. Ponieważ dobrze rozumiał rozmowę, wydawało się, że potrafi też sprawdzać poprawność danych. Dziś czytam każdy prompt ponownie i szukam zdań, które każą modelowi decydować, czy dane są poprawne. Przenoszę je do kodu. W CVing ta sama kontrola odrzuca też wartości, które nie mogą być imieniem.
Link w ogłoszeniu zawiera ofertę, na którą zgłasza się kandydat. Dociera w pierwszej wiadomości. Przy długim zgłoszeniu ta wiadomość wypadała z pamięci modelu. Wtedy model mógł wymyślić ofertę. Dłuższa pamięć tylko odsuwała problem do kolejnej wystarczająco długiej rozmowy. Dziś oferta jest zapisywana na początku rozmowy i ma pierwszeństwo przed wszystkim, co pamięta model. Od tamtej pory tak samo traktuję każdą daną, która decyduje, dokąd trafi działanie.
// bez liczb o konwersji: nie mam żadnej zmierzonej.