Duże modele językowe: możliwości i ograniczenia

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 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, 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 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 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 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.