Чому не кожне завдання ШІ потребує найбільшої моделі: проектування з урахуванням ресурсів

Одна система боротьби з шахрайством, чотири різні завдання

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

Проте сучасні системи ШІ пропонують спокусливий шлях швидкого рішення: направляти все до найбільшої універсальної моделі, яка є, і дозволяти їй приймати рішення. Це, безумовно, просто. Однак це також може бути зайво дорогим, повільним, порушувати приватність, бути важким для контролю чи просто не підходити для виконання завдання. Тут „найбільша“ означає найсильнішу чи найскладнішу універсальну модель, яка є, а не просто ту, що має найбільшу кількість параметрів.

Тож корисне дизайнерське запитання змінюється. Замість того, щоб запитувати, яка є найпотужніша модель, яка є, потрібно запитувати, який є найменш складний механізм, який все одно відповідає вимогам до якості та ризиків завдання. Іноді це потужна загальна модель. Іноді — менша спеціалізована. А іноді правильною моделлю взагалі не є жодна модель.

Бенчмарки проти продакшну

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

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

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

Що показують дослідження маршрутизації

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

У статті FrugalGPT авторів Chen, Zaharia та Zou (2024) були проаналізовані каскадні схеми використання різних мовних моделей. Ретельне поєднання цих моделей значно знизило витрати на обробку запитів, зберігаючи при цьому бажану продуктивність; у деяких тестових умовах економія сягнула 98%. Project RouteLLM (Ong та ін., 2025) пішов ще далі, навчившись визначати, коли запит слід надіслати до потужнішої чи слабкішої моделі. На своїх публічних тестах він зафіксував економію понад удвічі без зниження якості порівняно з базовою конфігурацією.

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

Спеціалісти, правила та точні порівняння

Поєднання моделей — це не лише вибір між двома універсальними LLM. Коли завдання суворо обмежене, спеціалізація іноді може замінити собою великі розміри. Pecher, Srba та Bielikova (2025) порівнювали невеликі спеціалізовані моделі з великими універсальними моделями у восьми завданнях класифікації тексту, і за допомогою досить невеликої кількості позначених даних ці невеликі моделі досягали рівня або навіть перевершували великі моделі у деяких специфічних задачах.

Проте існує обмеження. Компактний класифікатор, навчений для однієї мети, не може замінити потужну універсальну модель, коли робота вимагає широкомасштабних міркувань, незнайомих ситуацій, інтерпретації інформації з різних джерел чи знань, яких немає в його навчальних даних. Однак вузькі, повторювані задачі змінюють ситуацію: якщо система постійно виконує одну чітко визначену операцію, їй може не знадоблюватися розвиток широких здібностей, з якими вона ніколи не стикається. Дослідження в галузі маршрутизації також рухаються в цьому напрямку. BEST-Route (Ding et al., 2025) не лише визначає, яка модель має обробити запит, а й оцінює, скільки обчислювальних ресурсів потрібно для його обробки.

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

Розгляньмо ще простіші операції:

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

Жоден з цих етапів не є за своєю суттю семантичним. Надсилання точного порівняння через мовну модель перетворює детерміністичне завдання на ймовірнісне, додає навантаження від обробки інформації та створює ще одну причину для невдачі. Саме тому конструкції, що поєднують детерміністичні та навчені механізми, виглядають переконливішими, ніж використання ШІ у кожному компоненті. Нейросимболічні підходи в кібербезпеці вказують у тому ж напрямку: навчені частини сприяють розпізнаванню патернів, тоді як симболічні чи базовані на правилах елементи забезпечують чітке міркування та контроль (Bizzarri та ін., 2025).

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

Та сама дисципліна для багатоагентних систем

Системи з кількома агентами також заслуговують на таку саму ретельну перевірку. Як тільки команда усвідомлює, що одна велика модель не повинна керувати всім, легко перестрахуватися та розділити все на окремі агенти, оскільки це виглядає більш складним. Кількість агентів не є підставою для такого підходу. Дизайн із кількома агентами має сенс тоді, коли обов’язки справді розділені: різна експертиза, інструменти, дозволи чи джерела даних, або робота, яка може виконуватися паралельно. Шен та співавтори (2024) дослідили дизайн із кількома LLM для використання інструментів, у якому планування, виклик інструментів та узагальнення були розділені, і саме це розділення принесло позитивні результати.

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

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

Де відбуваються обчислення

Вибір механізму — це лише половина проблеми, адже його ще потрібно де-небудь запустити. Локальні пристрої, інфраструктура на периферії та хмарні платформи мають свої переваги та обмеження, і дослідження у сфері спільних обчислень розглядають можливість розподілу обробки даних між ними замість припущення, що весь обсяг роботи має знаходитися лише в одному місці (Zhou et al., 2019; Ren et al., 2023).

Ніщо тут не працює у всіх випадках. Робота локально не обов’язково є швидшою, адже апаратне забезпечення кінцевого пристрою може бути слабким, тоді як налаштований хмарний сервіс виконує завдання швидше. Робота в хмарі також не є автоматично кращою, оскільки затримки мережі, пропускна здатність, чутливість даних чи вимоги до безперервної роботи можуть змінити ситуацію. Питання приватності складніше, ніж просте твердження „локально – означає приватно“. Зберігання необроблених даних на пристрої зменшує кількість передаваних даних, проте проміжні форми, створені під час розділеної чи спільної обробки, все одно можуть розкрити конфіденційну інформацію. Хіггінс та інші (2025) досліджують ризики реконструкції та інференції в умовах розділеного навчання.

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

Приклад дослідження у сфері захисту від шахрайства

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

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

Рівень 0: фільтрація та сортування

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

Рівень 1: координація та пояснення

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

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

Шар 2: спеціалізовані аналітичні агенти

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

Цікавим є не стільки кількість трьох шарів, скільки ідея, яку вони передають: обчислювальні можливості мають бути пропорційними до проблеми, яку потрібно вирішити.

Що показало демонстраційне рішення

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

Було пропущено кілька аспектів: повний робочий процес для рівня 0 у продакшені, безперервна інтеграція з Microsoft 365 чи Google Workspace, OCR у продакшені, федеративне навчання, виявлення локальних аномалій за допомогою VAE, обробка даних у конфіденційному режимі та виявлення глибоких фейків у аудіо чи відео. Обсяг завдань має значення. Доказ концепції показує, що такий робочий процес є доцільним. Однак він нічого не доводить щодо точності у продакшені, масштабованості чи переваг повноцінної трьохрівневої архітектури.

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

Складність має свою ціну

Гетерогенна архітектура — це не безкоштовно:

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

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

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

Почніть з завдання

Перш ніж обирати модель, краще поставити низку простіших запитань:

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

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

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

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

Згадані дослідження

• Chen, Zaharia та Zou (2024): FrugalGPT – використання каскадних мовних моделей для скорочення витрат
• Ong та ін. (2025): RouteLLM – навчання для вибору маршруту між моделями на основі даних про переваги
• Ding та ін. (2025): BEST-Route – адаптивне маршрутизування з використанням ресурсів під час тестування
• Pecher, Srba та Bielikova (2025): невеликі спеціалізовані моделі проти великих універсальних моделей для класифікації тексту
• Bizzarri та ін. (2025): огляд нейросимболічних ШІ для виявлення вторгнень у мережу
• Shen та ін. (2024): багатоагентний агент для навчання інструментів
• Wang та ін. (2024): чи покращує багатоагентна дискусія міркування ШІ
• Li та ін. (2024): розріджена топологія комунікації у багатоагентних дебатах
• Zhou та ін. (2019) та Ren та ін. (2023): огляди щодо інтелекту на периферії та спільного виконання нейронних мереж

Higgins та ін. (2025): навчання з розділенням даних зі збереженням приватності проти адверсарських спроб інтерпретації