За оцінками 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-стратегію та ділиться досвідом, що змінилося завдяки впровадженню нових рішень.
«Я вже не можу уявити Favbet Tech без AI-рішень і вважаю, що якби компанія сьогодні відмовилася від них, то втратила б ринок. У нашій сфері занадто багато даних і занадто висока швидкість, тому “в Excel і блокнотиках таке вже не працює”, хоча це й допомагало в нульових», — пояснює Олексій.
Олексій Ковальчук
Head of Data & AI
Компанія планує у найближчі два-три роки ще більше автоматизувати бізнес-процеси та зробити їх прозорішими, зокрема це стосується доступу до аналітики та роботи із CRM.
«Вже є експерименти з внутрішніми чат-ботами, які дозволяють нам зменшити залежність від BI-систем. Такі речі ще не до кінця автоматизовані, але потенціал величезний», — додає Олексій.
Де шукати ШІ-моделі
Найбільший публічний хаб моделей і датасетів – це 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 реальних прикладів, пропустіть їх через кожну модель і порівняйте за трьома групами критеріїв:
- Якість на вашій задачі. Шукайте, хто стабільно дає адекватний результат саме у вашому контексті. Орієнтуватися для задач класифікації можна на F1-score, для QA/аналізу – на точність відповідей за чеклистом та ручну оцінку 20-30 випадків. Для генеративних моделей дивіться на якість і релевантність тексту та стиль (можна комбінувати метрики та ручну оцінку).
- Практичність для продакшну. Для цього вимірюйте стабільність роботи моделі та latency (середній час відповіді). Також варто порахувати вартість її запуску.
- Надійність та ризики. Тут порівняйте активність підтримки моделей та їхнього оновлення, умови ліцензій, чи зазначені якісь обмеження в документації (model cards).
Загалом, якщо модель дає 70-80% бажаної якості без доопрацювань, є сенс інвестувати у fine-tuning, RAG чи оптимізацію інференсу. Якщо ні – дешевше і швидше замінити кандидата на іншого.
Адаптація готової ШІ-моделі: кому вона потрібна та якою може бути
Інколи неадаптована модель уже достатньо хороша для запуску: як-от, для задач підтримки, контент-асистентів або внутрішніх аналітичних інструментів. У такому випадку ваші наступні кроки це:
- інтеграція в продукт;
- логування й моніторинг відповідей;
- контроль edge-кейсів і безпеки;
- human-in-the-loop на перших ітераціях;
- збирання даних про помилки для майбутніх покращень.
Це робоча стратегія і, за даними Gartner, головний спосіб використання GenAI в організаціях.
При цьому адаптація теж не обов’язково дорівнює переписуванню ваг. Це може бути:
- Коректне формулювання інструкцій і правил (промпт-інженерія). Ви задаєте системні правила, формати, тон й тим самим контролюєте відповіді. Так працює, наприклад Canva Magic Write, в якої під капотом готова модель від OpenAI.
- Додавання контексту (RAG). Модель отримує доступ до ваших документів, FAQ, бази знань чи історії сапорту і працює з актуальною інформацією без зміни власних ваг. Так працює Notion AI та багато корпоративних асистентів: модель залишається загальною, але знає ваш контекст.
- Легка параметрична адаптація (LoRA/QLoRA). Ви не переписуєте модель повністю, але донавчаєте невеликий шар під свій стиль або домен. Добре працює для вузьких категоризацій, внутрішньої термінології, службових комунікацій. Часто використовується у фінтеху, наприклад, в кейсі Apoidea Group, які будували інфраструктуру під обробку документів.
Нарешті, повна адаптація – це fine-tuning. Він має сенс, коли треба висока точність і є великий доменний корпус (і ресурси це зробити). Яскравий приклад – фінансова LLM BloombergGPT.
При чому, за дослідженням 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-рішень.