Дообчання (Fine-Tuning) відкритої LLM під задачі замовника

Дотонування моделей LLM з відкритим кодом для завдань клієнта

Дотонування моделі мови з відкритим кодом — найбільш гнучкий шлях отримання спеціалізованого інструменту AI з повним контролем над даними та інфраструктурою. На відміну від моделей API (GPT-4o, Claude), ви володієте вагами, можете розгорнути модель на місці, масштабувати логічний висновок без витрат на токени та адаптувати архітектуру до конкретних вимог.

Вибір базової моделі для завдання

Вибір базової моделі — критичне рішення. Неправильний вибір призводить до переробки на етапі ітерацій.

Архітектура типового проекту дотонування

Фаза 1: Аудит завдання та даних (1–2 тижні)
  ├── Формалізувати завдання (класифікація/генерування/видалення)
  ├── Інвентаризація існуючих даних
  ├── Оцінка необхідного обсягу та якості
  └── Вибір базової моделі та методу тренування

Фаза 2: Підготовка даних (2–6 тижнів)
  ├── Збір та агрегація джерел
  ├── Очистка (дублікати, шум, PII)
  ├── Маркування (ручне/синтетичне/комбіноване)
  ├── Форматування до chat template
  └── Train/val/test split (80/10/10)

Фаза 3: Тренування (1–4 тижні)
  ├── Оцінка базової моделі на базовій лінії
  ├── Перший запуск LoRA/QLoRA з параметрами за замовчуванням
  ├── Аналіз кривих втрат под час тренування/валідації
  ├── Налаштування гіперпараметрів
  └── Повне дотонування, якщо необхідно

Фаза 4: Оцінка та ітерації (1–3 тижні)
  ├── Автоматичні метрики (F1, BLEU, ROUGE, accuracy)
  ├── LLM-as-judge (GPT-4o або сильна модель як оцінювач)
  ├── Людська оцінка вибірки
  └── Аналіз випадків невдачі → доповнення даних

Фаза 5: Розгортання та моніторинг (1–2 тижні)
  ├── Квантизація (опціонально)
  ├── Розгортання через vLLM/TGI
  ├── Налаштування моніторингу
  └── A/B тест проти базової лінії

Синтетичне генерування даних через сильну модель

Часто трапляється сценарій: клієнт не має позначених даних, але має неструктуровані джерела (документи, нормативні акти, FAQ). Використовуємо GPT-4o або Claude для автоматичного генерування тренувальних пар:

from openai import OpenAI
import json

client = OpenAI()

def generate_training_example(document_chunk: str, num_examples: int = 5) -> list:
    """Генерувати тренувальні пари з фрагмента документу"""

    prompt = f"""Ти — експерт у створенні наборів даних для тренування мовних моделей.

На основі фрагмента документу нижче створи {num_examples} пар "запитання-відповідь" у форматі JSON.
Запитання повинні бути різноманітними: фактичні, аналітичні, практичні.
Відповіді — точні, засновані тільки на тексті документу.

Документ:
{document_chunk}

Повернути JSON-масив: [{{"question": "...", "answer": "..."}}]"""

    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}],
        response_format={"type": "json_object"},
        temperature=0.7
    )

    return json.loads(response.choices[0].message.content)["pairs"]

Важливо: синтетичні дані потребують ручної верифікації (мінімум 10–15%) для контролю якості. Галюцинації GPT-4o у синтетичних даних потраплять у тренування та погіршать якість.

Практичний випадок: спеціалізація під телемедицину

Завдання: помічник для лікарів первинної ланки — диференціальна діагностика за скаргами пацієнта, рекомендації обстежень, вибір коду МКБ-10.

Вихідні дані:

• 450 клінічних випадків з висновками (з медичної системи, анонімізовані)
• Клінічні рекомендації Міністерства охорони здоров'я РФ з 12 нозологій (PDF, 3200 сторінок)
• Довідник МКБ-10

Стратегія:

1. Конвертація клінічних рекомендацій у chunks
2. Синтетичне генерування 3200 прикладів через GPT-4o (скарги → діагностика)
3. Верифікація 15% вибірки практикуючими лікарями
4. Дотонування Qwen2.5-14B (найкращий російськомовний для медичної термінології)

Результати (після 4 епох QLoRA, r=32):

• Top-3 точність для МКБ-10: 71% → 89%
• Повнота рекомендацій обстежень (recall vs експерт): 0.62 → 0.84
• Рівень галюцинацій (придумані препарати/процедури): 24% → 6%
• Затримка (vLLM, A100): 1.8с на запит

Моніторинг якості в виробництві

Після розгортання налаштуємо систему безперервного моніторингу:

import mlflow

# Логування передбачень для аналізу дрейфу
with mlflow.start_run():
    mlflow.log_metrics({
        "avg_response_length": avg_len,
        "refusal_rate": refusal_rate,
        "latency_p95": latency_p95,
        "user_rating_avg": rating_avg,
    })

Ознаки деградації моделі: збільшення рівня відмов, зниження оцінок користувачів, вищий рівень escalation у downstream системах.

Вимоги до інфраструктури

Графік повного циклу

Мінімальний проект (готові дані, просте завдання): 3–5 тижнів. Типовий проект (підготовка даних з нуля): 8–14 тижнів. Складний проект (спеціалізований домен, ітеративне маркування): 16–24 тижні.