Nie cierpię dzwonić do przychodni. Paulina właśnie rozwiązała ten problem

Paulina od marca wymieniła z pacjentami 65 placówek ponad 150 tys. wiadomości i pomogła wygenerować ponad 4,3 tys. zapisów na wizyty. Jeszcze ciekawsze jest jednak to, co znajduje się pod maską. Zamiast GPT czy Gemini twórcy postawili na polskie modele Bielik i własną infrastrukturę.

Sercem systemu są polskie modele językowe z rodziny Bielik, rozwijane we współpracy z zespołami z AGH, Uniwersytetu Jagiellońskiego i Politechniki Wrocławskiej. Twórcy Pauliny podkreślają, że wybór lokalnego, polskiego modelu nie był przypadkiem. Chodziło o coś więcej niż samo generowanie tekstu, o system, który rozumie potoczny, często niedoskonały język pacjentów i pozwala zachować niezależność od zewnętrznych dostawców API.

Z danych zebranych przez Proassist wynika, że pacjenci najczęściej korzystają z bota w godzinach porannych, między 7:00 a 9:00, choć znacząca część rozmów toczy się także wieczorem, gdy tradycyjna rejestracja telefoniczna jest już niedostępna. Najczęstszą intencją pozostaje rejestracja na wizytę, tuż za nią plasują się pytania o charakterze informacyjnym. System wygenerował dotychczas ponad 4,3 tys. zapisów na wizytę, a jednocześnie w mniej niż jednym procencie rozmów musiał skierować pacjenta bezpośrednio do personelu.

Proassist nie zatrzymuje się na chatbocie. Firma rozwija już voicebota opartego na tym samym silniku, testuje wielojęzyczność (system obsługuje już angielski, niemiecki i ukraiński) i deklaruje ambicję zbudowania kompletnej platformy AI wspierającej nie tylko pacjentów, ale i wewnętrzne procesy placówek medycznych.

Właśnie od tego pytania zaczynam swoją rozmowę z Maciejem Wyleciałem, kierownikiem działu AI w Proassist i doktorantem na AGH.

Karol Kopańko Bizblog.pl Spider's Web: Dlaczego Bielik?

Gdybyśmy chcieli po prostu szybko uruchomić prostego chatbota albo przygotować demonstrację, to rozwiązania takie jak GPT czy Gemini byłyby naturalnym wyborem. Są mocne, łatwo dostępne i świetnie sprawdzają się w wielu ogólnych zadaniach. My jednak od początku zakładaliśmy, że Paulina ma być czymś znacznie więcej niż tylko oknem do rozmowy.

Czyli?

Budujemy system, który ma działać codziennie w placówkach medycznych, z pacjentami, i ma być częścią konkretnych procesów: rejestracji, zmiany terminu, anulowania wizyty, odpowiadania na pytania o usługi, specjalistów czy przygotowanie do badania. I właśnie wtedy zaczynają mieć znaczenie rzeczy, których często nie widać na etapie prostego demo.

Jakie to kwestie?

Pierwszą jest język polski. Pacjenci bardzo rzadko piszą idealnie, pełnymi zdaniami i formalnym językiem. Piszą tak, jak mówią na co dzień: skrótowo, potocznie, z literówkami, czasem chaotycznie, czasem wrzucając kilka informacji do jednej wiadomości. Dla nas ważne było więc to, żeby model nie tylko znał polski, ale dobrze rozumiał naturalny sposób komunikacji pacjentów. Bielik jest rozwijany właśnie z myślą o języku polskim i w naszych zastosowaniach bardzo dobrze wpisuje się w ten kontekst.

Druga rzecz to możliwość lokalnego uruchomienia. W medycynie bardzo zależy nam na kontroli nad tym, gdzie i jak dane są przetwarzane. Nie chcieliśmy, żeby kluczowy element naszego systemu był całkowicie uzależniony od zewnętrznego API. Dzięki temu, że modele mogą działać na naszej własnej infrastrukturze, mamy znacznie większą kontrolę nad całym procesem, nad wersją modelu, nad sposobem jego testowania i nad momentem wdrożenia kolejnych zmian.

Trzecia kwestia to niezależność. Przy zewnętrznych dostawcach zawsze jesteśmy w pewnym stopniu zależni od ich decyzji: zmian cen, limitów, sposobu dostępu do API, a czasem nawet zmian w zachowaniu modelu po aktualizacji. W systemie, który ma być stabilnym elementem obsługi pacjenta, chcieliśmy tę zależność ograniczyć. Wolimy mieć możliwość samodzielnego decydowania, kiedy coś aktualizujemy, jak skalujemy system i co dokładnie trafia na produkcję.

Bardzo ważna była dla nas też możliwość dostosowania modelu do naszych potrzeb. Paulina nie jest jednym modelem, który odpowiada na wszystko. To cały framework, w którym różne komponenty odpowiadają za różne zadania. Inaczej obsługujemy rozpoznawanie intencji, inaczej pytania o wiedzę placówki, inaczej uzupełnianie danych, a jeszcze inaczej rozmowę głosową w rozwijanym voicebocie. W takim podejściu lokalny model daje nam dużo większą swobodę — możemy go parametryzować, dostrajać, specjalizować i dokładnie testować pod konkretne procesy.

I jest jeszcze jeden aspekt, który jest dla nas ważny trochę bardziej strategicznie. Bielik jest polskim rozwiązaniem i bardzo szybko się rozwija. Pojawiają się kolejne wersje, poprawiana jest jakość i wydajność, a jednocześnie są to modele, które możemy realnie uruchamiać lokalnie bez budowania ogromnej infrastruktury. To pozwala nam rozwijać system w sposób, który jest zarówno technologicznie sensowny, jak i biznesowo przewidywalny.

Bielik jest dla was fundamentem rozwoju Pauliny. Jak go dostrajacie pod kątem specyfiki medycznej i słownictwa branżowego?

W przypadku zastosowań medycznych samo „dotrenowanie modelu na słowniku medycznym” byłoby zdecydowanie zbyt dużym uproszczeniem. Dla nas najważniejsze jest dostosowanie całego systemu językowego do sposobu, w jaki rzeczywiście komunikują się pacjenci i w jaki funkcjonują placówki.

Taki proces zaczyna się przede wszystkim od obserwacji realnych scenariuszy. Inaczej wygląda rozmowa o zapisaniu wizyty, inaczej pytanie o przygotowanie do badania, a jeszcze inaczej sytuacja, w której pacjent podaje nazwisko lekarza, nazwę placówki, specjalizację czy termin medyczny w potocznej albo niepełnej formie.

Na tej podstawie budujemy zestawy przypadków, na których możemy sprawdzać jakość działania modelu. Bardzo ważne jest dla nas nie tylko to, czy odpowiedź brzmi dobrze językowo, ale czy system prawidłowo rozumie intencję pacjenta, właściwie interpretuje informacje i zachowuje się zgodnie z procesem obowiązującym w placówce.

Jak to się odbywa w praktyce?

Samo dostosowanie może odbywać się na kilku poziomach. Czasami wystarczające jest odpowiednie przygotowanie kontekstu, wiedzy i sposobu prowadzenia rozmowy. W innych przypadkach można dostosowywać konkretne komponenty albo modele do węższych zadań. Nie każde zadanie wymaga ingerencji w sam model bazowy - często większą wartość daje dobre połączenie modelu językowego z wiedzą placówki, logiką procesu i mechanizmami kontroli.

A słownictwo?

Poświęcamy mu dużo uwagi: nazwom usług, specjalizacji, procedur, nazwiskom lekarzy czy określeniom, których pacjenci używają potocznie zamiast oficjalnych nazw. To właśnie te pozornie drobne elementy często decydują o tym, czy system rzeczywiście sprawdzi się w codziennej pracy.

Całość traktujemy jako proces iteracyjny: testujemy, analizujemy błędy, poprawiamy i ponownie sprawdzamy system na rzeczywistych scenariuszach. Nie chcemy natomiast publicznie wchodzić w szczegóły dotyczące konkretnych metod, danych czy architektury dostrajania, ponieważ jest to część naszego wewnętrznego know-how.

Jak przekłada się to na statystyki wykorzystania?

Obecnie mamy już ponad 10 tysięcy pełnych rozmów pacjentów z Pauliną, a liczba wymienionych wiadomości przekroczyła 150 tysięcy. To dla nas bardzo wartościowa skala, ponieważ pozwala analizować nie pojedyncze przypadki, ale rzeczywiste wzorce zachowań użytkowników.

A jak często system sugerował kontakt z rejestracją?

Mówimy tu łącznie o kilkuset takich komunikatach na ponad 150 tysięcy wiadomości. To oznacza, że stanowią one mniej niż 1 proc. całej komunikacji.

Co jednak ważne, nie traktujemy każdego takiego przypadku jako sytuacji, w której „bot sobie nie poradził” i konieczna była interwencja człowieka. W zdecydowanej większości były to pytania wykraczające poza wiedzę udostępnioną Paulinie przez konkretną placówkę albo dotyczące spraw, których system celowo nie powinien rozstrzygać samodzielnie.

W takich sytuacjach Paulina nie próbuje zgadywać. Informuje pacjenta, że w tej konkretnej sprawie najlepszym rozwiązaniem będzie kontakt z rejestracją. To jest dla nas element bezpieczeństwa systemu, a nie błąd.

Co ciekawe, bardzo często rozmowa na tym się nie kończyła. Pacjent zadawał kolejne pytanie, przechodził do innego tematu albo kontynuował proces rejestracji. Sam komunikat o konieczności kontaktu z personelem nie oznacza więc automatycznie przerwania obsługi przez bota.

Dlatego na obecnym etapie bardziej precyzyjnie powiedzielibyśmy, że kilkaset wiadomości wymagało skierowania pacjenta do człowieka w konkretnej sprawie, natomiast liczba rozmów, które rzeczywiście musiały zostać całkowicie przejęte przez personel z powodu nieskuteczności systemu, jest od tego zdecydowanie mniejsza.

A o ile realnie spadła liczba nieodebranych telefonów albo obciążenie rejestracji w placówkach, które wdrożyły Paulinę?

Na ten moment nie chcielibyśmy podawać jednej wartości procentowej dotyczącej spadku liczby nieodebranych telefonów, ponieważ nie mamy jeszcze wystarczająco jednolitego pomiaru porównującego okres przed i po wdrożeniu Pauliny we wszystkich placówkach. Każda z nich ma trochę inny model pracy rejestracji, godziny dostępności i natężenie ruchu, więc taki wynik wymagałby osobnej, dobrze kontrolowanej analizy.

To, co już widzimy bardzo wyraźnie, to fakt, że Paulina nie zastąpiła kanału telefonicznego, ale otworzyła dodatkowy, bardzo aktywnie wykorzystywany sposób kontaktu z placówką. Rejestracja telefoniczna nadal pozostaje ważnym elementem obsługi, natomiast pacjenci równolegle bardzo chętnie korzystają z możliwości napisania wiadomości.

Jest to szczególnie ciekawe dlatego, że duża część rozmów z Pauliną odbywa się również w godzinach, w których normalnie działa rejestracja telefoniczna. Pacjent ma więc wybór - może zadzwonić albo napisać - a mimo to często wybiera kanał tekstowy. Jednocześnie znacząca liczba rozmów odbywa się wieczorem, kiedy telefoniczna rejestracja jest już niedostępna. To pokazuje, że Paulina nie tylko przejmuje część istniejącego ruchu, ale również pozwala obsłużyć zapotrzebowanie, które wcześniej pojawiało się poza godzinami pracy personelu.

Jak podchodzą do tego placówki?

Z perspektywy placówki oznacza to przede wszystkim odciążenie z bardzo powtarzalnych kontaktów. Duża część pytań dotyczy na przykład dostępnych usług, możliwości zapisów na NFZ, form płatności, lekarzy, lokalizacji czy przygotowania do wizyty. To są sprawy ważne dla pacjenta, ale jednocześnie takie, na które rejestratorka często odpowiada wielokrotnie w ciągu jednego dnia. Paulina może przejąć tę część komunikacji, pozostawiając personelowi więcej czasu na sytuacje wymagające rzeczywiście indywidualnej rozmowy.

Skoro system działa on-premise, jak wygląda kwestia kosztów infrastruktury w porównaniu do rozwiązań chmurowych? 

Na pierwszy rzut oka rozwiązania chmurowe wydają się tańsze, bo nie trzeba kupować własnego sprzętu – podpinamy API i płacimy za wykorzystanie. Przy prostym pilotażu rzeczywiście często jest to najbardziej opłacalna droga. Natomiast kiedy system zaczyna obsługiwać tysiące rozmów, wiele placówek i kilka różnych modeli jednocześnie, ekonomia zaczyna wyglądać trochę inaczej.

W naszym przypadku Paulina nie jest jednym modelem językowym, który odpowiada na każde pytanie. To cały zestaw współpracujących komponentów. Mamy warstwę językową, rozpoznawanie intencji, własne mechanizmy prowadzenia procesu, pracę na wiedzy placówki, a teraz - wraz z rozwojem voicebota - dochodzą kolejne modele, między innymi do rozpoznawania mowy i syntezy głosu.

Gdyby każdy z tych elementów był osobną usługą rozliczaną przez zewnętrznego dostawcę za każde zapytanie, każdy token, każdą minutę rozpoznanej mowy i każdą minutę wygenerowanego głosu, przy rosnącej skali zaczęlibyśmy kumulować wiele niezależnych kosztów. Do tego dochodzi zależność od cenników dostawców, które mogą się zmieniać.

Jak więc zmienia się rachunek ekonomiczny przy własnej infrastrukturze?

Na początku trzeba oczywiście ponieść koszt sprzętu i posiadać kompetencje potrzebne do jego utrzymania, ale później ta sama infrastruktura może obsługiwać wiele modeli, wiele procesów i wiele placówek. Nie płacimy osobno za każde wywołanie modelu w taki sposób, jak dzieje się to w klasycznym modelu API.

Kluczowe jest jednak słowo „dobrze zaprojektowana” infrastruktura. Nie chodzi o to, żeby do każdego zadania uruchamiać największy dostępny model na bardzo drogim serwerze. To byłoby zarówno technologicznie, jak i biznesowo nieracjonalne.

Jak pomagacie klientom, aby dostosować modele do zadania?

W naszym zespole mamy osoby zajmujące się nie tylko wykorzystaniem dużych modeli językowych, ale również badaniami nad samymi modelami. Część zespołu prowadzi prace naukowe nad tym, jak modele można przyspieszać, zmniejszać i specjalizować tak, żeby zachować potrzebną jakość przy znacznie mniejszych wymaganiach obliczeniowych.

I to ma ogromne znaczenie praktyczne. Jeżeli wiemy, że konkretne zadanie można rozwiązać mniejszym, wyspecjalizowanym modelem, nie ma sensu angażować do niego ogromnego LLM-a. Możemy dobierać odpowiedni model do zadania, dostrajać go, optymalizować i uruchamiać kilka takich komponentów na wspólnej infrastrukturze.

Domyślam się jednak, że zaprzęgnięcie do pracy głosu jest trudniejsze.

Dochodzą nam modele ASR, które zamieniają mowę pacjenta na tekst, oraz TTS, które generują odpowiedź głosową. One również będą działały w naszym środowisku. Nie chcemy budować systemu, w którym każda sekunda rozmowy telefonicznej powoduje kolejną opłatę u następnego zewnętrznego dostawcy.

Ważne jest też to, że duża część Pauliny to nasze autorskie rozwiązania, a nie tylko modele językowe. Sam LLM jest jednym z elementów znacznie większej architektury. Gdybyśmy chcieli wszystkie te funkcje kupować jako oddzielne usługi chmurowe, koszt i złożoność całego rozwiązania mogłyby rosnąć bardzo szybko.

A jeśli chodzi o bezpieczeństwo i kontrolę nad danymi? W ochronie zdrowia wykorzystuje się przecież informacje wrażliwe.

Dlatego możliwość utrzymania kluczowych elementów przetwarzania na własnej, kontrolowanej infrastrukturze ma dla nas dodatkową wartość. Nawet jeżeli patrząc wyłącznie na pojedyncze zapytanie jakaś usługa chmurowa byłaby chwilowo tańsza, nie jest to jedyny parametr, który bierzemy pod uwagę.

Czy opłaca się to nawet małej placówce?

Tutaj bardzo ważne jest jedno rozróżnienie: mała placówka nie musi budować własnego centrum obliczeniowego ani kupować serwerów z kartami graficznymi. To zaplecze jest po naszej stronie. Koszt infrastruktury rozkłada się na cały system i wiele obsługiwanych placówek.

Z perspektywy niewielkiej placówki najważniejsze jest więc to, czy koszt usługi jest niższy od wartości, którą dzięki niej uzyskuje: możliwości obsługi pacjentów po godzinach, przejęcia części rutynowych pytań, umożliwienia rejestracji bez telefonu i odciążenia personelu.

Dlatego paradoksalnie własna infrastruktura może mieć sens również właśnie dla mniejszych placówek – pod warunkiem, że nie każemy każdej z nich budować jej samodzielnie, tylko wykorzystujemy ją jako wspólne zaplecze technologiczne.

A co dokładnie dzieje się, gdy Paulina „nie wie", jak odpowiedzieć?

W obecnej wersji Paulina działa przede wszystkim jako chatbot, więc jeśli pojawia się pytanie, na które nie ma wystarczających informacji w swojej bazie wiedzy albo które wykracza poza zakres danej placówki i jej usług, system nie próbuje zgadywać odpowiedzi.

W takiej sytuacji Paulina informuje pacjenta, że w tej konkretnej sprawie najlepiej skontaktować się bezpośrednio z rejestracją i podaje odpowiednie dane kontaktowe.

Czy oznacza to, że cała rozmowa zostaje w tym momencie zakończona?

Nie, bo najczęściej problem dotyczy jednej, bardzo konkretnej informacji, której po prostu nie ma w wiedzy udostępnionej systemowi. Pacjent może więc od razu zadać kolejne pytanie, przejść do innego tematu, rozpocząć proces rejestracji na wizytę albo w praktyce rozpocząć rozmowę od nowa. Paulina nadal pozostaje dostępna i może obsłużyć wszystkie pozostałe sprawy, które znajdują się w jej zakresie.

To jest dla nas bardzo ważna zasada: jeśli system nie ma wystarczających podstaw do udzielenia odpowiedzi, wolimy, żeby powiedział to wprost i wskazał właściwy kanał kontaktu, niż żeby próbował wygenerować odpowiedź, której nie możemy być pewni.

Jednocześnie intensywnie rozwijamy obecnie voicebota i tutaj mechanizm będzie bardzo podobny, ale pojawi się dodatkowa możliwość płynnego przekazania rozmowy do człowieka.

Jeżeli podczas rozmowy telefonicznej Paulina trafi na sprawę, której nie będzie mogła poprawnie obsłużyć, poinformuje o tym dzwoniącego i będzie mogła zapytać, czy chce zostać połączony z rejestratorką. Jeżeli pacjent potwierdzi, połączenie zostanie przekierowane do rejestracji.

Czyli docelowo nie chcemy budować systemu, który za wszelką cenę próbuje samodzielnie zakończyć każdą rozmowę. Wręcz przeciwnie — jednym z elementów dobrze zaprojektowanej automatyzacji jest rozpoznanie momentu, w którym człowiek będzie lepszym rozwiązaniem.

Paulina ma samodzielnie obsługiwać sprawy, w których rzeczywiście może pomóc, natomiast w sytuacjach bardziej nietypowych, wymagających informacji spoza jej wiedzy albo indywidualnej decyzji personelu powinna potrafić bezpiecznie oddać rozmowę człowiekowi.