1、大模型温度系数
在长文本生成模型中,采用温度系数(Temperature)动态递增策略(从 T=0.4T=0.4 逐渐升至 T=0.8T=0.8 )是一种旨在平衡"局部连贯性"与"全局多样性"的高级解码技巧。
这种策略的核心逻辑在于:让模型在开头保持严谨和确定,随着文本展开逐渐释放创造力和发散性。
以下是对该策略的深度解析、数学实现及工程注意事项:
为什么要这样做?(设计动机)
| 生成阶段 | 温度设定 | 目的与作用 | 解决的问题 |
|---|---|---|---|
| 起始阶段 | T≈0.4T≈0.4 | 高确定性、强约束。确保Prompt的续写紧密贴合指令,语法正确,逻辑锚点稳固。 | 防止开篇跑题、幻觉或格式错误;建立稳定的上下文基调。 |
| 过渡阶段 | 0.4→0.80.4→0.8 | 平滑过渡。避免风格突变导致的文本割裂感。 | 防止因温度跳变引起的语义断层或语气不一致。 |
| 后半程 | T≈0.8T≈0.8 | 增加熵值、提升多样性。引入更丰富的词汇和句式,避免长文陷入重复循环。 | 解决长文本生成中常见的"退化"问题(Repetition Degeneration)和内容枯燥。 |
在长文本生成中,将温度系数恒定保持在 T=0.8T=0.8 是一种与动态升温策略截然不同的设计哲学。其核心目标是:在整个生成过程中维持恒定的随机性水平(即熵值稳定),确保模型在任何位置的"探索-利用"权衡保持一致。
以下是对该策略的深度解析、适用场景及工程要点:
为什么选择恒定 T=0.8?
| 特性 | 恒定 T=0.8 | 动态升温 (0.4→0.8) |
|---|---|---|
| 概率分布形态 | 全程一致,softmax输出的熵不变 | 从尖锐到平坦,熵递增 |
| 风格一致性 | ✅ 全文语气、创造力水平均匀 | ⚠️ 前稳后放,可能存在风格断层 |
| 开篇稳定性 | ⚠️ 相对较弱,依赖Prompt质量 | ✅ 强约束,锚定效果好 |
| 长文抗退化 | ✅ 持续抑制重复模式 | ✅ 后期才发力抑制 |
| 可预测性 | ✅ 行为均匀,调试简单 | ⚠️ 需额外调参调度曲线 |
| 计算开销 | ✅ 零额外开销 | ✅ 几乎零开销 |
2、为什么现在的大模型都是Decoder-only架构
参考: https://www.zhihu.com/question/588325646/answer/3357252612
3、强化学习框架PPO、DPO、GRPO等
基本原理介绍:https://zhuanlan.zhihu.com/p/1984387073625593089
3.1、PPO
PPO使用clipping机制的原因:clip 函数的核心作用是截断。它将新旧策略的概率比率r强制限制在1−ϵ,1+ϵ 这个区间内。这意味着我们只允许模型在旧策略的基础上进行小步调整,防止模型因为一次性更新幅度过大(步子迈太大)而导致训练崩溃(扯着蛋),从而保证了强化学习过程的稳定性。
4、梯度消失与梯度爆炸
参考:https://zhuanlan.zhihu.com/p/15391570214
5、最大似然估计
参考:https://zhuanlan.zhihu.com/p/32341102
考题:二项分布的最大似然估计
6、Transformer
参考:https://zhuanlan.zhihu.com/p/1888714210940285525
(1)缩放点积为什么要除以根号dk
7、SFT
参考:https://zhuanlan.zhihu.com/p/2006404476056142687
(1)SFT出现过渡道歉现象的原因
SFT(监督微调)后模型出现"过度道歉"现象,最可能的原因是:训练数据中对齐语料的安全/拒绝回复模板高度同质化,导致模型将"礼貌性致歉"与"安全合规响应"形成了过强的统计绑定。
这本质上是一个数据分布偏差问题,而非模型架构或训练算法的缺陷。以下是分层归因分析:
核心原因:对齐数据的模板污染
在RLHF/SFT的对齐阶段,标注者或合成数据生成管线通常使用固定模板处理敏感/边界请求:
❌ "很抱歉,我无法回答这个问题。作为AI助手,我..."
❌ "对不起,我不能提供此类信息..."
❌ "I apologize, but I cannot..."
当这类模板在训练集中占比过高且变体极少时,模型会学到两个错误的启发式:
- 任何不确定性 → 触发道歉前缀(即使问题完全无害)
- 任何用户负面反馈/纠正 → 触发道歉(而非直接修正答案)
次要放大因素
| 因素 | 机制 | 严重程度 |
|---|---|---|
| DPO/RLHF奖励模型偏差 | 奖励模型本身偏好"礼貌但无用"的回复胜过"直接但有风险"的回复,强化学习进一步放大了道歉倾向 | ⭐⭐⭐⭐ |
| SFT数据去重不足 | 同一安全模板被重复采样数千次,远超正常对话中道歉的自然频率 | ⭐⭐⭐⭐ |
| 负样本缺失 | 训练集中缺乏"无需道歉的正常拒绝"和"被纠正后直接修正"的正例 | ⭐⭐⭐ |
| Base模型预训练偏差 | 预训练语料中客服/论坛道歉文本比例偏高,SFT未充分覆盖 | ⭐⭐ |
| Loss权重均匀 | 安全回复与普通回复使用相同loss权重,高频模板主导梯度方向 | ⭐⭐ |
8、贝叶斯网络
参考:https://zhuanlan.zhihu.com/p/573883337
(1)给定父节点的条件下,每个节点与其非后代节点条件独立,但后代节点在被观测到的前提下,仍可作为证据影响该节点
9、KV Cache
参考:https://zhuanlan.zhihu.com/p/1896199264121644180
参考:https://zhuanlan.zhihu.com/p/685853516
(1)计算复杂度
| 阶段 / 指标 | 无 KV 缓存 (1) | 有 KV 缓存 (2) |
|---|---|---|
| 单步 Token 计算量 | O(t²) | O(t) |
| 完整生成总计算复杂度 | O(n³) | O(n²) |
| 显存空间复杂度(内存开销) | O(1)(不存历史) | O(n)(随序列线性增长) |
(2)KV缓存大小
设输入序列的长度为 s ,输出序列的长度为 n ,模型深度为l,维度为h,以 FP16 来保存KV cache,那么KV cache的峰值显存占用大小为 b(s+n)h∗l∗2∗2=4blh(s+n) 。这里第一个2表示K/V cache,第二个2表示 FP16 占2个bytes。
以 GPT3 (175B) 为例,对比 KV cache 与模型参数占用显存的大小。GPT3 模型weight占用显存大小为350GB (FP16),层数 l为96,维度h为12888。
|------------|------|--------------|-----------------|
| batch size | s+n | KV cache(GB) | KV cache/weight |
| 4 | 4096 | 75.5 | 0.22 |
| 16 | 4096 | 302 | 0.86 |
| 64 | 4096 | 1208 | 3.45 |
10、机器学习管道(Machine Learning Pipeline)
10.1、Lasso回归
参考:https://zhuanlan.zhihu.com/p/88698511
通过正则化实现泛华
10.2、PCA
参考:https://www.zhihu.com/question/40956812
降维前,必须进行标准化,PCA不进行缩放,仅进行旋转
10.3、Permutation Importance
参考:https://zhuanlan.zhihu.com/p/563422607
对相关性高的变量会低估重要性,模型默认的Feature Importance同样存在该问题
10.4、特征哈希
参考:https://zhuanlan.zhihu.com/p/504100961
特征哈希(Feature Hashing / Hashing Trick):特征哈希是AI设计模式中的一种数据表示模式,能够有效解决分类数据不完整、高基数(特征类别不均)、以及冷启动问题(推理时无法处理新出现的类别)
11、大模型量化
11.1、量化影响因素
参考:https://zhuanlan.zhihu.com/p/2025924994631221677
12、Prefill和Decode
参考:https://zhuanlan.zhihu.com/p/2020090480008930343
(1)Prefill和Decode为什么不能放到一起:https://zhuanlan.zhihu.com/p/2063134827772130211
Prefill 负责一次性处理完整 prompt,更依赖 GPU compute,主要影响 TTFT。
Decode 负责逐 token 生成答案,需要频繁读取 KV cache,更依赖 memory bandwidth,主要影响 TPOT。
如果两者一直运行在同一组 GPU 上,长 prompt 的 Prefill 很容易干扰正在进行的 Decode,导致 latency spike、GPU utilization 不稳定,以及 TTFT 和 TPOT 很难同时优化。