Ми часто бачимо проєкти, де базова GigaChat видає загальні відповіді на корпоративні запити. Fine-tuning вирішує цю проблему: модель починає розуміти внутрішні регламенти, термінологію та контекст. Але процес вимагає глибокого розуміння архітектури та обмежень екосистеми Сбера. Наприклад, одна страхова компанія попросила нас адаптувати асистента під свою лінійку продуктів. Базова модель плутала умови КАСКО та ОСАГО, що призводило до помилок у рекомендаціях. Після дообучення точність відповідей досягла 95%. Але це потребувало ретельної підготовки: розмітки 1200 діалогів, балансування тематик і трьох ітерацій навчання. Ми використовуємо LoRA-адаптери для економії ресурсів — це знижує вартість GPU-годин у 2–3 рази порівняно з повним fine-tuning. Бюджет проєкту розраховується індивідуально залежно від обсягу даних.
Згідно з документацією Сбер Cloud, fine-tuning дозволяє адаптувати модель під конкретну предметну область.
На прикладі банківського асистента розберемо, як підготувати дані, запустити навчання та інтегрувати дообучену модель. Наші інженери мають 10+ років досвіду в NLP та MLOps, що гарантує результат.
Чому варто дообучати GigaChat для корпоративних завдань?
Стандартна модель дає загальні відповіді. Fine-tuning закриває три ключові проблеми: контекстна точність (модель засвоює внутрішні регламенти та терміни компанії, що критично для банків з їх нормативною базою), зниження галюцинацій (дообучення на ваших даних зменшує ймовірність вигаданих фактів — за нашими даними, частота помилок падає на 30–50%) та безпека (всі дані залишаються в контурі Сбер Cloud, що відповідає вимогам 152-ФЗ для банків та держструктур).
Порівняємо з альтернативами: YandexGPT теж доступний у корпоративному fine-tuning, але GigaChat дає глибшу інтеграцію з екосистемою Сбера. Llama при self-hosted потребує самостійної інфраструктури, але не прив'язаний до вендора.
Як підготувати дані для fine-tuning GigaChat?
GigaChat API доступний через платформу Сбер Cloud. Для fine-tuning потрібен корпоративний договір та тариф Enterprise. Аутентифікація — через OAuth 2.0:
import requests import base64 credentials = base64.b64encode( f"{client_id}:{client_secret}".encode() ).decode() response = requests.post( "https://ngw.devices.sberbank.ru:9443/api/v2/oauth", headers={ "Authorization": f"Basic {credentials}", "RqUID": "unique-request-id", }, data={"scope": "GIGACHAT_API_CORP"} ) access_token = response.json()["access_token"] Отриманий токен використовується для всіх подальших запитів. Для навчання необхідно завантажити датасет у форматі JSON Lines, де кожен приклад — діалог з ролями system, user, assistant:
{ "messages": [ { "role": "system", "content": "Ти — асистент страхової компанії. Допомагаєш клієнтам розібратися з умовами страхових продуктів." }, { "role": "user", "content": "Що входить у страхове покриття по КАСКО при ДТП з вини третьої особи?" }, { "role": "assistant", "content": "При ДТП з вини третьої особи за полісом КАСКО покриваються: збиток від зіткнення незалежно від винуватця, вартість відновлювального ремонту..." } ] } Приклад параметрів навчання
- learning_rate: 2e-5
- batch_size: 8
- epochs: 3
- LoRA rank: 16
- target_modules: q_proj,v_proj
Для якісного навчання потрібно мінімум 1000 діалогів, краще 3000+. Важливо деперсоналізувати дані, збалансувати тематики (не більше 15% на одну категорію) та розмітити складні кейси.
Практичний приклад: асистент для банківського чат-бота
Завдання: дообучення GigaChat Pro для обробки вхідних звернень у роздрібний банк — відповіді на питання щодо продуктів, маршрутизація складних запитів до операторів.
Датасет: 3500 діалогів з реальної переписки (знеособленої), що охоплюють 45 тематик (кредити, вклади, картки, перекази, спори за операціями).
Етапи підготовки:
- Вилучення діалогів з CRM.
- Деперсоналізація.
- Фільтрація діалогів з негативним результатом.
- Розмітка складних кейсів.
- Балансування за тематиками.
Результати:
- CSAT (задоволеність клієнта відповіддю бота): з 3.2 до 4.1 з 5.
- Відсоток коректних маршрутизацій: з 71% до 94%.
- Зниження escalation rate: з 61% до 38%.
- Середній час діалогу зменшився на 22%.
Які обмеження врахувати?
Закриті ваги: як і GPT-4o, ви отримуєте hosted endpoint без доступу до ваг. Інфраструктурна прив'язка: лише Сбер Cloud, немає on-premise деплою. Корпоративний поріг: fine-tuning недоступний на безкоштовних тарифах. Розмір контексту: 32K токенів — менше, ніж у Qwen2.5 або Claude 3.5 Sonnet.
Порівняння зі суміжними рішеннями
| Параметр | GigaChat | YandexGPT | Llama (self-hosted) |
|---|---|---|---|
| Екосистема | Сбер Cloud | Yandex Cloud | Довільна |
| Російська мова | Відмінна | Відмінна | Хороша |
| Відповідність 152-ФЗ | Так | Так | Так (on-prem) |
| Інтеграції | SberBusiness API | Yandex Tracker/Telemost | REST/OpenAI-compat |
| Fine-tuning доступ | Enterprise | Enterprise | Відкритий |
Що входить у проєкт
Ми пропонуємо повний цикл робіт:
- Аудит задачі — оцінюємо дані, формулюємо метрики, визначаємо план навчання.
- Підготовка датасету — деперсоналізація, розмітка, балансування.
- Запуск fine-tuning — ітеративне навчання з моніторингом метрик.
- Тестування — A/B-тестування на реальних діалогах.
- Інтеграція та підтримка — налаштування API endpoint, документація, навчання операторів.
Ми гарантуємо якість та надаємо сертифікати на виконані роботи. Замовте безкоштовний аудит ваших даних — ми оцінимо можливість fine-tuning за 2 дні. Бюджет проєкту розраховується індивідуально. Зв'яжіться з нами для консультації.
Терміни проєкту
| Етап | Тривалість |
|---|---|
| Аудит задачі, оцінка датасету | 3–5 днів |
| Підготовка та деперсоналізація даних | 2–4 тижні |
| Ітеративне навчання | 1–2 тижні |
| Тестування, A/B | 1 тиждень |
| Інтеграція, моніторинг | 1–2 тижні |
| Разом | 5–9 тижнів |