Fine-tuning LLM на корпоративных данных: когда нужен, когда хватит RAG
LoRA, QLoRA, PEFT, датасеты и риски: где дообучение модели действительно решает задачу, а где практичнее остаться на retrieval
Кратко
Fine-tuning меняет поведение модели, а не её знания. Для актуальных корпоративных документов почти всегда практичнее RAG: дешевле, обновляемо, объяснимо. Дообучение оправдано, когда нужно зафиксировать стиль, доменный язык, формат ответа или классификацию — и есть качественный датасет. В остальных случаях fine-tuning превращается в долгий и дорогой проект без понятного выигрыша.
После того как в компании внедрили RAG и пилот показал первые ответы по корпоративным документам, у руководителя ИТ или архитектора почти всегда возникает один и тот же вопрос: «А не дообучить ли нам модель?» Иногда это разумно. Чаще — нет. Граница между «здесь нужен fine-tuning» и «здесь достаточно RAG» проходит совсем не там, где её обычно проводят на маркетинговых слайдах.
Эта статья — о том, как читать симптомы и принимать решение. Без обещаний, что дообучение «выведет ИИ на новый уровень», и без презрения к нему как к якобы устаревшему подходу. Дообучение — обычный инженерный инструмент со своими сильными сторонами и жёсткими ограничениями, которые проявляются не сразу.
Когда RAG не справляется: симптомы
Если RAG развёрнут и работает, но что-то всё равно не устраивает заказчика, первое, что стоит сделать, — точно сформулировать, что именно не устраивает. От ответа зависит, нужен ли вообще fine-tuning.
Четыре характерных симптома, по которым видно, что проблема в поведении модели, а не в данных
Самая частая жалоба — модель отвечает «по документам», но не в нужном стиле. Юристам нужен сухой канцелярит со ссылками на пункты, а модель пишет в духе обзорной статьи. Поддержке нужны короткие, структурированные ответы по шаблону — модель отвечает развёрнутыми абзацами. Это поведенческая проблема, не информационная. Промпт-инжиниринг сильно помогает, но если требования к стилю жёсткие и проверяются ревью, fine-tuning закрепляет нужный паттерн надёжнее.
Близкая по природе ситуация — не хватает доменного языка. Модель отвечает корректно по смыслу, но использует «общерусский» вместо отраслевого. В нефтегазовой компании это заметно сразу: где специалист скажет «остановка УПН по аварии Б1», модель выдаёт «остановка установки подготовки нефти из-за аварийной ситуации в категории Б1». Технически верно, но не так, как пишут в смене. Базовая модель такой язык сглаживает: на выходе всё равно получается «общерусский», даже если в источниках был отраслевой жаргон.
Отдельная история — классификация. Когда LLM используется как классификатор обращений, типов договоров, рисков, у retrieval-подхода тут потолок. Few-shot в промпте даёт нестабильный результат, а полноценный fine-tuning на размеченных примерах резко повышает точность и стабильность.
Сюда же — нестабильное следование формату. Модель должна возвращать JSON со строгой схемой, а возвращает то JSON, то текст, то JSON с лишними полями. На большом потоке это превращается в кошмар для интеграции. Fine-tuning на тысяче примеров корректно сформированных ответов снимает большинство таких отклонений.
Что важно понимать буквально: если модель ведёт себя «не так», подсовывание ей документов это не исправит. Документы влияют на содержание ответа, не на манеру речи и не на следование инструкциям.
Практический вывод. Прежде чем планировать fine-tuning, отделите проблемы знаний (это к RAG) от проблем поведения (это к дообучению или промптам). На реальных пилотах смешение этих двух классов — основная причина того, что команда тратит месяцы на дообучение, а отвечать «по сути» модель так и не начинает.
Что такое fine-tuning технически
Терминология вокруг fine-tuning сильно засорена маркетингом — под одним словом продают разные вещи. Различать имеет смысл четыре уровня.
Четыре уровня дообучения: от полного обновления весов до адаптеров на потребительском GPU
Обновляются все веса модели — фактически новая её версия. Требует десятков гигабайт VRAM на инференс и кратно больше на обучение, много данных и аккуратной работы с гиперпараметрами. На корпоративных проектах применяется редко: дорого, есть риск «забыть» базовые способности (catastrophic forgetting) и трудно поддерживать.
Компромисс, который сейчас выбирают чаще всего. Вместо обновления исходных весов обучаются небольшие низкоранговые адаптеры, подключаемые к слоям внимания. Адаптер весит мегабайты-сотни мегабайт против десятков гигабайт у базовой модели. Типовые стартовые значения rank — 8–32, learning rate 1e-4–5e-4.
Та же LoRA, но базовая модель загружается в 4-битной квантизации. Это позволяет дообучать 13–70B-модели на одной серверной видеокарте уровня A100/H100; для 7B при коротком контексте часто хватает одной 24-гигабайтной потребительской карты. Все цифры плавают в зависимости от длины контекста и размера батча.
Зонтичное название для методов, обучающих малую долю параметров: LoRA, prefix tuning, adapter tuning, IA³ и другие. Так же называется библиотека от Hugging Face, которая де-факто стала стандартом для этой группы методов.
Важно держать в голове, что fine-tuning — это только один из трёх способов «настроить» поведение модели:
- → Prompt engineering — меняем инструкцию и примеры в промпте. Веса модели не трогаем. Самый дешёвый и быстрый способ.
- → RAG — подаём в промпт релевантные фрагменты документов. Веса модели не трогаем. Решает проблему знаний.
- → Fine-tuning — обновляем (всю или часть) весов. Меняем поведение модели на длительной основе.
Эти три инструмента не заменяют друг друга. На зрелых внедрениях они нередко работают вместе: дообученная под формат и стиль модель плюс RAG для актуальных данных плюс выверенные промпты.
Что нужно для fine-tuning
Прежде чем запускать обучение, имеет смысл честно проверить, готова ли компания к этой работе. Список короткий, но каждый пункт отрезвляет.
Качество и размер датасета
Это самая дорогая и наименее очевидная часть. Минимально жизнеспособный размер для LoRA на узкой задаче — порядка 500–1 000 примеров высокого качества. Для устойчивого результата — 3 000–10 000. Цифры ориентировочные и сильно зависят от задачи: для классификации хватает меньше, для генеративных задач нужно больше.
Разметка
Тысячу пар «вопрос — образцовый ответ» руками не пишут за вечер. Нужен либо процесс с разметчиками и контролем качества, либо способ собрать датасет из существующих артефактов: тикеты с финальными ответами поддержки, согласованные договорные формулировки, эталонные отчёты. На реальных проектах подготовка датасета съедает 60–80% бюджета — то есть всё, кроме GPU-времени и работы инженера, уходит на людей, размечающих и проверяющих примеры. Команды, которые планируют fine-tuning как «мы быстро прогоним обучение», обнаруживают этот перекос примерно через месяц.
Отдельно стоит сказать про состояние корпоративных корпусов. В тикетах поддержки 30–40% переписки — это обмен сообщениями вида «ок, починили», по которому ничему обучить нельзя. В файловых архивах юристов лежат пять версий одного договора с правками, и отличить итоговую от черновика без бизнес-логики не получится. Эта работа никуда не девается и в бюджет fine-tuning заходит целиком.
GPU
Для LoRA/QLoRA-пилотов 7–13B-моделей достаточно одной серверной видеокарты или мощной потребительской (A100 40GB, A6000, RTX 4090 — ориентир, проверять под конкретные модели и длину контекста). Full fine-tuning 70B+ моделей требует кластера и редко делается силами одного заказчика — обычно используют уже дообученные опенсорсные чекпойнты. Подробнее про подбор железа — в материале о стоимости LLM on-premise.
Время экспериментов
Один прогон обучения — это часы. Цикл «разметили → обучили → оценили → нашли ошибку → переобучили» занимает дни и недели. Реалистичный горизонт от старта подготовки датасета до пригодного к промышленной эксплуатации адаптера — два-три месяца. На сложных задачах больше.
Тестовые наборы и метрики
Без отдельного hold-out-набора и понятных метрик результат дообучения не отличить от случайного колебания. Для классификации это accuracy/F1, для генерации — ручная экспертная оценка по чек-листу, плюс автометрики там, где они применимы (BLEU и ROUGE для генеративных задач — слабый сигнал, на них нельзя опираться в одиночку).
Безопасность данных
Если корпус для дообучения содержит персональные данные, коммерческую тайну или сведения из защищаемой инфраструктуры, fine-tuning должен идти в закрытом контуре, на инфраструктуре заказчика, без передачи данных во внешние сервисы. Это вопрос не только облака против on-premise, но и того, кто имеет доступ к артефактам обучения и где хранятся итоговые веса. Подробнее об организации закрытого периметра — в руководстве по развёртыванию LLM в закрытом контуре и материале о приватности корпоративных LLM.
Реальные сценарии, где fine-tuning даёт эффект
Конкретные внедрения AZONE AI здесь намеренно не приводятся — это типовые классы задач, на которых дообучение регулярно даёт измеримый эффект.
Тысячи входящих писем, обращений, заявок, договоров — с проставлением категории, приоритета, типа контрагента. RAG здесь почти ничего не даёт, промпт с примерами работает нестабильно. LoRA-адаптер, обученный на 2–5 тысячах размеченных примеров, обычно стабильно перекрывает базовую модель и оказывается дешевле в эксплуатации.
Корпоративный ассистент должен отвечать в фирменном стиле, в строгом формате, с обязательной структурой. RAG обеспечит правильность данных, но не дисциплину изложения. Fine-tuning на образцовых ответах закрепляет паттерн.
Из договора нужно вытащить стороны, реквизиты, ключевые даты, предмет, ответственность, неустойки. На дополнительных соглашениях типичная ошибка базовой модели — путать дату самого соглашения с датой вступления изменений в силу; на размеченном корпусе такие систематические сбои чинятся. Особенно заметно работает на русскоязычных юридических текстах.
Медицина, нефтегаз, оборонная отрасль, банковское регулирование. Лексика, аббревиатуры, типовые формулировки. RAG подаст модели релевантные документы, но текст ответа всё равно будет звучать как «общерусский поверх специальных терминов». Fine-tuning на корпусе отраслевых текстов сглаживает этот разрыв.
Внутренний помощник методолога, помощник аналитика, помощник тестировщика — узкие роли с устоявшимися сценариями. Дообучение под роль даёт более предсказуемое поведение, чем длинные системные промпты, которые на потоке всё равно начинают «уезжать».
Если перечитать эти пять сценариев, видна общая черта: все они про поведение модели, не про знания. Если задача читателя ложится в этот список, fine-tuning имеет смысл планировать. Если нет — стоит ещё раз посмотреть, нельзя ли решить её через RAG и промпт.
Когда fine-tuning не поможет
Эти случаи встречаются чаще, чем хотелось бы. Часто заказчик ожидает от дообучения именно того, что оно дать не может.
Документы и регламенты меняются. Дообученная модель знает только то, что было в датасете на момент обучения. Каждое обновление = новый цикл fine-tuning. RAG обновляет индекс за минуты.
Если в выдаче retrieval мусор, никакое дообучение не спасёт. Сначала чинится retrieval (chunking, метаданные, reranker), потом ставится вопрос про fine-tuning.
Без датасета fine-tuning не существует как инженерная задача. Обещания «как-нибудь соберём в процессе» обычно приводят к шестимесячному проекту без результата. Команда возвращается к этапу «давайте честно посмотрим, что у нас в архивах» — и обнаруживает половину материалов без меток и половину с устаревшими версиями.
Доводить последние 10% через дообучение часто дороже, чем доработать промпт и retrieval.
Дообученная модель отвечает «из себя», без ссылок на конкретные документы. Для регуляторики, аудита и юридических задач это критично — там нужен именно RAG с прозрачной цепочкой источников.
Стек для on-premise fine-tuning
Минимально необходимый набор инструментов, который имеет смысл рассматривать при дообучении в закрытом контуре. Конкретные версии и совместимость нужно проверять перед стартом — экосистема меняется быстро.
Библиотека для LoRA, QLoRA и других PEFT-методов. Де-факто стандарт. Хорошо интегрирована с transformers и accelerate.
Фреймворк-обёртка, в которой конфигурация обучения описывается одним YAML-файлом. Удобен для воспроизводимости экспериментов.
Оптимизированная реализация LoRA/QLoRA, заметно ускоряющая обучение и снижающая потребление памяти на потребительских GPU. Полезен на пилотах с ограниченным железом.
lm-evaluation-harness для бенчмарков, MERA как русскоязычный набор задач (релевантность к корпоративным сценариям проверяется отдельно), собственный hold-out с ручной экспертной оценкой. Без последнего любой автоматический показатель — половина правды.
Внутренний реестр артефактов (например, MLflow или DVC) и контроль версий датасетов. Без этого через полгода никто не вспомнит, на каком корпусе обучалась версия адаптера, работающая в продакшене.
Отдельная тема — лицензионная пригодность базовой модели для корпоративных адаптеров: не каждый опенсорсный чекпойнт можно использовать в коммерческом продукте без оговорок. Этот вопрос лучше закрывать на этапе выбора модели, а не на этапе раскатки в прод. Сравнение опенсорсных и отечественных LLM, пригодных для дообучения в закрытом контуре, разобрано в статье об on-premise LLM и обзоре отечественных моделей.
Подводные камни
Дообучение — это работа с весами модели, и каждое такое вмешательство может сломать что-то незаметно для глаз. Главные группы рисков сводятся к нескольким повторяющимся сюжетам.
Обучая модель отвечать на ваших данных, легко «отучить» её от базовых способностей: рассуждения, общих знаний, кода. Характерно для full fine-tuning. LoRA снимает риск частично — базовые веса остаются нетронутыми, но при агрессивных гиперпараметрах деградация всё равно возможна.
Маленький датасет плюс много эпох, и модель начинает воспроизводить обучающие примеры почти дословно. На тестовых вопросах метрики выглядят отлично, на новых формулировках — катастрофа.
Дообученная модель — по сути, сжатая память о датасете. Всё, что в неё попало, может всплыть на выходе: фрагмент ПДн, конкретная формулировка из договора, кусок внутренней переписки. Датасет перед обучением чистится не как заметка «на всякий случай», а как обязательный этап с регламентом и ответственным.
Узко натренированная модель отвечает идеально в рамках своего домена и плохо — за его пределами. Если корпоративный ассистент должен покрывать несколько ролей, fine-tuning под одну может ухудшить остальные.
Через полгода другой инженер должен иметь возможность повторить обучение и получить тот же результат. Это требует фиксации: версии библиотек, точного датасета, гиперпараметров, seed, окружения. На практике об этом задумываются ровно в тот момент, когда «потеряли» рабочую модель и не могут её восстановить.
RAG vs Fine-tuning vs Prompt engineering: что выбрать
| Критерий | Prompt engineering | RAG | Fine-tuning |
|---|---|---|---|
| Что меняет | Только инструкцию | Контекст в промпте | Веса (адаптеры) |
| Когда нужен | Простая задача, мало вариаций | Нужны корпоративные знания | Нужно изменить поведение |
| Актуальность данных | По мере правки промпта | Обновляется в индексе | Только переобучением |
| Цитирование источников | Нет | Есть | Нет |
| Объяснимость для аудита | Низкая | Высокая | Низкая |
| Стоимость старта | Минимальная | Средняя | Высокая |
| Стоимость обновления | Низкая | Низкая | Высокая |
| Сложность поддержки | Низкая | Средняя | Высокая |
| Риск деградации модели | Нет | Нет | Есть |
| Типовой срок до пилота | Дни | 4–8 недель | 2–3 месяца + датасет |
Колонка «типовой срок» — ориентировочная, зависит от готовности данных, инфраструктуры и команды.
Бюджет fine-tuning: с чем сравнивать
Полная декомпозиция бюджета пилота приведена в материале о стоимости LLM on-premise. Применительно к fine-tuning имеет смысл разобрать структуру затрат отдельно — потому что бюджет, который выглядит на старте «средним», к концу проекта обычно превышает ожидания.
Пять основных статей расходов в пилоте fine-tuning — подготовка датасета доминирует
В типовом пилоте дообучения 13B-модели на корпус из 3–5 тысяч размеченных примеров основные статьи расходов выглядят так:
1–3 человеко-месяца разметчика, редактора и предметного эксперта. Самая дорогая и самая недооцениваемая статья. К концу первого месяца обычно становится понятно, что архив требует чистки, унификации форматов и согласования с владельцами данных.
Порядка десятков-сотен часов на один цикл LoRA-обучения 13B. На QLoRA с Unsloth требования к железу ниже, на full fine-tuning — кратно выше.
1,5–3 месяца параллельной работы на полный цикл: датасет → обучение → оценка → подготовка к продакшену.
Hold-out набор, ручная экспертная оценка, регресс на нескольких сценариях, документация модели и регламент её обновления.
Бюджет на год после запуска, не разовый. Адаптер живёт ровно до тех пор, пока стабильны данные и сценарии.
Если суммировать, классический сценарий «классификатор входящих обращений на 5 тысячах размеченных примеров» в закрытом контуре — это ориентировочно 2–3 месяца команды плюс понятная нагрузка на GPU на этапе экспериментов. Конкретные цифры сильно зависят от исходного состояния данных, наличия предметного эксперта и того, насколько готов внутренний регламент работы с моделями.
Fine-tuning почти всегда дороже сопоставимого по объёму RAG-проекта. Это нормально, если за стоимостью стоит измеримая выгода: рост точности классификации, отказ от ручной разметки, ускорение разбора потока документов. Если выгода неизмерима — это плохой повод запускать дообучение.
Как принять решение
Короткий чек-лист, который имеет смысл пройти до того, как закладывать fine-tuning в бюджет.
Развилка «знания или поведение» — первый и главный вопрос при выборе между RAG и fine-tuning
Если в знаниях — RAG. Если в поведении — дальше по списку.
Если ничего или сделано небрежно, fine-tuning не стоит обсуждать — сначала выжать понятный потолок из retrieval и инструкций.
Не «соберём в процессе», а конкретный источник примеров и план разметки.
Если нечем измерить улучшение, дообучение нельзя ни принять, ни отклонить.
GPU, MLOps-обвязка, версионирование, регламент обновлений.
Дообученная модель — это не разовый артефакт, а актив, требующий регулярного внимания.
Если по любому из пунктов ответ «нет» или «непонятно» — старт fine-tuning лучше отложить и сначала закрыть пробел.
Что делать дальше
Если статья совпадает с вашей текущей ситуацией, естественный следующий шаг — превратить «нам, кажется, нужен fine-tuning» в техническую гипотезу, которую можно проверить за пилот. Это означает зафиксировать: какую именно проблему вы пытаетесь решить, какой класс задач это (знания или поведение), какой датасет реалистично собрать и какие метрики покажут, что цель достигнута.
Если на этих вопросах команда буксует, проверять гипотезу проще на короткой консультации с архитектором, а не на трёхмесячном проекте без видимого выхода.
Если в вашем случае непонятно, нужен ли fine-tuning или достаточно RAG, AZONE-AI проводит экспресс-аудит данных и сценариев. За одну встречу фиксируем применимый подход, реалистичные сроки и требования к датасету — оставьте заявку на консультацию.
Частые вопросы
Подрядчик говорит, что без fine-tuning нормального корпоративного ИИ не получится. Это правда?
Чаще всего — нет. RAG в связке с продуманным промптом и нормальной подготовкой корпуса закрывает большинство задач, которые корпоративный заказчик называет «корпоративным ИИ». Fine-tuning имеет смысл там, где проблема в поведении модели — стиль, формат, классификация, — а не в том, что она «не знает» ваших документов. Если подрядчик начинает разговор с дообучения, не разобравшись, в чём именно проблема, это повод задать ещё несколько вопросов.
Что выбрать: LoRA или QLoRA?
QLoRA — практически универсальный выбор для пилотов на ограниченном железе. LoRA без квантизации даёт чуть лучшее качество, но требует более дорогих GPU. Full fine-tuning имеет смысл только при большом датасете и осознанной готовности нести стоимость поддержки.
Сколько данных нужно для дообучения LLM на русском языке?
От 500–1 000 высококачественных примеров для узкой задачи и 3 000–10 000+ для устойчивой генеративной задачи. Качество важнее объёма: 1 000 выверенных пар «вопрос — образцовый ответ» обычно дают результат лучше, чем 10 000 шумных.
Можно ли дообучать модель внутри закрытого контура?
Да. Для чувствительных данных это базовый сценарий: обучение разворачивается на инфраструктуре заказчика, базовая модель и датасет не покидают периметра, итоговые адаптеры хранятся во внутреннем реестре артефактов. Подробности — в руководстве по развёртыванию LLM в закрытом контуре.
Заменяет ли fine-tuning RAG?
Нет — это инструменты для разных задач.
Через какое время после запуска нужно переобучать модель?
Если меняется поведение задачи или появляется большой объём новых корректных примеров — раз в 3–6 месяцев. Если поведение задачи стабильно, адаптер может работать без изменений год и больше. Свежие знания должна обновлять RAG-часть, а не fine-tuning.
Актуальность материала
- Материал подготовлен по состоянию на май 2026 года.
- Числовые ориентиры (размер датасета, требования к VRAM, сроки, гиперпараметры LoRA, доля бюджета на подготовку датасета) — диапазоны для оценки. Под коммерческое предложение их нужно проверять на конкретной задаче, корпусе и железе.
- Состав экосистемы PEFT, Axolotl, Unsloth, lm-evaluation-harness и MERA быстро меняется. Перед стартом стоит сверить совместимость с текущими релизами и поддерживаемыми архитектурами моделей.
- Лицензионная пригодность базовых моделей для коммерческого использования и корпоративных адаптеров согласовывается с юридической службой отдельно по каждой модели.
RAG или fine-tuning — что подойдёт под вашу задачу
Экспресс-аудит данных и сценариев: за одну встречу зафиксируем применимый подход, реалистичные сроки и требования к датасету. Лицензии ФСТЭК, ФСБ и МО РФ. Опыт с 2003 года.