Chain-of-Thought / Self-Consistency 与推理型 AI 产品解读

Source anchors

• Chain-of-Thought Prompting paper: Chain-of-Thought Prompting Elicits Reasoning in Large Language Models
• Self-Consistency paper: Self-Consistency Improves Chain of Thought Reasoning in Language Models
• Zero-shot CoT related anchor: Large Language Models are Zero-Shot Reasoners
• Test-time compute related reading: Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters

1-page executive summary

• Chain-of-Thought, 简称 CoT, 不是让模型变成真正会思考的人, 而是用 intermediate reasoning steps 帮助大模型处理多步问题.
• CoT 论文的核心发现是: 当模型规模足够大时, few-shot examples 中展示推理步骤, 可以显著提升算术, 常识, 符号推理等复杂任务表现.
• Few-shot CoT 的产品含义是: 示例不只告诉模型最终答案格式, 还告诉模型如何拆问题, 连接条件, 排除错误路径, 形成结论.
• Zero-shot CoT 说明某些大模型可以被简单的 step-by-step 指令激活推理模式, 但它不是可靠性保证, 也不是上线策略.
• Self-consistency 的核心思想是: 采样多条 reasoning paths, 再聚合 final answers, 通常用 majority vote 或 answer aggregation 提升稳定性.
• CoT 改善的是单条推理路径的展开质量, self-consistency 改善的是多条推理路径的鲁棒性.
• 两者都不能保证事实正确, 不能替代 RAG, 规则引擎, 工具计算, 审计日志和人工复核.
• 对 PM 来说, 关键问题是哪些任务值得为更高 reasoning quality 支付额外成本和等待时间.
• 对 BA 来说, 关键问题是如何把复杂业务判断拆成输入字段, 规则条件, 证据要求, 例外路径和验收样例.
• 对架构师来说, 关键问题是如何把模型推理放进可观测, 可治理, 可审计的系统边界.
• Internal reasoning traces 和 user-facing explanation 必须强区分.
• Internal reasoning traces 是模型或系统为了得到答案产生的私有运行材料, 可能包含草稿, 错误分支, 安全策略和未验证推测.
• User-facing explanation 应该是简洁 rationale, 可验证 evidence, 引用来源, 决策规则, 不确定性和下一步行动.
• 不应要求模型向最终用户透露 hidden chain-of-thought.
• 在金融零售中, 审计证据应来自 inputs, retrieved sources, tool outputs, policy versions, decision records and reviewer actions, 而不是模型私有推理文本.
• CoT/self-consistency 可以看作理解 modern reasoning models 和 test-time compute 的历史入口.
• 但不能据此声称任何现代 reasoning model 的内部实现就是公开 CoT, self-consistency, tree search 或某种固定算法.
• 更稳妥的说法是: 产品系统可以在推理阶段通过外部编排增加 test-time compute, 例如多样本生成, 工具校验, evidence retrieval 和人工复核.
• 金融零售适用场景包括 AML typology reasoning, payment exception diagnosis, lending policy explanation, customer complaint RCA, regulatory impact analysis.
• 本笔记的核心结论是: 推理能力是产品能力和系统能力, 不只是模型能力.

读这组论文的目标

PM 要学到的是: CoT 和 self-consistency 不是 prompt 小技巧, 而是复杂任务产品质量的设计变量. 低风险文案任务可以 fast path, 高风险判断任务需要 evidence, eval, audit and escalation.

BA 要学到的是: 需求不能只写 "AI 判断是否可疑" 或 "AI 解释拒贷原因". BA 必须把判断拆成事实字段, 规则条件, 证据来源, 例外路径, 人工复核点和用户解释模板.

架构师要学到的是: reasoning 不是一次 API call 的私事, 而是运行时策略. 架构要决定是否检索证据, 是否调用工具, 是否多次采样, 是否启用 verifier, 是否进入人工审批, 是否保存审计记录.

三类角色的共同目标是: 让 AI 不是 "说得像对", 而是 "结论有证据, 解释可验证, 风险可升级, 过程可治理".

Problem: answer-only prompting 对复杂任务不够

传统 prompt 往往要求模型直接给 final answer. 这种方式适合摘要, 改写, 简单分类和低风险问答.

复杂业务任务不是一步完成. 一个 AML analyst 判断交易是否可疑, 需要识别交易模式, 比较客户画像, 检查地理风险, 查看历史行为, 关联制裁和 PEP 数据, 再决定是否升级.

如果模型直接输出 "可疑" 或 "不可疑", 团队很难判断它是否遗漏了关键条件. 更危险的是, 模型可能给出流畅答案, 但中间逻辑并不稳健.

CoT 的动机可以理解为: 让模型在得到答案前先处理子问题. 但产品目标不是展示全部中间 token, 而是提升系统的 reasoning discipline 并输出可验证解释.

flowchart LR
    A[User question] --> B1[Direct answer]
    B1 --> C1[Fast but fragile]
    A --> B2[Decompose task]
    B2 --> B3[Reason over conditions]
    B3 --> B4[Check evidence]
    B4 --> C2[Answer with concise rationale]

CoT core idea

Chain-of-Thought Prompting 的基本做法是: 在 few-shot examples 中, 不只给 question 和 answer, 还给中间推理步骤.

论文展示的关键现象是: 当模型足够大时, 这种 intermediate reasoning 可以显著提升多步推理表现. 模型较小时, CoT 未必有效.

这说明 CoT 不是简单模板填空, 而是在大模型已有能力中激活 decomposition and sequential inference.

为什么 intermediate reasoning 有帮助:

• 把复杂问题拆成更小的子问题.
• 减少一次性跨越太多逻辑步骤的压力.
• 在上下文中保留已计算或已判断的中间状态.
• 给模型更多 token budget 去展开条件匹配.
• 让 few-shot examples 同时传达任务格式和解题策略.

重要边界: 中间推理文本不是事实本身. 模型写出的 reasoning 可能是辅助推理, 也可能是事后合理化. 企业系统不能把它当成证据.

Few-shot CoT

Few-shot CoT 的样例通常包含 question, reasoning steps, answer. 模型看到这些示例后, 更倾向于对新问题也进行多步展开.

对 PM/BA 来说, few-shot examples 是 product behavior specification. 它们不只是 demo, 而是在定义模型如何拆问题, 哪些证据优先, 哪些边界不能越过.

例如贷款政策解释, 示例可以只展示最终拒绝原因, 也可以展示如何检查收入, 负债率, 信用记录, 产品适配性和例外政策. 后者更接近复杂业务判断.

样例质量非常关键. 如果样例把推测写成事实, 模型会模仿. 如果样例忽略合规边界, 模型会把忽略边界当成正常路径.

企业应由 BA, domain expert, risk, compliance and model owner 共同维护 high-quality examples.

Zero-shot CoT

Zero-shot CoT 的经典发现是: 在某些任务上, 即使没有 few-shot examples, 只要求模型 step-by-step, 也可能提升表现.

产品上不能把它理解成 "加一句 step-by-step 就可靠". 不同模型, 任务, 语言, 领域和风险等级下效果不同.

它还可能增加冗长输出, 并不一定增加事实正确性. 在用户界面中展示完整思路, 还可能暴露不该展示的内部推理或安全策略.

更稳妥的设计是: 内部允许模型进行推理, 对外只输出 concise explanation, evidence, assumptions and limitations.

Self-consistency core idea

Self-consistency 论文针对的问题是: 单条 CoT path 可能因为早期一步错而走偏. 一次生成的 final answer 可能高度依赖采样偶然性.

Self-consistency 采样多条 reasoning paths, 再从 final answers 中选出更一致的答案. 在很多推理任务中, 多条不同路径如果汇聚到同一答案, 这个答案更稳定.

这类似让多个 analyst 独立判断后看结论是否收敛, 但类比不能过度. 多次采样仍来自同一个模型, 共享训练偏差, 知识缺口和 prompt 上下文.

flowchart TB
    Q[Question] --> S1[Reasoning path 1]
    Q --> S2[Reasoning path 2]
    Q --> S3[Reasoning path 3]
    Q --> S4[Reasoning path N]
    S1 --> A1[Answer A]
    S2 --> A2[Answer B]
    S3 --> A3[Answer A]
    S4 --> A4[Answer A]
    A1 --> V[Aggregate answers]
    A2 --> V
    A3 --> V
    A4 --> V
    V --> F[Final answer plus confidence signal]

Why self-consistency works

复杂推理有多条可能路径. 单一路径会放大局部错误, 多路径采样可以覆盖更多 latent reasoning space.

当不同路径用不同方式到达同一答案时, 聚合答案通常更稳健. 对产品来说, 多样化路径可以降低一次回答的偶然性.

聚合不能粗暴. 数字答案可以 majority vote, 开放文本需要 semantic equivalence, 业务动作还要看风险等级和人工复核规则.

如果少数路径指出严重合规风险, 即使多数路径认为低风险, 系统也可能需要升级. 在监管和风控场景中, minority risk signal 不能被多数票自动删除.

Benefits and limits

CoT 的收益是提升复杂任务的可分解性. 它有助于多条件, 多步骤, 多约束问题, 也能让样例库承载更多业务判断模式.

Self-consistency 的收益是提升稳定性. 它可以降低单次采样的偶然错误, 并输出 disagreement signal, 例如 8 条路径中 5 条认为 A, 3 条认为 B.

这种分歧本身是产品信号. 在高风险业务中, 分歧可以触发人工复核, 而不是强行给出确定答案.

CoT 的限制是: 模型可以生成流畅但错误的中间推理, 也可以先猜答案再编造 rationale.

Self-consistency 的限制是: 如果错误来自系统性偏差或错误前提, 多次采样会重复错误.

两者都会增加成本和 latency. CoT 增加输出 tokens, self-consistency 增加调用次数和聚合复杂度.

两者还会增加隐私和安全风险. 中间 reasoning 可能包含敏感字段, 内部政策, 错误推测或不该展示的判断.

Relation to modern reasoning models and test-time compute

CoT 和 self-consistency 是理解 modern reasoning AI 的重要历史入口. 它们共同说明: 生成最终答案前投入更多推理计算, 可能提升复杂任务质量.

这与 test-time compute 的产品直觉一致. Test-time compute 指推理阶段投入更多计算资源, 例如更长思考, 多次采样, 搜索, 反思, 工具调用, verifier 检查或其他策略.

产品上可以把它理解为 quality-latency-cost tradeoff. 低风险任务走 fast path, 高价值或高风险任务走 slow path.

但不能从公开论文直接推断任何商业 reasoning model 的内部实现. 除非供应商正式披露, 架构文档不应声称某模型内部使用 CoT 或 self-consistency.

更可靠的表述是: 我们的系统在推理阶段通过外部编排增加 test-time compute, 例如多样本生成, 工具校验, evidence retrieval and human review.

Internal reasoning traces vs user-facing explanation

Internal reasoning traces 是模型或系统为了得到答案而产生的中间推理材料. 它们可能包含草稿, 假设, 错误分支, 安全策略, 敏感字段和未验证推测.

User-facing explanation 是给用户看的解释. 它应该简洁, 可验证, 与证据绑定, 区分事实和判断, 标明不确定性, 并说明下一步.

Internal reasoning traces 不等于 evidence. 模型说 "因为客户交易异常所以可疑" 不是证据. 交易时间, 金额, 对手方, 地理位置, 历史行为, 筛查结果, 政策条款和 reviewer notes 才是证据.

flowchart LR
    I[Internal reasoning traces] --> P[Private system boundary]
    E[Verifiable evidence] --> D[Decision record]
    R[Rules and policy versions] --> D
    P --> D
    D --> U[User-facing explanation]
    P -. not exposed by default .-> X[Do not reveal hidden chain-of-thought]

可以暴露给用户的是: final answer, concise rationale, key evidence, assumptions, confidence or uncertainty, cited sources, policy basis, next actions and appeal path.

不应默认暴露的是: hidden chain-of-thought, full private traces, raw scratchpad, prompt internals, safety policy internals, unrelated sensitive data, speculative branches and tool credentials.

Product pattern: fast path and slow path

推理型 AI 产品可以按风险分层. Fast path 用于低风险, 低价值, 可逆任务, 例如 FAQ 改写, 客服邮件草稿, 会议摘要.

Evidence path 用于中风险任务, 需要检索证据并输出结构化解释, 例如支付状态查询, 产品条款问答, 内部政策摘要.

Slow path 用于高风险, 高价值, 多步骤任务, 例如 AML alert triage, lending policy interpretation, regulatory impact analysis. 它可以启用 retrieval, self-consistency, verifier, tool calculation, policy check and HITL.

flowchart TB
    T[Incoming task] --> R{Risk and value}
    R -->|Low| F[Fast path]
    R -->|Medium| M[Evidence path]
    R -->|High| S[Slow path]
    F --> O[Response]
    M --> O
    S --> O
    S --> A[Audit package]

Eval design

Eval 不能只看最终答案是否好看. 复杂 reasoning 产品至少需要五层 eval.

• Final answer accuracy: 最终结论是否正确.
• Evidence grounding: 结论是否被正确证据支持.
• Rule adherence: 是否正确应用业务规则, 政策版本和监管要求.
• Explanation quality: 对用户或 analyst 的解释是否简洁, 准确, 不夸大, 不泄露私有推理.
• Escalation behavior: 在证据不足, 分歧较大, 风险较高时, 系统是否正确升级人工.

Self-consistency 还要评估 sample count 下的准确率, 成本, latency, disagreement rate, aggregation error, minority risk handling and answer normalization.

flowchart LR
    DS[Golden dataset] --> FA[Final answer eval]
    DS --> EG[Evidence grounding eval]
    DS --> RA[Rule adherence eval]
    DS --> EQ[Explanation quality eval]
    DS --> EB[Escalation eval]
    FA --> G[Release gate]
    EG --> G
    RA --> G
    EQ --> G
    EB --> G

Cost, latency and audit

如果 self-consistency 采样 5 条 paths, 成本可能接近单次调用的 5 倍, 还可能增加 aggregation 调用. 并行采样降低等待时间, 但增加并发和成本峰值.

成本优化不应只做模型降级. 还可以做任务路由, 缓存, 结构化输入, 规则前置, 工具计算, 样本数自适应和早停策略.

审计证据应围绕可验证事实. 一个 decision record 至少包括 user request, input snapshot, data source IDs, retrieved documents, tool outputs, policy version, model version, prompt version, final answer, user-facing explanation, risk score, escalation decision and reviewer action.

如果使用 self-consistency, 可以记录 aggregate statistics, 例如 sample count, answer distribution, disagreement rate, selected answer and escalation threshold.

是否保存完整 hidden reasoning traces 要谨慎. 很多场景下, 保存完整私有推理会增加隐私, 安全和数据保留风险. 更好的默认是保存 structured audit fields and evidence references.

Hallucinated rationale risk

Hallucinated rationale 指模型给出看似合理但不真实的解释. 它比普通事实错误更危险, 因为用户可能把解释当成真实决策过程.

例如模型说 "拒贷原因是负债率过高", 但真实系统原因是收入验证失败. 这种解释会影响客户权益和监管审查.

再如模型说 "付款失败是收款银行拒绝", 但真实原因是内部风控 hold. 这种解释会误导客服和客户.

治理方法包括: explanation grounded in decision record, cite exact evidence fields, restrict explanation vocabulary, separate facts from inference, use policy templates, and evaluate explanation faithfulness.

Financial retail example 1: AML typology reasoning

场景: 系统辅助 AML analyst 判断交易是否符合 structuring, mule account, rapid movement, high-risk corridor 等 typology.

内部 reasoning 可以帮助模型按 typology 拆解模式, 但 analyst 界面应展示触发证据, 规则匹配, 反证, 不确定性和建议动作, 不展示完整 hidden chain-of-thought.

用户侧解释示例: "该 alert 与 rapid movement typology 部分匹配: 24 小时内收到 6 笔入账并向 4 个新收款人转出 92%. 未发现制裁命中. 建议升级 enhanced review."

Eval 应覆盖 typology match accuracy, false positive reduction, missed suspicious pattern, evidence citation and escalation quality. Self-consistency 可用于高风险 alert, 分歧大时升级人工.

Financial retail example 2: payment exception diagnosis

场景: 客户付款失败, 系统要帮助客服定位原因. 可能原因包括余额不足, limit exceeded, sanctions hold, account status issue, beneficiary bank rejection, network timeout, duplicate payment, cut-off time miss.

更好的架构是先调用 payment logs, core banking status, risk engine result, network response code and customer profile. 解释应来自日志和状态码, 不来自模型猜测.

解释示例: "该付款未发送至清算网络. 失败发生在内部风控检查阶段, 原因代码 RF-214: 新收款人高额转账需二次验证. 建议客户在 app 中完成确认."

这种场景中确定性日志通常比 self-consistency 更重要. 多路径诊断只能用于生成候选原因, 最终必须由 verifier 检查证据.

Financial retail example 3: lending policy explanation

场景: 客户申请贷款被拒, 需要给出合规, 清晰, 可申诉的解释. 拒贷原因必须来自 underwriting decision record.

CoT 可用于内部 policy mapping, 例如把复杂政策条款映射到解释原因. 但用户-facing explanation 必须绑定真实 decision codes.

解释示例: "本次申请未通过的主要原因是: 最近 90 天可验证收入不足以支持申请额度; 当前债务收入比高于本产品政策上限. 你可以补充收入证明或降低申请额度后重新申请."

Eval 应包括 fair lending consistency, adverse action reason correctness, policy version match, explanation readability and appeal path completeness.

Financial retail example 4: customer complaint root-cause analysis

场景: 客户投诉 "银行乱扣费", 系统辅助投诉团队定位根因. 输入包括交易, fee schedule, communication, product terms, branch notes, prior complaints and regulatory SLA.

CoT 的价值是把投诉拆成事实线, 合同线, 操作线, 沟通线和补救线. 输出应分为 confirmed facts, pending checks, preliminary root cause, recommended remedy and SLA risk.

解释示例: "已确认 5 月 12 日扣费 15 美元来自账户维护费. 根据当期产品条款, 若月均余额低于 500 美元则收取该费用. 仍需核实开户时是否已正确告知费用豁免条件."

这个解释区分事实和待核实事项, 不把模型推测写成最终结论.

Financial retail example 5: regulatory impact analysis

场景: 新监管规则发布后, AI 辅助 BA 和架构师评估对产品, 流程, 数据和系统的影响.

系统应先拆成 obligations, affected products, impacted processes, data requirements, control changes, customer communication, reporting and timeline.

输出应是结构化 impact assessment, 包含引用条款和证据. 示例: "Section 4.2 要求在付款失败后 1 business day 内提供原因说明. 当前异常处理流程在 T+2 才生成客户通知, 因此 payment exception workflow 需要调整."

Self-consistency 可用于发现遗漏影响点. 如果少数路径指出 data retention impact, 即使不是多数, 也应进入 legal review checklist.

Architecture pattern

企业级 reasoning workflow 可以拆成 task router, evidence retriever, policy engine, model reasoner, self-consistency sampler, verifier, explanation generator and audit logger.

flowchart LR
    TR[Task router] --> ER[Evidence retriever]
    ER --> PE[Policy engine]
    PE --> MR[Model reasoner]
    MR --> SC{Need self-consistency?}
    SC -->|Yes| MS[Multi-sample candidates]
    SC -->|No| VR[Verifier]
    MS --> AG[Answer aggregation]
    AG --> VR
    VR --> EX[User-facing explanation]
    VR --> AU[Audit logger]
    EX --> OUT[Response or analyst workbench]

架构原则: 不要让模型直接访问全部业务系统; 通过 tool gateway, permission layer and policy engine 控制动作; 用 schema validation 和 evidence-grounding check 控制输出; 高风险动作必须 HITL 或 dual control.

Design checklist for PM

• 明确任务是否需要推理, 还是只需要检索, 分类或改写.
• 定义 fast path, evidence path, slow path.
• 定义用户需要看到的 explanation, evidence and next action.
• 定义哪些内部材料不能展示给用户.
• 定义成本和 latency 预算.
• 定义分歧时的体验, 例如 "需要人工复核" 而不是强答.
• 定义业务指标和风险指标, 例如 accuracy, handling time, hallucinated rationale rate, unsupported claim rate.

Design checklist for BA

• 把业务判断拆成事实字段, 规则条件, 例外条件, 反证条件和结论类型.
• 为每类结论定义可接受证据.
• 为解释模板定义允许表达和禁止表达.
• 为高风险场景定义人工复核点.
• 为 eval 准备 golden cases, edge cases, adversarial cases and policy-change cases.
• 确保样例覆盖 "证据不足" 和 "需要澄清".
• 把 internal reasoning 与 audit evidence 分开建模.

Design checklist for architect

• 将证据检索, 推理, 校验, 解释和审计拆成独立组件.
• 对 self-consistency 设置 sample count, timeout, budget and escalation threshold.
• 记录 model version, prompt version, policy version and data snapshot.
• 对 prompt injection, data leakage, inconsistent explanations and overconfident answers 建立监控.
• 对高风险动作使用 HITL 或 dual control.
• 默认保存 structured audit fields, 谨慎保存完整 hidden traces.

Interview questions

1. 什么是 Chain-of-Thought Prompting, 它解决了什么问题?
2. Few-shot CoT 和普通 few-shot prompting 的差异是什么?
3. Zero-shot CoT 的产品启发是什么, 为什么不能把它当成可靠性保证?
4. Self-consistency 如何改进单条 CoT path 的不稳定性?
5. Self-consistency 的 majority vote 在金融风控场景中有什么风险?
6. Internal reasoning traces 和 user-facing explanation 有什么区别?
7. 为什么不应要求模型向最终用户展示 hidden chain-of-thought?
8. 什么是 hallucinated rationale, 为什么它比普通幻觉更危险?
9. 如果要在 AML alert triage 中使用 reasoning AI, 如何设计 evidence 和 audit?
10. Payment exception diagnosis 已有确定性日志时, self-consistency 的价值和限制是什么?
11. 贷款拒绝解释为什么必须绑定 underwriting decision codes?
12. 推理型 AI 的 eval 为什么不能只看最终答案?
13. 如何评估 explanation faithfulness?
14. Test-time compute 和产品成本之间如何权衡?
15. 现代 reasoning models 与 CoT/self-consistency 有什么关系, 哪些说法是不应声称的?

Misconceptions

• 误解: CoT 就是让模型把所有思考过程展示给用户. 更准确: CoT 是提升复杂推理的机制, 用户界面应展示简洁解释和可验证证据.
• 误解: 模型写出的推理步骤就是它真实的内部原因. 更准确: 生成文本可能是推理辅助, 也可能是事后合理化.
• 误解: Self-consistency 多数票一定正确. 更准确: 多数票可以降低偶然错误, 但不能消除系统性偏差和错误前提.
• 误解: 多生成几条 reasoning paths 就等于多人审核. 更准确: 多路径采样仍来自同一模型和同一上下文.
• 误解: 更长解释代表更可靠. 更准确: 好解释应该短, 准, 可验证, 有证据.
• 误解: CoT 可以替代 RAG 或业务规则. 更准确: CoT 组织推理, RAG 提供证据, 规则系统提供治理边界.
• 误解: Reasoning model 的内部一定就是公开 CoT. 更准确: 外部行为不等于内部实现, 未披露机制不应被断言.

Practical exercises

1. 为 AML typology reasoning 设计 eval set, 覆盖正常客户, structuring, mule account, rapid movement, high-risk corridor, false positive and insufficient evidence cases.
2. 为 payment exception diagnosis 设计 fast path 和 slow path, 标注哪些错误代码可直接解释, 哪些状态冲突必须调用更多工具.
3. 为 lending policy explanation 写 5 个用户可见解释模板, 每个模板绑定 decision code, evidence field, appeal path and prohibited wording.
4. 设计 self-consistency aggregation policy, 包含 sample count, answer normalization, majority threshold, high-risk minority handling, timeout and fallback.
5. 设计 hallucinated rationale eval, 输入真实 decision record 和模型解释, 判断每个 claim 是否被证据支持.
6. 把 regulatory impact analysis 拆成 structured output schema, 字段包括 obligation, affected product, impacted process, impacted system, data requirement, citation, confidence and owner.
7. 写 PM one-pager: 是否在客户投诉 RCA 中启用 slow reasoning path, 必须包含 user value, operational value, risk, latency, cost, audit evidence and rollout metric.
8. 写 architecture ADR: internal reasoning traces 是否保存, 比较完整 traces, 结构化摘要, evidence references 三种方案.

Mini case: disagreement as product signal

假设一个 regulatory impact task 采样 7 条 reasoning paths: 4 条认为只影响 customer notification, 2 条认为还影响 data retention, 1 条认为影响 vendor reporting.

如果使用简单多数票, 系统会只输出 customer notification, 可能漏掉重要监管风险.

更好的聚合策略是: 多数结论作为 primary impact, 少数高风险结论进入 review queue.

用户-facing 输出可以写: "Primary impact appears to be customer notification. Additional potential impacts on data retention and vendor reporting require legal review."

Reasoning AI 的价值不是永远给唯一答案, 而是把复杂不确定性组织成可行动的 review package.

Good explanation vs bad explanation

好的用户解释通常包含 conclusion, supporting facts, policy basis, uncertainty and next action.

好例子: "该付款目前处于二次验证等待状态, 尚未发送到收款银行. 原因是新收款人首次高额转账触发规则 RF-214. 你已完成短信验证, 还需要在 app 中确认本次付款."

差例子 1: "我检查后怀疑你可能有风险, 所以我决定阻止付款." 问题是拟人化, 暴露内部判断, 且没有可验证证据.

差例子 2: "系统认为这笔付款有风险." 问题是没有状态, 规则, 证据和下一步.

差例子 3: "收款银行拒绝了付款." 如果真实日志不是这样, 这是 hallucinated rationale.

Release readiness checklist

• 是否有任务分层: fast path, evidence path, slow path.
• 是否有 golden eval set 和高风险 edge cases.
• 是否有 evidence grounding eval 和 explanation faithfulness eval.
• 是否定义 self-consistency sample count and aggregation policy.
• 是否定义分歧和证据不足时的 escalation.
• 是否区分 internal reasoning traces and user-facing explanation.
• 是否禁止向客户暴露 hidden chain-of-thought.
• 是否记录 model, prompt, policy and data versions.
• 是否有成本, latency and quality dashboard.
• 是否有人工复核 workflow 和错误反馈闭环.

Key takeaways

CoT 的核心价值是帮助模型处理多步问题.

Self-consistency 的核心价值是用多路径采样提升复杂推理稳定性.

二者都不是可靠性的完整答案. 可靠的企业 AI 需要 evidence, rules, eval, audit, HITL and governance.

最重要的产品边界是: internal reasoning traces 是私有运行材料, user-facing explanation 是可验证沟通材料.

金融零售 AI 的目标不是让用户看到模型怎么想, 而是让用户, analyst, auditor and regulator 都能看到结论依据是什么, 证据在哪里, 规则版本是什么, 还有哪些不确定性.

这才是 Chain-of-Thought 和 Self-Consistency 对 AI BA / PM / architect 最实际的启发.