AWS介绍Bedrock知识库智能检索：把多意图问题拆成子查询并迭代搜索
AWS机器学习博客发布技术文章，说明Amazon Bedrock Managed Knowledge Base新增的AgenticRetrieveStream API如何对多部分问题做检索规划，并与单次混合检索的Retrieve API对比。
AI解读：文章要回答的具体问题是：当用户一个提问里同时包含多个比较维度时，单次相似度检索为什么只能答出一部分。作者用“比较两个产品、三个维度”等于同时提出六个子问题的例子说明，单次检索只用一个查询向量近似所有意图的平均值，返回的片段虽然主题相关，但只覆盖问题的一部分。
按文章中描述的适用范围，把问题拆解、多次检索、判断证据是否足够再补检索的智能检索，适用于多部分、比较类、探索类问题，或证据分散在多个知识库的情况；单次、范围明确的短问题仍建议走Retrieve这条更便宜、更快的路径。
文章给出的限制包括：智能检索每次调用成本更高、会触发多次模型调用、延迟高于单次检索；注册知识库最多 5 个，子查询按每个知识库的自然语言描述路由；在langchain-aws中它是函数式检索而非标准LangChain retriever，嵌入链中需要RunnableLambda包装，读取计划轨迹需要直接调用boto3。
权限方面，文章提醒bedrock:AgenticRetrieveStream和bedrock:InvokeModelWithResponseStream无法限定到某个知识库ARN，而bedrock:Retrieve和bedrock:GetDocumentContent可以；当FullDocumentExpansion步骤认为片段缺少上下文时会调用GetDocumentContent，只授Retrieve的权限会在查询中途失败。
该文章建议按查询形态路由，用分类器或启发式把大部分流量导向低成本路径，只在需要时使用规划器，并称下一步应先在自有查询分布上测量。Agentic检索何时可用、除us-east-1以外的区域支持情况，需查看AWS文档。
AWS机器学习博客发布了一篇由Manideep Reddy Gillela撰写的技术文章，介绍如何在Amazon Bedrock Managed Knowledge Base上结合LangChain构建RAG应用，并演示单次检索与智能检索（agentic retrieval）处理同一个多部分问题的差异。文章称智能检索已在Amazon Bedrock Managed Knowledge Base上可用。
文章用一个客服助手的例子说明动机：当用户要求比较两个产品、覆盖三个维度时，实际等于同时提出六个问题；相似度搜索只用一个查询向量概括全部意图，检索器返回的是这些意图平均值的近似，因此返回片段虽然主题相关，却只覆盖了问题的一部分。
文章把两条检索路径对应到两个API：Retrieve API执行一次混合搜索并返回带分数的片段，在langchain-aws包中是可放入链的标准LangChain retriever；AgenticRetrieveStream API执行规划循环，把问题拆成子查询，运行后判断证据是否充分，不足则再次搜索，并以trace事件流式返回步骤。
智能检索的规划循环与多知识库路由
文章描述，AgenticRetrieveStream不只是发起一次搜索，而是先规划：拆分子查询、执行、判断证据是否足够，不够再搜索。langchain-aws同时暴露智能检索和标准检索两种方式，LangChain应用可以任选其一。
在一次请求中，智能检索最多可注册 5 个知识库，并按照为每个知识库附加的自然语言描述来路由子查询。文章称这一点是单次检索API完全做不到的。
在LangChain集成方式上，文章指出智能检索是一个函数，而不是LangChain retriever，因此要放进链中需要RunnableLambda包装；如果还需要查看查询计划的trace事件，则必须直接调用boto3。
- 规划循环：拆分问题、执行子查询、判断证据是否充分、必要时再检索
- AgenticRetrieveStream以trace事件流式返回规划步骤
- 一次请求最多注册 5 个知识库，按自然语言描述路由子查询
- 在langchain-aws中需RunnableLambda包装才能入链，查看trace需直接调用boto3
成本、延迟与两条路径的适用条件
文章给出的取舍是：短小、范围明确的问题用Retrieve，它更便宜、更快、可用于自管理知识库，并在结果中返回分数；文章称大多数生产流量属于这一类。多部分、比较类或探索类问题，或证据跨越多个知识库时，用AgenticRetrieveStream。
智能检索每次调用成本更高，会进行多次模型调用，延迟也是两者中更高的。文章建议按查询形态路由，用分类器或启发式把多数流量导向低成本路径，把规划器留给真正需要的问题，并称先在自有查询分布上做测量是下一步有用动作。
- Retrieve：单次混合搜索，返回带分数的片段，更便宜、更快，可用于自管理知识库
- AgenticRetrieveStream：多步规划，单次调用成本更高、模型调用更多、延迟更高
- 多知识库注册与子查询路由只有智能检索支持
- 文章建议按查询形态路由，而非全部流量走规划器
前置条件与权限配置
文章列出的运行前提包括：一个可访问Amazon Bedrock且智能检索已可用的区域的AWS账户，示例使用美国东部（弗吉尼亚北部）us-east-1；Python 3.12或更高版本；一个存放样例文档的S3桶，语料需有多个主题重叠的文档，因为单一扁平文档无法展示查询规划。安装包要求为langchain-aws>=1.6.3、langchain>=1.0、boto3>=1.43.32，文章特别指出agentic_retrieve_stream在boto3 1.43.32之前不存在。
权限涉及两个身份：知识库代入的服务角色，以及调用API的身份。文章称服务角色需要s3:ListBucket和s3:GetObject并以aws:ResourceAccount为条件，创建后应把knowledge-base/* 通配收窄到具体知识库ID；AWS STS调用身份需要bedrock:AgenticRetrieveStream和bedrock:InvokeModelWithResponseStream，这两项无法限定到某个知识库ARN。
文章专门提醒bedrock:GetDocumentContent常被忽略：当FullDocumentExpansion步骤判断某段文字缺少回答所需上下文时，智能检索会调用它；只授予bedrock:Retrieve的策略会一直工作到规划器取整篇文档时出现查询中途失败。若使用guardrails，还需加入bedrock:GetGuardrail和bedrock:ApplyGuardrail。
- 示例区域为us-east-1，文章提示其他区域支持情况查看AWS文档
- boto3>=1.43.32，因为此前没有agentic_retrieve_stream
- bedrock:AgenticRetrieveStream与InvokeModelWithResponseStream无法限定到知识库ARN
- FullDocumentExpansion需要bedrock:GetDocumentContent，只授Retrieve会中途失败
创建知识库与成本提示
文章演示用managedKnowledgeBaseConfiguration创建知识库，把embeddingModelType设为MANAGED以使用服务托管嵌入模型。与自管理知识库不同，该请求没有storageConfiguration，文章称这是API中最明确的信号，表明Amazon Bedrock掌管存储层。
创建后把S3桶挂为数据源并启动摄取任务。文章提醒摄取是异步的，应轮询直到任务到达终止状态，而不是固定睡眠一段时间；示例代码设置了 1800 秒超时并区分完成与失败、停止状态。
在生成环节，文章指出AgenticRetrieveStream的generate_response在示例中关闭：服务本身可以生成答案，但在链中通常想用自己的提示和模型，于是只取片段在下游生成；想要一次调用、更少代码时用服务生成，想掌控提示时用包装版本。
文章提醒运行该实验可能产生文档存储与摄取、检索调用、基础模型推理的费用，完成实验后应删除知识库、数据源、S3对象与桶以及创建的IAM角色，因为存有文档的知识库会继续产生存储费用。
- managedKnowledgeBaseConfiguration不需要storageConfiguration
- 摄取为异步任务，需轮询至终态
- 服务可自行生成答案，链中示例关闭generate_response以自控提示
- 实验结束需清理知识库、数据源、S3资源和IAM角色
文章自述的集成摩擦
在结论部分，文章总结了两处当前的集成摩擦：智能检索是函数而非LangChain retriever，需要RunnableLambda才能放进链；展示查询计划的trace事件需要直接调用boto3。
文章称智能检索以更高的单次调用成本换取多跳问题上更好的召回，查询规划使用内置模型；并建议在把全部流量交给规划器之前，先测量自己的查询组合。
- 函数式检索需RunnableLambda入链
- trace事件需直接boto3调用
- 文章主张先用自有查询分布测量再决定是否全量路由