Місце моделі в бенчмарку ще нічого не говорить про її цінність для бізнесу. Давайте скажемо це прямо.
У своєму дослідженні я оцінив 33 моделі від 15 провайдерів і розподілив їх за практичними сценаріями. Виявилося, що модель із найкращим reasoning може бути невигідною для масової автоматизації, а висока автономність може створювати більше ризиків, ніж користі.
Тому AI-агента потрібно оцінювати не лише за тим, що він уміє, а й за повною вартістю сценарію, рівнем доступу до даних та ціною помилки.
Матвій Дядьков, засновник Bitmedia Labs
Бенчмарк перевіряє модель, а не ваш бізнес-процес
Найкраще це видно на простому прикладі з мого pet project, агентської системи, яка моніторить нішевий ринок і оцінює, де ціни адекватні, а де ні.
Для аналізу я поставив туди топову модель із верхівки бенчмарків. Вона видала дуже переконливий звіт, але на фактчеку виявилося, що ключову оцінку вартості просто вигадала, а комісію майданчика порахувала неправильно.
У бенчмарку це мінус кілька балів. У реальному житті це мінус гроші, якби я прийняв рішення на основі цього звіту.
Тут для мене і проходить межа між технічною оцінкою та бізнесовою. Бенчмарк показує, наскільки модель сильна в середньому. Бізнесу важливіше знати, наскільки дорого вона помиляється в найгірший момент.
Тому в задачах, пов’язаних із грошима, я тепер закладаю окремий шар перевірки. І топова модель у результаті коштує дорожче, ніж написано в її прайсі: до API додаються перевірки, повторні виклики й час людини.
Спочатку визначте ціну помилки
Ціна помилки має напряму визначати рівень автономності.
Агент, який готує чернетку внутрішнього документа, може працювати майже самостійно. Якщо він помилився, текст переписали й пішли далі.
Зовсім інша історія, якщо агент створює SQL-запити, змінює код, працює з платежами або персональними даними. Тут уже потрібні sandbox, автоматичні перевірки, журналювання дій і точки, де рішення підтверджує людина.
Ключовий момент: безпека залежить не тільки від того, наскільки часто помиляється модель. Вона залежить від того, що система дозволяє їй зробити після цієї помилки.
Неправильний абзац можна переписати. Неправильна команда в базі даних може змінити або видалити інформацію. Це вже інша ціна помилки, а отже, інша архітектура.
Дорога модель має думати, дешева працювати
У моїй агентській системі оркестратор працює на Claude Opus. Він викликається рідко, але приймає складні рішення. Сканер, який цілодобово перебирає дані, працює на Sonnet: там тисячі викликів, і ціна за один запит важливіша за максимальний рівень reasoning.
Принцип простий: дорога модель думає, дешева працює.
Схожий підхід ми закладаємо в AI-генератор банерів у Bitmedia Labs. Сам банер створює сильна модель, а потім дешевша перевіряє результат: чи він достатньо якісний і чи не порушує рекламні правила. На генерацію потрібен сильніший інтелект, на перевірку вистачає уважності й чітких критеріїв.
Multi-model підхід має сенс, коли вже є обсяг і метрики. Тоді видно, де саме система фейлить, і можна точково замінити модель у конкретному місці.
А от будувати «зоопарк» моделей на старті я б не радив. Кожна модель це окремі промпти, версії та способи зламатися. Дебажити ланцюжок із чотирьох моделей це окремий вид страждань.
Моє правило: стартуйте з однієї моделі й розділяйте систему тільки тоді, коли цифри показують навіщо.
З чого я починаю будувати агентську систему
Я починаю не з вибору моделі, а з самого процесу. Що саме робить агент, де він може фейлити, що станеться після помилки і чи можна буде відкотити дію.
Далі вже дивлюся, де справді потрібен сильний reasoning, де вистачить дешевшої моделі, а де краще взагалі не давати агенту повну свободу.
І тільки коли з’являються реальні метрики, є сенс ускладнювати систему. До цього моменту модель просто один із компонентів, а не центр всієї архітектури.
Регіон теж може змінити правильну відповідь
Хороший приклад це AI-платформа для продажу вживаних авто, яку ми розробляємо для ринку MENA. Ми хотіли зробити пошук, з яким можна говорити як із другом, який добре знається на машинах: написав або надиктував, що тобі потрібно, і отримав нормальну підбірку замість стіни фільтрів.
На практиці однією з головних проблем стала мова. Бенчмарки з арабської зазвичай побудовані на літературній мові. Реальні користувачі в країнах Затоки пишуть діалектом, змішують арабську з англійською в одному реченні, частину слів вводять латиницею та використовують локальний автомобільний сленг.
Ми тестували моделі, які добре виглядали в рейтингах, але саме на таких запитах вони починали помилятися.
Другий фактор це дані. Маркетплейс працює із запитами користувачів, оголошеннями та персональною інформацією. Для продукту, де довіра критична, просто передавати все через зовнішні API в іншому регіоні не найкращий варіант. До цього додається латентність, яку користувач одразу відчуває в чаті.
У результаті архітектура вийшла багаторівневою. Легка швидка модель перетворює запит на структуровані фільтри. Сильніша підключається лише там, де справді потрібен reasoning. А основну модель ми хочемо максимально тримати під власним контролем, аж до self-hosted open-weight рішення.
Тут вибір визначили не бенчмарки, а три речі: діалект, латентність і питання, кому належать дані користувача.
У реальному продукті найкраща модель не та, що має найвищий score, а та, яка дає потрібний результат за прийнятну ціну помилки.