详细解释
Beam Search（集束搜索 / 束搜索） 是从机器翻译时代（2016 年 seq2seq）沿用到今天的解码算法，本质是对”每一步只选 Top-1 的贪婪解码（Greedy Decode）“做扩展：我不只走一条路，我同时开 B 条路（Beam = B，B 一般取 4、5、10），每一步给 B 条路的每个都算下一步词表所有概率 → 组合出 B × V 条新路 → 剪枝只留联合概率最高的 B 条 → 到终止符（EOS）或 max_tokens 就返回得分最高的那条。
直观对比 3 种解码策略（Prompt = “从北京去上海最快的交通方式是”）：
| 解码策略 | 过程描述 | 典型输出 | 适合场景 |
|---|---|---|---|
| Greedy（贪婪，B=1） | 每步直接选概率最高的 1 个词 | “从北京去上海最快的交通方式是高铁，约 5 个半小时。” | 简单抽取 / 机器翻译（要求准确、不要创造力） |
| Beam（B=5） | 同时保留 5 条最优路径，最后选联合概率最高的 | “从北京去上海最快的交通方式是京沪高铁复兴号，全程约 4 小时 28 分；其次是直飞航班 2 小时左右。” | 机器翻译、摘要、抽取——追求流畅 + 内容完整 + 不易错 |
| Top-P + Temperature（采样） | 每一步按核概率分布随机采样 | “从北京去上海最快的方式嘛，一般看情况！推荐京沪高铁复兴号（4.5h），赶时间也可以飞大兴→虹桥……” | 创意写作、闲聊、头脑风暴（要多样性和自然度） |
Beam Search 解决了 Greedy 的经典问题：局部最优不代表全局最优。比如一个翻译句子 “The cat sat on the mat”，Greedy 第一步选了”猫”（概率最高）就锁死了；但 Beam Size=5 会同时保留”猫 / 那只猫 / 这只猫咪 / 猫科动物 / 小猫”这 5 条候选，当后面词语是”坐在垫子上”时，可能”那只猫坐在垫子上”的全局联合概率比猫要高——Beam 就会选后者。所以 Beam 生成的句子整体更流畅、少重复。
Beam Search 重要超参数
| 超参数 | 常用值 | 作用 | 调参指南 |
|---|---|---|---|
| Beam Size（束宽 B） | 4、5、8、10 | 同时保留多少条候选路径 | B 越大越准（越不容易错过全局最优）但计算量 × B，超过 10 边际收益骤降，一般 5 足够 |
| Length Penalty（长度惩罚 α） | 0.6（摘要）~ 1.0（翻译） | 联合概率 = 每步乘积，天然偏短句（每步乘一个 小于 1 的概率，句子越长总得分越小）；LP 给长句一点补偿：Score = TotalLogProb / Length 的 alpha 次方。α=1 就是平均对数概率。 | 摘要短句 α=0.6，翻译 α=1.0，长文 α=1.2 鼓励长 |
| No Repeat N-gram（禁止重复 N 元组） | N=3 | 任意 N 元词组在输出中不允许出现两次，强力抑制”谢谢谢谢谢谢”这种复读 | 生成任务默认开 3；摘要/翻译 N=3，代码 N=2 |
| Diversity Penalty（多样性惩罚，多 Beam 不同） | 0.2 至 0.5，用于 Diverse Beam Search | 多个 Beam 输出相同路径时扣分，鼓励 B 条路各说各话 | 想生成 K 个不同的候选（SC 投票前用）时开 |
| Early Stopping（早停） | 开 | 只要 N 个 Beam 都出了 EOS 就停止生成，不用等到 max_tokens | 默认开，提速 20–40% |
主流生成场景下的 Beam / 采样选型建议（收藏级）
| 场景 | 推荐解码 | 原因 | 典型参数 |
|---|---|---|---|
| 机器翻译（中英/英中） | Beam Search | 翻译的”标准答案空间”相对单一，Beam 准确率最高 | beam=5, lenpen=1.0, no_repeat_ngram=3 |
| 新闻/文章摘要 | Beam Search（+ 短 LP） | 摘要要准确、要点全，不需要多样性 | beam=4, lenpen=0.8, min_length=30 |
| 结构化抽取（JSON/表格） | Greedy / Beam=1 + JSON Schema | 抽取不要创造力，要稳定和正确；强制 JSON 模式 | temperature=0, response_format=json_object |
| 代码生成（函数级） | 先 Self-Consistency（SC）用采样 出 K=40 → 单测过滤 | 代码正确与否单测一眼知道，采样多样性 + 客观测试最香 | temperature=0.7, top_p=0.95, K=40 |
| 创意文案/营销软文 | Nucleus Sampling（Top-P） | 需要风格和创意，Beam 会生成”万金油”文风 | temperature=0.9, top_p=0.9, Presence Penalty=0.8 |
| 闲聊对话客服 | Top-P + T=0.7 至 1.0 | 闲聊要求自然度，Beam 会显得像机器人 | temperature=0.8, top_p=0.9, Freq Penalty=0.3 |
| RAG 问答 | Top-P + T=0.2 + 结构化引用 | 低温度保证事实准确，采样比 Beam 更少编造 | temperature=0.2, Frequency Penalty=0.1 |
| 长文档续写（技术手册） | Beam + No Repeat 4-gram | 要求连贯、结构化、不重复段落 | beam=4, no_repeat_ngram=4, lenpen=1.2 |
唯元智创 的模型调试 Playground 把上述所有预设都做成了场景化下拉：选”翻译”自动切 Beam + 参数，选”文案”自动切 Top-P + T=0.9。
常见问题
为什么现在越来越多模型默认用 Top-P 采样，而不是 Beam？
两个原因：（1）Chat/对话成为主流场景，Beam 的输出”太正确”会显得机械、官方、不像人类闲聊；采样出的回复更自然。（2）2022 年后社区的多篇论文发现 Beam 在超长生成（500 tokens+）上反而更容易出现”枯燥重复 + 模板化表达”——所谓 Beam Search Degeneration（Beam 退化）。2025 年的结论是：任务型（翻译/摘要/抽取）继续用 Beam；开放对话/创意/写作 → 用 Top-P 采样。没有银弹，按场景选解码策略，不要迷信某个单一算法。
我能不能先 Beam 生成 K 个候选，再走 Self-Consistency 投票？
能，但实际效果 不如”Diverse Beam Search（多样性集束）→ SC 投票”组合更差。原因：标准 Beam Search 生成的 K 条路高度相似（它们是同一个概率峰附近的 B 个局部变体），拿它们投票就像”让一个人换 5 个坐姿做同一张试卷——结果大概率还是一样的错”，多样性不够。正确组合：SC 的 40 条候选由”高 Temperature 采样”生成（保证路径多样性），最后用”投票 + 客观指标（代码单测/正则匹配）“选答案；Beam Search 单独作为一个确定性场景的解码手段，不要把它和 SC 混到同一条链路上。
流式输出（Streaming）支持 Beam Search 吗？
支持，但和你想象的不一样——标准流式只能流”最终选出来的那一条 Beam”，中间切换路径时会有”跳字”问题（前 10 个 Token 是路径 A 的，第 11 步选了路径 B 全局更优，就得回滚 10 个 Token，这在 SSE 里实现不了）。所以在 Streaming 流式 API 里，厂商大多不开启 Beam Search 暴露给用户（或者内部用 Beam B=2 只流最终那条路径，用户看不到切换）。如果你的业务强依赖流式逐字效果，还是乖乖走 Top-P 采样。需要 Beam 质量的场景（翻译/摘要）就走非流式，一次性返回完整结果更稳。