Które zadania o dużym wolumenie oddać małemu modelowi językowemu

Co sprawia, że zadanie pasuje do małego modelu

Belcak i współautorzy w artykule stanowiskowym opublikowanym po raz pierwszy w 2025 roku dowodzą, że systemy agentowe wykonują wiele wywołań modeli, które powtarzają kilka wyspecjalizowanych zadań z niewielką zmiennością, i że małe modele są do nich często wystarczająco zdolne i tańsze. Przewodnik OpenAI o opóźnieniach ujmuje to praktycznie: dobrze zdefiniowane zadania o ograniczonym zakresie to dobrzy kandydaci dla mniejszego, ewentualnie dostrojonego modelu, a otwarte odpowiedzi asystenta lepiej zostawić większemu.

W postaci pytań o twoje własne obciążenie:

• Czy wynik jest ograniczony? Kategoria, obiekt JSON ze znanymi polami albo tak lub nie są łatwiejsze niż swobodna proza.
• Czy wejścia powtarzają strukturę, na przykład ten sam formularz, szablon zgłoszenia lub typ dokumentu?
• Czy ktoś potrafi ocenić, czy odpowiedź jest poprawna? Bez sprawdzalnej odpowiedzi nie przetestujesz mniejszego modelu.
• Czy zadanie wymaga faktów spoza wejścia? Wtedy bezpieczniejszy jest większy model albo retrieval.
• Ile kosztuje błędna odpowiedź i czy jest model zapasowy albo osoba, która ją sprawdzi?

Przesiewanie hipotetycznej listy zadań

Załóżmy, że zespół platformowy ubezpieczyciela spisuje pięć wywołań modeli o największym wolumenie. Wolumeny i oceny są hipotetyczne, zapisane tak, jak zespół mógłby wypełnić tę listę na warsztacie.

• Sortowanie maili do 14 kolejek, 40 000 dziennie: ograniczony wynik, powtarzalne wejścia, etykiety z wcześniejszego routingu. Mocny kandydat.
• Ekstrakcja pól z formularzy szkód, 25 000 dziennie: stałe pola, znane szablony, poprawione wartości w systemie szkód. Mocny kandydat.
• Streszczenia akt szkód dla likwidatorów, 6000 dziennie: swobodny tekst, długie wejścia, jakość oceniana przez ludzi. Słaby kandydat.
• Pytania klientów o polisy, 3000 dziennie: zależą od aktualnej treści warunków i szerszego rozumowania. Lepiej obsłuży je retrieval z większym modelem.
• Uzasadnienia zgłoszeń podejrzenia oszustwa, 400 dziennie: wysoka stawka, mały wolumen. Nawet przy założonych 10 € za 1000 wywołań 12 000 wywołań miesięcznie kosztuje około 120 €, znacznie mniej niż zbudowanie, ocena i przeglądanie modelu. Osobny model wymagałby uzasadnienia jakościowego, a nie kosztowego.

Ze względu na koszty zostaje dwóch kandydatów. Zespół zaczyna od sortowania maili, bo etykiety są czystsze, a źle przydzielony mail kosztuje kilka minut, a nie błędną decyzję o szkodzie.

Najpierw test, potem trening

Sprawdź, jak daleko zajdzie mały model bez fine-tuningu. Uruchom jeden lub dwa małe modele, hostowane lub z otwartymi wagami, na odłożonych przypadkach z tego zadania, z tym samym promptem i parserem co obecny model. Każdy z trzech możliwych wyników wskazuje następny krok.

• Już dorównuje obecnemu modelowi: zmień model i prompt, trening pomiń.
• Jest blisko, a błędy skupiają się w kilku kategoriach: oznaczone przykłady prawdopodobnie nauczą go tego, czego brakuje.
• Odstaje wszędzie: zadanie jest prawdopodobnie szersze, niż się wydawało, więc wróć do przesiewu.

Dokumentacja fine-tuningu OpenAI opisuje jeszcze jedną drogę, która działa tak samo z modelem z otwartymi wagami trenowanym w twoim środowisku: dopracować prompt większego modelu, aż zacznie dobrze działać, zachować jego odpowiedzi spełniające twoje kryteria i wytrenować na nich mniejszy model. To pomaga, gdy brakuje oznaczonych danych, ale mały model dziedziczy błędy dużego.

Policz opłacalność na własnym wolumenie

Mniejsze modele hostowane bywają tańsze w przeliczeniu na token, ale różnica zależy od dostawcy i obciążenia, a model hostowany samodzielnie kosztuje niezależnie od tego, czy przychodzą zapytania. Porównaj koszt miesięczny przy twoim wolumenie: obecny koszt zapytania razy wolumen wobec stałego kosztu serwowania plus pracy nad danymi, treningiem, ewaluacją i monitoringiem.

Hipotetyczny rachunek z jawnymi założeniami: obecny model kosztuje 3 € za 1000 posortowanych maili, więc 1,2 miliona maili miesięcznie kosztuje 3600 €. Jedno GPU po założonej stawce 1,50 € za godzinę kosztuje przy pracy ciągłej około 1100 € miesięcznie, jeszcze bez hostowanego modelu zapasowego na szczyty. Różnica około 2500 € miesięcznie musi pokryć pracę inżynierską i ponowne treningi. Przy tych założeniach i jednej dziesiątej wolumenu GPU kosztowałoby więcej niż model, który zastępuje. Wtedy warto przetestować mniejszy model hostowany, o ile jego cena, wyniki na twoich odłożonych przypadkach i sposób przetwarzania danych są do zaakceptowania.

Niektóre powody nie widnieją na fakturze: czas odpowiedzi i dane, które muszą zostać w twoich systemach. Wskazówki Hugging Face dodają, że model mieszczący się na jednym GPU jest znacznie prostszy we wdrożeniu niż taki, który trzeba rozdzielić na kilka.

Gdzie małe modele zawodzą

Typowa porażka to zadanie, które na papierze jest węższe niż na produkcji. Sortowanie maili wygląda na 14 etykiet, dopóki część maili nie zawiera dwóch próśb, groźby prawnej w dopisku albo języka, którego nikt nie przewidział. Zmierz te przypadki brzegowe i kieruj je do większego modelu, zamiast wciskać im etykietę.

Druga porażka to dryf. Kolejki, produkty i zasady się zmieniają, a mały model wytrenowany na zeszłorocznych etykietach tego nie zauważa. Przed uruchomieniem ustal, kto i po jakim sygnale go ponownie wytrenuje.