LLM-y w architekturze aplikacji. Czas na nowy model budowania systemów?

Do niedawna aplikacje oparte na dużych modelach językowych (LLM) były traktowane jako ciekawostka – demonstracja możliwości AI lub nowy interfejs konwersacyjny. Dziś coraz częściej stają się podstawą całych systemów biznesowych. To przesunięcie niesie ze sobą konkretne konsekwencje: zmienia nie tylko sposób, w jaki projektujemy oprogramowanie, ale także to, kto je projektuje i jakie kompetencje są potrzebne, by robić to dobrze.

Architekci IT stają więc przed pytaniem: czy tradycyjny model budowania aplikacji jeszcze wystarcza?

Od kodu do promptów – zmiana paradygmatu

W klasycznej architekturze aplikacji logika działania systemu opierała się na przewidywalnym kodzie. Dane wejściowe były przetwarzane według jasno zdefiniowanych reguł, a wynik był w większości deterministyczny. W podejściu z LLM na pokładzie, ta logika zostaje częściowo przeniesiona do modelu – który nie działa według kodu, ale według promptu.

Prompt to nie tylko polecenie. To nowa forma interfejsu logicznego, zawierająca instrukcje, ograniczenia, dane kontekstowe i oczekiwaną formę odpowiedzi. W efekcie część tego, co kiedyś było pisane jako kod, dziś jest „projektowane” jako prompt. Zamiast precyzyjnych instrukcji warunkowych, projektanci muszą teraz myśleć w kategoriach intencji, przykładów i oczekiwanego zachowania.

Aplikacja z AI w środku – jak wygląda nowa architektura?

W praktyce oznacza to nowy model budowania aplikacji, w których LLM działa jako jedna z głównych warstw logiki. Typowa architektura aplikacji AI-centrycznej może obejmować:

• Warstwę orchestratora, która zarządza przepływem danych między użytkownikiem a modelem.
• Prompt managera, odpowiedzialnego za generowanie, wersjonowanie i zarządzanie promptami.
• Model handlera, który obsługuje wywołania LLM (lokalnie lub przez API).
• Evaluatora, który analizuje jakość odpowiedzi i decyduje, czy wymagana jest interwencja lub retry.

Do tego dochodzą takie komponenty jak cache odpowiedzi, analiza kosztów tokenów, klasyfikacja zapytań czy detekcja błędów semantycznych. W efekcie architektura aplikacji zaczyna przypominać system oparty na pipeline uczenia maszynowego, a nie klasyczny monolit czy mikroserwis.

Nowe wyzwania dla zespołów IT

Największą zmianą jest jednak to, że LLM-y wprowadzają do aplikacji element… nieprzewidywalności. Modele są probabilistyczne – mogą podać różne odpowiedzi dla tych samych danych wejściowych, w zależności od parametrów jak temperatura, kontekst czy struktura promptu.

To z kolei oznacza:

• Nowy sposób testowania: klasyczne testy jednostkowe przestają wystarczać. Potrzebne są testy porównawcze, oceny jakości odpowiedzi i benchmarki semantyczne.
• Nowe podejście do błędów: trzeba projektować aplikacje tak, by radziły sobie z odpowiedzią niedokładną, niepełną lub nieistotną.
• Potrzeba „ewaluacji jakości”: pojawia się rola inżyniera ewaluacji, który ocenia, czy model działa zgodnie z oczekiwaniami biznesowymi.

Od LLM jako dodatku do LLM jako rdzenia systemu

Jedną z najważniejszych decyzji architektonicznych staje się odpowiedź na pytanie: gdzie umiejscowić model? Do wyboru są trzy podstawowe scenariusze:

• Model w chmurze (API) – prostsze wdrożenie, ale mniejsza kontrola, wyższe koszty i ograniczenia danych.
• Model lokalny (on-premise) – większa elastyczność i kontrola, ale potrzeba mocy obliczeniowej i zespołu do obsługi.
• Model jako mikroserwis wewnętrzny – kompromisowe podejście z wykorzystaniem wewnętrznych API i lokalnej infrastruktury.

Wybór zależy od wielu czynników: od wymagań regulacyjnych, przez koszt tokenów, po potrzeby w zakresie bezpieczeństwa i poufności.

Nowe wzorce projektowe: RAG i agentowy design

Z architektonicznego punktu widzenia szczególnie istotne stają się dwa podejścia:

1. RAG (Retrieval-Augmented Generation) – łączy LLM z zewnętrzną bazą wiedzy (np. bazą dokumentów lub wektorową wyszukiwarką), aby dostarczyć bardziej aktualne i precyzyjne odpowiedzi. Stosowane m.in. w chatbotach obsługi klienta.
2. Agentic AI – model nie tylko odpowiada, ale wykonuje zadania: może zaplanować sekwencję działań, wykonać API call, zaktualizować dane. To podejście przypomina budowanie cyfrowych agentów zdolnych do samodzielnej aktywności.

Czy to się opłaca? Kiedy nie używać LLM

Warto przy tym zadać pytanie: czy każda aplikacja powinna być oparta na LLM? Odpowiedź brzmi: nie. Istnieje wiele przypadków, w których klasyczne podejście jest:

• Tańsze,
• bardziej niezawodne,
• prostsze w utrzymaniu.

Jeśli system wymaga deterministycznych wyników, działania w czasie rzeczywistym lub ścisłej kontroli logiki biznesowej – lepiej pozostać przy tradycyjnej architekturze. LLM-y sprawdzają się najlepiej w zadaniach wymagających rozumienia języka naturalnego, elastyczności i adaptacji – niekoniecznie w księgowości czy przetwarzaniu płatności.

Zespół AI: nowe role i nowe procesy

Wraz z wejściem LLM-ów do architektury zmienia się także struktura zespołów IT. Pojawiają się nowe role:

• Prompt Engineer – projektuje i testuje skuteczne prompty.
• AI Product Owner – zarządza funkcjonalnością opartą na AI i jej wpływem na użytkownika.
• Eval Engineer – ocenia jakość odpowiedzi modelu w sposób ciągły.

To również oznacza inne podejście do iteracji – wersjonowanie promptów, testowanie ich skuteczności i zarządzanie nimi jako artefaktami produktowymi.

AI jako nowa warstwa logiki aplikacji

Wdrażanie dużych modeli językowych do aplikacji to coś więcej niż zmiana technologii – to zmiana sposobu myślenia o logice systemu, interfejsie i architekturze. LLM przestaje być narzędziem, a staje się nową warstwą systemu – równą bazie danych czy silnikowi reguł biznesowych.

Architekci IT muszą dziś nie tylko znać ograniczenia i możliwości LLM, ale też zrozumieć, jak zbudować wokół nich system odporny, bezpieczny i efektywny kosztowo. Nowa era oprogramowania to nie tylko AI-first – to również rethink-architecture-first.