Strategia jako dokument — Siódmy rozdział

Rozdział 6 — Strategia jako dokument, a nie kod

Docieramy do spostrzeżenia, które wśród osób budujących RAG od 2023 roku pojawia się najczęściej jako „rzecz, którą chciałbym zrozumieć od samego początku”.

Tradycyjne frameworki traktują strategię wyszukiwania jako kod Python. Chcesz, dla katalogów technicznych, najpierw szukać po kodzie produktu, potem po słowach kluczowych, potem po wektorach semantycznych, a dopiero na końcu generować odpowiedź? Napisz funkcję. Chcesz, dla albumów fotograficznych, całkowicie pominąć tradycyjne wyszukiwanie semantyczne i polegać na wyspecjalizowanym rerankerze dla obrazów? Napisz inną funkcję. Chcesz, dla filmów firmowych, oddzielić audio od ścieżki wizualnej, transkrybować je oddzielnie, traktować jako odrębne źródła, a następnie ponownie złożyć je w ostateczną odpowiedź? Jeszcze jedna funkcja. Każdy typ treści, każda domena, każdy klient kończy się generowaniem gałęzi kodu, która odbiega od innych, aż do momentu, w którym zmiana strategii wymaga wydania oprogramowania, przeglądu kodu, cyklu testów, wdrożenia. Czas między „mam pomysł, jak poprawić wyszukiwanie w instrukcjach technicznych” a „pomysł jest w produkcji” mierzony jest w tygodniach. Dla każdego pomysłu.

Alternatywny wgląd jest trywialny do wypowiedzenia, a głęboki w konsekwencjach: strategia wyszukiwania nie jest kodem. Jest dokumentem. JSON — ustrukturyzowany format tekstowy, który każdy redaktor, po półgodzinie szkolenia, może przeczytać — który mówi: "najpierw spróbuj tego, potem tego, jeśli pierwsze zawiedzie, przejdź do trzeciego, przerańkuj tak, odpowiedz tym modelem." Ten dokument żyje w bazie danych, a nie w repozytorium. Jest modyfikowany z interfejsu, a nie przez żądanie scalenia (pull request). Jest wersjonowany, kopiowany, specjalizowany dla danej domeny. Strategia dla katalogów technicznych, jedna dla albumów fotograficznych, jedna dla instrukcji instalacji, jedna dla filmów, jedna dla audio, jedna dla umów prawnych, jedna dla bilansów. Wszystkie współistnieją w tym samym systemie. Wszystkie modyfikowalne w czasie rzeczywistym.

Osoby, które pracowały z tym podejściem – nazwijmy je, bez nadmiernej fantazji, Meta-RAG – opowiadają o zmianie tempa, która wykracza poza inżynierię. Typowe zapytanie klienta typu "dodaj wyszukiwanie specyficzne dla kodów produktów zawierających skróty takie jak CMP40M lub RH1M" nie jest już zgłoszeniem deweloperskim na dwa tygodnie. To nowy krok dodany do procedury JSON, przetestowany na gorąco w środowisku stagingowym, wprowadzony na produkcję w jeden popołudniowy dzień. Na pytanie "co się zmieni, jeśli użyjemy innego rerankera dla zdjęć, utrzymując aktualny dla tekstu?" odpowiada się, modyfikując jedną linię konfiguracji. Eksperyment nie kosztuje nic, wycofanie zmian nie kosztuje nic (wystarczy przywrócić poprzednią wersję dokumentu), a zgromadzona wiedza – co działa dobrze dla określonego typu treści – staje się wersjonowanym i przenoszalnym zasobem, a nie ukrytą wiedzą osoby, która napisała dany fragment kodu i jest teraz na wakacjach.

Istnieje również ciekawy efekt społeczny, który ujawnia się w organizacjach, które przyjmują to podejście. Przy strategiach jako dokumencie granica między "programistą" a "ekspertem dziedzinowym" ulega przesunięciu. Bibliotekarz cyfrowy, archiwista korporacyjny, ekspert domenowy — kierownik biura technicznego, odpowiedzialny za dokumentację, product manager, który jak nikt inny zna prawdziwe pytania klientów — może przeczytać strategię, zrozumieć, co ona robi, zasugerować zmiany, a czasem nawet napisać je bezpośrednio. Nie musi przechodzić przez lejek zgłoszeń do rozwoju, nie musi tłumaczyć programiście rzeczy, których programista nie wie (bo nie leży to w zakresie jego kompetencji). RAG przestaje być produktem, który konsumujesz, a staje się narzędziem, które kształtujesz na podstawie swojej wiedzy organizacyjnej. To, w doświadczeniu osób, które tego spróbowały, zmienia morale projektu jeszcze przed liczbami w metrykach.

To nie magia i wiąże się to z kosztami. Potrzebny jest silnik, który będzie efektywnie i bezpiecznie wykonywał te strategie-jako-dokumenty. Potrzebny jest język opisu wystarczająco bogaty, aby obejmował rzeczywiste przypadki, a jednocześnie wystarczająco prosty, aby nie stać się kolejnym przebranym Turing-kompletny systemem. Potrzebne są narzędzia do kontroli wersji, testowania i wycofywania zmian. Ale to wszystko jest problemem dla tych, którzy budują silnik — raz, dla wszystkich użytkowników. Pojedynczy klient końcowy widzi tylko jedno: możliwość ewolucji swojej strategii wyszukiwania z prędkością myśli, a nie z prędkością cyklu wydawniczego oprogramowania. A to, dla tych, którzy są w to zaangażowani, jest cichą rewolucją, która jeszcze nie znalazła swojego miejsca na łamach czasopism branżowych.

Zamknięcie — Siódmy rozdział, za kilka miesięcy

Na początku 2026 roku, sumując wnioski z poprzednich rozdziałów — tabele, które się gubiły, wprowadzające w błąd rerankery, odziedziczone halucynacje, rosnące w zastraszającym tempie rachunki za chmurę, obiecujące, ale sztywne frameworki — ktoś we Włoszech zaczął budować inny serwer RAG. Napisany w Pythonie, zaprojektowany do działania na dostępnym sprzęcie, zdolny do komunikacji z modelami chmurowymi, gdy jest to opłacalne, a z modelami lokalnymi, gdy wymagana jest prywatność lub koszt nie ma uzasadnienia. Serwer, w którym strategie wyszukiwania są modyfikowalnymi dokumentami, reranker to lokalny proces na GPU, tabele nie gubią się, ponieważ są traktowane jako obywatele pierwszej kategorii, zdjęcia nie dziedziczą obiektów z zakurzonych archiwów z innych epok, a koszt zapytania — zarówno w pieniądzach, jak i w danych przesyłanych do stron trzecich — jest znany i kontrolowany do centyma.

Nie będziemy podawać nazwy projektu. To nie jest odpowiedni moment, aby to zrobić i nie chcemy zamieniać śledztwa w reklamę. Ale jeśli poprzednie rozdziały pozwoliły Ci rozpoznać sytuację, którą przeżywasz – chatbot firmowy odpowiadający z przekonaniem na błędne pytania, projekt RAG, który nie startuje od miesięcy, rosnący rachunek za chmurę, który rośnie szybciej niż przynoszone korzyści, narastające wątpliwości, czy Twoje poufne dokumenty podróżują w nieznane miejsca – to warto wiedzieć, że istnieje inna droga, którą ktoś w Italii już przebył i która w 2026 roku zaczęła dawać pierwsze odpowiedzi, których oczekiwano w 2023 roku.

Dobra wiadomość jest taka, że AI dla przedsiębiorstw w końcu wychodzi z fazy demonstracyjnej. Ta mniej dobra jest taka, że wychodzi z nią, ciągnąc za sobą wszystkie blizny z podróży: napuchnięte frameworki, zależności od dostawców, monolityczne architektury, brudne dane, ciche błędy i pewną tendencję w branży do sprzedawania rozwiązań, zanim jeszcze zrozumie się problem. Opowiedzieliśmy o tym w sześciu rozdziałach. Siódmy – historia tego, co się dzieje, gdy ktoś w końcu robi wszystko dobrze, z cierpliwością, po włosku i w oprogramowaniu open source – napiszemy wkrótce, z mniejszą ostrożnością w odniesieniu do nazw i większą liczbą danych na stole.

W międzyczasie, jeśli dotarłeś aż tutaj, przeprowadziłeś już więcej analiz niż 90% decydentów, którzy w tym momencie podpisują umowę na firmowego chatbota, nie zadając żadnego z pytań, które zadałeś czytając te rozdziały. To lepszy punkt wyjścia niż ten, z którego wyruszyli oni. A w nadchodzących miesiącach różnica między tymi, którzy zadali sobie te pytania, a tymi, którzy tego nie zrobili, będzie bardzo widoczna na fakturach – i na odpowiedziach, które Twoja AI udzieli Twoim klientom.

Niniejsze dochodzenie zostało sporządzone w kwietniu 2026 roku, w oparciu o osiemnastomiesięczne doświadczenie w projektowaniu, budowie i optymalizacji firmowych systemów RAG od końca 2024 do początku 2026 roku.