Przejdź do treści
Condictor Studio
AI
AI

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.

Około 5 min czytaniaautor
Trzy przezroczyste modele o różnej wielkości obok otworu w kształcie zadania, z najlepiej dopasowanym miętowym modelem pośrodku

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.

Ścieżka decyzyjna od małego modelu przez punkt pomiaru na własnych przykładach do modelu większego, obok sześć pól kryteriów rozłożonych na osi kosztu i trudności zadania
Kolejność doboru: najpierw model tani, potem pomiar na własnych przykładach, mocniejszy dopiero gdy nie wystarcza.

Model przez API czy z otwartymi wagami?

Model udostępniany przez APIModel z otwartymi wagami na własnej infrastrukturze
Czas do pierwszego efektuczęsto krótszy, bo infrastruktura jest gotowaczęsto dłuższy przez wdrożenie i utrzymanie infrastruktury
Koszt przy małej skaliczęsto niższymoże być wyższy przez stały koszt infrastruktury
Koszt przy dużej, stałej skalirośnie z użyciemmoże być niższy
Kontrola nad danymizależna od umowy i konfiguracjiwiększa, ale wymaga własnych zabezpieczeń
Praca własnaintegracjaintegracja 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:

  1. 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.
  2. Uruchom na nich dwa lub trzy modele i policz, ile razy wynik jest poprawny.
  3. Zapisz też koszt i czas jednego przebiegu.
  4. 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ąć.

Maciej Szukalski

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.

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

Opisz swój temat

Zobacz też

Wszystkie artykuły