Czym LLM nie jest — ani wyszukiwarką, ani bazą wiedzy, ani programem

przez Łukasz | sie 17, 2026

Większość nieporozumień wokół modeli językowych bierze się nie z tego, czego o nich nie wiemy, ale z tego, co błędnie zakładamy. Że gdzieś sprawdzają. Że coś pamiętają. Że wykonują polecenia.

Nie robią żadnej z tych rzeczy. Robią jedną i tylko jedną — i cała reszta serii jest rozwinięciem tego zdania.

Zacznijmy od analogii, którą zaraz trzeba będzie odstawić

Neuron w mózgu dostaje impuls elektryczny. Nie dostaje światła, dźwięku ani zapachu — te docierają do zmysłów w zupełnie różnej fizycznej postaci, ale zaraz potem zamieniają się na jedną wspólną walutę: aktywność komórek nerwowych. Dalej w mózgu nie ma już „światła”. Jest wzorzec pobudzeń.

Model działa podobnie w tym jednym punkcie. Tekst, obraz i dźwięk wchodzą różnymi drogami, ale po kilku krokach każde z nich jest po prostu listą liczb w tej samej przestrzeni. To dlatego jeden model potrafi obsłużyć kilka rodzajów danych naraz — na poziomie, na którym pracuje, różnica między nimi już nie istnieje.

I na tym analogia się kończy. Warto wiedzieć gdzie dokładnie, bo dalej prowadzi prosto w błąd.

Sztuczny neuron nie strzela. Nie ma impulsu, nie ma progu pobudzenia, nie ma czasu. Zwraca po prostu liczbę — i robi to przy każdym przebiegu, wszystkie naraz, równo. Mózg jest asynchroniczny i oszczędny: w danej chwili milczy zdecydowana większość komórek. Model liczy wszystko, zawsze.

Ważniejsza jest jednak druga różnica. Mózg przepina połączenia w trakcie działania — dlatego zapach potrafi związać się ze wspomnieniem. W modelu wagi są zamrożone po treningu i podczas rozmowy nie zmienia się w nim nic. Zupełnie nic. Wszystko, co wygląda na uczenie się w trakcie rozmowy, jest wyłącznie zawartością okna kontekstu — czyli tekstu, który za każdym razem podajesz od nowa.

Podobieństwo jest więc w reprezentacji, nie w działaniu. To wystarczy, żeby zrozumieć, dlaczego model przetwarza obraz i tekst tak samo. Nie wystarczy do niczego więcej.

Czym LLM nie jest

Nie jest wyszukiwarką

Wyszukiwarka ma indeks. Kiedy pytasz, sprawdza w nim, znajduje dokument i pokazuje ci, skąd wzięła odpowiedź. Zawsze można kliknąć źródło.

Model nie ma indeksu i niczego nie sprawdza. Nie istnieje moment, w którym „idzie zobaczyć”. Odpowiedź powstaje w całości z tego, co zapisało się w wagach podczas treningu, plus z tego, co dostał w kontekście. Kiedy model podaje adres strony, nie odczytuje go z żadnej listy — generuje ciąg znaków, który wygląda jak prawdopodobny adres. Czasem trafia, bo widział go wielokrotnie w danych. Czasem produkuje URL, który nigdy nie istniał, i wygląda on dokładnie tak samo wiarygodnie.

Modele podłączone do wyszukiwania to co innego — ale wyszukiwanie dzieje się wtedy poza modelem, a wynik wraca do niego jako zwykły tekst. Wrócimy do tego w artykule dwunastym.

Nie jest bazą wiedzy

Baza danych przechowuje fakty i zwraca je bez zmian. Zapisujesz „Kowalski, ul. Polna 3″, odczytujesz „Kowalski, ul. Polna 3″. Jeśli rekordu nie ma, baza mówi, że nie ma.

Model nie przechowuje faktów w postaci, w której da się je wskazać. Fakty są rozpuszczone w miliardach wag i nie ma tam żadnego miejsca, o którym można powiedzieć „tu siedzi data bitwy pod Grunwaldem”. Odpowiedzi nie są odczytywane, tylko rekonstruowane przy każdym pytaniu od nowa.

Stąd bierze się druga własność, która zaskakuje najbardziej: model nie ma sygnału „nie wiem”. Baza danych zwraca pusty wynik. Model zawsze ma rozkład prawdopodobieństwa — także wtedy, gdy w danych treningowych nie było żadnej odpowiedzi. Zdanie prawdziwe i zdanie zmyślone powstają dokładnie tą samą drogą, więc z jego perspektywy nie różnią się niczym.

To jest mechaniczna przyczyna halucynacji. Nie usterka, którą ktoś kiedyś załata — konsekwencja tego, jak model jest zbudowany.

Nie jest programem

Program wykonuje instrukcje. Napiszesz „usuń plik”, program usuwa plik. Wynik jest deterministyczny i sprawdzalny.

Model nie wykonuje niczego. Nie ma dostępu do internetu, do plików, do twojej bazy ani do żadnego stanu poza tym, co dostał w kontekście. Kiedy mówimy, że „model wywołał narzędzie”, w rzeczywistości model wygenerował tekst wyglądający jak prośba o wywołanie — nazwę funkcji i argumenty. Ten tekst przechwycił zwykły kod poza modelem, faktycznie odpalił funkcję i wkleił wynik z powrotem do kontekstu jako kolejny fragment tekstu.

Model nigdy się nie dowiaduje, czy cokolwiek naprawdę się wykonało. Widzi tylko, że w kontekście pojawiło się coś nowego.

Prompt nie jest więc poleceniem w sensie programistycznym. Jest kontekstem, który wpływa na rozkład prawdopodobieństwa kolejnych tokenów. Dlatego ta sama instrukcja działa różnie w różnych modelach, dlatego bywa zignorowana, i dlatego nie da się „zaprogramować” modelu tak, by czegoś nigdy nie zrobił.

Czym jest

Jedna operacja. Model dostaje ciąg tokenów i zwraca rozkład prawdopodobieństwa nad całym swoim słownikiem — dla każdej pozycji liczbę mówiącą, jak prawdopodobne jest, że to właśnie ona jest następna. Osobna warstwa wybiera z tego rozkładu jeden token, dokleja go do ciągu, całość wraca na wejście i wszystko powtarza się od nowa.

To wszystko. Odpowiedź, którą czytasz, powstała przez wielokrotne powtórzenie tego kroku — token po tokenie, każdy w osobnym przebiegu. Nazywa się to predykcją następnego tokenu i jest jedyną rzeczą, jaką model robi.

Warto od razu ustawić to sformułowanie odporne na resztę serii. Powiedzenie „tekst wchodzi, tekst wychodzi” jest wygodne, ale prawdziwe tylko dla klasycznego modelu językowego. W modelach multimodalnych na brzegach stoją inne enkodery i dekodery — obraz nie jest zamieniany na opis słowny, tylko od razu na liczby, a na wyjściu osobny dekoder zamienia tokeny w piksele albo w falę dźwiękową. Zmienia się to, co reprezentuje ciąg. Nie zmienia się to, co model z nim robi.

Przy okazji: „language” w nazwie to relikt. Pierwsze duże modele obsługiwały wyłącznie tekst i nazwa przyjęła się wtedy. Dziś większość tych, których używasz, przyjmuje też obraz, a coraz częściej dźwięk. Nazwa została, bo nazwy zostają.

Co z tego wynika w praktyce

Trzy rzeczy, które w codziennej pracy wyglądają na kaprysy modelu, a są konsekwencjami mechanizmu.

Model zmyśla przekonująco. Bo brzmienie wiarygodnie i bycie prawdą to dla niego ten sam proces. Żaden prompt tego nie wyłączy — pomaga dopiero dostarczenie faktów w kontekście i sprawdzenie odpowiedzi poza modelem.

Model nie pamięta. Nie dlatego, że ktoś zapomniał zaimplementować pamięć, tylko dlatego, że wagi są zamrożone i nie ma gdzie niczego zapisać. Historia rozmowy działa wyłącznie dlatego, że interfejs wysyła ją w całości przy każdym pytaniu. To jest przyczyna, dla której pamięć agenta buduje się z zewnątrz — a nie chwilowe ograniczenie.

Model nie sprawdzi własnej odpowiedzi. Pytanie „jesteś pewny?” nie daje wiarygodnego wyniku, bo deklaracja pewności powstaje tym samym mechanizmem co treść, którą ma ocenić. Weryfikacja musi przyjść z zewnątrz.

Wszystkie trzy prowadzą w to samo miejsce: rozwiązania nie mieszkają w modelu, tylko w warstwie nad nim. Jeśli czytałeś Anatomię agenta AI, rozpoznasz w tym opis połowy tamtej serii. Ta seria tłumaczy, dlaczego tamte rozwiązania musiały powstać.

Jak to sprawdzić u siebie

Do tego miejsca nie potrzebowałeś kodu i dalej nie potrzebujesz — poniższe kilkanaście linii jest dla tych, którzy chcą zobaczyć rozkład prawdopodobieństwa na własne oczy.

Większość API zgodnych z formatem OpenAI pozwala poprosić o logarytmy prawdopodobieństw wraz z listą najlepszych kandydatów na każdej pozycji. To dokładnie ten rozkład, o którym mowa wyżej.

python
from openai import OpenAI
import math

client = OpenAI()

r = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "Stolica Polski to"}],
    max_tokens=1,
    logprobs=True,
    top_logprobs=5,
)

for kandydat in r.choices[0].logprobs.content[0].top_logprobs:
    print(f"{kandydat.token!r:15} {math.exp(kandydat.logprob):.1%}")

Zobaczysz pięć kandydatów na jeden token i ich prawdopodobieństwa. Model nie „wie”, że stolicą jest Warszawa — ma rozkład, w którym ta odpowiedź dominuje. Spróbuj teraz zapytać o coś, czego w danych być nie mogło, na przykład o adres e-mail konkretnej osoby. Rozkład nadal będzie, kandydaci nadal będą wyglądać sensownie i nic w wyniku nie zasygnalizuje, że model zgaduje.

To jest halucynacja oglądana od środka, zanim jeszcze zamieni się w zdanie.

Nazwy parametrów różnią się między dostawcami, a część modeli nie udostępnia logprobs w ogóle — jeśli twój ich nie ma, zadziała każdy model otwarty uruchomiony lokalnie.

Co dalej

Skoro model dostaje ciąg tokenów, warto wiedzieć, czym właściwie jest token i skąd się bierze. Okazuje się, że krok, który zamienia twój tekst w liczby, nie jest częścią sieci neuronowej w ogóle — a mimo to decyduje o tym, ile zapłacisz. I że po polsku płacisz więcej.

O tym jest artykuł drugi: Tokenizacja — jak tekst przestaje być tekstem.

Agent kończy, ale zadania nie wykonał

Agent kończy, ale zadania nie wykonał

Objawy Agent odpowiada: „Przygotowałem i wysłałem potwierdzenie do klienta." Potwierdzenie nie zostało wysłane. Albo: „Zaktualizowałem wszystkie rekordy" — zaktualizował trzy z dwunastu. Albo: „Nie znalazłem żadnych zamówień" — bo narzędzie zwróciło błąd, którego nikt...

Agent zrobił coś, o co nikt nie prosił

Agent zrobił coś, o co nikt nie prosił

Objawy Operacja, której nikt nie zlecił. Dane wysłane pod adres, którego nie ma w żadnej konfiguracji. Rekord zmieniony poza zakresem zadania. Odpowiedź, z której wynika, że agent dostał instrukcje od kogoś innego niż ty. Cecha wspólna: technicznie wszystko zadziałało...

Agent zrobił to samo dwa razy

Agent zrobił to samo dwa razy

Objawy Ten syndrom różni się od pozostałych jedną rzeczą: objaw widzi klient, nie ty. Trzy identyczne wiadomości w skrzynce. Dwa zamówienia zamiast jednego. Podwójne obciążenie. Duplikaty rekordów, które ktoś zauważa tydzień później. W twoim dzienniku wszystko wygląda...

Agent gubi wątek w długim zadaniu

Agent gubi wątek w długim zadaniu

Objawy Pierwsze kroki idą wzorowo. Po kilkunastu agent zaczyna się rozjeżdżać. Przestaje przestrzegać reguły z promptu systemowego, której trzymał się na początku. Zmienia format odpowiedzi w połowie zadania. Wraca do czegoś, co już ustalił, i ustala to inaczej....

Agent podaje dane, których nie ma

Agent podaje dane, których nie ma

Objawy Numer zamówienia w idealnym formacie, którego nie ma w bazie. Kwota, której w dokumencie nie ma. Nazwa pola API, które nigdy nie istniało. Cytat z regulaminu, brzmiący dokładnie jak reszta regulaminu i w nim nieobecny. Cecha wspólna wszystkich tych przypadków:...

Działał wczoraj, dziś nie działa

Działał wczoraj, dziś nie działa

Objawy Nic się nie wywala. Nie ma wyjątków, nie ma timeoutów, dziennik wygląda tak samo jak zawsze. Po prostu odpowiedzi są gorsze. Postacie, w jakich to się objawia: Jakość. Agent zaczyna pomijać kroki, które wcześniej wykonywał, albo odpowiada ogólniej. Format....

Agent wybiera złe narzędzie

Agent wybiera złe narzędzie

Objawy Agent odpowiada nie na to pytanie. Pobiera listę zamówień, gdy pytano o jedno konkretne. Odpowiada z pamięci, choć miał sprawdzić w bazie. Albo sięga po właściwe narzędzie i wpisuje w argumenty coś, czego nie da się użyć. Sygnał, który odróżnia ten syndrom od...

Agent kręci się w kółko

Agent kręci się w kółko

Objawy Agent wykonuje kolejne obroty pętli, nie zbliżając się do zakończenia zadania. W dzienniku widać jedną z trzech postaci. Powtórzenie. To samo narzędzie, te same argumenty, raz za razem — czasem dziesiątki razy pod rząd. Oscylacja. Agent wywołuje na przemian dwa...