RAG 与知识库
Agentic RAG 不是多检索一步：状态、ACL、拒答与单位正确成本实验
用 39 份三租户合成策略、24 个冻结查询和 19 项测试，对比固定单次检索与有状态自适应检索，实际核算答案决策、ACL、拒答、步骤预算和单位正确成本。
时间与证据
这是一篇在 2026 年 7 月 15 日实际运行的本地实验记录。问题不是“Agentic RAG 听起来是否比普通 RAG 先进”，而是更窄、更容易被证伪：面对同一组多租户策略和查询，一个具有路由、改写、第二次检索与停止预算的控制器，能否比固定单次检索作出更多正确的 回答或拒答决策；如果能，增量召回需要付出多少步骤、工作量和单位正确成本；权限隔离是否仍然是不可抵扣的硬门。
实验的可复核工件全部保存在 labs/agentic-rag-eval/：
data/corpus.json固定 39 份合成政策文档，分属atlas、boreal、cinder3 个租户。同一主题在不同租户故意写入冲突事实，例如客户餐费上限分别是不同答案，用来验证系统不能先全库打分再补租户过滤。data/queries.json固定 24 个查询，其中 18 个可回答、6 个应拒答。一条可回答查询要求跨两个路由取回两个事实，另有显式询问其他租户、近邻但无答案、表达改写和歧义问题。src/evaluate.mjs实现词法切词、路由、显式改写、ACL 预过滤、固定单次检索、有预算状态机、答案事实选择、拒答和全部指标。执行过程中不调用模型、embedding、API 或网络。test/evaluate.test.mjs包含 19 项自动测试，覆盖路由平局、改写、租户隔离、当前与外部租户同时出现、大小写和租户名边界、跨租户提前停止、固定单次检索、第二次检索、步数与状态转换预算、循环终止、ACL 硬失败、指标分母、零接受时的成本分母、失败样本、重放载荷和原始工件哈希。results/2026-07-15-results.json保存协议、数据规模、两种方法的逐查询 trace、最终决策、汇总指标和失败原因，文件 SHA-256 为7ea15ce227bcb1428bcf693941197ff477e5b9d3567dbe0707795a487d668efa。results/README.md给出校验与重放命令。新运行只剥离capturedAt和environment两个证据外壳字段后，决定性载荷应与历史工件逐字段一致。
结果工件记录的环境是 Node.js v22.23.1、darwin、arm64。捕获时间以 UTC 保存为 2026-07-14T17:57:22.063Z，对应上海时间 2026 年 7 月 15 日。时间和运行环境用于回答“这份字节何时、在哪里产生”，不参与路由、检索或评分，所以不能为了让 hash 看起来稳定而伪造，也不能被纳入决定性载荷比较。测试同时固定完整文件 hash 和去除这两个外壳字段后的语义载荷，分别检查“历史文件没有变化”和“当前实现仍能产生同一结果”。
两条外部来源只定义背景，不替本站实验背书。Azure AI Search 在完整提交 6be729b15428060b34c980af93767e309e27edd5 中的 Agentic Retrieval 文档描述了读取对话历史、用 LLM 规划子查询、并行检索、合并排序，以及返回 grounding、reference 与 activity plan 的产品架构，也明确指出 query planning 会增加延迟。Adaptive-RAG v2讨论按问题复杂度在无检索、单步检索和迭代检索之间选择策略。这些来源说明为什么“按查询选择检索深度”值得研究，但它们的模型、数据和指标都不是本文结果来源。
本文证据等级是 reproduced，因为仓库内固定输入、实现、测试、原始结果、失败样本和 hash 均已执行并可重放。这个等级不等于 field-tested：39 份文档是为隔离控制变量而编写的 synthetic deterministic policy calibration，不是客户知识库；24 个查询不是生产流量；没有运行任何 LLM、embedding、向量数据库或语义重排器；工作量和成本都是协议规定的合成单位。因此，本文可以证明这套确定性控制器在这组冻结夹具上的行为，不能证明某个 Agentic RAG 产品、某个模型或某个真实企业部署达到相同收益。
实验设计
先把评测对象从“相关段落”改成“业务决策”
普通检索实验容易停在 Recall@K：只要相关文档进入候选列表，就算成功。但策略问答的真正交付对象是答案决策。系统可能检索到正确文档却因支持分不足而拒答，也可能检索到主题近邻文档后自信回答一个不存在的政策，还可能命中正确事实但同时带出另一个租户的机密内容。三种情况的检索分数都可能看起来不错，业务结果却完全不同。
本实验因此保留两层账。第一层是检索账：预期相关文档有多少、实际取回多少、每个可回答查询是否取全。第二层是答案账：预期 answer 还是 abstain，回答时返回的事实 key 是否与冻结答案集合完全一致，是否发生 ACL 泄漏，检索步数是否越过预算。只有答案类型、事实集合、权限和预算全部满足，查询才记为 accepted。相关文档召回单独报告，不能替代最终验收。
18 个可回答查询覆盖餐费、发票、假期、育儿假、MFA、密钥轮换、HTTP 429、P1 升级、客户数据删除、员工审计日志、入职和生产写权限。6 个拒答查询包括宠物牙科保险、停车补贴、只有“limit”的无上下文问题、未定义的 P1 日志保留、未定义的欧盟工资数据驻留，以及 atlas 身份显式询问 boreal 餐费政策。最后一条不是普通无答案，而是身份边界问题：即使其他租户确实存在答案，也必须在检索前停止。
答案没有交给生成模型自由表述。每份政策文档携带冻结的事实 key，例如 atlas-meal-cap-80；评估器从最高支持文档选择事实集合，与查询期待集合做精确比较。这样牺牲了自然语言生成的真实性，却把“召回控制器是否拿到并选择正确依据”从语言风格和模型随机性中隔离出来。本文所谓答案决策准确率，指的是这个受限协议下的精确事实决策，不是开放式回答的语义正确率。
多租户 ACL 必须在相似度计算之前执行
retrieve 先按认证租户过滤候选，只允许 document.tenantId === query.tenantId 或可选的 public 文档，再按路由和词法分数排序。实验数据没有 public 文档，因此每次实际候选都只能来自当前租户。这个顺序很重要：如果先在三租户全集向量化、召回或重排，再在返回前隐藏外租户文档，top score、缓存、日志、计费、工具 trace 甚至生成上下文本身都可能已经泄漏信息。
scope guard 会按大小写不敏感的完整标识边界收集查询中出现的全部已知租户名；只要集合里有一个不是认证租户，就在检索前停止并返回 tenant-scope-mismatch。因此同时出现 ATLAS 与 bOrEaL 也会阻断，而 Borealis 不会被子串误判为 boreal。评分器还会独立检查所有 retrievedIds；只要有未知文档或未经授权文档，加入 acl-leakage 失败原因，并把该查询判为硬失败。即使伪造一个内容完全正确的答案，ACL 泄漏也不能被答案分、召回分或成本分抵扣。测试专门构造“答案事实正确但引用了 atlas 文档来回答 boreal 查询”的运行记录，确认最终仍被拒绝。
固定基线与有状态控制器
fixed-one-shot 的流程是：路由一次、ACL 过滤后检索一次、决策一次。它不根据首轮证据改写查询，也不发起第二次检索。对显式跨租户请求，两种方法都在 scope guard 停止，因此固定方法在 24 个查询上的平均检索步数不是整齐的 1.0，而是 23 / 24 = 0.958333。
adaptive-stateful 使用显式状态，不靠一段不可检查的 Prompt 暗示“必要时再搜”：
route
-> retrieve(step 1, ACL first)
-> assess
-> support sufficient: stop -> decide
-> weak support: rewrite -> route
-> retrieve(step 2, ACL first)
-> assess -> stop -> decide
每次事件都写入 trace，包含使用的查询文本、路由、候选数量、排名、支持分、改写前后文本、检索步数、停止原因和最终 outcome。状态机的默认硬预算是最多 2 次检索、9 次状态转换、每次取 3 个候选。支持充分时以 support-sufficient 停止；已经用完检索额度时以 retrieval-budget 停止；转换数耗尽时以 transition-budget 停止；没有匹配的显式改写时以 no-rewrite 停止；重复遇到同一改写状态时以 loop-detected 停止。循环测试让改写函数在两个字符串之间来回切换，控制器在第 3 次检索后识别重复状态，没有跑满 20 次转换上限。
路由器对 finance、people、security、reliability、governance、access 六类提示词计数。最高分并列时返回 null，不偷偷用字母顺序挑一个看似确定的路由。null 表示退回当前租户的全路由候选，成本会因为候选数增加而上升。改写表也是公开规则，例如把 supper/ceiling 补成 meal dinner limit cap，把 PTO 补成 annual leave carryover，把 throttled/endpoint 补成 API 429 Retry-After backoff。规则不读取查询的 expected 字段；标签只在评分阶段使用。
这里的“adaptive/agentic”描述的是控制流，不是模型身份。Azure 固定文档里的产品架构会让 LLM 从对话中规划多个子查询并行执行；本文控制器只是一个确定性、串行、最多两步的可审计替身。它的作用是先校准状态、预算、权限与结果账本，不能冒充真实 LLM query planner。
分数、停止阈值和成本账
词法分数把查询 token 与文档标题、关键词和正文分别匹配，权重依次为 3、2、1；通用疑问词被去除。只有正分文档进入排名。首位分数达到固定阈值 4，且路由不是 null，控制器才认为支持充分；否则尝试一次显式改写或拒答。这个阈值没有用独立开发集校准，是实验常量，不是概率置信度。
指标分母固定如下：
- 路由准确率只统计期待路由非空的 23 个查询，报告最终路由正确数，不拿无路由歧义题凑分母。
- relevant micro recall 以全部期待相关文档为分母。18 个可回答查询中，组合题需要 2 份文档，所以文档分母是 19，不是 18。
- answerable query recall 要求一条查询的相关文档全部取回；组合题只取回一份算失败。
- 拒答 precision 的分母是实际拒答数，recall 的分母是期待拒答的 6 条；拒答 accuracy 则检查 24 条查询的 answer/abstain 类型是否正确。
- answer decision accuracy 的分子是通过完整接受条件的查询，分母始终是 24。失败、拒答和权限阻断不会从分母消失。
- ACL leakage rate 的分母也是 24，但任何非零泄漏都会额外设置
hardFailure: true。
为了避免用机器瞬时毫秒为一个确定性微实验制造噪声，协议定义 latency work units：route 为 1，retrieve 为 3 + 候选文档数，assess 为 1，rewrite 为 1，decide 为 1，scope guard 为 1。它表示相对工作量，不是 wall-clock latency。成本使用另一套 milliunit：route 100，retrieve 基础 500 并对每个候选加 50，assess 100，rewrite 150，decide 150，scope guard 100，最后除以 1000 得到 cost units。
unit accepted cost = total cost units / accepted decisions。若一个方法没有接受任何查询，结果必须是 null，而不是 Infinity、0 或悄悄换分母。这个定义让更高召回的控制器同时面对成本问题，但合成 cost unit 仍然只适合方法内对照，不能映射为美元、云账单或工程师工时。
复现命令是：
node --test labs/agentic-rag-eval/test/*.test.mjs
node labs/agentic-rag-eval/src/evaluate.mjs \
--out /tmp/agentic-rag-replay.json
shasum -a 256 \
labs/agentic-rag-eval/results/2026-07-15-results.json
jq 'del(.capturedAt, .environment)' \
labs/agentic-rag-eval/results/2026-07-15-results.json \
> /tmp/agentic-rag-checked-payload.json
jq 'del(.capturedAt, .environment)' \
/tmp/agentic-rag-replay.json \
> /tmp/agentic-rag-replayed-payload.json
diff -u \
/tmp/agentic-rag-checked-payload.json \
/tmp/agentic-rag-replayed-payload.json
结果
主结果：正确决策增加，但不是免费增加
| 指标 | Fixed one-shot | Adaptive stateful | 变化 |
|---|---|---|---|
| Answer decision accuracy | 0.625 | 0.875 | +0.250000 |
| Accepted / 24 | 15 | 21 | +6 |
| Relevant micro recall | 0.736842 | 0.947368 | +0.210526 |
| 取回相关文档 / 19 | 14 | 18 | +4 |
| Answerable query recall | 0.722222 | 0.944444 | +0.222222 |
| Route accuracy | 0.956522 | 0.956522 | 0 |
| ACL leakage queries | 0 | 0 | 0 |
| 平均检索步骤 | 0.958333 | 1.208333 | +0.250000 |
| 最大检索步骤 | 1 | 2 | +1 |
| 平均 latency work units | 7.791667 | 10.916667 | +3.125000 |
| Total latency work units | 187 | 262 | +75 |
| Total cost units | 21.05 | 29.65 | +8.60 |
| Unit accepted cost | 1.403333 | 1.411905 | +0.008572 |
固定方法正确接受 15 条，自适应方法正确接受 21 条，答案决策准确率由 0.625 提升到 0.875。相关文档微平均召回由 0.736842 提升到 0.947368：固定方法取回 19 个期待相关文档中的 14 个，自适应方法取回 18 个。按查询计算，固定方法在 18 个可回答查询中有 13 个取全，自适应方法有 17 个取全。组合题仍缺一份文档，所以两个召回口径都没有满分。
新增正确决策来自显式改写，而不是路由准确率变化。q04-atlas-pto 首轮使用 PTO roll into，与写作 annual leave carryover 的政策没有足够重叠；状态机记录第一次弱支持，追加明确领域词，重新路由后第二次检索，最终选择 atlas-leave-carryover-5。同类改善还出现在 throttled endpoint 到 API 429 Retry-After backoff、severity-one 到 P1 incident commander、erasure/agreement 到 data deletion/contract termination 等表达上。
q01-atlas-supper尤其说明为什么不能只看 relevant recall。固定方法凭 client 这一处弱重叠已经把 atlas-finance-meal 放进 retrieved 列表，因此该查询在文档召回上不算漏掉；但 top score 未达到支持阈值，最终正确地说是“没有足够支持”，而标签要求回答，所以答案决策失败。自适应方法把 supper/ceiling 改写为 meal/dinner/limit/cap 后，才形成足以回答的证据。检索到和能够承担答案，是两件不同的事。
两种方法的最终路由都是 23 个可评分查询中正确 22 个，即 0.956522。q16-atlas-onboarding 同时含 access systems 和 new hire，路由提示发生平局，返回 null；检索于是扩大到该租户全部路由，仍凭高词法分数选中正确入职文档。这个样本一方面说明路由错误不必然造成答案错误，另一方面也暴露成本：全路由候选比定向路由更多。把 route accuracy 当最终 KPI，会错过答案正确性和资源消耗的分离。
拒答：少拒了六次，也多错答了两次
固定方法在 6 条期待拒答中正确拒答 4 条，但总共拒答 10 条，其中 6 条其实可回答。因此它的拒答 precision 是 4 / 10 = 0.4，recall 是 4 / 6 = 0.666667，24 条查询上的 answer/abstain 类型准确率是 0.666667。自适应方法总共只拒答 4 条，并且这 4 条都应拒答，所以 precision 是 1.0；但另外 2 条应拒答查询被错误回答，recall 仍是 4 / 6 = 0.666667，类型准确率提升到 0.916667。
因此，不能把“拒答变少”直接解释成体验提升。自适应方法确实把 6 个固定方法的错误拒答转成正确答案，却没有提高拒答 recall；它保留了两个高词法重叠造成的错误作答。对低风险内部搜索，这种交换可能可接受；对合规、医疗、金融或权限操作，错误回答的损失可能远高于人工升级，生产门槛必须给误答更高权重。
权限、预算和成本
两种方法的 ACL leakage 都是 0。q19-cross-tenant 以 atlas 身份询问 boreal 餐费，路由后立即命中 scope guard，检索步骤为 0，trace 中不存在 retrieve 事件。另一个隔离测试用可能强匹配三个租户餐费文档的查询直接调用检索器，返回 ID 全部以当前租户开头。第三个负例向评分器伪造未经授权文档，即使答案 key 与期待一致，也得到 acl-leakage 硬失败。零泄漏是三层检查共同得到的实验结果，不是只看最终页面没有显示外租户文本。
自适应方法的平均检索步骤从 0.958333 增至 1.208333，最大值从 1 增至 2；24 条运行全部在预算内，没有历史数据运行触发 loop 或 transition 超限。测试夹具另外验证了 retrieval-budget、transition-budget 和 loop-detected 三种停止原因，证明这些分支不是 README 里的装饰。平均 latency work units 从 7.791667 增至 10.916667，总量从 187 增至 262，说明第二次检索和评估状态有可见成本。
unit accepted cost 从 1.403333 增至 1.411905，变化为 +0.008572。它没有随着正确决策增加而下降，因为总 cost units 从 21.05 增至 29.65。换一个增量视角：adaptive 多得到 6 个 accepted，额外花费 8.60 个合成 cost units，平均每多一个正确接受约 1.433333 units。这个数字只对当前固定成本模型成立，但它迫使评审回答一个比“准确率提高 25 个百分点”更接近采购的问题：每修复一个错误拒答，需要多付多少控制与检索成本，是否低于该业务决策的价值。
完整结果文件的 SHA-256 是 7ea15ce227bcb1428bcf693941197ff477e5b9d3567dbe0707795a487d668efa。19 项测试全部通过，独立写入 /tmp 的新结果在删除 capturedAt 和 environment 后与历史决定性载荷无差异。scope trace 从单个租户字段修订为全部提及与外部租户数组后，冻结 24 查询的主指标、失败样本和成本均未变化。文章中的数字来自这个工件，不是根据表格反推，也不是由封面图表达。
失败与边界
三个 adaptive 失败样本不能从分母移除
第一个失败是 q21-atlas-composite。查询同时要求“员工离开后立即关闭什么访问”和“审计日志保留多久”，期待相关文档是 atlas-access-offboarding 与 atlas-governance-audit-retention 两份，期待答案也有 atlas-offboarding-disable-immediately、atlas-audit-retention-365d 两个事实。路由器把它归到 governance，首轮审计日志文档得到高支持，控制器以 support-sufficient 停止。它取回 2 份期待文档中的 1 份，返回单一事实，最终是 answer-content-mismatch。
这个失败不是“再提高 topK”就能自动解决。ACL 后的候选仍被单一路由限定，另一份文档位于 access。系统需要能识别复合意图，形成两个有独立完成条件的子任务，分别执行权限过滤与检索，再在答案前检查事实槽位是否齐全。Azure 固定文档中的子查询分解正是产品级架构可探索的方向，但本文没有实现，也不能借外部文档声称已经解决。
第二个失败是 q23-cinder-p1-log-gap。查询问“P1 后日志保留多久”，语料只有 P1 升级策略，没有日志保留期限。P1 在标题、关键词和正文中形成高分，控制器把 cinder-p1-commander-immediate 当作有支持答案。检索的主题相关性很高，回答的谓词却错了：用户要 duration，文档给 escalation recipient。这是典型的 相关文档不等于蕴含答案。要修复它，至少需要问题槽位与文档事实类型对齐，或由可校准的 entailment/answerability 模型判断证据是否真的回答问题。
第三个失败是 q24-atlas-residency-gap。查询问欧盟工资数据驻留，语料只有客户数据删除政策。共同的 data 让删除文档超过阈值，于是系统回答 atlas-customer-delete-30d。这是宽泛业务词制造的近邻误答，也说明固定支持阈值 4 不是置信概率。更真实的索引还会同时出现 data classification、residency、retention、deletion、backup、legal hold 等相邻政策，单纯加词法分只会扩大冲突。
固定方法有 9 个失败，自适应修复其中 6 个，仍保留上述 3 个。保留失败样本比把规则继续补到 24/24 更重要：如果看到每条错误后都向 rewrite 表加入专用短语，最终得到的是答案标签的另一种编码，而不是可泛化控制器。实验的 rewrite 规则已经由同一作者结合冻结任务编写，存在开发集与测试集未分离的问题；本文不把 0.875 当作盲测结果。
零泄漏不是生产安全证明
三租户 ID 是简单字符串，身份来自查询夹具，不涉及 JWT、组织成员关系、文档级 ACL、组嵌套、共享空间、临时授权、缓存 key 或索引同步延迟。显式租户名检测只是对已知 ID 做 Unicode 规范化、大小写不敏感的完整标识边界匹配；真实系统仍需要从认证上下文获得 tenant、subject、roles、resource scopes 与 policy version，不能信任用户在问题里自报身份。
真实向量数据库还要验证过滤发生在 ANN 候选生成之前还是之后、过滤条件是否进入 cache key、reranker 和生成器是否只看到授权内容、trace 是否脱敏、权限撤销多久传播到索引、跨租户统计是否可能侧信道泄漏。本文的 ACL leakage = 0 只证明当前内存数组实现和 24 个夹具没有返回外租户 ID。它是一条最低可复现门禁，不是安全认证。
确定性替身没有覆盖模型系统
实验没有 embedding，因此不能评价语义召回；没有 chunking，因此没有段落边界和父子文档问题；没有向量索引，因此没有近似搜索参数与索引漂移；没有 reranker，因此没有二阶段排序成本；没有 LLM，因此没有 query planner 幻觉、提示注入、上下文污染、自然语言生成错误和引用错配；没有并发和网络，因此没有超时、重试、部分成功或未知结果；没有真实用户日志，因此没有长尾语言、拼写噪声、多轮指代和分布漂移。
答案 facts 是文档内预先写入的 key。这个设计使 answer decision 可以精确重放，却绕开了从自然语言证据抽取事实的困难。一个真实系统即使检索出正确文档，也可能遗漏“每位参会者”“仅限幂等请求”“需要双人审批”等限定词。生产评测必须把引用精确性、关键约束覆盖、无依据陈述和最终业务动作分开标注。
latency work units 和 cost units 也是模型化常量，不是观测值。候选文档数只粗略代理检索工作量，没有考虑索引大小、并行度、缓存命中、token 数、模型吞吐和区域网络。本文只能说“按协议计数，自适应比固定方法多 3.125 平均工作单位”，不能说生产延迟会增加某个百分比，更不能把 1.411905 写成美元成本。
下一次外部有效性验收应更严格
下一版至少要把规则开发集、阈值开发集和时间后移的保留集分离。语料应加入同主题多版本、冲突政策、失效文档、共享文档和细粒度 ACL；查询应由脱敏日志采样并由两名标注者独立判断 answerability、相关文档与关键事实。模型实验需要固定 embedding revision、reranker revision、LLM model snapshot、Prompt、温度、索引参数和容器，并保存每一步原始请求与响应。
对复合问题，应比较单路由、并行多路由和迭代检索；对无答案问题，应单独报告 false-answer rate，而不只给总体 accuracy；对权限，应做撤权、缓存和 trace 泄漏测试；对成本，应报告 p50/p95 wall-clock latency、token、检索调用、重排文档数和实际账单。只有 held-out 结果同时改善最终答案、拒答和权限，并且单位正确解决成本满足业务阈值，才能把这次校准升级为生产候选评测。
商业价值
企业购买的不是“多一个 agentic 图标”，而是减少错误查找、缩短处理时间、控制敏感知识和留下可审计依据。客服政策助手、员工服务台、合规问答、售前知识库和运维 runbook 都可能遇到同一矛盾：简单问题用固定检索便宜，术语错位或复合问题需要更多步骤，但每一步都增加延迟、模型费用和失败面。
本实验给出一个可落地的采购与上线框架。第一，先建立 fixed one-shot 基线，不允许新系统只和“完全不检索”比较。第二，把路由、相关召回、答案、拒答、ACL 与成本拆开，不能用一个平均分掩盖硬失败。第三，只有首轮证据弱或问题复杂时才支付第二次检索成本。第四，所有停止原因必须进 trace，使运营团队能区分“无规则可改写”“预算耗尽”“循环”“权限阻断”和“支持充分”。第五，按 accepted decision 核算单位成本，而不是只报每千次查询价格。
一个更接近业务的收益式可以写成：
单次查询期望净价值
= 正确自助解决率 × 每次人工处理节省
- 错误回答率 × 错误决策损失
- 错误拒答率 × 人工升级成本
- 检索、重排与模型成本
- 评测、内容治理与权限运维成本
ACL 泄漏不应作为普通期望损失参与加权平均，而应是发布硬门。原因不是每次泄漏都能被准确货币化，而是一次跨租户暴露可能触发合同、监管和客户信任后果，且平均准确率无法补偿。本文把任何未经授权 retrieved ID 直接判失败，正是为了让安全合同进入可执行评分器。
按当前合成账，自适应方法以 8.60 额外 cost units 换来 6 个额外 accepted，增量单位约 1.433333。如果一个正确解决的业务价值高于这个增量成本，且两个残留误答可以通过人工复核或风险路由控制，自适应路径可能值得；如果业务问题本来就高度词法化、fixed 已经足够，额外状态机只会增加工作量。这个判断必须换成真实账单和错误损失后重算，不能拿合成 units 直接做 ROI。
状态账本还有独立价值。产品经理可以看到哪些查询触发 rewrite，知识运营可以据此补同义词或修文档标题，安全团队可以抽查 scope guard 和 ACL，平台团队可以分析候选数与步骤预算，评测团队可以从 answer-content-mismatch 生成下一轮保留集。比起只保存最终回答，这些结构化事件更适合定位“是路由错、没取回、证据不足、事实缺失，还是不该回答却回答了”。
生产分层可以从低风险开始：首轮高支持且权限单一的问题自动回答；改写后才命中的问题附引用并抽样复核；复合问题、政策冲突和高影响动作进入人工或专用工作流；任何 scope mismatch、ACL 不确定、循环和预算耗尽都拒答。Agentic 控制的商业价值不在于让所有请求走最长链路，而在于把额外计算投向能产生可验证增量收益的请求。
复盘
第一条结论是，RAG 评测必须越过检索分数到达答案决策。q01 已经召回相关文档却仍无法承担答案，q23 和 q24 则有高相关候选却不包含所问事实。只报告 Recall@K 会同时高估前者的可用性和后两者的可信度。下一轮应把“文档相关”“证据蕴含”“事实完整”“最终回答”做成四层标签。
第二条结论是，自适应检索确实能修复显式词汇错位，但收益来自可见规则，不来自神秘智能。answer decision 从 0.625 到 0.875、relevant micro recall 从 0.736842 到 0.947368，对应的是改写后多取回 4 份期待文档并多正确接受 6 条查询。规则透明使结果可解释，也意味着它容易对当前集合过拟合。真正的下一步不是继续补到满分，而是冻结规则后运行未见过的时间切分查询。
第三条结论是，状态机的价值不仅是“允许再搜一次”，更是让预算和停止原因成为合同。最多两次检索、最多九次转换、重复改写停止、跨租户提前停止都能由测试验证。如果只在 Prompt 里写“避免无限循环”，评分器无法证明实际执行是否遵守；如果 trace 只保存最终答案，成本和失败路径也无法复盘。
第四条结论是，安全过滤必须先于相关性优化。三租户冲突事实让“先全局找最好答案，再看用户能不能看”立即暴露为错误架构。ACL leakage 为 0 是本次实验必要结果，但更重要的是评分规则把泄漏设为硬失败，使将来的优化不能通过提高答案分来掩盖权限退化。
第五条结论是，平均成本应跟正确交付绑定。自适应方法平均 steps 从 0.958333 到 1.208333，work units 从 7.791667 到 10.916667，unit accepted cost 从 1.403333 到 1.411905。准确率提升没有让每个正确接受更便宜。团队若只展示质量增益，不展示总调用、尾延迟和每个正确解决成本，无法判断架构升级是否真正创造价值。
第六条结论来自三个保留失败。组合题要求多路由计划，P1 日志问题要求 answerability 判断，data residency 问题要求抑制宽泛词近邻。这三类失败分别指向 planner、evidence verifier 和 calibrated abstention，而不是同一个“换更大模型”动作。失败样本把下一阶段研发拆成了可验收任务。
下一阶段建议按以下顺序推进：先建立时间隔离 holdout，防止继续把测试题写进规则；再实现事实槽位覆盖和多路由子任务账本；随后接入固定 revision 的 BM25、embedding 与 reranker 做消融；最后才加入固定模型 snapshot 的 query planner 和答案生成。每增加一层，都要保留 fixed one-shot，对同一 ACL、拒答和成本合同重放，不能因为架构变复杂就换一套更容易的分母。
方法披露
本文由 AI 工具协助代码实现、测试设计、资料定位和文字整理；作者逐项核对了数据规模、指标分母、逐查询失败、来源日期、固定提交、运行命令、结果工件和最终表述。39 份政策与 24 个查询是为本仓库编写的合成夹具，不包含客户数据，也没有伪装成真实流量。文中没有把外部论文或 Azure 文档的结果写成本地结果。
Microsoft 来源固定在完整 40 位提交 6be729b15428060b34c980af93767e309e27edd5，文件 frontmatter 日期和提交日期均为 2025 年 5 月 19 日；没有引用可变 main、branch 或 tag。Adaptive-RAG 来源固定到 arXiv 2403.14403v2，该版本修订于 2024 年 3 月 28 日。前者用于说明产品级 query planning、子查询、activity plan、延迟和计费边界，后者用于说明按查询复杂度选择无检索、单步和迭代策略的研究背景；两者都不证明本文 24 条合成查询上的任何数值。
本地评估器是纯 Node.js ESM，运行时不访问网络，不读取环境密钥，不使用随机数，不调用 LLM 或 embedding。检索和答案规则可在 src/evaluate.mjs 中完整审查。捕获文件保留 capturedAt 与 Node/platform/arch；重放比较只剥离这两个环境字段，其他协议、trace、分母、分数、成本和失败样本必须完全一致。原始结果 SHA-256 固定为 7ea15ce227bcb1428bcf693941197ff477e5b9d3567dbe0707795a487d668efa，测试若发现任何字节变化会失败。
19 项测试在文章撰写前全部通过。测试既覆盖当前冻结结果，也主动构造未出现在历史运行中的边界：当前与外部租户名同时出现、大小写与近似名称边界、交替 rewrite 的循环、只有一次检索额度、只有一次转换额度、外租户高分候选、答案内容正确但 ACL 泄漏、零 accepted 的成本分母。这些负例用于证明评分器分支实际可达，不代表生产事故频率。
封面图是对 ACL、状态、预算、答案和成本账本的概念重绘，不新增实验数据。所有精确数值以 JSON 结果工件为准。本文没有进行模型对比、向量检索对比、真实延迟测量、人工盲评或线上 A/B；任何超出“确定性合成策略校准”的推断都应在新的固定协议中重新验证。
修订记录
2026-07-15：初版发布；新增 39 份三租户合成策略、24 个冻结查询、fixed one-shot 与 adaptive stateful 对照、19 项测试、全租户提及 scope guard、ACL 硬失败、拒答与成本分母、三类保留失败，以及 SHA-256 固定的可重放结果工件。
Reusable projects
关联可复用项目
本文已经进入以下工程项目；项目页提供固定版本、运行命令和结果工件。
- 已独立复现
本文在 24 条多租户查询上比较固定单次检索与自适应状态机，验证 ACL、预算、答案决策和单位 accepted 成本。
Source ledger
来源账本
以下来源用于核对事实、日期与当时可用范围。厂商自报性能不视为本站独立复现。
讨论