Zespół badawczy zbudował router, aby zdecydować, czy tani model językowy poradzi sobie z zapytaniem programistycznym, mając nadzieję na obniżenie kosztów wnioskowania, jednak router nie zdołał pokonać punktu odniesienia „nigdy nie eskaluj”. Niepowodzenie to pokazuje, dlaczego metryki skoncentrowane na dokładności wprowadzają w błąd w przypadku kaskad, oraz wskazuje na sygnały, które faktycznie oddają poziom trudności.
Dlaczego router miał znaczenie
Kaskady modeli przesyłają każde zapytanie do najmniejszego modelu, który jest w stanie odpowiedzieć na nie poprawnie. Jeśli router wyśle prosty prompt do taniego modelu, system pomija kosztowne obliczenia wymagane przez większy model. Zespół wytrenował router na 539 rzeczywistych zadaniach programistycznych — 428 łatwych i 111 trudnych — licząc na to, że nauczy się on, kiedy tani model będzie wystarczający.
Liczby, które okazały się niewystarczające
- AUC na zbiorze testowym (pole pod krzywą ROC): 0,594
- Zakres 5-krotnej walidacji krzyżowej: 0,55 – 0,57
- Najlepszy próg: odpowiada polityce „nigdy nie eskaluj”
AUC na zbiorze testowym wyniosło 0,594, a zakres walidacji krzyżowej wynosił od 0,55 do 0,57, co oznacza, że klasyfikator ledwo rozróżnia przypadki łatwe od trudnych. Gdy optymalny próg reprodukuje politykę, która nigdy nie używa drogiego modelu, router nie wnosi żadnej wartości. Zachowuje się jak stały predyktor, a nie decydent.
Co testowały eksperymenty
Badacze porównali trzy zestawy cech:
| Zestaw cech | AUC |
|---|---|
| 11 prostych cech powierzchniowych (np. liczba tokenów, obecność słów kluczowych) | 0,610 |
| 1024-wymiarowe osadzenie promptu (wektor semantyczny) | 0,552 |
| Oba połączone | 0,609 |
Co zaskakujące, lekkie cechy powierzchniowe poradziły sobie lepiej niż wysokowymiarowe osadzenie semantyczne. Osadzenie uchwyciło temat promptu, ale nie jego wewnętrzną trudność. Podanie routerowi szkicu wygenerowanego przez tani model podniosło AUC do 0,640, co sugeruje, że sygnały pojawiające się podczas generowania są bardziej informatywne niż te obecne w samym prompcie.
Dwa fundamentalne błędy
1. Dokładność to niewłaściwa miara
Router musi poprawić kompromis między kosztem a dokładnością w porównaniu z naiwną polityką, a nie tylko przewidywać poprawność. Jeśli nie potrafi pokonać strategii „nigdy nie eskaluj”, nie oferuje żadnych korzyści kosztowych, niezależnie od surowej dokładności. Tradycyjne metryki, takie jak AUC, ignorują ekonomiczny wymiar kaskady.
2. „Zawsze eskaluj” to nie jest sufit
Eksperyment zakładał, że drogi model jest nieomylny, traktując zasadę „zawsze używaj dużego modelu” jako górną granicę. W rzeczywistości większy model czasami psuł odpowiedzi, które tani model podał poprawnie. Idealny router, który wie, kiedy pozostać przy tanim modelu, może pokonać punkt odniesienia „zawsze eskaluj” o około 4,2 punktu w wybranej metryce kosztowej. Luka ta pokazuje, że sufit wydajności drogiego modelu jest niższy, niż zakładano.
Projektowanie lepszych sygnałów routingu
Wyniki sugerują trzy praktyczne kierunki:
- Uwzględnij sygnały z czasu generowania. Podawanie routerowi pośredniego wyniku taniego modelu (jego szkicu) pozwala uchwycić trudność, którą sam prompt ukrywa.
- Nadaj priorytet cechom powierzchniowym specyficznym dla zadania. Proste metryki — takie jak długość, obecność określonych operatorów czy znaczniki stylu kodu — mogą mieć większą moc predykcyjną niż ogólne osadzenia semantyczne.
- Mierz sukces za pomocą metryk uwzględniających koszty. Zamiast czystej dokładności lub AUC, oceniaj, ile drogich wywołań udało się uniknąć przy zachowaniu docelowych poziomów jakości.
Wniosek: Router, który optymalizuje jedynie dokładność, nie może zagwarantować oszczędności kosztów; skuteczny routing wymaga dowodów z czasu generowania oraz ewaluacji uwzględniającej koszty.