Większość firmowych baz wiedzy nie potrzebuje RAG

Wewnętrzne firmowe wiki działa na pięciu poleceniach powłoki i ręcznie utrzymywanym pliku indeksu. Bez embeddingów, bez bazy wektorowej, bez zadań re-indeksowania. W przypadku bazy wiedzy liczącej około 200 dokumentów takie rozwiązanie jest szybsze w budowie, tańsze w utrzymaniu i dokładniejsze niż typowy potok RAG. Opłacalność tego drugiego podejścia pojawia się gdzieś powyżej tysiąca dokumentów, nie wcześniej.

Kilka słów o Karpathym i Obsidianie

Dwie rzeczy sprawiły, że to podejście stało się oczywiste. Pierwsza to konsekwentny argument Andreje Karpathy'ego, że agenty AI powinny otrzymywać narzędzia, a nie wycinki pobranych fragmentów. Jego projekt AutoResearch, opublikowany w marcu 2026 roku, ilustruje to dosłownie: agent uruchamia kod zamiast odpytywać embeddingi, a postęp wynika z wykonania. AutoResearch zostało omówione szczegółowo w jednym z wcześniejszych wpisów.

Druga rzecz to Obsidian. Repozytorium Obsidiana to zwykły folder plików markdown. Nie ma tu zastrzeżonej bazy danych, schematu do migracji ani SDK do nauki. W połączeniu z wtyczką lokalnego REST API Obsidiana cała baza wiedzy jest dostępna za pośrednictwem zwykłego punktu końcowego HTTP, z którego każdy proces może odczytywać i zapisywać dane. To połączenie sprawia, że wzorzec "daj agentowi narzędzia" jest trywialnie prosty do wdrożenia: kilka poleceń powłoki wystarczy, by LLM mógł czytać, pisać i przeszukiwać ustrukturyzowaną bazę wiedzy bezpośrednio.

Co faktycznie działa w produkcji

Wewnętrzne wiki liczy dziś 22 strony ustrukturyzowanej wiedzy: encje (osoby, firmy, projekty), koncepcje (frameworki i zasady), źródła (surowe notatki badawcze) oraz strony syntetyzujące, które je łączą. Każda strona zawiera linki do innych stron za pomocą wikilinków Obsidiana, a ręcznie utrzymywany plik `index.md` w katalogu głównym wymienia wszystko według kategorii z opisami w jednym zdaniu.

Agent nie przeszukuje repozytorium za pomocą embeddingów. Uruchamia pięć poleceń:

• `wiki read <path>`. Pobiera pojedynczą stronę markdown.
• `wiki write <path> -`. Tworzy lub nadpisuje stronę ze stdin.
• `wiki append <path> <text>`. Dodaje wiersz do strony (używane w dzienniku aktywności).
• `wiki search <query>`. Korzysta z wbudowanego wyszukiwania pełnotekstowego Obsidiana.
• `wiki list <dir>`. Wyświetla pliki w katalogu.

Cała implementacja to około 80 linii kodu bash i curl. Nie ma bazy wektorowej, modelu embeddingów, strategii podziału na fragmenty, rerankera ani nocnego zadania indeksowania. Dodanie nowej notatki polega na zapisaniu pliku. Agent uwzględnia ją przy następnym zapytaniu, bez żadnego kroku potoku pomiędzy.

Plik indeksu jako system wyszukiwania

Istota podejścia: agent zaczyna od pliku `wiki/index.md`. Ten starannie prowadzony spis treści wymienia każdą stronę z opisem w jednym zdaniu, pogrupowanym według kategorii. Z tego jednego odczytu wynoszącego około 400 tokenów agent wie już, która jedna lub dwie strony są istotne.

Kolejny krok to jedno lub dwa ukierunkowane odczyty pobierające odpowiednie strony w całości. Każda strona liczy od 200 do 800 tokenów. Większość zapytań kończy się po dwóch lub trzech odczytach, z mniej więcej tysiącem tokenów zawartości repozytorium w oknie kontekstu. To mniej niż to, co wstrzykuje domyślna konfiguracja RAG, a treść jest spójna (całe strony), a nie poszatkowana (fragmenty wyrwane z otaczającego kontekstu).

Utrzymywany indeks spełnia rolę, którą w potoku RAG pełni baza wektorowa: mapuje zapytanie na właściwe dokumenty. Różnica polega na tym, że człowiek raz stworzył to odwzorowanie, zamiast przybliżania go przez model embeddingów przy każdym zapytaniu.

Porównanie tokenów i kosztów

W przypadku małej firmowej bazy wiedzy liczącej około 200 dokumentów poniżej przedstawiono porównanie domyślnej konfiguracji RAG z wzorcem dostępu do plików opartym na indeksie. Liczby tokenów to szacunki kierunkowe oparte na typowych wzorcach wyszukiwania. Dane dotyczące infrastruktury pochodzą z publicznych cenników najpopularniejszych usług zarządzanych.

Oszczędności tokenów zależą od struktury korpusu i wzorców zapytań. Ważniejsze jest to, co znika z drugiej kolumny: żadnej pozycji bazy wektorowej na miesięcznej fakturze, żadnego modelu embeddingów do utrzymania i żadnych sesji debugowania strategii podziału na fragmenty, gdy odpowiedzi się zmieniają. W przypadku bazy wiedzy, która swobodnie mieści się w głowie jednej osoby, każdy z tych ruchomych elementów to narzut bez odpowiadającej mu korzyści.

Co przestaje zaprzątać uwagę

Najczystszy argument na rzecz tego wzorca to lista decyzji, które znikają:

• Strategia podziału na fragmenty. Koniec z debatą "czy dzielić według akapitu, zdania, liczby tokenów?". Strona jest jednostką.
• Wybór modelu embeddingów. Żadnych projektów badawczych porównujących text-embedding-3-small z dostrojonymi alternatywami.
• Obsługa bazy wektorowej. Żadnej zarządzanej usługi do monitorowania, aktualizowania ani budżetowania.
• Potoki re-indeksowania. Żadnych nocnych zadań wsadowych, żadnych wiadomości na Slacku o nieaktualnym indeksie.
• Zestaw do ewaluacji wyszukiwania. Żadnego zestawu testów precyzji i pokrycia działającego równolegle z bazą wiedzy.
• Strojenie hybrydowego wyszukiwania. Żadnego potoku BM25 plus wektory plus reranker do utrzymywania w równowadze.

To w zasadzie cały podręcznik operacyjny RAG, wyeliminowany. Zastępuje go jeden skrypt powłoki i dyscyplina utrzymywania aktualności pliku indeksu. Ta dyscyplina jest realna, ale jest tą samą dyscypliną, która w pierwszej kolejności sprawia, że wiki jest wartościowa dla ludzi.

Kiedy RAG pozostaje właściwym wyborem

Ten wzorzec ma wyraźne ograniczenia. Utrzymywany indeks przestaje działać sprawnie gdzieś około tysiąca dokumentów, kiedy człowiek nie jest już w stanie utrzymać struktury w głowie, a plik indeksu staje się zbyt długi, by agent mógł go efektywnie skanować przy każdym zapytaniu. Powyżej tej skali embeddingi i właściwa warstwa wyszukiwania zaczynają się opłacać.

Inne przypadki, w których RAG pozostaje właściwym narzędziem:

• Korpusy multimodalne. Pliki PDF z tabelami, zeskanowane dokumenty, transkrypcje audio, raporty z dużą ilością grafik. Repozytorium markdown zakłada, że wszystko sprowadza się do tekstu.
• Częste aktualizacje na dużą skalę. Indeksowanie tysięcy publicznych dokumentów zmieniających się co minutę z wymogiem natychmiastowej dostępności do zapytań.
• Ścisłe filtrowanie metadanych przy wyszukiwaniu. Gdy zapytania wymagają ustrukturyzowanych filtrów (zakresy dat, autor, typ dokumentu) wbudowanych w etap wyszukiwania, baza wektorowa z metadanymi jest lepszym rozwiązaniem.
• Treści niezaufane lub wrogie. Gdy korpus pochodzi od wielu autorów o sprzecznych celach i żadna pojedyncza osoba nie może być odpowiedzialna za utrzymanie skurowanego indeksu.

W przypadku większości wewnętrznych firmowych baz wiedzy (firmowe wiki, dokumentacja produktu, podręczniki sprzedaży, materiały onboardingowe, wewnętrzne standardowe procedury operacyjne) żaden z tych warunków nie zachodzi. Korpus jest mały, autorów jest niewielu, struktura jest stabilna, a osoby utrzymujące dokumentację najbardziej dbają o jej poprawność. RAG jest często złym domyślnym wyborem dla przypadków użycia, z którymi mamy do czynienia.

Rozwiązanie odpowiednie dla większości firm

Jeśli prowadzą Państwo małą lub średnią firmę i zastanawiają się, jak udostępnić istniejącą dokumentację do zapytań przez AI, szczera odpowiedź brzmi zwykle: baza wektorowa nie jest potrzebna. Potrzebny jest plik indeksu, krótki skrypt czytający i zapisujący dokumenty oraz LLM z dostępem do narzędzi. Wszystkie komponenty są ogólnodostępne. Praca polega na utrzymywaniu aktualności indeksu.

Dostawcy RAG jako usługi nie mylą się co do technologii. Spór dotyczy tego, kiedy powinna ona być domyślną architekturą. RAG jest właściwym narzędziem dla problemów o skali, której większość firm nie osiąga, i typów treści, których większość firm nie przechowuje. Sięganie po RAG w pierwszej kolejności prowadzi niekiedy do długich harmonogramów i powtarzających się kosztów infrastruktury, zanim oryginalny cel zostanie zrealizowany.

webvise buduje wewnętrzne narzędzia AI na takim pragmatycznym fundamencie: ustrukturyzowana wiedza, proste narzędzia, agenty czytające i zapisujące dane bezpośrednio. Jeśli rozważają Państwo projekt RAG dla dokumentacji swojego zespołu i chcą uzyskać drugą opinię na temat tego, czy złożoność jest uzasadniona, zapraszamy do kontaktu w celu omówienia rzeczywistego korpusu przed podjęciem zobowiązania wobec infrastruktury.