Реалізація LLM Fine-Tuning для задач мобільного додатку
Базова GPT-4 або Llama 3 не знає ні вашої предметної області, ні внутрішнього жаргону, ні специфіки ваших користувачів. Prompt-інжиніринг помагає до певного ступеня: системний промпт може ввести контекст, але модель все ще галюцинує на вузькоспеціалізованих термінах, неправильно розставляє пріоритети або генерує відповіді неправильного формату. Fine-tuning — це інший рівень втручання: ви змінюєте ваги моделі, а не просто інструкцію.
Коли prompt-інжиніринг вже не справляється
Три сценарії, після яких fine-tuning стає виправданим:
Детермінізм формату. Модель повинна повертати строго структурований JSON з користувацькими полями, специфічними для вашого домену. Навіть з few-shot прикладами в промпті базова модель періодично ломає схему або додає чужі поля. Після fine-tuning на 5,000–10,000 пар «запит → правильний JSON» помилки формату майже зникають.
Доменна термінологія. Медичний додаток з термінами МКБ-10, юридичний асистент з номерами статей, fintech з внутрішніми кодами продуктів — базова модель плутається або інтерпретує абревіатури загально. Fine-tuning на вашому корпусі документів це вирішує.
Стиль та тональність. Бренд-голос — реальна бізнес-потреба. Якщо асистент повинен відповідати в стилі конкретного персонажа або з певним рівнем формальності, дешевше вбудувати в ваги, ніж вносити в кожен запит через системний промпт.
Підготовка датасету — найкритичніша частина
80% успіху fine-tuning визначає якість тренувальних даних, а не вибір гіперпараметрів.
Форматування для OpenAI Fine-Tuning API (gpt-4o-mini або gpt-3.5-turbo як база):
{"messages": [
{"role": "system", "content": "Ти асистент медичного додатку. Відповідай на питання про симптоми коротко та безпечно."},
{"role": "user", "content": "Що таке ЧСС в спокої 45 уд/хв?"},
{"role": "assistant", "content": "Брадикардія. У тренованих спортсменів — норма. При запамороці — див. кардіолога."}
]}
Мінімальний обсяг для помітного результату — 50–100 прикладів (OpenAI дозволяє), реалістичний для продакшену — 500–2,000 пар. Автоматично згенеровані датасети через GPT-4 вимагають ручної валідації: автоматично створені приклади відтворюють помилки базової моделі.
Для open-source моделей (Llama 3, Mistral, Gemma 2) датасети зазвичай готуються в форматі Alpaca або ShareGPT та передаються в Hugging Face datasets.
Вибір підходу: OpenAI vs open-source
| Параметр | OpenAI Fine-Tuning | Open-source (Llama 3 + Unsloth) |
|---|---|---|
| Інфраструктура | Не потрібна | GPU від A100 / хмара |
| Контроль даних | Дані йдуть в OpenAI | Повний контроль |
| Швидкість старту | 1–4 години навчання | 2–8 годин + налаштування |
| Вартість інференсу | Per-token API | Власний сервер |
| Мобільний деплой | Через API | On-device можливо (GGUF) |
Для більшості мобільних продуктів OpenAI Fine-Tuning — найшвидший шлях до результату. Якщо дані не можуть покидати контур (медицина, фінанси) — open-source на власному сервері або локальний llama.cpp/CoreML.
Інтеграція дообученої моделі в мобільний додаток
Після навчання дообучена модель отримує ID виду ft:gpt-4o-mini-2024-07-18:org:name:xxxxx. Зміна коду мобільного додатку — підставити цей ID:
// iOS — Swift, OpenAI SDK
let request = ChatCompletionRequest(
model: "ft:gpt-4o-mini-2024-07-18:my-org:medical-assistant:abc123",
messages: conversationHistory,
maxTokens: 256,
temperature: 0.3 // нижча температура = більш детерміновані відповіді
)
// Android — Kotlin, Retrofit
data class ChatRequest(
val model: String = "ft:gpt-4o-mini-2024-07-18:my-org:medical-assistant:abc123",
val messages: List<Message>,
val max_tokens: Int = 256,
val temperature: Double = 0.3
)
На рівні API — жодної різниці. Та сама REST-точка, той же формат відповіді.
Оцінка якості та ітеративне вдосконалення
Fine-tuning — це не разова операція. Стандартний цикл:
- Baseline-замір на тестовій вибірці (15–20% датасету, відкладені до навчання)
- Навчання → запуск A/B-тесту в додатку на 10% трафіку
- Збір фідбеку користувачів (лайки/дизлайки, виправлення відповідей)
- Дополнення датасету проблемними прикладами
- Повторне навчання
OpenAI Fine-Tuning Dashboard показує training loss та validation loss по епохам. Переобучення (overfitting) видно як розходження кривих — validation loss зростає, training продовжує падати. Зменшіть кількість епох або збільшіть датасет.
Процес
Аудит поточних промптів та виявлення вузьких місць → збір та розмітка датасету → підготовка в потрібному форматі → навчання з контрольними метриками → інтеграція дообученої моделі → A/B-тест → ітеративне дополнення датасету.
Орієнтири за часом
Підготовка датасету з нуля (500–1,000 прикладів) — 2–4 тижні включаючи валідацію. Навчання на OpenAI — 2–6 годин. Інтеграція в мобільний додаток — 1–3 дні. Повний цикл від аудиту до продакшену — 3–8 тижнів. При наявності готових розмічених даних — 1 тиждень.