Czym jest LLM i jak wybrać model do firmy
LLM przewiduje kolejne tokeny na podstawie kontekstu. Poznaj sześć kryteriów doboru modelu do zadania, danych i budżetu — bez szybko starzejących się rankingów.

LLM (large language model, duży model językowy) generuje tekst przez przewidywanie kolejnych tokenów na podstawie kontekstu. To wyjaśnia, dlaczego potrafi tworzyć spójne odpowiedzi, ale nie stanowi samodzielnego mechanizmu sprawdzania prawdy. Tak ryzyko konfabulacji opisuje profil generatywnej AI przygotowany przez NIST.
Świadomie nie znajdziesz tu rankingu „najlepszych modeli”. Pozycje w rankingach potrafią zmieniać się szybko, natomiast kryteria wyboru — jakość na własnym zadaniu, koszt, opóźnienie, warunki danych i możliwość utrzymania — są stabilniejszym punktem odniesienia.
Co LLM potrafi, a czego nie potrafi z definicji
Dobrze pasuje do: przekształcania tekstu (streszczenie, tłumaczenie, zmiana formatu), klasyfikacji, wyciągania danych z nieustrukturyzowanego tekstu, generowania szkiców i tłumaczenia pytania na zapytanie do systemu — po sprawdzeniu jakości na realnych przykładach.
Nie daje z natury gwarancji: poprawności faktów i obliczeń, znajomości Twoich danych bez dostarczenia kontekstu ani identycznego wyniku w każdym przebiegu. Takie wymagania trzeba zabezpieczyć kodem, źródłami i ewaluacją.
Ten podział ma bezpośrednią konsekwencję projektową: model może interpretować język, a reguły i obliczenia powinny pozostać w kontrolowanym kodzie. Wyliczenie rabatu robi kod. Model może rozpoznać, o jaki rabat pyta klient w mailu, a wynik kierujemy do walidacji odpowiedniej do kosztu błędu.
Sześć kryteriów doboru modelu
1. Trudność zadania, nie prestiż modelu
Klasyfikacja maila do jednej z pięciu kategorii często nie wymaga najmocniejszego modelu na rynku. Analiza umowy z wyłapaniem sprzeczności może wymagać modelu o większych możliwościach, ale rozstrzyga to test na reprezentatywnych dokumentach. Dobór modelu „na zapas” podnosi koszt bez gwarancji lepszego wyniku.
Praktyczna reguła: zacznij od modelu mniejszego i taniego, zmierz jakość na własnym zestawie przykładów, podnoś tylko jeśli nie wystarcza. Nie odwrotnie.
2. Koszt na jednostkę pracy, nie cena za milion tokenów
Cennik podaje koszt za tokeny. Ciebie interesuje koszt jednego przetworzonego zgłoszenia albo jednego wygenerowanego opisu. Te dwie liczby mogą się mocno różnić, gdy w kontekst wchodzi dużo dokumentów — wtedy znaczną część kosztu może stanowić materiał podany modelowi na wejściu.
Dlatego przed zmianą modelu warto zmierzyć także kontekst pobierany przez RAG. Krótszy, trafny materiał może jednocześnie obniżyć koszt wejścia i ograniczyć szum, ale efekt trzeba sprawdzić na własnym zestawie pytań.
3. Wielkość okna kontekstu
Ile tekstu model przyjmie naraz. Duże okno upraszcza niektóre scenariusze, ale nie zwalnia z selekcji materiału: niepotrzebne fragmenty podnoszą koszt i mogą utrudnić odróżnienie właściwej podstawy odpowiedzi.
4. Opóźnienie
W interaktywnym czacie odbiorca zwykle oczekuje krótkiego czasu odpowiedzi, podczas gdy nocne przetwarzanie dokumentów może mieć znacznie luźniejszy limit. To inne wymagania wobec modelu i architektury; dostawcy mogą też oferować osobne, tańsze tryby wsadowe, co trzeba potwierdzić w aktualnym cenniku.
5. Miejsce przetwarzania danych
Model w chmurze dostawcy, model w wybranym regionie, model na własnej infrastrukturze. To decyzja o zgodności, ryzyku i odpowiedzialności operacyjnej, nie wyłącznie o technologii. Sprawdź cel i retencję danych, lokalizację przetwarzania, podwykonawców, warunki umowy, uprawnienia oraz procedurę incydentową.
6. Możliwość wymiany
Warstwa integracyjna powinna ograniczać zależność logiki biznesowej od jednego interfejsu modelu. Adapter może zmniejszyć zakres zmian przy wymianie dostawcy, lecz nie usuwa ponownej ewaluacji jakości, bezpieczeństwa, limitów i formatów odpowiedzi.
Model przez API czy z otwartymi wagami?
| Model udostępniany przez API | Model z otwartymi wagami na własnej infrastrukturze | |
|---|---|---|
| Czas do pierwszego efektu | często krótszy, bo infrastruktura jest gotowa | często dłuższy przez wdrożenie i utrzymanie infrastruktury |
| Koszt przy małej skali | często niższy | może być wyższy przez stały koszt infrastruktury |
| Koszt przy dużej, stałej skali | rośnie z użyciem | może być niższy |
| Kontrola nad danymi | zależna od umowy i konfiguracji | większa, ale wymaga własnych zabezpieczeń |
| Praca własna | integracja | integracja plus utrzymanie infrastruktury |
Przy braku szczególnych ograniczeń API jest użytecznym punktem startu do pomiaru jakości, użycia i kosztu. Własną infrastrukturę warto rozważyć wcześniej, gdy wynika to z wymagań zgodności, kontroli danych, opóźnienia albo policzalnej stałej skali. „Otwarte wagi” nie zawsze oznaczają dowolność użycia — trzeba sprawdzić licencję konkretnego modelu. Decyzję o sposobie przetwarzania podejmij przed użyciem danych produkcyjnych, nie dopiero po pilotażu.
Czego nie rekomendujemy firmom z naszego profilu klientów: trenowania modelu od zera. Zwykle nie uzasadniają tego ani skala danych, ani budżet; tańszy test to gotowy model połączony z własnymi danymi i pomiarem jakości.
Jak w ogóle zmierzyć, czy model jest dobry dla nas
Publiczne rankingi mówią o zadaniach ogólnych, nie o Twoich. Minimalna wersja własnego pomiaru:
- Zbierz na start 20–50 zróżnicowanych, realnych przykładów ze swojego procesu, także przypadki trudne i takie, których system nie powinien obsłużyć. To próba przesiewowa, a nie uniwersalna liczba wystarczająca do wdrożenia.
- Uruchom na nich dwa lub trzy modele i policz, ile razy wynik jest poprawny.
- Zapisz też koszt i czas jednego przebiegu.
- Ten zestaw zostaje na stałe i uruchamiasz go po każdej zmianie modelu albo promptu.
Taki mały zestaw nie zastępuje pełnej ewaluacji, ale jest lepszym filtrem zakupowym niż sam ranking ogólny. Gdy rozwiązanie wchodzi na produkcję, zestaw trzeba rozszerzać o błędy i nowe przypadki z rzeczywistego użycia.
Kiedy LLM to zły wybór
- Gdy wymagana jest powtarzalność co do znaku. Faktura, przelew, wyliczenie zobowiązania. Kod, nie model.
- Gdy dane wejściowe są już ustrukturyzowane. Jeśli masz porządną bazę, zapytanie do bazy jest szybsze, tańsze i pewniejsze.
- Gdy nie ma jak sprawdzić wyniku. Zadanie, w którym nikt nie umie ocenić, czy odpowiedź jest dobra, nie nadaje się na wdrożenie — bo nie zauważysz, kiedy przestanie działać.
Najczęstsze pytania
Czy większy model zawsze jest lepszy?
Nie. Większy model może osiągać lepszy wynik w części trudnych zadań, ale nie ma gwarancji przewagi na Twoim procesie, a koszt i opóźnienie mogą być wyższe. Porównaj kandydatów na tym samym zestawie przypadków i wybierz najmniejszy model spełniający ustalone kryterium jakości.
Jak często trzeba zmieniać model?
Nie ma stałego kalendarza wymiany. Nowy model warto ocenić, gdy obecny nie spełnia jakości, kosztu, opóźnienia lub wymagań dostawcy. Adapter skraca część pracy technicznej, ale czas decyzji zależy od ponownej ewaluacji i kontroli zgodności. Ten wpis przeglądamy kwartalnie.
Czy da się używać kilku modeli naraz?
Tak. Tańszy model może obsługiwać rutynowe przypadki, a droższy tylko sprawy przekraczające ustalony próg. Routing zwiększa jednak złożoność, więc opłaca się dopiero wtedy, gdy pomiar oszczędności i jakości uzasadnia dodatkowe reguły, testy oraz monitoring.
Dobieramy model pod zadanie i budżet, a nie pod modę — i budujemy warstwę integracyjną tak, żeby wymiana modelu nie była przepisywaniem systemu. Zobacz integracje LLM albo napisz, co chcesz osiągnąć.

Autor
Maciej Szukalski
Założyciel Condictor · architekt systemów · badania i rozwój
Od 2014 roku projektuje i buduje produkty cyfrowe. Specjalizuje się w architekturze, badaniach oraz aplikacjach z warstwami automatyzacji i inteligencji.
Poznaj doświadczenie i sposób pracyMasz problem do rozwiązania?
Sprawdźmy, od czego warto zacząć
Opisz sytuację w kilku zdaniach. Wrócimy z pytaniami lub propozycją konkretnego następnego kroku.
