Budowanie systemów AI: od RAG do agentów

Większość zespołów zaczyna od RAG, odkrywa jego ograniczenia, a potem dokłada fine-tuning. Obie techniki rozwiązują problem wyszukiwania i wnioskowania. Żadna z nich nie rozwiązuje orkiestracji: decydowania, kiedy działać, ile agentów uruchomić, kiedy się zatrzymać i co oznacza konsensus. Zbudowałem wieloagentowy system deliberacyjny (3500 linii Python, 86 hooków, 141 testów), który obsługuje wszystkie trzy aspekty.

TL;DR

RAG pobiera dokumenty w momencie zapytania. Fine-tuning modyfikuje wagi modelu danymi domenowymi. Obie techniki są narzędziami wyszukiwania i wnioskowania. Żadna nie obsługuje orkiestracji: koordynowania wielu agentów, walidacji konsensusu ani decydowania, czy zadanie wymaga jednego wywołania modelu, czy dwunastu. Natrafiłem na tę barierę, budując system jakości blogów, który wymagał równoległego lintowania, oceny głębokości, weryfikacji cytowań i ewaluacji LLM na 33 wpisach. Rozwiązaniem była warstwa orkiestracji agentów z deliberacją wyzwalaną przez poziom pewności, zarządzaniem budżetem spawnu i czterostopniową walidacją konsensusu. Ten wpis omawia decyzję RAG kontra fine-tuning, a następnie wchodzi tam, gdzie większość przewodników się kończy: co się dzieje, gdy potrzebne są agenty.

Część 1: RAG kontra fine-tuning

Badanie Databricks z 2024 roku wykazało, że 78% zespołów AI w przedsiębiorstwach wybrało najpierw RAG, ale 34% z nich później odkryło, że fine-tuning byłby lepszym podejściem, tracąc średnio 3,2 miesiąca na implementację.¹

Decyzja nie polega na wyborze jednego lub drugiego. Chodzi o dopasowanie techniki do problemu.

Kiedy RAG wygrywa

Często zmieniająca się wiedza. RAG pobiera aktualne dokumenty w momencie zapytania. Gdy baza wiedzy jest aktualizowana codziennie (dokumentacja produktowa, artykuły wsparcia, zgłoszenia regulacyjne), RAG dostarcza bieżące informacje bez konieczności ponownego trenowania.²

Wymagania dotyczące atrybucji źródeł. RAG cytuje konkretne dokumenty, ponieważ proces wyszukiwania generuje jawną listę źródeł. W branżach regulowanych (ochrona zdrowia, finanse, prawo) atrybucja źródeł jest często wymogiem zgodności.³

Duże bazy wiedzy. System RAG operujący na 10 milionach dokumentów działa porównywalnie do systemu na 1 milionie, o ile jakość wyszukiwania jest spójna. Modele po fine-tuningu napotykają ograniczenia pojemności wyznaczone przez rozmiar modelu.⁴

Kiedy fine-tuning wygrywa

Wzorce wnioskowania specyficzne dla domeny. RAG dostarcza informacje. Fine-tuning dostarcza umiejętności. Model poddany fine-tuningowi na konwersacjach o diagnostyce medycznej uczy się wzorców diagnostyki różnicowej: jak ważyć objawy, kiedy brać pod uwagę rzadkie schorzenia, jak formułować pytania uzupełniające. RAG może dostarczyć wiedzę medyczną, ale wzorzec wnioskowania wymaga modyfikacji wag.⁵

Ścisłe wymagania dotyczące formatu wyjściowego. Fine-tuning wymusza ustrukturyzowany format wyjściowy (JSON, XML, konkretne schematy) bardziej niezawodnie niż inżynieria promptów. W systemach, gdzie błędy formatu powodują awarie dalszych procesów, fine-tuning zapewnia wyższą niezawodność.⁶

Aplikacje krytyczne pod względem opóźnień. RAG dodaje opóźnienie wyszukiwania: osadzenie zapytania, przeszukanie bazy wektorowej, pobranie dokumentów, wstrzyknięcie ich do promptu. W aplikacjach wymagających czasu odpowiedzi poniżej 200 ms eliminacja wyszukiwania przez fine-tuning może być konieczna.⁷

Macierz porównawcza

Podejście łączone

Większość systemów produkcyjnych łączy obie techniki. Fine-tuning modelu na wzorcach wnioskowania domenowego i formatach wyjściowych. RAG do dostarczania aktualnej, możliwej do przypisania wiedzy w momencie zapytania. Model po fine-tuningu wie, jak wnioskować o domenie. System RAG dostarcza informacje o tym, o czym wnioskować.⁸ To kontekst złożony na poziomie systemu: każde wyszukiwanie wzbogaca warstwę wnioskowania, a warstwa wnioskowania usprawnia kolejne wyszukiwania.

Część 2: Kiedy potrzebne są agenty

RAG i fine-tuning obsługują wyszukiwanie i wnioskowanie. Żadna z tych technik nie obsługuje orkiestracji: decydowania, czy zadanie wymaga jednego wywołania modelu, czy dwunastu, kiedy uruchomić równoległych pracowników, jak zwalidować ich wyniki i kiedy eskalować do człowieka. Fundamentalną ideę — to, że kontekst jest architekturą — rozwijam w osobnym wpisie, a tekst o wzorcach AGENTS.md pokazuje, jak zapisać reguły orkiestracji w konfiguracji agentów.

Natrafiłem na tę barierę, budując infrastrukturę jakości mojego bloga. Miałem 33 wpisy do ewaluacji, naprawy i weryfikacji. Jedno wywołanie modelu na wpis nie wystarczało. Każdy wpis wymagał lintowania (12 modułów), oceny głębokości (5 sygnałów), analizy czytelności, weryfikacji cytowań i ewaluacji LLM. Sekwencyjne uruchamianie trwało zbyt długo. Równoległe uruchamianie bez koordynacji generowało konflikty i niespójne wyniki.

Rozwiązaniem nie było więcej RAG ani lepszy fine-tuning. Była nim warstwa orkiestracji agentów.

Czego wymaga orkiestracja agentów

Tradycyjny potok ML zakłada liniowy przepływ: dane, przetwarzanie wstępne, model, ewaluacja, wdrożenie.⁹ Systemy agentowe są nieliniowe. Agent może:

1. Ocenić własny poziom pewności i zdecydować, że potrzebuje pomocy
2. Uruchomić 5 równoległych podagentów o różnych specjalizacjach
3. Zebrać i uszeregować ich wyniki
4. Wykryć, gdy agenty zbyt szybko dochodzą do zgodności (myślenie grupowe)
5. Zwalidować konsensus względem progów jakości
6. Wygenerować ostateczną rekomendację

Każdy z tych kroków wymaga infrastruktury, której RAG i fine-tuning nie zapewniają.

Część 3: Co zbudowałem

Architektura

Mój system deliberacyjny obejmuje 3500 linii Python w 12 modułach:

Deliberation System
├── confidence.py       Triggers deliberation based on ambiguity/complexity/stakes
├── state_machine.py    Workflow: idle → research → ranking → consensus
├── agents.py           5+ persona templates (Architect, Security, Performance...)
├── context_isolation.py  RLM L0-L3 layers prevent context contamination
├── ranking.py          Stack ranking with weighted consensus calculation
├── spawner.py          Parallel agent spawning via Task API
├── conformity.py       Detects groupthink and premature convergence
├── mailbox.py          Multi-round debate protocol
├── memory.py           Cross-session learning and persona tracking
├── scaling.py          Dynamic agent count based on complexity
├── prd_generator.py    Converts decisions into product requirements
└── observability.py    Session metrics and audit replay

System działa na bazie 86 hooków, które przechwytują operacje w sześciu punktach cyklu życia (PreToolUse, PostToolUse, Stop i trzech innych). Każde uruchomienie agenta, każdy zapis pliku, każde polecenie git przechodzi przez walidację.

Wyzwalacz pewności

Nie każde zadanie wymaga debaty pięciu agentów. Zbudowałem algorytm oceny pewności, który analizuje cztery wymiary (ten sam wzorzec ważonej kompozycji, którego używam przy selekcji wiedzy):

1. Niejednoznaczność — czy zapytanie ma wiele poprawnych interpretacji? (Wzorce dopasowań: „best way”, „should I”, „compare vs”, „pros and cons”)
2. Złożoność domenowa — czy wymaga specjalistycznej wiedzy? (Wzorce dopasowań: „architecture”, „security”, „performance”, „database schema”)
3. Stawka — czy decyzja jest odwracalna? (Wzorce dopasowań: „production”, „breaking change”, „delete”, „security vulnerability”)
4. Zależność od kontekstu — czy wymaga zrozumienia szerszego systemu?

Wynik mapuje się na trzy poziomy:

• WYSOKI (0,85+): Kontynuacja bez deliberacji
• ŚREDNI (0,70–0,84): Kontynuacja z zalogowaną notatką o pewności
• NISKI (poniżej 0,70): Uruchomienie pełnej wieloagentowej deliberacji

Próg dostosowuje się do typu zadania. Decyzje dotyczące bezpieczeństwa wymagają 85% konsensusu. Zmiany w dokumentacji potrzebują tylko 50%. Zapobiega to nadmiernej inżynierii prostych zadań, zapewniając jednocześnie właściwą kontrolę ryzykownych decyzji.

Problem budżetu spawnu

Moja pierwsza implementacja używała limitów rekurencji opartych na głębokości: agent na głębokości 0 uruchamia głębokość 1, która uruchamia głębokość 2, blokada na głębokości 3. To od razu zawiodło. Agenty deliberacyjne muszą działać równolegle, nie szeregowo. Pięć agentów na głębokości 1 to nie głęboka rekurencja. To szeroka współpraca.

Rozwiązanie: model budżetu spawnu. Agent główny otrzymuje budżet (maksymalnie 12 agentów). Wydaje ten budżet, uruchamiając równoległych pracowników. Pracownicy dziedziczą pozostały budżet, ale nie mogą go przekroczyć. Zapobiega to niekontrolowanym łańcuchom, umożliwiając jednocześnie równoległe wykonanie wymagane przez deliberację.

Prawdziwy test przyszedł, gdy uruchomiłem 10 agentów recenzujących na przetłumaczonych wpisach blogowych. Zabezpieczenie rekurencji zablokowało agentów od 4 do 10, ponieważ liczyło uruchomienia jako przyrosty głębokości. Po przejściu na model budżetowy wszystkie 10 uruchomiło się pomyślnie. Głębokość nigdy nie przekroczyła 1. Szerokość rozszerzyła się, aby dopasować do zadania.¹⁰

Walidacja konsensusu

Po zakończeniu pracy agentów hook post-deliberacyjny uruchamia cztery kontrole:

1. Gotowość fazy — czy deliberacja przeszła z etapu badawczego do rankingowego?
2. Kworum agentów — czy co najmniej 2 agenty zakończyły pracę? (Konfigurowalne dla typu zadania)
3. Próg konsensusu — czy poziom zgodności spełnia wymagane minimum? (70% bazowo, 85% dla bezpieczeństwa)
4. Dokumentacja sprzeciwu — jeśli agenty się nie zgadzają, czy zastrzeżenia zostały zapisane?

Kontrola 4 była spostrzeżeniem, którego się nie spodziewałem. Wczesne uruchomienia generowały „konsensus”, w którym agenty po prostu zgadzały się z pierwszą odpowiedzią. Detektor konformizmu oznacza teraz przedwczesną zbieżność: jeśli wszystkie agenty zgadzają się w pierwszej rundzie z wysokimi wynikami podobieństwa, system wymusza drugą rundę analizy adwersarialnej.

Czego nauczyłem się na własnej skórze

Atomowe zapisy plików mają znaczenie. Wiele agentów piszących jednocześnie do tego samego pliku stanu powodowało uszkodzenie JSON. Rozwiązanie: zapis do plików .tmp, a następnie atomowe przeniesienie przez mv. System operacyjny gwarantuje, że mv jest atomowe na tym samym systemie plików. Ta jednolinijkowa zmiana wyeliminowała całą kategorię warunków wyścigu.

Izolacja kontekstu zapobiega myśleniu grupowemu. Każdy agent otrzymuje niezależny kontekst przez cztery warstwy (L0: wiedza bazowa, L1: specyficzna dla zadania, L2: specyficzna dla persony, L3: specyficzna dla rundy). Bez izolacji agenty zbiegają do pierwszej prawdopodobnej odpowiedzi zamiast eksplorować przestrzeń rozwiązań. Z izolacją agent bezpieczeństwa i agent wydajności dochodzą do rzeczywiście różnych wniosków, ponieważ startują z różnych założeń.

Testowanie infrastruktury agentowej jest trudniejsze niż testowanie kodu aplikacji. System ma 141 testów: 48 bashowych testów integracyjnych dla zachowania hooków, 81 testów jednostkowych Python dla modułów bibliotecznych i 12 symulacji potoków end-to-end. Każda historia awarii w pamięci mojego projektu (blokowanie budżetu spawnu, fałszywie pozytywne wykrywanie cudzysłowów, pliki planów bloga przypadkowo serwowane jako wpisy) stała się przypadkiem testowym po naprawie. Błędy agentowe są trudniejsze do odtworzenia niż błędy aplikacyjne, ponieważ zależą od synchronizacji, kolejności i współbieżnego stanu.

Podział ról między człowiekiem a agentem

Wzorzec: ludzie odpowiadają za decyzje wymagające kontekstu organizacyjnego, oceny etycznej lub kierunku strategicznego. Agenty odpowiadają za decyzje wymagające przeszukiwania obliczeniowego dużych przestrzeni możliwości.¹¹ Głębiej analizuję ten podział w mojej analizie architektury agentowej.

Agentowy inżynier ML nie pisze ręcznie potoków. Agentowy inżynier ML definiuje cele, ograniczenia i kryteria ewaluacji. Agenty obsługują pętlę implementacyjną: zaproponuj, wykonaj, oceń, iteruj. Rola człowieka przesuwa się z budowniczego na architekta: wyznaczanie granic, przegląd wyników i podejmowanie decyzji wymagających kontekstu domenowego, którego agentom brakuje.¹²

Kluczowe wnioski

Dla inżynierów rozpoczynających pracę z systemami AI: - Zacznij od RAG w każdym przypadku użycia obejmującym często zmieniającą się wiedzę lub wymagania dotyczące atrybucji źródeł; RAG zapewnia funkcjonalną bazę w ciągu dni, podczas gdy fine-tuning wymaga tygodni przygotowania danych - Połącz RAG i fine-tuning, gdy aplikacja wymaga zarówno wnioskowania domenowego, JAK I aktualnej wiedzy - Jeśli potrzebujesz więcej niż jednego wywołania modelu na zadanie, potrzebujesz orkiestracji agentów — a to zupełnie inny problem inżynieryjny niż RAG czy fine-tuning (bezpośrednie porównanie podejść do orkiestracji znajdziesz w Claude Code kontra Codex)

Dla zespołów budujących systemy agentowe: - Zbuduj ocenę pewności przed budowaniem agentów; większość zadań nie wymaga deliberacji, a system, który wie, kiedy użyć agentów, jest cenniejszy niż same agenty - Używaj budżetów spawnu, a nie limitów głębokości, w równoległych architekturach agentowych; limity głębokości blokują wzorce szerokiej współpracy, których deliberacja agentowa wymaga - Testuj jakość konsensusu, a nie samo jego istnienie; przedwczesna zgoda jest gorsza niż brak zgody, ponieważ tworzy fałszywą pewność

Często zadawane pytania

Czym jest generowanie wspomagane wyszukiwaniem (RAG)?

RAG to technika, która w momencie zapytania pobiera odpowiednie dokumenty z bazy wiedzy i wstrzykuje je do kontekstu LLM obok pytania użytkownika. Dzięki temu odpowiedź modelu opiera się na konkretnych, aktualnych informacjach, a nie wyłącznie na danych treningowych. RAG sprawdza się najlepiej wtedy, gdy wiedza często się zmienia, gdy wymagane jest wskazanie źródeł lub gdy baza wiedzy jest bardzo duża. Badanie Databricks z 2024 roku wykazało, że 78% firmowych zespołów AI wybierało RAG jako pierwsze rozwiązanie w swojej początkowej architekturze AI.

Czym agenty AI różnią się od systemów RAG?

RAG odpowiada za wyszukiwanie i ugruntowanie — dostarcza modelowi właściwych informacji do wnioskowania. Agenty odpowiadają za orkiestrację: decydują, kiedy działać, ile wywołań modelu wymaga zadanie, kiedy uruchomić równoległych pracowników i jak zwalidować wyniki. System RAG odpowiada na pytania. System agentowy koordynuje wiele wywołań modelu, zarządza walidacją konsensusu i rozstrzyga, czy zadanie wymaga jednego wnioskowania, czy dwunastu. Oba podejścia się uzupełniają: agenty często wykorzystują RAG jako jedno z wielu narzędzi.

Kiedy stosować RAG, a kiedy fine-tuning w aplikacji AI?

RAG warto wybrać, gdy wiedza zmienia się często (codzienne aktualizacje), gdy potrzebne jest wskazanie źródeł (branże regulowane) lub gdy baza wiedzy jest bardzo duża. Fine-tuning sprawdzi się tam, gdzie potrzebne są domenowe wzorce wnioskowania (diagnostyka medyczna, analiza prawna), ścisłe trzymanie się formatu wyjściowego albo opóźnienie poniżej 200 ms. Większość systemów produkcyjnych łączy oba podejścia: fine-tuning zapewnia wnioskowanie domenowe i format wyjściowy, a RAG dostarcza aktualną, możliwą do przypisania wiedzę w momencie zapytania. Szczegółowe zestawienie znajduje się w macierzy porównawczej powyżej.

Czym jest orkiestracja agentów i kiedy jest potrzebna?

Orkiestracja agentów to warstwa infrastruktury, która koordynuje wiele wywołań modelu AI w ramach jednego zadania: decyduje, kiedy uruchomić równoległych pracowników, jak zwalidować ich wyniki, kiedy uznać konsensus za osiągnięty i kiedy eskalować do człowieka. Orkiestracja jest potrzebna wtedy, gdy zadanie wymaga więcej niż jednego wywołania modelu: równoległych analiz z różnych perspektyw, deliberacji wyzwalanej poziomem pewności albo wieloetapowych potoków z bramkami jakości. Mój system deliberacyjny wykorzystuje budżety spawnu, wykrywanie konformizmu i czterostopniową walidację konsensusu, aby koordynować do 12 agentów na zadanie.

Jak zapobiegać niskiej jakości konsensusu wśród agentów AI?

Powierzchownej zgodzie zapobiegają trzy mechanizmy. Po pierwsze, izolacja kontekstu daje każdemu agentowi niezależny kontekst (wiedza bazowa, warstwa zadania, warstwa persony, warstwa rundy), dzięki czemu agenty dochodzą do rzeczywiście różnych wniosków. Po drugie, detektor konformizmu oznacza przedwczesną zbieżność: jeśli wszystkie agenty zgadzają się w pierwszej rundzie z wysokimi wynikami podobieństwa, system wymusza analizę adwersarialną. Po trzecie, progi konsensusu dostosowują się do typu zadania: decyzje dotyczące bezpieczeństwa wymagają 85% zgodności, a zmiany w dokumentacji tylko 50%. Architektura Ralph Loop egzekwuje te ograniczenia przez hooki uruchamiane w każdym punkcie cyklu życia.

Przypisy