Architektura AI nie zaczyna się od wyboru modelu. Zaczyna się od decyzji, którą system ma wspierać, danych potrzebnych do jej podjęcia, granic odpowiedzialności oraz sposobu sprawdzania rezultatu.
To rozróżnienie jest ważne, ponieważ model językowy jest tylko jednym z komponentów rozwiązania. Dopiero połączenie go z kontekstem, regułami procesu, narzędziami, kontrolą dostępu i mechanizmami oceny tworzy system, który można świadomie wdrożyć i utrzymywać. Szerszy opis tych zależności przedstawiam w filarze Architektura Asystenta AI.
Najważniejsze wnioski
- Najpierw należy zdefiniować decyzję lub rezultat procesu, a dopiero potem dobierać technologię.
- Część procesu może pozostać deterministyczna, nawet jeżeli inne etapy korzystają z modelu probabilistycznego.
- RAG, dostrajanie modelu i system agentowy rozwiązują różne problemy; nie są zamiennikami analizy wymagań.
- Ocena rozwiązania musi obejmować jakość, koszt, czas, ryzyko i możliwość bezpiecznego zatrzymania procesu.
- Architektura pozostaje hipotezą do czasu sprawdzenia jej na danych i scenariuszach odpowiadających rzeczywistemu użyciu.
Teza: najważniejszym elementem architektury AI jest granica odpowiedzialności
System AI może przygotować klasyfikację, rekomendację, odpowiedź albo plan działania. Nie wynika z tego automatycznie, że powinien samodzielnie wykonać kolejną operację. Zakres autonomii powinien zależeć od skutków błędu, odwracalności działania, jakości dostępnych danych oraz możliwości wykrycia nieprawidłowego wyniku.
Dlatego przed wyborem modelu zadaję pięć pytań:
- Jaki konkretny rezultat ma powstać?
- Kto odpowiada za jego akceptację?
- Jak rozpoznamy wynik poprawny, błędny i niepewny?
- Które działania można odwrócić, a które wymagają zatwierdzenia?
- Jak system zachowa się, gdy zabraknie danych albo wystąpi sytuacja spoza znanego zakresu?
Jeżeli nie potrafimy odpowiedzieć na te pytania, problem nie jest jeszcze gotowy do projektowania architektury. Można wtedy zbudować demonstrator technologiczny, ale nie należy mylić go z rozwiązaniem produkcyjnym.
Model analityczny architektury AI
Na potrzeby analizy proponuję sześć współzależnych warstw. Nie jest to lista produktów ani obowiązkowy stos technologiczny. To model pytań, które pozwalają sprawdzić kompletność projektu.
Na węższym ekranie przesuń tabelę w poziomie, aby zobaczyć wszystkie kolumny.
| Warstwa | Pytanie projektowe | Oczekiwany rezultat analizy |
|---|---|---|
| Cel i odpowiedzialność | Jaką decyzję lub czynność wspiera system i kto odpowiada za rezultat? | Zakres, właściciel procesu, granice autonomii i kryteria akceptacji. |
| Dane i kontekst | Z jakich informacji system może korzystać i jakie obowiązują uprawnienia? | Źródła danych, zasady dostępu, jakość, aktualność i pochodzenie informacji. |
| Logika i model | Które elementy wymagają reguł, wyszukiwania, modelu ML albo LLM? | Uzasadniony podział między mechanizmami deterministycznymi i probabilistycznymi. |
| Narzędzia i integracje | Jakie operacje system może wykonać w innych aplikacjach? | Kontrakty integracyjne, zakres uprawnień, limity oraz sposób obsługi błędów. |
| Kontrola rezultatu | Jak wykryć wynik niepoprawny, niepełny lub ryzykowny? | Walidatory, testy, progi eskalacji, ślad audytowy i udział człowieka. |
| Eksploatacja i informacja zwrotna | Jak obserwować jakość, koszt i zmianę zachowania systemu? | Metryki, monitoring, wersjonowanie, procedura zatrzymania i plan doskonalenia. |
Warstwy tworzą zależność:
cel → dane → sposób wnioskowania → działanie → kontrola → informacja zwrotna
Nie jest to jednak jednokierunkowy potok. Wynik testu może ujawnić brak danych, zbyt szeroki zakres działania albo błędnie określony cel. Projektowanie wymaga więc iteracji, a nie jednorazowego narysowania diagramu.
Reguły, RAG, dostrajanie czy agent?
Wybór mechanizmu powinien wynikać z charakteru zadania:
- Reguły deterministyczne są właściwe tam, gdzie warunki są jednoznaczne, dane mają ustaloną strukturę, a wynik musi być powtarzalny.
- Wyszukiwanie i RAG pomagają wtedy, gdy odpowiedź powinna korzystać z kontrolowanego i zmieniającego się zbioru wiedzy. Sam RAG nie gwarantuje jednak poprawności odpowiedzi ani właściwego egzekwowania uprawnień.
- Dostrajanie modelu może być uzasadnione, gdy dostępny jest odpowiedni zbiór przykładów, a problem dotyczy zachowania modelu lub wykonania określonego zadania. Nie zastępuje ono mechanizmu aktualizowania wiedzy ani kontroli rezultatu.
- System agentowy ma sens, gdy zadanie wymaga kilku kroków, doboru narzędzi i reagowania na wyniki pośrednie. Wraz z zakresem działania rośnie jednak potrzeba limitów, rejestrowania operacji i możliwości przerwania procesu.
W jednym rozwiązaniu mechanizmy te mogą się uzupełniać. Formularz może zostać sprawdzony regułami, opis zinterpretowany przez model, procedura odnaleziona w kontrolowanym źródle, a końcowa decyzja pozostawiona człowiekowi.
Przykład analityczny: obsługa zgłoszenia
Poniższy przykład jest modelem decyzyjnym, a nie opisem konkretnego klienta. Organizacja chce skrócić czas obsługi zgłoszeń przychodzących w języku naturalnym. Początkowy pomysł zakłada użycie modelu do przeczytania wiadomości i automatycznego wysłania odpowiedzi.
1. Ustalenie granicy automatyzacji
Analiza pokazuje, że wiadomości różnią się skutkami. Część dotyczy prostych pytań informacyjnych, a część może prowadzić do zmiany umowy, płatności albo dostępu. Wspólna automatyczna ścieżka dla wszystkich przypadków byłaby zbyt szeroka.
Zakres pierwszej wersji zostaje więc ograniczony do:
- rozpoznania rodzaju zgłoszenia,
- wyszukania odpowiedniej procedury,
- przygotowania projektu odpowiedzi,
- wskazania użytych źródeł,
- przekazania przypadków niepewnych do operatora.
System nie wysyła samodzielnie odpowiedzi wywołujących skutki prawne lub finansowe.
2. Rozdzielenie mechanizmów
Warunki formalne, takie jak obecność wymaganych pól i uprawnienie użytkownika, są sprawdzane deterministycznie. Model językowy interpretuje treść zgłoszenia. Aktualne procedury są pobierane z kontrolowanego źródła, a wygenerowana odpowiedź musi wskazać, na jakim materiale się opiera.
Takie rozdzielenie ogranicza liczbę decyzji pozostawionych modelowi i ułatwia ustalenie miejsca powstania błędu.
3. Kryteria oceny
Przed pilotażem nie należy przyjmować dowolnych wartości procentowych jako gwarancji sukcesu. Progi akceptacji powinny wynikać z bazowego pomiaru procesu oraz konsekwencji błędu. Warto obserwować co najmniej:
- poprawność klasyfikacji zgłoszeń,
- odsetek odpowiedzi opartych na właściwym źródle,
- liczbę przypadków skierowanych do człowieka,
- liczbę niebezpiecznych lub niedozwolonych działań,
- czas obsługi jednego zgłoszenia,
- koszt jednostkowy działania systemu,
- częstotliwość ręcznych korekt.
4. Interpretacja wyniku
Jeżeli system dobrze klasyfikuje proste sprawy, ale myli przypadki o wysokim wpływie, średnia skuteczność może wyglądać poprawnie, a rozwiązanie nadal nie powinno otrzymać większej autonomii. Wynik trzeba analizować osobno dla klas ryzyka i typów zgłoszeń.
Jeżeli koszt rośnie szybciej niż wolumen albo operatorzy poprawiają większość odpowiedzi, problemem może być zbyt szeroki zakres, niewłaściwy model, słabe źródła lub nieprecyzyjne kryteria jakości. Zmiana dostawcy modelu nie musi wtedy rozwiązać przyczyny.
Projekt Venom jako sprawdzian koncepcji
W Projekcie Venom punktem wyjścia było nie samo generowanie odpowiedzi, lecz monitorowanie procesu decyzyjnego i sterowanie jego przebiegiem tam, gdzie działania mają konsekwencje. Projekt służy mi do praktycznego sprawdzania tez rozwijanych w koncepcji Asystenta AI.
Najważniejsza obserwacja z tego przykładu dotyczy pętli kontroli. Agent może zaproponować lub wykonać kolejny krok, ale wynik musi zostać zarejestrowany, oceniony i wykorzystany przy podejmowaniu następnej decyzji. Bez tej informacji system wykonuje sekwencję poleceń, lecz nie tworzy kontrolowanego procesu.
Venom nie jest dowodem, że jedna architektura będzie właściwa dla każdej organizacji. Pokazuje natomiast, dlaczego mechanizmy kontroli, odpowiedzialności i informacji zwrotnej powinny powstać razem z logiką działania, a nie dopiero po uruchomieniu rozwiązania.
Ryzyko, bezpieczeństwo i regulacje
Zakres wymaganych zabezpieczeń zależy od zastosowania, roli organizacji, rodzaju danych i klasyfikacji systemu. Nie każdy system podlega tym samym obowiązkom. Unijny AI Act przewiduje szczegółowe wymagania między innymi dla systemów wysokiego ryzyka, w tym ciągły proces zarządzania ryzykiem w całym cyklu życia.
Również ryzyka techniczne muszą być oceniane w kontekście konkretnej architektury. Jeżeli model przetwarza treść z zewnętrznych dokumentów albo stron, należy uwzględnić możliwość manipulacji instrukcjami. Jeżeli wykonuje działania przez narzędzia, trzeba ograniczyć uprawnienia i walidować rezultaty przed przekazaniem ich do kolejnego systemu.
Zamiast ogólnej deklaracji „system jest bezpieczny”, architektura powinna wskazywać:
- jakie zagrożenia zostały rozpoznane,
- które zabezpieczenia je ograniczają,
- jak sprawdzana jest skuteczność zabezpieczeń,
- jakie ryzyko pozostaje po ich zastosowaniu,
- kto może zaakceptować ryzyko albo zatrzymać wdrożenie.
Jak doszedłem do tego wniosku?
Do przedstawionego modelu doszedłem, zestawiając trzy perspektywy obecne w mojej pracy: analizę procesów i wymagań, projektowanie systemów oraz praktyczne eksperymenty z agentami AI. W każdej z nich powtarza się ten sam problem: technologia może działać zgodnie ze specyfikacją, a cały proces nadal nie dostarczać oczekiwanego rezultatu.
Analiza biznesowo-systemowa zmusza do nazwania celu, aktorów, reguł i wyjątków. Architektura pokazuje zależności między komponentami. Implementacja ujawnia natomiast miejsca, w których założenia nie wytrzymują kontaktu z danymi, ograniczeniami integracji albo rzeczywistym zachowaniem użytkownika.
Dlatego traktuję architekturę nie jako jednorazowy dokument, lecz jako zestaw jawnych hipotez, które można zweryfikować. Każda ważna decyzja powinna mieć uzasadnienie, kryterium oceny i warunek ponownego rozpatrzenia.
Co wnosi architekt rozwiązań AI?
Rola architekta nie polega na automatycznym wyborze najbardziej rozbudowanej technologii. Polega na utrzymaniu spójności między potrzebą biznesową, procesem, danymi, modelem, integracjami, ryzykiem i sposobem eksploatacji.
W praktyce oznacza to między innymi:
- oddzielenie problemu biznesowego od proponowanego narzędzia,
- zdefiniowanie granic odpowiedzialności systemu i człowieka,
- udokumentowanie alternatyw oraz powodów podjętej decyzji,
- zaprojektowanie pomiaru przed rozszerzaniem zakresu,
- zaplanowanie obsługi błędów, zmian modelu i wycofania rozwiązania.
Zakres pracy i czas projektu zależą od procesu, danych, integracji, wymagań bezpieczeństwa oraz gotowości organizacji. Bez tych informacji nie da się rzetelnie podać uniwersalnego harmonogramu ani zagwarantować zwrotu z inwestycji.
Wniosek
Dobra architektura AI nie maksymalizuje liczby komponentów wykorzystujących sztuczną inteligencję. Wyznacza miejsce, w którym model wnosi wartość, oraz miejsca, w których lepsze pozostają reguły, klasyczne oprogramowanie lub decyzja człowieka.
Przejście do produkcji powinno być decyzją opartą na wynikach testów, kosztach i zaakceptowanym ryzyku. Dopiero wtedy prototyp staje się elementem kontrolowanego systemu.
