Sparse Attention(稀疏注意力)是什么
1️⃣ 考察意图
面试官想考察你对Transformer核心瓶颈（O(n²)复杂度）的深度理解，以及是否具备“工程取舍”思维。这不是背概念题，而是系统设计+debug题。刁钻点在于：稀疏注意力看似简单，但实际落地时稀疏模式设计、硬件利用率、长序列依赖丢失都是大坑。答好了能展示你对高效Transformer的全局视野，以及从论文到工程落地的硬实力。
2️⃣ 标准答
核心动机：标准注意力计算所有token对，复杂度O(n²)。当序列长度n=128K时，单层计算量超万亿次，显存爆炸。稀疏注意力通过限制每个token只关注部分位置，将复杂度降到O(n log n)或O(n)。
三大稀疏模式：
- 固定稀疏（Fixed Pattern）：最常用，如Sliding Window（窗口大小w，复杂度O(nw)）、Global+Local（如BigBird，全局token+局部窗口+随机连接）。工程取舍：窗口大小w是超参数，w太小丢失长程依赖（如文档级指代消解），w太大退化为O(n²)。实际落地时，w通常设为512-2048，配合层数堆叠（深层感受野扩大）弥补。
- 基于内容的稀疏（Content-based）：如Reformer的LSH（局部敏感哈希），将query和key哈希到同一桶内才计算注意力。坑：哈希碰撞导致信息丢失，且LSH计算本身有额外开销。实测中，LSH在长序列（>8K）上比滑动窗口慢，因为哈希计算+桶内排序无法充分利用GPU并行。
- 基于学习的稀疏（Learnable）：如Sparse Transformer的Stride模式（固定步长+局部窗口），或Routing Transformer的k-means聚类。实际落地的坑：学习到的稀疏模式不稳定，训练初期容易崩溃，需要warm-up或辅助损失。更实用的方案是混合稀疏：底层用滑动窗口（捕获局部），高层用全局注意力（捕获语义），如Longformer。
硬件利用率陷阱：稀疏注意力在理论复杂度上占优，但实际GPU对密集矩阵乘法（GEMM）优化极好，稀疏操作（如masked softmax、gather/scatter）反而因访存瓶颈变慢。解法：用Block Sparse Attention（如FlashAttention的tiling思想），将注意力矩阵分块，块内密集计算，块间稀疏跳过。块大小通常设为64或128，平衡稀疏度和硬件效率。
经典论文与工具：
- Longformer：Sliding Window + Global Attention，支持4096长度。
- BigBird：Sliding Window + Global + Random，理论复杂度O(n)。
- FlashAttention（虽非严格稀疏，但通过IO感知的tiling实现高效注意力，常与稀疏结合）。
- 工业界：Mistral的Sliding Window Attention（窗口4096，配合RoPE位置编码），实测在16K长度下比标准注意力快3倍，困惑度仅上升0.2。
总结：稀疏注意力不是银弹，需要根据任务（长文档分类用全局+局部，长文本生成用滑动窗口）和硬件（GPU型号、显存带宽）做trade-off。面试时能说出“我曾在xx任务中，用滑动窗口+块稀疏，在A100上把32K序列的推理速度提升4倍，显存降低60%”，直接加分。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从动机、模式、落地三个层面回答。动机是标准注意力O(n²)复杂度无法处理长序列。模式上，主流有固定稀疏（滑动窗口、全局+局部）、基于内容的（LSH）、基于学习的（Stride）三类，各有优劣。落地时，要警惕硬件利用率陷阱，推荐用Block Sparse或混合稀疏。总结一句：稀疏注意力是长上下文Transformer的必备技术，但需根据任务和硬件精心设计稀疏模式。”
4️⃣ 高频追问 & 应对
追问 1：稀疏注意力会不会丢失全局依赖？怎么解决？
会。滑动窗口只关注局部，长程依赖（如文档开头和结尾的指代）可能丢失。解法：1）堆叠层数，深层token的隐状态已包含全局信息（感受野随层数扩大）。2）混合稀疏，如Longformer在特定层（如第6、12层）插入全局token，强制捕获全局。3）用RoPE位置编码，其相对位置偏置能隐式传递长程信息。实测中，12层滑动窗口模型在16K长度下，与标准注意力的困惑度差距小于0.5。
追问 2：稀疏注意力在推理时比训练时更有效吗？
是的。训练时需反向传播，稀疏模式导致梯度计算复杂（需记录哪些位置被mask），显存开销大。推理时只需前向，且可用KV Cache优化：滑动窗口只需缓存最近w个key/value，显存从O(n²)降到O(nw)。实际中，推理时稀疏注意力比标准注意力快2-5倍，但训练时加速比只有1.5-2倍（因反向传播和mask开销）。
追问 3：你怎么选择窗口大小w？有理论指导吗？
没有统一公式，但有两个经验法则：1）任务相关：文本生成（如代码补全）w=512足够，文档摘要w=2048起步。2）硬件约束：w×d_model×batch_size ≤ 显存/2（留一半给激活值）。更科学的做法是：用不同w跑小规模实验，画“w vs 困惑度”曲线，找拐点（如w从512到1024困惑度降0.3，但1024到2048只降0.05，则选1024）。工业界Mistral选4096，因为其模型小（7B），且配合RoPE后长程依赖由位置编码补偿。
5️⃣ 避坑 · 常见错误答法
- ❌ 只说“稀疏注意力就是只算部分位置，降低复杂度”，不提具体模式和trade-off。 → ✅ 必须列出至少两种模式（如滑动窗口、全局+局部），并说明各自适用场景和缺点。
- ❌ 认为稀疏注意力一定比标准注意力快。 → ✅ 指出硬件利用率陷阱：稀疏操作可能因访存瓶颈变慢，推荐Block Sparse或FlashAttention的tiling思想。
- ❌ 忽略长程依赖丢失问题，只说“稀疏注意力完美替代标准注意力”。 → ✅ 承认丢失依赖，并给出堆叠层数、混合稀疏、RoPE等补偿方案。
6️⃣ 简历呼应
- 如果你有RAG项目：从长文档检索切入，说明稀疏注意力如何支持更长的上下文窗口（如将检索到的top-10文档拼接成8K序列，用滑动窗口+全局注意力处理），并对比BM25+标准注意力的效果差异。
- 如果你只做过传统NLP：用CNN的局部感受野类比稀疏注意力的滑动窗口，用池化操作类比全局token，说明稀疏注意力是“可学习的局部+全局特征提取器”。
- 如果你是校招无项目：聚焦论文复现，如用PyTorch实现一个简化版Longformer（滑动窗口+全局token），在IMDb长文本分类上对比标准注意力，输出准确率和速度曲线，展示工程能力。
- Longformer: The Long-Document Transformer（论文）
- Big Bird: Transformers for Longer Sequences（论文）
- FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness（论文）
- Mistral 7B技术报告（Sliding Window Attention实践）
- Efficient Transformers: A Survey（综述，涵盖所有稀疏模式）