Chatboty w bankowości. Dlaczego w Commerzbank wybraliśmy Symphony

Chatboty mogą wspomagać pracę, dostarczać rozrywki, służyć informacją, a nawet zamawiać jedzenie czy też wysyłać SMS-y. Słowem: chatboty mogą zrobić wszystko, czego odbiorca końcowy zapragnie, a co zespół developerski będzie w stanie stworzyć. Aktualnie można spotkać kilka rodzajów chatbotów: od oferujących rozmowę w formie naturalnej pogawędki, całkiem sensownie udającej rozmowę z drugim człowiekiem, po takie bardziej „mrukliwe”, reagujące jedynie na wyspecyfikowane komendy i wykonujące ściśle określoną funkcjonalność. 

Bartosz Iskierka. Lead Software Engineer w Commerzbank AG. Zajmuje się projektowaniem i tworzeniem aplikacji wsparcia bankowości inwestycyjnej. Od 2004 roku pracujący jako programista systemów informatycznych. Rozpoczynał tworząc rozwiązania dla polskich firm telekomunikacyjnych, następnie zajmował się projektowaniem i wdrażaniem systemów e-commerce w sektorach telekomunikacyjnych w polsce i za granicą. Absolwent Politechniki Łódzkiej na wydziale Fizyki Technicznej, Informatyki, Matematyki Stosowanej.


Przykładem prostego bota może być ankieta/wywiad przeprowadzana/-y na stronach przychodni lekarskich. Taki automat dzięki zadaniu użytkownikowi serii pytań potrafi postawić diagnozę i zaproponować leczenie, oczywiście o ile udzielone odpowiedzi nie będą wskazywały na poważny stan wymagający konsultacji z lekarzem. Wspomniana aplikacja z pewnością ukrywa w tle zaawansowany system ekspertowy, a sam robot jest zgrabnym, zrozumiałym dla normalnego człowieka interfejsem. Zastosowanie botów jest o wiele szersze niż jedynie przeprowadzanie ankiet i podejmowanie decyzji.

Cena wymiany waluty

W bankach chatboty znalazły zastosowanie w komunikatorach, gdzie dostarczają narzędzi, które mogą wspierać pracę zespołów w wykonywaniu ich codziennych zadań. O wiele łatwiej napisać w okienku czatu komunikatora pytanie o listę dzisiejszych zadań, sprawdzenie zaplanowanych spotkań czy nawet przetłumaczyć podany tekst na inny język, niż wchodzić na odpowiednie strony i wyszukiwać ręcznie potrzebnych informacji. Boty często potrafią zapamiętać kontekst rozmowy i poruszać się w ramach niego, dzięki czemu dobrze nadają się do przeprowadzania różnego rodzaju ankiet lub obsługi pomocy kontekstowej. 

Miejsce dla wirtualnych asystentów znalazło się również w naszym banku – przykładem może być News Bot, którego zadaniem jest dostarczanie wiadomości ze świata, agregując je z różnych źródeł. Użytkownik może sprecyzować swoje wyszukiwanie podając region, słowa kluczowe, które go interesują, wskazać zakres dat, z których chciałby zobaczyć wiadomości, czy nawet wybrać język wiadomości. To wszystko jest dostępne w standardowym, używanym przez niego na co dzień komunikatorze. Całość sprowadza się do wybrania odpowiedniego bota z listy użytkowników bota i rozpoczęcie zwykłego czatu. Ostatecznie użytkownik otrzymuje newsy wyświetlone w bardzo czytelny i przejrzysty sposób, mając jednocześnie możliwość poproszenia o zapisanie ich do wybranego formatu plików.

Innym przykładem bota jest taki, który można dołączyć do konwersacji między dwoma lub więcej osobami i jeśli użytkownik wyda odpowiednie polecenia, bot będzie tłumaczył wpisywane przez niego zdania na wybrany język. Takie rozwiązanie bardzo ułatwia współpracę w wielojęzycznych zespołach, w szczególności, kiedy jedna ze stron nie czuje się dość komfortowo, żeby samemu pisać w innym języku.

Bardzo ciekawym przykładem bota wykorzystywanego w bankowości inwestycyjnej jest rozwiązanie zaprezentowane podczas oficjalnej konferencji Symphony. Polega ono na stworzeniu takiego bota, który będzie wspierał handlowca bankowego obsługującego sprzedaż dowolnych aktywów różnym klientom korporacyjnym. Tacy handlowcy już teraz dostają pytania o cenę jakiejś wymiany dla zadanych kwot (rzędu milionów euro) na różnego rodzaju komunikatorach. 

Jak to działa w tradycyjnym systemie: Klient reprezentujący instytucję, inny bank lub dużą korporację wysyła do handlowca prośbę o możliwość i wycenę wymiany. Przedstawiciel banku otwiera odpowiednie serwisy, w których najpierw sprawdza dane klienta i jego uprawnienia do wykonania takiej transakcji, a potem, jeśli taka transakcja jest możliwa do wykonania, pobiera z innego systemu koszt wymiany i ostatecznie negocjuje z klientem cenę. Jeśli dojdą do porozumienia, to transakcja jest zawierana. To wszystko jest jednak czasochłonne i bardzo angażuje handlowca, przez co może on wykonywać tylko jedną transakcję naraz.

Przedstawione przez Symphony rozwiązanie mocno optymalizuje ten proces przez użycie chatbota: 

Pytanie przychodzące przez klienta na odpowiednim kanale komunikacji, do którego przypisany jest również nasz chatbot, jest analizowane w tle i odpowiednio klasyfikowane. O ile w tym miejscu nie następuje komunikacja samego chatbota z klientem (tym zajmuje się nadal handlowiec), to w tle chatbot uruchamia cały proces weryfikacji klienta i na osobnym kanale komunikuje się z handlowcem. Przesyła mu informacje o wynikach analiz i możliwościach handlowych klienta.

Dzięki odpowiednio skonfigurowanemu kontu użytkownika zna jego identyfikator w systemach bankowych i jest w stanie od razu sprawdzić historię i podstawowe parametry konieczne do potwierdzenia wymiany. Na życzenie handlowca może dokonać dodatkowych weryfikacji lub zmienić parametry w celu sprawdzenia innej oferty. Handlowiec w tym czasie może obsługiwać inną transakcję, dla której również na innym kanale chatbot dostarczy szczegółowych informacji. Przedstawiciel może zmodyfikować ofertę lub nie i zaprezentować ją klientowi. Jeśli klient zgodzi się, wpisując powiedzmy „biorę”, chatbot automatycznie sfinalizuje transakcję po przedstawionym kursie. 

Takie użycie chatbotów znacznie zwiększa szybkość obsługiwania transakcji, a tym samym stwarza więcej możliwości na pozyskanie nowych klientów i wykonanie więcej operacji przynoszących zyski bankowi. 

Wybór języka

Chatboty mogą być tworzone praktycznie dla każdej platformy komunikacyjnej wykorzystującej odpowiednie protokoły komunikacyjne (XMPP, WebSocket), mogą podłączyć się do wielu popularnych komunikatorów, takich jak Messenger, Slack, Smoch, a także mogą być wykorzystane do prostych czatów na stronach. W ramach bankowości inwestycyjnej skorzystaliśmy z używanego wewnętrznie komunikatora Symphony (wykorzystującego technologię IP Messagiging i WebRTC). Na potrzeby artykułu omówię, jak w prosty sposób stworzyć bota przy pomocy tego właśnie komunikatora.

Do stworzenia chatbota konieczne jest napisanie aplikacji uruchamianej w dowolnym miejscu, która będzie potrafiła zautentykować się w jednym z serwerów Symphony. Dostarczone od producenta API pozwala na wybór języka programowania wspieranego przez SDK spośród:

  • Node.js,
  • Java,
  • .NET,
  • Python.

W naszym przypadku skorzystamy z języka Java. Może to być zwykła javowa klasa main korzystająca z bibliotek Symphony (oferowanych w różnych SDK). W naszym przypadku do stworzenia aplikacji wykorzystamy framework Spring – SpringBoot, Spring Web, Spring Integration. Dodatkowe biblioteki pomocnicze zależą już od specyfiki czynności realizowanych przez naszego bota.

W pierwszej kolejności konieczne jest wygenerowanie nowego projektu, w którym będziemy tworzyć naszą aplikację. W IntelliJ wybieramy nowy projekt maven. Dla naszych potrzeb struktura wygenerowana automatycznie będzie wystarczająca. Do naszego projektu warto dodać zależności do spring boota:

  • spring-boot-starter

Oraz zależności do symphony:

  • symphony-api-client-java
  • symphony-client

W pierwszej kolejności nasza aplikacja musi wczytać klucze autentykacyjne dostarczone przez administratorów serwera symphony i zautentykować się w nim.

Najpierw konieczne jest wygenerowanie requestu autentykującego zawierającego informacje o użytkowniku zgodnym z użytkownikiem istniejącym na serwerze, expiration time – nie dłuższym niż 5 minut i podpisie z prywatnego klucza RSA odpowiadającego temu znajdującemu się na serwerze.

Przykładowa implementacja została zaprezentowana na stronie Symphony:

Token otrzymany w wyniku wykonania powyższego kodu w postaci:

Używamy do wysyłania requestu atentykującego do serwera symphony:

Jak parametr (w formacie JSON) podając powyższy klucz:

W następnej kolejności aplikacja musi wykonać request z otrzymanym sessionTokenem do key managera:

Parametrem podobnie jak poprzednio jest JSON zawierający odpowiedni token:

Otrzymany w ten sposób token pozwala nam bez przeszkód komunikować się z serwerem komunikatora. Aby utworzyć instancję klienta dla naszego bota wykorzystujemy uzyskane powyżej informacje autentykacyjne i konfigurację dla naszego bota podając je w wywołaniu:

Zasada działania bota polega na ciągłym nasłuchu utworzonego kanału między klientem i serwerem. W ten sposób bot może reagować na wszystko co zostanie do niego wysłane. W przypadku shymphony są one opisane odpowiednimi interfacami Listenera. Dwa podstawowe listenery które możemy zaimplementować to:

  • ImListener – reaguje na wiadomości przychodzące do bota,
  • RoomListener – reaguje na zdarzenia.

Dodajemy je do naszego clienta przez wywołanie metody addListeners:

Mając tak zbudowanego clienta dla naszego bota możemy rozpocząć implementację wymaganych funkcjonalności.

Wiadomość przychodząca do serwera zawiera komplet informacji o użytkowniku, który ją wysłał, treść wysłanej wiadomości, a nawet załączniki w niej zawarte – wszystko to jest opakowane w obiekt InboundMessage. Możemy do nich dostać się przez:

Mając te informacje możemy w łatwy sposób obsłużyć request przychodzący z serwera. Najprostszym przykładem jest zbudowanie i odesłanie odpowiedzi opakowując ją w obiekt: OutboundMessage:

Architektura bota (CQRS)

Jeśli chcielibyśmy, żeby bot reagował na konkretne komendy w inny sposób, a jednocześnie potrafił obsługiwać skomplikowane składniowo polecenia, warto przyjrzeć się wzorcowi CQRS (Command Query Responsibility Segregation). Traktując w takim podejściu wysyłaną przez użytkownika wiadomość jako obiekt wejściowy, przetwarzamy go we wzorcu CQRS.
W pierwszej kolejności implementujemy klasę handler, która ma za zadanie sprawdzić, czy dana komenda jest przez nią obsługiwana, a dalej metodę handle, która dany obiekt przetworzy.

Załóżmy, że użytkownik chciałby zapytać o cenę akcji. W takim przypadku możemy spodziewać się komendy w stylu:

“Podaj cenę akcji IBM”

Gdzie:

  • „podaj cenę” – jest nazwą czynności,
  • „akcji” – jest specyfikacją produktu finansowego,
  • „IBM” – jest identyfikatorem produktu finansowego.

Moglibyśmy tutaj dołożyć kolejne parametry specyfikujące, np. datę lub giełdę, której zapytanie dotyczy. Nasza implementacją Handlera (StocksPriceCommandHandler) mogłaby wyglądać następująco:

Wykorzystanie NLP w botach

W chatbotach jedną z pożądanych funkcjonalności jest symulacja normalnej rozmowy jak ze zwykłym człowiekiem. I nawet jeśli jest to bot realizujący ściśle określone zadania biznesowe, to warto żeby znał i rozpoznawał przynajmniej kilka podstawowych zwrotów z mowy potocznej. Z pomocą przychodzi tutaj NLU czyli (z ang. natural language understanding). NLU jest jednym z zagadnień NLP (z ang. natural language processing) i jego zadaniem jest klasyfikacja wprowadzonego tekstu na podstawie dostarczonego zbioru danych klasyfikujących. W stworzeniu takiego rozwiązania pomaga wiele bibliotek i/lub aplikacji takich jak Stanford Library, RASA, Siri, Alexa, czy Google Assistant.

Poniżej pokażemy wykorzystanie rozwiązania proponowanego przez firmę RASA. RASA oferuje nam zewnętrzny serwer Pythona, na którym poprzez REST wystawiona jest usługa interpretacji tekstu wejściowego na odpowiednią klasyfikację na podstawie modelu dostarczonego w naszym projekcie. Proces analizy tekstu wygląda tak:

Do utworzenia i wystartowania podstawowego projektu NLP przy użyciu RASA potrzebujemy naprawdę nie dużo. Instalujemy RASA zgodnie z instrukcją lub ściągamy i używamy gotowego docker image. Następnie Tworzymy nowy projekt:

To spowoduje utworzenie struktury dla nowego projektu z domyślnymi ustawieniami praktycznie gotowego do pracy.

Dalej trzeba stworzyć zestaw danych do trenowania naszego modelu. W tym obszarze RASA obsługuje dwa możliwe formaty danych.

Markdown Format

Można również używać wyrażeń regularnych:

Przy tworzeniu danych można również używać parametrów:

JSON Format

Ten format jest trochę bardziej skomplikowany w budowie, dostarcza jednak takie same funkcjonalności:

Podstawowy zestaw treningowy powinien zawierać przynajmniej kilka sekcji intent, w których znajdzie przynajmniej kilka wersji pytania/zdania/formuły, która będzie prowadziła do tego samego wyniku. Na przykład:

Po zbudowaniu danych warto zbudować stories, które są przykładami rzeczywistych rozmów. Na tej podstawie wytrenowany model będzie mógł podejmować decyzję, którą z odpowiedzi wybrać.

Teraz możemy wytrenować model:

Teraz możemy sprawdzić działanie naszego modelu przez narzędzia dostarczony wraz z RASA:

lub wystartować REST service, który udostępnia API do wykonywania zapytań do RASA, a także umożliwia wykonywanie różnego rodzaju akcji na samym modelu.

Teraz możemy z naszej aplikacji wywoływać zapytania do modelu przy pomocy REST.

W odpowiedzi RASA wyśle nam informację o klasyfikacji, jaką przyznała danemu tekstowi i o tym, z jaką pewnością tę klasyfikację wybrała.

Dzięki temu wiemy, że RASA sklasyfikowała tekst wejściowy jak powitanie i teraz możemy dowolnie na nie zareagować na podstawie wyuczonego modelu, wybierając jedną z możliwych odpowiedzi.

Dodatkowo modele można walidować i ewaluować, żeby poprawić ich efektywność. Jednym z najlepszych sposobów poprawienia efektywności modelu jest jego douczanie na podstawie już wcześniej odbytych konwersacji. W tym celu trzeba zapisywać logi z konwersacji w takiej formie, żeby w łatwy sposób mogła być przerobiona na kolejne zestawy danych treningowych. Dobrze jest też poprosić użytkownika końcowego o określenie, w jakim stopniu rozmowa była satysfakcjonująca. W ten sposób wzbogacamy odpowiedzi chatbota i poprawiamy trafność dopasowań.

Podsumowanie

W bankowości inwestycyjnej najbardziej pomocne jest samo NLU, czyli rozpoznawanie życzeń klienta, rozbijanie ich na poszczególne kategorie i klasyfikowanie parametrów. Dzięki takiemu użyciu jesteśmy w stanie szybko reagować na potrzeby użytkowników, dostarczając do odpowiedniego procesu taki zestaw danych jaki jest wymagany żeby sprawdzić i/lub przeprowadzić daną operację.


Zdjęcie główne artykułu pochodzi z unsplash.com.

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
Czy blockchain to dobre miejsce dla juniorów? Devdebata