Agentic AI 维基
AI 博客 / Bedrock Knowledge Bases、Vertex AI Search、Azure AI Search 与 Vectara 对比
AI 博客

Bedrock Knowledge Bases、Vertex AI Search、Azure AI Search 与 Vectara 对比

你从一套托管知识库买到的不是检索质量——你买的是那个把 SharePoint 的权限连同文件一起搬过来的连接器，以及那条按用户强制执行权限的查询路径。Azure 的 Agents SDK 搜索工具至今仍无法转发那个令牌，而权限层面的锁定才是真正拴住你的那一层。

作者 智能体 AI 维基 23 分钟读完

没有人是冲着检索质量去买一套托管知识库的——这四家之间的排序差距早就收敛了，你用 pgvector 加一个重排器，两周之内就能追平其中任何一个。你真正买的，是那个把 SharePoint 的权限连同 SharePoint 的文件一起搬过来的连接器，以及那条按最终用户逐一强制执行权限的查询路径。于是签约之前唯一值得问的问题就是：智能体那条集成路径究竟带不带最终用户的身份，还是只有你评估过的那个 API 才带？这四家里有一家，截至今天，有文档记录的答案是：不带。

速览

四家都在卖「不用自建流水线的 RAG」，而重心确实各不相同。其中三家是云原生的、继承各自云的身份平面；一家是独立平台，可以跑在你的 VPC 里，也可以完全离网部署。

服务形态权限从哪里来最难离开的那一层
Amazon Bedrock Knowledge BasesBedrock 内的托管版或自管版连接器继承的 ACL，检索前过滤，之上再加一次实时检查IAM 与连接器的接线
Vertex AI Search全托管数据存储，Google 的搜索家底来自你 IdP 的最终用户身份；导入数据用 acl_info 元数据与身份提供方的集成
Azure AI Search一台你去配置的搜索引擎，而不是一条买来的流水线查询上带最终用户令牌的权限过滤器索引模式与技能组
Vectara全流水线 API，SaaS / VPC / 本地部署平台 RBAC 加上你自己建模的语料级作用域没什么——这正是它的卖点
Four managed knowledge-base services across four axes A matrix comparing Amazon Bedrock Knowledge Bases, Vertex AI Search, Azure AI Search and Vectara on breadth of first-party connectors, query-time permission enforcement, how much of the pipeline you can control, and how portable the result is. Each service is strong on a different axis and none is strong on all four. Where each service leans hardest Connectors Query-time ACLs Pipeline control Portability Bedrock Knowledge Bases Strong Strong Medium Weak Vertex AI Search Strong Strong Weak Weak Azure AI Search Medium Strong in the API, not in the agent tool Strong Medium Vectara Weak Medium Weak Strong Strong Medium Weak Portability here means how much survives a move to another vendor
每一家都在不同的轴上最强，而没有一家四个轴都强。

Amazon Bedrock Knowledge Bases

它给你什么

六个一方连接器——S3、SharePoint、Confluence、Google Drive、OneDrive 和一个网页爬虫——外加自定义连接器与直接的流式摄取，用于那些不住在可爬取系统里的数据。元数据过滤支持布尔、字符串、双精度与整数属性，足以表达租户、文档类别与新鲜度，而不必另造一条旁路。

权限故事才是差异所在

托管版在检索之前施加 ACL 过滤，并在其上叠加一次实时访问检查；被预过滤出来的文档只在该次 API 调用的生命期内短暂存在，绝不呈现给模型或用户。第二道检查比听起来更要紧：针对已建索引的 ACL 做的预过滤，只新鲜到你上一次同步为止，而今早刚被撤销的一项权限，正是过滤器陈旧就等于泄露的那种情形。这正是带权限的检索所主张的设计——在检索之前强制，并对真正进到提示词里的内容做延迟绑定。

它让你付出什么

托管版拿掉了向量库，也就拿掉了调优它的能力。自管版把这些还给你——OpenSearch Serverless、Aurora、Neptune——连同整条摄取流水线，而那是另一个产品、另一份运维账单。在两者之间做选择才是真正的决定，而团队常常为了演示挑了托管版，然后发现自己的语料需要的是自管版。

Vertex AI Search

它给你什么

不出意外，这组里排序家底最厚的一个，要配的东西也最少。数据存储可从 Cloud Storage、BigQuery、网站与一方连接器摄取；混合检索与语义排序默认开启，而不用你自己拼。如果你的评估标准是「不做任何调优，它能不能找到对的东西」，通常是它赢。

访问控制以身份为先

Google 通过你的身份提供方把检索绑定到最终用户：搜索应用识别出是谁在问，并过滤到此人可见的范围。对于你自己导入的数据——Cloud Storage、结构化数据——你需要在文档元数据里提供 acl_info 字段，并把该数据存储标记为受访问控制。这是个干净的模型，同时也是一项硬依赖：你在把自己的 IdP 接进检索路径，这是一次安全评审，不是一次配置改动。

它让你付出什么

三家云服务里流水线控制最少的一个。你换不了切分器，嵌入模型是 Google 的。计费按每千次查询计量，另有一份独立的运行时费用，这很可预测，但也意味着一个每轮发四次搜索的话痨智能体，成本是只发一次的四倍——这是一个要求智能体式检索有所节制的理由，而它与质量毫无关系。

Azure AI Search

它给你什么

严格说它是这组里的异类：它是一台带索引器框架的搜索引擎，而不是一条托管 RAG 流水线。你拿到的控制权比另外三家加起来还多——自定义分析器、技能组、你自己的切分、由你调优的向量与混合配置——相应地要自己扛的也更多。对那些已经知道自己的检索该长什么样的团队，这正是重点。

文档级访问控制，以及那道缺口

权限模型本身确实做得好。权限元数据随内容一起建索引——SharePoint 索引器会直接摄取 ACL——而在查询时，你在 x-ms-query-source-authorization 请求头里传一个用户或用户组令牌。服务先检查你的客户端是否持有 Search Index Data Reader，然后把结果裁剪到该主体可见的范围。

Two paths into the same index, only one of which carries the end user's identity Ingest carries the permissions; the query has to carry the principal Source system SharePoint, Drive, Confluence Connector copies content + ACL metadata Index chunks, vectors, permission keys Retrieval: filter, then rank Path A — direct search call App authenticates the end user, forwards a user or group token on the request Filter has a principal to apply Path B — the agent tool wrapper Agent framework calls the same index with the service identity, no end-user context to pass Filter has nothing to apply — the index is wide open The permission model you evaluated lives on Path A; the agent you are building uses Path B Test the integration you will ship, not the API the documentation describes
你评估过的权限模型活在那条直接路径上。而你正在建的智能体可能不在那条路上。

接下来是该改变你评估方式的那部分。Azure AI Foundry Agents SDK 内置的 Azure AI Search 工具，没有提供任何方式去传那个请求头、或任何等价的按请求安全上下文——issue #44454，2025 年 12 月提出，截至撰稿时仍然开着、仍在等服务团队处理。原生 SDK 支持权限裁剪；智能体工具不支持。按文档方式接起来的智能体，是以服务身份在查询索引，而过滤器没有主体可施加。

这不是一条针对 Azure 的教训。这是「买了一套权限模型、却通过一个便利包装去够它」的通用失败模式：控制是在一条代码路径上评估的，产品发布在另一条上。如果你在 Azure 上、而且今天就需要裁剪，那就在你自己的工具实现里直接调用搜索 API，自己把令牌转发过去。代码没多少，而它是「会强制执行的检索层」与「只宣称有的检索层」之间的差别。

Vectara

它给你什么

这里唯一一家不属于某朵云的服务。摄取、用自家 Boomerang 模型做嵌入、混合检索、重排、生成与引用，全都在一个 API 后面，可以按 SaaS、在你的 VPC 里、或完全离网地部署在本地。对那些无法把语料放进超大规模云厂商托管服务的受监管买家来说，这个部署跨度就是这家公司能进候选名单的全部理由。

真正的差异在那套接地机制

Vectara 的 Hughes Hallucination Evaluation Model 会给「生成的摘要是否被其来源所支持」打分，而有意思的数字是延迟而不是准确率：在一块 RTX 3090 上约 0.6 秒，而前沿 LLM 裁判在 4096 令牌上下文上约需 35 秒。那道差距，正是「接地作为离线评测」与「接地作为一次你在每个答案上都负担得起的在线检查」之间的差距，而后者是另一种产品。Hallucination Corrector API 则把它从检测扩展到改写那段无依据的文字。

它让你付出什么

一方连接器最少，所以更多摄取要你自己建。权限是在语料与平台 RBAC 层面建模的，而不是从源系统按文档继承下来的，这意味着多租户的文档级裁剪是你自己要做的设计工作。而它是按企业年度合同售卖的——据报道起步在低六位数——而不是按量计费，于是它的价格把自己挡在了试验之外、挪进了承诺之中。

你究竟被锁进了什么

Three layers of lock-in, ranked by how hard each is to leave Three columns comparing the vector store, the parser and chunker, and the permission model, on what it costs to replace each one. Vectors are the cheapest to rebuild, parsing is weeks of tuning, and the permission model is the layer that reaches back into your identity provider and your source systems. What it actually costs to leave The vector store The parser and chunker The permission model Re-embed the corpus Re-tune extraction per document type Re-plumb identity and every source Cost: compute, measured in hours Cost: engineering, measured in weeks Cost: a security review, measured in quarters Portable: the corpus is yours Portable: only if you kept the raw source Portable: almost nothing transfers Evaluate the layer that is hardest to leave first — it is not the one the benchmarks measure
人人都在跑基准的那一层，正是最便宜就能换掉的那一层。

向量锁定是人人都在点名、却几乎无关紧要的那个：向量是派生数据，只要你留着源语料，一个周末就能把它重新嵌入到任何地方去。重建索引的操作手法已经很成熟——见重建索引与嵌入迁移。

解析器锁定更糟，而且更少被谈起。这四家服务每一家都自行决定 PDF 怎么变成文本、表格怎么线性化、扫描页怎么 OCR、分块边界落在哪里。这些决定框定了你的检索有可能找到什么，它们要按文档类型调上好几周，而这些调优一样都带不走。永远保留你摄取的一切的原始文件，否则一次迁移就变成一次重新采集。取舍在为 RAG 解析文档里，你可能想叠在上面的那层增强在上下文化检索里。

权限锁定才是真正拴住你的那个。它向回伸进你的身份提供方、伸进每个源系统的 ACL 语义、伸进一次已经通过了的安全评审。换掉它意味着这三样都要重做。如果你只认真评估一层，就评估这一层——并且要在你实际会上线的那条集成路径上评估。

什么情况选哪个

情形选因为
企业内容在 SharePoint/Drive/Confluence，必须按人给答案Bedrock KB 或 Vertex AI Search连接器继承 ACL 加上查询时强制，才是昂贵的那部分，而两家都带。
你已经清楚自己的检索设计，想去调它Azure AI Search这组里控制最多——但要自己实现搜索调用，好把用户令牌转发过去。
语料不能出网，或必须离网运行Vectara唯一一家有真正本地部署路径的。
接地必须在每个答案上在线检查Vectara亚秒级的接地打分，改变了你负担得起检查什么。
公开文档，没有按人的权限大概哪个都不用你付钱买的就是那套权限管道。没有它，pgvector 加一个重排器更便宜，而且是你自己的。
多云，或者你预期会搬家Vectara，或者自己建那三家云服务是有意重度依赖各自的身份与存储平面的。

对一个拥有正常企业语料的团队，诚实的默认选择是：挑你的身份提供方已经信任的那朵云所属的托管服务，把省下的时间花在评测上，而不是花在流水线上。失败模式不是选错了——而是照着排序基准做选择，六个月后才发现那条权限路径。

常见问题

托管知识库比用 pgvector 自己建更好吗？

论检索质量，不见得——一套称职的混合索引加重排器很难被打败，而且每个旋钮都归你。托管服务赢在连接器与权限强制上，而那正是要花上几个季度才能做对的部分。如果你的语料是公开的或单租户的，就自己建。

这些服务支持文档级访问控制吗？

四家都以某种方式表达权限，但机制差别很大：连接器继承 ACL、检索前过滤（Bedrock），来自你 IdP 的最终用户身份加上导入数据的 acl_info（Vertex），已建索引的权限元数据加上按查询的用户令牌（Azure），以及平台 RBAC 加你自己建模的语料作用域（Vectara）。在相信其中任何一条之前，先用两个用户和一份哨兵文档把你自己的那套测一遍。

Azure Foundry Agents SDK 的那道缺口究竟是什么？

Agents SDK 里内置的 Azure AI Search 工具，没有提供任何方式去传 x-ms-query-source-authorization 或等价的按请求安全上下文，所以通过原生搜索 SDK 生效的权限裁剪，通过这个智能体工具并不生效。变通办法是自己写一个调用搜索 API 并转发令牌的工具。

如果我要换家，索引能带走多少？

向量：带不走，而且无所谓。解析并切分后的文本：只有你留着才行。原始源文件：全都能带走，只要你留着。权限模型：几乎什么都带不走。留着原始源文件。

上下文化检索能叠在这些之上吗？

只在你掌控摄取的地方可以。Azure 的技能组与 Bedrock 的自定义连接器给了你放置那段引子的地方；Vertex 的托管数据存储基本上没有。如果分块级的上下文丢失是你的主要失败模式，这一点会收窄候选名单。

延伸阅读

本站：

来源：