RAG, тонкая настройка или агенты: выбор подходящего уровня и порядка его создания
RAG против тонкой настройки против ИИ-агентов: что делает каждый из них, стоимость, задержки и способы сбоев, ориентировочные правила, а также вспомогательный инструмент для HR, показывающий порядок их создания.
Источники: RAG vs Fine-Tuning vs AI Agents: When to Use What in Real-World AI Systems
Почти в каждом проекте с ИИ-моделями рано или поздно возникают два вопроса. Первый — следует ли загружать документы или настраивать модель под конкретные задачи. Второй — нужен ли продукту агент или достаточно более умных инструкций. Удивительно часто на эти вопросы дают плохие ответы, причем не только начинающие. Опытные инженеры тратят недели на настройку модели, чтобы та запоминала факты, которые можно было бы получить за один день с помощью запроса к источникам информации. Другие команды добавляют к стандартному интерфейсу для ответов на вопросы структуру агента лишь потому, что тема агентов обсуждалась на всех собраниях в тот квартал.
Менее захватывающая реальность заключается в том, что механизмы поиска информации, тонкой настройки и агенты не являются конкурентами в выполнении одной и той же задачи. Каждый из них решает отдельную проблему, а системы, работающие с реальными пользователями, обычно сочетают два из них или все три, при этом каждый компонент выполняет то, в чём он лучше всего справляется. Далее рассматривается, как работает каждый из этих компонентов, сколько они стоят, как команды злоупотребляют ими, как они взаимодействуют между собой, а также приводится небольшой проект, демонстрирующий порядок их создания.
Что на самом деле делает каждый компонент
Генерация с усилением поиска информации
Механизм поиска информации не влияет на саму модель. Он лишь изменяет то, что модель читает перед тем, как отвечать.
Когда поступает вопрос, система преобразует его в эмбеддинг — числовое представление его смысла, — затем ищет в векторной базе данных, такой как Pinecone, Qdrant, FAISS или Azure AI Search, хранимые фрагменты, наиболее близкие по смыслу. Эти фрагменты включаются в запрос в качестве контекста, и модель отвечает на основе этого материала, а не на основе того, что она усвоила во время предварительной обучения.
Ценность заключается в том, что это предотвращает ошибки. Модели с наибольшей легкостью выдумывают детали, когда вынуждены отвечать, опираясь на внутреннюю память, особенно по темам, которые являются недавними, малоизвестными или специфичными для определенной компании. Предоставление модели ссылочного текста при каждом вызове позволяет ей рассуждать на основе актуального материала и не делать угадываний.
Пайплайн имеет фиксированную структуру: загрузка документов, их разделение на фрагменты, встраивание этих фрагментов, хранение векторов, выполнение поиска по сходству (часто в сочетании с поиском по ключевым словам), при необходимости переранжирование кандидатов, сбор промпта и генерация результата.
Тонкая настройка
Тонкая настройка отличается по своей сути, а не только по степени. Заранее обученная модель продолжает обучение на тщательно отобранном наборе собственных примеров, обычно парах входных данных и желаемого результата, демонстрирующих именно ту поведенческую модель, которая требуется. Изменяются веса, или при использовании LoRA и QLoRA меняется небольшой набор весов адаптера, добавляемый к замороженной базовой модели.
Этот подход хорошо подходит для обучения определённым навыкам: тону голоса, строгому формату вывода, особому способу решения определённого типа задач или обработке крайних случаев в области, где существуют тысячи примеров с метками. Цель — изменить стандартное поведение так, чтобы одни и те же инструкции не требовались в каждом запросе, а не просто добавлять новые факты.
Он плохо справляется с тем, что постоянно меняется. Каталог продуктов, обновляемый еженедельно, не может разумно храниться в весах модели, поскольку знания замерзают по окончании обучения, и каждое обновление требует новой обработки.
Агенты
Агент помещает модель в цикл: наблюдение, рассуждение, действие, наблюдение за результатом, снова рассуждение, и так далее, пока не будет достигнута цель или не сработает правило остановки. Модель больше не выдает единственный ответ. Она решает, что делать дальше, часто с помощью инструментов вроде API, функций, баз данных и других сервисов, и использует их результаты для следующего решения.
Именно этот цикл превращает систему, отвечающую на вопросы, в систему, выполняющую задачи. LangGraph, CrewAI и ручно написанный цикл ReAct — все они реализуют его версию: модель формулирует мысль, выбирает инструмент, инструмент выполняется, результат возвращается в контекст, и цикл повторяется, пока агент не решит, что работа завершена, или не будет достигнут лимит шагов. Лимит шагов всегда следует устанавливать.
Краткий способ различить эти три компонента:
- Функция получения информации обеспечивает необходимые данные.
- Тонкая настройка обеспечивает правильное поведение.
- Агенты дают необходимую степень автономии.
Параллельно
Различия проявляются в нескольких аспектах:
- Обновление знаний. Получение информации происходит в реальном времени, поскольку достаточно обновить хранилище векторов. Знания, полученные в результате тонкой настройки, замораживаются до следующей тренировки. Для агентов это зависит от того, что они получают или вызывают.
- Затраты. Затраты на получение информации умеренные: эмбеддинги, хранение и дополнительные токены входных данных. Затраты на тонкую настройку высоки из-за подбора данных, вычислительных ресурсов, времени работы GPU и оценки. Затраты на агентов варьируются от умеренных до высоких, поскольку каждая задача включает несколько вызовов модели плюс оплату за использование инструментов.
- Сложность. Для поиска необходимы разбиение данных на части, использование эмбеддингов и настройка алгоритмов поиска. Для тонкой настройки требуется подготовка данных, инфраструктура обучения, циклы оценки и защита от переобучения. Для агентов необходимо планирование, интеграция инструментов, обработка ошибок и контроль циклов.
- Время на настройку. На поиск уходят дни, на тонкую настройку — недели, а на создание агентов — от дней до недель в зависимости от рабочего процесса.
- Наиболее подходящие задачи. Ответы на вопросы, поиск документов и обеспечение основы для поиска. Тон, форматирование и рассуждения в определенной области для тонкой настройки. Многократные операции, автоматизация и использование инструментов для агентов.
- Задержка. Поиск добавляет один этап обработки, обычно от 50 до 300 миллисекунд. Тонкая настройка не влияет на скорость вывода результатов по сравнению с базовой моделью. Агенты часто выполняют несколько этапов обработки, и на одну задачу может уходить несколько секунд.
- Техническое обслуживание. Получение информации подразумевает поддержание актуальности базы знаний. Доработка предполагает переобучение периодически по мере изменения потребностей. Агенты требуют обновления рабочих процессов, инструментов и инструкций.
- Типичные сбои. Некорректное получение информации приводит к нерелевантному контексту и плохому ответу. Чрезмерная адаптация делает отточенную модель чувствительной к незнакомым данным. Агенты заходят в цикл, вызывают неправильные инструменты или приводят к неограниченным расходам.
Три ситуации, по одной для каждой
Чат-бот поддержки, работающий с документацией к продукту, упрощает поиск информации. У программной компании с 400 страницами документации, журналами изменений и правилами можно настроить модель на основе этого текста, но к моменту следующего выпуска такая настроенная модель устареет. Встраивание каждого фрагмента в хранилище векторов позволяет избежать этой проблемы. Когда клиент спрашивает, поддерживает ли API пакетные запросы, система извлекает три наиболее релевантных раздела, модель отвечает на основе их содержимого и указывает соответствующую страницу. После изменений в документации в ходе следующего цикла разработки повторное встраивание обновляет ответы без необходимости переобучения модели.
Вспомогательный инструмент для написания в стиле статьи подходит для тонкой настройки. Компания средств массовой информации хочет, чтобы резюме были написаны в строго определенном стиле: с определенным ритмом предложений, без использования первого лица и с фиксированным количеством ключевых выводов в начале. Использование промптов позволяет приблизиться к нужному результату, но со временем возникают отклонения. Обучение на примерах примерно 2 000 пар резюме, отредактированных людьми, позволяет модели надежно генерировать текст в соответствии с брендовыми стандартами, без необходимости вставлять руководство по стилю в каждый запрос.
Отбор кандидатов — задача агента. Стартап по подбору персонала хочет, чтобы при наличии соответствия кандидата требованиям вакансии происходил его отбор и запись на звонок, а остальные действия выполнялись автоматически. Агент читает резюме, сравнивает его с требованиями должности с помощью внутреннего API для оценки, проверяет календарь руководителя отдела кадров, пишет и отправляет письмо с предложением о встрече, а также фиксирует результат в системе отслеживания кандидатов. Одно указание охватывает всё это, и никто не вмешивается в отдельные этапы.
В практике постоянно встречается такое разделение задач. В дизайнах, ориентированных на получение данных, отвечает за базовую обработку информации, агенты — за координацию действий, а тонкая настройка применяется лишь тогда, когда простые указания не позволяют стабильно контролировать поведение системы.
Как они взаимодействуют
Эти три компонента не являются изолированными слоями. Самые мощные системы объединяют их в единую цепочку: запрос исходит от агента, отвечающего за планирование, затем проходит через механизм поиска фактов, после чего попадает в настроенную модель, которая формулирует результат.
User Query
↓
Agent (decides what needs to happen — plan the steps)
↓
RAG (retrieves relevant knowledge, if the step needs facts)
↓
LLM (fine-tuned, if tone/format/behavior consistency matters)
↓
Action (respond to user, call a tool, trigger a downstream workflow)
↓
Agent (evaluates result → loop again or stop)
В среде поддержки всё происходит следующим образом: поступает сообщение, а оператор определяет его цель и приходит к выводу, что требуется информация о продукте. Система поиска извлекает соответствующие фрагменты документации. Настроенная модель составляет ответ в стиле бренда. Затем оператор оценивает, достаточно ли уверенности для автоматической отправки или необходимо вмешательство человека, и в конце записывает взаимодействие в CRM.
Если удалить любой из компонентов, возникает пробел. Система поиска без оператора не может решить, когда искать информацию, а когда действовать. Оператор без системы поиска не имеет представления ни о чем, что выходит за рамки его обучающих данных. Настроенная модель без системы поиска генерирует уверенные, красиво оформленные ответы, которые могут быть устаревшими.
Стоимость каждого компонента
Приведённые ниже цифры указывают лишь приблизительные значения, поскольку реальные показатели зависят от масштаба и поставщика.
Для поиска первоначальными затратами является внедрение корпуса данных — либо однократно, либо постепенно по мере увеличения объема документов. Расходы на эксплуатацию включают хостинг векторной базы данных в соответствующем тарифном плане, а также дополнительные токены за получаемый контекст при каждом запросе. Это самый экономичный способ получения нужного результата, поэтому большинству команд следует начинать именно с него.
Для тонкой настройки основной первоначальной затратой часто являются данные: сбор и маркировка качественных примеров для обучения стоят дорого. Затем идут расходы на вычисления во время циклов обучения и оценки. После этого требуется переобучение, когда необходимо изменить поведение модели, а также хостинг специализированной модели, если не используется LoRA на общей основе. Этот подход требует наибольших первоначальных инвестиций и наименее терпим к ошибкам, поскольку плохие данные для обучения напрямую влияют на параметры модели, формируя некачественное поведение.
Для агентов настройка включает проектирование рабочих процессов, интеграцию инструментов и тестирование сценариев сбоев. Расходы во время работы представляют собой скрытую проблему, поскольку каждый шаг работы агента соответствует ещё одному вызову модели. Задача, состоящая из пяти шагов, может стоить в пять–десять раз дороже, чем один запрос на поиск информации, а цикл без ограничения количества итераций может привести к чрезмерным затратам. Стоимость отражает сложность задачи, а не просто объём её использования.
На практике поиск информации обычно является самым дешёвым способом снизить вероятность галлюцинаций. Доработка модели окупается только тогда, когда стабильное поведение является неотъемлемым требованием продукта, а не просто дополнительным преимуществом. Агенты оправдывают стоимость за выполнение задачи лишь тогда, когда для её решения требуется несколько решений и действий, а не когда достаточно одного обоснованного вызова модели.
Ориентировочные критерии выбора
- Выбирайте метод поиска информации, когда данные часто меняются. Документы, правила, каталоги, цены и запасы, которые обновляются еженедельно или ежедневно, хорошо подходят для этого метода, но плохо — для тонкой настройки.
- Выбирайте тонкую настройку, когда поведение важнее знаний. Если модель знает область применения, но продолжает использовать неправильный тон, формат или схему рассуждений несмотря на правильные указания, проблема заключается в поведении.
- Выбирайте агента, когда задача требует нескольких шагов или действий в реальном мире. Ответ на вопрос не требует этого, но определение того, что необходимо сделать, и последующее выполнение действий в разных системах, скорее всего, требуют агента.
- Сочетайте метод поиска информации и тонкую настройку, когда необходимы как достоверные факты, так и стабильный стиль изложения, что очень часто встречается в продуктах, ориентированных на клиентов.
- Сочетайте метод поиска информации и агента, когда задача требует как фактов, так и принятия решений, причем агент выбирает, что искать и когда действовать на основе полученных данных.
Та же логика отражена в двух кратких диаграммах потоков. В первой проверяется, зависит ли ответ от информации, которая часто меняется.
Does the answer depend on information that changes often?
YES → RAG
NO ↓
Во втором вопросе спрашивают о последовательности поведения и о том, включает ли задание несколько шагов или реальные действия.
Does the model need to consistently behave/sound a certain way,
and prompting alone isn't holding that consistency?
YES → Fine-tuning
NO ↓Does the task require multiple steps, tool calls, or real actions
(not just answering a question)?
YES → Agent (likely combined with RAG, and fine-tuning if voice matters)
NO → A single well-prompted LLM call is probably enough
Небольшой проект, демонстрирующий порядок действий
Возьмём внутреннего помощника по кадрам.
- Начните с поиска информации. Разместите руководство для сотрудников, правила отпусков и документы о льготах в векторном хранилище. Тогда сотрудники смогут спросить, сколько у них дней болезни, и получить обоснованный, с цитатами ответ. Это покрывает примерно 70 процентов сценариев использования и занимает несколько дней.
- Добавляйте доработки только при появлении пробелов. Предположим, отдел кадров хочет, чтобы каждый ответ имел определённый эмпатичный тон и строгую структуру: «Вот правило, вот что оно означает для вас», но запросы сотрудников постоянно отклоняются от этой структуры. Небольшая модель, отрегулированная на нескольких сотнях тщательно подобранных пар вопросов и ответов в таком стиле, поможет устранить этот пробел.
Порядок действий выбран намеренно. Сначала производится поиск информации, поскольку это самый дешевый и эффективный способ. Настройка модели происходит только тогда, когда обнаруживается реальный разрыв в поведении. Агенты применяются в последнюю очередь, и только тогда, когда задача действительно требует многоэтапных действий.
Частые ошибки
- Тонкая настройка там, где требуется поиск информации. Команды пытаются встроить знания непосредственно в веса модели, когда при решении конкретной проблемы отсутствует доступ к актуальной информации. В результате работа становится медленнее, гораздо дороже, и данные, полученные в таком случае, устаревают сразу после использования.
- Агенты без четко определенного процесса работы. Размытая цель в сочетании с неограниченным набором инструментов приводит к тому, что агент действует хаотично, заходит в замкнутые циклы и ведет себя непредсказуемо. Ограниченный набор инструментов, четкие условия остановки и строгий лимит на количество шагов рассуждений помогают удерживать его в рамках заданных правил, в то время как простое указание на необходимость самостоятельного решения проблемы не заменяет четко определенного процесса.
- Игнорирование задержек и затрат. Каждый шаг поиска информации и каждое действие агента требуют дополнительных операций и оплаты за использование ресурсов. Демо-версия может выглядеть отлично, но в реальных условиях для получения одного ответа может потребоваться 12 секунд и шесть вызовов модели.
Направление развития
Индустрия явно движется к агентным рабочим процессам, то есть к системам, которые планируют, действуют и контролируют ход дел без постоянных указаний. Следующим шагом станет гибридный подход: использование поиска для получения ответов, настройка для стабилизации поведения и долговременная память, позволяющая агенту вспоминать предыдущие взаимодействия вместо того, чтобы начинать каждую сессию с нуля.
Наблюдается очевидный сдвиг от чат-ботов к тому, что некоторые сейчас называют искусственными сотрудниками — системам, которые выполняют постоянную работу в различных инструментах и со временем, вместо того чтобы ждать вопроса. Достижение этой цели мало связано с выбором самой яркой технологии. Оно зависит от понимания того, что каждая составляющая делает хорошо, и от их целенаправленного объединения, начиная с самого простого уровня, который решает проблему.
Вопрос никогда не заключался в выборе между извлечением информации, тонкой настройкой или агентами. Настоящий вопрос заключается в том, какая комбинация необходима конкретной системе и в каком порядке её создавать.
Связанные статьи
- Chroma Context-1: Подагент поиска объемом 20 миллиардов параметров для более дешевого и эффективного использования технологии RAG — Как Chroma Context-1 функционирует в качестве подагента, предназначенного исключительно для поиска, удаляя ненужный контекст, как он обучался, что не хватает без использования данного инструмента и в чем его ограничения.
- Практические заметки: Три уровня технологии RAG в Google Cloud — векторный поиск, двигатель RAG и механизм поиска для агентов — Подробное руководство по практическим заметкам о трех уровнях технологии RAG в Google Cloud: векторный поиск, двигатель RAG и механизм поиска для агентов, включающее контракты, проверки и готовые блоки кода.