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ć.⁸

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.

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:

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

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ść

Przypisy