Cyfryzacja lokalnych usługodawców z wykorzystaniem RAG i lokalnych modeli

Jeszcze niedawno cyfryzacja lokalnej firmy często zaczynała się i kończyła na założeniu skrzynki e-mail oraz stworzeniu arkusza kalkulacyjnego. Czasami pojawiał się też zeszyt z numerami telefonów klientów. Zeszyt miał tę zaletę, że działał bez baterii, ale gorzej radził sobie z wyszukiwaniem historii kontaktu, współdzieleniem informacji i odzyskiwaniem danych po zalaniu kawą.

Dzisiaj lokalni usługodawcy coraz częściej widzą, że cyfryzacja może przynieść konkretną, a więc również monetyzowalną wartość. Dobrze zaprojektowany system może skrócić czas obsługi klienta, ograniczyć liczbę pomyłek, ułatwić pracę zespołu, zwiększyć liczbę obsługiwanych spraw i pomóc lepiej wykorzystać wiedzę, która wcześniej była rozproszona po dokumentach, wiadomościach i głowach pracowników.

Nie oznacza to jednak, że każda firma potrzebuje od razu rozbudowanego systemu korporacyjnego, dziesięciu dashboardów i centrum dowodzenia z ekranami zajmującymi całą ścianę. Często większą wartość daje mały, dobrze dopasowany proces, który rozwiązuje konkretny problem.

Cyfryzacja ma sens wtedy, gdy poprawia wynik

Samo przeniesienie papierowego formularza do aplikacji nie jest jeszcze cyfryzacją procesu. Jest tylko zmianą miejsca, w którym ten sam problem będzie występował.

Warto zacząć od pytania: gdzie firma traci dziś najwięcej czasu albo pieniędzy?

Może chodzić o:

wielokrotne odpowiadanie na te same pytania,
ręczne przepisywanie danych z dokumentów,
trudności w odnalezieniu ustaleń z klientem,
brak spójnych informacji w zespole,
pomijanie ważnych kroków w procesie,
zbyt długie przygotowywanie ofert,
trudności w obsłudze większej liczby zgłoszeń,
zależność firmy od jednej osoby, która „wie, jak to działa”.

Jeżeli system skraca czas obsługi, pozwala przyjąć więcej zleceń, ogranicza liczbę błędów albo poprawia doświadczenie klienta, łatwiej ocenić jego wartość. Wtedy technologia przestaje być kosztem w kategorii „nowoczesne narzędzia”, a zaczyna być inwestycją w konkretny proces biznesowy.

Wiedza firmy jest cenna, ale często słabo dostępna

Lokalni usługodawcy mają zwykle dużo praktycznej wiedzy. Znają najczęstsze pytania klientów, wyjątki od standardowych procedur, zasady wyceny, sposób rozwiązywania problemów i szczegóły, których nie da się znaleźć w publicznej instrukcji.

Problem polega na tym, że ta wiedza często jest rozproszona pomiędzy:

dokumentami PDF,
umowami,
cennikami,
instrukcjami,
wiadomościami e-mail,
komunikatorami,
arkuszami,
historią wcześniejszych spraw,
prywatnymi notatkami pracowników.

Znalezienie właściwej informacji może wymagać przeszukania kilku miejsc albo zapytania osoby, która akurat jest na urlopie, spotkaniu lub — jak to zwykle bywa — „zaraz oddzwoni”.

Dobrze zaprojektowany system może zebrać te źródła w jeden kontrolowany przepływ. Nie musi od razu zastępować istniejących narzędzi. Może zacząć od wyszukiwania informacji, przygotowania odpowiedzi albo wsparcia pracownika podczas obsługi klienta.

RAG, czyli model z dostępem do właściwych informacji

RAG oznacza Retrieval-Augmented Generation. W praktyce jest to sposób łączenia modelu językowego z dokumentami i danymi konkretnej organizacji.

Model nie musi polegać wyłącznie na wiedzy zdobytej podczas treningu. Najpierw system wyszukuje odpowiednie fragmenty dokumentów, a dopiero potem przekazuje je modelowi jako kontekst do przygotowania odpowiedzi.

Przykładowe pytanie może brzmieć:

> Jakie dokumenty są potrzebne do rozpoczęcia tej usługi i jaki jest aktualny termin realizacji?

System może wyszukać odpowiednie informacje w procedurach, cenniku i wewnętrznej bazie spraw, a następnie przygotować odpowiedź opartą na tych danych.

RAG może wykorzystywać:

procedury obsługi,
cenniki,
dokumentację produktów,
instrukcje dla pracowników,
regulaminy,
historię spraw,
katalog usług,
informacje o dostępności,
szablony odpowiedzi,
wewnętrzne zasady podejmowania decyzji.

Ważne jest to, że RAG nie oznacza „wrzućmy wszystkie pliki do AI i zobaczmy, co się stanie”. Dokumenty muszą zostać przygotowane, podzielone na sensowne fragmenty, opisane i udostępnione zgodnie z uprawnieniami.

Jeżeli system nie znajdzie odpowiednich danych, powinien umieć powiedzieć, że ich nie znalazł. To znacznie lepsze niż pewna siebie odpowiedź zbudowana na domyśle.

AI nie musi oznaczać chmury

Wokół AI często pojawia się założenie, że każdy system musi wysyłać dane do zewnętrznej usługi chmurowej. Tak nie jest.

Architekturę można zaprojektować na kilka sposobów, zależnie od rodzaju danych, wymagań dotyczących poufności, kosztów, dostępnej infrastruktury i oczekiwanego poziomu kontroli.

Możliwe podejścia obejmują:

korzystanie z zewnętrznego modelu przez bezpieczne API,
uruchomienie modelu lokalnie na infrastrukturze firmy,
użycie prywatnej chmury lub odizolowanego środowiska,
połączenie modeli lokalnych i chmurowych,
przechowywanie dokumentów lokalnie przy użyciu zewnętrznego modelu tylko dla wybranych, oczyszczonych danych.

Nie istnieje jedno rozwiązanie dobre dla każdej firmy. Dla jednego usługodawcy najlepsza będzie prosta integracja z zewnętrznym API. Dla innego ważniejsze będzie utrzymanie danych na własnej infrastrukturze albo w środowisku z wyraźną izolacją.

Routing modeli: właściwe zadanie, właściwy model

Jednym z ciekawszych podejść jest routing modeli. Zamiast kierować każde zadanie do jednego, najdroższego albo największego modelu, system może najpierw określić rodzaj zapytania i dobrać odpowiednią ścieżkę.

Przykładowo:

proste pytanie o godziny otwarcia może obsłużyć mały model lokalny albo zwykła reguła,
wyszukanie informacji w cenniku może wykorzystać RAG i lokalny model,
trudniejsza analiza dokumentu może zostać przekazana do większego modelu,
zapytanie zawierające szczególnie poufne dane może pozostać w lokalnym środowisku,
sprawa wymagająca decyzji człowieka może zostać przekazana pracownikowi.

Routing może uwzględniać:

poziom poufności danych,
rodzaj zadania,
złożoność pytania,
wymagany czas odpowiedzi,
koszt przetwarzania,
dostępność modelu,
wymagany poziom dokładności.

Dzięki temu architektura nie musi być wyborem „albo wszystko lokalnie, albo wszystko w chmurze”. Można połączyć kilka modeli i kilka środowisk, a system może kierować zadania tam, gdzie ma to największy sens.

To trochę jak dobrze działająca recepcja. Nie każda sprawa trafia do dyrektora. Czasem wystarczy odpowiedź z cennika, czasem potrzebny jest specjalista, a czasem najlepiej od razu powiedzieć klientowi, że sprawą zajmie się człowiek.

Lokalne modele i poufność danych

Jeżeli firma pracuje z danymi klientów, umowami, cenami, dokumentacją medyczną, informacjami finansowymi albo wewnętrznymi procedurami, poufność może być kluczowym wymaganiem.

W takim przypadku można rozważyć lokalny model działający:

na serwerze organizacji,
na urządzeniu znajdującym się w siedzibie firmy,
w zamkniętej sieci,
w odizolowanym środowisku chmurowym,
w infrastrukturze zarządzanej przez zaufanego dostawcę.

Lokalne uruchomienie modelu może zwiększyć kontrolę nad tym, gdzie znajdują się dane, kto ma do nich dostęp i jak długo są przechowywane. Nie oznacza jednak automatycznie pełnego bezpieczeństwa.

Nadal trzeba zaprojektować:

uprawnienia użytkowników,
izolację danych pomiędzy klientami,
szyfrowanie,
logowanie dostępu,
politykę przechowywania,
usuwanie danych,
kopie zapasowe,
monitoring,
aktualizacje modeli i infrastruktury.

Lokalny model jest elementem architektury, a nie magicznym zaklęciem bezpieczeństwa. Sam fakt, że działa na komputerze w firmie, nie rozwiązuje problemu źle ustawionych uprawnień.

Izolowana chmura jako kompromis

Nie każda organizacja chce albo może utrzymywać własny sprzęt, modele i środowisko uruchomieniowe. Modele lokalne wymagają infrastruktury, aktualizacji, monitoringu i kompetencji technicznych.

W takich sytuacjach alternatywą może być środowisko chmurowe z odpowiednią izolacją. Dane mogą być przechowywane w wydzielonej przestrzeni, a dostęp do nich może być ograniczony do konkretnej organizacji i jej użytkowników.

Można również zastosować dodatkowe zabezpieczenia:

separację tenantów,
prywatne sieci,
ograniczenie dostępu do API,
szyfrowanie danych,
pseudonimizację,
filtrowanie informacji przed wysłaniem do modelu,
osobne środowiska dla testów i produkcji,
kontrolę retencji danych.

Wybór pomiędzy lokalnym modelem a izolowaną chmurą powinien wynikać z rzeczywistych wymagań. Nie ma sensu uruchamiać własnej infrastruktury tylko dlatego, że brzmi to bardziej technicznie, jeśli firma nie potrzebuje takiego poziomu kontroli. Z drugiej strony wysyłanie wszystkich danych do zewnętrznej usługi bez analizy ryzyka również nie jest dobrym planem.

Najpierw jeden proces, później większy system

Cyfryzacja często kończy się źle wtedy, gdy zaczyna się od próby zbudowania „AI dla całej firmy”. Taki projekt brzmi ambitnie, ale trudno określić jego zakres, koszt i rezultat.

Lepszym podejściem jest wybór jednego procesu, który:

powtarza się często,
zabiera pracownikom dużo czasu,
korzysta z istniejących danych,
ma jasny początek i koniec,
pozwala zmierzyć efekt.

Może to być:

wyszukiwanie informacji w dokumentach,
przygotowywanie odpowiedzi na typowe pytania,
klasyfikacja zgłoszeń,
tworzenie podsumowań rozmów,
przygotowanie pierwszej wersji oferty,
obsługa zapytań klientów,
wyszukiwanie informacji o historii współpracy,
przekazywanie spraw do właściwej osoby.

Jeżeli pierwszy proces działa dobrze, można stopniowo dołączać kolejne. W ten sposób system rozwija się razem z firmą, zamiast próbować od pierwszego dnia odwzorować każdy wyjątek, który wydarzył się w jej historii.

Jak cyfryzacja zaczyna przynosić pieniądze?

Korzyści z cyfryzacji nie muszą ograniczać się do oszczędności czasu. Mogą przekładać się bezpośrednio na przychód albo marżę.

System może pomóc:

obsłużyć więcej klientów tym samym zespołem,
szybciej odpowiadać na zapytania,
skrócić czas przygotowania oferty,
ograniczyć liczbę błędów i reklamacji,
zwiększyć dostępność obsługi poza godzinami pracy,
lepiej wykorzystywać wolne terminy,
szybciej rozpoznawać wartościowe zapytania,
ułatwić sprzedaż usług dodatkowych,
ograniczyć zależność od jednej osoby.

Warto mierzyć efekty przed wdrożeniem. Nie muszą to być skomplikowane analizy. Czas odpowiedzi, liczba obsłużonych spraw, liczba błędów albo liczba zapytań kończących się sprzedażą często wystarczą, aby sprawdzić, czy rozwiązanie działa.

Jeżeli nie da się powiedzieć, jaki proces ma się poprawić, trudno później ocenić, czy projekt zakończył się sukcesem.

Człowiek pozostaje częścią procesu

Automatyzacja nie oznacza, że człowiek powinien zostać usunięty z każdego przepływu. W wielu przypadkach najlepszym rozwiązaniem jest model hybrydowy.

System może:

znaleźć właściwe informacje,
przygotować propozycję odpowiedzi,
oznaczyć poziom pewności,
wskazać źródła,
sklasyfikować sprawę,
przekazać ją właściwej osobie.

Pracownik może następnie zaakceptować wynik, poprawić go albo zdecydować, że sprawa wymaga indywidualnego podejścia.

To szczególnie ważne wtedy, gdy odpowiedź ma konsekwencje finansowe, prawne, operacyjne albo dotyczące klienta. AI może przyspieszyć pracę, ale nie powinna ukrywać niepewności ani udawać, że zna odpowiedź na każde pytanie.

Dobrze zaprojektowany system rośnie razem z firmą

RAG, lokalne modele i routing modeli dają możliwość budowania systemów dopasowanych do rzeczywistych potrzeb organizacji. Nie trzeba wybierać pomiędzy prostym chatbotem a ogromną platformą AI.

Można zacząć od jednego procesu, sprawdzić rezultat, zmierzyć wartość i stopniowo dodawać kolejne elementy. W zależności od danych można użyć modelu lokalnego, izolowanej chmury albo połączenia kilku podejść.

Najważniejsze decyzje dotyczą nie samego modelu, ale całego systemu:

skąd pochodzą dane,
kto może z nich korzystać,
jak wybierany jest model,
gdzie odbywa się przetwarzanie,
jak sprawdzana jest odpowiedź,
co dzieje się w przypadku błędu,
kiedy do procesu włącza się człowiek.

Cyfryzacja lokalnych usługodawców nie musi być wielkim projektem transformacyjnym. Może być spokojnym, etapowym sposobem na uporządkowanie wiedzy, poprawę obsługi i zwiększenie wartości usług.

A zeszyt? Można go zachować. Najlepiej jednak jako pamiątkę, a nie główny system informatyczny firmy.