Сначала назовите тип ошибки

«Давайте дообучим модель на наших документах» звучит как универсальное решение. Но документы бывают двух разных типов. Прайс, регламент возврата и график отгрузки меняются; структура ответа оператору, тон письма или извлечение полей из заявки должны повторяться. Если смешать эти задачи, можно заплатить за обучение модели, которая уверенно цитирует вчерашний прайс. Внутрик уже приготовил стопку распечаток, но руководителю полезнее сначала определить, где в системе живёт актуальная истина.

Для первой задачи обычно нужен доступ к текущему источнику: поиск по документам (RAG), запрос к учётной системе или их сочетание. Для второй могут хватить хороших инструкций и примеров; дообучение имеет смысл только после измерения устойчивой ошибки. Microsoft прямо разделяет эти сценарии: RAG — для частных и часто обновляемых данных, fine-tuning — для изменения поведения, стиля и выполнения задачи. Это полезная отправная точка, не универсальная гарантия качества конкретного проекта.

Что происходит при обновлении знаний

В RAG документ остаётся вне весов модели. Система получает актуальную версию, разбивает её на фрагменты, индексирует, находит подходящие фрагменты по запросу и передаёт их модели вместе с вопросом. Для цены товара и остатка часто лучше прямой запрос к ERP или каталогу: поисковый индекс тоже может отстать. Документация Amazon Bedrock подчёркивает, что после добавления, изменения или удаления файлов базу знаний нужно синхронизировать; инкрементальная синхронизация обрабатывает изменившиеся документы. Для локального контура принцип тот же, хотя инструменты будут другими.

Дообучение меняет параметры модели или добавляет адаптер. Оно может закрепить нужный формат, терминологию и способ решения повторяющейся задачи. Но изменение строки в исходном прайсе само по себе не меняет обученные веса. Потребуются новые данные, запуск обучения, проверка и выпуск следующей версии. Исследование, опубликованное на EMNLP 2024, сравнивало способы добавления знаний и обнаружило преимущество retrieval-augmented подхода в исследованных настройках; это не доказательство, что любой RAG лучше любого дообучения на каждой бизнес-задаче.

Практическая развилка для малого бизнеса

  • **Нужны свежие факты с источником:** политика возврата, ассортимент, действующие условия договора. Используйте RAG для текстов и API к системе учёта для точных операционных значений. У ответа должны быть версия документа, дата и, где возможно, ссылка на конкретный фрагмент.
  • **Нужно устойчивое поведение:** одинаковый JSON на входящих заявках, классификация причин обращений, краткое письмо в заданном тоне. Начните с промпта, схемы и нескольких проверенных примеров. Сравните частоту ошибок до и после.
  • **Нужны оба свойства:** сохраняйте факты в RAG или системе записей, а адаптер применяйте только для стабильного формата/доменных оборотов. Такая гибридная конструкция дороже в сопровождении, поэтому сначала докажите, что более простая схема не проходит критерии.
  • **Нужны вычисления или транзакции:** модель не должна «помнить» итоговый баланс, скидку или наличие на складе. Их возвращают проверяемые функции и базы данных, а модель объясняет результат.

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

Инфраструктура и данные

Минимальный RAG-контур включает владельца документов, правила версионирования, загрузчик, индекс, управление доступом, модель ответа и журнал ошибок. Индекс — копия для поиска, не главный справочник: удаление или изменение в первичной системе должно доходить до индекса с понятной задержкой. Для персональных и коммерчески чувствительных данных нужны те же права в поиске, что и в исходной системе; фраза в промпте «не показывай чужое» не является контролем доступа.

Для дообучения понадобятся лицензированная базовая модель, согласованный набор качественных входов и желаемых ответов, отдельная проверочная выборка, вычислительные ресурсы, хранение версий адаптера и регрессионные тесты. Hugging Face объясняет: LoRA и другие PEFT-подходы сокращают число обучаемых параметров и память градиентов/оптимизатора, но не делают обучение автоматически дешёвым по всем ресурсам — остаются веса базовой модели и активации. Время экспертов на разметку и разбор неудач также не исчезает.

Локальное размещение не упрощает эти обязанности. Оно меняет границу передачи данных, но оставляет расходы на GPU/CPU, хранение, обновления, мониторинг и контроль доступа. Если отдел продаж меняет коммерческие условия ежедневно, важнее надёжный путь «утверждённый источник → обновление → проверка доступности», чем ещё одна эпоха обучения.

Модельный расчёт: считать не обучение, а изменение

Возьмём условный отдел с 2 000 запросов в месяц и 40 изменениями документов. Это **модельный пример, не результат компании**. Предположим, проверенный час специалиста стоит 2 000 ₽, а инфраструктурные и API-расходы обеих схем пока исключены: они сильно зависят от модели, нагрузки и размещения. Для RAG заложим 8 часов первичной настройки, затем по 15 минут на проверку каждого изменения и 6 часов в месяц на выборочную проверку ответов. Получается 16 000 ₽ запуска и 32 000 ₽ ежемесячного труда: 40 × 0,25 × 2 000 + 6 × 2 000.

Для варианта «переобучать при каждом обновлении» предположим даже очень скромные 2 часа на подготовку, обучение, тест и выпуск одной новой версии плюс те же 6 часов проверки в месяц. Это 172 000 ₽ ежемесячного труда: 40 × 2 × 2 000 + 6 × 2 000, без вычислений и первоначальной разметки. Этот пример не говорит, что RAG всегда дешевле: если документы меняются редко, поиск сложен, а поведенческий навык применяется миллионы раз, соотношение может быть иным. Он показывает, что частоту обновлений нужно включать в бюджет отдельно от цены одного ответа.

Для реального решения считайте стоимость **принятого** ответа: подготовка данных, индекс или обучение, инференс, проверка человеком, исправления, простои и новые версии. Не сравнивайте только цену токена с арендой GPU. Одинаковые 2 000 запросов могут требовать разного числа проверок и приводить к разной цене ошибки.

Пилот без дорогого эксперимента

Возьмите 50–80 обезличенных реальных обращений. Разделите их на вопросы о свежих фактах, задачи формата/тона и запросы к системам. Для каждого зафиксируйте ожидаемый источник, допустимое время устаревания, критическую ошибку и необходимость одобрения человеком. Сначала проверьте базовую модель с хорошей инструкцией; затем RAG или API только там, где нужно. Если оставшиеся ошибки действительно поведенческие и повторяются на независимой выборке, оцените малый адаптер и его жизненный цикл.

Решение о дообучении принимайте после теста на новых, не участвовавших в обучении случаях. Если правка документа снова превращается в цикл подготовки датасета и выпуска модели, вы, вероятно, храните изменяемое знание не там. Пусть Внутрик помогает находить последнюю утверждённую страницу, а не учит наизусть каждый новый прайс.