Wektorowe bazy danych weszły do mainstreamu, a RAG stało się synonimem „AI w firmie”. W praktyce - w połowie projektów, które wdrażamy, klasyczne wyszukiwanie pełnotekstowe daje lepsze wyniki przy ułamku kosztu. Pokazujemy, jak rozpoznać kiedy nie pchać się w RAG na siłę.
Co tak naprawdę chcesz osiągnąć?
Zanim sięgniesz po embeddingi i wektorową bazę danych, zadaj sobie podstawowe pytanie - czy użytkownik szuka konkretnej informacji, czy odpowiedzi syntezowanej z wielu źródeł? RAG świetnie radzi sobie z drugim przypadkiem, ale dla pierwszego dobry indeks pełnotekstowy z fasetami jest zazwyczaj lepszy.
Trzy sygnały, że nie potrzebujesz RAG
- Zapytania są krótkie i konkretne - „regulamin urlopu”, „numer faktury 2024/03”. Klasyczny inverted index Postgres FTS lub Elastic znajdzie to lepiej i szybciej.
- Dane są strukturalne - tabele, formularze, listy. Wektory tu nie pomagają; SQL z indeksami GIN/GIN-trgm wystarczy.
- Użytkownicy są ekspertami - znają słownictwo branżowe. Keyword search z synonimami da im większą kontrolę niż semantic search.
Kiedy RAG faktycznie się opłaca
RAG ma sens kiedy musisz: (a) odpowiadać pełnymi zdaniami, a nie zwracać listę dokumentów; (b) łączyć fragmenty z różnych źródeł w jedną odpowiedź; (c) obsługiwać zapytania nieprecyzyjne, które wymagają „zrozumienia intencji” - typowe dla obsługi klienta i wewnętrznych asystentów.
Najlepsze wdrożenia, które widzieliśmy, łączą oba podejścia: hybrydowy retrieval (BM25 + embeddings) i reranker, który decyduje co naprawdę trafia do kontekstu modelu.
Praktyczna heurystyka
Zacznij od najprostszej rzeczy, która może zadziałać. Postgres FTS + dobry UX wyszukiwarki to często 80% wartości RAG-a za 20% kosztu. Jeśli okaże się, że to za mało - dołożysz vector search.