Готові ШІ-моделі: як обрати та адаптувати під свій продукт – досвід

За оцінками Stanford AI Index, на тренування GPT-4 знадобилося орієнтовно $78 млн лише на обчислення; для Google Gemini Ultra – $191 млн. Дослідники Epoch AI прогнозують, що витрати на передові ШІ-моделі зростатимуть у 2-3 рази щороку й можуть перевищити $1 млрд до 2027.

Розробка та тренування ШІ з нуля – це дороге задоволення. Але також в ньому рідко коли є сенс: все, що вам треба, вже існує на ринку (хіба що ви маєте унікальні вимоги).

У цьому матеріалі разом із FAVBET Tech розбираємо, де шукати готові моделі, як їх обирати, перевіряти на власних даних і адаптувати під продукт.

Досвід Favbet Tech

У Favbet Tech напрямком даних та ШІ опікується Олексій Ковальчук, Head of Data & AI. Він допомагає компанії формувати AI-стратегію та ділиться досвідом, що змінилось завдяки впровадженню нових рішень.

 

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

Де шукати ШІ-моделі

Найбільший публічний хаб моделей і датасетів – це Hugging Face. На сьогодні тут розміщено 2+ млн моделей, 500 тис. датасетів та 1 млн демо.

Чому саме ця платформа стала GitHub для ШІ? Частково через вдалу інфраструктуру: тут можна розгорнути модель, донавчити її, інтегруватися з PyTorch, TensorFlow та ONNX, а також вийти у продакшн через Inference Endpoints (керовані API, автоскейлінг, логування). Якщо вам потрібно швидко знайти кілька кандидатів, підвантажити невелику вибірку власних даних і порівняти результати, Hugging Face зазвичай дає найменший поріг входу.

Крім того, навколо Hugging Face існує велике ком’юніті людей, які якраз й додають та підтримують моделі.

Втім, є кейси, коли Hugging Face для пошуку ШІ-моделей не підійде. В першу чергу, він не оптимальний для enterprise, бо має обмеження за ліцензіями, швидкістю та latency.

Нижче альтернативи, та для яких кейсів вони підходять:

• AWS Bedrock – коли інфраструктура в AWS і потрібні VPC-інтеграції, SLA, guardrails, бази знань та інтеграція з Anthropic/Meta/Mistral;
• Azure AI Foundry (Model Catalog) – оптимально, якщо використовується Microsoft-стек; доступні Azure OpenAI, Meta, NVIDIA, Mistral, HF-моделі;
• Google Vertex AI Model Garden – логічний вибір для GCP; є Gemma, інструменти для тюнінгу, інтеграції з BigQuery;
• PyTorch Hub / TensorFlow Hub – мінімальне тертя в межах одного фреймворку, готові чекпойнти, адаптація під CI/CD;
• Replicate – швидке проганяння багатьох моделей через API для PoC без налаштування інфраструктури;
• OpenRouter – єдине API для багатьох моделей, зручне порівняння вартості й latency;
• Papers with Code – свіжа наукова база, лідерборди, нішеві задачі;
• Kaggle Models / GitHub – корисно для вузьких доменів (наприклад, медичні або IoT-моделі);
• OpenAI / Anthropic / Mistral API – якщо потрібна SOTA-якість і прийнятний vendor lock-in.

Як обрати найкращу модель для вашого кейсу

Визначте задачу

Максимально конкретизуйте, що вам потрібно. Не «бот для підтримки», а «класифікація звернень у сапорт на 6 категорій, українська/англійська мови, середній обсяг тексту – 1–3 речення».

Чим точніше формулювання, тим швидше ви відсієте невдалі варіанти.

Підберіть перших кандидатів

На цьому етапі важливо не провалитись у нескінченний рісьорч. За лічені хвилини обрана платформа зі списку вище запропонує вам з десяток варіантів, але всі вони вам не потрібні. Оберіть 3-5, які:

• розв’язують подібну задачу (не просто LLM, а модель для класифікації/QA/summary);
• підтримують потрібні мови;
• мають активну підтримку або оновлення;
• мають зрозумілу ліцензію (MIT/Apache – безпечніше для продукту).

На етапі відбору завжди питайте: «Чи є приклади використання моделі у схожих реальних кейсах?».

Порівняйте кандидатів

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

Зберіть 100-300 реальних прикладів, пропустіть їх через кожну модель і порівняйте за трьома групами критеріїв:

1. Якість на вашій задачі. Шукайте, хто стабільно дає адекватний результат саме у вашому контексті. Орієнтуватися для задач класифікації можна на F1-score, для QA/аналізу – на точність відповідей за чеклистом та ручну оцінку 20-30 випадків. Для генеративних моделей дивіться на якість і релевантність тексту та стиль (можна комбінувати метрики та ручну оцінку).
2. Практичність для продакшну. Для цього вимірюйте стабільність роботи моделі та latency (середній час відповіді). Також варто порахувати вартість її запуску.
3. Надійність та ризики. Тут порівняйте активність підтримки моделей та їхнього оновлення, умови ліцензій, чи зазначені якісь обмеження в документації (model cards).

Загалом, якщо модель дає 70-80% бажаної якості без доопрацювань, є сенс інвестувати у fine-tuning, RAG чи оптимізацію інференсу. Якщо ні – дешевше і швидше замінити кандидата на іншого.

Адаптація готової ШІ-моделі: кому вона потрібна та якою може бути

Інколи неадаптована модель уже достатньо хороша для запуску: як-от, для задач підтримки, контент-асистентів або внутрішніх аналітичних інструментів. У такому випадку ваші наступні кроки це:

1. інтеграція в продукт;
2. логування й моніторинг відповідей;
3. контроль edge-кейсів і безпеки;
4. human-in-the-loop на перших ітераціях;
5. збирання даних про помилки для майбутніх покращень.

Це робоча стратегія і, за даними Gartner, головний спосіб використання GenAI в організаціях.

При цьому адаптація теж не обов’язково дорівнює переписуванню ваг. Це може бути:

• Коректне формулювання інструкцій і правил (промпт-інженерія). Ви задаєте системні правила, формати, тон й тим самим контролюєте відповіді. Так працює, наприклад Canva Magic Write, в якої під капотом готова модель від OpenAI.
• Додавання контексту (RAG). Модель отримує доступ до ваших документів, FAQ, бази знань чи історії сапорту і працює з актуальною інформацією без зміни власних ваг. Так працює Notion AI та багато корпоративних асистентів: модель залишається загальною, але знає ваш контекст.
• Легка параметрична адаптація (LoRA/QLoRA). Ви не переписуєте модель повністю, але донавчаєте невеликий шар під свій стиль або домен. Добре працює для вузьких категоризацій, внутрішньої термінології, службових комунікацій. Часто використовується у фінтеху, наприклад, в кейсі Apoidea Group, які будували ​​інфраструктуру під обробку документів.

При чому, за дослідженням Menlo Ventures (2024), лише ~9% компаній використовують fine-tuning, тоді як 51% покладаються на RAG, а решта – на промпти та інженерію навколо моделі. Також, навіть якщо ви дійдете до повної кастомізації, краще робити це поступово, після реальних сигналів, що це потрібно. Для цього впроваджуйте:

• продакшн-моніторинг (latency, точність, cost-per-call);
• логування запитів і помилок;
• ручну перевірку edge-випадків;
• збір даних від користувачів/операторів;
• контроль дрейфу даних (модель може «старіти»).

Типові помилки команд, що працюють із готовими моделями

Наостанок розберемо помилки, які найчастіше роблять при впровадженні ШІ-моделей:

• Не тестувати на власних даних. Лідерборди – не гарантія. Перевіряйте на реальних зверненнях, документах, кейсах.
• Ігнорувати ліцензію моделі. Не всі open-моделі дозволяють комерційне використання чи fine-tuning.
• Не збирати помилки впродовж перших тижнів. Саме на старті видно 80% проблем. Без логування й ручної валідації модель не покращиться.

Також велика помилка покладатися на модель у всьому, забуваючи, що вона може вигадати, помилитися або бути не впевненою. Тож fallback-механізм – це must-have. Мусите мати спосіб безпечно «відмовитися від відповіді» або передати запит іншій системі або людині.

У Favbet Tech із цим працює одразу кілька підрозділів: команда Data Science, команда BI та окремий підрозділ Data Engineering. Попри різні завдання, усі вони входять до одного департаменту й тісно співпрацюють між собою. Коли від бізнесу надходить запит, керівники команд декомпозують його на кілька стримів і розподіляють роботу так, щоб процеси синхронно рухалися від збору даних до впровадження AI-рішень.

Більше про FAVBET Tech