Побудова проти Покупки: Рамка Рішення для Проектів Машинного Навчання

Чому це рішення так часто йде не так

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

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

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

Три варіанти в одному параграфі кожен

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

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

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

Рамка оцінювання за 11 критеріями

Найбільш надійний спосіб прийняти таке рішення – оцінити проєкт за 11 критеріями, зважити кожен критерій відповідно до його важливості для бізнесу та підсумувати результат. Кожен критерій оцінюється від 1 (наголошує на будівництві) до 5 (наголошує на купівлі):

Помножте кожну оцінку на її вагу та підсумуйте. Сума менше приблизно 200 балів з максимального числа свідчить на користь будівництва; від 200 до 350 – на користь гібридного підходу; більше 350 – на користь покупки. Точні порогові значення менш важливі, ніж дисципліна оцінювання кожного критерію явно, а не автоматичного переходу до варіанту, який віддає перевагу найголоснішій особі в кімнаті.”]} self=

paragraphs_en

paragraphs_uk

Загальна вартість володіння перемагає початкову ціну

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

Розглянемо рекомендаційну систему для електронного магазину. Підписка на SaaS може коштувати $10 000 у перший рік (враховуючи налаштування), зростати до $12 000 і потім $15 000 зі збільшенням використання – ГВВ протягом трьох років становить приблизно $42 000. Кастомна розробка може коштувати $60 000 на розробку плюс $3 000 на хостинг у перший рік, потім $19 000 і $22 000 на наступні роки для підтримки та періодичного перенавчання – ГВВ майже $104 000. Гібридний підхід з використанням відкритого джерела з індивідуальною тонкою настройкою може коштувати близько $58 000 протягом трьох років – дешевше за повну розробку, але гнучкіший за чисту SaaS.

Зміни масштабу змінюють розрахунки. При дуже великому обсязі транзакцій лінійна модель ціноутворення на SaaS може перевернути порівняння: рекомендаційна платформа, що коштує $80 000 на рік при 100 000 користувачів щомісяця, коштує приблизно $400 000 протягом п’яти років, тоді як кастомна система з початковою розробкою в $60 000 і $27 000 на рік за обслуговування та підтримку загалом становить близько $180 000 – точка перелому зазвичай досягається у другий або третій рік. Правило велике: нижче приблизно 10 000 користувачів на день SaaS зазвичай виграє; вище 100 000 користувачів на день кастомна розробка зазвичай виграє; між ними потрібно проводити обчислення явно.

П'ять гібридних патернів, які варто знати

Гібридність — це не єдина стратегія, а родинка з п’яти розпізнаваних патернів, приблизно розташованих від найбільш гнучкого до найшвидшого:

П’ять кроків для прийняття рішення

На практиці рішення можна стиснути в короткий робочий процес. По-перше, запустіть фільтр на дві хвилини: якщо бюджет становить приблизно менше $15 000, термін виконання – менше двох місяців, п’ять або більше SaaS постачальників вже вирішують цю проблему, немає команди з машинного навчання та не планується її створення, відповідь майже завжди – купити – додатковий аналіз не потрібен. По-друге, якщо жоден із цих швидких фільтрів не застосовується, заповніть таблицю оцінювання за 11 критеріями вище. По-третє, розробіть модель ТКО на три-п’ять років для кожної варіативної опції, оскільки ціноутворення на перший рік систематично оманливе. По-четверте, де залишається невизначеність, запустіть пілот: безкоштовний пробний період для SaaS кандидата або доказ концепції, що охоплює приблизно 10% даних для кандидатури на побудову, перед тим як повністю виділити бюджет. По-п’яте, задокументуйте рішення – обраний підхід, обґрунтування, бюджет і терміни виконання, ключові ризики та явну стратегію виходу, якщо ціна постачальника різко зростає або система на замовлення працює гірше.

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

П’ять помилок, які повторюються в різних галузях

Однакові помилки виникають у рішеннях «розробка проти покупки» в дуже різних компаніях. Команди розробляють всередині компанії просто тому, що засновник або керівник інженерії хоче отримати досвід управління ML-командою, не усвідомлюючи, що компетентна команда коштує від 100 000 до 200 000 доларів США на рік у валовій вартості та виправдовує себе лише за допомогою трьох або більше ML-проектів у черзі протягом року. Команди порівнюють ціни, а не загальну вартість володіння (ТЦВ), не помічаючи, що річна вартість SaaS-інструменту збільшується, тоді як витрати на обслуговування спеціальної системи часто недооцінюються. Команди вважають open-source фреймворки безкоштовними, забуваючи, що розробка, хостинг та підтримка все одно коштують грошей — open-source зазвичай зменшує загальну вартість на 20–30 %, а не до нуля. Команди ігнорують залежність від постачальника до тих пір, поки це не стане надзвичайною проблемою. І команди планують запустити швидко з допомогою SaaS-інструменту та «пізніше правильно побудувати», план, який майже ніколи не витримує контакту з пріоритетами наступного кварталу, залишаючи накопичений технічний борг, який коштує дорожче у вирішення, ніж будівництво спеціальної системи з самого початку.”]} sport=

paragraphs

Часті запитання

Спробуйте наживо

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