„Który model powinniśmy wywołać?” — to pytanie brzmiało kiedyś jak pytanie dotyczące API. W coraz większej liczbie organizacji jest ono bliższe pytaniu z zakresu zakupów, inżynierii wydajności i architektury.
Ta zmiana wynika z prostego rozwoju sytuacji: obecnie istnieje wiele modeli oferowanych przez wielu dostawców, które znacząco różnią się możliwościami, cenami, charakterystyką opóźnień, opcjami wdrożenia i warunkami umownymi. Ogłoszona przez Stripe umowa przejęcia OpenRouter jest użytecznym sygnałem. Pojedyncze API OpenRouter obejmuje ponad 400 modeli od ponad 80 dostawców, a kryteria routingu uwzględniają złożoność zadania, cenę, szybkość, niezawodność, opóźnienie, przepustowość oraz koszty właściwe dla poszczególnych dostawców.
Powstająca rola nie musi oznaczać nowego stanowiska. Może obejmować inżynierię platform AI, architekturę, zakupy, operacje inferencji lub inżynierię produktu. Jej odpowiedzialność staje się jednak wyraźna: zdecydować, który model powinien obsługiwać daną pracę, przy jakich ograniczeniach, z jakim mechanizmem awaryjnym i na podstawie jakich dowodów.
Routing to decyzja dotycząca polityki przebrana za infrastrukturę
Naiwny router pyta: „Który model jest najtańszy?”. Użyteczny router zadaje bardziej konkretne pytanie: „Jaki jest najtańszy model spełniający wymagania tego żądania dotyczące jakości, opóźnienia, niezawodności, prywatności i działania operacyjnego?”
Wymagania te różnią się w zależności od zadania. Klasyfikator zapytań do obsługi klienta może potrzebować przewidywalnego ustrukturyzowanego wyniku i małego opóźnienia. Trudne zadanie programistyczne może uzasadniać użycie wolniejszego, ale bardziej wydajnego modelu. Wysokowolumenowy potok podsumowywania może preferować mniejszy model, zwłaszcza jeśli po testach jego jakość okaże się wystarczająca. Regulowany proces może wymagać konkretnego regionu, zasad przechowywania danych lub umowy z dostawcą, niezależnie od ceny tokenów.
Dlatego routing należy uwzględniać w przeglądach architektury, a nie tylko w kodzie aplikacji. Trasa wpływa na więcej niż samą fakturę. Może oddziaływać na lokalizację danych, ekspozycję na awarie, obserwowalność, spójność odpowiedzi, sposób korzystania z narzędzi oraz zakres wymaganej później weryfikacji przez człowieka.
Cztery dziedziny stojące za poważną funkcją routingu
1. Zakupy: porównuj całą usługę, a nie tylko wyeksponowaną cenę tokena
Ceny modeli łatwo porównać w niewłaściwy sposób. Tokeny wejściowe i wyjściowe mogą mieć różne stawki. Buforowane dane wejściowe, przetwarzanie wsadowe, usługa priorytetowa i żądania z długim kontekstem mogą zmienić obliczenia. Nominalna cena dostawcy mówi również niewiele o ponowieniach prób, limitach szybkości, wsparciu, minimalnych zobowiązaniach, opłatach za transfer danych ani koszcie inżynieryjnym zmiany dostawcy.
Osoba odpowiedzialna za routing powinna prowadzić ewidencję modeli i dostawców, zawierającą takie pola jak:
- ceny danych wejściowych, wyjściowych, buforowanych i przetwarzanych wsadowo;
- limity kontekstu i wyników;
- udokumentowane limity szybkości i zaobserwowana przepustowość;
- rozkłady opóźnień, a nie tylko średnie opóźnienie;
- dostępność i zachowanie w przypadku przekroczenia limitu czasu;
- warunki dotyczące wykorzystywania danych, przechowywania, lokalizacji oraz umów;
- obsługiwane możliwości, w tym wywoływanie narzędzi, ustrukturyzowane wyniki, obsługa obrazu i strumieniowanie;
- opcje awaryjne i migracyjne.
W rezultacie jest to bliższe zestawieniu materiałów technologicznych niż liście nazw modeli. Należy je przeglądać, gdy zmieniają się ceny, zasady, wersje modeli lub wolumeny biznesowe.
2. Inżynieria wydajności: mierz zadanie, a nie tabelę wyników
Ogólne benchmarki mogą pomóc w orientacji, ale decyzje dotyczące routingu wymagają testów właściwych dla danego obciążenia. Model, który dobrze wypada w publicznym benchmarku programistycznym, może nie być najlepszym wyborem dla wewnętrznych repozytoriów organizacji, jej konwencji nazewniczych, schematów narzędzi ani mechanizmów kontroli bezpieczeństwa.
Zbuduj reprezentatywny zbiór ewaluacyjny na podstawie rzeczywistych żądań, usuwając z niego materiały wrażliwe lub poddając je odpowiedniej kontroli. Oznacz wyniki, które mają znaczenie: poprawność merytoryczną, poprawny JSON, pomyślny wybór narzędzia, pomyślne przejście testów kodu, zachowanie przy odmowie, potrzebę eskalacji i akceptowalny styl. Następnie rejestruj koszt, czas do otrzymania pierwszego tokena, całkowite opóźnienie, odsetek przekroczeń limitu czasu, odsetek ponowień prób oraz długość wyniku.
Nie sprowadzaj wyniku zbyt wcześnie do jednej oceny. Ocena ważona może ukryć poważny tryb awarii. Na przykład model o doskonałej średniej jakości, ale często generujący niepoprawne wywołania narzędzi, może nie nadawać się do zautomatyzowanego procesu. Wolniejszy model może być korzystniejszy ekonomicznie, jeśli jego odpowiedzi ograniczają kosztowną weryfikację przez człowieka.
Stosuj proces oparty na modelu wiodącym i modelach konkurencyjnych: utrzymuj obecnie zatwierdzoną trasę, testuj alternatywy na tym samym korpusie i promuj model konkurencyjny dopiero wtedy, gdy spełni jasno określone progi jakościowe i operacyjne. Twierdzenia zgłaszane przez dostawcę należy traktować jako dane wejściowe do planu testów, a nie jako dowód, że model będzie działał podobnie w twoim środowisku.
3. Architektura: możliwość wymiany modelu
Routing staje się kosztowny, gdy założenia dotyczące konkretnego modelu przenikają całą aplikację. Odporna architektura oddziela zadanie biznesowe od wywołania dostawcy.
Zdefiniuj wewnętrzny kontrakt możliwości. Może on określać, że operacja „klasyfikacja” zwraca ustalony schemat, pola pewności lub wstrzymania się od odpowiedzi, identyfikator modelu oraz identyfikator śledzenia. Operacja „przygotowanie odpowiedzi” może określać ograniczenia dotyczące tonu, wymagania dotyczące cytowania oraz maksymalny budżet opóźnienia. Adaptery dostawców tłumaczą następnie ten kontrakt na poszczególne interfejsy API.
Wersjonuj prompty, schematy, definicje narzędzi, zasady bezpieczeństwa i reguły routingu. Rejestruj, który snapshot modelu i który dostawca obsłużyli każde żądanie. Zachowaj wystarczająco dużo informacji, aby odtworzyć decyzję, bez niepotrzebnego przechowywania wrażliwych treści użytkownika.
Starannie projektuj mechanizmy awaryjne. Mechanizmem awaryjnym może być inny dostawca, mniejszy model, przepływ pracy z kolejką lub ścieżka weryfikacji przez człowieka. Nie powinien on po cichu zmieniać znaczenia zadania. Jeśli ustrukturyzowane dane wyjściowe są obowiązkowe, mechanizm awaryjny musi obsługiwać ten sam kontrakt albo uruchamiać kontrolowaną eskalację.
4. Zarządzanie: decydowanie, kiedy nie stosować routingu automatycznego
Niektórych żądań nie należy kierować do najtańszego dostępnego modelu — ani do żadnego modelu zewnętrznego. Polityka routingu musi zawierać reguły wykluczające dotyczące danych poufnych, decyzji o dużym wpływie, nieobsługiwanych języków, wyjątkowo długiego kontekstu lub działań wymagających etapu zatwierdzenia przez człowieka.
Zespoły powinny również rozróżniać techniczną dostępność modelu od jego zatwierdzenia do konkretnego zastosowania. Wymagania zakupowe i prawne mogą różnić się w zależności od jednostki biznesowej. Model może świetnie wypaść w ewaluacji, a mimo to być niemożliwy do użycia w przepływie pracy, którego warunki przetwarzania danych nie odpowiadają organizacji.
Praktyczna tabela routingu
Początkowa polityka może być prosta i jednoznaczna:
| Klasa zadania | Główny cel | Możliwa ścieżka | Czynnik uruchamiający eskalację |
|---|---|---|---|
| Ekstrakcja na dużą skalę | Prawidłowy schemat i niski koszt jednostkowy | Mały lub średniej wielkości model z rygorystyczną walidacją danych wyjściowych | Błąd schematu lub niski poziom pewności |
| Złożona analiza | Jakość i obsługa dowodów | Bardziej zaawansowany model z większym budżetem opóźnienia | Brakujące dowody, niejednoznaczność lub sygnał dotyczący polityki |
| Interaktywna pomoc | Szybkość postrzeganej odpowiedzi | Model o niskim opóźnieniu, po którym może nastąpić dopracowanie | Niska pewność lub prośba użytkownika o szczegółowe wyjaśnienie |
| Wrażliwy proces | Zatwierdzone przetwarzanie danych i możliwość audytu | Dostawca zatwierdzony w umowie lub kontrolowane wdrożenie | Niezatwierdzone dane, działanie lub jurysdykcja |
Dokładna tabela będzie różnić się w zależności od organizacji. Najważniejsze jest to, aby zasady routingu były czytelne dla interesariuszy z obszarów produktu, bezpieczeństwa, finansów i inżynierii — a nie ukryte w instrukcji warunkowej.
Co to oznacza dla osób budujących kariery
Najsilniejsi kandydaci do tej pracy będą łączyć kilka rodzajów biegłości. Będą rozumieć wystarczająco dużo uczenia maszynowego, aby rozumować o możliwościach i spadku jakości; wystarczająco dużo inżynierii systemów, aby zarządzać opóźnieniami, ponowieniami prób, limitami zapytań i trybami awarii; wystarczająco dużo finansów, aby modelować całkowity koszt; oraz wystarczająco dużo zamówień i zarządzania, aby oceniać zobowiązania i ograniczenia dostawców.
Będą też swobodnie pisać dokumenty decyzyjne. Przydatny dokument wyjaśnia, dlaczego wybrano daną ścieżkę, jakie dowody ją wspierają, jakie ryzyka pozostają oraz jakie zdarzenie powinno uruchomić ponowną ocenę. Jest to cenniejsze niż zapamiętywanie najnowszych nazw modeli, ponieważ nazwy modeli i ceny będą się nadal zmieniać.
Niewielki projekt do portfolio może zademonstrować te umiejętności bez konieczności budowania dużego systemu produkcyjnego. Wybierz jedno obciążenie, utwórz zanonimizowany zestaw ewaluacyjny, połącz trzech dostawców modeli lub modele lokalne za wspólnym interfejsem, a następnie porównaj jakość, poprawność schematu, percentyle opóźnień, wskaźniki awarii i szacowany miesięczny koszt przy kilku poziomach wolumenu. Dodaj reguły zasad dotyczące wrażliwych danych wejściowych oraz ścieżkę awaryjną. Opublikuj metodologię testów i ograniczenia.
Precyzyjnie określ, co projekt udowadnia. Nie udowadnia, że jeden model jest uniwersalnie najlepszy. Udowadnia, że potrafisz przekształcić niejednoznaczny problem wyboru modelu w mierzalną politykę operacyjną.
Sygnał kariery
Routing modeli zyskuje strategiczne znaczenie, ponieważ inteligencja nie jest już pojedynczą, stałą zależnością. Jest portfelem usług o różnych kompromisach i zmieniającej się ekonomice. Zespoły, które traktują ten portfel jak wymienną infrastrukturę, mogą obniżyć koszty, ale mogą też stworzyć ukryte problemy z jakością, zgodnością i niezawodnością. Zespoły, które traktują go jak trwałe zobowiązanie wobec jednego modelu, mogą przeoczyć lepsze opcje.
Wyłaniająca się dziedzina lokuje się między tymi skrajnościami: jest wystarczająco abstrakcyjna, aby zmieniać dostawców, wystarczająco konkretna, aby zachować jakość wykonywania zadań, oraz wystarczająco oparta na dowodach, aby uzasadnić wybór. Na tym polega szansa zawodowa związana z routingiem modeli — nie na jednorazowym wyborze API, lecz na budowaniu systemu decyzyjnego, który nieustannie dokonuje trafnych wyborów.
Tom Whitfield jest odpowiedzialnym redaktorem AI Career Brief, który zajmuje się umiejętnościami, rolami i rozsądnymi posunięciami zawodowymi w erze AI.
