Indeks w pamięci czy zarządzana wyszukiwarka: kiedy przeskoczyć

Rozmowa o RAG w firmie prawie zawsze zaczyna się od pytania „co wybrać, lokalnie czy w chmurze”. To złe pytanie i prowadzi do dwóch złych odpowiedzi.

Pierwsza to prototyp, który nigdy nie dorasta. Działa na laptopie jednej osoby, indeks powstaje przy każdym uruchomieniu, wszyscy są zadowoleni i po pół roku nikt nie wie, jak to wdrożyć.

Druga jest droższa. Zespół od razu buduje zarządzany magazyn danych z konsolą, uprawnieniami i potokiem aktualizacji, żeby obsłużyć dwieście dokumentów, które zmieniają się raz na kwartał. Konfiguracja zajmuje dwa tygodnie, a odpowiedzi są takie same jak z indeksu w pamięci.

Właściwe pytanie brzmi: kiedy przeskoczyć. Poniżej to, co u mnie przesądza.

Trzy opcje, nie dwie

Większość porównań zestawia dwie skrajności i pomija to, co jest pomiędzy. W ADK dostępne są trzy poziomy, a ten środkowy bywa najlepszą odpowiedzią.

Środkowa kolumna to Vertex AI RAG Engine. Sam tworzysz korpus, wgrywasz dokumenty i ustawiasz sposób cięcia oraz embeddingi, ale nie utrzymujesz infrastruktury. To jest sensowny przystanek dla zespołu, który wyrósł z indeksu w pamięci, a nie potrzebuje jeszcze pełnej wyszukiwarki z rankingiem i personalizacją.

Wersja lokalna ma też wariant, o którym warto wiedzieć: obok FilesRetrieval w ADK jest LlamaIndexRetrieval, czyli to samo, tylko z podłączeniem do własnego indeksu zbudowanego w LlamaIndex. Przydaje się, gdy chcesz zostać lokalnie, ale przestaje Ci wystarczać wczytywanie katalogu.

Jedna różnica, która przesądza o reszcie

Wszystkie tabele porównawcze wymieniają kilkanaście cech. W praktyce decyduje jedna: czy indeks przeżywa restart procesu.

FilesRetrieval wczytuje katalog i buduje indeks w pamięci przy starcie agenta. Kilka plików to sekundy, tysiąc plików to kilka minut. Po restarcie wszystko dzieje się od nowa.

To nie jest wada. To jest decyzja projektowa i pociąga za sobą całą resztę:

• Skalowanie jest ograniczone pamięcią maszyny. Nie liczbą dokumentów w teorii, tylko RAM-em w praktyce.
• Każda instancja ma własną kopię. Dwa procesy to dwa indeksy i dwa razy ten sam koszt budowy.
• Start jest wolniejszy, a odpowiedzi szybsze. Płacisz raz przy uruchomieniu, potem szukasz lokalnie bez sieci.
• Aktualizacja danych jest trywialna. Podmieniasz plik, restartujesz, gotowe. Żadnego potoku indeksowania.

Ostatni punkt jest niedoceniany. W fazie, gdy dokumentacja zmienia się co drugi dzień, „restart i już” bije każdy zarządzany potok, w którym zmiana propaguje się kilkanaście minut.

Rozmowa o kosztach, która ma sens

Tu muszę zrobić rzecz niewygodną i sprostować własne materiały szkoleniowe.

W moich starszych notatkach koszt embeddingów wyliczony był na kwotę kilkukrotnie niższą od rzeczywistej. Sprawdziłem aktualne cenniki: modele embeddingowe Gemini kosztują dziś rząd wielkości 0,15–0,20 USD za milion tokenów, zależnie od tego, czy bierzesz wariant tekstowy, czy multimodalny.

Co ciekawe, korekta nic nie zmienia we wnioskach i to jest właśnie sedno sprawy. Sto stron dokumentacji to około 50 tysięcy tokenów, czyli koszt zaindeksowania rzędu grosza. Nawet gdyby cena była dziesięć razy wyższa, nadal byłby to szum w budżecie.

Embeddingi nigdy nie są czynnikiem decydującym o wyborze architektury. Jeśli ktoś uzasadnia nimi decyzję, liczy nie te rzeczy, co trzeba.

Liczą się trzy inne.

Zapytania. W produktach zarządzanych płacisz od tysiąca zapytań, a stawka zależy od tego, czy używasz zwykłego wyszukiwania, czy wersji z generowaniem odpowiedzi. Różnica między tymi trybami bywa kilkukrotna. To jest miernik, który rośnie wraz z sukcesem wdrożenia, więc warto policzyć go dla ruchu docelowego, a nie pilotażowego.

Przechowywanie indeksu. Rozliczane miesięcznie za gigabajt. Przy dokumentacji tekstowej to zwykle pozycja mała, przy skanach i załącznikach potrafi zaskoczyć.

Czas inżyniera. Największa pozycja w każdym z tych wariantów i jedyna, której nie ma w żadnym cenniku. Dwa tygodnie konfiguracji to koszt, przy którym rachunek za zapytania jest zaokrągleniem.

Trzy pytania, które rozstrzygają

Zamiast tabeli cech, trzy pytania. Odpowiedź na każde przesuwa Cię o poziom wyżej.

1. Czy ktoś poza Tobą musi z tego korzystać jednocześnie? Jeśli nie, zostań lokalnie. Jeden użytkownik i indeks w pamięci to układ, którego nie warto komplikować. Jeśli tak, indeks musi żyć poza procesem.

2. Czy dokumenty zmieniają się częściej, niż jesteś w stanie restartować? Dokumentacja aktualizowana raz na tydzień nie potrzebuje potoku indeksowania. Baza wiedzy, do której ludzie dopisują codziennie, potrzebuje.

3. Czy musisz wiedzieć, dlaczego system zwrócił ten fragment? To pytanie decyduje między RAG Engine a pełną wyszukiwarką. Produkt zarządzany sam tnie dokumenty, sam dobiera embeddingi i sam ustala ranking. Dostajesz lepsze wyniki od razu i tracisz wgląd w to, dlaczego są takie, a nie inne.

Trzecie pytanie brzmi akademicko, dopóki nie trafisz na sytuację, w której system uparcie podaje nieaktualną wersję procedury. Wtedy różnica między „mogę sprawdzić, jak to pocięło” a „muszę zgłosić sprawę do wsparcia” robi się bardzo praktyczna. Pisałem o tym szerzej w tekście o wierności cytowania w RAG.

Przeskok jest tańszy, niż się wydaje

Argument, który najczęściej blokuje decyzję, brzmi: „zacznijmy od razu porządnie, żeby potem nie przepisywać”. W ADK ten argument jest słabszy, niż się wydaje, bo zmiana poziomu to podmiana narzędzia w konfiguracji agenta.

# Lokalnie
from google.adk.tools.retrieval.files_retrieval import FilesRetrieval

tools = [FilesRetrieval(name="baza", description="...", input_dir="./docs")]

# Zarządzana wyszukiwarka
from google.adk.tools import VertexAiSearchTool

tools = [VertexAiSearchTool(search_engine_id="...", max_results=10)]

Instrukcja agenta, jego rola, ograniczenia i cała logika pipeline'u zostają bez zmian. Praca przenosi się na stronę infrastruktury: wgranie dokumentów, konfiguracja magazynu danych, uprawnienia.

To zmienia rachunek ryzyka. Zaczęcie lokalnie nie jest długiem technicznym, jeśli agent jest napisany sensownie. Jest normalnym etapem, w którym sprawdzasz, czy Twoje dokumenty w ogóle nadają się do tej pracy, zanim zapłacisz za infrastrukturę.

Czego żadne z tych narzędzi nie naprawi

Uczciwie na koniec, bo to jest rzecz, którą widzę częściej niż problemy z wyborem produktu.

Żadne z tych trzech rozwiązań nie poradzi sobie z dokumentacją, w której obowiązująca procedura leży obok trzech nieaktualnych wersji tego samego pliku. Wyszukiwarka znajdzie wszystkie cztery, bo wszystkie są o tym samym, i nie ma jak rozstrzygnąć, która obowiązuje.

Zanim wybierzesz poziom, zrób rzecz nudniejszą: ustal, który zbiór dokumentów jest źródłem prawdy, i usuń resztę z zakresu indeksowania. To jedno działanie poprawia jakość odpowiedzi bardziej niż przejście z indeksu w pamięci na produkt za kilkaset dolarów miesięcznie.

Jak zacząć w tym tygodniu

1. Zbuduj indeks lokalny na jednym katalogu. Kilkanaście linii, kilka minut. Celem nie jest wdrożenie, tylko sprawdzenie, czy Wasze dokumenty dają się sensownie przeszukiwać.
2. Napisz dwadzieścia pytań ze znanymi odpowiedziami, zanim ocenisz wynik. Bez tego ocenisz na wyczucie, a wrażenie „ładnie odpowiada” pojawia się zawsze.
3. Policz koszt zapytań dla ruchu docelowego, nie pilotażowego. Jeśli wychodzi mniej niż pensja stażysty, koszt nie jest kryterium i można zdecydować na podstawie trzech pytań wyżej.
4. Przeskocz dopiero, gdy odpowiedź na pierwsze pytanie brzmi „tak”. Wielu użytkowników naraz to jedyny powód, dla którego indeks musi wyjść poza proces.

Kolejne części serii dotyczą migracji na graf w ADK 2.0 oraz testowania agentów. Podstawowe pojęcia zebrałem w słowniczku.