Kierowanie zapytań do tańszych modeli bez ukrywania spadków jakości

Dwa błędy routingu o różnych kosztach

Zbyt niski routing wysyła zapytanie, które potrzebowało mocnego modelu, do taniego. Użytkownik dostaje gorszą odpowiedź, a w panelu kosztów nic tego nie pokazuje. Zbyt wysoki routing wysyła proste zapytanie do mocnego modelu. Odpowiedź jest w porządku, a oszczędność mniejsza, niż mogłaby być. Większość projektów routingu raportuje tylko drugi błąd, bo tylko jego widać na fakturze.

Oba błędy są ze sobą powiązane przez próg routera, więc przed strojeniem zdecyduj, który możesz tolerować. W asystencie programisty słaba odpowiedź kosztuje inżyniera kilka minut. W piśmie dotyczącym szkody może kosztować reklamację.

Zbuduj test akceptacyjny, zanim cokolwiek włączysz

Weź niedawną próbkę prawdziwych zapytań i przepuść każde przez oba modele. Eksperci albo model oceniający, którego oceny sprawdziłeś względem ekspertów, niech oznaczą każdą odpowiedź każdego modelu jako akceptowalną lub nie, według wzorca albo własnej oceny. Nie zakładaj, że mocny model zawsze ma rację: zapytania, w których żadna odpowiedź nie jest akceptowalna, to problem promptu lub zadania i nie powinny trafiać do liczb routingu. Potem uruchom router na tej samej próbce. Hipotetyczny wynik dla 1000 zapytań, w których mocna odpowiedź była akceptowalna zawsze, a tania w 700 przypadkach:

• Do taniego modelu i akceptowalne: 610
• Do taniego modelu, ale nieakceptowalne, czyli zbyt nisko: 40
• Do mocnego modelu, choć tani by wystarczył, czyli zbyt wysoko: 90
• Do mocnego modelu i słusznie: 260

Załóżmy, że tani model kosztuje jedną dziesiątą na zapytanie, a koszt samego routera pomijamy. Wysłanie wszystkiego do mocnego modelu kosztuje 1000 jednostek, ten routing 415, ale 4 procent użytkowników dostaje gorszą odpowiedź. Jeśli uzgodniony limit to 1 procent, podnieś próg, traktując tę próbkę jako zbiór kalibracyjny. Załóżmy, że nowy próg wysyła 560 zapytań do taniego modelu, z czego 9 zbyt nisko, za 496 jednostek. Potem potwierdź wynik na osobnej odłożonej próbce, której próg nigdy nie widział. Przy małych liczbach podawaj przedział: 9 błędów na 1000 odpowiada prawdziwemu odsetkowi od około 0,5 do 1,7 procent przy 95 procentach ufności, więc do wykazania, że limit jest dotrzymany, może być potrzebna większa próbka końcowa.

Reguły, routery uczone i kaskady

Reguły według funkcji, typu zadania czy klienta najłatwiej skontrolować i mogą dać znaczną część możliwych oszczędności. Routery uczone decydują dla każdego zapytania: RouteLLM trenuje je na danych o preferencjach ludzi i raportuje ponad dwukrotne obniżenie kosztów na niektórych benchmarkach bez spadku jakości odpowiedzi. Kaskady najpierw wywołują tani model i eskalują, gdy test nie przejdzie. FrugalGPT raportuje w ten sposób duże oszczędności, ale eskalowane zapytania płacą za dwa wywołania i czekają na oba, a sam test musi być wiarygodny.

Publikowane oszczędności traktuj jako dowód, że routing może działać, a nie jako prognozę. Pochodzą z ruchu benchmarkowego i różnic cenowych innych niż twoje. Routery mają już też bramki: auto routing w LiteLLM, w chwili pisania w wersji beta, przydziela zapytania do poziomów za pomocą heurystyk, klasyfikatora LLM lub własnej wtyczki. Cokolwiek wybierzesz, przechodzi ten sam test akceptacyjny.

Fallbacki chronią dostępność, a nie jakość

Fallback uruchamia się przy błędach. W LiteLLM wywołanie, które po ponowieniach nadal się nie udaje, przechodzi do następnej grupy modeli z uporządkowanej listy, a osobne listy mogą obsłużyć błędy okna kontekstu i polityki treści. Nic z tego nie sprawdza odpowiedzi. Jeśli celem fallbacku jest model, którego twój test akceptacyjny nigdy nie objął, awaria zamienia się w nieprzetestowaną zmianę jakości. LiteLLM ostrzega też, że fallback do innego dostawcy nie odczyta zaszyfrowanego rozumowania z wcześniejszych tur.

Przepuść każdy cel fallbacku przez test akceptacyjny i przećwicz przełączenie w środowisku nieprodukcyjnym, wywołując prawdziwy błąd dostawcy, jak zaleca dokumentacja LiteLLM.

Jak zauważyć, że routing zawodzi na produkcji

Zacznij od zapisywania, który model naprawdę odpowiedział. Przy auto routingu w LiteLLM treść odpowiedzi zachowuje alias, który wywołał klient, a model obsługujący zapytanie jest podany w nagłówku x-litellm-model-id, więc go zapisuj. Logi wydatków zapisują też dla każdego zapytania attempted_fallbacks i original_model_group, co oddziela ruch z fallbacku od ruchu z routingu. Potem obserwuj te sygnały dla każdego poziomu:

• Niewielka próbka zapytań z taniego poziomu wysyłana dodatkowo do mocnego modelu i porównywana, żeby zbyt niski routing mierzyć, a nie zgadywać
• Użytkownicy ponawiający lub przeformułowujący pytanie tuż po odpowiedzi z taniego poziomu
• Udział ruchu na każdym poziomie, który dryfuje, gdy zmienia się mieszanka zapytań lub dane wejściowe routera
• Odsetek fallbacków dla każdego dostawcy, liczony osobno od decyzji routingu