Agenci AI powinni wywoływać modele

Artykuł MLAT opisuje pilotaż produkcyjny, w którym agent wywołuje model cenowy XGBoost jako narzędzie, osiąga R^2 = 0,807 na zbiorze testowym, raportuje średni błąd bezwzględny na poziomie 3688 USD i skraca generowanie ofert z kilku godzin do mniej niż 10 minut.¹

Najważniejszy nie jest tu konkretny model cenowy. Najważniejsza jest granica odpowiedzialności: gdy zadanie wymaga oceny punktowej, prognozy, ceny, oszacowania ryzyka, rankingu, klasyfikatora lub detektora, agent powinien wywołać model wytrenowany właśnie do tego zadania. Nie powinien improwizować statystycznej odpowiedzi płynną prozą.

Wytrenowany model powinien znajdować się w rejestrze narzędzi agenta. LLM może zdecydować, kiedy go wywołać, objaśnić wynik, poprosić o brakujące dane wejściowe i obsłużyć wyjątki. Wytrenowany model powinien wygenerować oszacowanie liczbowe, sygnał pewności, wersjonowany wynik oraz ślad dowodowy.

TL;DR

Agenci LLM dobrze sprawdzają się w orkiestracji. Modele statystyczne i modele uczenia maszynowego często lepiej radzą sobie z ograniczoną predykcją. Wzorzec Machine Learning as a Tool traktuje wytrenowany model ML jako narzędzie możliwe do wywołania w przepływie pracy agenta, obok wyszukiwania, baz danych, API i innych narzędzi.¹

Dla zespołów oznacza to jasną zasadę operacyjną: agent koordynuje pracę, a wyspecjalizowane modele wykonują wyspecjalizowane wnioskowanie. Wynik powinien zawierać wersję modelu, schemat danych wejściowych, schemat danych wyjściowych, notatki o kalibracji oraz możliwy do prześledzenia zapis wywołania. Bez takiej granicy LLM może brzmieć pewnie, a po cichu zastępować model zgadywaniem.

Najważniejsze wnioski

• Dla twórców agentów: należy udostępniać wytrenowane modele jako typowane narzędzia ze schematami, wersjami i trybami awarii.
• Dla zespołów ML: agenta należy traktować jako system wywołujący, a nie jako zamiennik ewaluacji modelu, utrwalania artefaktów czy dyscypliny rejestru.
• Dla zespołów produktowych: trzeba pokazywać, czy liczba pochodzi z wywołania modelu, reguły, bazy danych czy objaśnienia LLM.
• Dla zespołów bezpieczeństwa: do narzędzi modelowych należy stosować tę samą logikę ograniczonych uprawnień, którą opisuje Klucze agentów potrzebują budżetów ryzyka.
• Dla recenzentów: przed zaufaniem odpowiedzi należy wymagać wywołania modelu, wersji modelu, danych wejściowych, wyniku oraz granic pewności.

Dlaczego agenci powinni wywoływać modele, zamiast je naśladować?

LLM może omówić cenę. Model cenowy może oszacować ją na podstawie cech, których się nauczył. LLM może streścić ryzyko. Model ryzyka może ocenić ryzyko na podstawie przetestowanego zestawu cech. LLM może opisać odpływ klientów. Model odpływu klientów może zwrócić prawdopodobieństwo powiązane z procesem treningowym.

To różne zadania.

Narzędzia agentów już pozwalają wprowadzić taki podział. Dokumentacja OpenAI Agents SDK opisuje narzędzia funkcyjne z parametrami JSON Schema, procedurami obsługi wywołań narzędzi i ustrukturyzowanymi wynikami narzędzi.² Dokumentacja Anthropic dotycząca użycia narzędzi opisuje, jak Claude wywołuje narzędzia po stronie klienta oraz funkcje zewnętrzne z danymi wejściowymi zdefiniowanymi przez JSON Schema.³ Agent może poprosić o predykcję modelu tym samym wzorcem narzędziowym, którego używa do wyszukiwania, aktualizacji kalendarza, poleceń powłoki czy zapytań do bazy danych.

Główny tryb awarii pojawia się wtedy, gdy zespoły pomijają ten podział. Proszą LLM o oszacowanie, bo LLM potrafi je wygenerować. Odpowiedź przychodzi szybko. Proza brzmi rozsądnie. Interfejs nie daje widocznej wskazówki, że liczba pochodzi z uzupełniania wzorców, a nie z wytrenowanego estymatora.

To słaby kontrakt. Użytkownik nie wie, co wygenerowało wynik. Recenzent nie może sprawdzić wersji modelu ani cech wejściowych. Operator nie może odtworzyć wywołania. Produkt nie potrafi wyjaśnić, dlaczego odpowiedź się zmieniła.

Tutaj obowiązuje bramka dowodowa: pewność nie jest dowodem. Wywołanie modelu może dostarczyć dowód. Zgadywanie ubrane w prozę zwykle nie.

Co wnosi wzorzec MLAT?

MLAT oznacza Machine Learning as a Tool. Artykuł przedstawia wytrenowany model ML jako pełnoprawne narzędzie, które agent LLM może wywołać, gdy rozmowa wymaga estymacji ilościowej.¹

System pilotażowy z artykułu, PitchCraft, używa dwóch agentów. Agent badawczy zbiera kontekst potencjalnego klienta przez równoległe wywołania narzędzi. Agent redakcyjny wywołuje model cenowy XGBoost, a następnie pisze ofertę z użyciem ustrukturyzowanych danych wyjściowych.¹ Model ML odpowiada za wycenę. LLM odpowiada za kontekst, złożenie całości i objaśnienie.

Ten podział ma znaczenie, bo pozwala uniknąć dwóch złych projektów:

Agent nadal jest istotny. Może rozpoznać, że dane wejściowe do wyceny są niekompletne. Może poprosić użytkownika o brakujące pola. Może wywołać wyszukiwarkę lub narzędzia CRM przed uruchomieniem modelu. Może wyjaśnić, że oszacowanie pochodzi z modelu, a nie z jego własnego autorytetu.

To właściwy podział pracy: LLM orkiestruje, wytrenowany model przewiduje.

Co powinno zwracać narzędzie modelowe?

Narzędzie modelowe nie powinno zwracać samej liczby. Poważne narzędzie modelowe powinno zwracać obiekt dowodowy.

Taki kształt wyniku sprawia, że narzędzia modelowe pasują do zasady opisanej w Ślady wykonania agenta są kontraktem środowiska wykonawczego. Jeśli agent wywołuje model cenowy, ślad powinien pokazać wywołanie modelu. Jeśli agent pomija model i mimo to wpisuje liczbę, ślad powinien wyraźnie ujawniać tę nieobecność.

Ta sama logika wspiera tekst Pakiety recenzji są nową odpowiedzią końcową. Odpowiedź końcowa z ceną jest słaba. Odpowiedź końcowa z zapisem wywołania modelu, wersją modelu, migawką cech i notatką o pewności daje recenzentowi coś, co można sprawdzić.

Gdzie pasują rejestry modeli?

Opakowanie w narzędzie nie zastępuje MLOps. Ono udostępnia MLOps środowisku wykonawczemu agenta.

Dokumentacja rejestru modeli MLflow opisuje pochodzenie, wersjonowanie, aliasy, tagi metadanych i informacje o cyklu życia modeli.⁴ Ta warstwa rejestru ma znaczenie, bo przepływ pracy agenta może zacytować wersję modelu tylko wtedy, gdy platforma w ogóle śledzi wersje.

Dokumentacja utrwalania modeli scikit-learn pokazuje pokrewny problem od strony serwowania: wybory dotyczące utrwalania niosą kompromisy bezpieczeństwa i przenośności, a ONNX może serwować modele bez środowiska Python, podczas gdy ścieżki oparte na pickle wymagają zaufania do źródła.⁵ Narzędzie modelowe nie powinno przemycać niebezpiecznego artefaktu modelu do agenta tylko dlatego, że agent poprosił o predykcję.

Minimalny stos operacyjny wygląda tak:

Zespoły często zwijają te warstwy do jednego punktu końcowego o nazwie predict. Ten skrót działa w demonstracjach. Zawodzi, gdy agent zaczyna łączyć predykcje w wiadomości do klientów, oferty sprzedażowe, notatki z oceny ryzyka, plany infrastruktury albo szkice segregacji medycznej.

Produkt potrzebuje kontraktu modelu, a nie magicznego punktu końcowego.

Jak produkty powinny pokazywać wyniki modelu?

UI powinien informować użytkownika, kiedy odpowiedź pochodzi z narzędzia modelowego.

Zła treść interfejsu ukrywa pochodzenie:

Lepsza treść nazywa ścieżkę produkcyjną:

To rozróżnienie chroni godność użytkownika. Użytkownicy nie powinni musieć zgadywać, czy liczba pochodzi z przetestowanego modelu, karty modelu, reguły biznesowej czy uzupełnienia przez model językowy. Tekst Projektowanie agentowe to projektowanie powierzchni kontroli argumentuje, że produkty agentowe potrzebują powierzchni nadzoru i kontroli. Pochodzenie modelu jest jedną z takich powierzchni.

Karty modeli pomagają z tym samym problemem na poziomie dokumentacji. Artykuł Model Cards proponuje ustrukturyzowane raportowanie charakterystyk modelu, zamierzonego użycia, metryk i kontekstu ewaluacji.⁶ Interfejsy agentów mogą zapożyczyć ten pomysł w czasie działania: każda odpowiedź modelu powinna nieść dość kontekstu, by użytkownik lub recenzent rozumiał, jakiego rodzaju twierdzenie przedstawił model.

Czego agenci powinni odmawiać?

Agent świadomy modeli powinien odmawiać kilku kuszącym skrótom.

Powinien odmówić wymyślenia wyniku modelu, gdy narzędzie modelowe jest niedostępne. Może powiedzieć, że model cenowy zawiódł. Może zapytać, czy użytkownik chce przybliżonego oszacowania oznaczonego jako ludzkie. Nie powinien po cichu zastępować modelu.

Powinien odmówić rozszerzenia domeny modelu bez dowodów. Model odpływu klientów wytrenowany na danych średnich firm SaaS nie powinien stać się uniwersalną wyrocznią kondycji biznesu tylko dlatego, że polecenie grzecznie o to prosi.

Powinien odmówić ukrywania niepewności. Jeśli model zwraca przedział, odpowiedź nie powinna spłaszczać go do jednej pewnej liczby, chyba że produkt ma jasną regułę prezentacji.

Powinien odmówić wywołania narzędzia modelowego z brakującymi lub sfabrykowanymi cechami. Agent może zebrać dane wejściowe, zadać pytania uzupełniające albo oznaczyć pola jako nieznane. Nie powinien wypełniać wektora cech wygodną fikcją.

Powinien odmówić traktowania autorytetu modelu jako autorytetu do działania. Model może oszacować ryzyko oszustwa. To nie znaczy, że agent może zamrozić konto. Działanie nadal wymaga dyscypliny kluczy o ograniczonym zakresie opisanej w Klucze agentów potrzebują budżetów ryzyka.

Reguła decyzyjna

Przy budowaniu przepływu pracy agenta warto stosować tę regułę:

Ta reguła daje LLM wartościową pracę, ale nie pozwala mu podszywać się pod każdy inny system. Może koordynować przepływ pracy, objaśniać wyniki, szkicować wiadomość i zadawać lepsze pytania. Nie może stać się modelem cenowym, modelem ryzyka, modelem oszustw, modelem rankingowym ani silnikiem polityk tylko dlatego, że brzmi płynnie.

Najlepsze produkty agentowe nie będą prosiły jednego modelu, by udawał całą firmę. Zbudują powierzchnię narzędziową, w której każdy system wykonuje pracę, którą potrafi udowodnić.

FAQ

Czy dotyczy to tylko tradycyjnych modeli uczenia maszynowego?

Nie. Ten sam wzorzec dotyczy każdego wyspecjalizowanego estymatora lub mechanizmu oceny: modeli wzmacniania gradientowego, klasyfikatorów, systemów rankingowych, modeli prognostycznych, silników reguł, mechanizmów scoringowych w wyszukiwaniu informacji i detektorów domenowych. Nie chodzi o algorytm. Chodzi o kontrakt wokół wyniku.

Dlaczego nie pozwolić LLM szacować bezpośrednio?

Czasem przybliżone jakościowe oszacowanie wystarcza. Produkt powinien powiedzieć to jasno. Gdy użytkownik potrzebuje ceny, oceny ryzyka, prognozy albo decyzji o kwalifikowalności, odpowiedź powinna pochodzić z przetestowanego modelu lub ścieżki reguł, z możliwymi do prześledzenia danymi wejściowymi i ograniczeniami.

Czy narzędzie modelowe automatycznie sprawia, że odpowiedź jest poprawna?

Nie. Narzędzie modelowe nadal może być przestarzałe, stronnicze, źle skalibrowane, niewłaściwie użyte albo stosowane poza prawidłową domeną. Narzędzie modelowe poprawia możliwość inspekcji. Nie usuwa potrzeby ewaluacji, monitorowania i ludzkiej recenzji.

Jaki jest minimalny wykonalny kontrakt narzędzia modelowego?

Na początek: schemat wejścia, schemat wyjścia, wersja modelu, predykcja, pewność lub zastrzeżenie, kształt błędu, limit czasu i identyfikator śladu. Gdy model wpływa na pieniądze, dostęp, bezpieczeństwo albo decyzje widoczne dla klienta, należy dodać nazwy cech, link do rejestru, odniesienie do karty modelu i notatki o kalibracji.

Jak zmienia to UX agenta?

Interfejs powinien oznaczać źródło ważnych wyników. Użytkownicy powinni widzieć, czy odpowiedź pochodzi z wywołania modelu, pobranego dokumentu, reguły biznesowej, ludzkiej akceptacji czy syntezy LLM. To pochodzenie zmienia poziom zaufania, na jaki odpowiedź zasługuje.

Źródła