AI 推理预算架构：Test-Time Compute / Verifier Cascade / Reasoning Budget

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_REASONING_BUDGET_TEST_TIME_COMPUTE_VERIFIER_CASCADE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

Date: 2026-06-30
Status: evergreen
Audience: experienced CBAP / 金融零售 AI 产品与架构从业者 / AI governance lead

---

核心导读

Reasoning budget 是运行时策略：系统在面对不同业务价值、客户影响、证据缺口、监管风险和时延约束时，决定是快速回答、检索证据、深度拆解、调用工具、运行 verifier、拒答，还是升级人工。Test-time compute 不是“让模型多想一会儿”，而是成本、质量、权限、证据和治理之间的动态资源分配。

金融零售里的关键问题不是“多花 tokens 会不会更聪明”，而是简单 FAQ、内部摘要、信贷解释、AML narrative、KYC 异常、支付争议和监管投诉根因是否应该走同一条推理路径。Reasoning budget 把请求分类、证据需求、工具权限、verifier cascade、人工门禁、成本上限和时延 SLO 放进同一套 runtime policy；系统价值来自让推理强度和客户影响、监管暴露、事实缺口相称。

架构取舍在 fast path、evidence path、deliberation path 和 controlled decision path 之间展开。低风险请求需要稳定、便宜、低延迟；证据型请求需要检索来源和 citation verifier；复杂分析需要拆解、计算、交叉检查和不确定性表达；高影响场景需要 rule engine、独立 verifier、abstention、人工审批和可追溯 disposition。更多计算不等于更多权限，高预算也不等于自动决策。

评估证据要证明预算策略本身有效：tier classifier 是否把高风险请求正确升级，RAG 和工具调用是否真的降低 unsupported claim，verifier 是否校准，人工门禁是否捕获关键失败，成本/延迟是否在 SLO 内，事故后能否重放 budget decision、source ids、tool outputs、model config、output hash、approval event 和 final disposition。控制边界同样明确：隐藏推理草稿不是审计证据，不应暴露给客户或坐席；审计需要可复现的外部证据和决策记录，而不是模型内部思维过程。

问题定义

AI 产品上线后，最贵的不是单次模型调用，而是把所有问题都当成同一种问题处理。简单 FAQ、低风险摘要、高风险授信解释、AML case narrative、支付争议判断和监管投诉根因分析，不应该共享同一条推理路径、同一延迟预算、同一审计证据、同一人工复核策略。

Reasoning budget 指系统在运行时愿意为一次任务投入多少 deliberation resource：tokens、samples、retrieval passes、tool calls、verifier checks、human review time、queue priority 和 audit evidence capture。它的目标不是最大化推理长度，而是让推理强度与业务风险相称。

本文不重复 CoT、self-consistency、process supervision、LLM-as-judge 或 prompt optimization 的基础介绍。这里关注企业如何把推理能力设计成可运营、可审计、可控成本的系统能力。

架构模型/核心原理

flowchart TB
  A[Business request] --> B[Risk and complexity classifier]
  B --> C{Budget tier}

  C -->|Tier 0 Fast path| F0[Direct response with schema checks]
  C -->|Tier 1 Evidence path| F1[RAG + grounded answer]
  C -->|Tier 2 Deliberation path| F2[Plan -> solve -> check loop]
  C -->|Tier 3 Controlled decision path| F3[Decompose + tools + verifier cascade + human gate]

  F0 --> V0[Safety and format check]
  F1 --> V1[Citation support verifier]
  F2 --> V2[Consistency, policy and calculation verifier]
  F3 --> V3[Independent verifier + rule engine + SME review]

  V0 --> D{Deliver, abstain, or escalate}
  V1 --> D
  V2 --> D
  V3 --> D

  D --> E[Customer or analyst output]
  D --> G[Runtime evidence packet]

  G --> H[Trace spans, source ids, policy versions]
  G --> I[Verifier results, risk score, abstention reason]
  G --> J[Human review action, final disposition]

架构图表达的是控制路径, 不是模型内部实现。企业不需要知道模型内部到底如何推理, 也不应该要求模型暴露 hidden chain-of-thought。企业能控制的是外部运行时: 是否检索证据、是否拆任务、是否调用工具、是否多次生成、是否运行 verifier、是否要求人工审批、是否记录证据。

---

核心架构模型

1. Request intake and risk classification

每次 AI run 先进入 request intake, 识别:

风险分类器不必一开始就复杂。成熟做法是把规则、用例台账和模型分类结合:

budget_tier = f(use_case, action_type, customer_impact, uncertainty, data_sensitivity, user_role, channel_slo)

2. Budget tiering

预算不是“越多越好”。高预算可能带来更长延迟、更高成本、更多表面合理化、更多隐私暴露面和更复杂的证据管理。关键是把预算和风险相称。

3. Decomposition and planner/solver/checker loop

复杂任务不要把所有要求塞进一个 prompt。推荐拆成三个角色, 但不要求一定是三个模型:

示例: 支付争议 reasoning。

Planner:
1. 识别 dispute reason code.
2. 检查交易状态、授权方式、3DS/AVS/CVV 结果、merchant evidence.
3. 检查客户争议窗口和法规/卡组织时限.
4. 判断是否需要临时贷记、补件或人工审查.

Solver:
根据检索到的交易数据和政策版本生成建议处置。

Checker:
验证时限、金额、原因码、客户通知模板、证据引用和禁用话术。

4. Abstention and escalation

推理预算体系必须承认“不能答”和“不能自动决定”是正常产出。

5. Hidden vs exposed rationale

企业系统应区分三类材料:

审计要的是可复现证据, 不是模型的完整思维过程。可复现证据包括: 输入摘要、检索来源、工具结果、规则版本、模型配置、输出哈希、verifier 分数、人工审批记录、最终业务处置。

---

关键机制

Policy 1: Risk-proportional compute

Policy 2: Budget cannot override authority

更多推理 token 不等于更多权限。系统即使很“自信”, 也不能绕过:

• 信贷拒绝、降额、冻结账户等 customer-impacting action 的授权流程。
• AML/SAR 的法定流程和合规复核。
• 支付争议的时限、通知和客户权利要求。
• 投诉处置的监管分类、根因编码和整改流程。

Policy 3: Budget escalation requires evidence

从 Tier 1 升到 Tier 2 或 Tier 3, 必须记录触发原因:

Policy 4: Stop conditions

系统需要明确何时停止继续消耗 test-time compute:

Policy 5: Budget ownership

---

Verifier cascade and evidence design

Verifier cascade 是把多个低耦合校验器按成本、确定性和风险影响排序。目标不是让某个 judge “裁判一切”, 而是用便宜、确定、可解释的检查先拦截明显问题, 再把复杂判断交给更昂贵的模型、规则或人工。

Cascade pattern

Evidence object design

建议每次 high-impact run 生成 reasoning_budget_evidence 对象:

不要把 hidden chain-of-thought 放进这个对象。需要记录的是控制结果和证据链接。

---

证据与控制

Product and operations metrics

Control metrics

Evidence model aligned to observability

OpenTelemetry 的 trace/span 思路可以映射到 AI reasoning workflow:

root span: ai.reasoning.run
  span: ai.budget.classify
  span: ai.context.retrieve
  span: ai.plan.create
  span: ai.solve.generate
  span: ai.tool.calculate
  span: ai.verify.citation
  span: ai.verify.policy
  span: ai.escalate.human
  span: ai.output.deliver

关键属性:

---

金融零售/AI产品场景

1. AML investigations

AML copilot 的高价值不是“自动判定可疑”, 而是减少 analyst 搜集材料和起草 narrative 的时间。

关键控制: AI 不应把“看起来可疑”的语言变成事实断言。叙述必须区分 observed facts, policy indicators, analyst judgment。

2. Credit policy reasoning

信贷场景的 reasoning budget 要保护公平性、可解释性和授权边界。

关键控制: AI 不能生成未经验证的不利行动原因, 不能使用禁止变量或 proxy reasoning, 不能把内部推理作为客户解释。

3. Payment dispute reasoning

支付争议需要在客户体验、卡组织规则、监管时限和损失控制之间平衡。

关键控制: 若证据不足, 系统应要求补件或升级, 而不是为了给出答案而猜测。

4. Complaints root-cause analysis

投诉 RCA 适合 test-time compute, 因为它通常需要跨渠道、跨系统、跨政策的证据拼接。

关键控制: 区分 customer allegation, confirmed fact, business error, systemic root cause, remediation action。

5. Contact center policy QA

Contact center 需要低延迟, 但不能牺牲政策准确性。

关键控制: 对话中不要展示内部推理。坐席需要的是可读话术、来源、限制和下一步。

---

反模式

---

最终心智模型

把 reasoning budget 放在 AI platform 的 runtime policy layer，而不是让每个应用团队靠 prompt retry 自行处理。平台应提供 budget classifier、orchestration contract、verifier registry、tool permission model、OpenTelemetry instrumentation 和 evidence store；每个 use case 注册 risk tier、SLO、allowed tools、verifier cascade、human gate 和 retention policy。

最终判断标准：更多 token 不等于更多权限，高预算也不等于自动决策。低风险走 fast path，证据型问题走 RAG 和引用校验，高影响场景走拆解、确定性工具、verifier cascade、abstention 和人工门禁。审计需要的是 source ids、policy versions、tool outputs、verifier results、model config hash、output hash、human approval 和 final disposition，而不是模型内部草稿。

Source Anchors

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。