Jak zbudować RAG do rozmów z gośćmi wydarzenia

Organizatorka konferencji stoi przy wejściu, gość podchodzi i mówi "cześć, pamiętasz mnie z zeszłego roku?". Ona nie pamięta. Ma w telefonie tabelkę Excel z 300 nazwiskami, ale szukanie w niej w locie to katastrofa. Właśnie tu wchodzi asystent AI, który potrafi to znaleźć w sekundę - jeśli dasz mu odpowiedni system dostępu do danych.

W tym poradniku pokażę Ci, jak zbudować taki system - w oparciu o konkretny przypadek: agenta AI (nazwanego w materiale źródłowym Alfred), który podczas gali ma pod ręką aktualne informacje o każdym gościu. Chodzi o technikę RAG (Retrieval-Augmented Generation) - i o to, dlaczego zwykły chatbot sobie z tym nie poradzi.

Czemu sam model językowy nie wystarczy

Standardowy LLM - niezależnie czy to duży model chmurowy, czy mniejszy open-source - ma jedną fundamentalną słabość w tym zadaniu: nie wie nic o Twojej konkretnej liście gości. To dane, których nigdy nie widział w treningu, bo są unikalne dla Twojego wydarzenia.

Do tego dochodzą trzy problemy, których sam model nie rozwiąże:

• Lista gości jest specyficzna dla Twojego eventu - nie ma jej w danych treningowych żadnego modelu, nawet najnowszego.
• Informacje zmieniają się często - gość dopisuje partnera, zmienia adres e-mail, aktualizuje dietę.
• Model musi podać precyzyjny szczegół, np. konkretny adres e-mail - a LLM bez dostępu do źródła danych ma tendencję do zgadywania (i zgaduje źle).

Tu RAG robi różnicę. Łączysz system wyszukiwania (retrieval) z modelem językowym - i model dostaje dokładnie te informacje, których potrzebuje, w momencie, gdy o nie prosisz. Jeśli chcesz zrozumieć mechanikę tego podejścia głębiej, mamy osobny przewodnik po RAG po polsku, który tłumaczy całą architekturę od podstaw.

Zanim zaczniesz - co musisz mieć przygotowane

Zanim usiądziesz do budowy, zbierz kilka rzeczy. Bez tego dalsze kroki będą frustrujące, a nie produktywne.

• Zestaw danych o gościach - najprościej arkusz lub prosty plik danych z kolumnami: imię i nazwisko, relacja z organizatorem, krótki opis/biografia, adres e-mail.
• Wybrany framework agentowy - w materiale źródłowym nie ma jednej wymuszonej opcji, możesz użyć któregokolwiek z frameworków, które już znasz z pracy z agentami AI.
• Dostęp do modelu językowego - lokalnego albo przez API, to on będzie generował odpowiedzi na podstawie znalezionych danych.
• Podstawowa struktura projektu - jeśli planujesz to wdrożyć naprawdę (nie tylko na własny użytek), warto od razu rozdzielić kod na osobne pliki, nie wrzucać wszystkiego do jednego skryptu.

Nie musisz być programistą-seniorem. Musisz umieć poskładać kilka klocków w logiczną kolejność - a to właśnie robimy poniżej.

Krok po kroku: budowa narzędzia do rozmów z gośćmi

Cały proces rozbija się na trzy sensowne etapy. Rozpisuję je tak, jak faktycznie wygląda praca nad takim projektem - od surowych danych do działającego agenta.

1. Załaduj i przygotuj dane o gościach. Bierzesz swój zestaw danych (imię, relacja, opis, e-mail) i zamieniasz każdy wpis na fragment tekstu, który system wyszukiwania będzie mógł przeszukać. To etap czysto porządkowy - jeśli dane są bałaganiarskie na wejściu, wyszukiwanie będzie kulawe na wyjściu.
2. Zbuduj narzędzie do wyszukiwania (retrieval). Tu tworzysz funkcję, która przyjmuje pytanie (np. "kto jest Janem Kowalskim i jaki ma e-mail") i zwraca najbardziej trafny fragment z Twojej bazy gości. To jest serce systemu RAG - część, która odpowiada za szukanie faktów, zanim model zacznie generować odpowiedź.
3. Zintegruj narzędzie z agentem. Ostatni krok to połączenie modelu językowego z Twoim narzędziem wyszukiwania - tak, żeby agent sam decydował, kiedy sięgnąć po bazę gości, a kiedy odpowiedzieć z własnej wiedzy. To jest moment, w którym pojedyncze klocki (dane, wyszukiwanie, model) zaczynają działać jako jeden użytkowy system.

W materiale źródłowym, na którym oparty jest ten poradnik, projekt jest rozbity na trzy pliki: jeden z narzędziami pomocniczymi dla agenta, jeden z funkcjami wyszukiwania wspierającymi dostęp do wiedzy, i jeden, który spaja wszystko w gotowego agenta. To dobra praktyka nawet w małych projektach - łatwiej debugować, łatwiej rozwijać.

Co konkretnie trzyma taka baza gości

W przykładowym zestawie danych każdy gość ma cztery pola: imię i nazwisko, relację z gospodarzem, krótki opis lub ciekawostkę oraz adres e-mail do kontaktu (np. do wysłania zaproszenia albo follow-upu). To minimalny, ale wystarczający zestaw, żeby agent mógł prowadzić sensowną rozmowę o konkretnej osobie.

W realnym zastosowaniu ten zestaw można rozszerzyć - dodać preferencje żywieniowe, zainteresowania (przydatne przy wyborze prezentu), tematy, których lepiej nie dotykać w rozmowie. Zasada jest prosta: im więcej sensownych pól w danych, tym więcej agent może Ci realnie podpowiedzieć, zamiast zgadywać.

Trzy sytuacje, w których to naprawdę działa

Zanim zapytasz, komu to się przyda poza galą Alfreda - kilka przykładów z życia, gdzie ten sam mechanizm ma sens:

• Recepcja konferencji branżowej - asystent AI, który w sekundę podaje firmę, stanowisko i temat wystąpienia danej osoby, zamiast organizatora gorączkowo przewijającego arkusz.
• Zarządzanie relacjami z klientami w małej firmie - agent, który przed telefonem do klienta przypomina historię kontaktu, ostatnie ustalenia i preferowany sposób komunikacji.
• Wewnętrzny asystent HR - bot, który odpowiada pracownikom na pytania o politykę urlopową firmy na podstawie aktualnego regulaminu, nie na podstawie tego, co model "pamięta" z treningu.

Wspólny mianownik: dane są specyficzne, zmienne w czasie i muszą być podane precyzyjnie. Dokładnie tam RAG bije zwykły chatbot na głowę.

Jeśli interesuje Cię, jak działa mechanizm wyszukiwania semantycznego pod maską (czyli jak model "rozumie", że pytanie o "Jana K." dotyczy tego samego wpisu co "Jan Kowalski"), zajrzyj do materiału o transformerach i tym, jak rozwiązują zadania - to fundament, na którym stoją embeddingi używane w RAG.

Gdzie ludzie najczęściej się wywalają

Największy błąd przy budowie takiego systemu to traktowanie retrievalu jako dodatku, a nie fundamentu. Jeśli Twoje wyszukiwanie zwraca nietrafione fragmenty, model dostanie śmieciowy kontekst i wygeneruje śmieciową odpowiedź - niezależnie od tego, jak dobry jest sam LLM. Zasada "garbage in, garbage out" tu obowiązuje bez wyjątków.

Drugi częsty problem: brak jasnego podziału odpowiedzialności między narzędziem wyszukiwania a agentem. Agent powinien wiedzieć kiedy sięgnąć po bazę gości, a kiedy nie - jeśli zapytasz go o pogodę, nie powinien przeszukiwać listy gości w poszukiwaniu odpowiedzi. To wymaga precyzyjnego opisania narzędzia, żeby model wiedział, do czego ono służy. Jeśli chcesz dopracować ten etap, przydatny będzie tekst o zaawansowanych technikach promptowania - dobre opisanie narzędzia to w praktyce dobry prompt.

Ten sam schemat budowy - dane, warstwa dostępu, integracja z agentem - powtarza się w wielu projektach agentowych, nie tylko w RAG do rozmów z gośćmi. Podobną logikę znajdziesz w poradniku o budowie własnego code review AI z Codex SDK, gdzie agent też korzysta z osobnego narzędzia do pobierania kontekstu przed wygenerowaniem odpowiedzi.

Najczęstsze pytania

Czy RAG to to samo co fine-tuning modelu?

Nie. Fine-tuning trenuje model na nowo na Twoich danych, co jest kosztowne i trzeba powtarzać przy każdej zmianie danych. RAG zostawia model w spokoju i po prostu dokłada mu aktualne informacje w momencie zadawania pytania - dlatego jest szybszy do wdrożenia i łatwiejszy do aktualizowania.

Jakiego frameworka użyć do zbudowania takiego agenta?

Materiał źródłowy nie wymusza jednego wyboru - możesz sięgnąć po framework agentowy, który już znasz i z którym czujesz się swobodnie. Kluczowe jest zachowanie tej samej logiki: dane, narzędzie wyszukiwania, integracja z agentem, niezależnie od konkretnego frameworka.

Czy muszę umieć programować, żeby zbudować własny RAG?

Podstawowa znajomość Pythona bardzo pomaga, bo cały projekt jest strukturą plików i funkcji. Możesz jednak zacząć od gotowych przykładów (np. Space'ów do klonowania) i modyfikować je krok po kroku, ucząc się na żywym kodzie, zamiast pisać wszystko od zera.

Czy ten sposób budowy RAG nadaje się tylko do organizacji wydarzeń?

Nie, to jest szkielet uniwersalny. Baza gości to tylko konkretny przykład danych - ten sam mechanizm (dane, wyszukiwanie, agent) możesz zastosować do bazy klientów, dokumentacji firmowej czy regulaminów wewnętrznych.

Cały ten poradnik sprowadza się do jednej myśli: agent AI bez dostępu do Twoich aktualnych danych to tylko elokwentny zgadywacz. RAG zamienia go w kogoś, kto naprawdę wie, o czym mówi - bo sprawdza fakty, zamiast je wymyślać.

Jeden krok na start: otwórz swój obecny arkusz z danymi (klientów, gości, pracowników - cokolwiek masz) i zamień jedną kolumnę na format, który da się łatwo przeszukać fragmentami tekstu. To pierwszy, najbardziej praktyczny krok do własnego RAG - reszta to już składanie klocków.