Jak można zaimplementować bota dla firm ubezpieczeniowych?

Jak można zaimplementować bota dla firm ubezpieczeniowych

Dzisiejszy wpis poświęcę kolejnemu rozwiązaniu z branży chatbotów, które znalazłem w jeden z publikacji na arXiv.org. Autorzy tekstu pokazali jak można zaimplementować bota dla firm ubezpieczeniowych, przeznaczonych do obsługi zapytań związanych z zakresem umowy (np. bot firmy ubezpieczeniowej).

Tego typu usługi wiążą się zazwyczaj z dużym stopniem skomplikowania umowy. Przykładowo wartość wypłacanego odszkodowania, zależy od wielu parametrów, tj. od miejscia, gdzie nastąpiło zdarzenie, okoliczności, wysokości składki itp. Obsługa wszystkich możliwości za pomocą tradycyjnego podejścia, w którym staramy obsłużyć wszystkie ścieżki staje się nieefektywna i zwiększa poziom skomplikowania bota. Mało tego, ewentualne późniejsze zmiany w chatbocie, w pewnym punkcie mogą stać się wręcz niemozliwe – wygenerujemy duży dług technologiczny.

Z tego powodu autorzy publikacji zaproponowali framework, który na podstawie optymalnie skonfigurowanych warunków, potrafi w poprowadzić użytkownika do satysfakcjonującej go wyceny szkody.

Pełną publikację możecie znaleźć TUTAJ.

Architektura rozwiązania

Proponowane rozwiązanie problemu składa się z 3 głównych komponentów:

  • klient
  • chatbot framework
  • serwis ekspercki

Pierwszy komponent to nic innego jak interfejs, umożliwiający komunikację z botem – może być to okno Messenger’a lub widget na stronie internetowej.

Framework pełni tu rolę kontrolera. Przyjmuje wiadomości z interfejsu, przetwarza i w odpowiedniej formie wysyła do serwisu eksperckiego zapytanie, oczekując odpowiedzi. Na tym etapie wiadomość jest przetwarzana za pomocą modelu NLP, który odpowiednio klasyfikuje je oraz wydobywa kluczowe informacje.

Powyższe 2 komponenty są elementami każdego tego typu rozwiązania, dlatego autorzy nie skupiali się na nich, ale na trzecim z nich – serwisie eksperckim. Umożliwia on przyjmowanie, odpowiednio sformatowanych zapytań i na podstawie zdefiniowanych zasad, generuje odpowiedź. Więcej o zasadzie jego działania dowiecie się z dalszej części tekstu.

Widać na powyższym obrazku (zapożyczonym z publikacji), jak wygląda przebieg rozmowy. Framework, otrzymujący pytanie od klienta, klasyfikuje je, wyciąga parametry i wysyła zapytanie do serwisu eksperckiego. Serwis ekspercki ocenia, jakich parametrów mu jeszcze brakuje i zwraca informacje o nich. Framework dopytuje klienta o brakujące parametry i po otrzymaniu odpowiedzi wysyła zapytanie ponownie do serwisu, który generuje satysfakcjonującą odpowiedź.

Serwis ekspercki

Tak jak wyżej zostało wspomniane, serwis przyjmuje odpowiednio przygotowany input, który zawiera intencje użytkownika oraz zbiór par parametr – wartość, które zostały znalezione w zapytaniu.

Przykład do tego może być następujący:

  • pytanie: Ile kosztuje ubezpieczenie na wyjazd na narty do Włoch?
  • intent: koszt ubezpieczenia
  • sport: narty
  • miejsce: Włochy

Aby duża liczba możliwych parametrów była możliwa do obsłużenia, autorzy publikacji proponują zamodelowanie hipergrafu, który pozwoli w łatwiejszy sposób wygenerować odpowiedź na podstawie dostarczonych parametrów.

 Hipergraf to graf, którego krawędzie mogą prowadzić do dowolnej liczby wierzchołków 

Przykład takiego hipergrafu macie poniżej:

Wyróżniamy tu następujące elementy:

  • wierzchołki – mamy 2 rodzaje wierzchołków – te które są parametrami zapytania, np. sport czy kraj oraz te, które są dostepnymi odpowiedziami, czyli np. koszt ubezpieczenia.
  • krawędzie – łączą poszczególne krawędzie, tworząc ścieżkę do odpowiedniej odpowiedzi. Przy czym krawędzie nie mogą łączyć wierzchołków leżących na jednym poziomie (np. dwóch rodzajów sportu)

Tak stworzone „ścieżki” mogą doprowadzić nas do odpowiedzi. Na podanym przykładzie ubezpieczenie od szkód w wyniku wspinaczki w Szwajcarii będzie kosztowało 20 euro.

Algorytm działania

Mając zbudowany graf, możemy przejść do algorytmu, który wykorzystywany jest do generowania odpowiedzi.

  1. Na podstawie parametrów podanych przez użytkownika serwis próbuje stworzyć ścieżkę do odpowiedzi.
  2. Jeśli ścieżka została znaleziona – wysyłamy odpowiedź (np. 20 euro)
  3. Jeśli użytkownik podał wszystkie parametry, ale nie znaleziono ścieżki oznacza to, że nie ma przewidzianej takiej konfiguracji i wysyłamy informacje o braku takiego ubezpieczenia
  4. Jeśli brakuje pewnych parametrów (np. kraju), aby stworzyć ścieżkę – dopytujemy o nich użytkownika i po otrzymaniu odpowiedzi, wracamy do 1. punktu.

Widać więc, że algorytm w ostateczej formie jest prosty i intuicyjny, a jedyna trudność to optymalna implementacja. Musimy bowiem pamiętać, że przy dużej ilości parametrów przeszukiwanie ściezek nie będzie tak trywialne, jak na podanych przykładzie.

Podsumowanie

Przedstawiłem Wam ciekawy case study, w jaki sposób poradzić sobie z logiką wyciągania wniosków na podstawie dostarczonych parametrów. Można się nim zainspirować przy tworzeniu nieco bardziej skomplikowanych projektów. Tu pokazane jest na przykładzie firmy ubezpieczeniowej, ale zastosowanie nie musi być ograniczone tylko do tej jednej branży. Jako ciekawostkę autorzy pokazują dodatkowo narzędzie, które stworzyli w celu konfiguracji wspomnianych parametrów. Narzędzie posiada interfejs graficzny i w czytelnej formie pozwala modyfikować wprowadzoną konfigurację parametrów.