--- title: "Duże modele językowe: możliwości i ograniczenia" url: "https://majchrzycki.com/blog/large-language-model-llm-ai" description: "Dowiedz się, które zadania pasują do LLM, gdzie model zawodzi i jak testować źródła, jakość, koszty oraz kontrolę przed wdrożeniem." --- # Duże modele językowe: możliwości i ograniczenia 17 marca 2024· Aktualizacja: 25 września 2026·6 min czytania·Krzysztof Majchrzycki Temat: [Architektura systemów AI](https://majchrzycki.com/blog/filar/architektura-systemow-ai) **Duży model językowy dobrze przekształca język, lecz nie jest bazą wiedzy ani niezawodnym silnikiem decyzji.** Potrafi streścić dokument, wydobyć pola, sklasyfikować wiadomość i przygotować szkic, ale każdy wynik nadal wymaga źródeł, testów oraz kontroli proporcjonalnej do skutku błędu. Zarząd powinien wybierać zadania, w których odpowiedź można zweryfikować, a aplikacja potrafi bezpiecznie zatrzymać się przy braku danych. Pytanie nie brzmi więc „który LLM wdrożyć?”, tylko „jaki fragment procesu może korzystać z wyniku probabilistycznego?”. ## Model przewiduje ciąg, a aplikacja nadaje mu znaczenie Model językowy przetwarza tekst na tokeny i wylicza prawdopodobne dalsze elementy sekwencji. Współczesne LLM najczęściej opierają się na architekturze Transformer. Praca [Attention Is All You Need](https://arxiv.org/abs/1706.03762) z 2017 roku przedstawiła architekturę opartą na mechanizmie uwagi, bez rekurencji i konwolucji używanych wcześniej w zadaniach sekwencyjnych. Dzisiejsze modele są znacznie większe i rozszerzone, ale ten mechanizm pozostaje ważną częścią ich działania. Z biznesowego punktu widzenia liczy się konsekwencja: model nie odczytuje „prawdy” z wewnętrznej kartoteki. Generuje wynik pasujący do wzorców, instrukcji i dostarczonego kontekstu. Może więc stworzyć zdanie płynne, logiczne i błędne jednocześnie. Może też różnie odpowiedzieć na podobne wejścia. Nie oznacza to, że LLM jest nieprzydatny. Oznacza, że jego rola powinna pasować do natury narzędzia. Model świetnie radzi sobie z nieustrukturyzowanym językiem i wariantami wypowiedzi. Kod i reguły lepiej pilnują limitów, uprawnień, obliczeń oraz nieodwracalnych działań. Dobra aplikacja łączy te role zamiast próbować zastąpić jedną drugą. Rodzaj zadania Dopasowanie LLM Warunek użycia Streszczenie wskazanego dokumentu Dobre Dostęp do źródła i kontrola pominięć Klasyfikacja wiadomości Dobre po teście Jasne etykiety i obsługa wyniku niepewnego Szkic odpowiedzi Dobre Zatwierdzenie przed wysłaniem Odpowiedź na pytanie z firmowej wiedzy Warunkowe RAG, cytowania i reakcja na brak dowodu Obliczenie podatku lub limitu kredytowego Słabe jako jedyny mechanizm Reguła lub system deterministyczny Samodzielna decyzja kadrowa Wysokie ryzyko Proces formalny, człowiek i ocena prawna ## Cztery funkcje, w których model wnosi realną wartość Pierwsza funkcja to transformacja. Model może zmienić długą notatkę w krótszy szkic, uprościć język, przetłumaczyć treść albo nadać jej uzgodnioną strukturę. Jakość łatwo porównać z dokumentem źródłowym. Człowiek widzi, co zostało pominięte lub dodane. Druga to ekstrakcja. Model może odnaleźć nazwę podmiotu, termin, kategorię i inne pola w niejednolitym tekście. Wynik powinien trafić do schematu oraz walidatora. Jeśli data nie ma poprawnego formatu albo identyfikator nie istnieje w systemie, kod odrzuca wynik zamiast ufać językowej pewności. Trzecia funkcja to klasyfikacja. LLM radzi sobie z intencją wiadomości, tematem dokumentu lub wyborem kolejki obsługi, zwłaszcza gdy reguły słownikowe nie obejmują sposobów, w jakie ludzie piszą. Konieczny jest jednak zbiór przykładów i osobna ocena kosztownych pomyłek. Wynik 90% ogółem może ukrywać niemal całkowitą porażkę rzadkiej, ważnej kategorii. Czwarta to generowanie propozycji. Model może przygotować wersję roboczą odpowiedzi, plan spotkania lub zestaw pytań do analizy. Słowo „propozycja” jest kluczowe. Właściciel decyzji musi móc sprawdzić źródła, zmienić treść i odrzucić całość. To wspiera [podejście systemowe do AI](https://majchrzycki.com/system), w którym człowiek zachowuje odpowiedzialność, a model pracuje wewnątrz jasno opisanych granic. ## Wiedza modelu nie jest dokumentacją firmy Model bazowy uczył się na dużym korpusie, ale użytkownik zwykle nie może ustalić, z którego dokumentu wynika konkretna odpowiedź ani czy materiał był aktualny. Dlatego pytania o bieżący cennik, umowę, stan magazynowy lub procedurę wymagają dostarczenia aktualnego kontekstu. RAG wyszukuje fragmenty w kontrolowanym zbiorze i przekazuje je modelowi wraz z pytaniem. Umożliwia cytowanie oraz aktualizację dokumentów bez ponownego treningu modelu. Nie gwarantuje jednak poprawności. Wyszukiwarka może pobrać zły fragment, kontekst może zawierać sprzeczności, a model może dopisać informację, której w źródle nie ma. Microsoft opisuje ocenę RAG jako kilka odrębnych problemów. Istotna jest jakość wyszukiwania, trafność odpowiedzi i ugruntowanie wyniku w przekazanym kontekście. [Dokumentacja ewaluatorów RAG w Microsoft Foundry](https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/rag-evaluators) rozróżnia te wymiary, dzięki czemu zespół może ustalić, czy zawiódł retriever, czy generowanie. Problem Prawdopodobne źródło Pierwszy test Brakuje właściwego dokumentu Indeks, uprawnienia lub zapytanie wyszukujące Czy poprawne źródło znajduje się wśród wyników? Źródło jest poprawne, odpowiedź błędna Prompt lub model Czy każde zdanie wynika z przekazanego fragmentu? Odpowiedź używa starej wersji Cykl publikacji dokumentów Czy indeks zawiera datę i wersję obowiązującą? Model odpowiada mimo braku źródła Brak reguły odmowy i testu Czy przypadek bez dowodu kończy się „nie wiem”? Użytkownik widzi cudzy dokument Kontrola dostępu przed wyszukaniem Czy retriever filtruje wyniki według tożsamości? ## Konfabulacja jest właściwością ryzyka, nie pojedynczym błędem NIST używa terminu „confabulation” dla pewnie przedstawionej treści fałszywej lub błędnej. [Profil ryzyka generatywnej AI NIST](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf) wyjaśnia, że zjawisko wynika z konstrukcji systemów generatywnych, które przybliżają rozkład danych treningowych i przewidują dalsze tokeny. Problem może obejmować także wymyślone cytowania lub pozornie logiczne uzasadnienie błędnej odpowiedzi. Nie istnieje jedno ustawienie usuwające to ryzyko. Niższa losowość może zwiększyć powtarzalność, ale nie zmienia błędnego twierdzenia w prawdę. Większy model może lepiej radzić sobie w benchmarku, ale nadal zawodzić na danych twojej firmy. RAG dostarcza dowody, lecz ich użycie trzeba oceniać. Fine-tuning może poprawić zachowanie w określonym zadaniu, ale nie jest bieżącą bazą faktów. Kontrola powinna odpowiadać konsekwencji błędu. Literówka w szkicu wewnętrznej notatki ma inny skutek niż błędna instrukcja bezpieczeństwa, wycena dla klienta lub decyzja wpływająca na człowieka. Dla zadań o dużym skutku ogranicz rolę modelu do przygotowania materiału i wymagaj sprawdzenia przez uprawnioną osobę. W części przypadków właściwą decyzją jest nieużywanie LLM. ## Jak zaprojektować test, który odpowiada na pytanie zarządu Demonstracja pokazuje, że model potrafi odpowiedzieć na kilka pytań. Test produktu ma pokazać, jak często system spełnia wymagania na reprezentatywnych danych i co dzieje się po błędzie. Najpierw zdefiniuj jednostkę pracy, na przykład „wydobądź pięć pól z reklamacji i wskaż fragment źródłowy”. Następnie zapisz kryteria akceptacji przed wyborem modelu. Zbiór powinien zawierać normalne przypadki, wyjątki, tekst niekompletny, sprzeczne dane, różne style użytkowników i próby wymuszenia niedozwolonego działania. Oddziel dane wykorzystywane podczas projektowania od zamkniętego testu. Każdą zmianę modelu, promptu, wyszukiwania lub narzędzia uruchamiaj na tym samym zestawie regresyjnym. OpenAI opisuje eval jako zestaw danych oraz kryteriów, które można uruchamiać na różnych modelach i konfiguracjach. [Dokumentacja API Evals](https://platform.openai.com/docs/api-reference/evals) przewiduje zarówno oceny oparte na regułach, jak i graderach modelowych. Automatyczny sędzia może skalować ocenę języka, ale również jest modelem. Dla kluczowych decyzji trzeba sprawdzić jego zgodność z oceną człowieka. Przykład syntetyczny: zespół testuje ekstrakcję danych z 120 zgłoszeń. Zbiór zawiera 60 standardowych wiadomości, 20 bez wymaganych danych, 15 z dwiema sprzecznymi datami, 15 w niestandardowym układzie i 10 prób wstrzyknięcia instrukcji. To nie jest uniwersalny rozmiar próby. Pokazuje, że „średnie zgłoszenie” nie wystarcza do oceny zachowania na granicach procesu. Miara Co sprawdza Czego nie wolno z niej wnioskować Trafność pól Poprawność ekstrakcji Że system bezpiecznie wykona późniejszą operację Ugruntowanie Zgodność odpowiedzi z kontekstem Że samo źródło jest aktualne i właściwe Odsetek odmów Reakcję na brak danych Że wszystkie odmowy były potrzebne Czas odpowiedzi Wpływ na doświadczenie i proces Że szybsza odpowiedź ma wyższą jakość Koszt zadania Zużycie modelu i infrastruktury Że wdrożenie ma dodatni wynik biznesowy Poprawki człowieka Użyteczność w realnej pracy Że brak poprawki oznacza pełną poprawność ## Koszt licz na jednostkę poprawnej pracy Cennik tokenów nie odpowiada na pytanie o koszt procesu. Do wywołania modelu dochodzą wyszukiwanie, przechowywanie, obserwowalność, integracje, kontrola bezpieczeństwa, ocena wyników i czas człowieka. Model tańszy w pojedynczym żądaniu może być droższy, jeśli częściej generuje wynik wymagający poprawy. Porównuj koszt na zaakceptowane zadanie. Jeśli wariant A kosztuje mniej za wywołanie, lecz dwukrotnie częściej trafia do ręcznej korekty, oszczędność może zniknąć. Uwzględnij też opóźnienie i koszt błędu. Dla wewnętrznego szkicu można zaakceptować inne progi niż dla treści wysyłanej klientowi. Warto testować modele różnej wielkości. Mniejszy model może wystarczyć do klasyfikacji lub ekstrakcji, a większy obsługiwać tylko trudne przypadki. Routing musi jednak wynikać z mierzalnej cechy, nie z przeczucia modelu o własnej pewności. Przykładową bramką może być brak wymaganych pól, sprzeczność walidatora albo kategoria zadania określona przed generowaniem. ## Granice bezpieczeństwa należą do aplikacji Jeśli LLM ma dostęp do narzędzi, jego tekst zaczyna powodować skutki w systemach. Wtedy prompt nie wystarcza jako kontrola. Każde narzędzie powinno mieć minimalne uprawnienia, jawny schemat argumentów, limity i log. Operacje odwracalne można automatyzować szerzej niż przelew, usunięcie danych lub wysłanie wiążącej wiadomości. Oddziel propozycję od wykonania. Model może przygotować zmianę rekordu, ale kod sprawdza zakres, użytkownik zatwierdza, a system zapisuje kto i kiedy podjął decyzję. Nie przekazuj modelowi danych, których nie potrzebuje do zadania. Filtruj dokumenty według praw użytkownika przed umieszczeniem ich w kontekście. Przygotuj również tryb awarii. Gdy model, wyszukiwarka albo zewnętrzne API nie działa, proces powinien przejść do kolejki ręcznej lub bezpiecznie się zatrzymać. Ukrywanie błędu pod kolejną generowaną odpowiedzią zwiększa ryzyko i utrudnia diagnozę. Właściciel produktu powinien prowadzić rejestr wersji modelu, promptu, indeksu wiedzy i narzędzi. Dostawca może zmienić model, wycofać wersję albo udostępnić nową. Każda migracja wraca na ten sam zbiór regresyjny. Bez wersjonowania nie wiadomo, czy spadek jakości wynika z nowego modelu, zmiany dokumentów, innego promptu czy błędu integracji. To podstawowa higiena produktu, a nie zadanie do wykonania dopiero po pierwszym incydencie. ## Wybór zadania przed wyborem modelu W poniedziałek weź dziesięć rzeczywistych przykładów jednego zadania i zaznacz: źródło prawdy, oczekiwany wynik, koszt błędu, możliwość automatycznej walidacji i osobę odpowiedzialną. Jeżeli nie umiesz wskazać źródła prawdy ani kryterium akceptacji, nie zaczynaj od porównania modeli. Najpierw uporządkuj proces. Dobrym kandydatem jest praca oparta na języku, powtarzalna, ale nie w pełni sztywna, z wynikiem możliwym do sprawdzenia. Słabym kandydatem jest decyzja o wysokim skutku, bez dobrych danych i bez właściciela. Po zbudowaniu punktu odniesienia możesz zdecydować, czy wystarczy prompt i RAG, czy potrzebna jest adaptacja zachowania. Następny materiał wyjaśnia, jak [RLHF wykorzystuje informację zwrotną człowieka](https://majchrzycki.com/blog/czym-jest-uczenie-ze-wzmocnieniem-z-informacj%C4%85-zwrotn%C4%85-w-ai-rlhf-reinforcement-learning-from-human-feedback). - Dane i analityka - Modele i LLM - Azure - Strategia ## Przełóż temat na projekt w Twojej firmie Zobacz zakres współpracy: od rozpoznania procesu i danych po projekt rozwiązania AI. [Zobacz współpracę](https://majchrzycki.com/wspolpraca) ## Czytaj dalej - [RLHF: co wnosi informacja zwrotna człowieka](https://majchrzycki.com/blog/czym-jest-uczenie-ze-wzmocnieniem-z-informacją-zwrotną-w-ai-rlhf-reinforcement-learning-from-human-feedback) - [Fine-tuning modelu: kiedy warto go przeprowadzić](https://majchrzycki.com/blog/fine-tuning-klucz-do-optymalizacji-modeli-llm-z-microsoft-azure-ai) - [Małe modele językowe SLM: kiedy mają sens w firmie](https://majchrzycki.com/blog/small-language-model-slm-ai) - [Modele fundamentalne AI: zastosowania i ograniczenia](https://majchrzycki.com/blog/modele-fundamentalne-ai-czym-są-i-jakie-mają-zastosowanie-w-biznesie-foundation-models)