AI System Architecture bez slajdowej mgły: jak projektować systemy z LLM, RAG i agentami tak, żeby dało się je utrzymać w produkcji

Najwięcej złych decyzji architektonicznych bierze się z tego, że ludzie próbują narysować AI jak kolejny mikroserwis

To jest zrozumiałe. Klasyczny software engineering nauczył nas myśleć warstwami: frontend, backend, baza, kolejka, cache, observability, CI/CD. Kiedy pojawia się AI, odruch jest prosty: dokładamy model jako nowy komponent i jedziemy dalej. W małym proof of concept to czasem wystarcza. W prawdziwym systemie zwykle nie.

Dlaczego? Bo system oparty o LLM, RAG, narzędzia i czasem agentową pętlę nie jest tylko backendem z dodatkowym API. To system, w którym część logiki staje się probabilistyczna, część danych wchodzi do promptu w runtime, część odpowiedzialności za wybór kolejnego kroku przejmuje model, a źródło błędu może siedzieć równie dobrze w retrievalu, co w promptcie, narzędziu, kontekście albo polityce uprawnień.

Właśnie dlatego AI system architecture nie polega na tym, żeby „podpiąć model”. Polega na tym, żeby rozdzielić odpowiedzialności tak, aby:

• model nie robił rzeczy, których nie powinien robić,
• dane trafiały do niego w kontrolowany sposób,
• decyzje o wysokim ryzyku nie były oddawane czystemu promptowi,
• system dawał się debugować, mierzyć i utrzymywać.

Jeśli chcesz spojrzeć na to jeszcze bardziej wykonawczo od strony modeli i ich codziennego użycia, dobrym uzupełnieniem jest też LLM engineering jako rdzeń pracy AI Engineera.

Najprostszy zdrowy podział: model to tylko jeden z komponentów, nie centrum całego świata

W dojrzałej architekturze AI zwykle warto rozdzielić przynajmniej te warstwy:

• warstwę wejścia i orkiestracji żądania,
• warstwę retrievalu i dostępu do wiedzy,
• warstwę promptów i kontraktów outputu,
• warstwę narzędzi i integracji z systemami zewnętrznymi,
• warstwę walidacji, bezpieczeństwa i uprawnień,
• warstwę observability, evali i feedback loopu.

To nie znaczy, że od razu potrzebujesz wielkiego platform engineeringu. Chodzi raczej o to, żeby nie mieszać wszystkiego w jednym, nieprzezroczystym handlerze, w którym połowa logiki siedzi w promptcie, a druga połowa w przypadkowo pospinanych utilach.

Najważniejsza zasada jest prosta: model powinien być bardzo dobry w tych zadaniach, w których probabilistyczne wnioskowanie daje przewagę, a kod powinien nadal kontrolować wszystko, co wymaga deterministyczności, uprawnień albo twardych reguł.

AI Solution Design zaczyna się od pytania o tryb pracy systemu

Zanim wybierzesz model, framework albo bazę wektorową, warto odpowiedzieć na bardziej fundamentalne pytanie: jaki to właściwie typ systemu?

Najczęstsze warianty są cztery.

Pierwszy to single-shot generator. Użytkownik podaje wejście, model odpowiada, koniec. Tu architektura może być lekka, bo nie ma wieloetapowej pętli ani dużej pamięci zadania.

Drugi to RAG-based assistant. Model odpowiada na podstawie dokumentów lub indeksu wiedzy. W tym wariancie kluczowe stają się jakość retrievalu, chunking, filtrowanie metadanych i sposób składania kontekstu.

Trzeci to tool-rich workflow. Model podejmuje decyzję, czy użyć narzędzia, pobrać stan z systemu, wykonać kolejny krok, a dopiero potem odpowiedzieć. Tu bardzo ważne robią się kontrakty narzędzi, kontrola skutków ubocznych i granice autonomii.

Czwarty to agentic system. Model działa w pętli, utrzymuje stan zadania, planuje, wywołuje narzędzia i aktualizuje własny kontekst. To jest najdroższy i najbardziej złożony wariant, więc nie powinien być domyślnym wyborem tylko dlatego, że dobrze wygląda na slajdzie. Jeśli wchodzisz w ten obszar, dobrze domyka to też artykuł o AI agents i agentic systems bez ściemy.

RAG Architecture, tool calling i agent orchestration to trzy różne problemy, których nie warto wrzucać do jednego worka

To częsta pułapka. Zespół mówi: „budujemy architekturę agentową”, a w praktyce robi po prostu RAG z jednym krokiem wyboru narzędzia. To nie jest zbrodnia, ale jeśli źle nazwiesz problem, łatwo dobierzesz złą złożoność rozwiązania.

RAG architecture odpowiada głównie na pytanie: jak dostarczyć modelowi właściwy materiał dowodowy z własnych źródeł wiedzy.

Tool calling odpowiada na pytanie: jak pozwolić modelowi korzystać z deterministycznych funkcji i systemów zewnętrznych bez oddawania mu całej kontroli.

Agent orchestration odpowiada na pytanie: jak sterować wieloetapowym przebiegiem, stanem i warunkami zatrzymania, kiedy kolejny krok nie jest z góry ustalony.

Te rzeczy mogą występować razem, ale nie muszą. I bardzo często sensowniej jest zacząć od prostszego układu:

• RAG bez agentowej pętli,
• tool use bez wieloagentowej orkiestracji,
• workflow z checkpointami zamiast pełnej autonomii.

Najdroższa architektura AI to zwykle nie ta z największą liczbą komponentów, tylko ta, która dodała agentową złożoność do problemu, który dało się rozwiązać prostym workflowem.

Jak wygląda sensowna architektura AI w praktyce

Najczęściej dobrze działa układ, w którym request przechodzi przez kilka bardzo czytelnych etapów.

Najpierw masz warstwę wejściową, która zbiera pytanie, stan użytkownika, tenant, uprawnienia i kontekst operacyjny. Już tutaj warto odsiać rzeczy oczywiste: brak wymaganych parametrów, nieobsługiwane żądanie, próby wejścia w niedozwolony obszar.

Potem wchodzi warstwa przygotowania kontekstu. To może być retrieval, odpytanie wewnętrznych API, pobranie historii sprawy, lekkie klasyfikowanie intencji albo routing do właściwego subflowu. Chodzi o to, żeby model nie zaczynał od zgadywania, jeśli system może najpierw zebrać lepszy materiał.

Dalej masz warstwę modelową, czyli prompt stack, kontrakt odpowiedzi, ewentualny tool selection i sama generacja. Tu model powinien dostać maksymalnie czysty i uporządkowany input, a nie śmietnik z całej aplikacji.

Po odpowiedzi modelu potrzebna jest warstwa walidacji i polityk. Structured output, schema validation, sprawdzenie limitów, filtrów bezpieczeństwa, akcji wymagających approval i zgodności z oczekiwanym formatem.

Na końcu wchodzi warstwa obserwowalności i zapisu śladu: tokeny, czas, źródła, wybrane narzędzia, sukces lub porażka walidacji, koszty, sygnały do evali.

To brzmi może mało romantycznie, ale dokładnie taka nuda architektoniczna odróżnia system produkcyjny od imponującego demka.

Single-agent i multi-agent architecture: gdzie jest sens, a gdzie jest teatr

Single-agent system ma jedną wielką zaletę: jest prostszy do zrozumienia, mierzenia i ograniczania. Jeśli jeden agent ma dobrze zdefiniowane narzędzia, jawny stan, limit kroków i checkpointy, to w bardzo wielu przypadkach w zupełności wystarcza.

Multi-agent architecture zaczyna mieć sens dopiero wtedy, gdy specjalizacja naprawdę redukuje chaos. Na przykład:

• osobny agent do retrievalu,
• osobny do planowania,
• osobny do generowania finalnej odpowiedzi,
• osobny do ewaluacji albo governance.

Ale trzeba być uczciwym: wiele systemów wieloagentowych to po prostu bardziej skomplikowany sposób na zrobienie tego, co dało się zrealizować sekwencją zwykłych kroków w workflowie. Jeśli nie ma mocnego powodu do rozdzielenia ról, multi-agent system często daje więcej kosztu, więcej latencji i więcej miejsc na porażkę niż zysku.

AI Patterns & Best Practices, które są nudne, ale działają

Najbardziej produkcyjnie wygrywają dziś wzorce, które nie próbują robić z modelu wszechwładnego komponentu.

Pierwszy to retrieval before generation. Zanim model zacznie syntezować odpowiedź, system dostarcza mu możliwie najlepszy dowód.

Drugi to plan before action tam, gdzie zadanie jest wieloetapowe. Nie chodzi o wielką autonomię, tylko o lepszą strukturę decyzji.

Trzeci to typed tools with least privilege. Narzędzia powinny mieć jawne schematy wejścia, ograniczony zakres i sensowne uprawnienia.

Czwarty to human-in-the-loop na granicach ryzyka. Tam, gdzie skutki błędu są duże, człowiek nie powinien być opcjonalnym dodatkiem po incydencie.

Piąty to evals and telemetry by default. Jeśli architektura nie zostawia śladu, nie da się jej poprawiać uczciwie.

AI Prototyping i R&D: kiedy warto pozwolić sobie na brudniejszą architekturę

W fazie prototypu oczywiście nie zawsze opłaca się budować pełną platformę. Tu chodzi o znalezienie właściwego poziomu dyscypliny. Prototyp ma prawo być prostszy, ale nie powinien maskować fundamentalnych ryzyk.

Jeżeli w PoC ignorujesz:

• źródła prawdy,
• koszt tokenów,
• jakość retrievalu,
• bezpieczeństwo narzędzi,
• mierzenie skuteczności,

to nie budujesz prototypu produktu. Budujesz pokaz możliwości modelu. To też bywa użyteczne, ale nie należy mylić jednego z drugim.

Najlepsze prototypy AI są proste, ale już od startu uczą czegoś o prawdziwej architekturze końcowej: o danych, o kosztach, o jakości i o tym, gdzie model naprawdę pomaga.

Czerwone flagi, po których od razu widać, że architektura AI jest bardziej slajdem niż systemem

Jest kilka sygnałów ostrzegawczych, które pojawiają się bardzo wcześnie. Pierwszy: nikt nie umie jasno powiedzieć, co jest źródłem prawdy, a co tylko materiałem pomocniczym dla modelu. Drugi: cały przebieg requestu siedzi w jednym promptcie i jednym handlerze. Trzeci: narzędzia nie mają typowanych kontraktów ani granic uprawnień. Czwarty: zespół opowiada o agentach, ale nie ma historii decyzji, limitu kroków ani warunków zatrzymania.

To są dokładnie te miejsca, w których później rodzą się najdroższe problemy produkcyjne. System raz odpowiada dobrze, raz źle, nikt nie wie dlaczego, koszty rosną, a bezpieczeństwo okazuje się zależeć od tego, czy model „zachowa się rozsądnie”. Innymi słowy: brakuje warstw, które w klasycznej architekturze uznalibyśmy za absolutne minimum higieny.

Dlatego bardzo praktyczny review architektury AI powinien obejmować pytania typu:

• gdzie kończy się probabilistyczna decyzja modelu,
• które akcje są wymuszane przez kod i walidację,
• jak wygląda degradacja przy słabym retrievalu albo timeoutach narzędzi,
• kto i na jakiej podstawie ocenia jakość po wdrożeniu.

Dobra architektura AI dojrzewa etapami, a nie przez jednorazowy wielki skok

W praktyce rzadko warto zaczynać od pełnej orkiestracji agentowej. Znacznie zdrowiej działa ścieżka dojrzewania. Najpierw prosty single-shot albo RAG z dobrym groundowaniem. Potem typed tools do kilku deterministycznych akcji. Następnie telemetry, evale i polityki bezpieczeństwa. Dopiero na końcu, jeśli use-case naprawdę tego wymaga, bardziej stanowy workflow albo agentowa pętla.

Ten porządek jest ważny, bo każda kolejna warstwa ma sens tylko wtedy, gdy poprzednia jest zrozumiała i mierzalna. Jeżeli podstawowy RAG nie jest stabilny, dodanie agenta nie rozwiąże problemu. Jeżeli nie umiesz obserwować kosztu i jakości, większa autonomia tylko podniesie cenę zamieszania. Jeżeli nie masz granic narzędzi, bardziej sprytny planner tylko szybciej dojdzie do złej akcji.

Właśnie dlatego dojrzałość architektury AI warto traktować jak sekwencję decyzji o odpowiedzialności, a nie konkurs na liczbę komponentów. Temat warstwy wiedzy w tym układzie rozwija też artykuł o RAG Architecture, hybrid retrieval i GraphRAG.

Najlepsza architektura AI bardzo rzadko jest tą najbardziej autonomiczną. Najczęściej jest tą, która najczytelniej rozdziela odpowiedzialności między model, kod, dane i człowieka.

Co z tym zrobić dalej, jeśli chcesz projektować systemy AI jak architekt, a nie jak fan nowego API

Najzdrowszy wniosek brzmi tak: AI System Architecture to sztuka rozdzielania tego, co powinno pozostać deterministyczne, od tego, co warto oddać modelowi jako probabilistycznemu komponentowi decyzji lub syntezy.

Nie zaczynaj od diagramu pełnego agentów. Zacznij od mapy odpowiedzialności:

1. co jest źródłem prawdy,
2. co jest stanem zadania,
3. co jest decyzją modelu,
4. co musi zostać zweryfikowane przez kod,
5. gdzie potrzebny jest człowiek.

Jeżeli odpowiesz na te pytania uczciwie, architektura zwykle sama robi się prostsza. A prostsza architektura AI prawie zawsze jest tańsza, bezpieczniejsza i łatwiejsza do utrzymania niż bardziej efektowna alternatywa.