What is the difference between local attention and global attention
1️⃣ 考察意图
面试官想考察你对稀疏注意力机制（Sparse Attention）的底层理解，而非简单背诵概念。这是一道典型的“工程取舍 + 系统设计”题，刁钻点在于：你是否能跳出“局部 vs 全局”的二元对立，理解它们如何协同解决长上下文场景下的计算瓶颈与信息捕获矛盾。答好了能展示：对 Transformer 计算复杂度的数学直觉、对 Longformer/BigBird 等经典工作的熟悉度、以及在实际部署中平衡效果与资源的工程能力。
2️⃣ 标准答
核心差异：局部注意力（Local Attention）限制每个 token 只关注固定窗口内的邻居（如 512 个 token），计算复杂度 O(n * w)；全局注意力（Global Attention）允许特定 token（如 [CLS] 或随机选取的锚点）关注整个序列，复杂度 O(n²)。两者本质是计算预算的分配策略。
设计动机：
- 局部注意力：解决全注意力 O(n²) 随序列长度平方增长的问题。典型实现是滑动窗口掩码（Sliding Window Mask），窗口大小 w 通常设为 512 或 1024。为什么这么做：自然语言中，相邻 token 的依赖最强（如短语、局部语法结构），牺牲远距离交互换取线性复杂度是合理的 trade-off。
- 全局注意力：弥补局部注意力丢失的长程依赖。例如在文档级任务中，主题词或指代关系可能跨越数千 token。通过少量全局 token（如每 64 个 token 设一个全局锚点）捕获全局信息，避免全注意力的 O(n²) 开销。
经典模型实现：
- Longformer：局部窗口 + 少量全局 token（如 [CLS] 和任务特定 token）。窗口大小 512，全局 token 数量固定（如 128 个）。实际落地的坑：全局 token 的选择策略很关键——如果随机选，可能漏掉关键信息；如果固定选 [CLS]，在长文档分类中效果稳定，但生成任务中需动态选择（如每段首 token）。解法：在训练时用可学习的全局 token 位置嵌入，让模型自己决定哪些位置需要全局视野。
- BigBird：局部窗口 + 全局 token + 随机注意力（Random Attention）。随机注意力让每个 token 随机关注序列中其他 token，进一步增加信息流动。为什么这么做：随机注意力在理论上能保证图连通性（Graph Connectivity），避免局部窗口导致的信息孤岛。计算复杂度仍为 O(n)，但效果逼近全注意力。
- Sparse Transformer：使用固定步长（Strided Attention）的局部模式，适合图像等结构化数据，但在 NLP 中不如滑动窗口灵活。
性能权衡：
- 计算量：混合模型复杂度 O(n * w + n * g)，其中 g 是全局 token 数（通常远小于 n）。对比全注意力 O(n²)，在 4096 长度序列上，窗口 512 + 全局 128 的混合模型计算量约为全注意力的 1/8。
- 效果：在长文档分类（如 PubMed 摘要分类）中，混合模型准确率比纯局部注意力高 3-5 个百分点，但比全注意力低 1-2 个百分点。工程取舍：如果任务对长程依赖敏感（如法律文档推理），优先保证全局 token 数量；如果计算资源受限（如移动端推理），缩小窗口大小比减少全局 token 更安全，因为局部信息丢失的代价通常更低。
- 显存：全注意力需要存储 n² 的注意力矩阵，混合模型只需存储 n * w + n * g 的稀疏矩阵。在 8192 长度下，混合模型显存占用约为全注意力的 1/10。
选择依据：
- 任务类型：文本分类/情感分析 → 局部注意力足够（依赖局部特征）；文档摘要/问答 → 需要全局注意力（依赖全局主题）。
- 序列长度：< 1024 → 全注意力更简单；1024-4096 → 混合模型性价比最高；> 4096 → 必须用稀疏注意力，且需考虑全局 token 的分布策略（如分段全局）。
- 硬件限制：GPU 显存 < 16GB → 优先用局部注意力 + 少量全局 token；显存充足 → 可增加全局 token 数量或使用 FlashAttention 优化全注意力。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从设计动机、实现差异、性能权衡三个层面回答。设计动机上，局部注意力解决 O(n²) 计算瓶颈，全局注意力弥补长程依赖丢失。实现上，Longformer 用滑动窗口加固定全局 token，BigBird 额外引入随机注意力保证连通性。性能上，混合模型在 4096 长度下计算量仅为全注意力的 1/8，但效果接近。总结一句：局部和全局不是对立，而是根据任务和资源动态分配计算预算的策略。”
4️⃣ 高频追问 & 应对
追问 1：如果序列长度达到 128K，你的混合模型还能用吗？怎么优化？
128K 长度下，即使局部窗口 512，计算量也达 65M 次注意力，显存仍可能爆炸。解法：采用分层注意力（Hierarchical Attention），先对局部窗口做池化（如平均池化）得到段向量，再在段级别做全局注意力。例如 Longformer 的扩展版本 Longformer-Large 使用 4096 的段大小，段内局部注意力，段间全局注意力。另一个方向是使用 FlashAttention 的 IO 感知优化，将注意力计算分块到 SRAM 中，避免显存瓶颈。实际落地时，128K 序列通常需要结合分块（Chunking）和流式处理（Streaming），比如每 4096 token 一个 chunk，chunk 内混合注意力，chunk 间用跨 chunk 的全局 token 连接。
追问 2：全局 token 的数量和位置如何确定？有没有理论依据？
数量上，经验值是序列长度的 1-5%（如 4096 长度设 128 个全局 token）。理论依据来自图论：全局 token 相当于图中的“枢纽节点”（Hub），保证任意两个 token 之间的路径长度不超过 2（通过全局 token 中转）。位置选择有三种策略：固定位置（如每 64 个 token 设一个）、学习位置（用可学习的位置嵌入让模型自己决定）、任务特定（如 [CLS] 和 [SEP] 强制设为全局）。实际工程中，固定位置最稳定，学习位置在训练数据充足时效果更好。注意：全局 token 过多会退化到全注意力，失去稀疏优势；过少则信息流动不足。
追问 3：局部注意力的窗口大小怎么选？有没有自适应方法？
窗口大小通常设为 512 或 1024，这是基于语言局部性假设（相邻 token 依赖最强）。自适应方法有：基于 token 类型动态调整（如标点符号处扩大窗口）、基于注意力熵（Attention Entropy）调整（熵高说明需要更大窗口）、或使用可学习窗口大小（如 Adaptive Span 模型）。但自适应方法在工程上复杂，推理时无法预计算，实际落地中固定窗口更可靠。一个折中是分段窗口：前 1/3 序列用小窗口（256），后 2/3 用大窗口（1024），因为长文档的后半部分通常包含总结性信息。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“局部注意力就是滑动窗口，全局注意力就是全注意力，两者互斥” → ✅ 正确切入：两者是互补的，混合模型才是主流，局部负责局部特征，全局负责长程依赖。
- ❌ 说“全局注意力计算复杂度是 O(n²)，所以永远不要用” → ✅ 正确切入：全局 token 数量是固定的（如 128 个），所以实际复杂度是 O(n * g)，g 远小于 n，不是 O(n²)。
- ❌ 说“窗口大小越大越好，因为能捕获更多信息” → ✅ 正确切入：窗口大小增加会线性增加计算量，且超过 1024 后收益递减（语言局部性假设失效），需要权衡。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从长文档分块（Chunking）角度切入，说明局部注意力相当于固定大小的 chunk，全局注意力相当于跨 chunk 的检索。可以讲你如何用混合注意力优化 RAG 的上下文窗口，比如在检索到的 top-5 chunk 内用局部注意力，chunk 间用全局 token 连接。
- 如果你只做过传统 NLP：用 CNN 的局部感受野类比局部注意力，用全连接层类比全局注意力。强调局部注意力是“卷积式”的，全局注意力是“全连接式”的，混合模型相当于 CNN + 全局池化。
- 如果你是校招无项目：聚焦 Longformer 论文复现 demo，讲你如何用 PyTorch 实现滑动窗口掩码，对比不同窗口大小下的准确率和显存占用。可以提你发现窗口 512 时准确率与全注意力差距 < 2%，但显存节省 80%。
- Longformer: The Long-Document Transformer（Beltagy et al., 2020）
- Big Bird: Transformers for Longer Sequences（Zaheer et al., 2020）
- Sparse Transformer: Generating Long Sequences with Sparse Transformers（Child et al., 2019）
- FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness（Dao et al., 2022）
- Adaptive Attention Span in Transformers（Sukhbaatar et al., 2019）