Wybór bazy danych wektorowych do RAG: porównanie ośmiu opcji

Wybór bazy danych wektorowej do RAG sprowadza się do kilku kluczowych pytań dotyczących rozmiaru, filtrowania, modelu zarządzania oraz możliwości przetwarzania operacji przez zespół. Oto krótka wersja przed szczegółami. Chroma i pgvector nadają się do małych projektów. Qdrant i Milvus to najczęściej wybierane rozwiązania do samodzielnego hostowania w środowisku produkcyjnym. Pinecone to opcja w pełni zarządzana. Jeśli w Twoim zestawie narzędzi już znajduje się Postgres, pgvector nie kosztuje nic dodatkowego, a jeśli chcesz szybko uruchomić lokalne rozwiązanie w ciągu kilku minut, Chroma można zainstalować za pomocą jednego polecenia pip.

Silniki o otwartym kodzie źródłowym, takie jak Qdrant, Milvus i Weaviate, radzą sobie z płatnymi platformami pod względem dokładności wyników i opóźnień, a każdy z nich oferuje darmową opcję samodzielnego hostowania obok opcji płatnej w chmurze. Jeszcze jedna liczba, którą warto zapamiętać: połączenie intensywnego wyszukiwania wektorowego z rzadkim wyszukiwaniem słów kluczowych BM25 podniosło wskaźnik Recall@10 z około 78% do około 91% w testach produkcyjnych, dlatego hybrydowe metody wyszukiwania pojawiają się w tak wielu z poniższych opcji.

Bazy danych wektorowych stanowią warstwę wyszukiwania w większości aplikacji opartych na sztucznej inteligencji generatywnej. Pozwalają one firmom oprzeć model językowy na własnych danych, dzięki czemu odpowiedzi są dokładne i dostosowane do konkretnego obszaru. W miarę wzrostu ilości danych niestrukturyzowanych, wyszukiwanie staje się głównym ograniczeniem jakości, a dobre wybór wymaga zrozumienia algorytmów indeksowania, zachowań filtrowania oraz kosztów infrastruktury.

Co tak naprawdę robi baza danych wektorowych

Baza danych wektorowych przechowuje wysokowymiarowe embeddingi i sortuje przechowywane wiersze według tego, jak blisko znajdują się one od wektora zapytania, wykorzystując podobieństwo kosinowe, iloczyn skalarny lub odległość L2. Silnik relacyjny dopasowuje dokładne tokeny, natomiast algorytm BM25 ocenia stopień pokrycia terminów. Wyszukiwanie wektorowe może zwrócić dokumenty o „samochodach dostępnych cenowo” dla zapytania „tani samochód”, ponieważ obie frazy znajdują się blisko siebie w przestrzeni embeddingów.

Istnieje jednak haczyk. Dokładne wyszukiwanie k najbliższych sąsiadów kosztuje O(N·d) na każde zapytanie, co staje się nieracjonalne po kilkuset tysiącach wektorów. Bazy danych wektorowych radzą sobie z tym, akceptując niewielką stratę w stopniu odzyskiwania informacji w zamian za indeksy najbliższych sąsiadów w przybliżeniu (ANN), które odpowiadają w czasie mniej więcej liniowym względem wielkości zapytania.

Co sprawdzić przed wyborem

Zespoły, które pomijają ocenę, zazwyczaj napotykają problemy w środowisku produkcyjnym. Warto przyjrzeć się czterem kluczowym aspektom.

Jakość wyszukiwania i opóźnienie. Wskaźnik Recall@K pokazuje, jak często system znajduje naprawdę najlepsze wyniki wśród pierwszych K rezultatów. Wyższy wskaźnik recall oznacza, że model otrzymuje najlepsze dostępne informacje. Opóźnienie, wyrażone w milisekundach, ma równie duże znaczenie – inżynierowie obserwują wartości p95 lub p99, ponieważ odzwierciedlają one gorszą stronę doświadczeń użytkowników.

Filtrowanie metadanych. Często zapytanie musi być zawężone za pomocą ustrukturyzowanych atrybutów. Wyszukiwanie frazy „polityka firmy” może wymagać obejmowania jedynie dokumentów z określonej daty lub dotyczących konkretnego działu. Dobrze skonstruowane filtry eliminują z wyników nieistotne lub nieuprawnione rekordy. Bazy danych z funkcją wstępnego filtrowania są zazwyczaj lepsze, ponieważ usuwają niepotrzebne rekordy przed rozpoczęciem wyszukiwania wektorowego, co chroni dokładność wyników.

Zgodność z ekosystemem. Baza danych staje się bardziej przydatna, gdy dobrze współpracuje z resztą stacku AI. Połączniki dla LangChain i LlamaIndex skracają czas potrzebny na stworzenie działającego pipeline’u RAG. Biblioteki klienta w kilku językach oraz obsługa AWS, GCP i innych chmur decydują o tym, jak płynnie system wpisuje się w istniejące oprogramowanie korporacyjne.

Gotowość operacyjna. Obejmuje to sprawdzenie, czy system jest w stanie funkcjonować w wymagającym środowisku produkcyjnym:

• Skalowalność, czyli możliwość obsługi miliardów wektorów i dużego ruchu zapytań.
• Izolacja użytkowników w aplikacjach typu multi-tenant.
• Spełnianie standardów takich jak SOC 2, HIPAA i GDPR.
• Możliwość monitorowania, dzięki której można śledzić wydajność wyszukiwania i zużycie zasobów.

Opcje darmowe i open-source

Silniki o otwartym kodzie źródłowym umożliwiają uruchomienie własnej infrastruktury i uniknięcie regularnych opłat subskrypcyjnych. Poniższe silniki są wymienione mniej więcej od najlżejszych do najcięższych.

Chroma

Chroma to baza danych do embeddingów stworzona z myślą o szybkości pracy programistów. To najkrótsza droga od pustego repozytorium do działającego prototypu RAG, a wiele osób używa jej jako swojego pierwszego magazynu wektorowego. Nadaje się do hackathonów, pracy lokalnej oraz szybkich eksperymentów, gdzie łatwość jest ważniejsza niż skalowalność.

Co oferuje: małą API w Pythonie, która pozwala przechodzić od tymczasowych testów lokalnych do trybu klient-serwer, lokalne przechowywanie wspierane przez SQLite, dzięki czemu nie trzeba konfigurować serwera bazy danych, oraz wbudowane funkcje embeddingów, które przy dodawaniu tekstu przekształcają go we wektory przy użyciu domyślnych modeli takich jak all-MiniLM-L6-v2. Może łączyć się z LangChain, LlamaIndex, OpenAI i Hugging Face.

Z pozytywnej strony instalacja polega jedynie na wywołaniu polecenia pip install chromadb, konwersja tekstu na wektory odbywa się bez dodatkowego kodu, a działanie lokalnie zapewnia pełną kontrolę nad danymi i infrastrukturą. Z negatywnej strony brakuje mu funkcji bezpieczeństwa i zarządzania wieloma użytkownikami, które są niezbędne w rygorystycznych środowiskach korporacyjnych, a także nie jest w stanie konkurować z specjalnie zaprojektowanymi systemami rozproszonymi, gdy liczba wektorów przekracza kilka milionów.

Baza danych podstawowa jest dostępna bezpłatnie na licencji Apache 2.0, a obecnie istnieje również wersja w chmurze przeznaczona do skalowania w produkcji.

Milvus

Milvus to chmurowa, wysoce rozproszona baza danych wektorowych, która oddziela obliczenia od przechowywania. Jest przeznaczona dla organizacji obsługujących ogromne ilości danych – setki milionów do miliardów wektorów – gdzie skalowanie jest koniecznością, a nie opcją.

Jego architektura dzieli węzły danych, węzły zapytań i węzły indeksów. Obsługuje wiele typów indeksów, w tym HNSW, IVF i DiskANN, dzięki czemu można dostosować go do konkretnego sprzętu, a także oferuje szybkie indeksowanie i wyszukiwanie przyspieszone kartami GPU. Węzły można dodawać lub usuwać w trakcie pracy bez przerwy w działaniu.

Zalety: zbiory danych na poziomie miliardów elementów zachowują się przewidywalnie, bez nagłych wzrostów opóźnienia p99, ścisła izolacja węzłów umożliwia przetwarzanie dokładnie tam, gdzie jest to potrzebne, a społeczność otwartego oprogramowania jest duża, z obfitą dokumentacją i wtyczkami. Wady: wdrożenie, dostosowanie i uruchomienie systemu opartego na Kubernetes wymaga znacznego wysiłku inżynieryjnego, a dla prostego aplikacji RAG dodatkowe komponenty, takie jak etcd i Kafka, stanowią niepotrzebny obciążenie.

Motor ten jest dostępny za darmo na licencji Apache 2.0. Zilliz, firma stojąca za nim, oferuje zarządzane hostingi od 155 dolarów miesięcznie.

Qdrant

Qdrant to silnik wyszukiwania wektorowego o otwartym kodzie źródłowym napisany w języku Rust, którego priorytetami są bezpieczeństwo pamięci, przepustowość oraz doskonałe filtrowanie danych. Zespoły szukające szybkości i niezawodności często wybierają ten rozwiązanie, szczególnie w przypadku zastosowań typu RAG z zaawansowanymi filtrami metadanych, dostosowanym mechanizmem oceny wyników oraz restrykcyjnymi limitemi opóźnień.

W jego podstawie leży silnik przechowywania napisany w Rust o nazwie Gridstore, zoptymalizowany pod kątem zadań wektorowych. Projekt wyszukiwania umożliwia łączenie w jednej zapytaniu gęstych wektorów, rzadkich wektorów oraz filtrów metadanych. Filtrowanie odbywa się bezpośrednio w grafie podczas przeszukiwania metodą HNSW, co zapobiega spadkom dokładności wyników spowodowanym filtrowaniem po zakończeniu wyszukiwania. Istnieje również Qdrant Edge – lżejsza wersja przeznaczona do zastosowań mobilnych i w robotyce.

Typowa latencja p50 wynosi około 4 do 5 ms, filtrowanie pozostaje dokładne nawet przy surowych ograniczeniach, a licencja (Apache 2.0) jest permissywna. Wadami są: udział w rozwoju jądra Rust oznacza bardziej stromy krzywa uczenia się, a uzyskanie optymalnego zachowania HNSW wymaga starannego dostosowania ustawień pamięci i indeksu.

Wersja open-source jest bezpłatna. Qdrant Cloud oferuje bezpłatny poziom zarządzany z 1 GB przestrzeni przechowywania, a także płatne klastry oparte na zużyciu.

Weaviate

Weaviate to bazda danych open-source przyjazna dla sztucznej inteligencji, zorganizowana wokół obiektów przypominających grafy, łącząca kilka styli wyszukiwania i typów danych w jedno doświadczenie zapytań. Jest odpowiednia, gdy potrzebujesz zaawansowanego wyszukiwania hybrydowego, złożonych relacji między obiektami oraz procesu pracy opartego na sztucznej inteligencji wbudowanego w bazę danych.

W sposób natywny łączy on gęstą podobieństwo z rankingiem słów kluczowych BM25. Moduły wektorowania łączą się z OpenAI, Cohere i Hugging Face, aby przekształcić tekst dla użytkownika. Dane przechowywane są w schemacie opartym na klasach, dostosowanym do relacji pomiędzy nimi, a także zapewniona jest izolacja i replikacja dla wielu użytkowników.

Korzyściami są mniej kodu szablonowego, ponieważ konwersja tekstu na wektor odbywa się bezpośrednio w bazie danych, dostosowywalne parametry hybrydowe umożliwiające równowagę pomiędzy dokładnością słów kluczowych a szerokim odtworzeniem znaczenia, oraz stabilne odpowiedzi w milisekundach nawet przy setkach milionów obiektów. Wadami są początkowe trudności z przyzwyczajeniem się do schematu opartego na klasach oraz większe wymagania sprzętowe w porównaniu z rozwiązaniami wbudowanymi.

Oprogramowanie jest dostępne bezpłatnie na licencji BSD-3. Weaviate Cloud oferuje plany zarządzane bez serwerów od 45 dolarów miesięcznie.

pgvector dla PostgreSQL

Rozszerzenie pgvector przekształca PostgreSQL w wydajne magazynowanie wektorów, umożliwiając przechowywanie embeddingów obok zwykłych danych transakcyjnych. Jest naturalnym wyborem dla zespołów już zaangażowanych w Postgres, które nie chcą tworzyć kolejnej bazy danych.

Dodaje natywny typ kolumny wektorowej do standardowych schematów SQL, obsługuje podobieństwo kosinowe, odległość L2 i iloczyn skalarny, tworzy indeksy HNSW i IVFFlat oraz przeprowadza zapytania dotyczące podobieństwa w ramach standardowych transakcji ACID.

Największą zaletą jest uniknięcie kosztów operacyjnych, przeglądów bezpieczeństwa oraz konieczności utrzymania oddzielnego systemu. Istniejące funkcje monitorowania, tworzenia kopii zapasowych i replikacji w Postgresie pozostają bez zmian, a filtrowanie metadanych to po prostu znajoma klauzula WHERE w połączeniu z funkcją mierzącą odległość. Wadami są wyższe zużycie pamięci oraz gorsza skalowalność w porównaniu z silnikami stworzonymi wyłącznie do obsługi wektorów, a także zauważalny wzrost opóźnień po przekroczeniu około 50 milionów wektorów, chyba że zostanie dodane coś takiego jak pgvectorscale.

Rozszerzenie jest darmowe i otwarte kodowo. To, ile zapłacisz, zależy od sposobu hostowania Postgresa.

Opcje płatne i zarządzane

Bazy danych zarządzane zapewniają niski poziom konieczności konserwacji, dzięki czemu zespół może skupić się na aplikacji zamiast na serwerach.

Pinecone

Pinecone w dużej mierze zdefiniował kategorię zarządzanych baz danych wektorowych dzięki bezserwerowemu, bezkonfiguracyjnemu projektowi, który ukrywa całą infrastrukturę backendową. Jest przeznaczony dla zespołów, które chcą szybko wejść do produkcji bez konieczności zarządzania serwerami, klastrami czy parametrami indeksu.

Funkcjonuje wyłącznie jako usługa SaaS w chmurze, dzieli warstwy odczytu, zapisu i przechowywania, dzięki czemu każda z nich może się skalować niezależnie, umożliwia uruchamianie modeli do embedowania i ponownego sortowania za pomocą Pinecone Inference, a także obsługuje wektory gęste, wektory rzadkie oraz skuteczne filtrowanie metadanych. W zamian nie ma konieczności zajmowania się infrastrukturą, aktualizacjami ani odbudową indeksu, istnieje szeroka kompatybilność z różnymi frameworkami i chmurami, a także wysoka dostępność przy przewidywalnej wydajności pod obciążeniem.

Wadami są fakt, że jest to oprogramowanie zamknięte, co oznacza prawdziwe uwięzienie u dostawcy, oraz szybki wzrost kosztów zużycia w przypadku obciążeń z dużą ilością operacji odczytu i zapisu.

Ceny jak podano: darmowy poziom Starter (2 GB, 1 mln operacji odczytu, tylko AWS us-east-1); Standard z minimalną opłatą 50 dolarów miesięcznie, 0,33 dolara za GB-miesiąc, plus około 4 do 4,50 dolara za milion operacji zapisu oraz 16 do 18 dolarów za milion operacji odczytu; Enterprise z minimalną opłatą 500 dolarów miesięcznie; oraz dodatek HIPAA w cenie 190 dolarów miesięcznie.

Turbopuffer

Turbopuffer to silnik wyszukiwania typu serverless, stworzony bezpośrednio na bazie chmurowego przechowywania obiektów, a kluczową cechą jest efektywność kosztowa. Jest to najlepszy wybór dla produktów SaaS i AI przeznaczonych dla wielu użytkowników z dużą liczbą przestrzeni nazw, gdzie wydatki muszą być kontrolowane.

Pomija tradycyjne dyski i przeszukuje bezpośrednio w systemach przechowywania obiektów, radzi sobie z miliardami wektorów bez żadnych ograniczeń dotyczących nazw przestrzeni, wykorzystuje indeks SPFresh dostosowany do przeszukiwań i umożliwia natychmiastowe widoczne w wynikach zapisy. Koszty przechowywania i zapytań znacznie spadają w porównaniu z starszymi usługami zarządzanymi, uniknięto również pułapek cenowych związanych z opłatami za każdy pod, które karzą projekty wielu użytkowników, a standardowe plany obejmują certyfikację SOC 2 i HIPAA.

Z drugiej strony jest to rozwiązanie o zamkniętym kodzie źródłowym, które ma krótszą historię rozwoju niż ugruntowani konkurenci, a jego ekosystem pluginów i integracji jest słabszy. Opłaty są w pełni uzależnione od ilości wykorzystania, przy czym standardowe plany wymagają minimalnej opłaty miesięcznej w wysokości 64 dolarów, a duże nazwy przestrzeni dają zniżki na liczbowość zapytań.

TiDB Vector Search

TiDB Vector Search od PingCAP łączy rozproszoną bazę danych SQL z własnym silnikiem embeddingów, dzięki czemu duże obciążenia transakcyjne oraz wyszukiwanie semantyczne mogą działać w jednym systemie skalowalnym. Jest to rozwiązanie sensowne, gdy potrzebna jest bardzo duża skalowalność pozioma w połączeniu z złożonym filtrowaniem SQL i wyszukiwaniem wektorowym w tych samych danych jednocześnie.

Platforma łączy przechowywanie embeddingów z rozproszoną bazą danych SQL, tworzy standardowe indeksy SQL obok indeksów wektorowych HNSW, rozpraszająca zapytania między węzłami dla zapewnienia wysokiej dostępności oraz obsługuje wyszukiwanie hybrydowe i dokładne dopasowywanie słów kluczowych oprócz porównywania podobieństwa wektorowego. Dzięki temu eliminowane są problemy synchronizacji oraz konieczność używania specjalnych pipeline’ów pomiędzy bazą danych aplikacji a oddzielnym magazynem wektorowym, umożliwia intensywne filtrowanie danych wielu użytkowników za pomocą połączeń SQL oraz skalowanie bez spowalniania zapytań.

To przesada dla lekkiego pipeline RAG opartego wyłącznie na wektorach, a optymalizacja wydajności wymaga dogłębnego zrozumienia zaimplementowanego SQL rozproszonego.

W ofercie TiDB Cloud Starter pakiet darmowy jest najhojniejszy w swojej kategorii: 5 GiB pamięci do przechowywania wierszy, 5 GiB do przechowywania kolumnowego oraz 50 milionów jednostek żądania na klastr, przy maksymalnie 5 klastrach na organizację. Daje to łącznie 25 GiB na przechowywanie wierszy, 25 GiB na przechowywanie kolumnowe oraz 250 milionów jednostek żądania miesięcznie bez żadnych opłat. Po tym progu kosztuje to 0,10 dolara za milion jednostek żądania oraz 0,20 dolara za GiB-miesiąc dla przechowywania wierszy w regionie us-east.

Gdzie wektorowe RAG ma ograniczenia

Wyszukiwanie wektorowe jest potężne, ale nadal ma słabości, które wpływają negatywnie na dokładność w zastosowaniach korporacyjnych.

• Utracona kontekst. Standardowe modele RAG przekształcają dokumenty na małe fragmenty, aby zmieściły się one w oknach kontekstowych. Ten mechaniczny proces niszczy strukturę złożonych dokumentów, a mały fragment łatwo traci powiązanie z nagłówkami lub sekcjami, które nadawały mu znaczenie.
• Nieprecyzyjność. Wyszukiwanie opiera się na bliskości w przestrzeni wektorowej, więc podobne terminy lub nazwy produktów o identycznym brzmieniu są mylone. Błędne fakty trafiają do zapytania, co prowadzi do halucynacji.
• Drogie aktualizacje. Przejście na lepszy model embedding oznacza konieczność ponownego przetworzenia całego korpusu oraz odbudowy dużych indeksów od zera, co zwiększa koszty obliczeniowe i finansowe.

Graph RAG to jedna z alternatyw. Modeluje punkty danych jako węzły, a relacje jako krawędzie, a narzędzia takie jak Writer Knowledge Graph utrzymują wyraźne powiązania między dokumentami. To umożliwia rozumowanie wieloetapowe, ogranicza halucynacje i pozwala zespołowi aktualizować pojedynczy fakt bez konieczności ponownego włączania wszystkich elementów.

Praktyczny sposób podjęcia decyzji

Zacznij od tego, co już używasz. W systemie Postgres z mniej niż około 10 milionami wektorów, pgvector radzi sobie z tym zadaniem bez dodatkowych zależności, natomiast pgvectorscale rozszerza jego możliwości do 50 milionów i więcej. W MongoDB należy użyć Atlas Vector Search. W Elastic lub OpenSearch można pozostać przy obecnym rozwiązaniu, ponieważ OpenSearch 3.0 w dużej mierze zamknął luki w funkcjonalnościach. W Redis należy skorzystać z wbudowanego wsparcia dla wektorów w Redis 8 z użyciem FT.HYBRID.

Jeśli zaczynasz od zera, weź pod uwagę trzy kwestie:

1. Skala i wydajność operacji. Tworzenie prototypów z użyciem mniej niż 1 miliona wektorów wskazuje na Chroma. Produkcja self-hosted z wysoką wydajnością filtrowania wskazuje na Qdrant. Zadania na skalę miliardów elementów lub z wykorzystaniem GPU wskazują na Milvus. Zarządzana produkcja wymagająca spełnienia określonych standardów wskazuje na Pinecone lub Weaviate Cloud.
2. Kształt kosztów. W przypadku intensywnego wykorzystania z wieloma użytkownikami, przy których większość z nich pozostaje nieaktywna, oszczędności wynoszące od 10 do 100 razy w Turbopuffer są rzeczywiste, chociaż zapytania „chłodne” zajmują około 500 ms. Dla systemów wrażliwych na koszty, pracujących z ponad 50 milionami wektorów przy przewidywalnym obciążeniu, odpowiednie będą pgvector w połączeniu z pgvectorscale.
3. Wymagania dotyczące mechanizmów rozumowania. W przypadku zapytań wieloetapowych lub wymagających wyjaśnialności oraz struktury relacyjnej, należy dodać graf wiedzy takiego jak Neo4j, Memgraph lub FalkorDB i używać Graph RAG razem z wektorami, a nie zamiast nich.

Częste pytania

Jak stworzyć bazę danych wektorową do RAG? Podziel dokumenty na fragmenty, utwórz embeddingi za pomocą modelu takiego jak OpenAI lub BGE, a następnie przechowaj i zindeksuj wektory w narzędziach takich jak Qdrant, Milvus lub pgvector. W przypadku całkowicie lokalnego rozwiązania można użyć Chromy lub FAISS działających na jednym komputerze, bez udziału chmury.

Jaką rolę pełni? Jest to silnik wyszukiwania znajdujący się pomiędzy dokumentami a modelem LLM. Przechowuje embeddingi, a podczas wyszukiwania zwraca najbardziej istotne fragmenty, dzięki czemu model może odpowiadać na podstawie konkretnego kontekstu, a nie tylko pamięci.

Którą bazę danych należy wybrać? Zależy to od skali i używanych narzędzi. Chroma i pgvector to najlepsze opcje darmowe do małych i średnich zadań, Qdrant i Milvus są najlepsze do samodzielnej implementacji w produkcji, natomiast Pinecone to najlepszy wybór w wersji zarządzanej, gdy nie chce się zajmować żadnymi operacjami technicznymi.

Jak wektory są wykorzystywane w tym procesie? Model embedding konwertuje fragmenty tekstu na wektory o wysokiej rozdzielczości. Baza danych przechowuje je, a gdy przychodzi pytanie, znajduje najbliższe wektory względem wektora zapytania za pomocą wyszukiwania ANN i przekazuje te fragmenty do promptu.

Czy zawsze potrzebna jest baza danych wektorowych? Nie, chociaż pozostaje standardem w branży. Systemy bez wektorów, takie jak PageIndex, całkowicie pomijają embeddingi. Zamieniają one dokumenty na drzewa hierarchiczne i pozwalają modelom LLM na szukanie odpowiedzi na podstawie spisu treści. Wiele zespołów korporacyjnych używa również baz danych grafowych do GraphRAG, pobierając kontekst poprzez wyraźne połączenia zamiast podobieństwa przestrzennego.

Jakie są siedem typów RAG? Naive RAG (proste pobieranie danych, a następnie generowanie odpowiedzi), retrieve-and-rerank (standardowe podejście w produkcji), hybrid RAG (łączenie intensywnej i rozproszonej wyszukiwania), multimodal RAG (tekst, obrazy i dźwięk w jednym procesie), Graph RAG (przechodzenie po grafie wiedzy w celu realizacji zapytań relacyjnych), agentic RAG (agent LLM wybiera najlepszą strategię pobierania danych dla każdego zapytania) oraz HyDE RAG (model najpierw tworzy hipotetyczną odpowiedź, a następnie wyszukuje dane na jej podstawie).