Тонкая настройка LLM (fine-tuning LLM) — это дообучение открытой языковой модели на ваших данных и правилах, чтобы она стабильно решала конкретную бизнес-задачу (поддержка, поиск по базе знаний, классификация, генерация документов) дешевле и предсказуемее, чем «попросили в промпте и молимся» — но за это вы платите данными, временем на разметку и MLOps-рутиной.

Если вы на уровне «хочу в IT, но не хочу стать шаманом по промптам», то новость хорошая: как настроить LLM под работу компании сейчас чаще похоже не на научную магию, а на инженерку и здравый смысл. Плохая: маркетинг продаёт это как «подкинул 100 диалогов — получил корпоративного Джарвиса». На практике всё упирается в качество данных, критерии качества и стоимость ошибки.

В российских компаниях три причины, почему вообще смотрят на открытые модели: (1) данные нельзя тащить в зарубежные API, (2) нужен контроль над поведением и логированием, (3) экономика — при большом потоке запросов свой контур может быть дешевле. И да, «открытая модель» не значит «бесплатно»: GPU, DevOps, безопасность и команда очень даже платные.

Что именно меняет тренд fine-tuning LLM

Промпт уже не спасает, когда нужен SLA

Тезис: промптинг хорош, пока вам не нужно гарантировать одинаковый стиль, формат и точность ответа.

Обоснование: у LLM вариативность — это фича, но в бизнесе это баг. В поддержке нельзя, чтобы один ответ был «вежливый», а второй — «я не знаю, но попробуйте переустановить Windows». Fine-tuning снижает разброс: модель учится отвечать «как надо» на типовые паттерны.

Практический вывод: если задача — стабильный формат (письма, карточки инцидентов, резолюции, классификация тикетов), fine-tuning часто окупается быстрее, чем бесконечные итерации промптов.

Подводный камень: дообучение не чинит пробелы в знаниях вашей базы. Если в документации хаос — модель будет выдавать хаос более уверенно.

RAG vs fine-tuning: не «или-или», а «что болит»

Тезис: RAG (Retrieval-Augmented Generation — генерация с поиском по базе) отвечает за актуальные знания, fine-tuning — за поведение и формат.

Обоснование: если нужно «отвечай строго по регламенту» — это про fine-tuning. Если нужно «берём свежие документы из Confluence/Битрикс24/1С-доков» — это про RAG. В российских реалиях часто делают гибрид: RAG достаёт факты, а дообученная модель оформляет их в нужный шаблон.

Практический вывод: начните с RAG, а fine-tuning подключайте, когда стало понятно, какие ответы и форматы повторяются тысячи раз.

Подводный камень: люди пытаются «впихнуть» в fine-tuning всю базу знаний. Итог: дорого, долго и всё равно устаревает.

Какие открытые модели реально берут в РФ и почему

Практичный набор: русскоязычность, лицензии, железо

На российском рынке чаще всего встречаются семейства и сборки на базе Llama-подобных архитектур, а также русифицированные/дообученные варианты (в том числе от отечественных команд). Важное не «как называется модель в презентации», а три вещи: качество на русском, условия лицензии для коммерции и требования к GPU.

Практический вывод: если вы джун/переходите в IT — научитесь говорить с бизнесом языком «лицензия, стоимость запроса, риски утечки», а не «модель умнее/глупее». Это сразу переводит вас из разряда «энтузиаст» в «инженер, которого слушают».

Подводный камень: выбрать модель по хайпу, а потом выяснить, что её нельзя легально использовать в проде или она не тянется на доступном железе.

Декомпозиция: как настроить LLM под бизнес-задачу без религиозных войн

Шаг 1. Формулируем задачу и метрику, иначе будет «кажется, стало лучше»

Тезис: fine-tuning без метрик — это хобби за счёт компании.

Обоснование: бизнесу не нужна «умная модель», бизнесу нужно: сократить время оператора, повысить точность маршрутизации тикетов, снизить долю ручных правок в документах. Это измеряется.

• Для поддержки: доля решённых без эскалации, время до первого ответа, CSAT.
• Для документооборота: % шаблонов без правок, время согласования.
• Для классификации: precision/recall по классам, стоимость ошибки (ложноположительные дороже?).

Практический вывод: заведите «золотой набор» из 100–300 кейсов и прогоняйте одинаковое сравнение: базовая модель vs промпт+RAG vs fine-tune.

Подводный камень: мерить «нравится/не нравится» вместо метрик. Потом это невозможно защитить перед руководством.

Шаг 2. Готовим данные: самый скучный этап и самый важный

Тезис: качество fine-tuning на 70% сидит в датасете, а не в «секретных параметрах».

Обоснование: для бизнес-задач обычно нужны пары «вход → правильный выход»: диалоги поддержки, письма, карточки инцидентов, выдержки регламентов + правильная формулировка ответа. Часто данные уже есть в Service Desk, почте, CRM и базе знаний — просто они не в виде датасета.

1. Экспортируйте реальные кейсы (обезличьте: ФИО, телефоны, договора).
2. Нормализуйте стиль: единый тон, формат, обязательные поля.
3. Разметьте «как правильно» (лучше 2 разметчика + разбор расхождений).
4. Сделайте train/val/test, чтобы не обманывать себя.

Практический вывод: если данных мало — не начинайте с дообучения «в лоб». Сначала шаблоны, RAG, строгий формат ответа, и только потом fine-tuning.

Подводный камень: учить модель на «как отвечали операторы». Операторы часто отвечают по-разному и иногда ошибаются.

Шаг 3. Выбираем тип fine-tuning: полный, LoRA, QLoRA

Тезис: для большинства задач хватает параметро-эффективного дообучения (LoRA/QLoRA), а не полного обучения всех весов.

Обоснование: LoRA (Low-Rank Adaptation) добавляет небольшие адаптеры, обучаются они быстрее и дешевле. QLoRA — то же, но с дополнительной экономией за счёт квантования.

Практический вывод: новичку проще и безопаснее стартовать с LoRA/QLoRA: быстрее цикл «обучили → проверили → поправили датасет».

Подводный камень: пытаться «улучшить интеллект» модели. Fine-tuning обычно улучшает соответствие вашим примерам, а не делает модель «в целом умнее».

Шаг 4. Встраиваем в ИС: без MLOps это всё останется экспериментом

Тезис: бизнес ценит не модель, а сервис: API, логи, мониторинг, доступы, обновления.

Обоснование: LLM в проде — это интеграции: корпоративный портал, Service Desk, 1С, СЭД, почта, чаты. Нужны версии модели, откат, A/B-тест, контроль подсказок, ограничение контекста, журналирование.

Практический вывод: заложите минимум: периметр доступа, маскирование ПДн, мониторинг качества (дрейф), и процесс обновления датасета раз в 2–4 недели.

Подводный камень: «прикрутили бота в чат» без логов и контроля. Потом никто не знает, почему он вчера отвечал нормально, а сегодня — как сосед по подъезду после третьего созвона.

Деньги, сроки, риски: что будет стоить fine-tuning в реальности

Цены и сроки гуляют, но структура затрат почти всегда одинаковая. И да: расходы на разметку часто больше, чем на GPU.

Риск №1: «дообучим и уволим половину поддержки». Потом выясняется, что модель снимает 20–30% рутины, а остальное — сложные кейсы, где нужен человек.

Риск №2: юридический. Лицензии и данные — скучно, но это то, чем вас накроет не баг, а юрист с печатью.

Риск №3: качество. Если нет тестового набора и регресса, вы «улучшаете» модель до момента, когда бизнес замечает ухудшение.

Два кейса из практики: успех и провал (и почему так)

Кейс «получилось»: классификация обращений в Service Desk

Компания с потоком ~10–20 тыс. тикетов/мес. Сначала сделали RAG по базе знаний, но основной болью была не генерация ответа, а маршрутизация: куда отправить тикет. Собрали 15 тыс. исторических тикетов, вычистили персональные данные, заново нормализовали классы (а не «как в старой системе»), сделали LoRA fine-tuning под классификацию + строгий формат JSON.

Результат: меньше ручной сортировки и меньше «перекидываний» между линиями. Бизнесу понравилось, потому что эффект измеряется в минутах и SLA.

Почему сработало: чёткая метрика, много однотипных данных, понятная цена ошибки.

Кейс «не получилось»: «дообучим на регламентах, будет консультант»

Другой проект хотел «корпоративного юриста» из LLM. В регламентах было много противоречий, версии документов гуляли, а правильные ответы зависели от контекста сделки, которого в данных не было. Fine-tuning сделали, модель стала отвечать «увереннее», но не точнее. Это самый дорогой вид ошибки: уверенная.

Почему провалилось: пытались fine-tuning’ом заменить управление знаниями и процессами.

Больше подобных разборов и практических гайдов по карьере и инженерным решениям — на https://itokno.ru (там иногда тоже развенчивают «волшебные кнопки», да).

Экспертный вердикт и инструмент: чек-лист перед fine-tuning

• 1) Какая метрика улучшится? Время оператора, точность классификации, доля шаблонов без правок — что именно?
• 2) Есть ли 1–5 тысяч качественных примеров? Не «каких-то», а проверенных, обезличенных, с единым стилем.
• 3) Что дороже: ошибка или задержка? Если ошибка дорогая — нужны строгие ограничения, RAG и валидация.
• 4) Можно ли начать с RAG/шаблонов? Часто это даёт 60% эффекта за 20% усилий.
• 5) Кто владелец качества? Если «никто» — модель быстро станет не помощником, а источником инцидентов.

Частые вопросы