Big tasks. Small models: po co agentowi kilka mniejszych modeli?

Duże zadanie nie zawsze wymaga jednego wielkiego modelu. Microsoft Research opisuje MagenticLite jako połączenie aplikacji i środowiska wykonawczego z dwoma specjalizowanymi modelami: MagenticBrain planuje, koduje i deleguje, a Fara 1.5 działa w przeglądarce. To podejście „Big tasks. Small models” ma sens, gdy zadanie składa się z odmiennych rodzajów pracy.

Dlaczego podział ról jest ważny?

Agent, który analizuje plik, oblicza wynik i wypełnia formularz, musi rozumować nad danymi oraz sterować interfejsem. Pierwszą pracę można dać modelowi orkiestrującemu, drugą modelowi wyspecjalizowanemu w obserwacji ekranu i działaniu. MagenticBrain odpowiada za plan i dobór narzędzia; Fara 1.5 za czynności przeglądarkowe. Magentic-UI było wcześniejszym eksperymentem z kontrolą człowieka; MagenticLite jest jego rozwinięciem.

Ważną częścią rozwiązania jest harness, czyli kod prowadzący cały cykl. Zarządza kontekstem, przekazuje zadania, ogranicza narzędzia i zatrzymuje działanie przy krytycznych punktach. Małe modele mogą szybciej tracić skuteczność w długim, zaśmieconym kontekście, dlatego środowisko podaje im tylko potrzebne informacje i podsumowuje wcześniejsze kroki. Zysk nie pochodzi wyłącznie z liczby parametrów modelu.

Co to oznacza dla firmy?

Mniejsze modele mogą ułatwić pracę bliżej danych i ograniczyć zależność od jednej usługi modelowej. Nie wolno jednak zakładać, że lokalnie znaczy tanio: trzeba policzyć GPU, pamięć, utrzymanie, opóźnienie dwóch modeli i pracę nad ewaluacją. Repozytorium Magentic-UI dokumentuje tryby hostowania i warunki uruchomienia, które należy sprawdzić dla własnej konfiguracji.

Nie wszystkie zadania nadają się do pełnej autonomii. Przy logowaniu, płatnościach, zapisie do CRM czy wysyłce maila potrzebny jest mechanizm zatwierdzenia i zapis skutku. Microsoft opisuje izolację wykonania oraz punkty krytyczne w badawczym wydaniu, lecz ich skuteczność zależy od konkretnej konfiguracji. Rozsądny pilot zaczyna się od jednego powtarzalnego procesu: porównaj ukończenie zadania, liczbę interwencji człowieka, koszt i jakość artefaktu z prostszym asystentem oraz regułową automatyzacją.

Jak wygląda obieg zadania?

Załóżmy, że użytkownik chce znaleźć trzy ceny części zamiennej i zaktualizować arkusz. MagenticBrain układa plan, Fara przegląda strony i zbiera informacje, a narzędzie plikowe zapisuje wynik. Harness przechowuje stan między krokami. Jeśli jedna strona zmieni układ, wykonawca może zgłosić błąd, a planista wybrać inną ścieżkę. Gdy na ekranie pojawi się logowanie lub zatwierdzenie zakupu, system ma zatrzymać się w punkcie krytycznym.

Warto oddzielić wiedzę modelu od mechaniki środowiska. Model może wiedzieć, jak porównać oferty, ale nie powinien przechowywać hasła do sklepu. To host udostępnia sesję przeglądarki, narzędzia plikowe i zakres uprawnień. Gdy zmienimy model, zasady dostępu i audytu mają pozostać. Ten podział ułatwia testowanie i potencjalną wymianę dostawcy modeli.

Koszt dwóch małych modeli też trzeba policzyć

Przy pracy lokalnej pojawia się koszt pamięci GPU oraz utrzymania dwóch endpointów. Przy pracy w chmurze dochodzą opłaty za wywołania, transmisję danych i ewentualne stałe instancje. Oszczędność na jednym kroku modelu może zniknąć, jeśli agent wykonuje zbyt wiele rund przeglądarkowych. Zmierz koszt ukończonego zadania, a nie tylko cenę miliona tokenów. Uwzględnij także czas człowieka potrzebny na poprawki.

Ostatecznie „small models” jest hipotezą architektoniczną do sprawdzenia na własnym procesie. Badania Microsoftu pokazują, że wspólne projektowanie modeli i harnessu może działać; nie dowodzą, że dowolny model 14B wraz z dowolnym agentem przeglądarkowym osiągnie ten sam wynik.