Вибір правильної моделі ШІ: баланс вартості та продуктивності

Є певний комфорт у виборі найпотужнішої моделі. Коли ви будуєте додаток, що використовує штучний інтелект, здається відповідальним, майже логічним, вибрати найпотужнішу доступну модель. GPT-4o. Claude Opus. Gemini Ultra. Це вражаючі технології, і ніхто ніколи не був звільнений за вибір найбільш розумного інструменту в кімнаті.

Однак є одне застереження. Проекти розростаються. Витрати зростають. Затримка збільшується. І десь біля третього місяця команда починає ставити незручні питання про те, чому проста функція автозаповнення спалює API-кредити, як стартап з ризиковим капіталом і без відповідальності.

Ось річ: “найздатніший” і “найвідповідніший” – це два різні стандарти. Постачальники послуг розробки застосунків зі штучним інтелектом вибирають моделі на основі оцінок, а не рейтингів.

Більша модель не стає кращою автоматично

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

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

Менші, спеціалізовані моделі обробляють фокусовані завдання з вражаючою точністю:

• GPT-4o mini покриває більшість мовних завдань при приблизно 15-разовій нижчій вартості, ніж GPT-4o
• Claude Haiku побудований для швидкості і ефективності на великих об’ємах структурованих робіт
• Mistral 7B і Llama 3.1 8B – це відкриті варіанти, які працюють швидко і добре піддаються тонкому налаштуванню

Розрив між цими і передовими моделями значно зменшується, коли завдання вузьке, а запити добре спроектовані.

Математика витрат, про яку ніхто не говорить на планувальних зустрічах

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

Наприклад, якщо ваш додаток робить 500 000 викликів API на місяць:

Та сама функція. Дуже різна ситуація з маржею.

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

Затримка – це проблема користувацького досвіду

Є причина, чому існує швидке харчування. Люди не завжди хочуть п’ятистравний обід. Іноді вони хочуть свою відповідь зараз.

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

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

Haiku, Mistral і Llama 3.1 8B працюють значно швидше (іноді в 3-5 разів швидше) під подібними умовами завантаження. Для функцій, орієнтованих на користувача, де сприйнята швидкість має значення, це не є незначною проблемою. Це рішення щодо продукту.

Змінна промпт-інженерії (що змінює все)

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

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

Деякі інструменти, які варто знати:

• LangChain і DSPy для складання і оптимізації конвеєрів запиту
• Guidance для обмеженої генерації і структурованих виводів
• PromptFoo для систематичної оцінки запиту на моделях

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

Тонке налаштування змінює рівняння

Порівняння між загальною передовою моделлю і меншою відкритою моделлю виглядає зовсім інакше, коли тонке налаштування вступає в гру. Модель Llama 3.1 8B, тонко налаштована на ваші конкретні дані домену (ваша термінологія, ваші граничні випадки, ваш формат виводу), може перевершити GPT-4o на вашому конкретному завданні.

Це не гіпотетично. Компанії в сфері охорони здоров’я, юридичної техніки та електронної комерції повторно продемонстрували це.

З чого почати тонке налаштування:

• Hugging Face для хостингу моделей із відкритим кодом, наборів даних і інфраструктури навчання
• Together AI для швидкого й доступного тонкого налаштування популярних відкритих моделей
• Replicate для розгортання власних моделей без управління вашою власною інфраструктурою GPU

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

Безпеку й розміщення даних не можна відкладати на потім

Деякі додатки не можуть надсилати дані на сторонні API зовсім. Розгляньте:

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

Ці середовища мають обмеження, яких жоден API передової моделі не може обійти, незалежно від можливостей. Моделі на власній інфраструктурі, як на місці, так і у приватній хмарі, – це єдиний шлях вперед. Це означає відкриті моделі, такі як Llama 3, Mistral або Phi-3, що працюють на вашій власній інфраструктурі. Передова модель, яку ви не можете законно використовувати у виробництві, – не правильний вибір, крапка.

Оціночний крок, який команди постійно пропускають

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

Ось процес, який працює:

1. Створіть оціночний набір з 100 до 200 репрезентативних вхідних даних з очікуваними результатами
2. Запустіть їх через дві чи три кандидатські моделі в реалістичних умовах
3. Оцініть за своїми реальними критеріями: точність, форматна відповідність, тон, затримка, вартість одного виклику
4. Вирішіть на основі даних, а не інтуїції чи рейтингів лідерборду

Інструменти, такі як Braintrust, PromptFoo і Weights & Biases Prompts, роблять такий систематичний аналіз доступним без дослідницького досвіду. Це займає кілька годин, щоб налаштувати. Віддача полягає в тому, що ви не вибираєте неправильну модель на шість місяців.

Коли передова модель насправді є правильним вибором

Заради справедливості: є завдання, для яких передові моделі справді заслуговують на свою ціну.

Використовуйте передову модель, коли:

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

Залишайтеся з легшою моделлю, коли:

• Завдання добре визначено і повторюється
• Швидкість і вартість мають значення на об’ємі, на якому ви працюєте
• Ви можете інвестувати в інженерію запиту або тонке налаштування
• Правила резиденції даних або відповідності виключають сторонні API

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

Підсумок

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

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

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