«Один вектор не представит шесть намерений»: AWS показала агентный поиск в Amazon Bedrock Knowledge Bases вместе с LangChain

Многозвенный вопрос против одного вектора

5 октября 2026 года AWS опубликовала в блоге Machine Learning Blog материал Манидипа Редди Гиллелы, Луиса Фелипе Флореса Леано, Сушмы Сунколлу Нагарадж и Сатьи Паттанаика о том, как в LangChain-приложении устроен агентный поиск поверх Amazon Bedrock Managed Knowledge Base.

Отправная точка — сценарий поддержки: пользователь просит сравнить два продукта по трём измерениям, а это фактически шесть вопросов одновременно. Similarity search кодирует все намерения одним вектором запроса, и ретривер возвращает лучшую аппроксимацию среднего по этим намерениям.

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

Два API одной базы знаний

Amazon Bedrock Managed Knowledge Base — полностью управляемая возможность RAG в Amazon Bedrock: она убирает из архитектуры самостоятельно управляемое векторное хранилище, эмбеддинги и модели реранжирования. По документации AWS у Knowledge Bases два типа: Managed Knowledge Base, где Amazon Bedrock сам ведёт приём данных, индексирование, хранение и поиск и где по умолчанию используются служебные модели, и Customer-managed Knowledge Base, где векторное хранилище и весь конвейер настраивает и обслуживает пользователь.

Прикладной интерфейс у Managed Knowledge Base двойной. API Retrieve выполняет один гибридный поиск и возвращает фрагменты с оценками, а API AgenticRetrieveStream запускает планирующий цикл и стримит его шаги обратно в виде событий трассировки.

Пакет langchain-aws повторяет это деление: первый API — обычный LangChain-ретривер, который можно встроить в цепочку, второй — функция извлечения прямо из базы знаний. Отдельного флага, включающего агентный режим в AmazonKnowledgeBasesRetriever, не существует.

Где одиночный поиск перестаёт хватать

Чтобы измерить потерю, AWS прогнала один и тот же многозвенный запрос про сравнение сервисов checkout и inventory по трём измерениям — эскалация дежурств, цели резервного копирования и восстановления, процедура отката развёртывания — с разным числом результатов.

При numberOfResults, равном пяти, вернулось пять фрагментов, это 10 % корпуса, и они закрыли 4 из 6 поднамерений: не хватило дежурств checkout и восстановления inventory. При десяти результатах нашлось уже 6 из 6 поднамерений, но с видимым перерасходом: два поднамерения покрыты дважды, а один фрагмент не несёт ничего.

Вывод AWS структурный: один вектор не может представить шесть намерений, и ни на одном шаге процесс не спрашивает, достаточно ли найденных доказательств, чтобы ответить.

Планирующий цикл и его трассы

Агентный поиск — не ретривер LangChain, а возможность самой Amazon Bedrock Managed Knowledge Base: сервис разбивает вопрос на подзапросы, выполняет их, оценивает, хватает ли доказательств, и при нехватке ищет снова.

Разложение видно только на прямом вызове agentic_retrieve_stream у клиента bedrock-agent-runtime: вспомогательная функция agentic_retrieve отбрасывает события трассировки и не даёт ни maxAgentIteration, ни собственной модели-планировщика.

Шаг события показывает положение планировщика. SpeculativeRetrieval выполняется до первого плана, чтобы срезать задержку, и не расходует бюджет итераций; Planning читает вопрос и предыдущие результаты и порождает подзапросы; Retrieval срабатывает по разу на подзапрос; FullDocumentExpansion появляется, когда модель решает, что отрывку не хватает контекста, и вытягивает документ целиком.

У каждого шага есть статус IN_PROGRESS, SUCCEEDED или FAILED и человекочитаемое сообщение, а итоговые фрагменты приходят отдельным событием result — это не пятый шаг, а собственный тип, и в нём лежат дедуплицированные фрагменты всех итераций вместе с обоснованным ответом, если генерация включена. Текст подзапроса стоит в attributes.actions[].retrieve.inputQuery.text, а не в верхнеуровневых полях трассы, поэтому обработчик, читающий только step и status, увидит, что планирование было, но не увидит, что именно решили.

Две тонкости, о которых стоит знать заранее

Первая — дедупликация касается только события result: фрагмент, найденный тремя подзапросами, в конце появится один раз, но в трассах — трижды.

Вторая — про оценки: ответ Retrieve даёт каждому фрагменту типизированное поле score с релевантностью к запросу, а результаты агентного поиска несут content, metadata и sourceRetriever без эквивалентного типизированного поля, так что код, читающий result["score"] после смены API, не получит ничего.

Цена, параметры и guardrails

Параметр maxAgentIteration принимает значения от двух до десяти и по умолчанию равен пяти, и AWS советует оставить его на значении по умолчанию. При двух-трёх планировщик проводит один цикл, не порождает подзапросов и возвращает то, что уже нашёл спекулятивный поиск, — это одиночное поведение по агентной цене; разложение начинается с четырёх, а потолок остаётся границей, а не целью, потому что планировщик часто останавливается раньше, признав доказательства достаточными.

В качестве внешнего ориентира AWS привела оценку агентного поиска на публичном бенчмарке многопереходных вопросов MuSiQue: рост полноты по сравнению с одиночным поиском оказался наибольшим на самых трудных вопросах, а на однопереходных вопросы выигрыш не превысил пяти пунктов.

Для продакшена AWS советует Amazon Bedrock Guardrails: агентный поиск поддерживает их через policyConfiguration.bedrockGuardrailConfiguration, а не через аргумент guardrail_config, который принимает ретривер LangChain, и только в режиме BLOCK — если полагаетесь на режим MASK, это довод остаться на API Retrieve.

Что выбрать и как это уложить в цепочку

Рекомендация AWS — маршрутизировать по форме запроса, а не выбирать один путь для всего. Retrieve подходит для коротких, хорошо очерченных вопросов: он дешевле, быстрее, работает и с самостоятельно управляемыми базами знаний и возвращает оценки в результатах, а именно так выглядит большая часть продакшен-трафика.

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

В цепочке LangChain стандартный ретривер собирается обычным LCEL-выражением, а агентный поиск, будучи функцией, заворачивается в RunnableLambda. Из наблюдений по ходу сборки AWS отдельно отметила функцию format_docs: если передавать в промпт объекты Document напрямую, отрисуется их repr и метаданные перемешаются с контекстом.

После эксперимента AWS советует удалить базу знаний, её источник данных, объекты и бакет S3 и созданную роль IAM — база с загруженными документами продолжает начислять плату за хранение.