RAG, chatbot czy agent AI — czego naprawdę potrzebuje Twoja firma?

Chatbot, RAG, pipeline LLM i agent AI nie są czterema wersjami tego samego rozwiązania. Mogą korzystać z podobnych modeli, ale wykonują zupełnie różne zadania.

Najpierw trzeba ustalić, czy system ma odpowiadać, wyszukiwać, przetwarzać czy działać. Dopiero później warto wybierać model, bazę wektorową i pozostałe elementy technologii.

Zwykle zaczyna się od chatbota

Coraz więcej rozmów o wdrożeniu AI zaczyna się podobnie:

— Chcemy mieć chatbota.

Czasami firma rzeczywiście potrzebuje chatbota. Po kilku pytaniach często okazuje się jednak, że system ma czytać dokumenty, sprawdzać aktualne dane w ERP, analizować informacje z kilku źródeł, pamiętać wcześniejsze decyzje albo wykonywać kolejne kroki.

A wtedy nie rozmawiamy już o prostym chatbocie.

Problem polega na tym, że chatbot, RAG, pipeline LLM i agent AI są dzisiaj wrzucane do jednego worka. Wszystkie mogą korzystać z modelu językowego. Wszystkie mogą mieć interfejs przypominający rozmowę. Z perspektywy użytkownika mogą nawet wyglądać podobnie.

Różnica zaczyna się głębiej.

W danych, z których korzystają. W procesie, który wykonują. W narzędziach, do których mają dostęp. I przede wszystkim w tym, jakiej odpowiedzialności od nich oczekujemy.

Dlatego zamiast zaczynać od pytania „jaki model wybrać?", lepiej najpierw odpowiedzieć na prostsze:

Czy system ma odpowiadać, wyszukiwać, przetwarzać czy działać?

Prosty chatbot obsługuje konkretny scenariusz

Najprostszy bot nie musi mieć dostępu do całej wiedzy firmy. Nie musi też rozumieć każdego pytania, jakie użytkownik jest w stanie wymyślić.

Ma wykonać określoną pracę.

Może odpowiedzieć na kilka najczęstszych pytań, pomóc wybrać usługę, zebrać dane kontaktowe, przeprowadzić użytkownika przez formularz albo przekazać rozmowę człowiekowi.

To nadal może być dobre rozwiązanie.

Nie każdy proces potrzebuje rozbudowanej architektury AI. Jeżeli zakres pytań jest ograniczony, odpowiedzi zmieniają się rzadko, a popełnienie błędu nie niesie dużych konsekwencji, prosty bot często będzie szybszy, tańszy i łatwiejszy do utrzymania.

Kłopot zaczyna się wtedy, gdy oczekujemy od niego odpowiedzi na podstawie setek dokumentów, zmieniającej się oferty albo aktualnych danych z systemów wewnętrznych.

W takim przypadku nie wystarczy już dobrze napisany prompt.

RAG daje modelowi dostęp do wiedzy firmy

RAG, czyli Retrieval-Augmented Generation, jest często opisywany jako połączenie modelu językowego z bazą dokumentów.

To prawda, ale tylko częściowo.

Najważniejsze jest to, że model nie musi odpowiadać wyłącznie na podstawie wiedzy, którą zdobył podczas treningu. Zanim przygotuje odpowiedź, system wyszukuje informacje w źródłach należących do firmy i przekazuje je jako kontekst.

Takim źródłem mogą być dokumenty, ale również baza SQL, katalog produktów, CRM, ERP, wewnętrzne API albo kilka różnych systemów naraz.

Warstwa wyszukiwania i pobierania kontekstu, czyli retrieval, może działać semantycznie - na przykład przez bazę wektorową - albo deterministycznie, gdy system wykonuje zapytanie SQL lub pobiera konkretną wartość przez API.

W większych i bardziej zróżnicowanych bazach wiedzy często stosuje się również wyszukiwanie hybrydowe. Łączy ono podobieństwo semantyczne z klasycznym wyszukiwaniem dokładnych słów, nazw własnych, kodów produktów lub innych oznaczeń.

W praktyce proces wygląda mniej więcej tak:

1. użytkownik zadaje pytanie,
2. system ustala, gdzie szukać odpowiedzi,
3. pobiera właściwe informacje,
4. przekazuje je do modelu,
5. model generuje odpowiedź opartą na znalezionych danych,
6. system może dołączyć źródła lub fragmenty potwierdzające odpowiedź.

Taki asystent może odpowiadać na pytania o dokumentację techniczną, procedury, ofertę, produkty, regulaminy czy wewnętrzną wiedzę firmy.

W dobrym systemie nie chodzi jednak tylko o znalezienie tekstu podobnego znaczeniowo do pytania.

Aktualny stan magazynowy lepiej pobrać bezpośrednio z ERP. Cenę z systemu, który jest jej źródłem prawdy. Dokumentację można przeszukać semantycznie, a relacje pomiędzy obiektami czasami wymagają grafu lub zapytania strukturalnego.

RAG nie oznacza więc automatycznie „PDF-y plus baza wektorowa".

To sposób dostarczania modelowi właściwego kontekstu. Sama metoda retrieval zależy od danych i pytania.

Dobrym przykładem jest system BLUP-FLOCK, w którym klasyczne wyszukiwanie dokumentów nie wystarczało. System musiał pracować na danych genealogicznych i relacjach pomiędzy kolejnymi pokoleniami zwierząt, dlatego potrzebny był własny mechanizm pobierania kontekstu oraz deterministyczna warstwa obliczeniowa.

Więcej o tej architekturze opisaliśmy w artykule o produkcyjnych integracjach AI, RAG i pipeline'ach LLM.

Pipeline LLM nie musi z nikim rozmawiać

Nie wszystkie systemy oparte na modelach językowych mają interfejs czatowy.

Czasami użytkownik nie chce rozmawiać z AI. Chce, żeby system wykonał pracę i zwrócił gotowy wynik.

Pipeline LLM może pobrać dokument, rozpoznać jego typ, wyciągnąć potrzebne informacje, sprawdzić je według reguł, zapisać wynik w CRM i przekazać sprawę do kolejnego etapu procesu.

Może analizować zapytania ofertowe, klasyfikować wiadomości, porządkować dane produktowe, przygotowywać podsumowania albo przetwarzać treści przed publikacją.

Kolejne kroki są zwykle określone z góry.

Model wykonuje fragment pracy wymagający rozumienia języka, ale cały proces nie musi samodzielnie decydować, co robić dalej. Jeżeli dokument został poprawnie sklasyfikowany, trafia do kroku numer dwa. Jeżeli nie, system uruchamia walidację albo przekazuje sprawę człowiekowi.

To ważna różnica.

Pipeline może korzystać z LLM, ale nie musi być agentem.

Agent AI dostaje rolę, pamięć i narzędzia

Agent zaczyna się tam, gdzie system nie tylko przetwarza dane według jednej ścieżki, ale musi ocenić sytuację i wybrać kolejny krok.

W naszych agentach marketingowych samo wywołanie modelu jest najmniej interesującą częścią.

Agent musi wiedzieć, dla jakiej firmy pracuje. Znać jej cele, historię wcześniejszych decyzji i ograniczenia. Mieć dostęp do odpowiednich danych. Rozumieć, czego może dotknąć, a czego nie wolno mu zmieniać.

Przykładowy agent może pobrać dane z Google Ads i wykryć istotny wzrost kosztu. Sama zmiana wskaźnika nie oznacza jednak jeszcze, że wydarzyło się coś złego.

System może sprawdzić, czy zmienił się popyt, liczba konwersji, jakość ruchu albo działanie strony. Może odczytać wcześniejsze rekomendacje i zauważyć, że podobna sytuacja wystąpiła miesiąc wcześniej. Dopiero wtedy przygotowuje wniosek.

Nie tylko:

CPC wzrosło o 18%.

Raczej:

CPC wzrosło, ale liczba konwersji pozostała stabilna. W tym samym okresie zwiększył się udział ruchu z droższej kampanii produktowej. Nie rekomendujemy ograniczenia budżetu, dopóki nie zostanie sprawdzona rentowność tej grupy produktów.

To nadal nie oznacza, że agent powinien samodzielnie zmienić kampanię.

Może przygotować rekomendację, dołączyć dane, określić poziom confidence wynikający z jakości, kompletności i zgodności danych, a następnie przekazać decyzję człowiekowi.

Uprawnienia do wykonywania zmian można dodać później - tylko tam, gdzie ryzyko jest kontrolowane i istnieje ślad audytowy.

Model jest ważny. Ale agent powstaje dopiero wtedy, gdy wokół modelu pojawiają się:

• rola,
• kontekst,
• pamięć,
• narzędzia,
• zasady,
• uprawnienia,
• monitoring,
• historia decyzji.

Taką architekturę wykorzystujemy w systemie agentów analizujących dane Google Ads, GA4 i Search Console. Agent nie tylko generuje raport, lecz porównuje źródła, ocenia jakość danych, zapisuje wcześniejsze decyzje i tworzy rekomendacje wymagające zatwierdzenia człowieka.

Zobacz case study AI Agents for Google Ads & SEO Intelligence.

Kiedy agent AI ma sens biznesowy?

Sam fakt, że proces korzysta z kilku systemów albo modelu językowego, nie oznacza jeszcze, że trzeba budować agenta.

Agent może mieć sens, gdy przynajmniej kilka z poniższych warunków występuje jednocześnie:

• decyzja wymaga połączenia informacji z kilku źródeł,
• sytuacja nie jest jednoznaczna i nie da się jej zamknąć w jednej regule,
• eksperci regularnie wykonują podobne analizy, ale za każdym razem muszą uwzględnić inny kontekst,
• czas reakcji wpływa na sprzedaż, koszty albo jakość obsługi,
• proces kończy się rekomendacją lub działaniem, a nie tylko wygenerowaniem tekstu,
• firma potrafi określić, które decyzje agent może podejmować sam, a które wymagają zatwierdzenia,
• istnieje sposób sprawdzenia, czy rekomendacje agenta rzeczywiście przynoszą efekt.

Samo łączenie kilku źródeł nie uzasadnia jeszcze agenta. Czasami wystarczy pipeline, dashboard albo dobrze napisana automatyzacja.

Agent staje się uzasadniony wtedy, gdy największą wartością nie jest samo zebranie danych, lecz ich interpretacja i wybór kolejnego kroku.

Cztery różne role systemowe

Najłatwiej zobaczyć różnicę, zestawiając nie same technologie, lecz role, jakie mają pełnić w procesie.

Kryterium	FAQ bot / prosty chatbot	Asystent RAG	Pipeline LLM	Agent AI
Główne zadanie	Obsługa ograniczonego scenariusza	Odpowiedzi oparte na danych firmy	Automatyczne przetwarzanie danych	Analiza i wieloetapowe działanie
Dane	Instrukcja w prompcie, statyczne odpowiedzi lub proste reguły	Dokumenty, API, SQL i retrieval	Systemy źródłowe i pliki	API, pamięć, narzędzia i kontekst
Interfejs	Najczęściej czat	Czat, wyszukiwarka lub API	Zwykle proces w tle	Czat, panel, e-mail lub proces w tle
Wynik	Odpowiedź albo przekierowanie	Odpowiedź oparta na źródłach	Ustrukturyzowany rezultat	Insight, rekomendacja albo akcja
Zmienność procesu	Niska	Średnia	Niska lub średnia	Wysoka
Kontrola człowieka	Zwykle przy wyjątkach	Przy odpowiedziach wysokiego ryzyka	Przy błędach i wyjątkach	Przy działaniach o istotnym wpływie

W jednym systemie te role mogą się oczywiście łączyć.

Agent może korzystać z RAG. Pipeline może zawierać etap retrieval. Asystent RAG może wyglądać jak chatbot. Prosty bot może przekazać trudniejsze pytanie do bardziej zaawansowanego systemu.

Nie chodzi o wybór jednej etykiety.

Chodzi o właściwe rozdzielenie odpowiedzialności.

Czasami najlepszym rozwiązaniem nadal jest zwykła automatyzacja

Im więcej mówi się o agentach, tym łatwiej zacząć budować je wszędzie.

Nie ma to sensu.

Jeżeli proces można jednoznacznie opisać:

jeżeli wydarzy się A, wykonaj B,

najlepiej zwykle napisać zwykłą regułę.

Kod będzie tańszy, szybszy, łatwiejszy do przetestowania i bardziej przewidywalny od modelu językowego.

Agent przydaje się wtedy, gdy sytuacja nie jest jednoznaczna. Trzeba połączyć informacje z kilku miejsc, zinterpretować ich znaczenie, postawić hipotezę albo wybrać kolejny krok.

Najlepsze systemy, które dziś budujemy, łączą oba podejścia.

Dane są pobierane i walidowane deterministycznie. Progi, formaty i podstawowe obliczenia pozostają w kodzie. Model wchodzi dopiero tam, gdzie rzeczywiście potrzebna jest interpretacja.

Reszta pozostaje w deterministycznym kodzie, bo kod jest tańszy, szybszy i łatwiejszy do przetestowania.

Nie dlatego, że chcemy używać AI mniej.

Dlatego, że chcemy używać go tam, gdzie wnosi wartość.

Co wpływa na koszt?

Nie da się uczciwie powiedzieć, że chatbot zawsze będzie najtańszy, a agent najdroższy.

Prosty bot obsługujący kilka pytań może kosztować niewiele. Chatbot działający na drogim modelu, obsługujący tysiące długich rozmów dziennie, może być droższy niż agent uruchamiany raz w tygodniu.

Koszt zależy między innymi od:

• liczby wywołań modelu,
• długości kontekstu,
• wybranego modelu,
• liczby kroków procesu,
• liczby wywołań zewnętrznych narzędzi,
• częstotliwości synchronizacji danych,
• sposobu wyszukiwania oraz dodatkowego sortowania wyników, czyli rerankingu,
• wymaganej szybkości odpowiedzi,
• monitoringu i ewaluacji,
• udziału człowieka,
• wymagań dotyczących bezpieczeństwa i infrastruktury.

W przypadku RAG dochodzi koszt przygotowania, indeksowania i aktualizacji danych. W pipeline'ach znaczenie ma wolumen przetwarzanych dokumentów. W agentach - liczba kroków, wykorzystywanych źródeł i częstotliwość uruchamiania.

Osobną kategorią jest koszt wejścia.

Obejmuje przygotowanie danych, integrację z istniejącymi systemami, konfigurację uprawnień, budowę zestawu testów, zaprojektowanie ograniczeń, obsługę sytuacji wyjątkowych i wdrożenie monitoringu.

W pierwszej fazie projektu koszt wejścia może być znacznie większy niż późniejszy koszt samych wywołań modelu.

Sam koszt tokenów często nie jest największą pozycją.

Więcej kosztuje przygotowanie danych, integracja z istniejącymi systemami, obsługa wyjątków i doprowadzenie rozwiązania do momentu, w którym można mu zaufać w produkcji.

Największe ryzyko pojawia się przed wyborem technologii

Łatwo uznać, że największym błędem będzie wybranie RAG zamiast agenta albo pipeline'u zamiast chatbota.

Częściej problem zaczyna się wcześniej.

Firma nie wie dokładnie, jaki proces chce poprawić. Nie ma jednoznacznego źródła danych. Dokumenty są nieaktualne. Dwa systemy pokazują inne wartości. Nikt nie ustalił, kto odpowiada za wynik ani co system powinien zrobić, gdy nie ma wystarczających informacji.

Problemy z jakością, dostępnością i zarządzaniem danymi należą do najczęstszych przyczyn zatrzymania projektów AI.

Nie są jednak jedynymi.

Równie istotne bywają:

• brak jasno opisanej wartości biznesowej,
• koszt utrzymania rozwiązania,
• niedoszacowanie integracji,
• brak monitoringu,
• brak procedury dla błędnych odpowiedzi,
• zbyt szeroki zakres pierwszej wersji,
• brak człowieka odpowiedzialnego za działanie systemu.

Można zbudować technicznie poprawnego chatbota, RAG albo agenta, który nie będzie nikomu potrzebny.

Dlatego projekt powinien zaczynać się nie od prezentacji modelu, ale od rozmowy o procesie.

Jak więc wybrać?

Jeżeli użytkownik ma przejść przez prosty, ograniczony scenariusz - prawdopodobnie wystarczy FAQ bot albo klasyczna automatyzacja.

Jeżeli ma zadawać pytania dotyczące firmowych dokumentów i danych - potrzebny może być asystent RAG.

Jeżeli system ma regularnie przetwarzać dokumenty lub rekordy według określonego procesu - warto rozważyć pipeline LLM.

Jeżeli ma obserwować sytuację, korzystać z kilku narzędzi, pamiętać wcześniejsze decyzje i wybierać kolejne kroki - wtedy zaczynamy mówić o agencie AI.

W bardziej złożonych projektach odpowiedź często brzmi:

potrzebujemy kilku tych elementów naraz.

Asystent może korzystać z RAG. Pipeline może przygotowywać dane dla agenta. Agent może uruchamiać deterministyczną automatyzację. Człowiek może zatwierdzać działania o większym wpływie.

Technologia powinna wynikać z procesu, a nie odwrotnie.

Model jest dopiero początkiem

Jeszcze niedawno większość rozmów o systemach AI zaczynała się od wyboru modelu.

GPT, Claude, Gemini, DeepSeek. Który jest lepszy? Który tańszy? Który ma większy kontekst?

To nadal ważne pytania, ale coraz mniej najważniejsze.

Model można wymienić. Znacznie trudniej wymienić źle zaprojektowane dane, brak integracji, niejasne uprawnienia albo proces, którego nikt wcześniej nie zrozumiał.

Dlatego w projektach AI zaczynamy od przypadku użycia, źródeł danych, ryzyk i miejsc, w których system ma realnie odciążyć człowieka.

Dopiero później wybieramy, czy potrzebny jest chatbot, RAG, pipeline LLM, agent - czy połączenie kilku warstw.

Bo firma zwykle nie potrzebuje „wdrożenia AI".

Potrzebuje rozwiązania konkretnego problemu. AI jest jedną z możliwych części tego rozwiązania.

Planujesz wdrożenie AI?

Projektujemy produkcyjne systemy AI połączone z realnymi danymi i procesami firmy - od asystentów RAG i pipeline'ów LLM po wyspecjalizowanych agentów korzystających z API, pamięci i narzędzi.

Każdy projekt zaczynamy od analizy przypadku użycia, danych i architektury. Nie od wyboru modelu.

Zobacz, jak budujemy systemy AI i integracje LLM.