ARTICLE · 1325955
AI Agent 知识点分享系列|第 11 篇:Transformer、Tokenization 与成本意识
本篇属于「AI Agent 知识点分享系列」，覆盖知识点 51–55。内容从自注意力、复杂度、分词与成本估算出发，建立 Agent 工程师必需的上下文、Token 和长文本成本直觉。
本篇概览
Agent 工程师不一定需要训练模型，但一定要理解三件事：上下文怎么算、Token 怎么计费、长文本为什么变贵。
整体关系：
文本↓ Tokenizer 切成 TokenToken 序列↓ 自注意力计算 Token 间关系注意力矩阵 / KV Cache↓计算成本、显存占用、首 Token 延迟、生成成本↓Agent 的上下文预算、检索策略、缓存策略和模型选型
一句话原则：
上下文不是免费的文本仓库，而是按 Token 计量、按注意力计算的工作内存；设计 Agent 时必须像管理内存一样管理它。
知识点 51：为什么 Agent 工程师要理解自注意力
一句话总结：自注意力决定每个 Token 如何从上下文中聚合信息，也决定了长上下文为什么更贵、更慢、更容易丢失中间信息；理解它有助于设计上下文分层、记忆检索、缓存和长任务架构。
先说人话：开会时每个人都能看别人的发言
一句话里的每个词，不是孤立理解的。比如“苹果发布了新手机”，理解“苹果”需要结合“发布”“手机”；理解“银行”要看它是金融机构还是河岸。
自注意力就是让每个 Token 动态地看其他 Token，并决定“应该关注谁”。
Q、K、V 的直觉
Attention(Q, K, V) = softmax(QKᵀ / √d) · V可以把它理解成：
当前 Token 用自己的 Query 去匹配所有 Key； 得到一组注意力权重； 用权重加权汇总对应的 Value； 形成新的上下文表示。
多头注意力
单个注意力头只能表达一种关注方式。多头注意力让模型同时关注：
语法关系； 指代关系； 位置关系； 实体关系； 任务指令。
不同头学到的模式不同，最后拼接起来形成更丰富的表示。
因果注意力
生成式模型通常使用因果掩码：第 t 个 Token 只能看到自己和之前的 Token，不能偷看未来。这保证训练和推理一致，也让 KV Cache 可以按历史顺序复用。
为什么长上下文会出问题
注意力需要处理更多 Token 对； 噪声和无关内容竞争注意力； 中间位置的信息可能被忽略； 指令和证据被大量文本稀释； KV Cache 占用显存，影响并发。
这也解释了为什么“窗口能放 128K”不等于“能稳定使用 128K”。
对 Agent 架构的影响
案例：长合同审查失败
Agent 把 100 页合同一次塞入上下文，却漏掉中间的关键条款。不是模型“没看到”，而是：
关键条款周围有大量相似文本； 审查指令在开头，长文档后权重下降； 模型没有引用具体段落； 输出只写结论。
改造后按章节检索、给条款编号、要求引用原文、在结尾复述验收标准，问题才可控。
实施清单
把上下文当成有限预算。 区分系统规则、工具、证据和历史。 长文档优先检索和分段。 关键约束放开头并复述。 关键证据要求引用。 长会话定期压缩。 监控 TTFT、Token 成本和上下文长度。
一句话记住
不懂注意力也能调 API，但很难做好上下文和成本架构；窗口是工作内存，不是免费硬盘。
知识点 52：自注意力的复杂度与长上下文成本
一句话总结：标准自注意力的计算复杂度近似 O(n²·d)，序列长度翻倍时注意力计算通常接近四倍；KV Cache 虽减少重复计算，但显存随长度增长。长上下文 Agent 必须把全量塞入视为昂贵方案，优先检索、摘要、分段和缓存。
先说人话：人越多，两两握手次数增长越快
3 个人两两交流有 3 对；10 个人有 45 对；100 个人有 4950 对。人数翻 10 倍，关系数约翻 100 倍。
自注意力类似：每个 Token 都要和序列中的 Token 交互，序列变长，注意力计算近似平方增长。
复杂度公式
对于长度 n、隐藏维度 d：
QKᵀ 计算：约 O(n² · d)注意力加权 V：约 O(n² · d)总注意力计算：约 O(n² · d)
朴素注意力还需要保存 n × n 的注意力矩阵，显存也近似 O(n²)。实际推理框架会用分块、FlashAttention 等技术降低中间显存，但长序列的计算和缓存压力仍然显著。
长度翻倍意味着什么
这是相对注意力的粗略直觉，实际总耗时还受矩阵并行、硬件和推理框架影响，但趋势成立：长上下文不是线性变贵。
Prefill 与 Decode
长 Prompt 的 Prefill 会显著增加首 Token 延迟。生成长输出时，Decode 又会持续占用缓存和显存。
KV Cache 的复杂度
KV Cache 大小近似：
2 × 层数 × KV Head 数 × Head 维度 × 序列长度 × Batch × 字节数它与序列长度近似线性增长。虽然比朴素的 O(n²) 注意力矩阵更可控，但长上下文仍然会降低并发数。
多轮 Agent 的累计成本
如果每轮都携带完整历史：
第 1 轮：n第 2 轮：2n第 3 轮：3n...第 k 轮：kn累计约 O(k²·n)
这就是长会话越聊越贵、越聊越慢的常见原因。
工程优化顺序
去掉重复历史； 裁剪工具结果； 滚动摘要； 检索相关证据； 分段处理； 启用缓存； 再考虑更大窗口模型。
案例：把整本手册塞进每次请求
一个客服 Agent 每次请求都带 80K Token 手册，连续 10 轮后成本和延迟飙升。改造为：
手册按章节索引； 仅检索当前问题相关段落； 最近对话保留原文； 旧对话做摘要； 固定前缀启用缓存。
输入长度下降，回答质量反而更稳定。
常见误区
实施清单
记录每轮上下文长度。 分离 Prefill 和 Decode 指标。 设置输入 Token 上限。 超限触发摘要或检索。 监控 KV Cache 和并发。 用真实任务测长上下文收益。
一句话记住
长上下文不是免费的硬盘，而是按平方付费的工作台；能检索就不要全量塞，能摘要就不要重复带。
知识点 53：Tokenization 与中文 Token 消耗
一句话总结：Tokenization 是模型把文本切成子词、字节或其他片段的预处理过程，模型看到的是 Token ID 而不是字符；中文、代码、JSON、emoji 和特殊符号的切分效率不同，同样语义的 Token 消耗可能差异很大。
先说人话：模型不是按“字”读书
人看到“人工智能”是四个汉字；模型可能看到：
一个完整词 Token； 两个词 Token； 多个字节片段； 甚至字符与空格组合。
不同模型有自己的词表，切法不同，计费和上下文占用也不同。
Tokenizer 做了什么
原始文本↓ 规范化（大小写、空格、Unicode 等，取决于模型）↓ 切分为子词/字节片段↓ 映射为 Token ID模型输入
模型只处理 Token ID。文本长度、字符数和 Token 数不是同一个概念。
中文为什么会不同
中文常用字可能：
被作为单个 Token； 与其他字组成词 Token； 被拆成 UTF-8 字节片段； 在词表覆盖不足时拆得更碎。
因此“1 个汉字 = 1 Token”也是不准确的。常用表达可能更紧凑，生僻字、特殊符号和空格格式可能更碎。
不同内容的 Token 密度
代码和 JSON 为什么贵
一段 JSON：
{”order_id”:”SO-20261102-001”,”amount”:1999.00,”currency”:”CNY”}对人类来说结构清楚，但 tokenizer 可能把：
order_id拆成多个子词； 引号、冒号、逗号算独立 Token； 日期和订单号被拆成数字/符号片段； 小数点和末尾零产生额外 Token。
所以工具 Schema 和结构化输出往往比自然语言更占空间。
模型之间不能直接复用估算
不同厂商、不同模型版本可能使用不同词表和切分规则。在一个模型上测到的 Token 数，不能直接套到另一个模型。
工程建议
用目标模型的 tokenizer 实测。 对系统提示、工具 Schema 和历史分别计量。 为中文和代码保留更高预算余量。 压缩重复模板和客套话。 长数字和 ID 用结构化字段，不靠自然语言重复。 记录 API 返回的真实 usage。
案例：同一个模板换模型后超预算
团队按模型 A 的 Token 数设计 Prompt，迁移到模型 B 后超出上下文。因为模型 B 对中文和代码符号切分更碎。修复方式是重新用模型 B 的 tokenizer 计量，并为工具 Schema 单独设置预算。
一句话记住
计费单位是 Token，不是字数，更不是“感觉差不多”；跨模型必须重新测。
知识点 54：字符数除以四为什么估算不准
一句话总结：字符数除以四只适用于部分英文文本的粗略估算，面对中文、代码、JSON、URL、长数字、emoji 和工具 Schema 时误差会明显扩大；成本敏感系统应使用目标 tokenizer 实测，并在预算中保留安全余量。
先说人话：用身高估体重，只适合一部分人
“字符数 ÷ 4 ≈ Token 数”来自一些英文文本的经验。它对普通英文文章可能勉强可用，但遇到其他内容就像用身高估体重：方向有点关系，精度完全不够。
为什么会有“除以四”
部分英文 tokenizer 中，常见单词和子词组合效率较高，平均约几个字符一个 Token。但这是统计平均，不是模型规则。
哪些情况偏差大
一个正确的预算流程
准备典型 Prompt 样本↓用目标模型 tokenizer 统计↓按系统/工具/历史/输入/输出分项↓加上 10%–30% 安全余量↓运行时用 API usage 校准↓定期更新模型版本基准
安全余量不是浪费，而是防止：
中文比预期更碎； 工具返回超长； 输出被截断； 不同租户数据差异； tokenizer 版本变化。
成本估算公式
单次成本 ≈输入 Token × 输入单价+ 输出 Token × 输出单价+ 缓存/推理 Token 成本+ 重试和工具调用成本
字符估算只能用于早期粗排，不能作为账单预测。
案例：中文客服预算翻倍
团队按“英文 4 字符 ≈ 1 Token”估算中文客服 Prompt，结果实际 Token 数高出 60%。原因是中文、订单号和 JSON 工具结果都更碎。改用目标 tokenizer 实测后，预算才准确。
实施清单
建立真实 Prompt 样本库。 用目标 tokenizer 计量。 分项统计 Token。 设置安全余量。 用 API usage 校准。 模型变更后重新估算。 不把字符估算写进财务模型。
一句话记住
字符估算是拍脑袋，tokenizer 计量才是成本依据；中文和代码尤其不能套英文比例。
知识点 55：BPE 分词的原理与意外现象
一句话总结：BPE 通过反复合并高频相邻符号构建子词词表，在词表大小和未登录词覆盖之间取得平衡；它会让数字、空格、大小写和拼写计数出现反直觉现象，因此精确计算和字符级操作应交给代码工具。
先说人话：把常见组合做成积木
BPE 像搭积木：
一开始每个字符都是小积木； 统计哪些相邻积木经常一起出现； 把高频组合合并成更大的积木； 重复很多轮，形成词表。
这样常见词可以一个 Token 表示，罕见词则拆成多个子词。
BPE 训练直觉
假设语料中 t 和 h 经常相邻，th 会被合并；接着 th 和 e 经常相邻，the 可能成为新 Token。最终词表里既有完整词，也有常见片段。
为什么未登录词还能处理
即使一个词没在词表里，也可以拆成更小的子词或字节：
unbelievable → un + believe + able这样模型不必为每个词准备一个 Token。
反直觉现象
长数字、日期、金额可能被切成不规则片段。模型做逐位比较或精确算术时容易出错。
有些 tokenizer 把前导空格和后一个词合并，导致格式匹配和截断行为与直觉不同。
Apple 和 apple 可能切分不同，影响精确匹配。
模型看到的是子词碎片，不天然拥有字符级视图。问“strawberry 有几个 r”，它可能需要额外推理或容易数错。
对工程的启示
案例：模型数错订单号位数
用户要求提取 18 位订单号。模型输出少了一位，因为它把连续数字当成整体片段，没有逐位核对。修复：
用正则提取； 校验长度和校验位； 模型只负责定位字段； 最终结果由代码确认。
常见误区
实施清单
需要精确字符操作时用代码。 数字、ID、金额做结构化和校验。 用目标 tokenizer 检查边界。 避免让模型做长数字心算。 对格式模板做实际切分测试。 记录 Token 化后的长度。
一句话记住
模型看到的是子词碎片，不是人眼里的完整字符串；精确计数和算术，交给代码。
本篇小结
本篇原则：
先理解 Token 怎样进入模型，再理解注意力怎样处理它，最后才能准确估算成本、设计上下文和选择工具。
下一篇将分享知识点 56–60，继续讨论 KV Cache、Prompt Caching 与上下文窗口。
