RAG или дообучение: что выбрать

Когда необходимо, чтобы LLM хорошо работала в Вашей конкретной предметной области, у Вас есть две основные стратегии: генерация с дополнением извлечёнными данными (RAG) динамически добавляет релевантные знания во время вывода, тогда как дообучение обновляет веса модели, встраивая в неё знания, стиль или предпочтения к формату. Правильный выбор между ними может означать разницу между надёжной системой и месяцами дорогостоящих вычислений на GPU, потраченных на неподходящий подход.

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

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

В любом случае, когда информация со временем меняется, RAG явно превосходит другие подходы. Переиндексация векторного хранилища при обновлении документов занимает минуты и не требует ресурсов GPU. Дообучение модели на новых данных требует повторного обучения (это дорого и медленно), и даже после этого модель может ненадёжно вспоминать новые факты. Каталоги товаров, правовые нормы, медицинские рекомендации и политики компаний лучше обслуживать с помощью RAG, а не дообучения.

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

Дообучение имеет высокую первоначальную стоимость (вычисления для обучения, время на подготовку набора данных и оценку), но снижает стоимость отдельного запроса, если благодаря дообучению можно использовать модель меньшего размера. У RAG низкая первоначальная стоимость (индексация в векторной базе данных обходится дёшево), но он добавляет накладные расходы на каждый запрос: вызов API для получения векторного представления и немного более длинные запросы со вставленным контекстом. Для большинства приложений с менее чем 10 миллионами запросов в день накладные расходы RAG на отдельный запрос незначительны по сравнению со стоимостью разработки при дообучении.

Дообученные модели могут быть быстрее во время вывода, поскольку требуют более коротких запросов: знания находятся в весах, а не в контексте. RAG добавляет два обмена данными: вызов API для получения векторного представления и запрос к векторному поиску. Общие накладные расходы обычно составляют 50–200 мс. Для приложений, чувствительных к задержке, например голосовых помощников реального времени, это важно. Для большинства приложений чата и вопросов и ответов дополнительная задержка незаметна пользователям.

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

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

Следуйте этому алгоритму: проблема связана с единообразием стиля или формата? → Рассмотрите дообучение. Информация закрытая или часто обновляется? → Используйте RAG. Нужны цитаты источников? → Используйте RAG. Набор данных слишком мал для дообучения (менее 500 примеров)? → Используйте RAG с обучением на нескольких примерах. Нужно, чтобы модель выполняла задачу, которую она сейчас отказывается выполнять? → Дообучите её с помощью RLHF или DPO. Если Вы сомневаетесь, начните с RAG: его быстрее создать, проще обновлять, и он прозрачнее.

Используйте эти сценарии для формирования интуитивного понимания: внутренний чат-бот HR (политики меняются ежеквартально, необходимо цитировать источники) → RAG. Автодополнение кода для собственной платформы (единообразный стиль кода, шаблоны платформы) → дообучение. Вопросы и ответы по юридическим документам (закрытые документы, необходимы точные цитаты) → RAG. Бот поддержки клиентов (определённый тон, FAQ о продуктах меняется еженедельно) → дообучение для тона + RAG для знаний. Система обобщения медицинской литературы (актуальные исследования, критически важна атрибуция) → RAG.

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