Маршрутизація моделей: як добирати виконавця до задачі

У команді можуть бути доступні кілька моделей, продуктів і способів виклику. Найдорожча модель не обов’язково потрібна для кожного кроку, а найдешевша за токенами не обов’язково дасть найдешевший прийнятий результат. Маршрутизація — це рішення, яка конфігурація виконання підходить для конкретної роботи за її вимогами, ризиком і перевірюваністю.

Навчальний результат. Після цієї глави читач розрізняє модель і продукт, який її запускає; обирає конфігурацію з урахуванням задачі, даних, інструментів і наслідків помилки; задає безпечний маршрут ескалації; порівнює повну вартість і якість на репрезентативних задачах; пояснює межі невеликого тесту та змінність каталогів моделей.

Передумови. Глава спирається на контекст і обмеження з глави 24, джерела правди з глави 25, спеціалізацію та людську відповідальність із глави 41 і паралельні потоки з глави 42. Метрики та повнішу економіку студії розглянуто в главах 69 і 70.

43.1. Маршрутизуємо роботу, а не шукаємо одну найкращу модель

Маршрутизація моделі (model routing) — це вибір моделі або іншої конфігурації для кроку робочого процесу. Конфігурація може включати модель, продукт чи програмний інтерфейс, рівень міркування, інструкції, доступні інструменти, дозволи, джерела даних, обмеження бюджету та спосіб перевірки. Розглядати лише назву моделі — все одно що обирати інструмент, не перевіривши, чи він під’єднаний до потрібного середовища.

Для маршруту спершу визначте:

1. Тип задачі та бажаний результат. Класифікувати повідомлення, знайти факт у документах, запропонувати архітектуру, написати код, змінити багато однотипних файлів чи рецензувати diff — це різні роботи. Скажіть, що вважатиметься правильним результатом.
2. Ціну помилки. Помилковий тег, який можна виправити, відрізняється від хибної міграції даних, небезпечної дії або висновку, що впливає на права людини. Серйозні наслідки вимагають сильніших обмежень, доказів і людського нагляду, незалежно від рекламованих здібностей моделі.
3. Перевірюваність. Чи є тест, схема, джерело або детерміноване правило, яке може прийняти або відхилити відповідь? Коли умова формальна й стабільна, скрипт або звичайна програма часто підходить краще за мовну модель.
4. Повну конфігурацію. Чи підтримує обраний продукт потрібні типи входу, довжину контексту, структурований результат та інструменти? Чи має він потрібні дозволи й доступ до даних?
5. Обмеження експлуатації. Час відповіді, доступність, черги, ліміти запитів, бюджет, правила приватності й регіональна обробка можуть виключити варіант до порівняння якості.

Лише після цих фільтрів порівнюйте придатні варіанти за якістю, часом і вартістю на власних задачах. Довший контекст, вищий рівень міркування або сильна модель не усувають браку даних, неправильного критерію чи відсутнього дозволу.

43.2. Модель, продукт і робоче середовище — не одне й те саме

Модель створює відповідь або запит на інструмент у межах своїх можливостей. Продукт чи інтеграція визначає, як саме до неї звертаються, які інструменти під’єднані, який стан середовища зберігається й що дозволено робити. Наприклад, одна назва моделі в каталозі API (application programming interface, програмний інтерфейс застосунку) не доводить, що та сама модель доступна в кожному чаті чи плані. Так само «підтримує використання інструментів» не означає, що інструмент увімкнений, має доступ або виконує команду без хоста.

Перевіряйте щонайменше такі розбіжності між кандидатами:

• Вхід і контекст. Текст, зображення, аудіо чи файли; фактичний ліміт запиту; здатність знайти потрібну деталь у довгому контексті. Заявлений розмір вікна не гарантує, що модель однаково добре використає кожну його частину.
• Вихід і формат. Чи можна отримати схему, об’єкт JSON (JavaScript Object Notation, текстове подання структурованих даних) або коротку класифікацію, яку перевірить код? Структурований формат полегшує обробку, але не робить значення правдивим.
• Інструменти. Вебпошук, файли, термінал, редактор, база чи API доступні лише через конкретний продукт і налаштований хост. Вихідна команда моделі не доводить, що її справді виконали: звіряйте журнал фактичної дії та відповідь інструмента.
• Стан і права. Чи працює агент у потрібному репозиторії або обліковому записі? Чи має тільки читання, може редагувати, запускати код або змінювати реальний стан? Права задає середовище, а не текст відповіді.
• Час і доступність. Довгі міркування, повтори, завантаження контексту й черга можуть збільшити затримку. Публічна межа швидкості — не гарантія доступної пропускної здатності саме вашого облікового запису.
• Дані та політика. Узгодьте точний продукт, endpoint, інструменти, налаштування зберігання й обробки з правилами організації. Загальний напис про приватність або параметр на кшталт вимкнення збереження не доводить, що весь маршрут відповідає вимогам.

Створіть короткий реєстр перевірених варіантів: провайдер і модельний ID (identifier, ідентифікатор), продукт або API, дата перевірки, контекст і формати, інструменти й дозволи, умови обробки даних, чинні ліміти, ціни, клас задач і результат внутрішньої оцінки. Таке датоване поле допомагає помітити застарілі припущення. Воно не має перетворитися на безстроковий рейтинг.

43.3. Прості й комбіновані стратегії маршрутизації

Для малої або нової системи початковий маршрут часто може бути одним придатним якісним варіантом. Це створює базову лінію порівняння. Кілька моделей додавайте лише тоді, коли є конкретна економія, доступність або вимога якості, яку можна виміряти.

Стратегія	Коли може допомогти	Що потрібно контролювати
Один маршрут	Невеликий обсяг, високі наслідки помилки або ще немає доказу користі від поділу	Вартість і час базового маршруту; ризик єдиної точки недоступності
Явне правило	Відомий тип задачі або метадані надійно вказують на інструмент чи клас роботи	Невідомі типи й винятки не повинні тихо потрапляти до непридатного маршруту
Класифікатор перед викликом	Вхід має кілька повторюваних класів, а маршрут для кожного виміряно	Помилки класифікатора, власна затримка й ціна, стан «не знаю», порядок резервного маршруту
Дешевший перший крок із перевіркою та ескалацією	Перший результат часто проходить незалежний тест, а невдалі випадки можна безпечно повторити сильнішим варіантом	Якість перевірки, повторні виклики, дублювання токенів, приховані збої та повна ціна після ескалації
Сильний планувальник і швидкі виконавці	Роботу можна поділити на обмежені, перевірювані кроки з різними вимогами	Накладні витрати координації, спільні ресурси, вартість зведення й спільної перевірки з глав 40–42
Другий рецензент	Потрібне окреме критичне читання або пошук пропущених умов	Інша модель чи провайдер не є доказом незалежної правильності, якщо обидва не бачили потрібного джерела або мають спільне хибне припущення

Класифікатор може впевнено помилитися. Тому визначте, коли він повертає «невідомо», і який безпечний шлях застосовується до незнайомої задачі. Якщо помилкове направлення коштує дорожче, ніж використати якісний варіант за замовчуванням, класифікація не виправдовує своєї складності.

Ескалацію запускають спостережувані умови: відсутній обов’язковий доказ, тест не пройдено, повтор не допоміг, джерела суперечать одне одному, запит виходить за межі дозволів, задача стала ризикованішою або змінилася сама постановка. Самооцінка впевненості моделі не є каліброваною ймовірністю правильності, доки її не порівняли з результатами на відповідній вибірці. На критичному кроці потрібне правило, прив’язане до доказу чи перевірки, а не лише до фрази «я впевнена».

43.4. Розібрані рішення для трьох частин одного процесу

Уявімо сервіс, що приймає звернення, пропонує виправлення довідника та планує зміни схеми. Маршрут визначається окремо для кожного кроку:

1. Класифікувати повідомлення. Якщо ключове слово чи затверджений формат однозначно визначає мітку, спершу працює правило. Для вільного тексту модель повертає мітку з обмеженого переліку та поле «потрібне уточнення». Код перевіряє схему, а людина періодично перевіряє вибірку й усі невідомі чи суперечливі випадки. Не треба викликати складну модель для запису, де правило вже дало однозначну відповідь.
2. Знайти джерело для відповіді. Якщо відповідь залежить від чинного внутрішнього документа, потрібен маршрут із доступом до актуальної версії. Перевірка порівнює ключове твердження з документом. Якщо пошук не повернув підтвердження або документи конфліктують, маршрут має передати випадок фахівцеві. Більший контекст без пошуку потрібної версії не усуває застаріле знання.
3. Спроєктувати міграцію. Модель може зібрати залежності, порівняти зворотні варіанти та скласти план безпечного розгортання, але спершу їй потрібні схема, читачі й записувачі старого формату, обмеження відновлення й авторитетні джерела. Якщо рецензент не може підтвердити критичну умову сумісності або порядок міграції, наступний крок — перевірка документації, аналіз коду чи людське рішення. Запуск ще кількох моделей на тому самому неповному контексті не дає відсутнього доказу.

Для повторюваного форматування файлів стабільний скрипт може бути головним виконавцем, а модель — лише для неоднозначного тексту. Для коду вибирайте не тільки модель: потрібні робоча копія, конкретні інструменти, обмежені права, перевірки на виході та журнал дій. Рецензент без коду, тесту чи джерела може знайти неузгодженість аргументації, але не підтвердити фактичну сумісність.

43.5. Оцінюйте однакові задачі за прийнятим результатом

Демонстрація на одному вдалому запиті або загальний рейтинг моделі не відповідають на запитання, як вона впорається саме з роботою вашої команди. До зміни маршруту зберіть вибірку, що відображає реальний розподіл задач і включає крайні випадки. Для кожного класу сформулюйте прийнятний результат, частоту помилки, яку можна витримати, і критерій, що знаходить неправильну відповідь.

Порівнюйте кандидатів за тим самим завданням і процесом. Зафіксуйте ревізію даних, інструкції, середовище, доступні інструменти та дозволи; позначте ID і версію моделі, рівень міркування, режим швидкості та дату. Випадки слід розподілити між кандидатами однаково; якщо поведінка мінлива, повторіть частину запусків. Зміни умов тесту разом зі зміною моделі унеможливлюють приписати різницю одному фактору.

Оцінка має охопити кілька зрізів:

• Якість прийнятого результату: частка задач, що пройшли той самий критерій; критичні помилки; помилки за класом; частка хибних прийнять і хибних відхилень.
• Час: повний час до прийняття, медіана й повільний хвіст, з урахуванням очікування, повторів і людської рецензії.
• Повна вартість: виклики всіх моделей, повтори, токени введення й відповіді, інструменти, пошук і обчислення, маршрутизатор, людська перевірка, виправлення й інтеграція.
• Робота нагляду: скільки відповідей людина прочитала, що їй довелося виправити, чому відхилила результат і скільки часу витратила.
• Надійність процесу: збої інструментів, обриви, обмеження швидкості, перехід на резервний шлях і здатність відновити задачу.

Корисний економічний показник — витрати повного процесу, поділені на кількість перевірених прийнятих результатів. Звітуйте разом із часткою невдач: середня ціна успіху приховає процес, який дешево відхиляє більшість задач. Для продуктів із підпискою чи планом окремо покажіть використання та ліміт доступності; не приписуйте їм точну граничну ціну за токен, якої система вимірювання не надає.

Невелика вибірка дає попередню оцінку, а не вічний рейтинг. Розбивайте висновки за типом і ризиком; позначайте кількість запусків і розкид. Якщо різниця між кандидатами мала порівняно з коливаннями між запусками або кількістю людських перевірок, даних недостатньо для надійного вибору. Повторюйте оцінку після зміни моделі, інструкцій, інструментів, даних чи критеріїв. Як зазначено в офіційних посібниках оцінювання OpenAI та Anthropic, якість потребує заздалегідь визначених критеріїв, репрезентативних прикладів і відповідних до задачі оцінювачів; автоматичний оцінювач теж потребує перевірки OpenAI: найкращі практики оцінювання, Anthropic: визначення критеріїв і побудова тестів.

Навчальний приклад: дешева модель може збільшити загальні витрати

Уявна команда має 100 подібних задач. Для прикладу вона встановила внутрішні умовні витрати: короткий виклик недорогої конфігурації коштує $0,02, сильнішої — $0,10; людська перевірка п’ять хвилин коштує $2,50 за задачу за умовної вартості людської праці $30 за годину. Ці числа не є прайсом провайдера. Припустімо також, що всі наведені результати пройшли один і той самий процес перевірки й у підсумку прийняті. Таблиця не включає вартість побудови маршрутизатора чи оцінювача.

План на 100 прийнятих задач	Виклики моделей	Людська перевірка	Разом	Вартість на прийняту задачу
Сильніша конфігурація одразу: 100 × $0,10; п’ять винятків × $2,50	$10	$12,50	$22,50	$0,225
Недорога спершу: 100 × $0,02; 20 ескалацій × $0,10; чотири винятки × $2,50	$4	$10	$14	$0,14
Недорога спершу, але багато ескалацій: 100 × $0,02; 60 ескалацій × $0,10; 20 винятків × $2,50	$8	$50	$58	$0,58

У цьому умовному сценарії дешевий перший крок знижує повні витрати лише тоді, коли більшість задач проходить перевірку й мало з них переходить до людини. За високої частоти ескалації дешевша ціна виклику вже не компенсує людську працю. Для реального вибору команда мусить виміряти ті самі критерії прийняття на обох маршрутах і врахувати відхилені задачі; приклад демонструє арифметику, а не доводить, що один маршрут якісніший.

Обмежений інженерний кейс: одна система, інша задача — інший результат

У вересні 2026 року Fiddler описав три серії перевірок коду на одному циклі агента. У першій серії п’ять завдань налагодження Python виконували дві моделі: три повтори, три проходи, 45 запусків на модель. У цьому досліді Haiku 4.5 мала вдвічі нижчу ціну токенів, ніж Sonnet 5, але обчислені авторами витрати запусків склали $4 проти $0,45. В одному запуску Haiku згенерувала відповідь на 21 492 токени, що описувала 60 команд оболонки, хоча цикл дозволяв виконати одну команду за хід і фактично виконав тільки першу. Модель продовжила відповідь так, ніби передбачені нею команди вже відпрацювали; ці токени коштували грошей, а довга відповідь збільшила контекст наступних ходів. Перевіреним успіхом вважалася задача, що проходила приховані тести; у трьох проходах перших п’яти задач співвідношення вартості на підтверджений успіх коливалося від 8,4 до 14,1 раза. Автори зауважили, що це розходження чутливе до окремих довгих відповідей, тож його не слід трактувати як універсальне число.

В іншій серії з дев’ятьма спеціально написаними задачами видимі тести прийняли кожен запуск, але приховані тести виявили пропуски. Результат також відрізнявся на наборі HumanEval+. Це приклад того, що ціна токена й один набір задач не передбачають ані повної вартості, ані рангу на іншій роботі. Доларові суми — облік запусків у цьому експерименті, а не повна вартість організації: дослідження не вимірювало людську інтеграцію чи перевірку. Також його створив постачальник інструменту моніторингу, перша серія мала лише п’ять задач і використовувала один агентний цикл. Її слід читати як аргумент перевіряти власний процес, а не як рейтинг моделей чи доказ, що дешевші моделі завжди програють Fiddler AI: дослідження запусків агентів коду, 11 вересня 2026 року.

43.6. Ризик, ескалація та відновлення

Резервний маршрут — частина початкового дизайну. Він має визначати, що робить система, якщо модель недоступна, ліміт вичерпано, вихід не відповідає схемі, інструмент завершився помилкою або якість нижча за встановлений поріг. Повторювати можна лише після класифікації причини: ще один ідентичний виклик не виправляє застарілий документ, відсутній дозвіл, зламаний парсер чи суперечливу вимогу.

Для ризикованих задач обмежуйте наслідки незалежно від вибраної моделі: спершу режим лише читання; інструментальні дозволи за принципом найменших потрібних прав; тестова база або симуляція для змін; перевірка людиною перед дією, яку складно відкотити. Сильний результат моделі може допомогти фахівцеві, але не надає системі дозволу на зміну продуктивного середовища.

Записуйте повний ланцюжок: задача й маршрут, версія, фактичне введення та відповіді, виклики інструментів і їхній результат, автоматичний критерій, людські правки, ескалація, прийняття або відхилення. Без цього окремий лічильник токенів не пояснює, чому виконання було дорогим чи правильним. Доступ до такого журналу й термін зберігання також мають відповідати правилам роботи з даними.

Короткий підсумок

Маршрутизуйте кожен тип роботи до придатного шляху, враховуючи результат, ризик, перевірку, контекст, інструменти, права, час, бюджет і політику даних. Почніть із простого вимірюваного маршруту; додавайте класифікацію, каскад чи другого рецензента лише за наявності репрезентативних доказів користі. Порівнюйте ціну до прийнятого результату разом із якістю, затримкою, повторами й людською працею. Датуйте каталог і повторюйте перевірку, коли змінюються моделі, продукти або умови.

Джерела та подальше читання

• OpenAI, Model selection. Як розглядати модель та рівень міркування як початкову гіпотезу для перевірки на власному робочому процесі. Актуальну сторінку перевірено 2026-09-24.
• OpenAI, Models, Pricing, Rate limits, Tools та Your data. Довідники поточного каталогу, способів виклику, лімітів, інструментів і правил даних. Перевірено 2026-09-24.
• OpenAI, Evaluation best practices. Планування перевірок на задачах, критеріях та метриках, що відповідають роботі. Перевірено 2026-09-24.
• Anthropic, Models overview, Model IDs and versions, Pricing та Rate limits. Поточний каталог і застереження щодо версій, цін та доступності. Перевірено 2026-09-24.
• Anthropic, Tool use overview, Data retention та Define success criteria and build evaluations. Розмежування виклику інструмента й його виконання, обробка даних і побудова перевірок. Перевірено 2026-09-24.
• Fiddler AI, Why Cheaper Models Cost More to Complete Coding Tasks, опубліковано й оновлено 2026-09-11. Первинний звіт компанії про три оцінювання агентів коду, включно з невеликою серією п’яти задач; не є незалежним рейтингом. Перевірено 2026-09-24.