Прибуток:
- Можна порівняти модельне сімейство (швидке/збалансоване/потужне) за можливостями, швидкістю та вартістю
- Розробляє вибір моделі та стратегії маршрутизації відповідно до складності завдання
- Базує вибір моделі на доказах із невеликим набором оцінок
Єдине рішення, яке визначає вашу найбільшу віддачу від ваших грошей і якості в інтеграції LLM, це те, яку модель ви використовуєте. Загальний рефлекс «вибери найсильнішу модель»; Однак це часто означає непотрібні витрати та затримки. Правильний підхід полягає в тому, щоб вибрати найлегшу модель, яка впорається з кожним завданням, і зробити вибір на основі вимірювань, а не припущень. У цьому розділі ви порівняєте сімейство моделей за віссю можливостей/швидкості/вартості, створите стратегію маршрутизації моделі відповідно до складності завдання та підтвердите вибір за допомогою невеликого набору оцінок.
Розуміння модельної сім’ї
Провайдери зазвичай пропонують три класи: швидкий/дешевий, стабільний і потужний. Зв'язок між ними узагальнюється за трьома осями: здатність (потужність для вирішення складних завдань), швидкість (затримка), вартість (ціна токена).
клас
приклад
талант
швидкість
Вартість
Доступні завдання
швидко
Хайку 4.5
середній
дуже високий
низький
Класифікація, маркування, короткий зміст, орієнтування
збалансований
сонет 5
висока
висока
середній
Загальне призначення, кодування, багатоетапний потік, більшість агентських робіт
сильний
Опус 4.8
найвищий
середній
висока
Складне міркування, довгострокові автономні завдання, важкий аналіз
Важливе розуміння: потужніша модель не виконує кращу роботу. У простому маркуванні «терміново чи ні» сильна і швидка моделі дають однакову правильну відповідь; різниця лише в тому, що потужний в 5 разів дорожчий і повільніший. Додатковий талант створює цінність лише тоді, коли цього вимагає місія.
Крок за кроком: як вибрати модель?
- Класифікуйте завдання. Це рутинний/шаблонний (маркування, висновок) чи відкритий/багатетапний (аналіз, планування, код)?
- Почніть з найлегшого кандидата. Спробуйте зі швидкою моделлю. Якщо цього достатньо, зупиніться.
- Якщо недостатньо, переходьте у вищий клас. Якщо точність низька, переходьте до збалансованого, якщо цього недостатньо, переходьте до сильного.
- Міряйте, не гадайте. Порівняйте точність і вартість кожного кандидата з невеликим набором eval (нижче).
- Налаштувати перенаправлення. Замість підключення до однієї моделі розподіліть завдання на правильну модель за допомогою «маршрутизатора».
Маршрутизація моделі
Реальне робоче навантаження змішане: більшість вхідних запитів прості, деякі складні. Марна трата відправляти їх усіх до потужної моделі; Надсилання їх усіх до швидкої моделі знижує якість. Маршрутизація вирішує це: дешева модель (або просте правило) спочатку класифікує завдання, а потім завдання переходить до відповідної моделі.
# Підказка маршрутизатора (працює з дешевою моделлю) Класифікуйте вхідний запит відповідно до його складності. Повертати лише такий JSON:{"difficulty": "simple|complex"}Simple: одноетапний, формульний, з короткою відповіддю.Complex: потребує багатоетапного обґрунтування, аналізу або тривалої генерації.Request: """{{request}}"""
- перейти до простий → швидка модель (дешево, швидко).
- переходити до складної → потужної моделі (дорого, але необхідно).
Цей шаблон значно знижує середню вартість, оскільки більшість трафіку зазвичай є простим.
Порада: рішення про направлення не завжди вимагає LLM. Прості правила на зразок «Перейти до швидкої моделі, якщо текст менше 20 слів» також є орієнтиром і не призводять до нульової додаткової вартості символів. Спочатку спробуйте правило.
Пов’язка вибору з доказами: малий кластер оцінки
Не вибирайте модель за принципом «мені вона виглядає краще». Eval (набір оцінок) — невеликий набір зразків, для яких відома правильна відповідь; ви запускаєте кожну модель на цьому наборі та вимірюєте точність, вартість і затримку.
# Шаблон налаштування Eval1) Зберіть 20-50 реальних прикладів, напишіть від руки «правильну відповідь» на кожному.2) Запустіть кожну модель (швидку/збалансовану/сильну) у цьому наборі.3) Для кожної моделі: кількість виправлень, середня пропускна здатність токенів, вартість запиту, середній час.4) Виберіть модель, яка «дає достатню точність найдешевше».
# Таблиця порівняння Eval (заповнити) Модель | Точність | Вартість за запит | Середня тривалістьХайку | ...% | ... $ | ... snSonnet | ...% | ... $ | ... snOpus | ...% | ... $ | ...сек
Слабка підказка / Сильна підказка (рішення про вибір моделі)
# СЛАБКО (немає основи для рішення) Давайте використаємо найкращу модель, бюджет не важливий.
# СИЛЬНИЙ (рішення на основі вимірювання) В оцінці 50 зразків Haiku дав 96% точності, Sonnet дав 97% точності; Різниця статистично незначуща. Haiku вибрали тому, що це в 5 разів дешевше і в 2 рази швидше. Якщо точність впаде нижче 95%, рішення про оновлення до Sonnet буде прийнято автоматично.
Потужна версія; прив’язує вибір до числа, порогу та правила ескалації. Це як захист сьогоднішнього рішення, так і керування майбутніми змінами.
Три міні-чохли
Випадок 1 — Втеча від сильної моделі. Кол-центр створював усі підсумки розмов із Opus; щомісячний рахунок був високим. При оцінці 40 зразків Sonnet був на 1% нижче Opus за точністю, але коштував одну третину. Вони перенесли підсумковий твір до Сонета; місячна вартість знизилася з 9000 доларів США до 3100 доларів США, без жодних скарг на якість.
Випадок 2 — змішаний трафік із перенаправленням. 80% запитів команди юридичних технологій стосувалися простого тегування документів, 20% – аналізу складних контрактів. Вони посилали їх усіх до потужної моделі. Вони додали дешевий маршрутизатор і розподілили прості завдання в Haiku, а складні — в Opus; середня вартість запиту знизилася на 64%, при збереженні якості аналізу.
Випадок 3 — Вартість зменшення без вимірювання. Щоб зменшити витрати, одна команда скоротила вилучення складного медичного коду безпосередньо до швидкої моделі; Вони не оцінили. У прямому ефірі точність впала з 92% до 78%, що призвело до повернення неправильних висновків. Їм потрібно було спочатку оцінити: це завдання вимагало потужної моделі. Урок: як зменшення, так і підвищення виконуються вимірюванням.
Поширені помилки
- Рефлекс «найсильнішої моделі»: марнотратство та непотрібне затягування простих завдань.
- Зміна моделі без вимірювання: як зменшення, так і розширення ризиковані без оцінки.
- Об’єднання в одну модель: маршрутизація у змішаному трафіку часто ефективніша.
- Завжди приймаючи маршрутизатор за LLM: прості правила можуть працювати без витрат.
- Не встановлено порогове значення підвищення: що станеться, якщо точність впаде, потрібно визначити заздалегідь.
- Не виправлення версії моделі: запишіть, над якою моделлю/версією ви працюєте у виробництві; Зміна версії може змінити поведінку.
Глибше: увічнення оцінки та поступове випробування
Вибір моделі – це не одноразове рішення. Провайдери представляють нові моделі, ціни змінюються, ваша посадова інструкція розвивається. Тож налаштуйте кластер eval один раз і не забудьте; тримай його як живу істоту. Коли виходить нова модель, ви перевіряєте ті самі 20-50 зразків, оновлюєте таблицю та приймаєте рішення знову. Це захистить вас від пастки «інтуїції перемикання шаблонів».
Друга просунута техніка – це резервний / каскадний шаблон. Ви спочатку даєте завдання дешевій моделі; Якщо результат має низьку достовірність або рівень перевірки (блок 11) відхиляє його, ви посилаєте той самий запит. Таким чином, більша частина трафіку розподіляється на дешевій моделі, і лише менша частина йде на дорогу модель. Це і дешевше, і довговічніше, ніж фіксований підхід однієї моделі.
По-третє, eval включає не тільки точність, але також вартість і затримку. Якщо модель на 1% точніша, але в 3 рази дорожча і в 2 рази повільніша, компроміс не вартий того для більшості робіт. Прийміть рішення за трьома осями (точність, вартість, затримка) і визначте «поріг достатності»: «якщо точність вище 95%, виберіть найдешевший».
Нарешті, запишіть, яку модель/версію ви використовували у виробництві. Якщо одного разу якість виведення зміниться, перше, на що ви звернете увагу, це чи змінилася версія моделі. Відстеження версій дозволяє швидше знаходити першопричину проблем із якістю.
Ще одне застереження: кластер eval має відображати ваше фактичне навантаження. Оцінка, що складається лише з простих прикладів, приховує, де модель спотикається у складних випадках, і вселяє у вас помилкову впевненість. Хороша оцінка; Він містить загальні прості приклади, а також кутові випадки, з якими ви стикаєтеся в реальності (неоднозначні, неповні, суперечливі вхідні дані). Ця важка меншість визначає ваш вибір моделі, тому що в будь-якому випадку кожна модель досягає успіху в легкій більшості. Зберігайте свій Eval свіжим і репрезентативним, періодично додаючи йому нові справжні зразки.
Підсумовуючи
Правильна модель — це найлегша модель, яка виконує роботу; Більш потужний не означає кращий у кожній роботі, він просто дорожчий і повільніший. Класифікація завдання та початок від найлегшого кандидата, розподіл змішаного трафіку з маршрутизацією та обґрунтування вибору невеликим набором оцінок у багато разів зменшує вартість при збереженні якості.
Аплікаційне завдання
Виберіть навантаження. (1) Класифікуйте завдання як просте/складне. (2) Створіть невеликий набір eval із 20 реальних прикладів (з їх правильними відповідями). (3) Складіть план заповнення таблиці порівняння точності/вартості/часу для трьох класів моделей. (4) Якщо у вас змішаний трафік, напишіть правило маршрутизації та встановіть поріг ескалації.
контрольний список
- [ ] Я можу порівняти сімейство моделей за віссю можливостей/швидкості/вартості.
- [ ] Я можу застосувати принцип «найлегшої успішної моделі».
- [ ] Я можу налаштувати модель маршрутизації відповідно до складності завдання.
- [ ] За допомогою невеликого набору eval я можу прив’язати вибірку до доказів.
- [ ] Я можу визначити поріг підвищення/пониження.