Gotowe frameworki agentów nie sprawdzają się w sektorze bankowym. Tak, właśnie od tego chciałbym zacząć, i nie, ani bardziej przejrzysta strategia podpowiedzi, ani bardziej restrykcyjna brama API tego nie zmieniają.
Standardowy zestaw składający się z LangChain, narzędzi, bazy danych wektorowej oraz bramy API pozwala na uruchomienie agenta. Może on przekierowywać intencje, pobierać kontekst, wywoływać narzędzia i zwracać dopracowaną odpowiedź. W porządku. Jednak w sektorze bankowym problem nie polega na tym, czy agent “potrafi wywołać API”. Sektor bankowy zawodzi na poziomie: “Czy ta rozmowa została zatwierdzona, objęta zakresem, zweryfikowana, zarejestrowana i czy można ją bezpiecznie pokazać temu klientowi?”. To już zupełnie inny problem związany z architekturą.
Są trzy powody, dla których nie wdrożyłbym standardowego stosu agentów w środowisku produkcyjnym obsługującym procesy bankowe bez dodania dedykowanej warstwy zaufania.
Po pierwsze, dane finansowe to dane dotyczące zobowiązań. Błędna informacja podana przez chatbota w handlu detalicznym jest kłopotliwa. Błędne dane dotyczące salda, statusu transakcji, wyjaśnienia opłat lub decyzji kredytowej mogą narazić firmę na konsekwencje prawne. Zgodnie z Obowiązek FCA wobec konsumentów, Na przykład instytucja musi wykazać, że klienci otrzymują rzetelne, zrozumiałe i odpowiednie wsparcie. Jeśli model zaproponuje nieprawidłową opcję spłaty lub błędnie wyjaśni produkt, nie można wzruszyć ramionami i zrzucić winy na “sztuczną inteligencję”. Bank ponosi odpowiedzialność za wynik. Dlatego architektura musi traktować każde stwierdzenie dotyczące faktów jako coś, co należy zweryfikować w systemie źródłowym.
Po drugie, wielodostępność to nie tylko kwestia wyboru projektu produktu. Jeśli z jednej platformy obsługujesz wielu klientów bankowych, akceptantów, jednostki biznesowe lub regiony, izolacja dzierżawców musi być zapewniona na każdym poziomie: monitach, pamięci, indeksach wektorowych, uprawnieniach narzędzi, logach, kluczach Redis, wierszach bazy danych, sekretach oraz eksportach audytowych. Pojedynczy wyciek między dzierżawcami nie jest zgłoszeniem błędu. Może to być zdarzenie podlegające zgłoszeniu. Dlatego nie lubię architektur, w których agent ma szeroki dostęp, a warstwa aplikacji “pamięta”, aby później filtrować dane. Filtrowanie w późniejszym czasie jest przyczyną wycieków danych.
Po trzecie, model LLM jest najmniej wiarygodnym elementem w całym łańcuchu. Brzmi to surowo, ale to słuszne założenie. Model ma charakter probabilistyczny. Może wykonywać złośliwe polecenia, nadmiernie ufać pobranemu kontekstowi lub ujawnić dane osobowe w podsumowaniu. Może wygenerować wywołanie narzędzia, które wygląda na prawidłowe, dopóki nie sprawdzi się jego parametrów. Dlatego nigdy nie pozwoliłbym, aby model znajdował się bezpośrednio obok podstawowych interfejsów API systemu bankowego.
Bezpieczniejszym podejściem jest pozostawienie wnioskowania modelowi, a egzekwowanie zasad – systemom deterministycznym. Wnioskowanie należy do warstwy agenta. Egzekwowanie należy do walidatorów schematów, kontroli zgodności z polityką, uprawnień w zakresie dzierżawcy, bram zatwierdzających i dzienników audytowych. Po dokonaniu tego podziału architektura przestaje być łańcuchem wywołań API sterowanych modelem i staje się kontrolowanym systemem zaufania, w którym LLM jest traktowany jako użyteczny, ale niewiarygodny komponent wnioskowania.
Pewne ujęcie ułatwia zastosowanie tego podziału. Kiedy przyglądam się agentowi bankowemu, interesuje mnie przede wszystkim to, jak duże uprawnienia posiada i jak daleko te uprawnienia sięgają od osoby, która je przyznała. Możliwości wskazują, jak dobra jest wersja demonstracyjna. Uprawnienia określają, w jakim zakresie system może sprawować kontrolę. Genialny model połączony z narzędziami tylko do odczytu to „cienki asystent”. Nudny model posiadający stały klucz umożliwiający przenoszenie środków stanowi zupełnie inny problem i wymaga wszystkich warstw poniżej. W artykule podzieliłem tę oś uprawnień na cztery klasy — asystenta, koordynatora, operatora i podmiotu gospodarczego — Nie każdy agent jest podmiotem gospodarczym.
Zatrudnij nas
O nas