2.1 大语言模型工作原理
2.1.1 注意力机制和上下文(自己看笔记)
- Query、Key、Value：每个 Token 被转换为三个向量
- 注意力分数计算：Query 与所有 Key 计算相似度
- 加权求和：根据注意力分数对 Value 加权求和
- 输出表示：得到融合了上下文信息的 Token 表示
2.1.2 计算复杂度
准自注意力的计算复杂度是 $O(n^2)$，其中 $n$ 是序列长度。这意味着：
- 序列长度翻倍，计算量增加 4 倍
- 这是限制上下文窗口大小的主要技术瓶颈
| 技术 | 原理 | 代表模型 |
|---|---|---|
| 稀疏注意力（Sparse Attention） | 只计算部分位置之间的注意力，减少需要计算的注意力连接 | Longformer、BigBird |
| 线性注意力（Linear Attention） | 对自注意力进行近似，将注意力计算复杂度从二次级别降低到近似线性级别 | Linear Transformer |
| 滑动窗口注意力（Sliding Window Attention） | 限制每个位置只关注其附近的局部窗口，避免计算完整的全局注意力 | Mistral |
| 分组查询注意力（GQA） | 多个 Query 头共享较少数量的 Key-Value 头，从而减少 KV Cache 和推理时的内存占用 | LLaMA 2 70B、许多现代大模型 |
2.1.3 预训练和涌现能力
语言模型通过在海量文本上预训练，学习语言的统计规律和世界知识。随着模型规模、训练数据、后训练方法和工具接口共同演进，模型会逐步表现出更强的 涌现能力（Emergent Abilities）：
- 少样本学习：通过几个示例就能理解新任务
- 逻辑推理：执行多步推理
- 代码生成：根据自然语言描述生成代码
- 工具使用：理解和调用外部工具
2.2 上下文窗口的本质
2.2.1 什么是上下文窗口
上下文窗口是LLM一次能够处理的最大token序列长度 它包括输入的提示词,对话历史,检索到的文档等信息,以及模型的输出
类比为模型的工作记忆:
- 有固定的容量上限
- 超出容量的部分无法处理
- 窗口内所有信息可见且相互影响
2.2.2 输入和输出的关系
上下文窗口容量=输入Token数+输出Token数
2.2.3 上下文窗口的技术实现
- 位置编码:现在多采用RoPE（旋转位置编码）和 ALiBi（注意力线性偏置）
- KV缓存
- 注意力计算
2.2.4 长上下文的挑战
- 中断迷失:对开头和结尾的信息更敏感
- 注意力稀释:噪声,冲突证据,位置偏置的暴露面更大
- 成本和延迟
- 质量和长度的权衡
2.2.5 有效上下文的长度
声称上下文长度:宣称支持的最大程度 有效上下文长度:真正能够有效利用的长度
评估有效上下文长度:大海捞针测试:将一条关键信息放置在上下文不同位置,看测试模型能否正确检索
2.3 Token与上下文限制
2.3.1 什么是token
token是LLM处理文本的基本单位 它可以是:
- 一个完成的单词
- 单词的一部分
- 单个字符或者标点符号
- 特殊符号
2.3.2 分词算法
主流的算法包括:
- ** BPE（Byte Pair Encoding）**: OpenAI 的 GPT 系列采用，从单字符开始迭代合并最频繁出现的字符对，直到达到预设的词表大小
- WordPiece: Google 的 BERT 采用，与 BPE 类似但使用不同的合并策略
- SentencePiece: 处理多语言文本的通用方案，不依赖于预先的空格分词，特别适合中文、日文等语言
2.3.3 Token计数的重要性
- 容量规划:防止请求过长被截断
- 成本估算
- 性能优化
2.3.4 Token计数实践
Tokenizer: 采用官方的分词器
- OpenAI：tiktoken 库
- Anthropic：Claude 分词器
- Google：Gemini tokenizer
2.3.5 上下文限制的管理策略
预算分配:
为不同组成部分分配token预算:例如系统提示词,检索内容等等
内容筛选
只包含当前任务真正相关的信息: 精确检索而非全量加载;移除冗余和重复内容;过滤噪声信息
格式优化
简洁的表达;避免不必要的格式修饰;结构化而非散文化表述
动态调整
简单任务使用更小的上下文;复杂任务拓展必要信息;实时监控token使用情况
2.3.6 token与成本
输入,输出,缓存读,缓存创建对应的token计费规则不同
成本优化策略:
- 压缩输出
- 控制max_tokens控制最大输出长度
- 简单利用prompt caching机制复用公共内容
- 简单任务使用小模型.复杂的用大模型
- 批量请求可能有折扣
2.4 主流模型的上下文能力对比
2.4.1 主流模型概览
| 模型系列 | 官方快照中的代表能力 | 典型优势 | 典型取舍 |
|---|---|---|---|
| OpenAI GPT 系列 | 当前快照中官方目录首位已是 GPT-6 Astra（滚动开放中，非全量可用）；已全量可用的档位以 GPT-5.6 Sol 作为复杂推理和编码旗舰，GPT-5.6 Terra 平衡智能与成本，GPT-5.6 Luna 面向成本敏感的高吞吐负载；GPT-5.3-Codex 面向编码智能体 | 通用推理、代码与工具生态成熟 | 按 Sol、Terra、Luna 的能力与成本边界分层评估；价格和可用性按模型 ID、账号层级、缓存、区域与服务层级核验 |
| Anthropic Claude 系列 | 当前快照记录 2026-09-01 发布的 Claude Fable 5.1 与 Mythos 5.1 已进入当前阵容（Mythos 5.1 与 Mythos 5 同样非普遍可用，仅通过 Project Glasswing 向获批客户受限开放）；Claude Fable 5 已随之移入 legacy；并收录面向所有套餐和 API 发布的 Claude Sonnet 5 与 2026-07-24 发布的 Claude Opus 5（官方模型页的 legacy 区间现含 Fable 5、Opus 4.8/4.7/4.6/4.5 与 Sonnet 4.6/4.5） | 长文理解、代码与写作稳定性 | 同时核验能力规格、访问状态、区域路由、缓存、批处理和实际账号可用区 |
| Google Gemini 系列 | 当前快照中稳定 Flash 序列的最新一档是 Gemini 3.8 Flash，此前的 Gemini 3.5 Flash 仍在目录中；具体 token limits 由附录引用的官方模型页维护 | 多模态与长上下文任务 | 区分 stable 与 preview，并在部署前确认模型字符串、弃用计划和区域可用性 |
| Meta Llama 系列 | Meta 官方模型卡显示 Llama 4 Scout 为 10M context、Llama 4 Maverick 为 1M context；实际托管服务可能给出更低上限 | 私有化与可定制能力 | 需要自行评估部署、显存、量化和服务商限制 |
| Qwen / DeepSeek 等开源或开放 API 系列 | 上下文窗口、价格和工具能力随具体模型、服务商和部署方式变化 | 中文、多语言或推理性价比突出 | 需结合官方文档、模型卡和本地压测确认 |
2.4.2 选择模型的考量因素
上下文需求 任务类型 成本 延迟要求
2.4.3 长上下文性能评测
- Needle in a Haystack (NIAH)：在长文档中插入特定信息，测试模型能否准确检索。现代长上下文模型在简单单针任务上可能接近饱和，因此还应结合多针、聚合、多跳和干扰证据任务
- RULER：更全面的长上下文评测基准，包含多种任务类型：检索、聚合、跟踪等
- LongBench：中英文双语长上下文基准，覆盖问答、摘要、代码等多种场景
2.5 SSM vs Transformer 在上下文工程中的对比
2.5.1 引言: 架构之战如何影响上下文策略
- 自注意力复杂度：Transformer 为 O(n²)，SSM 为 O(n)
- 上下文长度成本：长上下文下，Transformer 费用陡增，SSM 线性增长
- 信息流向：Transformer 全局互注，SSM 线性扫描
- 检索策略：需要不同的优化方向
2.5.2 Transformer自注意力机制和上下文成本
Transformer 的核心是自注意力（Self-Attention）机制。对于长度为 n 的上下文序列，注意力的计算方式为：
| |
Q,K,V来自同一个source即为input(这里有关于transformer的理解,自己去看笔记)
成本特征:
- 时间复杂度:O(n ^2),n为上下文长度
- 空间复杂度:朴素训练实现会产生 O(n²) 注意力中间状态；现代推理通常通过内核优化避免长期保存完整注意力矩阵，但 KV Cache 仍随上下文长度线性增长
- 每个token的成本随上下文线性增长:第 i 个 Token 需要计算与所有(i-1)个前序 Token 的注意力
Attention中的上下文丢失问题
注意力分散的问题:导致Transformer理论上能看到所有内容,但是在实际应用中,会对关键信息注意力不足.存在"Lost in the Middle"现象