Token 与 Embedding

1. 学习目标

理解 Token、Tokenizer、词表（Vocabulary）和 Embedding 的职责边界；
能够解释 BPE、Unigram 等子词方案为什么能兼顾开放词表与计算成本；
能从张量维度说明 Token ID 如何变成模型输入，并计算参数量与复杂度；
能实现一个最小文本向量化和余弦相似度检索实验；
能排查 Tokenizer 不匹配、截断、Padding 污染、特殊 Token 配置错误等工程问题。

2. 面试结论

2.1 30 秒回答

Tokenization 负责把原始文本按配置好的规则转换为离散 Token ID，Embedding 再用可训练矩阵把每个 ID 映射成连续向量。生产推理在关闭子词采样并固定完整配置时通常是确定性的；训练增强可显式启用 Subword Sampling 或 BPE Dropout。子词切分在“整词词表过大”和“字符序列过长”之间折中；输入 Embedding 只表示查表后的初始向量，经过 Transformer 后才成为依赖上下文的表示。Tokenizer 配置、词表、特殊 Token 和模型权重必须版本一致，否则即使服务不报错，语义也会被系统性破坏。

2.2 一分钟复述版

一条文本进入 LLM 前，通常先经过规范化、预切分、子词模型、特殊 Token 拼接，再得到形状为 $[B, n]$ 的 ID 张量。模型用词嵌入矩阵 $E \in R^{V \times d}$ 查表，得到 $[B, n, d]$ 的向量，并加入或融合位置信息。这里 $V$ 是词表大小， $d$ 是隐藏维度。子词算法降低未知词问题，但词表越大，Embedding 和输出层参数越多；切分越细，序列越长，Attention 成本越高。项目中要固定 Tokenizer 版本，显式记录截断和特殊 Token，池化时排除 Padding，并区分“模型内部 Token Embedding”和“用于检索的句向量 Embedding”。

3. 面试官为什么问

核心考察点：是否真正理解 LLM 的输入边界，而不是只会调用 generate 或 Embedding API；
实现能力：能否说清 ID、Embedding 矩阵、Mask、位置编码的张量形状；
工程经验：是否见过上下文超限、Tokenizer 版本漂移、多语言切分异常和错误池化；
系统设计能力：能否在词表规模、序列长度、质量、显存和吞吐之间做权衡；
优秀回答的区分度：主动区分静态 Token Embedding、上下文化表示和检索句向量，并给出验证方法。

4. 概念与边界

小白先这样理解：一句话如何进入“乐高仓库”

想象你要用乐高拼出“人工智能真有趣”。分拣员不会为每句话制造一块新积木，而会按固定规则拆成可复用的大小块，贴上编号，再去仓库取出该编号对应的“可学习坐标卡”。之后的模型处理的正是这些数字卡，而不是原始文字。

生活角色 → 技术概念： 分拣规则是 Tokenizer，积木块是 Token，货架编号是 Token ID，仓库总表是 Embedding 矩阵，取出的坐标卡是 Token Embedding 向量。

类比边界： Embedding 不是人工绘制且永不变的地图，而是训练中学得的参数；单个 Token 的初始向量也不含完整上下文语义，还需后续 Transformer 结合位置和前后文。

4.1 是什么

Token：Tokenizer 规则下的离散符号，可能是字、子词、标点、字节片段或特殊标记，不等同于“一个汉字”或“一个英文单词”；
Tokenizer：从文本到 Token/ID、以及从 ID 到文本的处理流水线；固定规范化、预切分、子词模型、Added Tokens、特殊 Token 和采样开关时，生产编码通常确定；显式启用 Subword Sampling/BPE Dropout 时可产生随机切分；
Vocabulary：Token 到整数 ID 的映射集合；
Token Embedding：按 ID 从可训练矩阵中取出向量；
Positional Encoding/Embedding：为无递归的序列模型注入顺序信息；
Sentence Embedding：将整句或整段压缩为一个向量，通常需要专门训练目标和池化策略。

4.2 不是什么

Token 数不能稳定地由字符数或单词数换算，必须用目标模型的实际 Tokenizer 计算；
Token Embedding 不是天然可用于语义检索的句向量；简单平均能做教学实验，但不等于生产级检索模型；
Embedding 维度更高不保证语义质量更好，质量取决于数据、目标函数、模型与评测；
子词方案降低未知词风险，但不会自动解决乱码、Unicode 规范化或跨语言效果问题；
位置编码不是 Tokenizer 的组成部分，它发生在模型输入侧。

4.3 解决什么问题

自然语言是开放集合，而神经网络需要有限、可索引、可批处理的输入。Tokenizer 将开放文本映射到有限词表；Embedding 则把离散 ID 转换为可以参与矩阵运算、通过梯度学习的连续表示。

4.4 输入、输出与前置条件

环节	输入	输出	关键前置条件
文本规范化	Unicode 文本	规范化文本	训练与推理规则一致
子词切分	规范化文本	Token 序列	固定的词表与模型文件
ID 映射	Token 序列	`input_ids: [B,n]`	Token 与 ID 映射不漂移
Padding/Truncation	不等长 ID	定长批次与 `attention_mask`	最大长度和截断方向明确
Embedding 查表	`input_ids: [B,n]`	`X: [B,n,d]`	ID 满足 $0 \leq i d < V$

4.5 与相近概念的区别

概念	粒度	是否依赖上下文	常见用途
One-hot	单 Token	否	概念教学，实际存储通常不用稠密 One-hot
Token Embedding	单 Token 初始表示	否	Transformer 输入
Hidden State	每个位置	是	生成、分类、抽取
Sentence Embedding	句/段	是，且通常专门训练	语义检索、聚类、去重
Positional Encoding	位置	不读取词义	注入顺序信息

5. 原理剖析

5.1 直觉理解

整词词表像一本只允许收录固定单词的字典：词表会很大，生僻词仍可能不在其中。纯字符方案几乎不会遇到未知词，但一句话会被切得很长。子词方案把常见片段保留为整体、把罕见词拆得更细，在词表大小和序列长度之间折中。

5.2 核心流程

图 1：文本进入 Transformer 前的数据流替代文本： 原始文本依次经过规范化、子词切分、ID 映射、特殊 Token、Padding/截断、Embedding 与位置表示，形成模型输入张量。

图表加载中…

读图结论： Tokenizer 的输出不是“字符串列表”就结束了，模型真正消费的是与 Mask、特殊 Token 和位置规则一致的 ID/向量张量。

以 BPE 为例，训练阶段从较小符号集合出发，反复合并语料中高频相邻符号对，直到达到目标合并次数或词表规模；编码阶段按已学习的合并规则切分。Unigram 则从候选子词集合出发，以概率模型和似然目标选择更合适的切分，并逐步裁剪词表。二者目标相近，但训练与解码机制不同。

5.3 数学、张量维度与位置表示

设：

批大小为 $B$ ；
序列长度为 $n$ ；
词表大小为 $V$ ；
隐藏维度为 $d$ ；
input_ids 为 $I \in {0, \dots, V - 1}^{B \times n}$ ；
Embedding 矩阵为 $E \in R^{V \times d}$ 。

查表结果为：

X_{b, t, :} = E_{I_{b, t}, :}, X \in R^{B \times n \times d}

Embedding 参数量是 $V d$ 。若语言模型输出层不与输入 Embedding 权重共享（weight tying），输出投影还需要一组约 $d V$ 的权重；是否共享由具体架构决定。

两向量的余弦相似度为：

\cos (u, v) = \frac{u^{⊤} v}{‖ u ‖_{2} ‖ v ‖_{2}}

它比较方向而弱化模长影响，但没有专门语义训练时，相似度不一定符合业务语义。

教学插图：概念性的 Embedding 语义空间

动物、水果和交通工具分别形成相对接近的概念簇

替代文本： 猫与狗、苹果与橙子、汽车与火车分别在概念性三维空间中靠得更近，不同类别的簇相距较远，用来直观表示“向量距离可以承载某种相似性”。

读图结论： Embedding 把离散对象映射到连续空间，使相似度可以计算；但图中的三维位置只是高维空间的教学投影，真实距离取决于模型、训练目标、版本和归一化方式。

这张图不能证明模型已经“理解”概念，也不能把 Token Embedding、上下文化 Hidden State 和专门训练的 Sentence Embedding 混为一谈。

原始 Transformer 的固定正弦位置编码写作：

P E (p o s, 2 i) = \sin (p o s / 10000^{2 i / d})

P E (p o s, 2 i + 1) = \cos (p o s / 10000^{2 i / d})

其中 $p o s$ 是位置， $i$ 是维度索引。现代模型还可能使用可学习位置 Embedding、RoPE 或相对位置偏置；它们不能互换加载，必须服从模型架构和权重配置。

5.4 复杂度与关键假设

Embedding 查表输出 $B n d$ 个元素，时间与写出这些元素的成本近似为 $O (B n d)$ ，参数内存为 $O (V d)$ ；
对 $N$ 个已归一化候选向量做暴力余弦检索，查询时间为 $O (N d)$ ，存储为 $O (N d)$ ；近似最近邻索引用额外结构换取更低查询延迟，但可能牺牲召回；
Tokenization 的精确复杂度依算法和实现而异，不能一概声称为严格 $O (n)$ ；工程上应基于目标实现做基准；
切分更细会增大序列长度，而标准 Self-Attention 的注意力矩阵随 $n^{2}$ 增长；因此词表大小与上下文计算成本存在耦合；
余弦相似度成立的前提是向量来自同一模型、同一版本和一致的归一化/池化流程。

6. 实现与代码

6.1 最小可运行 PyTorch 示例

运行环境：Python 3.10+、PyTorch 2.x。示例手工构造词表，用 Masked Mean 得到句向量，再做余弦检索；它用于验证维度与 Padding 处理，不代表生产级语义模型。

python

import torch
import torch.nn.functional as F

torch.manual_seed(7)

PAD, UNK = "<pad>", "<unk>"
vocab = {PAD: 0, UNK: 1, "AI": 2, "学习": 3, "检索": 4, "视频": 5}
embedding = torch.nn.Embedding(
    num_embeddings=len(vocab),
    embedding_dim=4,
    padding_idx=vocab[PAD],
)


def encode(tokens, max_length=4):
    ids = [vocab.get(token, vocab[UNK]) for token in tokens][:max_length]
    mask = [1] * len(ids)
    pad_count = max_length - len(ids)
    return ids + [vocab[PAD]] * pad_count, mask + [0] * pad_count


def masked_mean(input_ids, attention_mask):
    # input_ids: [B, n] -> token_vectors: [B, n, d]
    token_vectors = embedding(input_ids)
    weights = attention_mask.unsqueeze(-1).to(token_vectors.dtype)  # [B, n, 1]
    summed = (token_vectors * weights).sum(dim=1)                    # [B, d]
    counts = weights.sum(dim=1).clamp_min(1.0)                      # [B, 1]
    return F.normalize(summed / counts, p=2, dim=-1)                # [B, d]


texts = [["AI", "学习"], ["AI", "检索"], ["视频"]]
encoded = [encode(tokens) for tokens in texts]
ids = torch.tensor([item[0] for item in encoded], dtype=torch.long)
mask = torch.tensor([item[1] for item in encoded], dtype=torch.long)
vectors = masked_mean(ids, mask)
scores = vectors[0] @ vectors[1:].T

assert ids.shape == (3, 4)
assert vectors.shape == (3, 4)
assert torch.isfinite(vectors).all()
print("input_ids =", ids.tolist())
print("query 对候选的余弦相似度 =", scores.tolist())

6.2 关键实现说明

input_ids 必须是整数类型且范围落在词表内；
padding_idx 让 Padding 行在训练时不更新，但池化仍应显式使用 Mask；
attention_mask.unsqueeze(-1) 将 $[B, n]$ 扩为 $[B, n, 1]$ ，从而按 Token 屏蔽所有维度；
clamp_min(1.0) 防止全 Padding 输入产生除零；真实系统通常应在入口直接拒绝空文本；
句向量归一化后，点积等于余弦相似度。

6.3 边界条件与验证

增加空文本、未知 Token、超长输入、全角/半角字符、组合 Unicode 字符测试；
比较有无 Mask 的池化结果，确认 Padding 不污染向量；
序列化并重新加载 vocab 与模型，验证同一文本的 ID 完全一致；
生产中使用专门 Embedding 模型时，固定模型版本、池化、归一化和最大长度，并保存到索引元数据。

6.4 技术栈与横向选型

Token 和 Embedding 是模型与算法概念，不绑定某个框架。下表把教学代码之外的实现拆成三个主技术点：生产系统必须固定 Tokenizer、Embedding 模型与索引指纹，不能只记一个库名。

技术点 ID	技术点/环节	类型	采用方案	链路职责	版本/证据边界
TP-TE-01	子词切分与 ID 映射	库	跟随模型发布物锁定 Tokenizer；`tokenizers` 或 SentencePiece 仅作参考实现	完成规范化、切分、特殊 Token、截断与 ID 转换	词表、特殊 Token 和规范化规则都属于模型契约；目标版本 API 需按官方文档复核
TP-TE-02	句向量编码	框架/模型	Sentence Transformers 生产参考栈；PyTorch 手写池化作最小验证	运行 Encoder、Mask-aware Pooling 和归一化，输出可检索向量	模型是否经过句向量目标训练比库名更重要；质量必须用固定标注集实测
TP-TE-03	向量候选召回	库/存储	FAISS 作单机试验参考；生产按权限、过滤和运维需求选向量服务	按相似度召回候选，并保留原文、元数据和向量版本	FAISS 不自动提供多租户 ACL 和分布式运维；数据规模与过滤基准未实测前不作性能结论

技术点 ID	候选方案	优点	缺点/代价	适用场景	不适用场景	选择结论与依据
TP-TE-01	Hugging Face `tokenizers`	Rust 实现、批处理快，与 Transformers 生态集成直接	模型配置和词表若漂移，即使同名算法也会产生不同 ID	已有 Hugging Face 模型发布物、需高吞吐预处理	目标模型明确使用其他 Tokenizer 契约	优先跟随模型自带配置，不因性能偏好擅自替换
TP-TE-01	SentencePiece	可直接从原始文本训练 BPE/Unigram，跨语言与独立工具链成熟	重训词表会破坏原模型的 Token ID 契约，仍需自行治理配置	自训 Tokenizer、多语种语料或已绑定 SentencePiece 的模型	直接给已训练模型更换词表	只在训练或模型契约需要时采用，切换前做编码回归
TP-TE-02	Sentence Transformers	封装批处理、池化、归一化与常见句向量模型	高层封装可能隐藏截断、Prompt 和 Pooling 差异	通用语义检索原型与生产基线	需自定义多模态结构或研究级中间层控制	默认参考实现，但必须把模型、Pooling 和归一化指纹一起固定
TP-TE-02	Transformers + 自定义 Pooling	中间层、Mask 和 Pooling 策略完全可控	容易遗漏 Attention Mask、归一化或模型特定 Prompt	研究复现、自定义编码头和严格特征实验	只想快速获得稳定句向量基线	只在需要显式控制时使用，并与参考模型输出对齐
TP-TE-03	FAISS	本地可嵌入、索引类型丰富，适合算法实验	权限、元数据、备份与横向扩展需额外工程	单机基准、离线评测、有限数据集	多租户权限和托管运维是一级需求	用于最小验证；进入生产前重新评估数据与运维边界
TP-TE-03	Qdrant	提供服务化检索、持久化与元数据过滤	引入独立服务、容量规划和备份运维成本	需按业务字段过滤、在线更新和多实例部署	数据小且仅做离线研究	只在过滤、可用性和运维收益经基准证明后切换

6.5 架构与技术调用流程

图：架构｜Token 与 Embedding 可回滚编码架构

替代文本： 原始文本经过与模型绑定的 Tokenizer、Encoder、Mask-aware Pooling 和归一化后写入向量索引；注册表同时固定词表、模型、池化和索引版本，评测集在切换前验证新旧链路。

图表加载中…

读图结论： Tokenizer、模型、Pooling 和索引是一个不可随意拆分的版本契约，只有整链路回归通过才能切换索引别名。

架构图表达静态职责与版本边界；向量库只承担候选检索，不能修复错误切分、不同模型的向量混用或缺失的权限元数据。

图：技术调用流程｜文本编码与向量写入时序

替代文本： 摄取服务先获取受控的编码指纹，再调用 Tokenizer 和 Encoder；长文本按契约截断并记录信号，指纹不一致时拒绝混写，全部校验通过后才幂等写入索引。

图表加载中…

读图结论： 成功路径不是“算出向量就写库”，而是在截断、数值和指纹三类边界都可观测后才提交。

时序图表达动态交互：截断是可管理的边界分支，而指纹错配是必须阻断的一致性错误；两者不应被统一重试隐藏。

7. 实际项目案例

示例项目，非真实仓库实现；以下不包含虚构性能指标。

7.1 背景、目标与约束

建设内部技术文档语义检索：用户输入中文或中英混合问题，系统召回相关段落。约束包括文档版本频繁更新、查询可能超过最大长度、Embedding 模型会升级、线上索引不能混用不同向量空间。

7.2 架构与调用链

离线侧解析文档，保留文档 ID、版本、章节和权限元数据；
使用固定版本 Tokenizer 检查长度，再按语义边界切块；
用同一 Embedding 模型、池化和归一化配置生成向量；
写入向量索引，并记录 model_id、tokenizer_hash、dimension、normalized；
在线查询走同版本编码流程，检索后再进行权限过滤或重排；
结果返回文档版本与原文引用，方便验证。

7.3 方案选择与实现难点

不能把 LLM 输入层 Token Embedding 直接当通用检索向量，应选择经过句向量/对比学习训练的模型；
固定字符数切块不能稳定控制 Token 数，应使用实际 Tokenizer 计数并为 Prompt 留出预算；
模型升级时新旧向量不在同一空间，应新建索引版本并灰度切流，而不是增量混写；
多语言效果必须用业务查询—文档相关性集合验证，不能仅凭模型说明推断。

7.4 异常处理、监控与测试

现象	可能根因	解决方式	验证证据
召回整体突降、Token 分布突变	Tokenizer 与模型或索引版本不匹配	启动时校验模型、词表与配置哈希，不匹配则拒绝加载	固定样本的 ID、向量版本和基线召回恢复一致
长查询效果显著差、关键结论消失	超长输入被静默截断	记录原 Token 数与截断方向，改为分段、摘要或查询重写	长文本回归集无静默丢失，截断率和溢出片段可观测
同一短文本随批次或 Padding 长度改变向量	池化时把 Padding 向量计入平均	使用 `attention_mask` 做 Masked pooling，并拒绝全空输入	同一文本在多种 Padding 长度下的向量满足指定容差
同一查询结果不稳定且候选版本混杂	新旧 Embedding 向量写入同一索引空间	新建版本化索引，双写验证后原子切换	抽样结果的模型/索引版本单一，切换前后指标可回滚
视觉相同文本得到不同 ID	训练与推理 Unicode 规范化规则漂移	固化规范化配置，保留原文与规范化版本	组合字符、全半角等回归样本的 ID 与预期一致

7.4.1 故障演练：新旧 Embedding 混写造成召回抖动

现象与影响：同一查询多次返回不同候选，相关文档时有时无，且无法从相似度分数解释变化。
定位证据：检查候选的 embedding_model、dimension、normalization、index_version 与写入批次；按版本分别重放固定查询。
根因：模型升级时把新向量增量写入旧索引空间，查询向量和文档向量来自不同坐标系。
临时止损：冻结增量写入，将读流量固定到最后一个单一模型版本的健康索引，并清理跨版本缓存。
长期修复：新模型构建独立候选索引，绑定模型与预处理指纹；双跑评测通过后原子切换别名，禁止跨空间混写。
回归验证：固定查询集比较 Recall@k、MRR、延迟和版本纯度；切换、回滚及缓存失效后候选版本必须单一。
防复发：索引写入校验维度和模型指纹，版本不一致直接拒绝；发布门禁加入混写故障注入和索引对账。

监控至少包含 Token 长度分位数、截断率、未知/回退片段比例、空输入率、模型与索引版本、离线 Recall@k，以及按语言/文档类型切片的质量指标。

7.5 结果与复盘

验收不写假设收益，而以可复现证据为准：固定标注集上的检索指标、同版本可重复编码、权限正确性、长文本与异常字符回归、切换前后质量和延迟对比。没有实测前只描述方案，不宣称提升幅度。

8. 方案权衡与常见误区

8.1 适用与不适用场景

子词 Tokenizer 适合开放文本和多语言建模，但对字符级精确对齐、代码缩进或特殊领域符号仍需专门评估；
向量检索适合语义近似匹配，不适合替代精确编号、金额、日期等结构化过滤；
平均 Token Embedding 可用于教学和基线，不应在无评测时直接上线为检索方案。

8.2 关键权衡

决策	收益	代价/风险
增大词表	常见片段 Token 更少	Embedding/输出层参数和内存增加
更细切分	生僻词覆盖更稳	序列变长，Attention 成本增加
更高向量维度	可能容纳更多表示能力	存储、传输、检索成本上升，不保证质量
Padding 到固定长度	编译与批处理形状稳定	无效计算增加
动态 Padding	减少无效 Token	批次形状变化，编译/调度更复杂

8.3 常见错误回答

“一个 Token 就是一个词”：忽略子词、标点、字节和特殊 Token；
“Embedding 就是词义”：输入 Embedding 不含当前句子的上下文；
“余弦相似度高就一定语义相关”：相似度受训练目标、数据分布和池化影响；
“模型支持固定字符数”：模型限制通常按 Token 或内部位置计算，不按字符；
“换 Tokenizer 只影响展示”：ID 语义会变化，模型权重查到错误行。

8.4 生产环境风险与解决原则

配置漂移：模型、Tokenizer、索引作为不可分割版本单元发布；
静默截断：记录原长度、保留策略和溢出，关键场景禁止无提示截断；
敏感信息进入第三方 Embedding：先做数据分类、脱敏、授权和留存策略；
向量模型升级：用固定评测集重建新索引、双路对比后切换；
成本失控：按 Token 统计离线重建量，去重并缓存内容哈希对应的向量。

9. 面试题与参考答案

问题 1：为什么 LLM 普遍使用子词，而不是整词或纯字符？

难度：基础；
考察点：开放词表、词表规模、序列长度之间的权衡；
合格答案要点：整词词表大且有 OOV，字符覆盖好但序列长，子词折中；
优秀答案加分项：联系 $V d$ 参数量与 Attention 的 $n^{2}$ 成本；
常见错误：声称子词完全消除所有未知输入问题；
可继续追问：BPE 与 Unigram 的训练思路有何不同？

问题 2：`input_ids` 如何变成 Transformer 输入？

难度：中级；
考察点：张量维度、Embedding 查表、位置和 Mask；
合格答案要点： $[B, n]$ ID 经 $[V, d]$ 查表得到 $[B, n, d]$ ，再融合位置表示；
优秀答案加分项：说明 Padding Mask、weight tying 和 ID 范围；
常见错误：把 One-hot 的稠密矩阵当作实际必须构造的输入；
可继续追问：为什么查表与 One-hot 乘 Embedding 矩阵数学等价？

问题 3：Token Embedding 能直接用于语义检索吗？

难度：中级；
考察点：表示层次与训练目标；
合格答案要点：通常不能直接保证；需要上下文化、合理池化和适合检索的训练目标；
优秀答案加分项：提出业务标注集、Recall@k、版本与归一化验证；
常见错误：认为维度越高检索必然越准；
可继续追问：同一向量模型升级时为什么通常要重建索引？

问题 4：线上召回质量突然下降，你如何排查 Tokenizer 链路？

难度：高级；
考察点：生产排障与可观测性；
合格答案要点：先确认影响范围和变更，再比对模型/Tokenizer/索引版本、固定样本 ID、长度与截断分布；
优秀答案加分项：提到配置哈希、灰度、回滚、分语言切片和不变性测试；
常见错误：直接调 Top-k 掩盖编码错误；
可继续追问：如果 ID 完全一致但结果仍下降，下一步查什么？

10. 递进追问

基础概念：Token、Token ID、Embedding 三者分别是什么？
原理细节：为什么 Embedding 查表等价于 One-hot 向量乘矩阵？
张量与复杂度：给定 $V$ 、 $d$ 、 $B$ 、 $n$ ，如何计算参数量和输出形状？
实现边界：为什么同一文本放入不同 Padding 长度的批次，句向量可能发生错误变化？
工程权衡：词表扩大后，模型参数、序列长度和服务成本分别如何变化？
系统与复盘：如何无停机地把线上检索从旧 Embedding 模型迁移到新模型，并证明可以切流？

11. 实践任务

[ ] 最小实现：运行本文代码，打印 input_ids、Mask、Token 向量和句向量形状；
[ ] 对比实验：故意去掉 Masked Mean，比较同一短句在不同 Padding 长度下的向量；
[ ] Tokenizer 实验：用同一官方 Tokenizer 比较中文、英文、代码、Emoji 和组合 Unicode 的 Token 数；
[ ] 检索实验：构造至少 10 条小语料和人工相关性标签，对比点积、余弦与不同池化；
[ ] 故障注入：交换两个 Token ID 或换一份词表，观察“服务不报错但语义错误”的现象；
[ ] 面试口述：分别用 30 秒和 1 分钟解释 Tokenizer 与 Embedding 的边界。

验收证据应包含运行命令、依赖版本、输入样本、输出、失败样本和结论；没有实测数据时不要填写提升百分比。

12. 相关知识与参考资料

12.1 相关知识

后续主题：Attention 与 Transformer；
训练关系：LLM 预训练、微调与对齐；
关键连接：Token 序列长度决定 Attention 的输入规模，Tokenizer/词表又必须和训练及推理权重同步版本化。

12.2 一手参考资料

以下资料均于 2026-07-10 访问；框架 API 可能继续演进，使用时应重新核对目标版本。

Sennrich et al., Neural Machine Translation of Rare Words with Subword Units，ACL 论文；
Kudo and Richardson, SentencePiece: A simple and language independent subword tokenizer and detokenizer，EMNLP 论文；
Vaswani et al., Attention Is All You Need，Transformer 与正弦位置编码原始论文；
PyTorch, torch.nn.Embedding 官方文档；
Hugging Face, Tokenizer 官方 API 文档；
Google, SentencePiece 官方源码，包含确定性编码与 Subword Sampling 接口；
Provilkov et al., BPE-Dropout: Simple and Effective Subword Regularization，BPE Dropout 原始论文；
Hugging Face, Tokenizers 官方文档及其开源实现。

13. 简明总结

一句话记忆： Tokenizer 把开放文本变成有限 ID，Embedding 把离散 ID 变成连续向量，而版本一致性决定这条输入链路是否可信。

子词方案在词表大小、未知词覆盖和序列长度之间折中；
$[B, n]$ 的 ID 经 $[V, d]$ 查表得到 $[B, n, d]$ ，Embedding 参数量为 $V d$ ；
输入 Token Embedding、上下文化表示和检索句向量不是同一个概念；
项目最易踩坑的是 Tokenizer/模型不匹配、静默截断、Padding 污染和新旧向量索引混用；
面试必须同时讲清概念边界、张量维度、复杂度和版本化排障。

Token 与 Embedding ​

目录 ​

1. 学习目标 ​

2. 面试结论 ​

2.1 30 秒回答 ​

2.2 一分钟复述版 ​

3. 面试官为什么问 ​

4. 概念与边界 ​

小白先这样理解：一句话如何进入“乐高仓库” ​

4.1 是什么 ​

4.2 不是什么 ​

4.3 解决什么问题 ​

4.4 输入、输出与前置条件 ​

4.5 与相近概念的区别 ​

5. 原理剖析 ​

5.1 直觉理解 ​

5.2 核心流程 ​

5.3 数学、张量维度与位置表示 ​

5.4 复杂度与关键假设 ​

6. 实现与代码 ​

6.1 最小可运行 PyTorch 示例 ​

6.2 关键实现说明 ​

6.3 边界条件与验证 ​

6.4 技术栈与横向选型 ​

6.5 架构与技术调用流程 ​

7. 实际项目案例 ​

7.1 背景、目标与约束 ​

7.2 架构与调用链 ​

7.3 方案选择与实现难点 ​

7.4 异常处理、监控与测试 ​

7.4.1 故障演练：新旧 Embedding 混写造成召回抖动 ​

7.5 结果与复盘 ​

8. 方案权衡与常见误区 ​

8.1 适用与不适用场景 ​

8.2 关键权衡 ​

8.3 常见错误回答 ​

8.4 生产环境风险与解决原则 ​

9. 面试题与参考答案 ​

问题 1：为什么 LLM 普遍使用子词，而不是整词或纯字符？ ​

问题 2：input_ids 如何变成 Transformer 输入？ ​

问题 3：Token Embedding 能直接用于语义检索吗？ ​

问题 4：线上召回质量突然下降，你如何排查 Tokenizer 链路？ ​

10. 递进追问 ​

11. 实践任务 ​

12. 相关知识与参考资料 ​

12.1 相关知识 ​

12.2 一手参考资料 ​

13. 简明总结 ​

Token 与 Embedding

目录

1. 学习目标

2. 面试结论

2.1 30 秒回答

2.2 一分钟复述版

3. 面试官为什么问

4. 概念与边界

小白先这样理解：一句话如何进入“乐高仓库”

4.1 是什么

4.2 不是什么

4.3 解决什么问题

4.4 输入、输出与前置条件

4.5 与相近概念的区别

5. 原理剖析

5.1 直觉理解

5.2 核心流程

5.3 数学、张量维度与位置表示

5.4 复杂度与关键假设

6. 实现与代码

6.1 最小可运行 PyTorch 示例

6.2 关键实现说明

6.3 边界条件与验证

6.4 技术栈与横向选型

6.5 架构与技术调用流程

7. 实际项目案例

7.1 背景、目标与约束

7.2 架构与调用链

7.3 方案选择与实现难点

7.4 异常处理、监控与测试

7.4.1 故障演练：新旧 Embedding 混写造成召回抖动

7.5 结果与复盘

8. 方案权衡与常见误区

8.1 适用与不适用场景

8.2 关键权衡

8.3 常见错误回答

8.4 生产环境风险与解决原则

9. 面试题与参考答案

问题 1：为什么 LLM 普遍使用子词，而不是整词或纯字符？

问题 2：`input_ids` 如何变成 Transformer 输入？

问题 3：Token Embedding 能直接用于语义检索吗？

问题 4：线上召回质量突然下降，你如何排查 Tokenizer 链路？

10. 递进追问

11. 实践任务

12. 相关知识与参考资料

12.1 相关知识

12.2 一手参考资料

13. 简明总结