LLM 工程决策系列（01/17）

这是「LLM 工程决策系列」的第 1 篇，共 17 篇。
我们不讲技术原理，只讲什么时候值得用，什么时候不值得用。

⚡ 3秒速读：

• 结论： 强推理（o1-style）成本是CoT的5-10x，只在"错了会死人"的场景值得用
• 适用： 医疗诊断、法律审查、金融风控 | 不适用： 客服问答、内容生成、日常对话
• 今天就做： 先用CoT跑100个case，准确率<85%再考虑强推理

---

工程问题：推理能力升级了，但错误也升级了

你的系统从"有用"变成"危险"的那一刻，通常是这样的：

一开始，模型回答不稳定。同样的问题，今天说 A，明天说 B。你让它写出推理过程（CoT），答案看起来更"讲道理"了。

你开始信它了。

然后你发现：它只是把一个错误前提，推理得非常完整。推理链条很长，每一步看起来都对，但结论是错的，而且你第一眼看不出来。

强推理没有减少错误，只是让错误更难被质疑。

关键是：模型会推理，但不会怀疑自己的前提。

---

快速决策表：什么时候该开强推理？

场景类型	是否开强推理	成本	延迟	准确率	为什么
简单问答（FAQ、事实查询）	❌ 不开	1x	1-2s	85-90%	普通模型足够，开强推理浪费
结构化提取（JSON、表单）	❌ 不开	1x	1-2s	90-95%	用 Structured Output 更便宜
复杂规划（多步推理、逻辑链）	✅ 考虑开	2-5x	3-8s	88-92%	强推理有价值，但要控制频率
高风险建议（合同审查、合规）	✅ 必须开	2-5x	5-15s	90-95%	错误成本高，值得付费
评审类任务（代码审查、文档校对）	✅ 考虑开	2-5x	3-10s	88-93%	需要"二次确认"，强推理有价值

判断标准：

• ✅ 错误成本 > 延迟成本 → 开强推理
• ✅ 调用频率低（< 1000次/天）→ 开强推理
• ❌ 高频调用（> 10万次/天）→ 不开强推理
• ❌ 延迟敏感（< 3s）→ 不开强推理

---

📦 最小落地方案（复制即用）

场景：医疗问答系统（准确率要求 >90%）

架构：

用户问题 
  → 先用 CoT 快速判断（2s，成本 1x）
  → 如果置信度 <80%，调用 o1-mini（8s，成本 5x）
  → 返回结果 + 推理过程

成本估算：

• 每天 1 万次调用，80% 走 CoT，20% 走 o1-mini
• 成本：$30/天（纯 CoT）→ $60/天（混合）
• 延迟：平均 3s（80% 是 2s，20% 是 8s）
• 准确率：从 85% 提升到 92%

实现清单：

• 用 GPT-4 + CoT 跑 100 个测试 case，记录准确率
• 找出"CoT 错误但很自信"的 case（这些是强推理的目标）
• 加一个置信度判断逻辑（比如"如果 CoT 输出包含’可能/也许/不确定’，就走强推理"）
• 用 o1-mini 重跑这些 case，对比成本和准确率

风险：

• 风险 1：o1 延迟高（8-30s），用户会等不及 → 加个"正在深度分析"的进度条
• 风险 2：成本翻倍 → 先只在"高风险问题"上用，比如涉及用药、手术的问题

---

为什么"推理更长"，反而更危险？

原因一：推理过程会制造"可信感"

想象你问模型：“Python 3.11 是否依赖 asyncio？”

普通模型的回答：

是的，Python 3.11 依赖 asyncio。

用户会质疑：“真的吗？我去查一下。”

强推理模型的回答：

让我分析一下：
1. Python 3.11 是 Python 的最新版本
2. asyncio 是 Python 的标准库
3. 标准库是 Python 的一部分
4. 因此，Python 3.11 包含 asyncio
5. 所以，Python 3.11 依赖 asyncio

用户会想：“推理过程这么完整，应该是对的。”

但实际上： 步骤 1-4 都是对的，步骤 5 是错的（“包含"不等于"依赖”），结论是错的。

原因二：中间步骤无法验证

假设你问模型：“如果 A 依赖 B，B 依赖 C，C 有漏洞，A 是否有风险？”

强推理模型会给出完整的推理链：步骤 1-6 看起来都对。但如果前提 2 是错的（B 实际上不依赖 C），那么整个推理链都是基于错误前提的"正确推理"。

问题是： 模型不会质疑前提 2 是否正确，用户也很难发现（因为推理链太长），系统无法自动验证每个前提。

原因三：系统无法自动发现"错在哪一步"

如果推理链有 20 步，你需要检查 20 个步骤，每个步骤都可能有错误假设。调试时间从 5 分钟变成 50 分钟。

真正危险的不是模型不会推理，而是它推理得太像人。

---

技术选项对比：普通推理 vs CoT vs 强推理

维度	普通推理	CoT	强推理（o1-style）
成本	1x	1.2x	2x-5x
延迟	1-2s	2-3s	3-15s（波动大）
稳定性	高（可预测）	高（可预测）	中（搜索深度不可控）
可验证性	低（黑盒）	中（有推理链）	高（有搜索树）
失败模式	直接错误	推理链断裂	搜索超时/路径爆炸
适用场景	简单问答	中等复杂度	高风险、低频任务

关键区别：

• 普通推理：直接输出答案，快但不可靠
• CoT：显式推理链，可追溯但仍可能错
• 强推理：多路径搜索+验证，更可靠但更贵更慢

---

强推理的三大工程代价（必须量化）

代价 1：成本 2-5x（不是线性增长）

为什么是 2-5x？

强推理的成本不是"多生成一些 token"，而是"多路径搜索 + 验证"：

1. 搜索阶段：生成 3-5 条候选路径（成本 3x-5x）
2. 验证阶段：每条路径都要验证（成本再 ×1.5x）
3. 迭代阶段：根据验证结果再搜索（成本再 ×1.2x-2x）

总成本 = 3x × 1.5x × 1.5x ≈ 6.75x（不是 3x + 1.5x + 1.5x = 6x）

实际案例：

某团队全量开启强推理：

• 日均调用：10 万次
• 普通模型成本：$500/月
• 强推理成本：$500 × 5x = $2,500/月
• 成本增加：$2,000/月

如果只对 10% 的复杂问题开强推理：

• 强推理成本：$500 × 10% × 5x = $250/月
• 普通模型成本：$500 × 90% = $450/月
• 总成本：$700/月（增加 $200/月）

工程结论：选择性开启强推理，成本只增加 40%，而不是 400%。

---

代价 2：延迟 2-4x，且波动更大

为什么延迟波动大？

普通推理的延迟：

• 固定：生成 token 数量 × 生成速度
• 可预测：通常 1-2s

强推理的延迟：

• 不固定：取决于搜索深度（2 层 vs 5 层）
• 不可预测：可能 3s，也可能 15s+

实际数据：

场景	普通推理	CoT	强推理
简单问题	1s	2s	3-5s
中等问题	1.5s	2.5s	5-8s
复杂问题	2s	3s	8-15s+

用户体验影响：

• 1-2s：用户感觉"很快"
• 3-5s：用户感觉"可以接受"
• 8s+：用户感觉"太慢了"，开始放弃

工程结论：强推理的延迟波动会直接影响用户体验，必须设置超时（比如 10s）。

---

代价 3：调试更难（推理过程更长，错误更隐蔽）

为什么调试更难？

普通推理的调试：

输入：用户问题
输出：答案
调试：检查答案是否正确

强推理的调试：

输入：用户问题
搜索：生成 5 条候选路径
验证：每条路径打分
选择：选出最优路径
输出：答案

调试：
1. 为什么生成这 5 条路径？
2. 为什么这条路径得分最高？
3. 为什么其他路径被排除？
4. 答案是否正确？

典型调试场景：

用户反馈：“系统说 Python 3.11 依赖 asyncio，但这是错的”

调试过程：

第 1 步：检查搜索树
- 生成了 5 条候选路径
- 路径 1：Python 3.11 包含 asyncio（正确）
- 路径 2：Python 3.11 依赖 asyncio（错误）
- 路径 3：asyncio 是 Python 3.11 的新特性（正确）
- 路径 4：Python 3.11 升级了 asyncio（正确）
- 路径 5：asyncio 替代了 threading（错误）

第 2 步：检查验证分数
- 路径 1：0.85
- 路径 2：0.92（最高）← 为什么这条得分最高？
- 路径 3：0.80
- 路径 4：0.78
- 路径 5：0.70

第 3 步：检查验证器
- 验证器：GPT-4
- Prompt："Rate the correctness of this reasoning path"
- 问题：为什么验证器给错误路径打了最高分？

第 4 步：尝试修复
- 修改验证器 Prompt
- 重新验证所有路径
- 发现新的错误...

工程结论：强推理的调试时间是普通推理的 3-5x，因为需要检查"搜索树 + 验证器 + 选择逻辑"。

---

强推理的三类"最值"任务

值得 1：多约束规划（时间/预算/步骤）

什么是"多约束规划"？

• 需要同时满足多个约束条件
• 比如：“在 $1000 预算内，3 天内完成，需要 5 个步骤”

为什么强推理有价值？

• 普通推理容易"顾此失彼"（满足预算但超时间）
• 强推理可以"多路径搜索"，找到同时满足所有约束的方案

典型场景：

• 旅行规划：预算 + 时间 + 偏好
• 项目排期：资源 + 时间 + 依赖关系
• 采购决策：价格 + 质量 + 交期

工程结论：多约束规划是强推理的"最佳适用场景"，准确率可从 70% 提升到 90%。

---

值得 2：多跳推理（需要链式）

什么是"多跳推理"？

• 需要多步推理才能得出结论
• 比如：“A 依赖 B，B 依赖 C，所以 A 间接依赖 C”

为什么强推理有价值？

• 普通推理容易"推理链断裂"（推到第 3 步就错了）
• 强推理可以"验证每一步"，确保推理链完整

典型场景：

• 代码依赖分析：库 A → 库 B → 库 C
• 因果推理：事件 A → 事件 B → 事件 C
• 逻辑证明：前提 A → 前提 B → 结论 C

工程结论：多跳推理是强推理的"核心价值"，准确率可从 75% 提升到 88%。

---

值得 3：评审/检查（对输出质量的二次确认）

什么是"评审/检查"？

• 对已有内容进行"二次确认"
• 比如：代码审查、文档校对、合同审查

为什么强推理有价值？

• 普通推理容易"漏掉细节"（只看大框架，不看细节）
• 强推理可以"多角度检查"，发现隐藏问题

典型场景：

• 代码审查：检查逻辑错误、性能问题、安全漏洞
• 文档校对：检查语法错误、逻辑矛盾、事实错误
• 合同审查：检查条款冲突、法律风险、遗漏条款

工程结论：评审/检查是强推理的"高价值场景"，可以发现 80% 的隐藏问题。

---

四阶段演进：从"默认不开"到"自动决定"

第一阶段：默认不开（成本 1x）

策略：

• 所有请求都用普通模型
• 不开强推理

适用场景：

• MVP 阶段
• 成本极度敏感
• 用户对准确率要求不高

工程代价：

• 成本：1x
• 准确率：85-90%
• 延迟：1-2s

---

第二阶段：只对"难题"开（成本 1.2x-1.5x）

策略：

• 用规则识别"难题"（比如问题长度 > 200 字、包含"为什么"、“如何”）
• 只对"难题"开强推理
• 其他请求用普通模型

适用场景：

• 有明确的"难题"特征
• 可以接受 20-50% 成本增加
• 需要提升复杂问题的准确率

工程代价：

• 成本：1x × 80% + 3x × 20% = 1.4x
• 准确率：85% × 80% + 90% × 20% = 86%
• 延迟：1.5s × 80% + 5s × 20% = 2.2s

实施细节：

def should_use_strong_reasoning(query):
    # 规则 1：问题长度 > 200 字
    if len(query) > 200:
        return True
    
    # 规则 2：包含"为什么"、"如何"
    if any(keyword in query for keyword in ["为什么", "如何", "怎么"]):
        return True
    
    # 规则 3：包含"对比"、"区别"
    if any(keyword in query for keyword in ["对比", "区别", "差异"]):
        return True
    
    return False

---

第三阶段：只对"高价值任务"开（成本 1.5x-2x）

策略：

• 用业务规则识别"高价值任务"（比如付费用户、高价值订单）
• 只对"高价值任务"开强推理
• 其他请求用普通模型

适用场景：

• 有明确的"高价值"标准
• 可以接受 50-100% 成本增加
• 需要为高价值用户提供更好的体验

工程代价：

• 成本：1x × 70% + 3x × 30% = 1.9x
• 准确率：85% × 70% + 90% × 30% = 86.5%
• 延迟：1.5s × 70% + 5s × 30% = 2.55s

实施细节：

def should_use_strong_reasoning(user, task):
    # 规则 1：付费用户
    if user.is_premium:
        return True
    
    # 规则 2：高价值订单（> $1000）
    if task.order_value > 1000:
        return True
    
    # 规则 3：关键业务（合同审查、合规检查）
    if task.type in ["contract_review", "compliance_check"]:
        return True
    
    return False

---

第四阶段：加 Eval/回归自动决定开不开（成本 2x-3x）

策略：

• 用 Eval 系统评估每个请求的"难度"和"价值"
• 自动决定是否开强推理
• 持续优化决策模型

适用场景：

• 有完善的 Eval 系统
• 可以接受 2x-3x 成本增加
• 需要最优的"成本-准确率"平衡

工程代价：

• 成本：1x × 50% + 3x × 50% = 2x
• 准确率：85% × 50% + 90% × 50% = 87.5%
• 延迟：1.5s × 50% + 5s × 50% = 3.25s

实施细节：

def should_use_strong_reasoning(query, user, task):
    # 用 Eval 模型预测"难度"和"价值"
    difficulty = eval_model.predict_difficulty(query)
    value = eval_model.predict_value(user, task)
    
    # 决策逻辑：难度高 + 价值高 → 开强推理
    if difficulty > 0.7 and value > 0.8:
        return True
    
    # 难度中等 + 价值高 → 开强推理
    if difficulty > 0.5 and value > 0.9:
        return True
    
    return False

关键：Eval 系统需要持续优化

• 收集"开强推理"vs"不开强推理"的效果数据
• 训练决策模型
• A/B 测试验证效果

---

反面案例：推理很完整，逻辑很顺，结论是错的

某技术团队用强推理做"技术选型建议"：

用户问题：
“我们的系统需要处理 10 万 QPS，应该用 MySQL 还是 MongoDB？”

强推理模型的回答：

让我分析一下：

1. 系统需要处理 10 万 QPS（高并发）
2. MySQL 是关系型数据库，适合事务处理
3. MongoDB 是文档型数据库，适合高并发读写
4. 高并发场景下，MongoDB 的性能通常优于 MySQL
5. 因此，推荐使用 MongoDB

结论：推荐使用 MongoDB

团队采纳了建议，6 个月后系统崩溃。

失败原因解剖：

原因 1：推理很完整，逻辑很顺

• 步骤 1-4 的推理链条完整
• 每一步看起来都有道理
• 结论自然而然地得出

但问题是：

• 步骤 4 是一个"常识性假设"，不是事实
• 实际上，MySQL 和 MongoDB 的性能取决于具体场景
• 模型没有问"你的数据结构是什么？"“你的查询模式是什么？”

原因 2：结论是错的，但人类第一眼看不出来

为什么团队会采纳？

• 推理过程看起来很专业
• 每一步都有依据
• 团队没有深入质疑

实际情况：

• 系统的数据是高度结构化的（适合 MySQL）
• 系统需要复杂的 JOIN 查询（MongoDB 不擅长）
• 系统需要强一致性（MongoDB 的一致性较弱）

如果用 MySQL：

• 性能完全满足需求
• 查询更简单
• 一致性更强

原因 3：模型基于错误前提做了"正确推理"

错误前提：

• “高并发场景下，MongoDB 的性能通常优于 MySQL”

这个前提为什么错？

• 它忽略了"数据结构"和"查询模式"
• 它是一个"过度简化的常识"
• 它在某些场景下是对的，但在这个场景下是错的

模型为什么会有这个前提？

• 训练数据中有大量"MongoDB 适合高并发"的文章
• 模型学到了这个"常识"
• 但模型不会质疑这个"常识"是否适用于当前场景

原因 4：系统无法自动发现"错在哪一步"

如果你想调试这个推理过程：

第 1 步：检查步骤 1 → 正确（10 万 QPS 确实是高并发）
第 2 步：检查步骤 2 → 正确（MySQL 确实适合事务处理）
第 3 步：检查步骤 3 → 正确（MongoDB 确实适合高并发读写）
第 4 步：检查步骤 4 → ？？？（这一步是对还是错？）

问题：步骤 4 是一个"常识性假设"，很难验证。
- 你需要查阅大量资料
- 你需要做性能测试
- 你需要考虑具体场景

结论：调试成本太高，团队直接采纳了建议。

工程结论：

真正危险的不是模型不会推理，而是它推理得太像人。

当推理过程看起来"很专业"时，人类会降低警惕，不再深入质疑。这就是强推理的最大风险。

---

---

工程结论：强推理不是更高阶智能，而是更高风险表达

明确的决策建议

1. 默认不开强推理，只对"高风险任务"开

   • 为什么？推理过程制造"可信感"，让错误更难被质疑
   • 什么时候例外？所有任务都是"高风险"（比如医疗诊断、法律建议）
   • 如果你的任务错误成本不足以覆盖推理风险，这一步不值得做

2. 不要因为"有推理过程"就信任结论

   • 为什么？推理链越长，错误前提越难被发现
   • 什么时候例外？你有完善的 Eval 系统，可以验证每个推理步骤
   • 一旦你把系统建立在"模型会想对"的假设上，失败是必然的

3. 强推理必须配合人工审核或 Eval 系统

   • 为什么？模型不会质疑自己的前提，系统无法自动发现"错在哪一步"
   • 什么时候例外？任务足够简单，推理链足够短（< 3 步）
   • 如果你没有验证机制，强推理只是在放大你不知道的错误

4. 设置超时和成本上限，避免推理失控

   • 为什么？强推理的延迟和成本不可控，可能 15s+ 或 10x 成本
   • 什么时候例外？用户可以接受长延迟和高成本（比如离线分析）
   • 如果错误成本很高，这一步不值得做

反模式警告

⚠️ 不要把强推理当作"默认升级"

• 强推理不是"更聪明"，而是"更会说服你"
• 推理过程制造"可信感"，让用户不再质疑结论
• 如果违反： 你会发现"模型推理得越完整，用户越容易被误导"

⚠️ 不要以为"有推理链"就能调试

• 推理链越长，调试成本越高（需要验证每个步骤）
• 错误前提很难被发现（因为推理过程看起来很对）
• 如果违反： 你会发现"调试时间从 5 分钟变成 50 分钟，但仍然找不到错误"

⚠️ 不要在没有 Eval 的情况下全量开启强推理

• 强推理会放大你不知道的错误
• 没有 Eval，你无法知道哪些推理是对的，哪些是错的
• 如果违反： 你会发现"准确率提升了 3%，但错误更难被发现了"

最后三句话

强推理不是更高阶智能，而是更高风险表达。

一旦你把系统建立在"模型会想对"的假设上，失败是必然的。

如果错误成本很高，这一步不值得做。

---

关键词：强推理 / CoT / o1-style / 推理幻觉 / 错误放大 / 认知陷阱 / 工程边界

---

下一篇预告

下一篇：长上下文的幻觉：看完所有信息 ≠ 理解问题

——我们将讨论什么时候值得用，什么时候不值得用。

---

📚 系列完整规划

篇号	标题	状态
01	强推理不是更聪明，只是错得更完整	👉 当前
02	长上下文的幻觉：看完所有信息 ≠ 理解问题	📅 即将
03	多模态不是能力升级，而是调试灾难的开始	📅 即将
04	当你开始优化推理成本，说明架构已经失败	📅 即将
05	模型对齐不是安全，而是系统里最慢的一层	📅 即将
06-09	RAG 系列（能查 → 查得准 → 自救 → GraphRAG）	📅 即将
10-11	工具与 MCP（Function Calling、MCP）	📅 即将
12-13	Agent 系统（单 Agent → 多 Agent）	📅 即将
14-17	生产系统（LLMOps → Eval → 安全 → 产品）	📅 即将