RAG или дообучение: как выбрать подход под вашу задачу

Промпт, RAG и обучение решают разные части задачи

Промпт и примеры в контексте задают инструкцию на конкретный вызов. В них можно описать формат, показать правильный ответ и приложить небольшой документ. Параметры модели при этом не меняются.

RAG добавляет этап поиска: приложение находит подходящие фрагменты и передаёт их модели вместе с вопросом. Документация Microsoft Foundry связывает этот подход с частными и меняющимися данными. Ответ можно снабдить ссылками, но поиск и генерация всё равно требуют проверки.

Fine-tuning, или дообучение, меняет веса предварительно обученной модели на данных задачи. Microsoft описывает адаптацию стиля, структуры и выполнения задачи; улучшение не гарантировано. В этом разборе основной пример — обучение по парам «вход → желаемый ответ», а не создание модели с нуля.

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

Матрица выбора: что менять и что измерять

Это рекомендации Dev Crabs для постановки пилота, а не результаты измерений. Они помогают выбрать следующий эксперимент; ни одна строка не обещает преимущество конкретной модели.

Размещение — отдельный выбор: RAG и дообучение возможны в разных инфраструктурных схемах. Ограничения по передаче данных разбираем в статье о локальных LLM и облачном AI.

Три ошибки на вымышленном регламенте

Учебный пример, не клиентский кейс и не проведённый benchmark. Ниже — три вымышленные заявки. Числа обозначают условный лимит из регламента; это не стоимость услуги и не показатель качества модели.

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

Если лимит можно однозначно проверить обычным условием в программе, вынесите окончательную проверку туда. Модель может извлекать данные или готовить объяснение, а решение по формальному правилу — принимать проверяемый код.

Как провести честный сравнительный пилот

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

1. Зафиксируйте условия. Версия документов, модель, инструкция, параметры генерации, права пользователя и нагрузка. Составьте эталонные ответы с допустимыми вариантами. Включите отсутствие ответа в источниках, смену версии и запрос без доступа.
2. Разделите данные до настройки. Обучающий набор, набор для подбора решений и закрытый финальный тест. Связанные заявки и почти одинаковые документы не должны одновременно обучать и проверять систему. Для свежих правил полезен отдельный временной срез.
3. Соберите базу. Инструкция, несколько согласованных примеров и проверка формата. Затем добавьте retrieval к той же базовой модели. Если документов мало, сравните поиск с передачей всего допустимого контекста.
4. Добавьте обучение только с обоснованием. Нужны пригодные примеры и конкретная категория оставшихся ошибок. Сначала сравните базовую и дообученную версии при одинаковом контексте. Затем при необходимости проверьте гибрид. Замена семейства модели — отдельный фактор эксперимента.
5. Измерьте результат. Доля принятых ответов, критические ошибки, верность ссылок, корректность отказов, время до готового результата и полные затраты. Повторите прогоны, если ответы нестабильны; сохраняйте разброс, а не только лучший ответ.
6. Примите решение. Выберите наименее сложный вариант, который проходит обязательные критерии. Если ни один не проходит, зафиксируйте ограничения и следующий проверяемый шаг. Не переносите неудачный пилот в production ради уже потраченного времени.

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

Сравнивайте стоимость принятого результата

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

Разовые затраты покажите отдельно от регулярных и явно укажите период их распределения. Для пилота считайте сам эксперимент; для эксплуатации — ожидаемую нагрузку с проверкой чувствительности к её изменению. Такой расчёт не заменяет тарифы выбранного поставщика и замеры на ваших данных.

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

Когда нужен гибрид и кто его поддерживает

Гипотеза для гибрида: документы часто меняются, а ответы требуют устойчивой классификации или особого формата. RAG поставляет актуальный контекст, дообученная модель применяет освоенный способ обработки. Усложнение оправдано только дополнительным выигрышем на независимой проверке.

Назначьте владельцев документов, правил разметки, поискового индекса и модели. Сохраняйте версии и процедуру отката; после изменения регламента повторяйте затронутые сценарии. Не считайте факт загрузки файла подтверждением того, что его новая версия уже используется.

Факт о правах: Azure AI Search документирует фильтрацию результатов по доступу к документам; для механизмов с метаданными прав изменения отражаются после их синхронизации. Некоторые встроенные варианты помечены preview. Это описание конкретной платформы, не автоматическое свойство любой RAG-системы.

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

С чего начать обсуждение решения

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

Если основной пробел — поиск по актуальным документам, смотрите RAG и корпоративные базы знаний. Если после базовых улучшений остаются ошибки поведения и есть пригодная разметка — дообучение LLM под задачу компании. Выбор готового продукта или собственной разработки разбираем в отдельной статье.

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

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