Dlaczego nie każde zadanie AI wymaga największego modelu: projektowanie uwzględniające zasoby

Jeden system wykrywania oszustw, cztery różne zadania

Zobaczmy, z czym musi sobie poradzić pojedynczy system wykrywania oszustw. Nazwa domeny może wymagać sprawdzenia wobec dostępnych informacji o zagrożeniach. Faktura może potrzebować porównania z ustalonymi danymi płatniczymi dostawcy. Niejednoznaczny e-mail wymaga interpretacji w kontekście, a sfałszowane audio lub wideo mogą wymagać znacznie bardziej zaawansowanego modelu analitycznego. Wszystko to zalicza się do prac związanych z bezpieczeństwem, ale pod względem obliczeniowym nie są to te same problemy.

Mimo to nowoczesne systemy AI oferują kuszącą skrótową drogę: kierowanie wszystkiego do największego modelu uniwersalnego dostępnego na rynku i pozostawienie mu decyzji. Jest to z pewnością proste. Może to jednak być również niepotrzebnie drogie, powolne, naruszające prywatność, trudne do kontrolowania lub po prostu nieodpowiednie do realizacji zadania. Tutaj „największy” oznacza najsilniejszy lub najbardziej zaawansowany model uniwersalny, a nie tylko ten z największą liczbą parametrów.

Zatem pytanie dotyczące projektu zmienia się. Zamiast pytać, jaki jest najsilniejszy dostępny model, należy zapytać, jaki jest najmniej złożony mechanizm, który nadal spełnia wymagania jakościowe i związane z ryzykiem zadania. Czasami jest to silny model ogólny, czasami mniejszy, specjalistyczny model. A czasami odpowiednim modelem w ogóle nie jest żaden model.

Benchmarks versus produkcja

Benchmarks pokazują, co model potrafi zrobić. Architektura produkcyjna musi rozstrzygnąć zupełnie inny problem: co system powinien faktycznie używać. Jakość to tylko jedna z wielu wymiarów. Rzeczywiste systemy muszą również uwzględniać cele dotyczące opóźnień, budżety obliczeniowe, zasady ochrony prywatności, ograniczone zasoby obliczeniowe, warunki sieciowe, cele niezawodności oraz koszty operacyjne.

Model, który wygrywa w testach benchmark, może zatem nie nadawać się do konkretnego zastosowania. Gdy kwestię rozstrzyga dokładne, deterministyczne porównanie, dodatkowa moc obliczeniowa prawie nic nie daje. Gdy dane powinny pozostać w lokalnym środowisku, ich wysyłanie do usługi zdalnej zmienia sytuację pod względem prywatności i bezpieczeństwa. A gdy proces biznesowy musi udzielić odpowiedzi w sztywnym terminie, decyzja nie może opierać się wyłącznie na jakości modelu.

Jeden ze sposobów sformułowania tego problemu: odpowiedni mechanizm łączy wystarczającą jakość, akceptowalne ryzyko oraz akceptowalne koszty operacyjne. To nie oznacza wyboru najtańszej opcji, ponieważ tani mechanizm, który nie radzi sobie z zadaniem, nie jest odpowiedni. Oznacza to, że dodatkowe możliwości powinny być uzasadnione swoimi dodatkowymi kosztami.

Co pokazują badania nad routowaniem

Ta koncepcja staje się coraz bardziej widoczna w badaniach nad modelami routingu. Zamiast zakładać, że każda prośba trafia do jednego modelu premium, badacze opracowali systemy, które wybierają model w zależności od prośby oraz wymaganego wyniku wydajnościowego.

W artykule FrugalGPT autorstwa Chen, Zaharii i Zou (2024) przeanalizowano sekwencje działania różnych modeli językowych. Ich staranne łączenie znacznie obniżyło koszty obliczeń, zachowując jednocześnie zamierzony poziom wydajności, a w niektórych testowanych warunkach oszczędności wyniosły aż 98%. RouteLLM (Ong i wsp., 2025) posunął się dalej, ucząc się, kiedy zapytanie powinno trafić do silniejszego lub słabszego modelu. Na swoich publicznych benchmarkach odnotował ponad dwukrotną redukcję kosztów bez straty jakości w porównaniu z użytym wcześniej podejściem.

Te liczby nie stanowią gwarancji dotyczących wydajności w praktyce. Zależą one od modeli, testów porównawczych, struktur cenowych oraz metod routingu w poszczególnych eksperymentach. Nadal jednak obowiązuje ta zasada architektoniczna: maksymalna wydajność nie musi być punktem pracy domyślnym.

Specjaliści, zasady i dokładne porównania

Mieszanie modeli nie polega wyłącznie na wyborze między dwoma uniwersalnymi modelami LLM. Gdy zadanie ma ściśle określone ramy, specjalizacja może czasami zastąpić samą wielkość modelu. Pecher, Srba i Bielikova (2025) porównali małe, specjalistyczne modele z dużymi, uniwersalnymi modelami w osiemdziesięciu zadań klasyfikacji tekstu i stwierdzili, że przy dość niewielkiej ilości oznaczonych danych z danej dziedziny małe modele dorównywały lub przewyższały duże modele w niektórych specyficznych problemach.

Istnieje jednak pewna granica. Kompaktowy klasyfikator przeszkolony do jednego celu nie może zastąpić silnego modelu ogólnego, gdy zadanie wymaga szerokiego rozumowania, nieznanych sytuacji, interpretacji między różnymi modalnościami lub wiedzy wykraczającej poza dane treningowe. Jednak problemy wąskie i powtarzalne zmieniają sytuację matematyczną: jeśli system wielokrotnie wykonywa jeden dobrze zdefiniowany operację, może nie musieć posiadać szerokich umiejętności, których nigdy nie wykorzystuje. Badania nad routowaniem również zmierzają w tym kierunku. BEST-Route (Ding i in., 2025) pyta nie tylko o to, który model powinien obsłużyć zapytanie, ale także o to, ile obliczeń w czasie testowym jest dla niego wymagane.

Podstawowa idea jest prosta. Różne obciążenia pracowe znajdują się w różnych obszarach możliwości, a architektura sprawdza się, gdy potrafi je rozróżnić.

Rozważmy jeszcze prostsze operacje:

• określanie, czy dwa znormalizowane identyfikatory kont się pokrywają
• sprawdzanie, czy transakcja przekracza określony próg
• testowanie, czy domena może należeć do zbiórka z pamięci podręcznej
• stwierdzanie, czy w ustrukturyzowanym rekordzie brakuje wymaganego pola

Żadna z tych czynności nie jest z natury semantyczna. Przesyłanie dokładnego porównania za pomocą modelu językowego zamienia zadanie deterministyczne na probabilistyczne, dodaje obciążenie wynikające z inferencji i stwarza kolejną przyczynę niepowodzenia. To jeden z powodów, dla których rozwiązania łączące mechanizmy deterministyczne i uczone wydają się bardziej przekonujące niż wdrażanie sztucznej inteligencji we wszystkich komponentach. Prace neurosymboliczne w cyberbezpieczeństwie wskazują w tym samym kierunku – części uczone przyczyniają się do rozpoznawania wzorców, podczas gdy części symboliczne lub oparte na regułach zapewniają wyraźne rozumowanie i kontrolę (Bizzarri i in., 2025).

Oczywiście zasady nie są powszechnie lepsze. Stają się kruche, gdy język jest niejednoznaczny, gdy zmienia się zachowanie, gdy atakujący używają parafraz, których nikt nie przewidział, lub gdy system musi generalizować poza to, co przewidzieli jego projektanci. Prawdziwa różnica nie leży w zasadach przeciwko sztucznej inteligencji, ale w tym, czy zadanie rzeczywiście wymaga wnioskowania. Tam, gdzie warunek można sformułować dokładnie, logika deterministyczna stanowi doskonałe rozwiązanie inżynieryjne. Tam, gdzie istotne są znaczenie, niepewność lub generalizacja, modele uczone zasługują na swoje miejsce. Dojrzała architektura radzi sobie z obiema sytuacjami.

Ta sama dyscyplina w systemach wieloagentowych

Systemy wieloagentowe zasługują na takie samo dokładne przyjrzenie się. Gdy zespół przyjmie, że jeden duży model nie powinien zajmować się wszystkim, łatwo jest przesadzić z korektami i podzielić wszystko na agenty, ponieważ wygląda to bardziej zaawansowanie. Liczba agentów nie jest uzasadnieniem. Projekt wieloagentowy ma sens, gdy obowiązki są rzeczywiście rozdzielone: różne umiejętności, narzędzia, uprawnienia lub źródła danych, albo prace, które mogą faktycznie być wykonywane równolegle. Shen i współpracownicy (2024) zbadali projekt oparty na wielu modelach językowych do używania narzędzi, w którym planowanie, wywoływanie narzędzi i podsumowywanie były oddzielone, a korzyść wynikała właśnie z tej funkcjonalnej separacji.

Dodatkowi agenci również powodują wzrost kosztów koordynacji. Wang i współpracownicy (2024) badali dyskusje między wieloma agentami w zadaniami rozumowania i stwierdzili, że nie zawsze przewyższają one silne bazowe rozwiązania oparte na jednym agencie, co podważa założenie, że dodawanie konwersacji między modelami automatycznie poprawia rozumowanie. Topologia również ma znaczenie. Li i współpracownicy (2024) pokazali, że sposób komunikacji między agentami wpływa zarówno na wydajność, jak i koszty obliczeniowe.

Następująca zasada projektowania mówi, że agenci powinni się specjalizować, ponieważ wymaga tego obciążenie pracy. Jeśli kilka agentów analizuje w zasadzie ten sam kontekst, korzysta z tych samych narzędzi i przeprowadza sekwencyjne wersje tego samego rozumowania, architektura prawdopodobnie jedynie zwiększa zbędne obciążenia. Jeden agent z dobrze zaprojektowanymi narzędziami może być lepszym rozwiązaniem.

Gdzie odbywają się obliczenia

Wybór mechanizmu to zaledwie połowa problemu, ponieważ obliczenia muszą również gdzieś być wykonywane. Urządzenia lokalne, infrastruktura brzegowa oraz platformy chmurowe mają po swojej stronie zalety i ograniczenia, a badania nad wspólnymi procesami inferencyjnymi skupiają się na rozkładaniu obliczeń pomiędzy nimi, zamiast zakładać, że całe obciążenie należy do jednego miejsca (Zhou i in., 2019; Ren i in., 2023).

Nic tutaj nie działa we wszystkich przypadkach. Uruchamianie lokalnie nie jest automatycznie szybsze, ponieważ sprzęt końcowa punktu może być słaby, podczas gdy zoptymalizowana usługa chmurowa wykona zadanie szybciej. Uruchamianie w chmurze również nie jest automatycznie lepsze, gdyż opóźnienia sieciowe, przepustowość, wrażliwość danych lub wymagania dotyczące czasu dostępności mogą zmienić sytuację. Kwestia prywatności jest bardziej złożona niż stwierdzenie „lokalne oznacza prywatne”. Przechowywanie surowych danych na urządzeniu zmniejsza ilość przesyłanych danych, jednak pośrednie reprezentacje powstające w wyniku podzielonego lub współpracy w procesie inferencji mogą nadal ujawnić wrażliwe informacje. Higgins i współpracownicy (2025) badają ryzyka związane z rekonstrukcją i inferencją w środowiskach uczenia się podzielonego.

Zatem wybór miejsca uruchomienia to decyzja systemowa, a nie preferencja technologiczna. Pytanie nie brzmi, czy chodzi o urządzenie lokalne, czy chmurę – chodzi o to, które środowisko w odpowiedni sposób spełnia wymagania obciążenia pracy.

Przypadek studium z zakresu ochrony przed oszustwami

Kwestia stała się konkretna podczas projektowania architektury bezpieczeństwa cybernetycznego mającej na celu zbadanie metod ochrony przed oszustwami w małych i średnich firmach. Pytanie o to, który model sztucznej inteligencji powinien wykrywać oszustwa, nigdy nie było właściwym podejściem. Koncepcja ta obejmowała bardzo różne zadania: szybkie sprawdzenia techniczne, uporządkowaną porównywanie danych finansowych, interpretację semantyczną, analizę anomalii oraz potencjalnie znacznie bardziej złożoną analizę materiałów medialnych. Traktowanie ich jako jednego problemu obliczeniowego nie miałoby sensu.

Rezultatem było zaproponowanie trójpoziomowej hybrydowej architektury opartej na wielu agentach, zorganizowanej według rosnącej głębi analitycznej. Ważna jest tu jedna różnica: projekt trójpoziomowy stanowi architekturę docelową, natomiast węższy model dowodowy stworzony dla projektu końcowego potwierdza jedynie jej podzbiór. Nie pokazuje on, że każdy zaproponowany element produkcyjny istnieje lub został sprawdzony.

Warstwa 0: filtrowanie i triaż

Pierwsza warstwa to ta tania i szybka. Proponowane zadania obejmują normalizację, sprawdzanie nadawcy i domeny, sygnały autoryzacyjne, testy przynależności do filtrowania Bloom przechowywanego w pamięci podręcznej, analizę metadanych załączników oraz deterministyczne wskaźniki ryzyka finansowego. Zgodnie z projektem wiele z tych czynności nie polega na sztucznej inteligencji. Filtrowanie Bloom to szybka struktura probabilistyczna służąca do sprawdzania przynależności, a nie klasyfikator oszustw – pozytywny wynik oznacza jedynie, że dany element może znajdować się w zbiorze, więc nadal wymaga potwierdzenia. Pozostałe deterministyczne wskaźniki stanowią natomiast dowody do dalszej analizy, a nie ostateczną ocenę. Ta warstwa istnieje po to, by uniknąć kosztownej analizy tam, gdzie prostsze dowody mogą rozstrzygnąć sprawę lub doprowadzić do jej dalszego rozpatrywania.

Warstwa 1: orkiestracja i wyjaśnianie

Druga warstwa zapewnia kontrolowany przepływ pracy. W docelowym projekcie LangGraph zarządza stanem, węzłami, warunkowym kierowaniem przepływem oraz przepływem dowodów. Mały model językowy może opcjonalnie pomóc w ograniczonej interpretacji semantycznej lub w sformułowaniu treści dla użytkowników, jednak nie ma na celu decydowania o kierowaniu przepływem, stopniu powagi ani działaniach o dużym wpływie.

To ma znaczenie, ponieważ używanie modelu językowego wewnątrz systemu nie wymaga przekazania mu kontroli nad systemem. Warstwa orkiestracji może ograniczyć obszar działania modeli, dowody, które mogą zobaczyć, oraz dostępne dla nich dalsze działania. Może również oddzielić analizę od wyjaśnienia: najpierw ustalić ustrukturyzowane dowody, a następnie przekształcić potwierdzone wyniki w czytelną treść językową.

Warstwa 2: specjalistyczne agenty analityczne

Trzecia warstwa zawiera bardziej zaawansowaną analizę. Projekt docelowy oddziela analizę tekstu i faktur, wykrywanie anomalii oraz intensywnie obliczeniową analizę audio lub wizualną. Funkcje te niekoniecznie wymagają tego samego modelu, dostępu do danych ani środowiska wykonawczego. Właśnie tutaj przydaje się koncepcja wielu agentów – nie jako twierdzenie, że więcej agentów oznacza większą inteligencję, lecz jako sposób reprezentacji naprawdę różnych obowiązków analitycznych.

Ciekawe jest nie tyle liczba trzech warstw, co idea, którą one reprezentują: moc obliczeniowa powinna być proporcjonalna do problemu, który ma być rozwiązany.

Co pokazało dowód koncepcji

Zaimplementowany dowód koncepcyjny został celowo opracowany w węższym zakresie. Wykorzystywał syntetyczne scenariusze kompromitacji adresów e-mail dostawców oraz odwracania faktur przy użyciu deterministycznego LangGraph StateGraph. Proces pracy utrzymywał centralizowany stan, kierował się wyraźnymi ścieżkami routingu, wyodrębniał z tekstu i faktur strukturyzowane wskaźniki ryzyka, deterministycznie agregował stopień powagi sytuacji i generował ostrzeżenia oparte na dostępnych dowodach. Obejmował on podejrzany scenariusz, bezpieczny scenariusz bazowy oraz kontrolowaną ścieżkę błędu, przy użyciu testów automatycznych i lokalnej eksploatacji.

Wypущono kilka elementów: pełny proces pracy w warunkach produkcyjnych na warstwie 0, integrację w czasie rzeczywistym z Microsoft 365 lub Google Workspace, OCR w warunkach produkcyjnych, uczenie federowane, wykrywanie lokalnych anomalii oparte na VAE, przetwarzanie danych poufnych w mediach oraz wykrywanie deepfake’ów w audio i wideo. Zakres ma znaczenie. Dowód koncepcyjny pokazuje, że taki proces jest wykonalny. Nie dowodzi on jednak niczego na temat dokładności w warunkach produkcyjnych, skalowalności ani przewagi kompletnego projektu trójwarstwowego.

Podkreślono jedną ważną lekcję. W tym procesie żaden model językowy nie musiał kierować każdą decyzją. Najpierw pojawiały się dowody w formie uporządkowanej, następnie oceniano je za pomocą wyraźnej logiki, a dopiero potem przekształcano je w ostrzeżenia zrozumiałe dla ludzi. Oddzielenie zdolności rozumowania od uprawnień w procesie było jednym z najprzydatniejszych wniosków architektonicznych.

Skomplikowanie ma swoją cenę

Architektura heterogeniczna nie jest darmowa:

• Każdy router może wybrać złą trasę.
• Kaskada może powodować opóźnienia, zanim przejdzie na droższy model, który był potrzebny od początku.
• Liczne modele oznaczają większą ilość prac związanych z oceną, hostowaniem i zarządzaniem wersjami.
• Projekty oparte na wielu agentach wiążą się z kosztami komunikacji i koordynacji.
• Komponenty działające w pobliżu użytkownika muszą być dostarczane, aktualizowane i monitorowane na różnych punktach końcowych.
• Rozproszenie danych powiększa obszar podatny na luki bezpieczeństwa, niewidoczne punkty oraz awarie.

Istnieje poważny argument przeciwny: czasami jeden silny model jest najprostszym i najlepszym rozwiązaniem. Jeśli spełnia wymagane standardy jakości, opóźnienia, ochrony prywatności, niezawodności i kosztów, dodawanie routerów, specjalistycznych modeli lub dodatkowych agentów może wprowadzić większą złożoność operacyjną, niż jest to warte. To nie stoi w sprzeczności z zasadą uwzględniania zasobów – należy do niej, ponieważ złożoność również musi mieć uzasadnienie.

Celem nie jest zmniejszanie rozmiaru modeli, maksymalizacja liczby agentów ani przenoszenie obliczeń na brzeg sieci tylko dlatego, że obliczenia brzegowe są interesujące. Celem jest unikanie wydatków finansowych, opóźnień, ryzyka dla prywatności lub wysiłków inżynieryjnych związanych z funkcjonalnościami, których zadanie nie wymaga.

Zacznij od zadania

Zanim wybierzesz model, lepiej postawić serię prostszych pytań:

• Czy dokładna zasada, porównanie lub wyszukiwanie mogą wykonać tę pracę? Jeśli tak, może w ogóle nie być potrzebne wnioskowanie.
• Czy zadanie jest na tyle specyficzne i powtarzalne, by uzasadnić potrzebę specjalisty?
• Czy rzeczywiście wymaga ono rozumowania semantycznego lub szerokiej generalizacji?
• Gdzie można przetwarzać dane bez naruszania ograniczeń czasu reakcji, bezpieczeństwa czy prywatności?
• Co się dzieje, gdy wybrany mechanizm jest błędny, i czy proces może być bezpiecznie eskalowany?
• Jeśli rozważa się kilku agentów, czy mają oni odrębne obowiązki, narzędzia lub dane, czy też jedno zadanie jest dzielone tylko dlatego, że tak wygląda bardziej zaawansowanie?

Dopiero po udzieleniu odpowiedzi na te pytania wybór modelu nabiera sensu. To odwraca powszechny zwyczaj, w którym najbardziej imponujący model jest wybierany najpierw, a zadania znajduje się dla niego później. Zacznij od obciążenia pracy i niech jej ograniczenia określą wybrany mechanizm.

Wielkie modele uniwersalne wciąż są niezwykłymi narzędziami, a projektowanie uwzględniające ograniczenia zasobów nie jest wezwaniem do ich unikania. Jest to wezwanie do wykorzystywania ich możliwości tam, gdzie przynosi to korzyści. Operacje deterministyczne powinny pozostać deterministyczne, jeśli to wystarczy. Modele specjalistyczne powinny mieć możliwość specjalizacji. Silniejszy model uniwersalny powinien otrzymywać zadania, które rzeczywiście wymagają jego zdolności rozumowania. A system wieloagentowy powinien istnieć tylko wtedy, gdy wymaga tego rzeczywista specjalizacja. Krótko mówiąc: używaj najprostszego mechanizmu, który odpowiednio spełnia wymagania jakości i ryzyka zadań.

Gdy najsilniejszy model przestanie być założonym celem, pojawia się kolejne, nieuniknione pytanie: jak system powinien zdecydować, dokąd trafi każde zadanie? To pytanie dotyczące routingu, czyli rozdzielenia zasobów obliczeniowych pomiędzy różne poziomy w zależności od zadania, stanowi naturalny następny problem do rozwiązania.

Wspomniane badania

• Chen, Zaharia i Zou (2024): FrugalGPT – wykorzystanie łańcuchowych modeli językowych w celu obniżenia kosztów
• Ong i współpracownicy (2025): RouteLLM – uczenie się doboru ścieżek pomiędzy modelami na podstawie danych preferencji
• Ding i współpracownicy (2025): BEST-Route – adaptacyjne planowanie ścieżek z wykorzystaniem zasobów obliczeniowych w czasie testowania
• Pecher, Srba i Bielikova (2025): małe, specjalistyczne modele w porównaniu z dużymi, uniwersalnymi modelami do klasyfikacji tekstu
• Bizzarri i współpracownicy (2025): przegląd sztucznej inteligencji neurosymbolicznej do wykrywania intruzji w sieciach
• Shen i współpracownicy (2024): agent oparty na wielu modelach językowych do uczenia się narzędzi
• Wang i współpracownicy (2024): czy dyskusje między wieloma agentami poprawiają rozumowanie modeli językowych
• Li i współpracownicy (2024): rzadka topologia komunikacji w debatach między wieloma agentami
• Zhou i współpracownicy (2019) oraz Ren i współpracownicy (2023): przeglądy inteligencji brzegowej oraz współpracy przy wykonywaniu operacji w sieciach neuronowych

Higgins i współpracownicy (2025): uczenie się rozdzielone z ochroną prywatności przeciwko atakom typu adversarial inference