Як обрати ML-вендора: чеклист для CTO та технічного директора

## Чому вибір ML-вендора — стратегічне рішення Вибір ML-вендора — це не те саме, що вибір агентства для розробки корпоративного сайту. Тут ставки значно вищі: ви довіряєте партнеру доступ до ваших бізнес-даних, критичних процесів і конкурентних переваг. Неправильний вибір може коштувати не лише грошей, але й часу — найціннішого ресурсу. У цьому матеріалі ми зібрали 12 критеріїв оцінки ML-вендора, з практичними запитаннями для переговорів і «червоними прапорцями», які мають насторожити будь-якого CTO. ## Блок 1: Технічна компетентність ### Критерій 1: Релевантний портфоліо Перший і найважливіший критерій — чи має вендор реальний досвід у вашій галузі або з вашим типом задачі? **Що перевіряти:** - Кейси з вашої галузі з конкретними метриками - Контакти реальних клієнтів для референс-дзвінків - Опис архітектурних рішень, а не лише результати **Червоний прапорець:** вендор показує лише «пілотні проєкти» без production-деплою або відмовляється надати референси. **Запитання на переговорах:** «Розкажіть про проєкт, який не вдався, і що ви зробили інакше наступного разу.» Якщо вендор каже, що всі проєкти успішні — це або неправда, або відсутність рефлексії. ### Критерій 2: Технічний стек і сучасність підходів ML — галузь, що змінюється щороку. Вендор, що використовує підходи 2018 року, не зможе дати вам конкурентну перевагу у 2025. **Що перевіряти:** - Використання сучасних фреймворків: PyTorch, Hugging Face, Ray, MLflow - Підхід до MLOps: чи є CI/CD для моделей, моніторинг в production? - Досвід з LLM і foundation models (якщо релевантно для вашої задачі) **Червоний прапорець:** вендор не знає термінів «data drift», «model registry» або «feature store» — це ознака того, що вони будують ML-системи «на коліні». ### Критерій 3: Команда і ротація Ви купуєте не компанію, а конкретних людей. Запитайте, хто буде безпосередньо працювати над вашим проєктом. **Що перевіряти:** - Кваліфікація lead ML engineer (LinkedIn, публікації, Kaggle) - Ротаційна політика компанії - Співвідношення senior/junior у команді **Червоний прапорець:** на презентацію приходять сеньори, а на проєкті будуть стажери без нагляду. ## Блок 2: Процес і управління проєктом ### Критерій 4: Методологія і прозорість ML-проєкти мають нелінійний характер: перший підхід рідко дає найкращий результат. Як вендор управляє цією невизначеністю? **Що перевіряти:** - Чи є чіткий процес від дослідницького етапу до production? - Як часто відбуваються статус-колли і яка їх форма? - Як вендор комунікує погані новини? **Добрий знак:** вендор пропонує короткий discovery-спринт (1–2 тижні) перед підписанням великого контракту. ### Критерій 5: Підхід до визначення успіху Перед початком проєкту має бути погоджено, як вимірюється успіх. Якщо вендор ухиляється від конкретних KPI — це ризик. **Що обговорювати:** - Технічні метрики: precision/recall, RMSE, AUC - Бізнес-метрики: конверсія, виручка, скорочення витрат - Умови, за яких проєкт вважається невдалим **Червоний прапорець:** вендор наполягає виключно на технічних метриках і відмовляється прив'язуватися до бізнес-результатів. ### Критерій 6: Управління даними і безпека Ваші дані — це ваш актив. Як вендор їх обробляє? **Що перевіряти:** - Де зберігаються дані під час проєкту? - Чи є DPA (Data Processing Agreement)? - Який процес видалення даних після завершення? - Чи проходив вендор аудит безпеки (ISO 27001, SOC 2)? **Запитання:** «Якщо наш контракт завершиться завтра, де будуть наші дані через 30 днів?» ## Блок 3: Комерційні умови і ризики ### Критерій 7: Модель ціноутворення Різні моделі ціноутворення несуть різні ризики для клієнта. **Типові моделі:** - Time & Materials: ви платите за години, ризик бюджетного перевищення - Fixed Price: вендор бере ризик на себе, але може економити на якості - Milestone-based: оплата за досягнення конкретних результатів — найбільш збалансована **Червоний прапорець:** вендор наполягає виключно на T&M для проєктів з чіткими вимогами або пропонує Fixed Price для відкритих R&D задач. ### Критерій 8: Інтелектуальна власність Кому належить модель, що навчена на ваших даних? **Що прояснити в контракті:** - IP на модель і ваги - IP на preprocessing pipeline і feature engineering код - Право вендора використовувати ваш кейс у портфоліо **Стандарт:** усе, що розроблено на ваші кошти з вашими даними — ваше. Якщо вендор претендує на IP — це потребує серйозного обговорення. ### Критерій 9: Vendor lock-in Чи зможете ви відійти від вендора без катастрофічних втрат? **Що перевіряти:** - Чи використовуються відкриті стандарти і фреймворки? - Чи передбачена передача knowledge base? - Чи є escrow для вихідного коду? **Тест:** запитайте, що станеться, якщо ви захочете перенести систему in-house через рік. Якщо вендор описує це як надзвичайно складний або дорогий процес — насторожтеся. ## Блок 4: Довгострокова перспектива ### Критерій 10: Підтримка і SLA ML-система потребує постійної уваги: дрейф даних, перенавчання, інфраструктурні оновлення. **Що обговорювати:** - SLA на усунення критичних багів - Процес і вартість перенавчання моделі - Включення моніторингу в ongoing-пакет ### Критерій 11: Трансфер знань Ваша команда має розуміти, що вендор побудував. Інакше ви повністю залежите від нього. **Що включати в контракт:** - Технічна документація (архітектура, рішення, обмеження) - Сесії knowledge transfer з вашими інженерами - Коментований код ### Критерій 12: Культурний fit Технічно компетентний вендор, з яким важко спілкуватися — джерело стресу і затримок. **Що оцінювати:** - Реакція на складні запитання (захищаються чи пояснюють?) - Проактивність у комунікації - Ставлення до вашої галузевої експертизи ## Практичний чеклист для CTO Підсумовуючи, ось мінімальний список дій перед підписанням контракту: - Провести технічну презентацію з детальним розбором одного релевантного кейса - Поговорити з двома реальними клієнтами (не з тих, кого вендор сам рекомендував) - ЗапитатиCV трьох людей, які безпосередньо будуть на проєкті - Узгодити KPI і метрики успіху до підписання - Прояснити IP ownership у юридичному відділі - Провести discovery-спринт (2 тижні) перед великим зобов'язанням Вибір правильного ML-партнера займає час, але цей час окупається багаторазово протягом усього проєкту.