Чому найздатніший модель штучного інтелекту рідко є правильним вибором для вашого додатка

Є певний комфорт у виборі найбільш потужного моделі. Коли ви будуєте додаток, що використовує штучний інтелект, здається логічним вибрати найбільш потужний модель, доступний. 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

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

Підсумок

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

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

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