Дообучение или RAG: когда модель учить, а когда дать ей документы

Чаще всего задачу ставят так: «обучите модель на наших документах, чтобы она по ним отвечала». За этой фразой обычно стоят три разных желания: чтобы ассистент знал регламенты и договоры, чтобы отвечал в принятом у вас тоне и формате и чтобы понимал ваши термины и категории. Первое решается поиском по документам (RAG), второе и третье — иногда дообучением. Если их перепутать, получится модель, которая уверенно пересказывает прошлогодний прайс и не может сказать, откуда взяла цифру.

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

Дообучение учит форме, поиск — фактам

На конференции EMNLP 2024 вышли две работы, которые стоит прочитать до того, как «учить модель своим знаниям». Ovadia и соавторы (откроется в новой вкладке) сравнили дообучение на текстах и поиск по документам на задачах, где нужны знания. Поиск оказался стабильно точнее — и на фактах, которые модель уже встречала, и на совершенно новых. Новые факты дообучением усваивались плохо; помочь может только многократное повторение одного факта в разных формулировках.

Gekhman и соавторы (откроется в новой вкладке) (Технион и Google Research) поставили контролируемый эксперимент. Примеры с новыми для модели знаниями усваивались заметно медленнее остальных, а по мере того как модель их всё-таки запоминала, её склонность к галлюцинациям росла линейно. Вывод авторов: знания модель получает в основном на предобучении, а дообучение учит её эффективнее пользоваться тем, что она уже знает.

Ещё раньше к похожему выводу пришли авторы LIMA (откроется в новой вкладке) (2023): модель на 65B, дообученная всего на 1 000 тщательно отобранных примеров, в слепом сравнении давала ответы не хуже, чем GPT-4, в 43% случаев. По их гипотезе, тысяча примеров не добавляет модели знаний, а показывает, в каком формате отвечать.

Отсюда рабочее разделение. Дообучение — для того, как отвечать: стиль, структура ответа, терминология, классы, схема полей. Поиск по документам — для того, что отвечать: регламенты, договоры, описания продуктов, всё, что меняется и на что нужна ссылка. Авторы самого подхода RAG (откроется в новой вкладке) ещё в 2020 году называли ссылку на источник и обновление знаний нерешёнными проблемами моделей, которые хранят знания только в параметрах.

Дообучение учит модель, как отвечать. Что отвечать, ей должны дать документы.

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

Живые данные — цены, остатки, статусы заказов — не годятся ни для дообучения, ни для индекса: веса устареют к утру, индекс — к обеду. Здесь модель должна вызывать запрос к 1С или CRM как инструмент и пересказывать то, что вернула система. Для этого ей достаточно права на чтение.

Что попало в веса, оттуда не удалить

Модель может запоминать обучающие данные дословно. Carlini и соавторы (откроется в новой вкладке) (USENIX Security 2021) извлекли из GPT-2 фрагменты обучающего набора с именами, телефонами и адресами электронной почты — в том числе такие, что встречались в данных всего в одном документе. Дообучение на переписке с клиентами создаёт ту же возможность: при подходящем запросе модель может воспроизвести чужой номер телефона.

Выборочно удалить сведения из параметров модели нельзя. Обзор Cooper и ещё более 30 соавторов (откроется в новой вкладке) (2024) приходит к выводу, что «машинное разобучение» не даёт универсального способа убрать конкретную информацию из весов.

По 152-ФЗ (откроется в новой вкладке) после отзыва согласия оператор обязан уничтожить персональные данные (ПДн) в срок не более 30 дней, если у него нет другого законного основания их обрабатывать (ч. 5 ст. 21). Если обработка неправомерна и исправить это нельзя — в течение 10 рабочих дней (ч. 3 ст. 21). В поиске по документам это одна операция: удалить документ, его фрагменты и векторы из индекса. С дообученной моделью единственный надёжный путь — обучить её заново без этих примеров, прогнать эталонный набор и заменить веса везде, где лежат копии. Технически это возможно, прогон стоит сотни рублей, но тогда каждый отзыв согласия запускает такой цикл.

Векторы — тоже не обезличивание. В списке рисков OWASP для приложений с языковыми моделями (LLM08:2025 (откроется в новой вкладке)) отдельно названа инверсия эмбеддингов: по сохранённым векторам злоумышленник может восстановить значительную часть исходного текста. Векторы документов с ПДн хранят и удаляют так же, как сами документы.

Как устроен поиск по документам на русском

«Загрузить документы в векторную базу» — только половина поиска. Векторный поиск находит по смыслу: на вопрос «как вернуть бракованный товар» он поднимет раздел «Порядок возврата», хотя общих слов почти нет. Но точные обозначения — артикулы, номера договоров, ИНН — векторы различают плохо: для эмбеддинга «договор 47/2025» и «договор 74/2025» почти одно и то же. Полнотекстовый поиск ведёт себя наоборот: точное совпадение найдёт, синоним — нет.

1. Нарезать документыкуски под лимит эмбеддинга
2. Метки доступакто может видеть каждый кусок
3. Два поиска (главный шаг)векторный и полнотекстовый
4. Слить и упорядочитьRRF, затем реранкер
5. Ответ со ссылкойчеловек проверяет источник

Поэтому рабочая схема для русского языка — два поиска сразу. Первый — векторный, второй — полнотекстовый в Postgres с конфигурацией russian: стеммер сводит «договора», «договоров» и «договору» к одной основе. Два списка сливают методом Reciprocal Rank Fusion: каждый фрагмент получает сумму 1/(60 + место в списке) по обоим спискам, и то, что стоит высоко в обоих, поднимается наверх. Затем реранкер — модель, которая читает вопрос и фрагмент вместе, например открытая bge-reranker-v2-m3 (откроется в новой вкладке) (Apache 2.0), — переупорядочивает 20–50 кандидатов, и в языковую модель уходят 5–20 наиболее подходящих фрагментов. Эти числа — ориентир для старта, а не норма: их подбирают на эталонном наборе.

Открытых эмбеддинг-моделей с хорошим русским на октябрь 2026 года несколько: BGE-M3 (откроется в новой вкладке) (MIT, до 8 192 токенов), FRIDA (откроется в новой вкладке) от Сбера (MIT, но только 512 токенов — документы придётся резать мельче), Giga-Embeddings от Сбера (MIT), Qwen3-Embedding (откроется в новой вкладке) (Apache 2.0, до 32K токенов). Общее сравнение даёт бенчмарк ruMTEB (откроется в новой вкладке), но выбирать стоит на своих данных: возьмите 50 реальных вопросов, для каждого отметьте правильный фрагмент и посчитайте, у какой модели он чаще попадает в первую десятку.

Векторизация недорога и в облаке: в Yandex AI Studio (откроется в новой вкладке) эмбеддинги стоят 0,0101 ₽ за 1 000 токенов (с НДС, октябрь 2026). Архив из 10 000 страниц по 500 токенов — 5 млн токенов — индексируется примерно за 50 ₽. Если документы нельзя передавать провайдеру, те же открытые модели работают на вашем сервере.

Одна техническая ловушка. Расширение pgvector (откроется в новой вкладке) (версия 0.8.7) индексирует векторы до 2 000 измерений для типа vector и до 4 000 для halfvec. Старшая Qwen3-Embedding выдаёт 4 096 измерений, и такой вектор в индекс не войдёт. Выход — задать модели меньшую размерность (она это позволяет, от 32 до 4 096) или индексировать только начало вектора: pgvector это умеет.

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

И главное ограничение: ссылка на источник не гарантирует правоту. Исследование Stanford RegLab (откроется в новой вкладке) (Journal of Empirical Legal Studies, 2025) проверило коммерческие юридические системы, построенные на поиске по документам: они выдумывали или искажали сведения в 17–33% ответов. Отдельный тип ошибки — ссылка на реальный источник, который утверждение не подтверждает. Поэтому интерфейс должен показывать сам фрагмент, а не только название файла: так человек проверит ответ за секунды.

Ссылка на источник — не доказательство правоты, а способ быстро её проверить.

Почему не загрузить всё в контекст на миллион токенов

Контекст в миллион токенов выглядит заменой поиску: отдать модели весь архив, и пусть ищет сама. Замеры говорят обратное. В тесте RULER (откроется в новой вкладке) (COLM 2024) из моделей, заявляющих контекст 32K и больше, удовлетворительное качество на длине 32K сохранила лишь половина. Работа Lost in the Middle (откроется в новой вкладке) (TACL, 2024) показала другую проблему: модель хуже использует сведения из середины длинного контекста, чем из его начала и конца.

На своём сервере длинный контекст оплачивается видеопамятью под KV-кэш, и на нескольких пользователей её уходит больше, чем на сами веса; подробно — в статье про сервер для языковой модели.

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

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

Дообучение оправдано, когда задача — устойчивая форма, а промпт с примерами не дотягивает на эталонном наборе: строгая структура ответа, тон компании, ваши классы, своя схема полей. Ещё один повод — перенести узкую задачу на модель поменьше, чтобы она работала быстрее или помещалась на ваш сервер. Это гипотеза, которую проверяют на эталоне, а не заранее известный результат.

Почти всегда достаточно LoRA — дообучения небольших добавочных матриц вместо всех весов модели. В исходной работе (откроется в новой вкладке) на модели размера GPT-3 это сократило число обучаемых параметров в 10 000 раз и потребность в видеопамяти в 3 раза, а задержки при работе не добавило. Для бизнеса важно и другое её свойство: по данным работы LoRA Learns Less and Forgets Less (откроется в новой вкладке), она хуже полного дообучения усваивает новую область, но и меньше забывает то, что модель умела до этого. Полное дообучение всех весов малому бизнесу почти не нужно.

1. Ступень 1: Промпт с примерамиформат и стиль на нескольких образцах
2. Ступень 2, выделена: Поиск по документамфакты со ссылкой; документ можно удалить
3. Ступень 3: Гибридный поисквекторы, полнотекст и реранкер
4. Ступень 4: LoRA-дообучениеформа ответа, классы, схема полей
5. Ступень 5: Полное дообучениемалому бизнесу почти не нужно

Пример задачи на форму — классификация входящих документов по типам и маршрутам; о ней подробно в статье про документы и ИИ. Поиск по архиву договоров обычными словами и сортировку входящих мы настраиваем в рамках услуги «Документооборот с ИИ».

Сколько стоит: железо дёшево, данные дороги

Видеопамяти для дообучения нужно меньше, чем кажется. Минимальные требования Unsloth (откроется в новой вкладке) на октябрь 2026: для QLoRA (модель в 4 битах) — 6 ГБ на модель 8B, 8,5 ГБ на 14B, 26 ГБ на 32B, 41 ГБ на 70B; для LoRA в 16 битах — 22 ГБ на 8B и 76 ГБ на 32B. Это абсолютный минимум, длинные примеры требуют больше. Авторы QLoRA (откроется в новой вкладке) дообучили модель на 65B на одной видеокарте с 48 ГБ без потери качества относительно 16-битного дообучения.

Если дообучать YandexGPT Lite прямо в Yandex AI Studio, на стадии Preview сам процесс дообучения не тарифицируется, а дообученная модель оплачивается по тарифу базовой (октябрь 2026).

Дорого другое. Обучающий набор — это 200–1 000 примеров, каждый из которых человек проверил и при необходимости исправил: качество набора важнее размера, это главный практический вывод LIMA и QLoRA. Допустим, на проверку одного примера уходит 3 минуты, а час специалиста стоит 800 ₽. Тогда 500 примеров — это 25 часов и 20 000 ₽: в 7–22 раза больше счёта за GPU для модели на 32B из расчёта выше. К этому добавляются эталонный набор и повторные замеры после каждого изменения.

Порядок работ

1. Эталонный набор. 50–200 реальных обезличенных вопросов с ожидаемым ответом и документом-источником. Сколько примеров нужно, чтобы разница между вариантами что-то значила, — в статье о том, где ИИ окупается.
2. Промпт с примерами. Базовая модель, хорошая инструкция и несколько образцов ответа — это первый замер.
3. Поиск по документам. Гибридный, с реранкером и фильтром по правам.
4. Разбор ошибок. Для каждой ошибки на эталоне выясните, где она возникла: поиск не нашёл нужный фрагмент или фрагмент нашёлся, но модель ответила не так. Первое исправляют нарезкой, эмбеддингами и реранкером — дообучение здесь не поможет. Второе — кандидат на дообучение.
5. LoRA или QLoRA — только если разрыв остался: 1–3 эпохи, 10–20% примеров на валидацию, без ПДн в наборе.
6. Повторный прогон эталона после каждого изменения модели, промпта или индекса.

Где всё это запускать — в российском облаке, на арендованной GPU или на своём сервере — разобрано в статьях «Локальная модель или API» и «Свой сервер для языковой модели».