同一条退货或采购问题，不同国家、不同岗位的员工，未必应该看到同一份答案。AWS在10月22日披露宠物零售集团IskayPet的知识助手实践：它没有把所有SharePoint文档混进一个入口，而是按助手划分知识范围。每次先取回25段材料，清理后最多放入15段。比多塞几页文档更重要的，是先确认这些材料属于谁、能给谁看。

快速看点：案例覆盖三个国家、四种语言和多个业务部门，沿用SharePoint而非先搬迁文档；应用入口与检索阶段分别处理可见范围；托管检索减少基础设施工作，但不会替应用认证用户，也不意味着文档更新后无需同步。

按助手分知识库，不把所有问题塞进一锅

IskayPet的运营资料分散在不同地区和部门，涉及门店、员工入职、采购等日常流程。相似的问题可能对应不同地区制度，资料本身也会更新。单纯增加上下文长度，不能决定哪份制度才适用于提问者，更不能补上原有文档中的矛盾或缺项。

团队比较了两种结构：共享一个知识库，用国家、部门标签逐次过滤；或者为每个助手建立独立知识库，连接指定SharePoint站点、资料库及包含路径。案例选择后者，让每个助手有自己的索引范围和调优空间，新增领域时再接入对应内容。

这不是说共享知识库一定错误。独立划分便于隔离和验收，也会增加助手数量、公共材料维护和跨域查询的管理工作。企业需要根据权限差异、文档责任人和问题分布选择结构，不能仅凭这一个案例把“每个助手一个库”当成通用最优设计。

底层采用Bedrock Managed Knowledge Base，服务管理摄取、索引、存储与检索基础设施。它与客户自己选择、维护向量数据库的模式不同。团队仍负责选数据源、配置身份、维护应用和评估答案，“托管RAG”不等于业务交付自动完成。

能看见助手，还要能看见答案用到的文档

案例把权限检查分成两层：用户只看到其有权访问资料的助手，无法确认权限时不显示入口；提问进入检索后，再按文档权限限制返回段落。两名员工问同一个问题，得到不同材料支持的回答，在这种设计里可能是正确结果，而不是模型不稳定。

但产品文档明确提醒，ACL感知检索提供的是权限列表过滤，并不认证最终用户。应用必须先完成认证，再传入经过验证的身份上下文。若允许调用方任意填写别人的身份，单靠知识库过滤就不能构成完整安全边界，这一责任不会因为用了托管服务而消失。

身份匹配也有具体约定：用户邮箱需要与连接数据源中的邮箱精确一致，没有自动别名解析或跨身份提供方映射。组成员关系来自同步所得数据；对支持实时核验的连接器，还会向源系统确认文档访问。不能把某个连接器具备的检查能力推广到所有数据源。

文档说明，ACL解析或实时核验出错时，应不返回受影响文档。因此“没有检索到结果”可能是内容确实不匹配，也可能是权限处理失败。把两者都转成一句流畅的否定回答，会隐藏故障；应用需要保留可排查的状态，而非让模型自行猜测业务规则。

25段变成最多15段，是案例参数而非标准答案

案例采用混合检索结合语义与关键词，再进行重排。先取回25段，剔除重复和过短片段后，最多将15段送入提示词。这样既考虑精确术语匹配，也控制重复材料和输入token；这些数量来自该团队的调优设定，不代表其他文档或模型照搬就会得到同样结果。

回答要求依托取回材料并附带可核查的文档引用，材料不足时说明无法回答。这里的引用是企业助手自身的溯源功能，不是把检索结果变成新授权。正文读者应区分“模型引用了文档”和“引用内容正确、仍有效、适用于这个岗位”这几项不同验收条件。

数据新鲜度同样需要单独安排。官方同步文档说明，增删改文档后仍要同步重建相应索引；增量同步只处理变化部分，默认频率是按需触发，也可配置周期。内容更新与查询时的实时权限检查不是一回事，不能把后者理解为每次都重新读取全文。

团队使用实际反馈改进评估，并把检索条数视为输入成本的重要杠杆。产品评估工具也区分“只检索”和“检索加生成”，有助于判断错误出在找材料还是写答案。案例提到的收益缺少足够公开样本与独立基线，本稿不采用提速百分比；预计查询量也不写成已达成规模。

小编判断：先验收权限，再讨论回答有多快

这项实践的可复用价值，是把国家、业务范围、文档权限与上下文预算放在同一个设计里。它不以换一个更大模型解决所有问题，也没有把既有SharePoint仓库视为必须先迁走的负担。托管服务省下的是部分基础设施工作，留下的则是更清楚的业务责任划分。

对准备试点的团队，可以先用少量跨岗位、跨地区问题建立验证集，同时测试有权、无权、撤权、同步失败和材料缺失。再把答案依据、更新时间、错误分层及每次请求成本记录下来。以上是实施建议，不是已复现测试。能回答问题只是起点；知道为什么这名员工能看到这份答案，才是企业知识助手可交付的一部分。