GenAI to nie eksperyment. To świadoma, strategiczna decyzja banku

Z Krzysztofem Dąbrowskim, COO w mBanku rozmawiam o:

• pięciu inicjatywach wykorzystania Generatywnej AI – Talk to Your Data, mKanon, mComplaints, Speech to text i mSmart,
• efektach ich wykorzystania; podejściu do wyboru projektów GenAI,
• szybkim dostosowywaniu konkretnego modelu LLM do aktualnej potrzeby,
• byciu w zgodzie z regulacjami przy ich wykorzystaniu.

mBank pokazał pięć przykładów wykorzystania generatywnej, sztucznej inteligencji. Czy to wszystkie, które weszły na produkcję?

Nie, to są po prostu te, które pokazujemy. Nie chwalimy się tym, co zrobimy, lecz tym, co już zrobiliśmy. Jakiś czas obiecałem nawet Panu Redaktorowi, że odezwę się, jak już będziemy gotowi. No więc z tymi pięcioma Use Case jesteśmy gotowi.

Ale oczywiście pracujemy nad większą liczbą przypadków użycia AI / GenAI w banku. Nic nie wskazuje też, aby miały się nam skończyć pomysły.

Który z projektów w mBanku można potraktować jako PoC mający sprawdzić możliwości dostępnych modeli AI?

Żaden. Od razu poszliśmy szeroko. Mamy w mBanku wewnętrzny inkubator, w którym testujemy technologie GenAI. Naszym zdaniem nie ma sensu robić Proof of Concept w jednym, odizolowanym miejscu, aby ostatecznie przekonać się, że w tym przypadku technologia ta zadziałała.

A jeśli okaże się, że akurat w tym obszarze nie, to co wtedy?

Wybraliśmy kilka projektów – więcej niż pięć, które pokazujemy – i uruchomiliśmy wszystkie na raz. Nie traktowaliśmy ich jako PoC, lecz pierwszy krok, swego rodzaju MVP. Jak zadziała, to uruchamiamy go jako pełnoprawny projekt biznesowy.

Jeśli nie zadziałał – szybko go kończymy i w to miejsce bierzemy kolejny. Nasza fabryka GenAI w ten właśnie sposób działa. Dlatego mówię, że nie było jednego Proof of Concept. De facto wszystkie projekty nimi były. Z naszych doświadczeń wynika, że 80% pomysłów działa i ma sens.

Jaki procent pracowników z nich korzysta? Przykładowo Grupa PZU dała wszystkim pracownikom dostęp do Copilota.

My również. Mieliśmy ten komfort, że – jako jeden z pierwszych banków w Polsce – w całej organizacji używaliśmy Office 365. Uruchomienie Copilota było więc małym, inkrementalnym krokiem. Była to kwestia podjęcia odpowiedniej decyzji i włączenia tej funkcji.

Na jakich rozwiązaniach oparliście cztery, prezentowane rozwiązania?

W każdym przypadku jest to nasze oprogramowanie, które jedynie korzysta z dostępnych modeli AI.

Raczej używamy rozwiązań open-source, a stos technologiczny budujemy w języku Python. Same modele są dla nas – co do zasady – wtórne i łatwo wymienialne.

We wspomnianych rozwiązaniach używaliśmy OpenAI. Zrobiliśmy to z dwóch powodów. Po pierwsze jest to dziś swego rodzaju standard. Choć nie znaczy to, że firma ta jest we wszystkim najlepsza. Po drugie – co było dla nas ważniejsze – mieliśmy wcześniej funkcjonujący już program chmurowy. W jego ramach korzystamy z rozwiązań Microsoft, a wkrótce także Google Cloud.

Modele OpenAI dostępne są w Microsoft Azure. Możemy więc je – w sposób „koszerny” – używać nie martwiąc się np. tajemnicą bankową. Migrując się do Office365 przeszliśmy już proces Compliance. Każdy, inny model spoza tego ekosystemu, byłby trudniejszy do użycia.

Oczywiście dzięki temu, że skończyliśmy integrację z Google Cloud, to możemy już korzystać nie tylko z modeli Google DeepMind, ale też np. Anthropic.

W tym momencie możemy używać dowolnego z mainstreamowych, dużych modeli językowych. Ponieważ jednak chcieliśmy szybko wystartować, wybraliśmy rozwiązanie, które było na wyciągnięcie ręki.

Jednym z projektów, który zwrócił moją uwagę jest „Talk to Your Data”, choć na pozór wygląda na bardzo skomplikowany. Odpowiada tylko na potrzeby zaawansowanych użytkowników, Data Scientists?

Nie, jest dedykowany grupie analityków danych. Ich główne zadanie polega na rozwiązaniu jakiegoś problemu biznesowego. Często są one związane z raportowaniem regulacyjnym albo wdrożeniem nowego systemu. Ci analitycy, zazwyczaj muszą przeczytać dostarczoną specyfikację i sprawdzić czy zawarte tam są np. wymagania co do przechowywanych w banku danych. W kolejnym kroku, muszą sprawdzić, gdzie się one znajdują, a jeśli nie są wprost zapisane w naszych bazach, to je wyliczyć.

W dużej organizacji, przy dużych modelach danych zajmuje to bardzo dużo czasu. Żadna z tych osób, nawet najbardziej doświadczona, nie ma ich w głowie. Posiadanie narzędzia, które – choćby w przybliżony sposób – przetworzy język naturalny na zapytania SQL, które wskażą, w której tabeli i kolumnie znajdują się poszukiwane informacje, zdejmują z analityków sporą część pracy przeznaczanej do tej pory na szukanie.

Do tego narzędzia można wrzucić cały paragraf konkretnej specyfikacji czy raportu regulacyjnego prosząc o odnalezienie konkretnych, dotyczących go danych. W odpowiedzi analityk dostanie listę miejsc z potrzebnymi informacjami. W telegraficznym skrócie „Talk to your data” to nasz wewnętrzny przewodnik po danych.

Wdrożyliście także narzędzie podsumowujące wiedzę o klientach bankowości korporacyjnej. Czym różni się od „klasycznych” systemów CRM?

CRM posiadają wszystkie, szanujące się firmy. My też posiadamy informacje o działaniach klienta w zakresie współpracy z nami. Nie potrzebna nam do tego sztuczna inteligencja. Jednak dziennikarze tacy, jak Pan, ale i tysiące innych osób generują codziennie ogrom newsów, informacji i wiedzy.  Dotyczy to także firm, które są naszymi klientami.

Wśród średnich firm mamy kilkadziesiąt tysięcy klientów. Każdy z opiekunów ma ich przypisanych kilkaset. Nawet gdyby chciał się raz na rok spotkać albo zadzwonić do każdego z nich, to przed takim spotkaniem powinien zrobić co najmniej kilkugodzinny research. I nie mówię o tym, aby zrozumieć potrzeby klienta. To, co z nami robi wiemy. Ale nieprofesjonalnie wyglądać będzie to, gdy doradca zadzwoni do klienta, aby zapytać co słychać i nie będzie wiedzieć, że np. miesiąc temu podpisał największy kontrakt w historii. Albo, że tego typu kontrakt jednak nie doszedł do skutku i firma właśnie „walczy o życie”.

Większość newsów jest dla nas neutralna, ale o części po prostu nie wypada nie wiedzieć. Nasze narzędzie gromadzi tego typu informacje z jednego z serwisów informacyjnych. My tę strumień informacyjny codziennie wciągamy do naszej bazy wektorowej i przetwarzamy, tak aby każdy doradcza mógł dostać komplet aktualnych informacji o kliencie, lub też podsumowanie na temat danej branży, jeżeli ilość materiałów na temat danej firmy jest zbyt mała.

Oczywiście trzymamy te informacje u siebie tylko przez określony czas. Newsy mają swój „termin ważności”. Największym wyzwaniem jest to, że musimy je codziennie ściągać i przetwarzać tak by były zawsze aktualne i dostępne.

W tym przypadku też zastosowaliście model OpenAI?

Tak, ale jeszcze raz podkreślę. Dla nas model jest wtórny. Nasze rozwiązania tworzymy w ten sposób by bez problemu zmieniać model językowy. Nawet w ramach oferty OpenAI wykorzystujemy różne modele, w zależności od kontekstu.

Wyścig, który się toczy w tej chwili między dostawcami narzędzi GenAI, to z jednej strony jest wyścig na jakość, a z drugiej na cenę. Przykładowo do analizy newsów nie jest nam potrzebny najbardziej wyrafinowany model. Zadanie dla LLM jest proste. Ma wybrać z bazy wektorowej 10, najbardziej wartościowych, kluczowych artykułów i podsumować je. Tu możemy użyć szybkiego i taniego modelu.

Są też w pełni open-sourcowe rozwiązania, choćby polski Bielik.

Na wczesnym etapie Bielik dawał dużą wartość dodaną, bo lepiej rozumiał język polski. Ale zachodni dostawcy nie przespali tego okresu. Nie jest moją intencją krytykowanie Bielika, po prostu modele typu „frontier”, których używamy dają nam jakość, której potrzebujemy i na dziś język polski nie jest już dla nich żadnym problemem.

Bielik jest jednak rozwiązaniem open source. Jest więc bezpłatny.

Nie do końca. Aby zadziałał trzeba kupić serwery z GPU i wstawić je do data center. Sam Bielik jest bezpłatny jako oprogramowanie, ale już infrastruktura pod niego nie. Decyzja jakiego modelu użyć do konkretnego zadania jest zawsze kontekstowa i nie można jej podejmować w oderwaniu od problemu, który rozwiązujemy.

Co nie znaczy, że w ogóle nie używamy modeli działających w środowisku on-premise. Używamy. Mają one jednak inną zaletę. Znajdują się właśnie w naszym centrum danych. Rachunek ekonomiczny może przemawiać właśnie za nimi.

Kiedy rachunek ekonomiczny przemawia za rozwiązaniami on-premise?

Przykładowo analiza jakości pracy naszych konsultantów i tego, z czym dzwonią nasi klienci wymaga wykorzystania narzędzia Speech to text. W tym projekcie, na razie taniej jest wykorzystać modele AI działające na własnym sprzęcie. Nie mówimy tu bowiem o sporadycznym odpytaniu chatbota, lecz analizie 50 000 rozmów dziennie w naszym call center i zamianie ich na tekst.

Każde użycie narzędzia Speech to text w chmurze generuje koszty. Natomiast na rozwiązanie on-premise przeznaczyliśmy budżet raz, na samym początku projektu. Przez kolejne 5 lat, gdy sprzęt się amortyzuje, dodatkowym kosztem będzie tylko energia elektryczna. Wiemy więc jakie ponieśliśmy koszty i mamy je pod kontrolą.

Oczywiście konkurencja nie śpi i są już modele open-source, które lepiej sobie radzą z zamianą mowy na tekst niż wybrany przez nas Whisper. Jeśli pojawi się lepszy, to jesteśmy w stanie podmienić sam back-end. Nowy model pobierze plik audio i w odpowiedzi wygeneruje plik tekstowy. Nasze narzędzie pozwala w miarę szybko podmienić model AI na nowy, lepszy. Ale trzeba mieć na to czas, a nie mamy w co rąk włożyć (śmiech).

Ważny jest też koszt. Przykładowo narzędzia do skanowaniu dokumentów OCR dostępne w chmurze Google Cloud jest na tyle tanie, że nie opłaca się nam „kombinować” z własnym. Koszt korzystania z tego modelu AI to kilkanaście dolarów dziennie za przeprocesowanie wszystkich, spływających do nas faktur. To mniej niż 1 cent za kartkę.

Co dokładnie robi narzędzie analizujące rozmowy w call center mBanku? Szuka określonych słów kluczowych?

To byłoby zbyt proste i jest możliwe do zrealizowania bez dużych modeli językowych. Kiedyś wykorzystywaliśmy do tego algorytmy bazujące na analizie tekstów. Określały one czego dotyczyły rozmowy – np. kredytów lub depozytów. To było OK, ale miało tę wadę, że mieliśmy do czynienia ze stateczną strukturą. Przypisanie zaś do poszczególnych kategorii mogło nie do końca być prawidłowe.

W przypadku tego narzędzia jest o tyle ciekawie, że wykorzystujemy model LLM do dwóch rzeczy na raz. Z jednej strony każemy mu wyciągnąć esencję z danej rozmowy i wskazać w kilku słowach czego dotyczyła. A jak model AI stworzył podsumowanie, to de facto również przypisał do konkretnej kategorii. Nasze narzędzie w locie tworzy kategorie i każdego dnia mogą być inne. Nie mamy więc do czynienia ze sztywnymi kategoriami, lecz analizą statystyczną żywych rozmów.

To jest jedna strona tego rozwiązania. Druga, to analiza całego zestawu kryteriów tego, w jaki sposób powinien komunikować się z klientem nasz konsultant. 10 lat temu wprowadziliśmy u nas mKanon czyli zbiór zasad prostej komunikacji. Aby pomóc naszym pracownikom sprawdzać czy opracowują swoje teksty zgodnie z tymi zasadami, opracowaliśmy narzędzie, które sprawdza w jakim stopniu dana treść jest zgodna z zasadami mKanonu

Rozwiązanie, o którym wspominam, stworzyliśmy jeszcze przed powstaniem modeli językowych. Sugeruje także co można poprawić. Nasze oczekiwania są takie, aby ta komunikacja nie schodziła poniżej jakiegoś poziomu punktacji. mKanon sprawdzał się w „powolnej”, bardziej statycznej komunikacji, czyli np. mailowych odpowiedzi na zapytania klienta.

Zupełnie inna jest sytuacja z rozmowami na żywo w call center. A chcielibyśmy całą naszą komunikację analizować pod kątem prostoty języka. Tutaj też chcemy wiedzieć, czy nasz doradca przywitał się, czy był kulturalny, zachował profesjonalizm, próbował zaproponować nowy produkt, pożegnał się.

Każda taka rozmowa dostaje metryczkę. Raporty tego typu – na koniec każdego tygodnia – są podstawą do rozmowy, co dany doradca może poprawić w komunikacji z klientami. Warto podkreślić, że nasi pracownicy to nie są roboty, nie korzystają z gotowych skryptów. Dajemy im sporą dowolność w tym, jak mogą poprowadzić rozmowę.

Kiedyś odsłuchiwaliśmy losowo 1 na 1000, 1 na 10 000 rozmów. Teraz każdy pracownik contact center może dostać – z automatu – feedback na temat każdej z nich. W kolejnym kroku przełożony, na tej podstawie, może mu zasugerować zmiany w sposobie obsługi.

Pozwala nam to także na bieżąco wykrywać ewentualne trendy, gdy jakaś kategoria rozmów zaczyna częściej się powtarzać. Wcześniej obserwowaliśmy to, gdy ta „fala” była już duża, gdy zaczęła szybko narastać. Teraz jest to możliwe już po analizie kilku rozmów.

Przykładowo, po ostatnim wdrożeniu jednego z systemów, pojawił się drobny błąd w jednej z mniej istotnych fikcjonalności. Normalnie dowiedzielibyśmy się o tym za miesiąc, gdy okazałoby się, że mamy sporo tego samego typu reklamacji. Teraz wykryliśmy go już w raporcie, w którym znalazło się 10 tego typu przypadków. A mówimy o banku, który ma 4,5 mln aktywnych klientów. Zdążyliśmy to naprawić zanim masowo pojawiły się reklamacje.

A propos reklamacji. Opisywaliście funkcjonowanie dedykowanego ich obsłudze narzędzia mComplaints.

Jak każda, duża firma chcemy jak szybciej rozwiązywać problemy klientów. Narzędzie wykorzystujące Generatywną AI pozwala nam zaś bardziej precyzyjnie mierzyć poziom obsługi reklamacji.

Nowe narzędzie miało odpowiedzieć na dwa wyzwania: jak określić z jakim problemem mamy do czynienia oraz czy w złożonej reklamacji są wszystkie, niezbędne informacje, aby móc ją rozwiązać. Często ich brakuje, co powoduje, że nie możemy zrealizować prośby klienta. Wpierw musimy uzyskać do niego dodatkowe informacje.

Obecnie prośbę tę wysyła człowiek. Naszym pomysłem było to, aby zanim dyspozycja lub reklamacja trafią do konsultanta, model AI sprawdził kompletność danych. Często już na etapie wypełniania formularza na naszej stronie, czy w aplikacji mobilnej.

Dlaczego to jest ważne? Bo reklamacje nie są obsługiwane w czasie rzeczywistym, tylko trafiają do kolejki. A jeśli dostaniemy niepełną informację i poprosimy o jej dosłanie, to klient przesuwa się na dalsze pozycje w tej kolejce. Zebranie danych może zająć nawet tydzień, a dzięki mComplaints w tym samym czasie cała sprawa może już zostać rozwiązana.

mComplaints ma zrobić dwie rzeczy. Przede wszystkim – używając całej wiedzy, którą go zasililiśmy – napisać pracownikowi, co powinien zrobić, aby rozwiązać problem. To może nie jest wyzwaniem dla doświadczonych pracowników, którzy długo pracują nad danym typem reklamacji, ale dla osób, które się uczą, albo trafiają do nowego działu to ogromna pomoc.

Druga funkcjonalność mComplaints to skonstruowanie odpowiedzi na reklamację. Oczywiście mamy skończoną liczbę problemów, ale nikt nie chce pisać (ani czytać) gotowych szablonów. One też szybko stają się nieaktualne, a gdy pracownicy z nich korzystają to komunikacja wygląda nieco nienaturalnie. Tymczasem AI potrafi zaproponować pewne stałe paragrafy odpowiedzi dla pracownika, które są związane z danym pytaniem, ale jednocześnie zostawiają przestrzeń, aby dostosował odpowiedź do tego, co wie o kliencie.

mComplaints to coś pomiędzy pełnym automatem, którego my i klienci nie lubimy, a odpowiadaniem indywidualnie na każdy list, co z kolei bardzo „słabo” się skaluje.

Czy są inne rozwiązania GenAI, o których – nawet nieoficjalnie – można mówić?

Publicznie jeszcze o tym nie mówiliśmy, ale jest nim mSmart. Jest to swego rodzaju wyszukiwarka połączona z modelem językowym, który jest w stanie nie tylko odnaleźć informacje, ale także przetworzyć je, podsumować i stworzyć odpowiedź na zadane pytanie.

Jednym z typowych problemów dużej organizacji, która działa na rynku konsumenckim jest to, że niekiedy posiada bardzo skomplikowane produkty. W przypadku bankowości korporacyjnej mówimy nawet o jeszcze bardziej wyrafinowanych produktach. To właśnie pracownikom tej części mBanku w pierwszej kolejności zaoferowaliśmy mSmart.

To, co w tym projekcie było ważne, to fakt, że bankowość korporacyjna miała dość dobrze przygotowaną, wewnętrzną bazę wiedzy. Była ona uporządkowana. Posiadała też dobry, wewnętrzny proces aktualizacji i zarządzania nią. Wbrew pozorom w dużej organizacji to skomplikowany proces, bo dotyczy dokumentacji produktowej, którą tworzą dziesiątki ludzi w wielu departamentach. A w jednym miejscu trzeba zadbać, aby była ona aktualna.

Mieliśmy więc dobry wsad dla modelu językowego. Po „nakarmieniu” go bazą wiedzy, pracownicy bankowości korporacyjnej mogą chatowi mSmart zadawać pytania np. o to, w jaki sposób działa konkretny produkt albo co trzeba zrobić, aby go uruchomić konkretnemu klientowi. Kiedyś pracownicy dostawali link do 2-3-stronicowego artykułu, w którym było to opisane. Teraz LLM wyjaśnia, krok po kroku, cały proces. Oczywiście wskazując za każdym razem dokument źródłowy.

Liczyliście już korzyści czy zwrot z inwestycji z projektów, o których rozmawiamy?

Nie. Staramy się wypróbować jak najwięcej sensownych hipotez. Każda z nich jest oczywiście osadzona gdzieś w biznesie. Żaden z działów nie przyjdzie jednak do nas z tego typu projektem z gotowym Business Case i prognozą dodatkowego strumienia przychodów lub obniżenia kosztów.

Wychodzimy z założenia, że zamiast kazać „umierać” tym pomysłom w kolejce po zasoby, na poziomie zarządu uznaliśmy, że projekty AI / GenAI w dłuższej perspektywie przyniosą bankowi korzyści i po prostu inwestujemy w najlepsze pomysły.

Staramy się realizować je przyrostowo, aby nie poświęcać każdemu roku lub dwóch i wówczas dopiero sprawdzić, czy coś z nich wyszło. Dzielimy je też na projekty mniejsze, realizowane szybko i zwinnie. Przeprowadzamy również wewnętrzne demonstracje, w czasie których podejmujemy decyzje o kontynuacji projektu lub rezygnacji z niego.

Warto jednak zaznaczyć w tym miejscu, że łatwe rzeczy dawno już zrobiliśmy. Często nawet nie potrzebowaliśmy do tego sztucznej inteligencji. Narzędzi GenAI używamy do tych bardziej rozbudowanych. A w ich przypadku ciężej jest osiągnąć jakiś „spektakularny” wynik. Co w tym przypadku jest bardzo istotne to, że celem wdrożeni w mBanku narzędzi GenAI jest wsparcie użytkowników, a nie ich zastąpienie.

Nasz program inkubacyjny cały czas działa. Pojawiają się nowe pomysły. Warto obserwować to, co komunikujemy. Choć oczywiście zdajemy sobie sprawę z tego, że coraz więcej rozwiązań AI będzie zaszywana w gotowych produktach.

Czy realizacja projektów związanych z wykorzystaniem modeli AI wymagała po stronie mBanku jakichś przygotowań?

Nie. Po pierwsze mieliśmy już doświadczony zespół Data Science. Musieliśmy więc go wyłącznie rozbudować, a nie tworzyć od zera. Posiadaliśmy też większość niezbędnego stosu technologicznego.

Co ważne, mieliśmy również mocne postanowienie zarządu, że uruchamiamy wewnętrzny inkubator projektów GenAI i chcemy by zespoły wykorzystały ich potencjał. Określiliśmy też budżet na tego typu projekty. Znacząco obniżyło to „barierę wejścia”.

Zarząd upoważnił mnie do tego, abym kierował tym programem. Dzięki temu w ciągu tygodnia możemy uruchomić jakiś projekt, ale też – jeśli nie spełnia założeń – zamknąć go.

Największy problem był z infrastrukturą on-premise na potrzeby projektów AI / GenAI. Kiedy zaczynaliśmy były problemy z dostawami układów GPU. Niekiedy musieliśmy więc dostosować nasze wymagania do dostępnych na rynku urządzeń.

Swoją drogą jestem ciekaw, co zrobi NVIDIA, kiedy Google, Apple i wielu, innych producentów, a być może i OpenAI tworzą własne procesory GPU. Nie będą one zapewne sprzedawane niezależnie. Nie rozwiążą więc problemów całego rynku. Ale z pewnością ich moc będzie udostępniana w modelu chmury obliczeniowej.

A propos GenAI, czyli robienia tego, o czym wszyscy dookoła mówią… jednym z kluczowych tematów w finansach i bankowości jest modernizacja systemów, mówiąc językiem IT – replatforming. Ten proces w mBanku już trwa?

Z dużą satysfakcją mogę powiedzieć, że ten proces, a właściwe dwa procesy, już się w mBanku zakończyły. Zrobiliśmy to, jako pierwszy – i do tej pory jedyny – bank w Polsce. Wszyscy nasi klienci – detaliczni i ci z obszaru bankowości korporacyjnej są zmigrowani z platformy mainframe na nową opartą o .NET.

To na pewno nie było łatwe zadanie, ale my w mBanku mamy apetyt na innowacje i robienie rzeczy naprawdę ważnych, a przede wszystkim potrzebnych naszym klientom. Nasza transformacja systemów została zauważona i doceniona także poza Polską. Forrester Research wyróżnił nas prestiżową nagrodą Technology Strategy Impact Award dla regionu Europy, Bilskiego Wschodu i Afryki.

A co było w całym tym procesie najtrudniejsze?

Trudno wskazać element, który był najtrudniejszy do realizacji. Celem projektu było unowocześnienie najważniejszych systemów banku przy zachowaniu ciągłości działania i kontroli kosztów. Przenieśliśmy dotychczas działający system oparty na technologii mainframe na nowoczesne rozwiązanie działające na architekturze x86.

Zmodernizowaliśmy też drugi system centralny, który przetłumaczyliśmy na współczesny język programowania i uruchomiliśmy w chmurze prywatnej. A równolegle cały czas dodawaliśmy nowe produkty i rozwiązania biznesowe.

Mówiąc wprost – transformując systemy nie mogliśmy pozwolić sobie na spowolnienie rozwoju funkcjonalności biznesowych. Musieliśmy trzymać tempo, a cały proces przeprowadzić w sposób niewidzialny dla klientów. I to się nam udało.