Дообучение LLM на своих данных: когда это оправдано, а когда — трата денег

Дообучение LLM на своих данных — запрос, с которым к нам приходят чаще всего. «Хотим нейросеть, которая знает всё про нашу компанию». Звучит логично. Только в большинстве случаев дообучение модели, fine-tuning, — не то, что бизнесу нужно. Задачу закрывает подключение базы знаний к готовой модели через RAG, Retrieval-Augmented Generation. Это дни работы, а не месяцы. И в разы дешевле.

Что такое fine-tuning на самом деле

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

Главное, что должен понимать руководитель. Fine-tuning меняет то, «как» модель отвечает, а не то, «что» она знает. Свежие факты о вашей компании через дообучение надёжно не загружаются. Для этого существует RAG.

Путаница этих двух задач — главная причина, по которой компании покупают дорогое дообучение там, где хватило бы подключённого к модели архива документов.

RAG против fine-tuning

RAG ищет нужные фрагменты в векторной базе и подкладывает их модели перед ответом. Модель при этом не меняется. Именно поэтому RAG считают оптимальным вариантом для закрытых корпоративных данных. А fine-tuning в профессиональной практике — крайнее средство, к которому переходят, когда не хватило промптов и RAG.

Когда дообучение действительно нужно

Есть задачи, где без него никак:

1. Массовые однотипные операции. Классификация обращений, извлечение полей из одинаковых документов, модерация по строгим правилам. Чем больше объём, тем быстрее окупается.
2. Жёсткий формат ответа, который промптом не удержать. Например, строгая структура для передачи в другую систему.
3. Поведение, а не знания. Нужно, чтобы модель всегда отвечала в определённом тоне и формате при любой длине и сложности запроса.
4. Масштаб, оправдывающий вычисления. Полное дообучение требует серьёзных GPU-ресурсов и памяти. Без масштаба это деньги в трубу.

Обратите внимание: «чтобы модель знала наши товары» в этом списке нет. И не будет. Знание товаров, цен и остатков меняется каждую неделю. Вшивать его в веса модели — всё равно что печатать прайс на кирпичах: надёжно, солидно и абсолютно бесполезно уже к следующему понедельнику. Для таких данных нужен RAG, который подтягивает свежую выгрузку перед каждым ответом.

Сценарий: поддержка из трёх человек

Небольшая компания, отдел поддержки — три человека. Решают «дообучить нейросеть на истории переписки», чтобы отвечала «как наши». Цель понятная. Инструмент — мимо.

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

Через fine-tuning вышло бы так: разметка тысяч диалогов, недели работы, заметный счёт. А потом поменялись тарифы — и модель уверенно называет клиентам старые цены. Дообучайте снова. И снова. И снова. Красота.

Дешевле полного дообучения: адаптеры

Если дообучение всё-таки нужно, полное переобучение всех параметров — не единственный вариант. Существуют экономичные методы, PEFT, Parameter-Efficient Fine-Tuning. Самый известный — LoRA: основные веса модели замораживаются, обучаются только небольшие адаптеры.

Ресурсов нужно заметно меньше, адаптеры легче хранить и менять. Для большинства бизнес-задач, где дообучение оправдано, это разумная стартовая точка. Если подрядчик сразу предлагает «полное дообучение на кластере» и не упоминает адаптеры — спросите почему.

Локальная модель: вопрос «где», а не «как»

Часто с дообучением путают другое — локальное развёртывание модели на своём сервере вместо облачного API. Это не альтернатива fine-tuning и не замена RAG. Это вопрос, где физически работает модель.

Зачем компании свой сервер с моделью:

• Конфиденциальность. Персональные данные клиентов, финансы, коммерческая тайна не уходят за пределы вашей инфраструктуры.
• Предсказуемые расходы. Вместо оплаты каждого запроса — фиксированное обслуживание своего железа.
• Независимость. Внешний сервис поменял условия или недоступен — у вас всё работает.

Инструменты вроде Ollama позволяют запустить открытую модель локально буквально несколькими командами. Но запуск модели на своём сервере сам по себе не делает её знатоком вашей компании. Знания всё равно подключаются через RAG поверх локальной модели.

Облако — это чужой компьютер, на котором лежит ваш бизнес. Если в запросах коммерческая тайна, пусть лучше лежит на вашем.

Почему RAG выигрывает по деньгам и времени

RAG не требует переобучения при изменении данных. Обновили документ в базе — на следующий запрос модель отвечает с учётом нового текста.

С дообучением иначе. Каждое изменение — новый цикл: подготовка данных, обучение, проверка качества через evals. Evals — это наборы тестовых вопросов с известными правильными ответами, по которым видно, не стала ли модель хуже после дообучения. Каждый цикл — деньги и время.

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

Про то, о чём молчат продавцы «дообучения под ключ»

Любая языковая модель ошибается. Дообученная тоже. Она может уверенно выдать несуществующий факт — это свойство технологии, а не брак конкретного подрядчика. Fine-tuning меняет стиль и формат, но не превращает модель в безошибочного эксперта.

А теперь резко. Подрядчик, который продаёт малому бизнесу «дообучение нейросети на ваших данных» за серьёзные деньги, не объяснив разницу с RAG, не показав план проверки качества и не предупредив, что при каждом изменении прайса процесс придётся повторять, — продаёт не решение. Он продаёт себе загрузку на полгода за ваш счёт. Красивое слово «fine-tuning» в коммерческом предложении часто означает только одно: дешёвый вариант вам решили не показывать.

Самый дорогой ИИ-проект — тот, где вы заплатили за обучение модели тому, что можно было просто положить в папку.

Данные: мусор на входе — мусор на выходе

Что для дообучения, что для RAG решает одно и то же — качество ваших данных. И вот тут начинается самое весёлое.

Регламенты в трёх версиях, и никто не помнит, какая действующая. Договоры в виде сканов, кривых и повёрнутых. Переписка, где половина ответов клиентам — «уточню и перезвоню». Прайс в Excel, который ведёт один человек и никому не показывает. Если скормить всё это модели, она честно выучит хаос. И будет уверенно его воспроизводить.

Поэтому любой ИИ-проект у нас начинается не с выбора модели, а с инвентаризации знаний. Что считать правдой? Где лежит актуальная версия? Кто отвечает за её обновление? Без ответов на эти вопросы ни RAG, ни дообучение не взлетят.

Бонус, который заказчики не ожидают: после такой ревизии компании нередко сами впервые видят свои регламенты целиком. И находят в них противоречия, которые годами разруливались звонком «спроси у Марины».

Три вопроса подрядчику до подписания договора

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

1. Как часто будут меняться данные, которые модель должна «знать»?
2. Сколько однотипных запросов в месяц реально проходит через эту задачу?
3. Что будет с качеством ответов, когда данные изменятся через полгода?

И четвёртый, бонусный: как будете измерять результат? Если ответ «посмотрим на нескольких примерах» вместо набора тестов с правильными ответами — качество будут оценивать на глаз. А на глаз, как известно, все модели прекрасны. До первого клиента.

Сценарий: «модель стала хуже, но мы не знаем где»

Компания всё-таки дообучила модель для классификации обращений. Первые недели всё отлично. Потом подрядчик выпускает «улучшенную версию», дообученную на свежих данных. Через месяц менеджеры замечают, что жалобы на качество стали попадать в категорию «вопросы по доставке» и теряются.

Почему никто не заметил сразу? Потому что набора тестов не было. Новую версию проверили на десятке примеров, они прошли — и в бой. Evals на пару сотен типовых обращений поймали бы проблему до выката. Без них каждое «улучшение» — лотерея.

Чек-лист: RAG или fine-tuning

• ☐ Задача про то, «что модель знает» → RAG.
• ☐ Задача про то, «как модель отвечает» → возможно fine-tuning.
• ☐ Данные часто меняются (тарифы, остатки, статусы) → RAG.
• ☐ Огромный объём однотипных операций → можно рассматривать дообучение, начиная с адаптеров.
• ☐ Бюджет ограничен, результат нужен быстро → RAG и аккуратные промпты.
• ☐ В запросах персональные данные или коммерческая тайна → локальное развёртывание, независимо от выбора RAG или дообучения.
• ☐ Есть набор тестов для оценки качества до и после изменений.

Что делаем мы и чем это отличается

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

• Задача закрывается базой знаний — разворачиваем RAG-контур, а не продаём дообучение, которое вы не сможете оценить.
• Дообучение действительно нужно — начинаем с экономичных адаптеров и набора тестов.
• Данные конфиденциальны — разворачиваем локальную модель на вашей инфраструктуре или на нашем сервере.
• Берём сервер с ИИ-инструментами на обслуживание — от 7 000 ₽ в месяц.

Типичный подрядчик, живущий на часах разработки, не заинтересован рассказывать про дешёвый вариант. Мы заинтересованы в том, чтобы вы вернулись со следующей задачей, а не с претензией.

Прежде чем платить за дообучение

Попросите подрядчика объяснить, почему ваша задача не решается через RAG. Нет внятного ответа — скорее всего, вам продают длинный проект там, где хватило бы недели настройки. Напишите нам в АйТи Фреш: разберём задачу и подберём решение под неё, а не под максимальный счёт.

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