注意力机制如何决定模型“看哪里”？
- 场景: 处理“北京的天气怎么样”时，读到“怎么样”需判断前面哪些词最重要;
- 三类向量:
| 向量 | 含义 | 在例子中 |
|---|
| Query（查询） | 当前词发出的“搜索请求” | “怎么样”问：哪个词和我最相关？ |
| Key（键） | 每个词的“标签”，用于被搜索匹配 | “北京”偏地名，“天气”偏气象 |
| Value（值） | 每个词的“内容”，匹配成功后被提取 | 匹配到“天气”后提取其语义 |
- 三步计算: 当前词生成 Query；Query 与每个词的 Key 做点积得匹配度（两组数字逐位相乘再相加）；用匹配度对各 Value 加权求和;
- 直觉: 打分高的词贡献多，打分低的贡献少，合成出一个综合理解;
注意力热力图揭示了哪些模式？
- 因果三角形: 每行是一个 Query、每列是一个 Key，热力图呈三角形——每个词只能看到自己和前面的词;
- 注意力储存池（Attention Sink）: 序列第一个 token 常吸收异常高的权重，有时超过总注意力的 70%;
- Sink 的成因: softmax 保证所有注意力权重之和恰好为 1，模型无法表达“不关注任何东西”，必须为剩余权重找稳定容器，序列开头最自然;
- 思维链三角形:
<think> 内的思考展现三角自注意力，生成新思考时频繁回看之前的思考与工具定义;
- 输出三角形: 思考结束后的输出过程形成另一个三角形，用思考过程作为提示来作答;
- 位置偏好（Position Bias）: 模型对上下文开头和结尾分配更高注意力，中间更易被忽视;
- 工程推论: 设计上下文时把最关键的信息放在开头或结尾是一项重要实践原则;
为什么 Key 与 Value 需要被缓存？
- 观察: 每生成一个新词，其 Query 都要与前面所有词的 Key 匹配，再用所有 Value 加权求和;
- 问题: 若每次都从头计算所有 K、V，计算量随上下文长度不断增长;
- 解法: KV Cache 把已算过的 K、V 缓存下来供新词直接复用;
为什么长思维链与工具调用能力依赖上下文学习？
- 上下文学习（In-Context Learning）: 模型无需重新训练，仅凭输入中给出的指令与示例就能适应新任务;
- 依赖关系: 模型的长思维链能力与工具调用能力都高度依赖这种能力;
- 理论视角: 上下文示例使模型行为像被“临时定制”过——没有改变参数，但效果类似一次小型专项训练;
- 推论: 这种调整是暂时的、浅层的、会话结束后消失，因此提示工程需要每轮重新提供上下文;
- 代价: 长上下文会稀释每个 token 获得的注意力，并可导致 上下文腐化;