Берете пользовательский запрос, прогоняете через эмбеддинги, считаете косинусное расстояние в векторной базе, выдергиваете топ-5 кусков текста, запихиваете все это великолепие в контекст и ждете чуда. Поздравляю, вы построили классический пассивный пайплайн. Он сломается ровно на первом реальном пользователе, который задаст вопрос чуть сложнее, чем пересказ заголовка документации. Большинство инженеров катят это в прод, а потом искренне не понимают, почему бизнес в ярости от галлюцинаций. Реальность такова, что тема «Агентный RAG: как заставить ассистента переспрашивать, перепроверять и не выдавать мусор» — это не академический изыск, а суровая необходимость для выживания корпоративной вопросно-ответной системы.
Пассивный поиск мертв, да здравствует агентный
В пассивном подходе система исходит из двух безумных предпосылок: пользователь точно знает, как сформулировать свой вопрос, а семантическая близость векторов идеально отражает фактологическую суть бизнес-логики. Вы едите то, что нашли. Если юзер спрашивает про падение выручки в третьем квартале, а векторная база подсовывает кусок про квартальную премию и выручку от продажи старых стульев, LLM уверенно сгенерирует аналитический бред.
Агентный RAG ломает эту трубу. Здесь модель — больше не генератор текста в самом конце конвейера. Она становится оркестратором процесса.
Цикл Reflect-Retrieve-Verify и суровая цена интеллекта
Правильно спроектированный агентный пайплайн начинается с сомнения. Получив запрос, система не бежит слепо в базу. Она инициирует фазу reflect — рефлексии. Модель анализирует интент и декомпозирует сложный вопрос на несколько простых. Иногда она понимает, что запрос вообще лишен смысла, и просит пользователя уточнить параметры. Только после этого начинается retrieve — поиск данных. Но магия случается не здесь, а на этапе verify.
Верификация — это ребро, на котором ломаются 90 процентов пет-проектов. Модель обязана прочитать извлеченные куски текста и жестко ответить на один вопрос: достаточно ли здесь контекста для формирования ответа? Если контекст — мусор, агент не имеет права генерировать ответ. Он должен либо переформулировать поисковый запрос и сделать новый заход в базу, либо честно признать свое невежество. Ловить недостаточный контекст и бить модель по рукам за попытки выдумать факты — ваша главная задача при построении eval-контура. И здесь мы упираемся в то, о чем предпочитают молчать на хайповых конференциях.
За интеллект приходится платить железом и временем.
В пассивной схеме вы делали один вызов тяжелой модели. В агентном RAG вы делаете их три, пять, а иногда и десять. Подумать. Разбить запрос. Найти. Оценить найденное. Снова найти. Снова оценить. Сформировать ответ. Ваш p99 latency улетает с комфортной полутора секунд в стратосферу десяти-двенадцати секунд. Ваш счет за API или утилизация локальных GPU умножается кратно.
Видели когда-нибудь, как агент зацикливается, пытаясь найти в пустой базе документ, которого там отродясь не было? Я видел. Отличный способ сжечь месячный бюджет на инференс за одни выходные на зависшем тест-раннере.
Чтобы система не пошла по миру, внедряется жесткий лимит итераций. Три попытки поиска. Не нашел — отдаешь управление пользователю с просьбой уточнить. Никаких бесконечных циклов рассуждений. Но даже этого недостаточно для балансировки нагрузки, и здесь на сцену выходит Adaptive RAG.
Адаптивный RAG — это роутер сложности. Глупо гонять запрос «как сбросить пароль» через весь тяжелый агентный цикл с многократной верификацией фактов. На входе ставится дешевый классификатор, который работает как сортировочная станция. Простые FAQ-запросы улетают в быстрый пассивный поиск или к легкой модели. Сложные аналитические задачи, требующие сопоставления фактов из разных источников, маршрутизируются в полноценный агентный контур. Вы сознательно идете на трейд-офф: лечите точность в сложных кейсах, жертвуя скоростью, но не стреляете из пушки по воробьям на базовых вопросах.
LLM-RAG on-premise: как мы решаем это на железе
Когда вы работаете с промышленными предприятиями, никакие данные не покидают периметр. У нас в Morana Labs мы строим такие агентные системы исключительно on-premise. На локальных серверах критически важно выжимать максимум из железа, поэтому роль роутера сложности у нас обычно выполняет крошечная дообученная модель, работающая с нулевой задержкой. Она бережет вычислительные квоты для тяжелой локальной LLM, которая отвечает за verify-цикл. Проектирование такого пайплайна сразу идет в связке с автоматическим eval-контуром: мы не ждем жалоб пользователей, а измеряем метрики качества ретривала и галлюцинаций прямо в CI/CD на синтетических датасетах, постоянно проверяя, насколько точно агент оценивает собственную слепоту.