What is Chain-of-Thought (CoT) prompting, and when is it most useful
1️⃣ 考察意图
面试官想考察的远不止“CoT 就是让模型一步步思考”这个定义。核心是：你是否理解 CoT 的本质是“将隐式推理显式化”，并能在工程中判断何时该用、何时该弃。 这是典型的“背概念 + 工程取舍”混合题。刁钻点在于：CoT 不是万能的，它牺牲 token 成本换取推理精度，且对模型基础能力有门槛（小模型用了反而更差）。答好了，能展示你对 LLM 推理机制（如自回归解码中的注意力分配）和实际部署成本（延迟、吞吐）的深刻理解。
2️⃣ 标准答
Chain-of-Thought (CoT) Prompting 是一种引导大语言模型在输出最终答案前，先生成中间推理步骤的技术。它本质上是把人类解决复杂问题时的“草稿纸”思维，通过 prompt 注入到模型解码过程中。
核心原理与形式
- Few-shot CoT：在 prompt 中提供包含推理步骤的示例（如“Q: 小明有 5 个苹果，吃了 2 个，又买了 3 个，现在有几个？A: 先吃后剩 5-2=3 个，再买 3+3=6 个，答案是 6”），让模型模仿这种“分步走”模式。经典论文（Wei et al., 2022）在 GSM8K 上从 18% 提升到 58%。
- Zero-shot CoT：更轻量，只需在 prompt 末尾加一句“Let's think step by step”（Kojima et al., 2022）。原理是利用模型预训练时见过的“推理链”模式，触发其内部隐式的序列化推理能力。在 MultiArith 上准确率从 17% 提升到 79%。
为什么有效？
- 分解注意力瓶颈：自回归解码时，模型每一步只能看到前文 token。直接输出答案需要一步跨越巨大语义鸿沟（如“5个苹果”到“6个”），而 CoT 将这个大跨度拆成多个小跨度（5→3→6），每一步的注意力负载更轻，错误率更低。
- 利用语言作为工作记忆：中间步骤的文字相当于模型的“外部缓存”，把中间结果写回上下文，避免遗忘。这类似于人类用笔算而不是心算。
何时最有用？
- 数学推理：GSM8K、MATH 等数据集，CoT 是标配。但注意：对简单加减法（如 2+3），CoT 反而因生成多余 token 而增加延迟，且准确率无提升。
- 逻辑/符号推理：如“A比B高，B比C高，谁最高？”这类需要传递性推理的任务。
- 多步规划：如“从北京到上海，先买机票，再订酒店，最后租车，请列出步骤”。CoT 能显式输出每一步依赖关系。
- 复杂常识推理：如“为什么下雨天容易堵车？”需要分步解释（能见度低→车速慢→刹车距离长→车流积压）。
工程取舍与坑
- Trade-off：精度 vs 成本。CoT 生成的 token 数可能比直接输出多 5-10 倍。在 GSM8K 上，CoT 的准确率约 80%，但延迟从 0.5s 飙升到 3-5s。对于高吞吐场景（如客服机器人），需要做“是否启用 CoT”的决策：简单问题直接输出，复杂问题才触发 CoT。可以用一个轻量分类器（如基于问题长度或关键词）做路由。
- 实际落地的坑：小模型（<7B 参数）用 CoT 反而更差。原因是小模型的“推理链”生成能力弱，中间步骤可能出错，且错误会累积。例如，用 3B 模型在 GSM8K 上，Zero-shot CoT 准确率从 15% 降到 12%。解法：要么用大模型（>70B），要么用“思维树（Tree-of-Thoughts）”做多路径搜索，但成本更高。
- 另一个坑：CoT 可能产生“幻觉链”——模型编造看似合理的中间步骤，但结论错误。例如，在逻辑推理中，模型可能写出“因为 A 是 B，B 是 C，所以 A 是 C”，但实际关系是“A 不是 B”。解法：结合验证步骤，比如让模型在生成 CoT 后，再生成一个“检查”步骤（Self-Consistency 或 Self-Refine）。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从原理、适用场景、工程取舍三个层面回答。原理上，CoT 通过生成中间推理步骤，将复杂问题分解为多个小跨度，降低每一步的注意力负载。适用场景上，它最擅长数学推理、逻辑推理和多步规划，但对简单问题反而增加成本。工程取舍上，核心是精度 vs 延迟的平衡，且小模型用 CoT 可能更差。总结一句：CoT 是提升推理精度的利器，但必须配合场景路由和模型规模选择来落地。”
4️⃣ 高频追问 & 应对
追问 1：CoT 和直接输出答案相比，为什么能提升准确率？你能从注意力机制角度解释吗？
核心在于自回归解码的“注意力瓶颈”。直接输出答案时，模型需要从输入 token 一步跳到输出 token，中间跨度大，注意力可能分散到无关信息。CoT 将这个大跨度拆成多个小跨度，每一步模型只需关注前一步的结果和输入中的局部信息。例如，在数学题中，第一步“5-2=3”只关注“5”和“2”，第二步“3+3=6”只关注“3”和“3”。这相当于把注意力从“全局搜索”变成“局部聚焦”，减少了注意力矩阵中的噪声干扰。论文（Wei et al., 2022）中的消融实验也证明，移除中间步骤后准确率大幅下降。
追问 2：如果用户问一个简单问题（如“2+3等于几”），你用 CoT 会有什么问题？怎么优化？
问题在于：CoT 会生成多余 token（如“先算 2+3=5”），增加延迟和 token 成本，且对准确率无提升。优化方案是做一个“CoT 路由”：用一个轻量分类器（如基于问题长度、关键词或复杂度分数）判断是否启用 CoT。例如，问题长度 < 10 个 token 且不含“为什么”“如何”等词，直接输出；否则启用 CoT。实际部署中，这个路由模型可以用一个简单的逻辑回归或小 BERT 模型，延迟 < 1ms，能节省 30-50% 的 token 消耗。
追问 3：CoT 和 Tree-of-Thoughts (ToT) 有什么区别？什么时候该用 ToT？
CoT 是单一路径的线性推理，而 ToT 是树状的多路径搜索。ToT 在每一步生成多个可能的推理分支，并用 BFS/DFS 或评分函数选择最优路径。适用场景：当问题需要探索多种可能性时（如“设计一个营销方案”），CoT 可能陷入局部最优，而 ToT 能覆盖更多解空间。但 ToT 的 token 成本是 CoT 的 10-100 倍，延迟也更高。工程上，只有对高价值问题（如金融风控决策）才值得用 ToT，普通问答用 CoT 即可。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“CoT 对所有推理任务都有效，是万能药” → ✅ 正确切入：CoT 对简单问题（如直接事实问答）无效，甚至有害；对需要创造性或开放性问题（如写诗）也不适用。必须强调场景选择性。
- ❌ 说“CoT 的原理是让模型更聪明，像人类一样思考” → ✅ 正确切入：CoT 本质是利用语言作为工作记忆，分解注意力负载，而非让模型“理解”逻辑。这是工程视角，不是哲学视角。
- ❌ 说“CoT 的缺点是 token 消耗大，所以不用” → ✅ 正确切入：应该用“路由”策略，而不是一刀切禁用。CoT 的价值在复杂问题上远超成本，关键是做成本收益分析。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“CoT 作为 RAG 的推理增强”切入。例如，在检索后，用 CoT 引导模型分步推理检索到的文档，而不是直接生成答案。可以提“在金融问答中，CoT 将准确率从 65% 提升到 82%，但延迟从 1s 增加到 4s，我们通过问题复杂度路由优化了 40% 的延迟”。
- 如果你只做过传统 NLP：用“序列标注 vs 序列生成”类比。CoT 相当于把分类任务（直接输出答案）变成序列生成任务（输出推理链），类似于 NER 中把实体识别拆成“先找边界，再分类”。强调这种“分解”思想在传统 NLP 中也有应用（如句法分析中的 CKY 算法）。
- 如果你是校招无项目：聚焦论文复现。可以说“我复现了 Wei et al. 2022 的 CoT 实验，在 GSM8K 上用 GPT-3.5 从 18% 提升到 58%，并分析了不同示例数量（2-shot vs 8-shot）对准确率的影响”。展示动手能力和对论文细节的理解。
- Wei et al., 2022. "Chain-of-Thought Prompting Elicits Reasoning in Large Language Models"
- Kojima et al., 2022. "Large Language Models are Zero-Shot Reasoners"
- Wang et al., 2022. "Self-Consistency Improves Chain of Thought Reasoning in Language Models"
- Yao et al., 2023. "Tree of Thoughts: Deliberate Problem Solving with Large Language Models"
- 博客：Lilian Weng, "Prompt Engineering" (2023) - 包含 CoT 的工程实践和变体