Зачем вам эта статья? Потому что Classic RAG уже не справляется
Представьте себе конвейер. Документы загружаются, разбиваются на чанки, индексируются. Пользователь задает вопрос — система ищет похожие фрагменты, склеивает их с промптом и отправляет в LLM. Ответ готов. Это Classic RAG. Он работает, пока ваши запросы просты, а данные статичны. Но в 2026 году все изменилось.
Запросы стали сложными: "Сравни требования к безопасности в стандартах X и Y на основе последних обновлений, найди противоречия и предложи план миграции". Classic RAG даст вам выдержки из документов, но не выполнит анализ, не сделает выводов, не предложит план. Он — пайплайн. Тупая труба.
Где Classic RAG ломается? Смотрите сами
Проблема не в том, что Classic RAG плох. Он просто не предназначен для мира, где вопросы требуют рассуждений. Вот типичные сбои:
- Многошаговые запросы: "Найди все инциденты с утечкой данных за 2025 год, выдели основные причины, сопоставь с нашими политиками безопасности и оцени риски для нового филиала в Азии". Classic RAG вернет кучу чанков, но не свяжет их в логическую цепочку.
- Динамический контекст: Данные постоянно меняются. Вчерашний ответ уже неактуален. Classic RAG не умеет проверять актуальность сам — нужно переиндексировать все.
- Неявные знания: Вопросы типа "Почему проект X провалился?" требуют анализа разрозненных документов (отчеты, переписка, метрики). Classic RAG ищет буквальные совпадения, а не причины.
- Ошибки в ответах: Если в релевантных чанках есть противоречивая или устаревшая информация, Classic RAG слепо скормит ее модели. Результат — галлюцинации на основе ваших же данных. Ирония.
Именно эти боли привели к появлению Agentic RAG. Это не "улучшенная версия", а смена парадигмы. От линейного пайплайна — к адаптивному контрольному циклу.
Agentic RAG: когда ИИ сам решает, как искать и думать
Забудьте про "запрос-поиск-ответ". В Agentic RAG появляется новый игрок — агент. Это LLM (например, GPT-5 или Claude 3.7, актуальные на 2026 год), которая управляет процессом. Ей дают не только промпт с контекстом, но и набор инструментов: поиск в векторной БД, запросы к SQL, вызов внешних API, даже выполнение кода. И главное — способность планировать.
Агент работает по циклу ReAct (Reasoning + Acting):
- Думает: "Чтобы ответить на этот вопрос, мне нужно сначала найти последнюю версию стандарта Y, потом сравнить пункт 4.2 с нашим внутренним регламентом..."
- Действует: Вызывает инструмент поиска по векторной БД с конкретным запросом.
- Наблюдает: Получает результаты. Если их недостаточно или они противоречивы — возвращается к шагу 1, формулирует новый запрос, возможно, использует другой инструмент (например, полнотекстовый поиск).
- Повторяет цикл, пока не соберет достаточно данных для полного ответа.
| Аспект | Classic RAG (Пайплайн) | Agentic RAG (Контрольный цикл) |
|---|---|---|
| Архитектура | Линейная цепочка: индексирование -> поиск -> генерация | Циклическая: Агент планирует, действует, наблюдает, повторяет |
| Гибкость | Нулевая. Один путь для всех запросов. | Высокая. Маршрут зависит от рассуждений агента. |
| Сложные запросы | Часто проваливает. Выдает несвязные фрагменты. | Специализируется на них. Разбивает на подзадачи. |
| Затраты (токены/Latency) | Предсказуемы и обычно ниже. | Непредсказуемы. Может быть в 3-5 раз выше из-за циклов. |
| Отладка | Относительно проста: смотри входы/выходы каждого шага. | Сложна. Нужно анализировать цепочки рассуждений и решения агента. |
Кому и когда переходить на Agentic RAG? Четкие критерии
Не бегите менять работающую систему. Agentic RAG — не серебряная пуля. Вот когда он оправдан:
- Вы строите экспертные системы: Для юристов, аналитиков, исследователей, где запросы — это мини-расследования. Как в этом примере с агентом для объяснения настольных игр.
- Ваши данные живые и разнородные: Не только документы, но и API, базы данных, графики знаний. Агент умеет работать со всем этим.
- Точность критична: Агент может проверять источники, перепроверять ответы, уменьшая галлюцинации. Особенно важно в эпоху атак на RAG-системы.
- У вас есть ресурсы: Для содержания более мощных LLM (агентов) и обработки длинных цепочек.
Classic RAG остаётся королём для: FAQ-ботов, поиска по документации, простых Q&A систем. Не усложняйте без нужды.
1 Шаг 1: Диагностика боли. Что не так с вашим Classic RAG?
Не переходите на Agentic RAG, потому что это модно. Сядьте и проанализируйте логи. Какие запросы получают низкие оценки удовлетворенности? Где пользователи переформулируют вопрос по 5 раз? Соберите эти кейсы. Они станут тестами для вашего агента.
Частая ошибка: пытаться сделать агента, который обрабатывает ВСЕ запросы. Начните с четко очерченной ниши сложных запросов. Остальное пусть делает старый добрый Classic RAG.
2 Шаг 2: Выбор "мозга" — какой LLM будет агентом?
На 2026 год выбор огромен: OpenAI GPT-5 (если она уже вышла), Anthropic Claude 3.7, открытые модели вроде DeepSeek-R1 или Qwen2.5-Max. Критерий не размер, а способность следовать инструкциям и рассуждать. Для начала используйте ту же модель, что и в генераторе Classic RAG. Но готовьтесь к росту затрат: агент делает много запросов "про себя".
3 Шаг 3: Спроектируйте набор инструментов (Tools)
Это сердце системы. Какие инструменты нужны агенту для решения ваших кейсов?
- Векторный поиск: Базовый инструмент для поиска по чанкам.
- Полнотекстовый поиск (Elasticsearch): Для точного соответствия терминам.
- Запрос к SQL-БД: Чтобы доставать структурированные данные.
- Калькулятор или код-интерпретатор: Для вычислений.
- Веб-поиск (через API): Для актуальной информации, которой нет в вашей базе.
Не давайте агенту все сразу. Начните с 2-3 самых необходимых. Каждый инструмент должен иметь четкое описание для агента: что делает, какие параметры принимает.
4 Шаг 4: Сборка контрольного цикла с фреймворком
Не пишите велосипед. Используйте фреймворки, которые уже решают эту задачу. В 2026 году это LangChain (уже версия 0.3.x+ с полной поддержкой агентов), LlamaIndex (с его агентными workflow), или более легкие варианты вроде тех, что описаны в гайде по сборке агента без тяжелых библиотек.
Суть: вы определяете агента (LLM + промпт-инструкции), даете ему список инструментов, запускаете цикл с максимальным числом шагов (чтобы избежать бесконечных петель).
5 Шаг 5: Тестирование, отладка и кровавые сопли
Самая сложная часть. Агент будет принимать странные решения: искать не то, делать лишние шаги, зацикливаться. Вам нужен механизм логирования ВСЕГО цикла: мысли агента, вызовы инструментов, результаты. Без этого вы в слепую.
Собирайте трассы (traces) для каждого запроса. Анализируйте, где агент ошибся, и корректируйте:
- Инструкции агента: Делайте их конкретнее. "Ты эксперт по безопасности. Сначала всегда ищи официальные стандарты, потом внутренние документы".
- Описания инструментов: Уточняйте, когда какой инструмент использовать.
- Стоп-сигналы: Ограничивайте число шагов. 10-15 обычно достаточно.
Помните, отладка агента — это не исправление бага в коде, это тонкая настройка поведения. Будьте готовы к итерациям.
Чего никто не говорит: подводные камни Agentic RAG
- Стоимость взлетает: Каждый шаг цикла — это запрос к LLM. Один сложный запрос может стоить как 20 простых в Classic RAG. Мониторьте usage как ястреб.
- Latency — враг: Пользователь не будет ждать 30 секунд, пока агент делает 10 шагов рассуждения. Кэшируйте результаты, ставьте агрессивные таймауты, используйте более быстрые модели для простых шагов.
- Сложность мониторинга: Метрики Classic RAG (precision, recall) не работают. Нужны новые: успешность завершения цикла, среднее число шагов, удовлетворенность ответом на сложные запросы.
- Безопасность: Агент с доступом к инструментам — это новый вектор атаки. Он может выполнить вредоносный запрос к БД, если промпт пользователя будет сконструирован специально. Об этом подробнее в обзоре угроз 2026 года.
Вопросы, которые вы хотели задать, но стеснялись
Можно ли сделать гибридную систему?
Конечно. И это часто лучший путь. Маршрутизатор (еще одна LLM) анализирует входящий запрос: если он простой — отправляет в Classic RAG пайплайн. Если сложный — агенту. Так вы экономите ресурсы и сохраняете скорость для простых случаев. Пример гибридного подхода в проекте Ragex.
Насколько Agentic RAG зависит от качества данных?
Еще сильнее, чем Classic RAG. Если в вашей векторной БД хлам, агент будет настойчиво искать в этом хламе, тратя шаги и токены. Качественное индексирование и очистка данных — фундамент для любой RAG-системы. Обновления на 2026 год включают умное chunking и семантическое индексирование, что помогает.
Стоит ли ждать, когда появятся готовые решения?
Они уже есть, но кастомная настройка под ваши данные и инструменты все равно потребуется. Платформы вроде LangSmith, Weights & Biases предлагают инструменты для оркестрации и наблюдения за агентами. Но magic button "Сделать мне Agentic RAG" не появится. Работать придется.
Переход от пайплайна к контрольному циклу — это не просто апгрейд. Это смена мышления. Вы перестаете быть строителем труб и становитесь тренером для цифрового сотрудника. Сложнее? Да. Дороже? Пока да. Но для задач, где Classic RAG безнадежно тупит, другого пути нет.
Начните с малого. Возьмите один болезненный тип запросов, соберите прототип на основе локального гайда, чтобы не платить за API, и испытайте эту магию самостоятельного мышления ИИ. После этого вы уже не сможете смотреть на статичный пайплайн прежними глазами.
