企业 AI 助手的引用、权限与线上评估

Taxbit 把 AI 助手嵌进了税务合规产品，但真正费工夫的不是聊天界面，而是让回答有出处、操作建议符合用户权限，并且不越界提供税务建议。他们的经验是：先整理知识、固定权限边界，再调整提示词。

这篇案例值得程序员读，是因为它把企业 AI 助手拆成了一组具体工程问题：检索为什么会答偏，多租户身份该放在哪里，上线后怎样判断回答质量。至于托管平台带来的收益，原文也有一些尚缺对照数据的结论。

回答靠不靠谱，先看知识库收了什么

Taxbit 成立于 2018 年，服务交易所、支付服务商和经纪商。产品知识散落在官网、API 文档和帮助中心，还有一部分只存在于代码里。助手首先要解决的，是把这些知识变成能检索的产品说明。

他们使用 Amazon Bedrock Knowledge Bases，底层由 Amazon S3 Vectors 存储向量；嵌入模型是 Cohere Embed English v3，生成 1,024 维 float32 向量，以余弦距离比较。

但选好组件只是起点。站点地图有 400 多个 URL，真正适合回答产品问题的只有 70 多个，单是 /blogs/ 就有 300 多篇营销内容。营销页混进索引，会和帮助文档争夺引用位置。团队发现，排除它们比修改提示词更有效。

另外两类内容来自代码生成的 Markdown，以及人工编写的补充文章和已批准纠正。代码生成文档覆盖页面路由、权限门槛、表单适用条件和报表配置，把产品实际行为补进知识库。

九个抓取器按 S3 前缀归入三个数据源：product-public/、product-internals/、curated/。Amazon EventBridge 按错开的夜间和每周计划调度 AWS Lambda；抓取器利用 sitemap 的 lastmod 和内容哈希识别变化，只在内容更新时触发入库。

切块后还保不保留适用范围，比切块本身更重要。

语义切块在他们的检索测试中优于固定长度切块，但正文中间的一段话，可能丢掉「只适用于非美国申报」的前提。拿它回答 IRS Form 1099 问题，文字没错，结论却可能误导。

团队通过自定义转换钩子，在 POST_CHUNKING Lambda 中给每块补上 H1 标题和导语。前缀约 128 tokens，标题最多 80 字符、范围说明最多 300 字符；正文限制为 384 tokens，配合 Cohere Embed English v3 的 512 tokens 输入上限。生产探测发现，约 28% 的块落在 385–512 tokens 区间，加前缀后尾部会被静默截断。

查询阶段则先扩大候选，再重排、去重：

question ─► vector search (75 candidates)
─► Cohere Rerank 3.5, server-side in the same Retrieve call
─► top 12 reranked
─► cap of 2 chunks per source document
─► top 5 passed to the model

要看的是每篇文档最多保留 2 块这一行，它避免一篇长文占满上下文。75 个候选也有原因：权威文章经常排在向量检索的第 20–50 位，进入候选池后才被重排推到前面。Cohere Rerank 3.5 在同一次 Retrieve 调用内执行。

引用资格同样由代码控制：只有官网、API 文档、帮助中心可以生成来源链接；内部文档可以支撑答案，但不能给用户一个打不开的地址。

模型能选工具，身份必须由服务端决定

Taxbit Assist 是运行在 Amazon Bedrock AgentCore runtime 上的 Strands Agents SDK Python 应用，以 ARM64 容器发布到 Amazon ECR。它只有八个工具：知识搜索、组织权益检查、用户角色检查、工单创建/查询/更新/关闭，以及当前时间。

当前版本不读取客户税务数据，写操作只涉及调用者自己的工单。这让权限边界相对清楚。

关键设计是：email、organization ID 和 dashboard roles 来自已认证的调用服务，通过闭包绑定到工具。模型可以决定是否调用权限检查，却不能填写「检查谁」的身份参数。输入边界还会清洗用户内容，防止其冒充可信上下文。

这比在提示词里要求模型遵守权限更可靠。不过，原文没有说明所有越权路径是否都有强制工具检查，不能仅凭身份绑定就推断整个授权流程已经完备。

会话由 AgentCore runtime 隔离，历史按 memory、session 和 actor ID 分区。actor ID 必须来自调用服务，因为 runtime 共用一个 AWS service role；若直接用 AWS 调用身份，所有用户可能进入同一历史分区。

请求进入后，先通过独立的 ApplyGuardrail 调用检查当前用户轮次，被阻断就不调用模型。密码、银行卡验证码、云访问密钥直接拦截；社会安全号码、ITIN、银行账号、路由号码和 IBAN 等按策略匿名化。团队后来针对误报，将 PIN 和银行路由号码检测器调成 detect-only，让 1099 这类表单编号通过。因此，不能把这一方案理解成所有敏感数字都会自动脱敏。

跨区域推理使用带地理前缀的 inference profile，使 EU 部署在 EU 内推理、US 部署在 US 内推理。BYOK 账户中，会话历史等客户数据存储使用客户自己的 AWS KMS key 加密。外部集成凭据则放在 AWS Secrets Manager，运行时读取。

上线后，要把检索错误和回答错误分开测

每次请求通过 OpenTelemetry 向 Amazon CloudWatch 发出追踪数据，评估异步进行，不阻塞响应。

AgentCore online evaluations 抽取 10% 的线上会话，用六类 LLM-as-a-judge 评估器检查有用性、有害性、连贯性、指令遵循、工具选择准确性和工具参数准确性。

团队另外用 Lambda 评估「是否忠于检索来源」和「检索文章是否相关」。这两个指标必须分开：模型完全照着错误文档回答，忠实度可能很高，问题却出在检索。

税务建议边界由另一个基础模型分类器检查每条响应。解释 Taxbit 如何执行 FIFO 属于产品说明，建议用户选择某种计税方式则越界。作者报告，带指令和示例的模型分类器误报接近零，主题过滤器约为 25%。原文没有给样本规模、漏报率和标注标准，这只能证明他们报告过这样的结果，不能证明边界已经守住。

人工审核补上最后一环：抽样问答移除个人信息后交给专家，批准的纠正写入 curated/，触发增量入库，几分钟内影响后续答案，无须部署。

工程发布也有质量门槛。整套基础设施用 AWS CDK 定义；每个 PR 运行黄金场景离线评估，检查预期工具路径和行为，每晚再对生产运行。合并后先部署 staging，再经人工批准进入 production。

我的判断

我最认可的是他们把注意力放在知识范围、分块上下文和身份绑定上。这些问题即使换模型也不会消失。与优先微调相比，这个案例至少说明：模型之前的输入质量，有很多可直接修复的空间。

但它仍是一份厂商平台上的客户案例。语义切块胜过固定切块、检索调整胜过提示词修改，都没有给出完整对照数据，应当视为团队经验。

效果数字也要分开看。自 2026 年 5 月在 US 和 EU 上线后，超过 55% 的提问用户在 24 小时内再次使用 Assist；这是复用信号，不等于问题解决率。W-8、W-9 接入客户减少等待支持的故事，也没有量化工单节省。

作者报告平均每次对话模型成本低于 20 美分，约四分之三输入 tokens 命中缓存，模型成本下降超过一半。前提是 system prompt 逐字节稳定并以 cache checkpoint 结束，请求上下文放在 user message 中。该数字不是包含检索、存储和运维的总成本。

托管方案适合这个小团队，但一般团队还要衡量 AWS 依赖和迁移成本。ISO/IEC 42001 管理体系实践、ISO/IEC 27001 和 ISO/IEC 27701 认证、SOC 2 Type II 报告，也不能替代单次回答的验证。Taxbit 不训练或微调模型，Amazon Bedrock 不用提示和回答训练模型，同样不代表数据处理的全部问题都已解决。

能拿来做什么

• 给产品后台加 AI 帮助入口前，先筛选帮助文档和 API 文档，把营销内容排除；同时给每块保留产品、地区和适用条件，检查加前缀后是否超过嵌入模型上限。
• 在 Node 工具层用已认证会话绑定租户和用户身份，避免把可由模型填写的 userId、organizationId 当作授权依据；推荐操作前同时检查功能权益与角色。
• 把检索相关性和回答忠实度分开评估，并让专家纠正进入可增量更新的知识源，形成可追踪的修复流程。
• 使用 Bedrock 自定义转换前，准备独立的中间存储 bucket，同一 bucket 换前缀不被接受；已有数据源启用转换会触发替换，要预留完整重新入库的时间。