Asystent AI na stronie dewelopera ma jedno zadanie: odpowiedzieć klientowi, które mieszkania są wolne, ile kosztują i czym się różnią. Jeśli powie, że zarezerwowany lokal jest dostępny, albo poda cenę o kilkadziesiąt tysięcy niższą od cennika, dział sprzedaży ma problem, a nie oszczędność czasu.
Ten tekst opisuje, co zrobiliśmy z takim asystentem u dewelopera mieszkaniowego z trzema inwestycjami i ok. 210 lokalami w ofercie. Najważniejszy wniosek jest mało efektowny: większość zmyśleń nie wynikała ze słabości modelu, tylko z tego, jakie dane do niego trafiały.
Jak wyglądały błędy
Poprzednia wersja asystenta działała i często odpowiadała dobrze. W próbie porównawczej wyszły jednak błędy, których w sprzedaży nie da się zaakceptować:
- lokal zarezerwowany opisany jako dostępny,
- na pytanie o trzy pokoje lista, w której dwa mieszkania miały dwa pokoje,
- zawyżona liczba wolnych mieszkań, bo system liczył wpisy bazy wiedzy zamiast lokali,
- terminy oddania z prospektów, które już minęły, podawane jako aktualne,
- przy pytaniu z budżetem zgadywana cena „od około” zamiast najtańszego lokalu z oferty.
Kiedy prześledziliśmy każdy przypadek, za większością stał ten sam mechanizm. Model nie miał w kontekście pełnej, aktualnej informacji, więc uzupełniał luki czymś prawdopodobnym. Baza wiedzy zawierała liczby wolnych lokali i widełki cen sprzed miesięcy. Wyszukiwanie semantyczne zwracało kilka podobnych fragmentów zamiast wszystkich pasujących mieszkań. W jednym miejscu funkcja w bazie podstawiała opis najstarszego lokalu jako opis całej inwestycji, więc model dostawał w danych mieszkanie sprzedane dawno temu.
Zasada pierwsza: liczby tylko z danych na żywo
Podzieliliśmy pracę między dwa mechanizmy. Twarde kryteria, czyli liczbę pokoi, budżet i inwestycję, rozpoznaje deterministyczny kod, a pasujące lokale pobiera zwykłe zapytanie SQL na aktualnej ofercie. Model dostaje pełną listę dopasowań razem z ich łączną liczbą, w osobnej sekcji danych. Jeśli nic nie pasuje, dane mówią to wprost i podsuwają najbliższe opcje, żeby model nie musiał zgadywać.
Wyszukiwanie wektorowe zostało do tego, w czym jest dobre: pytań opisowych o okolicę, standard wykończenia czy proces zakupu. Nie decyduje o liczbach, cenach ani statusach.
Bazę wiedzy przepisaliśmy rzeczowo. Wypadły z niej liczby wolnych lokali, widełki cen i marketingowe wykrzykniki. Zostały fakty, a terminy z prospektów dostały dopisek „według prospektu”. Ofertę importujemy co godzinę ze źródła dewelopera, a sprzedane lokale nie zostają w danych ze starą ceną.
Zasada druga: dane w formie, której model nie przekręci
Sposób zapisu danych w kontekście ma większe znaczenie, niż się wydaje. Każdy lokal to jedna linijka zapisana po ludzku: numer, pokoje, metraż z polskim przecinkiem, piętro i cena. Lokal spoza oferty pojawia się bez ceny, za to ze statusem, więc pytanie o konkretny numer dostaje prawdziwą odpowiedź, nawet jeśli mieszkanie jest sprzedane.
Dwie obserwacje z testów zaskoczyły nas najbardziej. Pierwsza: przykłady w instrukcji z realistycznie wyglądającymi liczbami szkodzą. Model potrafił skleić z nich lokal, który nie istnieje, więc przykłady zamieniliśmy na wzory z polami do uzupełnienia. Druga: gdy inwestycja miała tylko kilka wolnych mieszkań, a w danych był sam skrót bez numerów, model dopisywał numer i piętro lokalu, który znał z innego miejsca. Zakaz w instrukcji nie pomógł. Pomogło dopiero podanie tych kilku lokali w pełnych linijkach.
Zasada trzecia: obrona, która nie zależy od modelu
Asystent na publicznej stronie dostaje też pytania, które mają go wyprowadzić z roli. Zamiast liczyć, że model zawsze odmówi, dołożyliśmy warstwy działające niezależnie od niego:
- dane oferty i bazy wiedzy trafiają do wydzielonego bloku, z którego tekst w danych nie może „wyjść” i udawać instrukcji,
- wąski filtr przed modelem rozpoznaje jednoznaczne próby wyciągnięcia instrukcji i odpowiada stałym tekstem, bez wywołania modelu i bez kosztu,
- strażnik na wyjściu przerywa odpowiedź w trakcie strumieniowania, jeśli zaczyna ona powtarzać instrukcje, a widget podmienia dymek na odmowę,
- widget zamienia na zwykły tekst każdy link do domeny spoza listy dozwolonych.
Filtr wejścia jest celowo wąski. Lepiej przepuścić podejrzane pytanie do modelu, który i tak ma swoje zabezpieczenia, niż zablokować klientowi zwykłe pytanie o zasady rezerwacji. Uczciwie trzeba też dodać, że współczesne małe modele odpierają typowe ataki nawet bez tych warstw. Warstwy dają co innego: przewidywalność niezależną od modelu, więc model można wymienić bez ponownego budowania zabezpieczeń.
Jak to mierzymy
Bez pomiaru każda z tych zmian byłaby tylko opinią. Zbudowaliśmy więc test porównawczy: 106 scenariuszy w 16 kategoriach, od pytań ogólnych i kryteriów, przez konkretne lokale, porównania, parking i proces zakupu, po rozmowy wieloturowe, literówki, pytania po angielsku i próby nadużyć.
Obie wersje asystenta, stara i nowa, odpowiadają na te same pytania na tej samej kopii oferty i na tym samym modelu, z wyłączonym cache podpowiedzi. Potem ocena idzie dwutorowo:
- Fakty sprawdza program, nie model. Każda cena, kwota i metraż w odpowiedzi musi istnieć w bazie, a lokal nazwany w zdaniu musi być w ofercie. Osobny test sprawdza, czy numer, pokoje, metraż, piętro i cena w jednym zdaniu należą do tego samego lokalu. Każda z tych liczb osobno może być prawdziwa, a ich kombinacja zmyślona.
- Styl i pomocność ocenia model-sędzia na ślepo. Widzi skrót danych oferty i obie rozmowy jako A i B w losowej kolejności, ocenia je w pięciu wymiarach i wskazuje lepszą.
Sędzia też się myli. Ponowna ocena tych samych rozmów potrafi przesunąć wynik o kilka, a w skrajnym przypadku o około dziesięć wygranych. Dlatego decyzje opieramy na tym, co liczy program, a werdykt sędziego traktujemy jako drugi sygnał.
Wyniki
W pierwszej rundzie liczba odpowiedzi ze zmyślonymi faktami spadła z 5 do 0. W trzeciej rundzie nowa wersja wygrała 81 razy, zremisowała 18 i przegrała 6, a po ponownej ślepej ocenie było to 89, 11 i 6. Średnie oceny sędziego w skali 1-5 wzrosły dla trafności z 3,38 do 4,16, a dla zwięzłości z 3,04 do 4,65. Mediana długości odpowiedzi spadła z 403 do 178 znaków, bo klient w czacie nie chce czytać eseju.
Osobno zoptymalizowaliśmy koszt. Stałą część instrukcji przenieśliśmy na początek, a zmienne dane za nią, dzięki czemu cache po stronie dostawcy obejmuje dłuższy wspólny początek. Koszt jednej odpowiedzi spadł z 0,268 do 0,109 centa, a mediana czasu do pierwszego słowa z 1,6 do 0,85 s. Test jednostkowy pilnuje teraz, żeby nikt przypadkiem nie przestawił kolejności.
Czego się nauczyliśmy
Zakaz w instrukcji okazał się najsłabszym narzędziem. W podsumowaniach rozmów dla działu sprzedaży model kończył 37 z 54 tekstów tą samą błędną formułką, mimo wyraźnego zakazu. Zakaz zmniejszył problem, ale go nie usunął. Pomogły przykłady dobrych podsumowań, a resztę wycina kod. Na 71 kolejnych podsumowaniach formułka nie pojawiła się ani razu.
Cache potrafi zafałszować porównanie modeli. Przy pierwszym teście sześciu modeli cache podpowiedzi zwracał każdemu z nich odpowiedź zapisaną wcześniej dla innego modelu. Na czas ewaluacji trzeba go wyłączać.
Koszt ewaluacji też trzeba zaprojektować. Pierwszego dnia testy z sędzią przez zewnętrzne API kosztowały ok. 18 USD. Po przeniesieniu oceny do równoległych agentów i podzieleniu rozmów na paczki pełny przebieg kosztuje ok. 0,57 USD, a 106 rozmów jest ocenionych w około minutę.
Ograniczenia
Zero zmyśleń dotyczy tego zbioru 106 scenariuszy i nie jest gwarancją na produkcji. Model wciąż ma swoje nawyki, np. kończy część odpowiedzi pytaniem „Chcesz, żebym…?”. W kilku rozmowach sędzia wolał starą wersję, bo była cieplejsza i dłużej opisywała okolicę. Wpływ asystenta na liczbę zapytań sprzedażowych zmierzymy po pełnym sezonie, a nie po kilku tygodniach.
Jeśli rozważacie asystenta AI w sprzedaży albo obsłudze klienta, zacznijcie od pytania, skąd model weźmie liczby, i od zestawu testów, zanim powstanie pierwsza wersja instrukcji. Opis całego wdrożenia jest w realizacji.
