">

Amazon Bedrock 网页搜索支持域名过滤与用户位置控制

AWS 于 2026 年 10 月 23 日宣布,Amazon Bedrock 的 Web Search 新增域名过滤与用户位置两项控制,均可在现有 OpenAI Responses API 请求的网页搜索工具上直接配置,允许的域名与屏蔽的域名各最多写 100 条。

这次发布的是什么

AWS 于 2026 年 10 月 23 日在官方 What's New 渠道宣布,Amazon Bedrock 的 Web Search(网页搜索)能力新增两项控制:域名过滤(domain filtering)与用户位置(user location)。前者用来限定参与检索的站点名单,后者用来告诉搜索「用户在哪」。

两项都不是新接口,也不需要改动应用架构 —— AWS 的说明是直接在现有 OpenAI Responses API 请求中的网页搜索工具上配置参数即可。对做检索增强问答的团队来说,这意味着「模型拿哪些网页来回答」这件事终于有了官方层面的开关。

可用性与限制

  • 形态:2026 年 10 月 23 日起可用。
  • 前提条件:必须使用 Amazon Bedrock 的 Web Search,并以 OpenAI Responses API 的方式发起请求。
  • 区域:官方列出的可用区域为美国东部(弗吉尼亚北部)、美国东部(俄亥俄)、美国西部(俄勒冈)与 AWS GovCloud(US-West),即「网页搜索已支持的全部区域」;其他区域的可用性以 AWS 官网为准。
  • 数量上限:允许域名清单与屏蔽域名清单各自最多 100 条。
  • 计费:网页搜索本身的计价方式以 Bedrock 定价页为准,本次更新不改变已有计费结构。
  • 生效范围:只作用于检索阶段,不等于事实校验环节。

主要功能

  • 用允许域名清单把检索结果限定在指定站点集合内
  • 用屏蔽域名清单排除不希望被引用来源
  • 用位置参数指定用户地理信息,让结果贴合目标地区
  • 在同一条请求里随场景切换过滤规则,不必改造应用
  • 与已有的网页搜索工具调用方式保持兼容

技术原理

据 AWS 说明,Web Search 在 Bedrock 中以工具的形式存在:请求里声明网页搜索工具后,服务端完成检索,再把命中的内容作为回答依据交给模型。因为「哪些页面进入结果集」会直接影响最终答案,所以把过滤放在工具层是最省事的做法 —— 应用层既不用自己包一层检索服务,也不必在提示词里反复叮嘱「只引用某某站点」。

需要注意边界:这是检索前置规模化过滤,不是答案层面的真实性保证。模型仍可能对命中的内容做出错误归纳,涉及事实性结论时还应保留引用出处与人工复核环节。

实际体验

本文未做实测,以下是文档层面可以核对的几点:改动是向后兼容的,不传这两个参数时行为与之前一致,因此现有请求不会因为这次更新而报错;允许与屏蔽清单各有 100 条上限,站点数量更多的场景需要在应用侧自行合并或分批请求;位置参数为非必填,只有在涉及区域可用性、当地服务网点这类与地理位置强相关的问题时,差别才会明显。

至于命中率、延迟与成本是否会因为加了过滤而变化,官方没有给出可比对的数值,需要用各自的查询集做回归后再判断。

项目地址与获取方式

  • 官方公告:https://aws.amazon.com/about-aws/whats-new/2026/10/bedrock-web-search-domain-user-location/
  • 用户指南(网页搜索章节):https://docs.aws.amazon.com/bedrock/latest/userguide/web-search.html
  • 定价:https://aws.amazon.com/bedrock/pricing/
  • 请通过 AWS 官方控制台开通,避免经由非官方中间层转接。

适合谁用

  • 做检索增强问答、且对引用来源有硬性要求的场景:金融、法务、医疗、企业内部知识库等。
  • 需要明确把某些站点排除出结果集的团队,比如不希望答案引用聚合站或二手转述。
  • 面向多个国家或地区提供本地化答案的产品:位置参数可以让回答更贴合当地情况。
  • 不必急着用:调用量很小、本来就有自建检索链路的团队,以及业务需要落在本次未列出的区域的用户 —— 后者要先确认区域可用性。

常见问题

最多能写多少条域名?

官方说明是允许域名清单与屏蔽域名清单各上限 100 条。超出了需要在应用层自己先做一轮合并或拆分请求,接口不会帮忙去重。

不填位置参数会怎样?

网页搜索照常工作,只是结果不再针对特定地区做适配。若业务本身不涉及地域差异,可以保持不填。

域名过滤能保证答案准确吗?

不能。它限定的是「允许哪些来源进入检索」,解决的是来源可控的问题;最终答案是否准确,仍然取决于命中的内容与模型的归纳能力,重要结论建议保留出处并人工核对。

现有的请求需要改写吗?

不需要。两个新参数都挂在网页搜索工具上,不传即为原有行为,已有代码可以照常运行,按需逐步灰度打开即可。

相关工具与内容

Related
快讯 6 小时前

MCP 官方参考服务器 2.1.0:修复 8 个安全漏洞

Model Context Protocol 官方参考服务器仓库于 2026 年 10 月 25 日发布 v2.1.0,一次修掉分布在 filesystem、everything、fetch 三个参考服务器里的八个漏洞,并给出每个包的受影响版本区间与修复版本;其中文件系统服务器的写入重定向问题在 Windows 上仍只是部分修复。

前沿快讯 18 阅读
快讯 6 小时前

Open WebUI 0.12.4:技能按需加载与上下文压缩

自托管大模型前端 Open WebUI 于 2026 年 10 月 25 日发布 0.12.4:技能支持按需加载、上下文压缩在聊天里可见且覆盖到更多场景,管理员可按角色隐藏界面控件并自动隐藏不可用的选项;同时改了三项默认行为,其中 Direct Integrations 默认关闭会让已保存的连接停止生效。

前沿快讯 14 阅读
快讯 6 小时前

Pydantic AI 2.61.0:引用结构化与新模型名入库

Python 智能体框架 Pydantic AI 于 2026 年 10 月 24 日发布 2.61.0:把引用做成结构化数据并统一多个云厂商的返回格式、能按原始产出方回放引用,新增 kimi-k3.1-pro 与 kimi-k3.1-pro-highspeed 两个模型名,同时把持久化引擎的扩展接口转为公开,并收紧了输入护栏的默认行为。

前沿快讯 20 阅读

继续阅读:GitHub Copilot 用量指标开始显示自建 skill、Agent 与 MCP 服务器的名称 · NVIDIA 推出 Minerva:面向 AI 工厂的可观测性运维平台

关于本文:本站文章由编辑部独立撰写,评测口径与免责说明见关于我们。想继续找工具,可从分类导航按场景浏览,或回首页搜索。

链接已复制