核心 GUIDE
Sampling Controls（采样控制）
Temperature、top-p 等解码参数会改变 Runtime 如何从模型概率分布中采样，从而改变输出多样性；它们不会修复缺失证据、错误 Context 或模型能力不足。
核心心智模型
Sampling Control 是作用在 Next-token 分布上的 Runtime 策略。它可以让候选 Token 的选择更集中或更分散，但并不会改变“模型知道什么”，更不会自动增加事实正确性。
为什么重要
团队经常把 Temperature 当成通用质量旋钮。降低随机性可能让输出更一致，却仍然稳定地产生同一种系统性错误；提高随机性可以产生更多备选，却会增加结果方差。正确设置取决于任务究竟需要可重复性、探索性、多样性，还是需要显式表达不确定性。
01
把模型打分与解码策略拆开理解
先得到模型的 Next-token 概率，再由配置的解码策略变换并选择 Token。Temperature 会重新缩放相对 Logit，Nucleus Sampling 会把候选限制在一段累计概率质量内。不同 Provider 的参数表面不同，但工程问题相同：任务允许多少输出方差，以及下游哪一层负责验证剩余的不确定性。
02
示例：结构化抽取与创意命名
发票字段抽取通常需要较低生成方差和严格结构约束，因为下游代码依赖稳定 Schema；品牌命名 Brainstorm 则更需要较宽采样，因为一堆近似答案价值很低。但任何采样参数都无法证明模型读对了发票，也无法证明名称没有商标风险，这些问题必须由独立证据与检查解决。
常见失败模式
- 用 Temperature 弥补缺失或无关的 Context。
- 认为 Temperature 越低，事实就越正确。
- 所有任务共用同一组解码参数，不考虑允许的方差。
工程启发
- 依据任务级 Evaluation 调参，而不是依据文风偏好。
- 能够被确定性验证的正确性，交给 Validator 而不是采样参数。
- 把探索型配置与要求可重复 Contract 的生产路径分开。
关键结论
- 01Sampling 改变的是选择行为，不是真实性。
- 02不同任务需要不同的方差预算。
- 03解码策略与正确性验证是两类独立责任。
阅读记录
这里只记录你真实做过的动作，不代表掌握、熟练或认证。
用于这些学习路径
这个 Concept 会在多个 canonical 学习路径中复用。
继续学习
来自 Knowledge Graph 的相关知识点
这些关系直接来自 canonical graph，不维护第二套 Guide 分类体系。