RAG и дообучение LLM: точность, задержка и стоимость

Поэтому вопрос «что точнее?» не имеет ответа вне конкретной задачи и конфигурации.

Опубликованные эксперименты показывают, насколько велик разброс. В исследовании исправления названий товаров RAG с контекстным дообучением дал F1 71,0 против 64,1 у базового дообучения; в классификации текстов о психическом здоровье дообученная LLaMA 3 показала точность 91% на классификации эмоций. Эти цифры нельзя поставить в один рейтинг: различаются задачи, модели и данные. Зато они помогают понять, что именно нужно измерять при выборе архитектуры.

Как работают RAG и дообучение

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

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

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

Исходная работа о RAG, опубликованная в 2020 году, описывала архитектуру, сочетающую параметрическую память генеративной модели с непараметрической памятью — плотным векторным индексом Wikipedia. Нейронный ретривер, то есть компонент поиска, выбирал материал для ответа. В экспериментах авторы сообщили о сильных результатах на трёх задачах открытого вопросно-ответного поиска. Это свидетельство возможностей конкретной системы на конкретных наборах данных, а не гарантия превосходства RAG в любой прикладной задаче.

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

Точность: одна метрика не описывает все задачи

Сравнение RAG и дообучения часто сводят к одному числу, хотя метрика отвечает только на вопрос, который заложен в конкретный тест. F1, например, объединяет точность и полноту обнаружения целевого класса в одну оценку. Она полезна для задач вроде исправления названий, но не измеряет качество поиска по внутренним документам или корректность длинного ответа.

В исследовании 2024 года по коррекции написания названий товаров использовали Mistral-7B и индекс из 572 тысяч документов, включавший 132 тысячи уникальных брендов. Базовое дообучение показало F1 64,1, а RAG с контекстным дообучением — 71,0. Для запросов, содержащих названия брендов, разница была заметнее: F1 составил 44,1 и 60,8 соответственно.

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

Число из бенчмарка описывает модель, данные и задачу вместе. Вне этой связки оно перестаёт быть прогнозом качества продукта.

Другой результат получен в исследовании 2025 года, где сравнивали стратегии для анализа текстов о психическом здоровье на LLaMA 3. Дообучение показало точность 91% при классификации эмоций и 80% при выявлении состояний. Для prompt engineering — настройки поведения через инструкции в запросе — и RAG в аннотации указана точность в диапазоне 40–68%.

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

Поэтому в продуктовой оценке полезно разделять как минимум три уровня:

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

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

Задержка RAG-системы: важна вся цепочка

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

В исследовании коррекции товарных названий, где использовали Mistral-7B, поиск по пулу из 60 тысяч документов добавлял 2,42% к общему времени генерации, а поиск по 572 тысячам документов — 2,79%. Это результаты конкретной системы. Их нельзя использовать как типовой прогноз задержки любого RAG-сервиса: другая архитектура поиска, оборудование или объём контекста способны изменить картину.

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

Исследование системных компромиссов при инференсе RAG описывает сценарии, в которых неэффективная конфигурация увеличивала TTFT вдвое. Авторы также отмечают, что неоптимизированные хранилища могут занимать терабайты. Эти наблюдения указывают на инженерные риски, а не задают норматив задержки для всех систем. Хорошо настроенный индекс и неудачно настроенный индекс нельзя сравнивать по одному слову «RAG».

Практическое измерение лучше строить по компонентам:

1. Замерить время поиска отдельно от генерации, чтобы увидеть, где возникает основная задержка.

2. Проверить несколько реалистичных размеров корпуса и долю запросов, требующих обращения к источнику.

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

4. Оценивать не только среднее время, но и распределение задержек, включая медленные запросы, которые заметны пользователю.

5. Повторить замеры на целевом оборудовании и при ожидаемой нагрузке: тест на небольшом стенде не описывает поведение сервиса в эксплуатации.

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

Стоимость владения: модель, индекс и обновление данных

Универсальной цены RAG и fine-tuning нет. Сопоставимый расчёт требует одинаковых условий: модели, оборудования, числа запросов, размера входного контекста и периода эксплуатации. Исследования, приведённые здесь, не устанавливают общего денежного порога, после которого один подход всегда становится выгоднее другого.

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

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

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

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

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

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

Когда подходы сочетают

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

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

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

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

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

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

Практический выбор вместо общего рейтинга

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

Трезвая оценка начинается с собственного набора запросов и заранее заданных метрик. Показатели F1 71,0 в задаче исправления брендов и точность 91% в классификации эмоций полезны как ориентиры для чтения исследований, но не как прогноз для конкретного сервиса. Универсального порога по точности, задержке или стоимости, который автоматически выбирает RAG либо дообучение, доступные результаты не устанавливают.

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