Co to jest LLM: podstawy dla agentów AI

Co oznacza „LLM jako silnik rozumowania”?

Agent AI to coś więcej niż chatbot: realizuje cel w wielu krokach, wywołuje narzędzia, obserwuje wyniki i decyduje, co zrobić dalej. W centrum tej pętli znajduje się duży model językowy (LLM) pełniący rolę silnika rozumowania, czyli instancji, która planuje, waży opcje, wybiera narzędzia i interpretuje wyniki.

Metafora, która mocno ukształtowała praktykę, pochodzi od Andreja Karpathy'ego (czerwiec 2025): LLM to CPU, okno kontekstowe to pamięć operacyjna (RAM), a inżynier pełni rolę systemu operacyjnego, który na każdym kroku wypełnia tę pamięć właściwymi informacjami. Stąd kluczowy wniosek na 2026 rok: agenci w środowisku produkcyjnym prawie nigdy nie zawodzą dlatego, że model jest „za mały”. Zawodzą, bo kontekst jest źle skonstruowany. Zespół Applied AI w Anthropic opisuje Context Engineering jako naturalną ewolucję prompt engineeringu: dobór tokenów, które trafiają do ograniczonego okna kontekstowego. Od tego doboru zależy, czy agent działa niezawodnie.

Jeśli budujesz agentów, potrzebujesz więc solidnych podstaw w czterech obszarach: tokeny, okno kontekstowe, Function Calling oraz wybór modelu (open source czy model własnościowy). Ta strona przeglądowa zbiera podstawy; tematy pogłębione (Context Engineering, RAG, FinOps, zgodność z przepisami) mają osobne moduły.

Tokeny: jednostka przetwarzania i kosztów

Modele LLM nie przetwarzają tekstu jako słów, lecz jako tokeny, czyli jednostki podsłowne, które tokenizer tworzy z tekstu. Tokeny są jednocześnie jednostką rozliczeniową: dostawcy naliczają opłaty osobno za tokeny wejściowe i wyjściowe, zwykle za milion tokenów.

W regionie DACH (Niemcy, Austria, Szwajcaria) tokenizacja nie jest tematem pobocznym, lecz mierzalnym czynnikiem kosztowym. W popularnych tokenizerach BPE język niemiecki generuje o 30-50% więcej tokenów niż angielski przy równoważnej treści. Przyczyny:

• Rzeczowniki złożone: „Lebensversicherungsgesellschaftsangestellter” rozpada się na długi łańcuch podsłów, podczas gdy „life insurance company employee” dzieli się na znajome tokeny odpowiadające całym słowom.
• Fleksja: niemieckie końcówki przypadków i czasowników tworzą warianty morfologiczne, które są ujmowane jako osobne podsłowa.
• Stronniczość tokenizera: dane treningowe popularnych tokenizerów są zdominowane przez angielski; rzadkie niemieckie podsłowa są dzielone drobniej.

Wynikają z tego trzy praktyczne konsekwencje. Po pierwsze, efektywne okna kontekstowe mieszczą mniej treści (w oknie 200K zmieści się tylko tyle niemieckiej treści, ile po angielsku zajęłoby ok. 130K-150K tokenów). Po drugie, koszty jednego wywołania są odpowiednio o 30-50% wyższe. Po trzecie, prompt caching opłaca się przy obciążeniach DACH jeszcze bardziej niż przy angielskich, bo rabat dotyczy większej liczby tokenów.

Ważna uwaga dotycząca migracji modeli: Claude Opus 4.7 trafił na rynek z nowym tokenizerem, który dla wielu danych wejściowych generuje nawet o 35% więcej tokenów niż Opus 4.6; przy identycznych cenach za token efektywny koszt jednego zapytania może więc wzrosnąć wyłącznie przez zmianę tokenizera. Przed każdą migracją zrób benchmark na własnym profilu obciążenia.

Okno kontekstowe: nominalne a efektywne

Okno kontekstowe to maksymalna liczba tokenów, jaką model może „zobaczyć” w jednym zapytaniu, czyli łącznie prompt systemowy, definicje narzędzi, pobrane treści, historia rozmowy i miejsce na odpowiedź. W 2026 roku nominalnie duże okna są standardem: Claude Opus 4.7 i Sonnet 4.6 obsługują 1M tokenów, a Gemini 3.1 Pro również ok. 1M.

Kluczowe jest jednak to, że pojemność nominalna to nie to samo co efektywna. Badanie „Context Rot” firmy Chroma (lipiec 2025, 18 modeli frontier) empirycznie wykazało, że wszystkie modele tracą na jakości wraz ze wzrostem długości wejścia. Wzajemnie wzmacniają się trzy mechanizmy:

1. Lost-in-the-Middle: modele zwracają większą uwagę na początek i koniec kontekstu, mniejszą na środek.
2. Rozmycie uwagi: kwadratowa złożoność mechanizmu uwagi oznacza, że przy 100K tokenów występuje już ok. 10 miliardów relacji między parami.
3. Interferencja dystraktorów: semantycznie podobne, ale nieistotne treści aktywnie prowadzą do błędnych odpowiedzi.

Wynik zależy od zadania: w prostym wyszukiwaniu faktów nowsze modele wyraźnie nadrobiły zaległości, ale w rozumowaniu wieloetapowym (multi-hop) efekt pozostaje strukturalny. Heurystyka dla produkcji: efektywna pojemność robocza wynosi 30-50% nominalnej w zadaniach opartych na rozumowaniu i 60-80% w zadaniach opartych na wyszukiwaniu. Jeśli całkowicie wypełniasz okno 1M, marnujesz zasoby i do tego tracisz na jakości.

Praktyczną odpowiedzią na context rot nie jest „upychanie więcej”, lecz selekcja: cache'owanie stabilnych elementów, celowe ładowanie treści dynamicznych, przycinanie starych treści i kompresja przy zapełnieniu na poziomie 70-85% (compaction). Tym zajmuje się moduł Context Engineering.

Function Calling i tool use: LLM jako aktor

Aby LLM stał się silnikiem agenta, musi umieć działać, czyli generować ustrukturyzowane wywołania funkcji zewnętrznych. Służy do tego Function Calling (także: tool use): model otrzymuje definicje narzędzi w formacie JSON Schema i w razie potrzeby zwraca ustrukturyzowane wywołanie z parametrami, które wykonuje aplikacja.

Najważniejszy wniosek z praktyki w 2026 roku: gdy agent działa błędnie, przyczyna zwykle nie leży w modelu, lecz w definicji narzędzia. Anthropic formułuje tę zasadę dobitnie: jeśli inżynier-człowiek nie potrafi jednoznacznie wskazać, którego narzędzia użyć w danej sytuacji, agent też tego nie potrafi. Konkretne konsekwencje:

• Liczba narzędzi: optymalnie 3-7 aktywnie załadowanych narzędzi; od ok. 10 narzędzi zaczyna się mierzalna degradacja. W wewnętrznych ewaluacjach MCP firmy Anthropic trafność wyboru narzędzi przy dynamicznym wyszukiwaniu narzędzi wzrosła z 49% do 74% (Opus 4) oraz z 79,5% do 88,1% (Opus 4.5).
• Nakładanie się narzędzi jest zabójcze: dwa narzędzia, które mogłyby wiarygodnie obsłużyć to samo zapytanie, to jedyny problem, którego nie rozwiąże nawet najlepszy prompt. Wyraźna klauzula „kiedy nie używać” w opisie to najskuteczniejszy i często pomijany element.
• Ustrukturyzowane wyniki: systemy przetwarzające je dalej potrzebują wyników niezawodnie czytelnych maszynowo. OpenAI Structured Outputs (ogólnie dostępne od sierpnia 2024) osiąga dzięki constrained decoding 100% zgodności ze schematem; Anthropic osiąga to samo przez tool use z JSON Schema, a modele open-weight przez grammar-constrained decoding (Outlines, jsonformer, vLLM).

Standardem podłączania narzędzi jest w 2026 roku Model Context Protocol (MCP), opublikowany przez Anthropic w listopadzie 2024 jako standard oparty na JSON-RPC. Według raportów branżowych liczba pobrań SDK wzrosła z ~100 000 miesięcznie (listopad 2024) do ~97 mln miesięcznie (marzec 2026), a protokół przyjęły OpenAI, Google i Microsoft. (Te liczby pobrań pochodzą z raportów dostawców i branży i nie zostały niezależnie zweryfikowane; sam wzorzec adopcji uchodzi za bezsporny.) Do oceny jakości tool callingu najważniejszym benchmarkiem pozostaje Berkeley Function-Calling Leaderboard (BFCL), z zastrzeżeniem, że żaden model nie prowadzi we wszystkich kategoriach, a modele closed-weight wciąż wygrywają w złożonym, wieloturowym tool use.

Open source czy model własnościowy: wybór modelu

Wybór modelu bazowego to decyzja o najdalej idących konsekwencjach strategicznych. W 2026 roku nie jest to już kwestia zero-jedynkowa, lecz alokacja portfela. Najpierw wyjaśnienie pojęć, bo „otwarty” ma kilka wymiarów:

• Zamknięte/własnościowe: wyłącznie przez API, wagi niedostępne (Claude, GPT-5.5, Gemini).
• Open-weight: wagi do pobrania, czasem na restrykcyjnych licencjach. Llama jest modelem open-weight, ale OSI i FSF wyraźnie nie klasyfikują go jako open source, m.in. z powodu progu 700 mln MAU i ograniczenia multimodalnego dla UE w Llama 4.
• Open Source AI według definicji OSI (OSAID 1.0, październik 2024): wymaga dodatkowo otwartego kodu treningu i inferencji oraz wystarczającej przejrzystości danych treningowych. Większość modeli sprzedawanych jako „open source” nie spełnia tego progu.

Kluczowy trend: luka możliwości między najlepszymi modelami open-weight (DeepSeek V4 Pro, Kimi K2.6, Mistral Large 3, Qwen 3.6, Llama 4 Maverick) a zamkniętymi modelami frontier (stan na maj 2026: Claude Opus 4.7, GPT-5.5 Pro, Gemini 3.1 Pro) zmniejszyła się z 12-18 miesięcy (2024) do 3-6 miesięcy (2026). Przy niektórych standardowych obciążeniach, takich jak rutynowe programowanie czy zadania matematyczne poniżej poziomu frontier, jest praktycznie zerowa. Kimi K2.6 (1 bln parametrów, open-weight) zajmuje w Artificial Analysis Intelligence Index 4. miejsce (wynik 54), tuż za Anthropic, Google i OpenAI (po 57).

Jednocześnie w obciążeniach premium (programowanie agentowe na najwyższym poziomie, matematyka frontier, długi kontekst, multimodalność premium) zamknięte modele frontier pozostają realnie lepsze. W wielu firmach do tej kategorii premium trafia tylko niewielka część wolumenu tokenów, ale duża część wartości strategicznej. Podejście hybrydowe staje się więc ekonomiczną koniecznością.

Ceny według publicznych cenników dostawców, stan na kwiecień-maj 2026; przed każdym wieloletnim zobowiązaniem sprawdź je ponownie.

Trzeźwa logika decyzyjna opiera się na czterech wymiarach: kontrola nad wagami (kto może dostarczyć model, kiedy i na jakich warunkach?), suwerenność hostingu (jakiej jurysdykcji podlega stack?), ścieżka dostosowania (gotowe rozwiązanie, prompt, RAG, LoRA, pełny fine-tuning) i profil kosztów (płatność za token czy amortyzacja self-hostingu). W przypadku większości standardowych obciążeń (klasyfikacja, ekstrakcja, asystenci wiedzy oparci na RAG, workflowy w języku niemieckim) premia za zamknięte modele frontier nie jest już ekonomicznie konieczna.

Kontekst DACH: suwerenność i zgodność z przepisami

W regionie DACH na wybór modelu wpływają dodatkowo trzy czynniki. Po pierwsze, nastroje wokół suwerenności: według Bitkom (badanie Digitale Souveränität 2025, 603 firmy) 89% importerów technologii cyfrowych uważa się za zależnych; w badaniu ludności (tygodnie 8-11/2026) 72% uważa, że Niemcy są w kwestii AI zbyt zależne od USA, a 67% chętnie korzystałoby z niemieckiej AI. Komercyjnie wiarygodną suwerenną opcję europejską oferuje Mistral. Druga może powstać z Cohere i Aleph Alpha: obie firmy przypieczętowały umową we wrześniu 2026 połączenie ogłoszone w kwietniu 2026. W chwili ogłoszenia wycena wynosiła według doniesień prasowych ok. 20 mld USD. Moc obliczeniową ma dostarczać Schwarz Gruppe za pośrednictwem STACKIT. We wrześniu 2026 zamknięcie transakcji wciąż wymagało zgód organów regulacyjnych. Połączona firma ma działać pod nazwą Cohere z podwójną siedzibą w Toronto i Berlinie. To zatem opcja kanadyjsko-niemiecka, a nie czysto europejska.

Po drugie, region UE u amerykańskiego hiperskalera (np. Claude w AWS Bedrock we Frankfurcie) zmniejsza opóźnienia i tarcia związane z RODO, ale nie eliminuje jurysdykcji USA (CLOUD Act). Prawdziwa suwerenność wymaga suwerennego europejskiego stacku (STACKIT, OVHcloud, T-Systems, IONOS) lub rozwiązania on-premise.

Po trzecie, warto znać uwarunkowania regulacyjne (informacyjnie, nie stanowi to porady prawnej): modele dostępne przez zamknięte API są modelami AI ogólnego przeznaczenia (GPAI) swoich dostawców; podmiot stosujący z UE ponosi obowiązki podmiotu stosującego. Jeśli robisz istotny fine-tuning modelu open-weight, możesz sam stać się dostawcą GPAI; wytyczne Urzędu ds. AI UE (lipiec 2025) wskazują orientacyjny, niewiążący próg >1/3 mocy obliczeniowej pretreningu modelu bazowego (domyślnie 3,33 × 10²² FLOPs, jeśli jest nieznana). LoRA/QLoRA zwykle mieszczą się wyraźnie poniżej, continued pretraining powyżej. Obowiązki dostawców GPAI mają zastosowanie od 2 sierpnia 2025. Od 2 sierpnia 2026 Komisja Europejska (Urząd ds. AI) może je też egzekwować za pomocą kar pieniężnych (art. 101 i art. 113 AI Act). Do tego dochodzą obowiązki wynikające z RODO dotyczące pipeline'u treningowego przy fine-tuningu na danych osobowych. Te kwestie szczegółowo omawiają odpowiednie moduły poświęcone zgodności.

Perspektywy i wskazówka praktyczna

Podstawy LLM to nie jednorazowa lekcja, lecz ruchomy cel: tokenizery się zmieniają, okna kontekstowe rosną, nowe modele pojawiają się co miesiąc, a wyniki benchmarków wahają się o 5-10 punktów procentowych w zależności od test harnessu. Na lata 2026/2027 szczególnie warte obserwacji są trzy otwarte pytania: czy luka możliwości między modelami otwartymi a zamkniętymi będzie się dalej zmniejszać, czy długie okna kontekstowe spełnią obietnicę „wrzuć wszystko” (obecnie: nie, Context Engineering nadal jest potrzebny) i czy suwerenna infrastruktura europejska osiągnie parytet skali z amerykańskimi hiperskalerami.

W praktyce obowiązuje więc prosta dyscyplina: nie wybieraj na podstawie marketingowego wpisu na blogu, tylko mierz na własnym zestawie ewaluacyjnym. Jeśli wybór modelu, budżet kontekstu i projekt narzędzi weryfikujesz na rzeczywistych śladach wykonania, a nie intuicyjnie, budujesz agentów, którzy sprawdzają się w środowisku produkcyjnym, i zachowujesz strategiczną elastyczność, by przy zmianach cen, licencji lub możliwości zmienić dostawcę bez zaczynania od zera.