AI & LLM Systems for Sales & Operations

Chatbot odpowiada według wcześniej zaprojektowanych ścieżek i zwykle nie ma dostępu do danych firmy. System oparty na modelu językowym pracuje na tekście, którego nie dało się przewidzieć regułą, i może odpowiadać na podstawie Waszych dokumentów oraz uruchamiać kroki w procesie.

Różnica, która ma znaczenie w praktyce: chatbota rozbudowuje się, dopisując kolejne ścieżki; system oparty na modelu rozwija się przez dane, uprawnienia i ocenę jakości odpowiedzi.

Tak — ale tylko z tych, które mu udostępnimy, i w zakresie ustalonym przed wdrożeniem. Zakres danych, uprawnienia i sposób ich przekazywania są elementem projektu systemu, a nie decyzją podejmowaną po uruchomieniu.

Model sam z siebie nie zna Waszych ofert, notatek ani dokumentacji. Żeby z nich korzystał, buduje się warstwę wyszukiwania po firmowych źródłach (RAG).

RAG (retrieval-augmented generation) to sposób pracy, w którym model przed odpowiedzią pobiera fragmenty dokumentów firmy i odpowiada na ich podstawie, podając źródła. Zamiast polegać na tym, co „wie” z treningu, system najpierw wyszukuje właściwy fragment.

Ogranicza to zmyślanie, ale go nie eliminuje: jakość odpowiedzi zależy od tego, co jest w bazie wiedzy i jak dobrze da się w niej znaleźć właściwy fragment.

Tak, i to jeden z częstszych przypadków: streszczanie historii kontaktu, porządkowanie notatek, uzupełnianie rekordów, klasyfikacja zgłoszeń.

Przy danych z CRM dwie rzeczy ustala się przed wdrożeniem: które pola w ogóle wchodzą do systemu (dane osobowe zwykle nie są potrzebne do zadania) i czy odpowiedzi respektują uprawnienia osoby pytającej.

Może — jako agent z dostępem do narzędzi, w granicach zapisanych w jego uprawnieniach. Projektujemy jednak operacje tak, by domyślnie były odwracalne: zapis do szkicu zamiast wysyłki, propozycja zmiany zamiast zmiany.

Nie budujemy systemów, w których model samodzielnie prowadzi korespondencję z klientem, ustala warunki handlowe albo składa zobowiązania.

Zasada, którą stosujemy: model przygotowuje, a człowiek zatwierdza wszystko, co wychodzi na zewnątrz lub zmienia stan zobowiązań. Im wyższa konsekwencja błędu, tym wcześniej w procesie stoi akceptacja.

Kroki pośrednie — research, streszczenie, klasyfikacja do przeglądu — zwykle nie wymagają zatwierdzania, bo błąd widać przed skutkiem u klienta.

Kilkoma mechanizmami naraz: odpowiedzi opierane na firmowych źródłach z obowiązkowym cytowaniem, jawna instrukcja „nie wiem” zamiast zgadywania, walidacja wyniku innym mechanizmem niż ten, który go wytworzył, oraz akceptacja człowieka tam, gdzie stawka jest wysoka.

Nad wszystkim stoi ewaluacja: zestaw pytań z oczekiwanymi odpowiedziami, uruchamiany po każdej zmianie promptu, modelu lub bazy wiedzy. Bez niego nie da się stwierdzić, czy system działa gorzej niż miesiąc temu.

Od opisania procesu, a nie od wyboru narzędzia: discovery, projekt systemu, prototyp na wąskim wycinku, wdrożenie i ewaluacja. Pierwszy pilotaż zwykle da się uruchomić obok istniejącego stosu, bez migracji.

Najbardziej pracochłonna i najczęściej niedoszacowana część to integracja — wynik pracy modelu musi pojawiać się tam, gdzie zespół i tak pracuje.