RAG или дообучение? Чему реальные проекты с клиентами научили нас в выборе подхода

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

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

Начните с того, чего не хватает модели

Если модель плохо справляется с бизнес-задачей, ей не хватает одного из двух.

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

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

Для решения первой проблемы подходит RAG, для второй — дообучение. Большая часть путаницы, с которой я сталкиваюсь, возникает из-за попыток использовать дообучение для передачи фактов.

Почему дообучение — плохой способ пополнить знания модели

Заманчиво думать, что, обучив модель на своих документах, вы заставите её их «знать». На практике она гораздо надёжнее усваивает стиль этих документов, чем содержащиеся в них факты. Исследователи из Microsoft напрямую сравнили оба подхода на вопросах, требующих обширных знаний, и обнаружили, что RAG неизменно превосходил обучение без учителя — как при работе с фактами, встречавшимися модели во время обучения, так и с совершенно новыми.

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

В RAG, впервые описанном в статье Льюиса и соавторов за 2020 год, знания хранятся вне модели. При получении вопроса вы находите релевантные фрагменты и передаёте их модели в качестве контекста. Чтобы обновить знания, достаточно обновить индекс — переобучать модель не нужно. Кроме того, в каждом ответе можно указать источник.

Хороший пример — один из наших клиентов в сфере логистики. Его заказчики хотели мгновенно узнавать, где находятся их грузы и каких документов не хватает. Эта информация меняется каждые несколько минут. Никакое обучение не позволило бы поддерживать модель в актуальном состоянии, поэтому созданный нами помощник при каждом запросе отвечает на основе данных отслеживания грузов и устройств Интернета вещей в реальном времени, а не по памяти. Единственным работоспособным решением был поиск.

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

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

• Строгий, повторяющийся формат вывода. Если модель должна тысячи раз в день выдавать одинаковый структурированный результат — например, извлекать данные из счетов в соответствии с фиксированной схемой JSON, — небольшая дообученная модель зачастую надёжнее и обходится намного дешевле, чем большая модель, которой задают инструкции в запросе.
• Отраслевая терминология. В некоторых областях используются сокращения, которые базовая модель интерпретирует неверно. Типичные примеры — коды статусов в логистике, клинические сокращения и внутренние коды продуктов. Устранить эту проблему можно с помощью несложного дообучения.
• Снижение затрат и задержек при масштабировании. Когда задача чётко определена, небольшая дообученная модель может заменить большую универсальную модель. Такие методы, как LoRA, делают это доступным по цене: вместо обучения всей модели настраивается небольшой набор дополнительных весов.

Обратите внимание: ни один из этих случаев не связан с фактами. Речь идёт о том, чтобы научить модель выполнять уже хорошо понятную вам задачу нужным образом.

Большинство сбоев RAG связано с поиском

Когда команда говорит мне: «Мы попробовали RAG, но он не сработал», проблема редко заключается в модели. Обычно дело в этапе поиска. Качество модели не может быть выше качества переданных ей фрагментов.

Исправления не впечатляют, но помогают:

• Разбивайте текст по смыслу, а не по количеству символов. Если разделять договор каждые 500 символов, пункты окажутся разорваны пополам. Разбиение по разделам и заголовкам позволяет сохранить контекст.
• Добавляйте контекст к каждому фрагменту. Фрагмент со словами «срок составляет 30 дней» бесполезен, если неизвестно, к каким правилам он относится. Anthropic сообщила, что добавление краткого контекста документа к каждому фрагменту перед индексацией — подход, который компания называет контекстным поиском, — сократило число неудачных поисковых запросов на 49%, а при использовании совместно с повторным ранжированием — на 67%.
• Сочетайте поиск по ключевым словам с векторным поиском. Векторный поиск хорошо улавливает смысл, но плохо справляется с точными терминами, например с номерами деталей. Гибридный поиск позволяет учесть и то и другое.
• Проверьте качество поиска отдельно. Составьте набор реальных вопросов с известными правильными исходными фрагментами и оцените, попадает ли нужный фрагмент в число первых результатов, прежде чем оценивать итоговые ответы.

Когда стоит использовать оба метода

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

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

Простой список вопросов для принятия решения

1. Зависит ли задача от фактов, которые меняются чаще одного раза в квартал? Используйте RAG.
2. Нужно ли пользователям или аудиторам видеть, откуда взялся ответ? Используйте RAG.
3. Проблема связана с форматом, тоном или лексикой ответов, а не с их фактической точностью? Рассмотрите дообучение.
4. Это узкоспециализированная задача, которая выполняется в больших объемах и для которой важны стоимость или скорость? Рассмотрите дообучение модели меньшего размера.
5. Оценивали ли вы качество поиска отдельно? Если нет, начните с этого.

Главный вывод

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