Kiedy dziekanat odpowiada w sekundy, a nie w godziny [Case study Uniwersytetu SWPS]

Jak Craftware zbudował dla Uniwersytetu SWPS agenta obsługi studenta na platformie Salesforce?

Wąskie gardło nie brało się z braku kompetencji zespołu. Brało się z arytmetyki. Studentów przybywa, spraw razem z nimi, a doba wciąż ma tyle samo godzin. W praktyce składało się na to kilka trudności.

Po pierwsze, większość pytań się powtarzała. Odpowiedź zwykle znajdowała się już w regulaminie lub artykule bazy wiedzy, ale za każdym razem pracownik musiał ją odszukać, przeredagować i dopasować do sytuacji konkretnej osoby studiującej. Po drugie, brakowało wspólnego standardu. Dwoje pracowników mogło odpowiedzieć na to samo pytanie inaczej: innym tonem, z różnym poziomem szczegółowości, w odmiennej strukturze, czasem inaczej interpretując ten sam przepis lub kładąc nacisk na inne kwestie. Po trzecie, liczba spraw rosła sezonowo. W czasie rekrutacji, sesji i obron oraz w terminach składania podań związanych z tokiem studiów bieżąca obsługa zamieniała się w zator odczuwalny zarówno przez osoby studiujące, jak i pracowników.

Koszt zaniechania łatwo przewidzieć. Utrzymanie starego modelu prędzej czy później wymusiłoby zatrudnianie kolejnych osób w tempie, w jakim rośnie liczba zapytań. Byłoby to rozwiązywanie problemu skali przez dokładanie rąk do pracy, a nie przez zmianę sposobu pracy.

Nie sprzedaliśmy uczelni licencji z instrukcją obsługi w załączniku. Wzięliśmy odpowiedzialność za całą zmianę procesu wsparcia: od zrozumienia, jak on naprawdę przebiega, po jego działanie na produkcji i dalszy rozwój. Rozwiązanie objęło trzy warstwy: audyt i architekturę, budowę i integrację oraz utrzymanie i rozwój.

To, co odróżnia nasze podejście, zaczyna się jeszcze przed pierwszą linijką konfiguracji. Nie podłączamy sztucznej inteligencji do nieuporządkowanych danych z nadzieją, że jakoś to będzie. Zaczęliśmy od audytu i uporządkowania uczelnianej bazy wiedzy. Na warsztatach oceniliśmy jakość poszczególnych artykułów i przygotowaliśmy je tak, żeby dobrze czytała je maszyna. To nie kosmetyka. Model, który opiera się na treści niekompletnej albo nieaktualnej, odpowie równie niekompletnie i nieaktualnie. Zrobi to przy tym płynnym, przekonującym zdaniem, które trudno podważyć. Uporządkowanie źródeł, zanim uruchomi się agenta, to najtańsze zabezpieczenie przed błędnymi odpowiedziami. Dla uczelni oznaczało ono trafne, poparte źródłami odpowiedzi już od startu.

Druga zasada brzmi prosto: jak najmniej kodu, jak najwięcej gotowych mechanizmów platformy. Salesforce daje wiele narzędzi konfiguracyjnych i po nie sięgamy najpierw. Kod piszemy tam, gdzie naprawdę rozwiązuje problem nie do rozwiązania konfiguracją. Dzięki temu system jest tańszy w utrzymaniu i łatwiejszy w rozwoju. O utrzymaniu myślimy zresztą od pierwszego dnia, nie po wdrożeniu.

Trzecia zasada dotyczy ludzi, którzy z systemu korzystają. Nie zamknęliśmy całej logiki w rękach działu IT. Część oddaliśmy pracownikom. Wdrożony komponent pozwala im samodzielnie tworzyć, porządkować i uruchamiać własne polecenia dla agenta. Mogą więc dopasować jego działanie do zadań, które znają najlepiej, i nie czekają na kolejne wydanie systemu.

Ciągłość obsługi studentów traktowaliśmy jako warunek, nie jako miły dodatek. Dlatego wdrożenie rozłożyliśmy na krótkie etapy. Uczelnia w żadnym momencie nie została z systemem działającym w połowie.

Funkcje udostępniliśmy stopniowo, etap po etapie. Jedną z nich jest akcja, która podsumowuje wcześniejsze kontakty studenta z uczelnią. Pracownik dostaje obraz sytuacji od razu i nie musi przekopywać archiwum korespondencji ani spraw. Takie wczesne ułatwienie działa podwójnie: realnie odciąża zespół i buduje zaufanie do narzędzia, zanim wejdą jego trudniejsze funkcje.

Zespół uczelni włączaliśmy w pracę tam, gdzie jego wiedza o procesach była nie do zastąpienia. Wszędzie indziej oszczędzaliśmy jego czas. Adopcja to zwykle najtrudniejszy element wdrożenia AI. Tutaj pomogło samo rozwiązanie: agent skracał codzienną pracę i podawał gotowe propozycje odpowiedzi, więc pracownicy szybko zobaczyli w nim realne wsparcie, a nie kolejny obowiązek. Działał w narzędziu, które już znali, i uruchamiali go wprost na rekordach, bez zmiany dotychczasowych przyzwyczajeń.

Ta część jest dla tych, którzy pytają nie o to, co zbudowaliśmy, ale jak. Opisuję architekturę i wzorce, których użyliśmy, i pomijam szczegóły konfiguracji właściwe dla tej uczelni. Całość opieraliśmy na oficjalnych dobrych praktykach Salesforce dla RAG w Agentforce.

Rys. 1. Droga od źródeł danych do odpowiedzi i akcji w Service Cloud.

Dwa światy RAG: przygotowanie i użycie

RAG działa w dwóch etapach, rozdzielonych w czasie. Pierwszy to etap przygotowania danych, wykonywany przed użyciem rozwiązania i ponawiany po aktualizacji źródeł lub indeksu. Dane trafiają do Data 360, gdzie system dzieli je na fragmenty (chunki) i zamienia na wektory, czyli liczbowe zapisy znaczenia, które maszyna potrafi porównywać. Drugi etap zachodzi w czasie rzeczywistym, przy każdym zapytaniu. Retriever dostaje zapytanie z szablonu promptu, zamienia je na wektor, wyszukuje w indeksie najlepiej pasujące fragmenty i dokłada je do promptu. Tak uzupełniony prompt trafia do modelu językowego, który układa odpowiedź. Ta prosta z pozoru sekwencja jest fundamentem całej reszty.

Rys. 2. Pięć kroków, które dzieją się przy każdym pytaniu.

Szybka ścieżka czy pełna kontrola: Agentforce Data Library kontra Data 360

Salesforce daje najkrótszą drogę do działającego RAG: Agentforce Data Library. Dodanie takiej biblioteki tworzy od razu cały komplet elementów: data streams (strumienie danych), mapowania danych, vector store (magazyn wektorowy, czyli bazę, w której trzymane są wektory i po której odbywa się wyszukiwanie znaczeniowe), search index (indeks wyszukiwania), retriever, prompt template (szablon promptu) oraz akcję agenta — wszystko na ustawieniach domyślnych. To dobry punkt startu, ale ma granice. Może korzystać m.in. z artykułów Salesforce Knowledge, przesłanych plików, wyszukiwania internetowego lub niestandardowego retrievera, ale oferuje mniejsze możliwości konfiguracji niż ręczne przygotowanie rozwiązania w Data 360.

Tam, gdzie potrzebowaliśmy większej kontroli nad tym, co i jak agent pobiera, korzystaliśmy z ręcznej konfiguracji w Data 360. Zgadza się to z naszą zasadą, żeby sięgać po kod tylko tam, gdzie jest naprawdę potrzebny. Nie mnożymy złożoności bez potrzeby, ale też nie udajemy, że ustawienia domyślne wystarczą do każdego zadania.

Jakość źródła, czyli dlaczego audyt bazy wiedzy jest sprawą techniczną

Wróćmy na chwilę do warsztatów z bazą wiedzy, bo z perspektywy inżynierskiej nie były sprawą poboczną. Sposób, w jaki napisano artykuł, wprost decyduje o tym, czy agent go znajdzie i dobrze zrozumie. Dobra treść jest konkretna i szczegółowa. Zawiera realne przykłady, ma logicznie powiązane akapity i sensowne nagłówki. Długie informacje rozkłada się na osobne pola: osobno pytanie, osobno opis, osobno rozwiązanie. Do tego dochodzi higiena, czyli regularne przeglądy i wersjonowanie. Baza wiedzy, której nikt nie pielęgnuje, po roku wprowadza w błąd. Porządkowanie treści nie jest więc etapem przed właściwą pracą techniczną. Ono jest właściwą pracą techniczną.

Indeks wyszukiwania i cztery role, jakie może pełnić pole

Budując indeks, Data 360 dzieli treść na chunki i zamienia je na wektory. Pojedynczy wektor nie odda znaczenia całego długiego dokumentu, więc każdy chunk niesie jeden spójny, zamknięty fakt. Projektując indeks, każdemu polu trzeba świadomie przypisać jedną z czterech ról:

•  Indexed fields (pola indeksowane) — system dzieli je na chunki i wektoryzuje; to one biorą udział w wyszukiwaniu znaczeniowym i tylko one są przeszukiwane semantycznie.

•  Prepend fields (pola dołączane) — dokleja je na początku każdego chunku, żeby łatwiej było rozpoznać, z czego pochodzi dany fragment; nie są przeszukiwane, ale dają kontekst.

•  Filter fields (pola filtrujące) — trafiają do indeksu bez wektoryzacji i służą wyłącznie do zawężania wyników po konkretnej wartości, na przykład typie dokumentu.

•  Return fields (pola zwracane) — wskazujemy je na poziomie retrievera; to ich zawartość wraca do promptu jako materiał dla modelu.

Jest tu pułapka. Kusi, żeby indeksować pola z samymi kategoriami, ale dają one krótkie fragmenty bez kontekstu i psują wyszukiwanie. Kategorie lepiej sprawdzają się jako pola dołączane (prepend) niż jako indeksowane.

Wyszukiwanie hybrydowe i kwestia dwóch języków

W praktyce mamy do wyboru dwa podejścia. Wyszukiwanie wektorowe, czyli semantyczne, porównuje znaczenie i dlatego rozumie parafrazy — wie, że „jak się zalogować” i „jak wejść na konto” pytają o to samo, ale bywa głuche na dokładne nazwy własne, numery i terminy. Wyszukiwanie po słowach kluczowych, czyli leksykalne, działa odwrotnie: szuka dokładnego dopasowania ciągu znaków, więc świetnie radzi sobie z terminami i numerami, lecz gubi synonimy i omówienia. Wyszukiwanie hybrydowe łączy oba naraz — bierze trafność znaczeniową z wektorów i precyzję z dopasowania słów. Dlatego tam, gdzie liczyła się precyzja, sięgaliśmy właśnie po nie. Ma to swoją cenę: podnosi trafność, ale zwiększa opóźnienie i zużycie zasobów, więc stosujemy je świadomie, a nie wszędzie z automatu.

Osobny wątek, dla uczelni ważny, to wielojęzyczność. Regulaminy i część korespondencji są po polsku, inne treści po angielsku. Wielojęzyczny model wektorów zachowuje podobieństwo znaczeń między językami. Pytanie po polsku potrafi więc znaleźć trafną treść zapisaną po angielsku i odwrotnie. Gdy odpowiedź ma zostać w jednym języku, język można narzucić filtrem.

Nie znajdą tu Państwo procentów ani kwot. Zamiast obiecywać dokładność, której jeszcze rzetelnie nie zmierzyliśmy, opiszemy zmianę tak, jak wygląda w codziennej pracy.

Najmocniej widać ją w czasie. Przygotowanie odpowiedzi dla osoby studiującej nie wymaga już każdorazowego pisania jej od zera. W ciągu kilku sekund agent przygotowuje projekt na podstawie źródeł uczelnianych. Odpowiedź nie jest publikowana automatycznie: pracownik Centrum Spraw Studenckich sprawdza ją, w razie potrzeby uzupełnia ją i podejmuje ostateczną decyzję o wysłaniu. Agent pozostaje narzędziem wspierającym zespół, a zaoszczędzony czas może zostać przeznaczony na indywidualne, bardziej złożone sprawy wymagające konsultacji z kilkoma biurami.

Druga zmiana dotyczy wglądu. Pracownik nie odtwarza już historii osoby studiującej z rozproszonych spraw i wiadomości, lecz od razu otrzymuje jej podsumowanie. Trzecia dotyczy spójności: projekty odpowiedzi czerpią z tych samych, uporządkowanych źródeł, a ich ostateczny kształt i wysłanie pozostają po stronie pracownika. Dzięki temu Centrum Spraw Studenckich może sprawniej obsługiwać powtarzalne pytania, zachowując czas na sprawy wymagające indywidualnego podejścia.

Pełniejsze dane pokażemy, gdy pomiar obejmie dojrzałe użycie na kolejnych obszarach obsługi.

Już wkrótce dostępny będzie tutaj plik PDF z pełną wersją Case Study. W nim między innymi:

• Streszczenie
• Omówienie cyklu życia studenta

Przedstawienie dodatkowych etapów realizacji:

• Retrievery, filtry i granice tego, co da się wyklikać
• Ensemble retriever, czyli baza wiedzy i pliki w jednym strumieniu
• RAG w kontekście jednego rekordu
• Akcje, czyli ręce agenta
• Jak sprawdzamy, że to naprawdę działa