注意力机制需匹配任务结构，序列长度、依赖类型、计算约束三点未对齐时反而损害性能；点积注意力快省内存但需缩放防饱和，加性更鲁棒但开销大；实际选择取决于任务场景与硬件限制。
直接上结论：注意力机制不是“加个模块就变强”，而是要匹配任务结构——序列长度、依赖类型、计算约束这三点没对齐，加了反而拖慢训练、降低泛化。
注意力该用点积还是加性？看输入维度和硬件
点积注意力（torch.bmm(query, key.transpose(-2, -1))）快、省内存，但当 query 和 key 维度高（比如 >512）时，原始分数容易爆炸，必须加缩放因子 / sqrt(d_k)，否则 softmax 会饱和输出接近均匀分布。
加性注意力（torch.tanh(query + key)）更鲁棒，对维度不敏感，但多一层线性变换，显存和计算开销明显上升。PyTorch Forecasting 中的 FullAttention 默认用点积，而早期 pytorch-seq2seq 的 Attention 类用加性——不是谁先进，是前者面向长时序批量预测，后者面向短句翻译。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 序列长度
- 特征维度 > 768 或 batch_size 很小（
- 用 GPU 推理且显存紧张 → 避免加性中
repeat或expand操作，改用广播
掩码（mask）漏写或写错位置，模型当场失效
常见错误是只在训练时 mask 填充位（src_mask），却忘了在自回归解码时加因果掩码（tril）。比如用 nn.TransformerDecoder，必须传入 memory_mask 和 tgt_mask 两个参数；漏掉 tgt_mask，模型会在预测第 t 步时偷看 t+1 及之后的真实 token，验证指标虚高，部署后立刻崩。
-
nn.Transformer要求tgt_mask是上三角矩阵（torch.triu(torch.full(...), diagonal=1)） - 手动实现时，别用
float('-inf')直接赋值——某些旧版 PyTorch 在 CUDA 上会触发 NaN，改用torch.finfo(torch.float32).min - 时间序列预测中，若用相对位置编码，掩码还要同步遮蔽负索引区域，否则相对偏移计算越界
多头注意力的 head 数不能硬凑，得看 hidden_size
PyTorch 的 MHA 层要求 embed_dim % num_heads == 0，但很多人只检查整除，忽略实际通道利用率。例如 hidden_size=256 设 num_heads=12，虽然 256÷12≈21.3，不整除直接报错；设 num_heads=8，每头 32 维，看着合理，但如果下游接的是 128 维的 FFN，头数过多会导致信息稀释——实测在 TFT 模型中，num_heads=4 比 8 更稳定。
- 优先选 2 的幂次：2、4、8、16（GPU 并行友好）
- head_dim 64 → 显存陡增，且梯度更新变慢
- Temporal Fusion Transformer 论文明确建议 head 数 ≤ hidden_size // 32
真正卡住人的往往不是公式推导，而是 mask 形状不对、head_dim 除不尽、缩放因子漏掉——这些细节不跑通，注意力连 baseline 都打不过。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
