Bedrock Knowledge Base научили выбирать глубину поиска: от 0 вызовов LLM до агентного RAG

Утром сотрудник банка спрашивает внутреннего ИИ-ассистента, какие документы нужны для открытия счёта ИП. Ответ лежит в одном чек-листе. Днём он же спрашивает, чем отличаются требования для ИП, ООО и партнёрств с несколькими владельцами. Ответ размазан по нескольким регламентам. Ассистент один, а вопросы очень разные по сложности и по цене. Если на оба вопроса запускать тяжёлый агентный цикл, вы переплатите и потеряете в задержке. Если на оба делать один поиск, на сложном вопросе потеряете в точности.

AWS закрывает этот зазор в Amazon Bedrock Managed Knowledge Base. Раньше через AgenticRetrieveStream был доступен только агентный режим, теперь добавились ещё два.

Один параметр вместо двух API

Всё управляется через maxAgentIteration. Диапазон теперь 0–5, и от значения зависит поведение запроса.

0 — только поиск. Сервис делает один гарантированный поиск и ничего не генерирует. Вызовов foundation model нет, по сути это аналог обычного Retrieve API. Режим удобен тем, кто уже перешёл на AgenticRetrieveStream и не хочет переключаться на другой API ради запроса без генерации. Если при нуле выставить generateResponse=true, вернётся ошибка 4xx: для ответа нужна LLM.

1 — классический RAG. Один поиск, один вызов модели для ответа, никакого планирования и переписывания запроса. Пример из статьи: «Какие документы нужны для открытия бизнес-счёта ИП?». Чек-лист в базе есть, планировщик здесь только добавит задержку. Если большая часть трафика состоит из прямых и чётко очерченных вопросов, AWS намекает, что это ваш дефолт.

2–5 — агентный режим. Модель разбивает вопрос на подзапросы, ищет по каждому, оценивает, хватает ли найденного, и при необходимости уточняет поиск или подтягивает документ целиком. Значения 2–5 работают как раньше, существующие запросы не поломаются.

Как считаются итерации

Правило простое: одна итерация равна одному вызову foundation model. Последняя итерация всегда уходит на генерацию ответа. Поэтому значение n даёт до n−1 раундов планирования, а каждый раунд — это переписывание запроса плюс поиск.

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

Отдельно AWS подчёркивает, что одиночный поиск не значит одну базу знаний. Все три режима, включая 0 и 1, работают с несколькими базами. Агентный режим добавляет декомпозицию вопроса, оценку найденных свидетельств и итеративный поиск, а мультибазность от него не зависит.

На примере банка это выглядит так. Для вопроса про чек-лист ИП ставим maxAgentIteration=1 и generateResponse=true. Для сравнения ИП и ООО с проверками нерезидентов ставим 4, то есть до трёх раундов планирования. Когда сотруднику нужен сам текст регламента, а не пересказ, ставим 0 и generateResponse=false, и приложение показывает пассажи со ссылками на источники. Переключение из агентного вызова в обычный RAG — правка одного числа в JSON.

Ограничения и что делать на практике

Главное: выбор режима остаётся на стороне вашего приложения. Автоматической маршрутизации по сложности вопроса здесь нет. Нужен либо простой роутер (по типу сценария, по эвристике, по маленькому классификатору), либо жёсткое закрепление режима за конкретным экраном или фичей.

Второе: формат ответа в режиме 0 отличается от прямого Retrieve. Дедуплицированные пассажи приходят в result-событии стрима без полей score и location. Если ваш интерфейс опирается на оценку релевантности или точную локацию фрагмента, проверьте это до миграции.

Третье: примеры с банком в статье иллюстративные. Замеров задержки, стоимости или качества AWS не приводит. Заявление, что single-shot снижает латентность и расход модели по сравнению с агентным режимом, логично, но цифр под ним нет. Не принимайте его на веру.

Практический план такой:

• Соберите набор реальных вопросов с эталонными ответами из ваших документов.
• Прогоните его через режим 1 и через текущую агентную конфигурацию на одной и той же базе знаний.
• Замерьте задержку и стоимость запроса и проверьте, что ответы верны и подтверждены найденными пассажами.
• Обязательно включите вопросы, на которые нужно собирать ответ из нескольких документов. Именно на них одиночный поиск обычно проседает.

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