Реализация Fine-Tuning LLM под задачи мобильного приложения

Реализация Fine-Tuning LLM под задачи мобильного приложения

Базовая GPT-4 или Llama 3 не знает ни вашей предметной области, ни внутреннего жаргона, ни специфики ваших пользователей. Промпт-инжиниринг помогает до определённого предела: системный промпт можно накормить контекстом, но модель всё равно галлюцинирует в узкоспециализированных терминах, неверно расставляет приоритеты или генерирует ответы в неправильном формате. Fine-tuning — это другой уровень вмешательства: вы меняете веса модели, а не только инструкцию.

Когда промпт-инжиниринг уже не справляется

Три сценария, после которых 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 с деплоем на собственном сервере или локальным запуском через CoreML / llama.cpp.

Интеграция дообученной модели в мобильное приложение

После обучения дообученная модель получает 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 — это не разовая операция. Стандартный цикл:

1. Baseline-замер на тестовой выборке (15–20% датасета, отложенные до обучения)
2. Обучение → запуск A/B-теста в приложении на 10% трафика
3. Сбор фидбека пользователей (лайки/дизлайки, исправления ответов)
4. Дополнение датасета проблемными примерами
5. Повторное обучение

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 недели.