Większość firmowych baz wiedzy nie potrzebuje RAG

Nasz wewnętrzny wiki firmowy działa na pięciu poleceniach shell i ręcznie utrzymywanym pliku indeksu. Żadnych embeddings, żadnej vector database, żadnego zadania re-indeksowania. Dla bazy wiedzy liczącej około 200 dokumentów takie rozwiązanie jest szybsze we wdrożeniu, tańsze w utrzymaniu i dokładniejsze niż typowy pipeline RAG. Kompromis zaczyna się opłacać gdzieś powyżej tysiąca dokumentów, nie wcześniej.

Kilka słów o Karpathym i Obsidian

Dwie rzeczy sprawiły, że to podejście stało się dla nas oczywiste. Pierwsza to konsekwentny argument Andreja Karpathy'ego, że agenty AI powinny otrzymywać narzędzia, a nie pobrane fragmenty tekstu. Jego projekt AutoResearch, opublikowany w marcu 2026, ilustruje tę tezę dosłownie: agent uruchamia kod zamiast odpytywać embeddings, a postęp wynika z wykonania. AutoResearch omówiliśmy szczegółowo we wcześniejszym artykule.

Druga rzecz to Obsidian. Vault Obsidian to zwykły folder z plikami markdown. Nie ma tu własnościowej bazy danych, schematu do migracji ani SDK do nauki. W połączeniu z lokalną wtyczką REST API Obsidiana cała baza wiedzy jest dostępna przez normalny endpoint HTTP, który dowolny proces może odczytywać i zapisywać. To połączenie sprawia, że wzorzec "daj agentowi narzędzia" jest trywialny w implementacji: kilka poleceń shell i mamy LLM, który może czytać, pisać i przeszukiwać ustrukturyzowaną bazę wiedzy bezpośrednio.

Co faktycznie uruchamiamy

Nasz wewnętrzny wiki to dziś 22 strony ustrukturyzowanej wiedzy: encje (osoby, firmy, projekty), koncepty (frameworki i zasady), źródła (surowe notatki badawcze) oraz strony syntezy, które je łączą. Każda strona linkuje do innych stron za pomocą wikilinks Obsidiana, a ręcznie utrzymywany `index.md` w katalogu głównym wymienia wszystko według kategorii z jednowierszowymi opisami.

Agent nie przeszukuje vault za pomocą embeddings. Uruchamia pięć poleceń:

• `wiki read <path>`. Pobierz pojedynczą stronę markdown.
• `wiki write <path> -`. Utwórz lub nadpisz stronę ze stdin.
• `wiki append <path> <text>`. Dodaj linię do strony (używane do bieżącego dziennika aktywności).
• `wiki search <query>`. Wywołaj wbudowane wyszukiwanie pełnotekstowe Obsidiana.
• `wiki list <dir>`. Wylistuj pliki w katalogu.

Cała implementacja to mniej więcej 80 linii bash i curl. Nie ma vector database, modelu embeddingów, strategii chunking, reranker ani nocnego zadania indeksowania. Dodanie nowej notatki oznacza zapisanie pliku. Agent pobiera ją przy następnym zapytaniu bez żadnego etapu pipeline pomiędzy.

Plik indeksu jest systemem wyszukiwania

To jest część, którą zajęło nam trochę czasu, zanim ją przyznaliśmy. Gdy agent otrzymuje pytanie, nie zaczyna od wyszukiwania czegokolwiek. Zaczyna od odczytania `wiki/index.md`, który jest starannie opracowanym spisem treści napisanym przez człowieka (lub przez agenta-opiekuna uruchamianego harmonogramem). Indeks wymienia każdą stronę z jednozdaniowym opisem pogrupowanym według kategorii. Z tego pojedynczego odczytu zajmującego około 400 tokenów agent już wie, która jedna lub dwie strony są istotne.

Kolejny krok to jeden lub dwa celowane odczyty, które pobierają odpowiednie strony w całości. Każda strona ma od 200 do 800 tokenów. Większość zapytań kończy się na dwóch lub trzech odczytach i mniej więcej tysiącu tokenach zawartości vault w oknie kontekstu. To mniej niż to, co wstrzykuje domyślna konfiguracja RAG, a treść jest spójna (całe strony), a nie pocięta (fragmenty wyrwane z otaczającego kontekstu).

Utrzymywany indeks wykonuje pracę, którą vector database wykonuje w pipeline RAG: mapuje zapytanie na właściwe dokumenty. Różnica polega na tym, że człowiek raz stworzył to mapowanie, zamiast modelu embeddingów przybliżającego je przy każdym zapytaniu.

Porównanie tokenów i kosztów

Dla małej firmowej bazy wiedzy liczącej około 200 dokumentów przedstawiamy, ile kosztuje domyślna konfiguracja RAG w porównaniu z wzorcem dostępu do plików opartego na indeksie. Liczby tokenów pochodzą z obserwacji naszego własnego vault. Liczby dotyczące infrastruktury pochodzą z publicznych cenników najpopularniejszych usług zarządzanych.

Oszczędności tokenów na zapytanie rzędu 30 do 60 procent są realne, ale to nie jest najważniejsza informacja. Najważniejsze jest wszystko w drugiej kolumnie, co znika. Żadnej pozycji vector database na miesięcznej fakturze. Żadnego modelu embeddingów do utrzymywania. Żadnej sesji debugowania "zmieniliśmy strategię chunking i odpowiedzi się zmieniły". Dla 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.

O czym przestajesz myśleć

Najlepszym sposobem na uzasadnienie tego wzorca jest wymienienie decyzji, które znikają:

• Strategia chunking. Żadnej debaty: "czy dzielić na akapity, zdania, czy liczbę tokenów?". Strona jest jednostką.
• Wybór modelu embeddingów. Żadnego projektu badawczego porównującego text-embedding-3-small z dostrojonymi alternatywami.
• Operacje na vector database. Żadnej usługi zarządzanej do monitorowania, aktualizowania ani budżetowania.
• Pipelines re-indeksowania. Żadnego nocnego zadania wsadowego, żadnych wiadomości Slack "indeks jest nieaktualny".
• Harness ewaluacji wyszukiwania. Żadnego zestawu testów precyzji i pełności działającego obok bazy wiedzy.
• Strojenie hybrid search. Żadnego pipeline BM25 + wektor + rerank do utrzymywania w równowadze.

To mniej więcej cały podręcznik operacji RAG, usunięty. Zastępuje go jeden skrypt shell i dyscyplina utrzymywania dokładnego pliku indeksu. Dyscyplina jest realna, ale jest to ta sama dyscyplina, która sprawia, że wiki jest wartościowe dla ludzi.

Kiedy RAG nadal jest właściwym wyborem

Ten wzorzec ma wyraźne ograniczenia. Utrzymywany indeks przestaje działać gdzieś około tysiąca dokumentów, gdy 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 sprawnie skanować przy każdym zapytaniu. Powyżej tej skali embeddings i prawdziwa warstwa wyszukiwania zaczynają się opłacać.

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

• Zbiory multimodalne. Pliki PDF z tabelami, zeskanowane dokumenty, transkrypcje audio, raporty z dużą ilością obrazów. Vault markdown zakłada, że wszystko sprowadza się do tekstu.
• Aktualizacje o wysokiej częstotliwości na dużą skalę. Jeśli indeksujesz tysiące publicznych dokumentów zmieniających się co minutę i potrzebujesz natychmiastowej możliwości ich odpytywania.
• Ścisłe filtrowanie metadanych przy wyszukiwaniu. Gdy zapytania wymagają ustrukturyzowanych filtrów (zakresy dat, autor, typ dokumentu) wbudowanych w etap wyszukiwania, vector database z metadanymi jest lepszym rozwiązaniem.
• Niezaufana lub wroga zawartość. Gdy korpus pochodzi od wielu autorów o sprzecznych celach i żaden pojedynczy człowiek nie może być powierzony utrzymaniem kuratowanego indeksu.

Dla większości wewnętrznych firmowych baz wiedzy (wiki firmowe, dokumentacja produktowa, playbooki sprzedażowe, przewodniki onboardingowe, wewnętrzne SOPs) żaden z tych warunków nie zachodzi. Korpus jest mały, autorów jest niewielu, struktura jest stabilna, a osoby utrzymujące dokumentację to te same osoby, którym najbardziej zależy na jej poprawności. RAG jest złym domyślnym wyborem.

Co to oznacza dla większości firm

Jeśli prowadzą Państwo małą lub średnią firmę, patrzą na istniejącą dokumentację i zastanawiają się, jak uczynić ją dostępną dla AI, uczciwa odpowiedź brzmi zazwyczaj: nie potrzebujecie Państwo vector database. Potrzebujecie pliku indeksu, krótkiego skryptu do odczytu i zapisu dokumentów oraz LLM z dostępem do narzędzi. Wszystkie komponenty są gotowe do użycia. Praca polega na utrzymywaniu indeksu w aktualnym stanie.

Firmy sprzedające RAG jako usługę nie mylą się co do technologii. Mylą się co do domyślnego wyboru. RAG jest właściwym narzędziem dla problemów w skali, której większość firm nie osiąga, i dla typów treści, których większość firm nie przechowuje. Sięganie po nie jako pierwsze to sposób, w jaki wewnętrzne projekty AI kończą się sześciomiesięcznym harmonogramem i cyklicznymi rachunkami za infrastrukturę, zanim odpowiedzą na pierwsze prawdziwe pytanie.

W webvise budujemy wewnętrzne narzędzia AI na takich pragmatycznych podstawach: ustrukturyzowana wiedza, proste narzędzia, agenty czytające i piszące 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, skontaktujcie się z nami, a omówimy Państwa rzeczywisty korpus przed podjęciem decyzji o infrastrukturze.