Дослідницька група розробила роутер, щоб вирішувати, чи зможе дешева мовна модель впоратися із запитом на написання коду, сподіваючись знизити витрати на інференс, проте роутер не зміг перевершити базовий рівень стратегії «ніколи не ескалювати». Ця невдача демонструє, чому метрики, орієнтовані лише на точність, вводять в оману при побудові каскадів, і вказує на сигнали, які насправді дозволяють оцінити складність завдання.
Чому роутер мав значення
Каскади моделей спрямовують кожен запит до найменшої моделі, яка може відповісти на нього правильно. Якщо роутер надсилає простий промпт дешевій моделі, система пропускає дорогі обчислення, необхідні для більшої моделі. Команда навчила роутер на 539 реальних завданнях із програмування — 428 легких і 111 складних, очікуючи, що він навчиться визначати, коли буде достатньо дешевої моделі.
Показники, що не виправдали очікувань
- AUC на відкладеній вибірці (площа під ROC-кривою): 0.594
- Діапазон 5-кратної крос-валідації: 0.55 – 0.57
- Найкращий поріг: відповідає стратегії «ніколи не ескалювати»
AUC на відкладеній вибірці становив 0.594, а під час крос-валідації показник коливався від 0.55 до 0.57, що означає, що класифікатор ледь розрізняє легкі та складні випадки. Коли оптимальний поріг відтворює стратегію, яка ніколи не використовує дорогу модель, роутер не приносить жодної користі. Він поводиться як константний предиктор, а не як інструмент прийняття рішень.
Що перевіряли експерименти
Дослідники порівняли три набори ознак:
| Набір ознак | AUC |
|---|---|
| 11 простих поверхневих ознак (наприклад, кількість токенів, наявність ключових слів) | 0.610 |
| 1024-вимірний ембедінг промпту (семантичний вектор) | 0.552 |
| Обидва поєднані | 0.609 |
На диво, легкі поверхневі ознаки виявилися ефективнішими за високовимірний семантичний ембедінг. Ембедінг фіксував тему промпту, але не його внутрішню складність. Подання чернетки від дешевої моделі роутеру підвищило AUC до 0.640, що свідчить про те, що сигнали, які з'являються під час генерації, є інформативнішими, ніж ті, що містяться лише в промпті.
Дві фундаментальні пастки
1. Точність — неправильне мірило
Роутер має покращувати компроміс між вартістю та точністю порівняно з наївною стратегією, а не просто передбачати правильність. Якщо він не може перевершити стратегію «ніколи не ескалювати», він не дає економічної вигоди, незалежно від чистої точності. Традиційні метрики, такі як AUC, ігнорують економічний аспект каскаду.
2. «Завжди ескалювати» — це не верхня межа
В експерименті припускалося, що дорога модель є непогрішною, розглядаючи стратегію «завжди використовувати велику модель» як верхню межу. Насправді велика модель іноді псувала відповіді, які дешева модель давала правильно. Ідеальний роутер, який знає, коли варто залишитися з дешевою моделлю, може перевершити базовий рівень «завжди ескалювати» приблизно на 4.2 пункти за обраною метрикою вартості. Ця різниця показує, що межа продуктивності дорогої моделі нижча, ніж вважалося.
Розробка кращих сигналів для маршрутизації
Результати пропонують три практичні напрямки:
- Включайте підказки часу генерації. Подання проміжного результату (чернетки) дешевої моделі роутеру дозволяє вловити складність, яку приховує сам промпт.
- Надавайте пріоритет специфічним для завдань поверхневим ознакам. Прості метрики — такі як довжина, наявність певних операторів або маркери стилю коду — можуть бути кращими предикторами, ніж загальні семантичні ембедінги.
- Вимірюйте успіх за допомогою метрик, що враховують вартість. Замість чистої точності або AUC оцінюйте, скільки дорогих викликів вдалося уникнути, зберігаючи цільовий рівень якості.
Висновок: Роутер, який оптимізує лише точність, не може гарантувати економію коштів; ефективна маршрутизація потребує доказів під час генерації та оцінки з урахуванням вартості.