RAG или fine-tuning: как выбрать решение по ошибкам LLM

RAG меняет контекст, дообучение — параметры

Обычное RAG-приложение ищет документы и передаёт выбранные фрагменты модели вместе с вопросом. В документации Google Cloud загрузка, преобразование, индексация, поиск и генерация описаны как отдельные этапы. Поэтому изменение правил может обновить доступные сведения без нового обучения модели, когда загрузка и индекс уже обработали новую версию документа.

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

• Google Cloud: RAG Engine overview
• Google Cloud: Introduction to tuning
• Lewis et al.: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

Сначала установите причину ошибки

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

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

Разбор сравнения: помощник по подпискам

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

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

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

Качество RAG зависит от выбора сведений

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

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

Качество дообучения зависит от примеров

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

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

• Google Cloud: Introduction to tuning

Оценивайте поиск отдельно от финального ответа

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

Сравнивайте базовый промпт, промпт с поиском и дообученные варианты на одинаковых отложенных вопросах. Добавьте неизвестный регион, недоступный документ, конфликт редакций и недавно изменённое правило продления. Учитывайте обоснованный отказ от ответа наряду с успешными ответами. Измеряйте полное время и стоимость с неудачными попытками. Вручную проверяйте критические ошибки и сверяйте с этими решениями оценки моделей. Любые предполагаемые показатели остаются гипотезой, пока вы не провели эксперимент на своих данных.

• Microsoft: Retrieval-Augmented Generation evaluators

Сравните эксплуатацию и ограничения

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

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

Проверяемый список для выбора подхода

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

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

• RecallDeck: что такое ИИ-агенты

Коротко

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