Правильний вибір розміру LLM: маршрутизація, отримання даних та оцінка замість простого вибору за розміром моделі.
Дізнайтеся, як обирати між невеликими та великими мовними моделями з урахуванням обсягу роботи, оцінюйте витрати на кожне успішне завдання та спочатку використовуйте механізми маршрутизації, RAG, кешування та верифікації.
Кількість параметрів дозволяє створювати прості заголовки, і є спокуса вважати їх показником якості продукту: модель на 70 мільярдів параметрів має бути кращою за модель на 7 мільярдів, тож найбільша модель, яку ви можете собі дозволити, має бути безпечним вибором. Однак у реальних умовах цей швидкий підхід швидко виявляється неефективним. Більші моделі зазвичай коштують більше за один запит, реагують повільніше, збільшують навантаження на інфраструктуру та часто вирішують проблеми, яких у вашому додатку ніколи не було. Цей посібник показує, як обирати модель з урахуванням обсягу роботи, а не її розміру, як одночасно оцінювати витрати, затримки та ризики невдачі, а також які архітектурні елементи (маршрутизація, отримання даних, перевірка, кешування та сам код) зазвичай дають кращі результати, ніж просте оновлення.
Чому принцип „чим більше, тим краще“ перестає працювати в реальних умовах
Інтуїція зрозуміла. Інженери програмного забезпечення протягом десятиліть спостерігали, як оновлення апаратного забезпечення приносять користь: швидший процесор, більше оперативної пам’яті, більші диски та сучасніший графічний процесор майже завжди є покращеннями. Коли моделі мов стали більшими та здатнішими, здавалося природним перенести цю ментальну модель. Якщо одна модель міркує краще за іншу, чому хтось мав би навмисно обирати слабшу?
Відповідь з’являється у ту мить, коли модель використовує реальні функції. Запитання, яке ви ставите, змінюється з «Яка модель найрозумніша?» на «Яка модель дасть найкращий результат для цієї конкретної задачі?» Це зовсім різні запитання. Найбільша за розміром модель може дати трохи кращу відповідь, але працювати набагато повільніше. Її використання може коштувати у кілька разів більше. Для простого кроку класифікації вона може бути марною, генерувати занадто довгі відповіді, які не може відобразити інтерфейс, спалювати ресурси контексту та ускладнювати процес розгортання. Найголовніше — вона може вирішувати проблему, якої насправді немає.
Почніть з обсягу роботи, а не з кількості параметрів
Більш надійний спосіб вибору моделі — це початок з опису самої роботи. Перш ніж порівнювати будь-які моделі, відповідайте на ці запитання:
- Як виглядає вхідні дані?
- Який результат очікується?
Останнє запитання є справжнім інженерним питанням, і решта цього посібника присвятована його відповіді: чому найбільший модель не є автоматично найкращою, як вибирати між малими та великими моделями, коли велика модель справді варта своєї вартості та як виглядає розумний дизайн для продакшену.
Один продукт підтримки, два абсолютно різні обсяги роботи
Розгляньмо додаток підтримки для корпорацій. Користувач вводить «Скиньте моє пароль». Що повинен робити шар ШІ в цьому випадку? Найімовірніше, він просто розпізнає намір користувача та прив’язує його до певної мітки, щоб додаток міг передати запит на обробку за фіксованою, детермінованою схемою.
PASSWORD_RESET
Для прив’язки до такої мітки не потрібна складна модель міркувань. Надсилання цього запиту через таку модель було б сумнівним рішенням з точки зору проектування, адже його цілком може обробити проста модель чи навіть збіг ключових слів та правил.
Тепер уявімо інший запит: європейські клієнти зустрічають періодичні проблеми з оплатою з моменту впровадження вчора, і користувач хоче, щоб система порівняла зміни після впровадження з журналами операцій служби оплат, виявила ймовірні причини проблем, визначила, чи пов’язано це з новим механізмом перепробувань, та запропонувала план скасування змін. Для обробки такого запиту потрібно набагато більше.
- отримання відповідних змін у розгортанні та журналів подій
- велика кількість контексту
- здатність читати та розуміти код
- аналіз вихідних даних журналу
- міркування, що охоплюють кілька кроків
- кореляція подій у різних системах
- чітке технічне пояснення
- чесне ставлення до невизначеності
Тут більш потужна модель справді може додати цінності. Помилкою є не використання великої моделі, а сприйняття цих двох запитів як однакового обсягу роботи.
Функціональне визначення цінності моделі
Корисний спосіб сформулювати вибір — це приблизна гіпотеза:
Цінність моделі = можливості × надійність × корисність ÷ витрати
Це не формула, яку потрібно обчислити. Це спосіб мислення. Модель, яка на 10% ефективніша, але в п’ять разів дорожча та у три рази повільніша, не є автоматично кращим варіантом для виробництва. Так само поганим вибором є модель, яка дуже дешева, але ненадійна для вашої задачі. Те, що ви оптимізуєте, — це не максимальна інтелектуальність, а найкорисніша інтелектуальність за одиницю витрат, затримки та складності.
Чому великі моделі є привабливими та де з’являються обмеження
Віддавати перевагу великим моделям — це не ірраціонально, адже вони мають реальні переваги. Вони часто краще справляються зі складним міркуванням, демонструють більш стабільну продуктивність у різних завданнях, більш гнучко інтерпретують нечіткі вказівки, ефективніше працюють із складними кодовими базами, потребують менше специфічних підказок та можуть бути набагато потужнішими у справді складних завданнях.
То чому б не використовувати найсильнішу модель скрізь? Тому що у продакшені існують обмеження, про які рідко йдеться у таблицях лідерів. Уявіть ендпоїнт, який обробляє 100 000 запитів на день. Якщо більша модель коштує значно більше за кожен виклик, ця різниця більше не залишається абстрактною — вона впливає на бюджет інфраструктури. Якщо більша модель також працює повільніше, користувачі це помічають. Якщо вона схильна до довгих відповідей, зростає кількість витрачених токенів. А якщо додаток виконує тисячі дрібних завдань, надсилання кожного з них до складної моделі міркувань — це просто марнотратство.
Вибір моделі — це проблема оптимізації, а не конкурс популярності.
Модель, яка знаходиться на вершині таблиці тестування, не обов’язково є тією, яка створює найкращий додаток.
Кількість параметрів — це лише один з показників
Порівняння моделей часто зосереджуються лише на розмірі: 7B, 13B, 34B, 70B, сотні мільярдів. Сам розмір мало що говорить про придатність моделі. Практичне порівняння враховує кілька параметрів одночасно, наприклад:
- здатність до виконання конкретного завдання
- затримка — час отримання першого токена та загальний час генерації
- витрати за запит та за успішно виконане завдання
- пропускна здатність при очікуваному навантаженні
- розмір контексту, який насправді потрібен для виконання завдання
- надійність та послідовність під час багаторазових запусків
- варіанти розгортання, включаючи локальне чи приватне хостинг
- контрольованість
Контрольованість заслуговує на особливу увагу, оскільки її легко проігнорувати. Модель може бути дуже потужною, але важкою для контролю. У корпоративних робочих процесах передбачувана поведінка часто має більшу цінність, ніж креативність.
Структуроване вилучення — це інша мета
Візьмемо, наприклад, вилучення рахунків-фактур. Ця функція потребує формату, схожого на наведений нижче, а не ретельного опису документа.
{
"invoiceNumber": "...",
"invoiceDate": "...",
"vendor": "...",
"total": 0
}
Тут важливим є надійний, правильно сформований результат, який код на наступних етапах може завжди обробити. Це окрема мета оптимізації, відмінна від загальної здатності до міркувань, і менші або більш обмежені моделі часто добре її досягають, особливо у поєднанні з перевіркою схеми.
Затримка: перша пастка у продакшені
У демо-версії шестисекундне очікування здається прийнятним. Результат є вражаючим, ви ділитеся ним з командою, і всі задоволені. Але якщо розмістити такий самий процес за кнопкою у реальному додатку, ситуація змінюється: користувач натискає, з’являється індикатор завантаження, і минають три, п’ять чи вісім секунд. У цей момент ніхто вже не захоплюється інтелектом моделі — всі дивуються, чому додаток працює так повільно.
Затримка є характеристикою продукту, і в інтерактивному програмному забезпеченні вона має величезне значення.
Чому більші моделі зазвичай реагують повільніше
Точна залежність залежить від багатьох факторів: архітектура моделі, обладнання, технології обробки даних, квантування, групування запитів, кількість генерованих токенів, розмір запиту та конструкція моделі. Однак загалом більш ресурсоємкі моделі потребують більше ресурсів на кожен токен і можуть повертати результати повільніше. Це має найбільше значення у:
- інтерфейси чату
- асистенти з кодуванням та автодоповнення
- голосові асистенти
- інструменти підтримки клієнтів
- інтерактивні панелі керування
- робочі процеси з агентами, де час очікування накопичується на кожному етапі
Автодоповнення чітко ілюструє це. Пропозиція коду, яка генерується протягом п’яти секунд, вже не є автодоповненням — це перервання роботи. Модель меншого розміру, яка відповідає майже миттєво, часто є набагато кориснішою, ніж більш потужна модель, яка змушує розробника чекати.
Стрімінг покращує сприйняття, а не обчислення
Стрімінг — це стандартний спосіб зробити час очікування менш відчутним. Без нього користувач нічого не бачить, поки не буде готова повна відповідь:
[wait...]
Hello! Here is the answer...
За допомогою стрімінгу текст з’являється на екрані по мірі надходження токенів:
Hello
Hello, here
Hello, here is
Hello, here is the
Hello, here is the answer...
Необхідно чітко розрізняти ці аспекти. Стрімінг зменшує сприйняту затримку, оскільки перші слова з’являються швидко, але він не скорочує кількості обчислень чи загальний час до отримання результату. Це покращення користувацького досвіду, а не оптимізація продуктивності, і воно не має жодного впливу на неконверсаційні етапи, такі як класифікатор у межах пайплайну.
Витрати: вимірюйте їх за кожним успішним завданням
Саме на цьому етапі багато прототипів перетворюються на дорогі системи. Під час розробки витрати здаються незначними: один інженер надсилає кілька запитів, і ніхто не думає про рахунок. Однак коли починається справжній трафік, кожен запит може містити значно більше інформації, ніж просто повідомлення користувача:
- багато одночасних користувачів
- кілька запитів за сеанс
- довгі запити
- отримані документи
- результати роботи інструментів
- історія розмови
- сформовані відповіді
Обсяг токенів швидко зростає, і вибір моделі починає мати велике значення.
Більш об’єктивним показником, ніж ціна за один виклик, є вартість правильного виконання завдання. Порівняймо дві гіпотетичні моделі (цифри наведені для ілюстрації, а не як результати тестування):
- Модель A: 0,01 долара за запит, точність виконання завдання — 90%, приблизно 1,11 запитів потрібно на один успішний результат, що дорівнює приблизно 0,011 долара за успішне завдання.
- Модель B: 0,05 долара за запит, точність виконання завдання — 96%, приблизно 1,04 запитів потрібно на один успішний результат, що дорівнює приблизно 0,052 долара за успішне завдання.
Очікувана кількість спроб дорівнює просто одному поділеному на показник успішності, тож витрати за кожен успіх — це вартість запиту поділена на рівень точності. Якщо модель B коштує в п’ять разів більше, проте покращує результати лише незначно, бізнес може обґрунтовано віддати перевагу моделі A. Ситуація змінюється, коли неправильна відповідь має серйозні наслідки — наприклад, коли це призводить до повернення грошей, проблем зі виконанням вимог чи перерв у роботі. Саме тому витрати завжди потрібно оцінювати разом із наслідками невдачі, а не окремо.
Занадто великі моделі для недостатньо складних проблем
Поширений антипаттерн виглядає так: кожне надіслане повідомлення класифікується як скарга, запитання чи заява на повернення грошей, і кожне з них потрапляє до найскладнішої доступної моделі. Причина — зручність: один API, один запит, одна модель — і все готово. Але архітектура полягає не у тому, щоб зробити один компонент здатним на все; вона полягає у тому, щоб підбирати для кожної задачі відповідний компонент. Для простої класифікації існують такі варіанти:
- детерміністичні правила
- ембеддинги
- невелика мовна модель
- спеціалізований класифікатор
- більша модель, призначена для випадків низької впевненості
Останній варіант призводить до одного з найефективніших паттернів у продакшені.
Ескалація: дорога модель як обробник винятків
У наївному дизайні все надсилається безпосередньо до великої моделі:
Every request
↓
Large model
Дизайн з ескалацією дозволяє спочатку використовувати дешеву модель та перевіряти її рівень впевненості:
Every request
↓
Small/cheap model
↓
Confidence check
↓
┌───────────────┐
│ │
High confidence Low confidence
│ │
Fast answer Large model
Відповіді з високим рівнем впевненості повертаються негайно; лише сумнівні випадки передаються до більш потужної моделі. Дорога модель більше не є стандартним варіантом обробки та стає обробником винятків. Цей підхід залежить від наявності надійного сигналу впевненості – наприклад, скорингу класифікатора, узгодженості результатів різних методів чи верифікатора, який може відхилити некоректний результат; тому необхідно вимірювати, як часто низькоякісні відповіді проникають через гілку „висока впевненість“, перш ніж покладатися на неї.
Розподіл запитів між різними рівнями моделей
Як тільки ви починаєте мислити таким чином, моделі перестають виглядати як конкуренти та починають здаватися спеціалізованими працівниками. Маршрутизатор запитів може знаходитися перед кількома рівнями та обирати відповідний для кожного запиту, з спільним кроком перевірки перед тим, як щось дістанеться користувачеві:
User Request
|
v
Request Router
|
+-----------+-----------+
| | |
v v v
Simple Medium Complex
| | |
v v v
Small LLM Mid Model Large Model
| | |
+-----------+-----------+
|
v
Validation Layer
|
v
Response
Маршрутизатору потрібне поняття складності. Найпростіша версія — це невеликий набір категорій:
SIMPLE
MEDIUM
COMPLEX
Логіка розподілу може бути настільки простою, як перемикач за рішенням класифікатора. Наведений нижче приклад написаний на C#, але мова є другорядною; така сама структура чудово підходить для сервісу на TypeScript.
public async Task<string> ProcessAsync(Request request)
{
var complexity = await classifier.ClassifyAsync(request);
return complexity switch
{
Complexity.Simple =>
await smallModel.GenerateAsync(request),
Complexity.Medium =>
await mediumModel.GenerateAsync(request),
Complexity.Complex =>
await largeModel.GenerateAsync(request),
_ => throw new InvalidOperationException()
};
}
Важливим є архітектурний підхід, який обирає код: не кожен запит заслуговує на максимальний рівень інтелектуалізації. Якщо це рішення застосовувати послідовно, воно може драматично змінити економічну ефективність системи ШІ. Зауважте, що сам класифікатор додає кожному запиту додатковий виклик та певну затримку, тому він має бути значно дешевшим за моделі, до яких він направляє запити; крім того, невідома категорія має спричиняти чіткий сигнал про помилку, як це робить стандартний варіант обробки.
Коли проблема — це знання, а не інтелект
Ще одним поширеним рефлексом є: «Модель не знає нашої внутрішньої документації, тож давайте перейдемо на більшу модель». Розмір не вирішує проблеми браку знань. Коли інформація є ексклюзивною, нещодавньою чи сильно специфічною для певної галузі, проблемою є доступ до знань, а не здатність до міркувань. Саме цю проблему вирішує технологія Retrieval-Augmented Generation (RAG). Основний алгоритм роботи виглядає так:
User Question
|
v
Embedding / Retrieval
|
v
Relevant Documents
|
v
Prompt + Retrieved Context
|
v
Language Model
|
v
Answer
Якщо користувач запитує про внутрішню політику повернення грошей вашої компанії для корпоративних клієнтів, жодна універсальна модель, якою б великою вона не була, не знає відповіді. Ви повинні надати відповідний текст у запиті. Щоб детальніше дізнатися, як працює цей крок отримання інформації, перегляньте наш посібник про те, як системи RAG отримують свіжі знання за потребою.
Виправте канал передачі інформації до моделі
Це призводить до принципу, який варто прийняти як правило:
Покращуйте те, що ви подаєте моделі, перш ніж оновлювати саму модель.
Команди часто намагаються виправити погані відповіді, переходячи на більш потужну модель, хоча справжня причина лежить в іншому:
- слабке отримання інформації
- нерелевантні документи
- відсутня метадана
- погане розділення на частини
- недостатній контекст
У таких випадках проблемою є не сама модель, а процес обробки інформації.
Якість контексту важливіша за його кількість
Великі вікна контексту справді вражаючі, але більше контексту не означає автоматично кращого результату. Надання моделі 200 сторінок документації, коли відповідь міститься у двох абзацах, технічно забезпечує її інформацією, але на практиці ускладнює завдання, оскільки тепер їй потрібно знаходити корисну інформацію серед шуму. Надмірний обсяг контексту зазвичай призводить до:
- підвищеного споживання токенів
- затримки
- підвищених витрат
- відволікань
- ймовірності наявності суперечливої інформації
Кращою метою є використання найменшої кількості високоякісного контексту, яка все одно дозволяє моделі правильно відповісти. Саме тому зрілі системи RAG інвестують значні ресурси у шар пошуку, використовуючи такі методи, як:
- семантичний та гібридний пошук
- фільтрація за метаданими
- переписування запиту користувача
- переурочення пріоритетів кандидатських уривків
- підтримання актуальності документів
- створення належним чином сформованих фрагментів
Галюцинації вимагають перевірки, а не більшої моделі
Неприємна правда: використання достатньо потужної моделі не змушує галюцинації зникати. Сильніші моделі дійсно частіше правильно визначають факти та краще міркують у різних завданнях, проте мовна модель залишається генератором тексту, а не джерелом істини, яке можна запитувати, як базу даних. Тож рішення має бути у самому дизайні: слід додати явну перевірку у процес обробки, наприклад:
User Request
↓
Retrieve Evidence
↓
Generate Answer
↓
Validate Claims
↓
Return Response
Для важливих робочих процесів це можна посилити за допомогою:
- цитат, які вказують на докази
- структурованих результатів, перевірених за схемою
- перевірки відповідності бізнес-правилам
Нехай модель міркує, а програмне забезпечення дотримується правил
Це створює важливий розділ у архітектурі. Якщо від моделі вимагають обчислити загальну суму рахунку-фактури, немає причин довіряти її арифметиці, коли ваше додатку може виконати ці обчислення точно. Краще розділити обов’язки:
Model:
Extract line items
Application:
Calculate subtotal
Application:
Calculate tax
Application:
Calculate total
Model:
Explain the result
Модель витягує окремі позиції та пояснює результат; додаток обчислює суму до оподаткування, податок та загальну суму. Кожна частина виконує те, у чому є надійною, і числа, які бачить користувач, завжди є правильними за своєю конструкцією.
Де проявляють себе невеликі моделі та де вони не справляються
Малі мовні моделі часто вважаються „менш розумними“, що технічно є правдою в багатьох ситуаціях. Але інженерія — це не лише питання розуму, і малі моделі мають конкретні переваги:
- нижча вартість обробки даних
- нижча затримка
- простіше розгортання на локальних пристроях
- менші вимоги до інфраструктури
- потенційно вища продуктивність
- легше масштабування
- ідеально підходять для вузькоспеціалізованих завдань
- корисні у сценаріях роботи на периферійних пристроях
- потенційно краща конфіденційність під час роботи локально
Вони особливо корисні для класифікації, вилучення інформації, створення резюме, маршрутизації, автодоповнення, простих трансформацій та робочих процесів, специфічних для певної галузі. Якщо ви хочете детальніше дізнатися про цю тенденцію, наш огляд невеликих спеціалізованих моделей, які ефективніше працюють за гігантськими LLM розглядає це питання більш глибоко.
Проте невеликий розмір не означає автоматично кращої якості. Деякі завдання виходять за межі того, що невелика модель може виконувати надійно: складне міркування на основі багатьох джерел, аналіз складного коду, складні проблеми планування чи тонке тлумачення інформації. У таких випадках більш потужна модель може виправдати свою вартість. Обидва крайнощі є поганою порадою. „Завжди використовувати найбільшу“ — це марнування грошей, а „завжди використовувати найменшу“ — це низька якість результату. Краще правило:
Використовуйте найменшу модель, яка відповідає пороговим значенням якості вашого застосунку.
Обчислювальні завдання, які виправдовують використання великої моделі
Жоден з цих аргументів не є запереченням проти великих моделей. Вони надзвичайно корисні, і певні обчислювальні завдання однозначно компенсують додаткові можливості.
Складне багатокрокове міркування
Коли функціонал залежить від послідовних міркувань, потужніша модель може забезпечити значно кращі результати.
Робота з жорстко закодованим кодом
Великі моделі стають корисними при складних вимогах, незнайомих кодових базах, архітектурних рішеннях та складних сеансах виправлення помилок.
Неоднозначна природна мова
Деякі запити не підпадають під заздалегідь визначені категорії. Потужніша модель зазвичай краще розуміє нюанси та наміри.
Синтез з багатьох документів
Коли відповідь вимагає поєднання інформації з багатьох джерел, ще важливішими стають можливості моделі.
Агентні робочі процеси
Агент зазвичай мусить:
- зрозуміти мету
- спланувати дії
- вибрати інструменти
- перевірити результати
- відновитися після невдач
- скоригувати план
- завершити завдання
Це набагато складніше, ніж класифікація, тому наявність потужнішої моделі є цілком обґрунтованою. У кожному випадку тест один і той самий: використовувати великі моделі там, де їхні додаткові можливості створюють вимірюваний ефект.
Операційні витрати розумної архітектури
Існують витрати, які ніколи не показують тестування: складність архітектури. Найпростішим можливим дизайном є одне застосування, одна велика модель, одна відповідь:
Application
↓
Large Model
↓
Response
Тепер уявіть оптимізацію всього одночасно:
Application
↓
Router
↓
Classifier
↓
Small Model
↓
Confidence Evaluator
↓
RAG
↓
Reranker
↓
Large Model
↓
Validator
↓
Fallback Model
↓
Human Review
Цей конвеєр може дійсно створити кращу систему, але водночас вводить значно більше компонентів, і кожен з них приносить:
- додатковий моніторинг та журнали
- нові способи збоїв
- більшу площу для тестування
- додаткову інфраструктуру для роботи
- складнішу процедуру розгортання
- більше знань, які команда повинна мати для її функціонування
Тому оптимізація має бути усвідомленою. Створення архітектури з семи моделей заради економії кількох центів на запит рідко є хорошою угодою; додавайте кожен шар лише тоді, коли показники свідчать про те, що його утримання є виправданим.
Оцінюйте на основі власного обсягу роботи, а не за таблицями лідерів
Публічні бенчмарки є лише відправною точкою, а не основою для прийняття рішень. У вашому додатку є власний бенчмарк, і саме він має значення. Для асистента з перегляду коду на основі ШІ набір для оцінки може включати:
- Вразливості типу SQL injection
- Умови змагання
- Баги, пов’язані з null-референцями
- Недоліки авторизації
- Неправильна обробка винятків
- Проблеми з продуктивністю
- Порушення архітектурних принципів
Для асистента підтримки клієнтів потрібно вимірювати різні показники:
- Дотримання правил
- Точність інформації
- Тон спілкування
- Точність передачі інформації на вищий рівень підтримки
- Поведінка при відмові
- Дійсність структурованого результату
Набір для оцінки має якомога більше нагадувати реальний трафік.
Створення інструменту для порівняння
Основна процедура проста: збирати запити, схожі на реальні, із очікуваними результатами, працювати кожною з моделей із ними та порівнювати результати.
Production-like prompts
↓
Expected outcomes
↓
Run Model A
↓
Run Model B
↓
Compare
↓
Measure
Корисні показники для запису під час кожного запуску:
- Правильність та завершення завдання
Завдяки цьому вибір моделі стає інженерним рішенням, а не припущенням, і ви можете знову запустити той самий інструментарій щоразу, коли постачальник випускає нову версію моделі.
Чотирикроковий процес вибору моделі
Для нової функції ШІ добре підходить простий, повторюваний процес.
Крок 1: Точно визначте завдання
Не починайте з питання «Яку модель нам використати?» Почніть з питання «Що саме має зробити модель?» та запишіть відповідь у конкретних термінах:
Input:
Customer email
Output:
Intent + urgency + recommended workflow
Така специфікація з чітким вхідним та вихідним даними набагато корисніша, ніж розпливчаста мета.
Крок 2: Визначте, що означає «достатньо добре»
Встановіть чіткі критерії прийнятності ще до тестування чого-небудь. Наприклад:
Intent accuracy >= target threshold
Structured output must always validate
Response should normally arrive within target latency
Фактичні порогові значення залежать від додатку; важливо те, щоб вони існували ще до порівняння моделей, щоб пізніше не можна було виправдовувати результати.
Крок 3: Спочатку спробуйте найменшу працездатну модель
Це крок, який команди найчастіше пропускають. Почніть з малого, виміряйте результати та зупиніться, якщо все пройде успішно. Переходьте до наступного кроку лише у разі невдачі:
Small Model
↓
Evaluation
↓
Pass? ── Yes → Ship
|
No
↓
Larger Model
↓
Evaluation
↓
Pass? ── Yes → Ship
|
No
↓
Stronger architecture/model
Фактично ви піднімаєтесь по драбині можливостей, крок за кроком, причому кожен крок потрібно здобути через невдалий аналіз.
Крок 4: Оптимізуйте навколишню систему
Перш ніж перейти на наступний рівень, перевірте решту системи:
- Чи повертає процес пошуку правильний матеріал?
- Чи є запит чітким та однозначним?
- Чи кожен елемент контексту справді є релевантним?
- Чи перевіряється результат перед використанням?
Покращення в цій сфері іноді зовсім усувають потребу у більш складній моделі.
Інші заходи, які варто вжити перед оновленням
Інструкції як контракти
Інженерія інструкцій — це не магія, але погано сформульоване завдання може змусити навіть потужну модель погано працювати. Порівняйте нечітку інструкцію:
Analyze this customer message.
з тією, яка визначає очікуваний результат та правила для ситуацій невизначеності:
Analyze the customer message.
Return JSON with:
- intent
- urgency
- sentiment
- recommended_action
Do not invent information that isn't present.
If the intent is unclear, return "unknown".
Друга версія надає моделі чіткі умови використання: іменовані поля, пряма заборона на вигадування фактів та визначене значення за замовчуванням. Додавання кількох прикладів часто ще більше покращує результати. Однак існує межа — жоден варіант формулювання запиту не може надати моделі здібностей, яких у неї фундаментально бракує, а коли така здібність відсутня, корективи запиту приносять все менший ефект. Розглядайте формулювання запитів як один із етапів оптимізації, а не як повне рішення.
Тонку налаштування, RAG чи перевірка?
Ще однією поширеною реакцією на слабкі результати є фраза «давайте проведемо тонку налаштування». Іноді це справді правильно, але спочатку потрібно діагностувати проблему:
- Якщо у моделі бракує актуальних чи специфічних для компанії знань, наприклад сучасної політики, отримання інформації зазвичай є кращим варіантом, ніж тонке налаштування, оскільки знання змінюються, а перенавчання — повільне.
Підбір правильного рішення до конкретної проблеми допомагає заощадити як час, так і гроші.
Кешування: нудна, але ефективна оптимізація
Кешування не є привабливим з точки зору вигляду, але дуже ефективним. Якщо користувачі постійно запитують „Яка у вас політика повернення?“, немає сенсу кожного разу викликати модель. Якщо відповідь стабільна, її потрібно зберегти в кеші. У наведеному нижче прикладі на C# спочатку перевіряється кеш, модель викликається лише у разі його відсутності, а результат зберігається протягом 30 хвилин:
public async Task<string> GetAnswerAsync(string question)
{
var key = CreateCacheKey(question);
var cached = await cache.GetStringAsync(key);
if (cached is not null)
return cached;
var answer = await model.GenerateAsync(question);
await cache.SetStringAsync(
key,
answer,
TimeSpan.FromMinutes(30));
return answer;
}
Справжнє семантичне кешування є складнішим за пряме зіставлення рядків, адже два запити з різною формулюванням можуть потребувати однакової відповіді, і потрібна політика для анулювання відповідей у разі зміни основних фактів. Архітектурна ідея залишається незмінною:
Найшвидший запит до ШІ — це той, якого ви ніколи не формулюєте.
Той самий принцип застосовується до усунення дублікатів, попереднього обчислення, детермінованих відповідей, повторного використання результатів пошуку, кешування префіксів запитів у разі підтримки цього постачальником, а також до простого повторного використання відповідей. Перш ніж оплачувати додаткові обчислювальні ресурси, усуньте ті, які вам не потрібні.
Розглядайте токени як бюджет ресурсів
Як тільки ви починаєте розглядати систему ШІ як розподілену систему, токени стають ще одним ресурсом, який потрібно керувати. Традиційні сервіси керують процесором, пам’яттю, мережею та зберіганням. Додатки ШІ додають вхідні токени, вихідні токени, розмір контексту та час обробки, що робить проектування запитів проблемою продуктивності.
Розгляньте можливість надсилання повної історії розмови з кожним запитом. Запити постійно збільшуються, до них додаються отримані документи, результати роботи інструментів, інструкції системи та попередні дії агента. Просте запитання може мати величезний обсяг даних. Більш оптимізоване проектування передбачає вибір лише релевантної історії перед отриманням даних та створення компактного контексту:
Conversation
↓
Relevant history selection
↓
Retrieval
↓
Compact context
↓
Model
замість того, щоб передавати все, що система коли-небудь бачила:
Everything we've ever seen
↓
Model
Більше контексту — це ніколи не безкоштовно: ви платите за це грошима, затримками та, часто, якістю відповідей.
Агенти множать кожне з цих рішень
Системи з агентами роблять вибір моделей ще більш значущим. Одна запит користувача може розгалужуватися на багато кроків:
User Request
↓
Planning
↓
Tool Selection
↓
Search
↓
Database Query
↓
Code Execution
↓
Analysis
↓
Final Response
Якщо кожен крок виконується за допомогою найдорожчої моделі, витрати можуть стрімко зрости. Проте крокам рідко потрібні однакові можливості. Змішане призначення може виглядати так:
Intent classification → Small model
Simple tool selection → Small model
Complex planning → Large model
Data extraction → Small model
Final explanation → Medium model
Це гетерогенна архітектура ШІ, і саме до неї прямують багато продакшн-систем: не одна величезна модель, яка робить усе, а кілька моделей, інструментів, детермінованих компонентів, каналів отримання даних та верифікаторів, які працюють разом. Наша стаття «Чому витрати на агентське ШІ зростають» детальніше розглядає аспекти витрат у цьому контексті.
Уявіть моделі як членів команди
Корисна аналогія: уявіть трьох інженерів. Один — дуже досвідчений, дорогий та перевантажений роботою. Інший — досвідчений та ефективний. Третій — молодший, але дуже швидкий у виконанні повторюваних завдань. Ви не будете доручати кожне завдання старшому інженеру. Ви будете розподіляти роботу за складністю:
Simple repetitive task
→ Engineer C
Normal feature
→ Engineer B
Complex architecture problem
→ Engineer A
Моделі можна розглядати так само. Менша модель не є „поганою“; вона може просто підходити для виконання більш обмежених завдань. Ключова навичка — розділення роботи на частини. Замість пошуку однієї моделі, яка впорається з усім, розділіть робочий процес так, щоб кожен компонент виконував ту частину, яку він робить найкраще. Такий підхід дозволяє краще масштабуватися.
Об’єднання елементів: архітектура для посилань
Об’єднавши ці ідеї, корпоративного AI-асистента можна структурувати ось так:
User
|
v
API / Gateway
|
v
Request Router
|
+-------------+-------------+
| |
v v
Simple Request Complex Request
| |
v v
Small Model Planner
|
+------------+------------+
| | |
v v v
Search Database Tools
| | |
+------------+-------------+
|
v
Context
|
v
Strong Model
|
v
Validator
|
+------+------+
| |
Valid Invalid
| |
v v
Response Retry/Fallback
Зверніть увагу на те, що не відбувається: найпотужніша модель не змушена виконувати все. Прості запити надсилаються до менш потужної моделі. Складні запити проходять через планувальник, який збирає дані з пошуку, баз даних та інструментів, і лише потім потужна модель працює з підготовленим контекстом. Валідатор перевіряє результат, а недійсні результати спричиняють повторну спробу або використання запасного рішення. Дизайн ґрунтується на:
- маршрутизаторі, який обирає шлях
- засобах отримання та обробки даних
- детерміністичних системах для точної роботи
- моделях, спеціалізованих за роллю
- механізмах валідації, повторних спроб та запасних рішень
Тут модель є лише частиною системи, а не всією системою.
Десять постійно повторюваних помилок
- Спочатку обирають модель, а проблему описують пізніше. Цей порядок є неправильним; спочатку необхідно чітко визначити обсяг роботи.
Чек-лист для прийняття рішення щодо вибору моделі
Коли потрібно вирішити, яку модель обрати, розгляньте ці запитання у порядку:
- Чи може детерміністичний код це вирішити? Якщо так, напишіть код. Не використовуйте ШІ лише через те, що він доступний.
- Чи є завдання простим та повторюваним? Спробуйте використати невелику модель.
Цей чек-лист набагато корисніший, ніж просте запитання про те, яка модель є найбільшою серед доступних.
Питання, яке варто поставити старшим інженерам з ШІ
Корисне питання під час співбесіди на посаду з архітектури ШІ: "Чому б просто не обирати найсильнішу модель на ринку для всього?"
Слабка відповідь обмежується фразою «менші моделі коштують дешевше». Це правда, але неповна. Сильна відповідь враховує можливості моделі для конкретного завдання, надійність, затримку та пропускну здатність, вартість, кількість необхідного контексту, маршрутизацію між моделями, процес отримання даних, функції, які має виконувати код, методи оцінки, витрати у разі збою та операційне навантаження.
Природним наступним запитанням є: «Як ви доведете, що обрана модель достатньо якісна?» Відповідь має стосуватися оцінки, а не думок, постів у соціальних мережах, скріншотів табелей лідерів чи презентацій постачальників. Вирішальними є ваше обсяг роботи, ваші дані та ваші показники.
Поетапна оптимізація існуючого додатку
Коли функція ШІ працює занадто повільно або коштує занадто дорого, стримуйте бажання негайно замінити модель. Натомість досліджуйте ситуацію систематично:
- Вимірювання. Збирайте дані про кількість запитів, кількість вхідних та вихідних токенів, затримку, частоту помилок, рівень успішності завдань та витрати на роботу моделі.
- Визначення дорогих завдань. Встановіть, які типи запитів споживають найбільше ресурсів.
- Видалення зайвих викликів. Використовуйте кешування, детерміновану логіку, усунення дублікатів та попередню обробку даних.
- Зменшення обсягу контексту. Видаляйте нерелевантну історію та документи.
- Покращення процесу пошуку. Повертайте більш корисні дані замість великої кількості інформації.
- Спробуйте меншу модель. Перевірьте, чи залишається якість прийнятною.
- Впровадження механізму маршрутизації. Надсилайте лише складні випадки до більш потужних моделей.
- Перевірка важливих аспектів. За потреби застосовуйте схеми, правила, інструменти та людський огляд.
Якщо це здається вам знайомим, так і має бути. Це по суті та сама дисципліна, яка використовується для оптимізації звичайного програмного забезпечення.
Найкраща архітектура ШІ зазвичай є гібридною
Уявлення про додаток ШІ як про фронтенд, який викликає API LLM та отримує відповідь, поступово зникає:
Frontend
↓
LLM API
↓
Response
Справжні додатки все частіше нагадують шлюз, який координує правила, процеси пошуку, моделі, інструменти та процедури верифікації:
Application
|
v
AI Gateway
|
+-----------+-----------+
| | |
v v v
Rules Retrieval Models
| | |
+-----------+-----------+
|
v
Tools
|
v
Validation
|
v
Application
Такий підхід поєднує класичну інженерію програмного забезпечення з машинним навчанням, моделями мов та процесами пошуку, а також базами даних, API, механізмами безпеки, можливостями спостереження та бізнес-логікою, написаною у вигляді коду. Це гарна новина для інженерів програмного забезпечення: інженерія ШІ не замінює інженерію програмного забезпечення, а додає до неї потужний новий елемент.
Пов’язана зміна погляду також допомагає: припиніть запитувати, яка модель найрозумніша, і почніть запитувати, яка система найрозумніша. Блискуча модель у погано спроєктованій системі може давати жахливі результати, тоді як модель середньої потужності у добре спроєктованій архітектурі може забезпечити чудовий продукт. Хороші системи компенсують слабкості моделі за допомогою механізмів пошуку та інструментів, маршрутизації та кешування, структурованих результатів та перевірки, коду для точної роботи та постійної оцінки. У цьому сенсі здатність ШІ є властивістю архітектури, а не лише моделі.
Почніть з малого та поступово розширюйтеся за наявності доказів
Розумна стандартна стратегія для будь-якої нової функції ШІ описана у цьому алгоритмі:
Start
|
v
Define the workload
|
v
Can code solve the problem?
/ \
Yes No
| |
Use code v
Try small model
|
v
Evaluate
|
+----------+----------+
| |
Pass Fail
| |
Ship v
Improve architecture
|
v
Evaluate
|
v
Try stronger model
|
v
Evaluate
Це запобігає дуже поширеній помилці: витрачанню грошей на проблему, яку можна було б вирішити за допомогою кращої інженерної реалізації.
Іноді правильна модель — це взагалі жодна модель
Урок полягає не в тому, що малі моделі кращі; це було б так само неправильно, як і протилежне твердження. Правильною є та модель, яка відповідає вимогам завдання, збалансовуючи продуктивність та надійність з часом виконання, витратами та складністю. Іноді це маленька модель, іноді велика, іноді їхня комбінація, а іноді це взагалі не модель ШІ. Якщо певний тип запиту можна обробити за допомогою простої структури, як ця, немає причин використовувати LLM:
if (request.Type == "PasswordReset")
{
return StartPasswordResetWorkflow();
}
Це не анти-ШІ; це хороша інженерія. Ви не купуватимете сервер з необмеженою кількістю ядер CPU для сервісу, який потребує двох ядер, або виділите терабайт пам’яті для процесу, який використовує 4 ГБ. Той самий принцип застосовується до моделей: продуктивність, яка вам не потрібна, — це витрати, які вам також не потрібні.
Ключові висновки
- Замініть фразу «Який найбільший модель ми можемо собі дозволити?» на «Яка найпростіша архітектура, яка надійно вирішує цю проблему?» Це запитання природно спрямовує вашу увагу на механізми маршрутизації, пошуку інформації, кешування, детермінований код, оцінку ефективності, затримки та обробку помилок.
- Оцінюйте моделі за витратами на виконання кожного успішного завдання з урахуванням наслідків неправильної відповіді, а не за ціною за один запит чи кількістю параметрів.
- Вважайте відсутність знань проблемою пошуку інформації, а арифметичні операції чи правила — проблемою програмного забезпечення; жодна з цих проблем не вирішується за допомогою більшої моделі.
- Використовуйте найменшу модель, яка пройде оцінку на основі ваших власних даних, схожих на реальні умови роботи, і переходьте на більш складні моделі лише за наявності переконливих доказів.
- Зробіть архітектуру настільки простою, наскільки це дозволяють економічні вигоди, та продовжуйте її аналізувати після запуску, оскільки моделі, запити та користувачі постійно змінюються.
Спочатку розробіть рішення, орієнтуючись на проблему, а вже потім оберіть модель, яка підходить до цього дизайну. Іноді така модель буде величезною, іноді — на диво маленькою, а іноді найрозумнішим рішенням буде взагалі не використовувати модель.
Пов’язана література
- Retrieval-Augmented Generation Explained: Fixing LLM Knowledge Gaps — Дізнайтеся, чому ШІ створюють хибну інформацію та втрачають актуальність, а потім дізнайтеся крок за кроком, як метод RAG отримує дані, розділяє їх на частини, вбудовує та доповнює запити для усунення цих проблем.
- RAG vs Agentic RAG vs Graph RAG: Choosing the Right Retrieval Architecture — Дізнайтеся, чому простий метод RAG не справляється з запитами, що вимагають кількох кроків обробки, та зі структурованими даними, а також як агентні механізми та пошук на основі графів усувають відповідні слабкості.