Fine-tuning или RAG: что выбрать, когда модель ошибается

Спор о том, что лучше — fine-tuning или RAG — обычно сводят к сравнению цены и точности. Это неправильная постановка вопроса. Эти два подхода меняют разные вещи, поэтому сначала надо понять, что именно сломано.

Главное различие

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

Fine-tuning меняет веса. Он сдвигает распределение, из которого модель семплирует, — в сторону ваших форматов, стиля, разбиения задачи на шаги, словаря меток. Никакого источника не прикрепляет, без нового обучения не обновляется, применяется одинаково ко всем запросам.

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

Ошибка первая: обучать на факты

Логика обычно такая: у нас 40 000 страниц документации, давайте сделаем fine-tuning, и модель будет знать продукт. На деле модель выучивает стиль документации — заголовки, ритм, оговорки — и выдаёт гладкие, хорошо оформленные, уверенно неверные ответы.

Механизм простой. Факт, встречающийся один раз в 40 000 страниц, даёт ничтожную долю градиентного сигнала. Стилистика встречается на каждой странице и попадает в каждый батч. Градиентный спуск — машина частотности, он учит частое.

Симптом стоит научиться замечать: после fine-tuning под знания ответы выглядят лучше, но не становятся точнее, и модель заметно охотнее отвечает на вопросы, на которые должна отказать. Вторая часть важнее.

Ошибка вторая: retrieve для поведения

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

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

Формат — это то, в чём fine-tuning действительно силён. Если в вашем промпте появился раздел про стиль длиннее, чем описание самой задачи, — это датасет для fine-tuning, который ещё не записан.

Что показали опубликованные сравнения

Две работы стоят того, чтобы прочитать их целиком.

• Ovadia et al., 2023 — Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs (arXiv 2312.05934). Сравнивали некотролируемый fine-tuning с retrieval для ввода новых фактов и обнаружили, что retrieval опережает на задачах, требующих знаний, — даже на фактах, которые модель видела при предобучении.
• Gekhman et al., 2024 — Does Fine-Tuning LLMs on New Knowledge Encourage Hallucinations? (arXiv 2405.05904). Нашли, что примеры с действительно новыми знаниями усваиваются медленно, и по мере их усвоения модель начинает галлюцинировать чаще на других вопросах. Это лучшее объяснение симптома «уверенно неверно и теперь более склонна угадывать».

Ни одна из работ не говорит, что fine-tuning бесполезен. Обе говорят, что это неправильный инструмент для знаний — ровно тот вывод, о котором статья.

Они сочетаются, и обычно так и надо

Зрелая конфигурация — обе: retrieval даёт факты, а fine-tuning учит модель работать с извлечённым контекстом: когда цитировать, как сказать «документы не отвечают на этот вопрос», как примирить противоречащие пассажи, что выдать, когда retrieval пуст.

Последнее поведение — настоящая цель для fine-tuning, отказ при недостаточном контексте — это поведение, а не факт. Обучить модель отказываться — значит научить её политике, а это как раз то, что веса кодируют хорошо.

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

Выбор: четыре вопроса

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

Fine-tuning и RAG не конкурируют за один бюджет. Они чинят разные поломки. Сначала диагностика: меняется ли ответ? нужен ли источник? это форма или суждение? раздулся ли промпт? Ответы уже дают архитектуру, а не вкусовщину.