#模块二：Tokenizer、Embedding、位置编码与上下文窗口知识点
一、Tokenizer 是模型的输入协议，不只是文本预处理
大模型不能直接读字符串，第一步一定是把文本切成 token，再把 token 映射成整数 ID。这个过程叫 tokenization。它决定了同一句话在模型眼里有多长、哪些片段被当成稳定单位、哪些罕见词会被拆碎，也决定了训练和推理的计费单位。面试里不要把 tokenizer 说成“分词器”就结束，因为它实际是模型、词表、embedding table、训练数据分布和部署接口之间的长期契约。模型训练好以后，随便更换 tokenizer，等于改变了输入 ID 的语义，原来的 embedding 行、位置分布和 token 长度统计都会失效。
二、BPE、WordPiece、SentencePiece 怎么区分
BPE 的直觉是从更小单位开始，反复合并语料中最常见的相邻片段，例如把 low 和 er 合成 lower，最终得到一个大小受控的子词词表。它简单、工程成熟，很多自回归模型采用 byte-level BPE，使任意字符都能被编码，避免真正的 OOV。代价是某些语言或符号组合会被切得很碎。
WordPiece 也构建子词词表，但选择合并时更强调对训练语料似然的提升，而不只是局部频次。BERT 系列常见的 ##ing 这类标记表示该片段接在词内部。它通常依赖预分词，对英文词形变化很友好，但对无空格语言、混合符号和代码场景需要额外规范化。
SentencePiece 更像一个“端到端文本到子词”的框架，不强依赖空格预分词，常把空格也编码成普通符号。它可以实现 BPE 或 unigram language model，适合中日文、多语言和混合语料。核心差异可以这样记：BPE 关注频繁片段合并，WordPiece 关注子词组合对似然的贡献，SentencePiece 关注不依赖外部分词器的统一训练流程。
三、Token 粒度影响中文、英文、代码、成本和上下文
token 粒度是一个三方权衡：太粗，词表变大、长尾词难覆盖、embedding 参数膨胀；太细，同一段内容 token 数暴涨，训练和推理成本上升，长上下文里可放的信息减少。英文有空格，子词通常能较自然地覆盖词根、前后缀和常见词；中文没有显式空格，如果 tokenizer 偏向字级，语义单位会被拆散，如果偏向词级，又会遇到新词、人名、术语和中英混排问题。
代码场景更敏感。标识符、缩进、括号、操作符、路径、版本号和驼峰命名都可能被切成很多 token。比如一个长函数名或 JSON key 被拆碎后，模型需要跨多个 token 才能恢复“这是同一个变量”的概念，复制、编辑和对齐都更难。成本上也很直接：API 按 token 计费，attention 和 KV cache 也按 token 扩张。同样 10KB 文本，中文、英文、代码、日志的 token 数可能差很多，所以上下文窗口不是字符窗口，而是 token 窗口。
四、Embedding table 与 contextual representation
token ID 进入模型后，第一站是 embedding table。它本质上是一个矩阵：每一行对应一个 token 的可训练向量。查表后得到的是该 token 在进入 Transformer 之前的初始表示，可以理解为“这个离散符号的基础坐标”。它不是句子语义，也不知道当前上下文。
contextual representation 是经过多层 Transformer self-attention 和 MLP 更新后的隐藏状态。它会融合左右文或前文信息，因此同一个 token 在不同句子里的表示可以完全不同。Word2Vec 这类静态 embedding 通常给一个词一个固定向量，难以区分“苹果公司”和“吃苹果”；大模型里的 contextual representation 会根据上下文把它们推向不同语义区域。面试回答时要明确：embedding table 是输入层参数，contextual embedding 是模型计算后的动态状态。
五、位置编码：从“第几个”到“相距多远”
Transformer 的 attention 本身对顺序不敏感，如果不加位置信息，“我喜欢你”和“你喜欢我”的 token 集合很像。绝对位置编码给每个位置一个编号相关向量，可以是固定正弦编码，也可以是可训练向量，然后与 token embedding 相加。它表达“这是第 37 个 token”，实现简单，但训练长度外的位置往往缺少可靠表示。
相对位置编码更关注 token 之间的距离，例如当前位置和被关注位置相隔多少。它更贴近 attention 的比较过程，因为 attention 分数本来就在判断 token 两两之间的关系。ALiBi 用距离相关偏置惩罚远距离注意力，RoPE 则把位置信息注入到 query 和 key 的几何关系里。二者都比朴素绝对位置更适合讨论长上下文。
RoPE 的核心不是把位置向量加到 token embedding 上，而是对每个位置的 Q 和 K 做旋转。位置越靠后，旋转角度越大；两个 token 做内积时，attention 分数自然包含相对位移信息。它适合自回归模型，能优雅表达相对位置，也方便做位置插值、NTK-aware scaling、YaRN、LongRoPE 等长上下文扩展。但 RoPE 不是无限外推保证：当推理长度远超训练长度，旋转相位、频率尺度和训练分布都会变成问题。
六、Context window、外推与有效利用
context window 指一次推理中模型可见的最大 token 数，包括系统提示、用户输入、检索材料、工具返回、中间推理痕迹和已生成输出。它重要，是因为长文阅读、代码仓库理解、RAG、Agent 记忆和多轮对话都依赖“能看见足够多上下文”。但窗口大小不等于有效能力。一个模型标称 128K，不代表它能稳定利用 128K 中任意位置的证据；常见问题是 lost in the middle：开头和结尾的信息更容易被用到，中间证据容易被忽略。
长上下文外推难在三层。第一，训练时很少见到那么长的序列，模型没有充分学会长距离依赖。第二，attention 计算随序列长度增加而变贵，prefill 阶段近似按 \(O(n^2)\) 增长。第三，位置编码的数值规律可能超出训练分布，RoPE 的相位在超长位置上会产生不稳定或分辨率下降。因此扩窗通常不是把 max length 改大，而要结合长序列数据、位置缩放、注意力优化和评测。
回答这类题时，最好把“能放下”和“能用好”分开。能放下是接口、显存和调度问题，能用好是训练覆盖、证据位置、注意力分配和指令遵循问题。很多失败不是模型没看见材料，而是关键证据被噪声包围、排在弱位置，或问题需要多跳组合但模型只抓住了局部片段。
七、KV cache 是长上下文的主要成本来源
自回归解码时，每生成一个新 token，都需要和历史 token 做 attention。为了避免重复计算历史 token 的 K 和 V，系统会缓存每层的 KV，这就是 KV cache。它的占用近似和 batch * seq_len * layers * kv_heads * head_dim * 2 成正比，还要乘数据类型字节数。参数量固定不代表推理显存固定；序列越长、batch 越大，KV cache 越容易先打爆显存。
这也解释了为什么长上下文服务很贵。128K 输入不仅 prefill 慢，而且会留下巨大的 cache，后续每步解码都要访问更长的历史。工程上会用 GQA/MQA 降低 kv heads，用 paged attention 管理碎片，用 prefix caching 复用共享前缀，用 KV 压缩、驱逐或滑窗注意力控制成本。面试回答里要把“上下文窗口成本”从模型参数成本里拆出来讲。
八、RAG 与长上下文不是谁替代谁
长上下文的优势是简单直接：把材料放进去，模型可以跨文档综合，减少检索漏召回带来的硬失败。缺点是成本高、延迟高、证据排序难、无关内容会稀释注意力。RAG 的优势是先检索再生成，只把高相关片段放入上下文，成本低、可更新、可溯源，也便于权限控制；缺点是检索、切块、重排、引用定位任何一环出错，模型就看不到关键证据。
实际系统常用组合策略：用 RAG 找候选证据，用 reranker 排序和去重，再把最关键材料放在提示的强位置；对于需要全局一致性的合同、代码 diff、长会议纪要，可以利用长上下文保留更多原文。判断标准不是“窗口越大越好”，而是任务是否需要全量上下文、证据是否可检索、延迟预算是否允许、答案是否要求引用可追踪。
面试中可以把取舍落到三个具体问题上。第一，知识是否频繁更新：频繁更新的业务知识更适合 RAG，因为不必重新训练或持续塞进超长提示。第二，答案是否需要严格证据：需要引用原文、审计和权限隔离时，检索链路更容易做可观测性。第三，任务是否需要跨全文推理：如果问题依赖大量分散线索，长上下文能减少切块带来的信息断裂。好的系统通常不是单选，而是用检索控制候选范围，用长上下文提供综合空间，用引用和评测约束输出质量。
九、常见误区
- 误区一：token 等于词。实际 token 可能是字、子词、字节、符号或空格片段。
- 误区二：换 tokenizer 只是换预处理。实际会破坏 token ID、embedding、训练分布和服务兼容性。
- 误区三：embedding table 就是模型理解。真正的语义通常来自多层上下文计算后的 hidden states。
- 误区四：RoPE 能自然支持无限长度。RoPE 有相对位置优势，但长外推仍需要缩放、数据和系统优化。
- 误区五：上下文越长，RAG 越不重要。长上下文解决“放得下”，RAG 解决“找得准、可更新、可引用、成本可控”。
十、复盘清单与追问链路
复盘时按这条线检查：第一，能否解释文本如何变成 token ID，BPE、WordPiece、SentencePiece 的差异是什么；第二，能否说明 token 粒度如何影响中英文、代码、计费和有效上下文；第三，能否区分 embedding table、静态词向量和 contextual representation；第四，能否从 absolute、relative 讲到 RoPE，并说明 RoPE 为什么在 Q/K 上旋转；第五，能否把 context window、long-context extrapolation、lost in the middle、KV cache、RAG 取舍放到同一套工程成本框架里。
追问链路通常会从“为什么不能按词切”进入 tokenizer，再追到“中英文混合为什么 token 数差异大”；随后转向“token ID 之后发生什么”，要求你区分 embedding table 和 hidden state；再问“Transformer 为什么需要位置编码”，引出绝对、相对和 RoPE；最后落到系统题：“8K 扩到 128K 为什么贵，KV cache 怎么算，RAG 还要不要”。能把这条链路讲顺，就说明你理解的是输入表示到推理系统的完整路径，而不是背了几个名词。