Команда AI for Devs подготовила перевод статьи о новом подходе — Agentic RAG. Он превращает извлечение данных в активный процесс: агенты сами решают, где искать, как уточнять запросы и когда остановиться. В результате ИИ становится гибче, точнее и действительно готовым к "боевым" задачам.

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

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

После ряда неудачных попыток я нашёл решение — автономное принятие решений с выборкой через Agentic RAG.

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

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

Agentic RAG воспринимает выборку как активное действие. У агента есть цель, он оценивает найденное и решает, что делать дальше: переформулировать запрос, сменить источник или завершить работу, если контекста достаточно.

В моём случае я применял Agentic RAG от Qodo для агентных сценариев, которые работали с git-репозиториями, файлами, PR и логами терминала. Благодаря Model Context Protocol (MCP) я задавал агенту цель, подход к задаче, fallback-логику и критерии завершения работы.

В этой статье я расскажу, как работает Agentic RAG на практике, чем он отличается от традиционного RAG и как использовать его в Qodo.

Что такое Agentic RAG?

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

Схема ниже показывает, как формируется Agentic RAG:

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

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

Типы архитектур Agentic RAG

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

Single-Agent RAG (маршрутизирующий агент)

Простейший вариант Agentic RAG — один агент, который принимает решения. Такой агент работает как «умный маршрутизатор»: получает вопрос, оценивает, где лучше искать ответ, и выбирает инструмент — векторное хранилище, документную базу или, например, API вроде Slack или поисковика. Важен не сам выбор базы, а то, что агент динамически решает, где именно искать контекст.

Эта модель подходит, если источников немного и достаточно лёгкой координации. Агентичность проявляется в том, что выбор делается во время выполнения, а не задаётся заранее.

Multi-Agent RAG (система специализированных агентов)

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

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

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

Agentic RAG против традиционного RAG

IBM отмечает: «Agentic RAG добавляет в конвейер RAG агентов, что повышает адаптивность и точность», позволяя LLM-моделям работать с несколькими источниками и управлять сложными многошаговыми процессами.

Если сравнивать, стандартный RAG — это разовый поиск по одной базе. Agentic RAG же рассматривает модель как активного агента, который может итеративно уточнять запросы, обращаться к разным инструментам и перепроверять результаты.

Ниже таблица с основными отличиями:

Как работает Agentic Mode в Qodo?

Мы разобрали, что такое Agentic RAG. Теперь посмотрим на Qodo. Режим Agentic Mode позволяет запускать автономных агентов, которые планируют, рассуждают и действуют для достижения цели без жёстких промптов и ручного контроля. Каждый агент настраивается: вы задаёте его цель, доступные инструменты и поведение.

Агенты используют модульные компоненты — MCP-инструменты (Model Context Protocol). С их помощью агент работает с кодовой базой, API, файлами, документацией и вебом. Например: /fetch для загрузки PR, /review для проверки качества кода или /search для поиска в документации.

Связка агентов и MCP даёт настоящую агентность. Вместо единичных промптов Qodo-агенты могут добывать больше контекста, менять план и решать, что делать дальше — как настоящий разработчик.

Чтобы лучше понять работу, начнём с примера. У меня был репозиторий с несколькими сервисами — auth-service, billing-service и notifications-service. Я попросил Qodo добавить новые функции в два из них.

Что касается MCP-интеграций, то в Qodo уже есть встроенные MCP: Git, навигация по коду, файловая система и терминал. Это базовый набор. Если нужно больше — можно подключить через «Add new MCP» или выбрать популярные из готовых.

Интерфейс Qodo Agentic Tools MCP показывает встроенные интеграции для Git, Code Navigation, File System и Terminal с переключателями.

Qodo Gen поддерживает два типа MCP — локальные и удалённые. Локальные MCP запускаются прямо в вашей среде и не требуют сетевых вызовов. Они подходят для логики, не зависящей от внешних API.

Удалённые MCP — рекомендуемый вариант для корпоративных окружений. Они работают на внешних серверах и взаимодействуют с Qodo по HTTP. Чтобы их настроить, нужно указать endpoint URL и, если требуется, добавить HTTP-заголовки, например для авторизации.

Для демонстрации я использую встроенные MCP. С помощью Git MCP я запросил у Qodo последние изменения в моём удалённом репозитории. Agentic RAG от Qodo проверил репозиторий через Git MCP.

Он не просто вывел список коммитов — он проанализировал структуру кодовой базы, набор изменений и при необходимости даже проследил зависимости файлов. Я попросил показать последние изменения, и он выдал все коммит-сообщения по моим сервисам. Вот пример вывода:

Проверка git-репозитория в Qodo: репозиторий переинициализирован, нет несохранённых изменений, список файлов — .git, .qodo, App.tsx, microservice-refactor-agent, README.md.

Когда базовые MCP были настроены и сервисы синхронизированы, я перешёл к более сложной задаче — оркестрации многосервисного рефакторинга с помощью агентного слоя Qodo. Моя цель: сгенерировать коммиты для auth-service и billing-service, сохранив целостность тестов и понятность изменений.

Я отдал Qodo команду:

Сгенерируй рефакторинговые коммиты для сервисов auth-service и billing-service, опиши изменения и проверь, что тесты проходят

Qodo интерпретировал задачу как многошаговую. Сначала он создал тестовый слой для billing-service, написав requirements.txt и test_billing.py. Это обеспечило проверку pytest до коммита.

Вот пример:

Qodo Gen AI создаёт коммиты с Python-скриптами для auth и billing сервисов.

Затем он сгенерировал центральный скрипт refactor_services.py, который динамически загружает и запускает RefactorAgent. Скрипт особенно интересен тем, что импортирует агента из общей директории и определяет метод run_tests(), который через subprocess запускает тесты в нужных сервисах.

После того как я синхронизировал изменения с feature-веткой и создал PR, Qodo автоматически подготовил PR Reviewer Guide с ключевыми замечаниями для разработчиков:

Qodo авто-сгенерировал PR Reviewer Guide с важными наблюдениями.

В него вошли: оценка усилий на ревью (4/5), подтверждение покрытия тестами и раннее выявление уязвимостей — хардкод секретов (SECRET_KEY), использование MD5 и хранение номеров карт в открытом виде. Также Qodo отметил возможные ложные срабатывания в обнаружении «мертвого кода», особенно при использовании динамических импортов.

Qodo также выдал схему описающую агентный пайплайн рефакторинга, показав взаимодействие Demo Script, RefactorAgent и RefactoringEngine.

Схема Qodo с этапами рефакторинга — версионирование API, удаление мёртвого кода, внедрение зависимостей.

Заключение

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

Гибкость и рассуждения, которые дают агентные сценарии, обеспечивают уровень адаптивности, необходимый корпоративным средам. Речь идёт не о том, чтобы «что-то достать», а о том, чтобы понять зачем и как достать, и действовать автономно.

Русскоязычное сообщество про AI в разработке

Друзья! Эту статью перевела команда ТГК «AI for Devs» — канала, где мы рассказываем про AI-ассистентов, плагины для IDE, делимся практическими кейсами и свежими новостями из мира ИИ. Подписывайтесь, чтобы быть в курсе и ничего не упустить!