Silnik, który miał sześć biegunów — Mit dziesięciu linijek kodu

Śledztwo w sześciu częściach na temat powodów, dla których dokumentacyjny chatbot, który kupiłeś, wciąż wymyśla — oraz o innym kierunku, który ktoś zaczął podążać na początku 2026 roku.

Śledztwo w sześciu częściach na temat powodów, dla których dokumentacyjny chatbot, który kupiłeś, wciąż wymyśla — oraz o innym kierunku, który ktoś zaczął podążać na początku 2026 roku.

Wprowadzenie — Silnik, który miał osiem biegunów (ale miał sześć)

Mediolan, marzec 2026 roku. Manager otwiera firmowego chatbota, tego, który został zamontowany przez dział IT "w dwa tygodnie" z wielkim entuzjazmem i niewielką nieufnością. Zadaje proste pytanie: "Ile biegunów ma silnik CMP40M?" Chatbot odpowiada z całą pewnością, jaką potrafią wykazywać duże modele językowe: "Silnik CMP40M ma osiem biegunów."

Źle. Ma sześć. Prawidłowa odpowiedź nie znajdowała się w katalogu liczącym 422 strony, który ktoś, miesiącami wcześniej, z pełnym zaufaniem umieścił w bazie wektorowej, przekonany, że od tego momentu system "będzie wiedział wszystko". Tej danej po prostu nie było w katalogu. Znajdowała się w pliku PDF załączonym do e-maila od techników SEW, zapisanym w folderze, którego nikt nie raczył zindeksować.

Ta scena, z różnicami w branży i dialekcie, powtarza się w setkach biur we Włoszech. Obietnica była prosta i kusząca: przekaż swojemu asystentowi AI wszystkie dokumenty firmowe, a będzie on mógł odpowiedzieć na każde pytanie na ich temat. Rzeczywistość jest o wiele bardziej prozaiczna: chatbot czyta, ale nie rozumie, szuka, ale nie znajduje, a kiedy czegoś nie znajdzie — zamiast to powiedzieć — wymyśla. Wymyśla płynnie, z perfekcyjną gramatyką, z wiarygodnymi liczbami. A to jest o wiele gorsze niż brak odpowiedzi.

Między końcem 2024 a początkiem 2026 roku spędziliśmy miesiące na przeprowadzaniu sekcji zwłok tych niepowodzeń. Nie po to, aby podsycać kontrowersje, ale aby zrozumieć jedną rzecz: dlaczego tak liniowy pomysł — "daj mu dokumenty, a potem zadawaj pytania" — staje się tak trudny, gdy opuszcza scenę demonstracyjną i wkracza do sali z prawdziwymi serwerami.

To śledztwo w sześciu rozdziałach opowiada o tym, co znaleźliśmy: cichych błędach, które usuwały całe katalogi, chmurnych rerankerach z błędnymi wynikami, halucynacjach powstałych nie z modelu, ale z danych skażonych lata temu, fakturach wychodzących, które sprawiały, że każde zapytanie było droższe niż jego wartość, oraz „popularnych” frameworkach, które obiecują wszystko w dziesięciu linijkach kodu, pod warunkiem, że nie będzie się ich zbyt dużo wymagać. A w ostatnim rozdziale – innym kierunku, który ktoś w ciszy zaczął podążać na początku 2026 roku – architekturze, w której strategia wyszukiwania przestaje być kodem i staje się dokumentem, który każdy w firmie może czytać i modyfikować.

Każdy rozdział jest samodzielny. Jeśli chcesz zacząć od historii 342 znikniętych tabel, albo od historii kłamliwego rerankera, jesteś wolny to zrobić. Ale cała opowieść ma morał, który wyłania się dopiero na końcu: firmowe RAG – ten techniczny akronim, który oznacza Retrieval-Augmented Generation, czyli „generuj odpowiedzi na podstawie dokumentów, które najpierw pobierzesz” – nie jest jeszcze produktem gotowym. To granica. I jak każda granica, do tej pory opowiadali o niej głównie sprzedawcy. Czas posłuchać również tych, którzy żyli w niej od środka.

Rozdział 1 – Mit dziesięciu linijek kodu

Slajd jest identyczny na każdej konferencji poświęconej sztucznej inteligencji od 2023 roku: "Twój firmowy asystent dokumentacji w 10 linijkach kodu." Pod tytułem znajduje się blok kodu Python w pastelowych kolorach, prezentujący bibliotekę open source — zazwyczaj jedną z tych słynnych amerykańskich, której nazwa przywołuje łańcuchy drzew lub tybetańskie lamy — która ładuje pliki PDF, dzieli je na fragmenty, wkleja do bazy danych wektorowych i przeszukuje za pomocą modelu językowego. W pięć minut masz chatbot. W pięć minut, oklaski. W pięć minut, włoska firma średniej wielkości przekonuje się, że problem został rozwiązany i że jej dział IT poradzi sobie z tym w dwa tygodnie.

Problem — tego, czego slajd nie mówi — polega na tym, że demo jest zbudowane z trzech dobrze sformatowanych plików PDF, pytania dopasowanego do treści, sceny bez rzeczywistych opóźnień i prezentera, który przećwiczył to wszystko dwadzieścia siedem razy przed wejściem na scenę. W rzeczywistości, dokumenty firmowe to geologiczna katastrofa: skany skanów, tabele nakładające się na tekst, przypisy wsuwające się w akapity, kody alfanumeryczne typu "RH1M", które fragmentator przecina na pół, myśląc, że to słowa, obrazy, które zawierają siedemdziesiąt procent przydatnych informacji, ale których nikt nie wydobywa, oraz układy tak kreatywne, że wymagają archeologa, a nie parsera.

RAG – to jest idea stojąca za tym rozwiązaniem – to świetny pomysł. Pobierz pytanie użytkownika, wyszukaj w swoim archiwum najbardziej odpowiednie dokumenty, przekaż je do modelu językowego i uzyskaj odpowiedź opartą na tych dokumentach. W teorii, elegancko rozwiązuje problem halucynacji: model nie musi już "wiedzieć" odpowiedzi, musi ją tylko "przeczytać" w fragmentach, które mu dostarczyłeś. W praktyce, każdy element łańcucha – dzielenie na fragmenty, osadzanie, wyszukiwanie, ponowne szeregowanie, ostateczna generacja – ma swoje sposoby na zawiedzenie, a awaria rzadko objawia się jako widoczny błąd. Objawia się jako lekko błędna odpowiedź. Potem jako całkowicie błędna odpowiedź. Potem jako menedżer zastanawiający się, dlaczego płaci za system, który wie mniej niż stażysta.

Frameworki open source, które spopularyzowały RAG, są stworzone do demonstrowania, a nie do produkcji. To eleganckie łańcuchy abstrakcji, w których każda warstwa ukrywa niedopowiedziane założenie: że Twoje pliki PDF mają przyzwoite OCR, że Twoje zdjęcia zostały już opisane, że Twoje tabele przestrzegają konwencji, że model osadzania rzeczywiście mówi Twoim językiem (spoiler: wiele mówi dobrze tylko po angielsku), że Twój archiwum zostało już oczyszczone z duplikatów. Kiedy któreś z tych założeń zawiedzie — a przynajmniej jedno zawiedzie zawsze, prawie zawsze trzy — system nie przestaje działać. Co gorsza: przestaje działać dobrze, ale nadal podaje odpowiedzi. Płynne, pewne i często oderwane od prawdy.

Istnieje zdanie, które krąży wśród osób budujących te systemy zawodowo, a którego nigdy nie znajdziesz w samouczkach: "RAG jest łatwy do zrobienia, ale trudny do zrobienia dobrze." Między pierwszym demo a usługą produkcyjną istnieje przepaść, której nie wypełnisz dodając GPU lub zmieniając model. Wypełnisz ją, rozumiejąc jedną niewygodną rzecz: budując firmowe RAG, nie piszesz kodu. Projektujesz mały, uparty silnik wyszukiwania, skrojony na miarę twoich dokumentów, ze wszystkimi wyborami redakcyjnymi, które to implikuje — co jest szumem, co sygnałem, co należy indeksować dwa razy, a co wyrzucić. Tylko w samouczkach składających się z dziesięciu linijek kodu, te wybory są podejmowane za ciebie, raz, przez kogoś, kto nigdy nie widział twoich dokumentów. I prawie zawsze są to złe wybory dla twojego przypadku.