# 带读笔记：Datawhale《DIY LLM》第 2 章 · 分词器

> 起于 2026-11-07 · 侃姐在学，会陆续问问题；小 Q 记录「原话 + 回答 + 时间」，只追加不改写
> 资料：<https://github.com/datawhalechina/diy-llm/blob/main/docs/zh/chapter2/chapter2_分词器.md>
> 概念地图：[2026-11-07-tokenizer-history.html](2026-11-07-tokenizer-history.html)

**这份笔记是什么**：学习过程中的问答记录 + 概念地图，不是章节摘要。侃姐问什么就记什么，不替她总结「该问什么」。无排期、不打卡、不承诺下一期。

**讲解规则（沿用 2026-11-06 定下的硬规则）**：零基础起步；出现英文缩写/专名前先说清它是什么类型（算法 / 工具库 / 模型名 / 产品实现 / 做法）；一个例子贯穿到底；每节只讲一件事；不密集列清单。

---

## 一句话判断

**分词器这 30 年不是一堆散名词，是一条主线：「以什么为单位切」被四个具体痛点逼着改了四次。年份不用背，但「BPE 是从压缩软件借来的、核心是一张合并顺序表」必须懂——因为本章附录 6 让你手写的就是它。**

另有一句更要紧的：**你记不住的根源不是记性，是教材把四类不同的名字塞进了同一张「算法对比表」**。先分类，再看表。

---

## 0 · 名词分类（先做这一步，后面才不会乱）

| 名字 | 类型 | 一句话 |
|---|---|---|
| BPE | **算法 / 做法** | 数谁最常挨着，就把这俩粘成一块 |
| Byte-Level BPE / BBPE | 算法的变种 | 还是 BPE，起点从「字符」降到「字节」 |
| WordPiece | **算法 / 做法** | 也粘，但挑「粘了最划算」的那一对 |
| Unigram | **算法 / 做法** | 反过来：先摆一大堆候选，再删掉没用的 |
| SentencePiece | **工具库，不是算法** | 一个软件包，里面能跑 BPE 或 Unigram |
| tiktoken | 具体实现 | OpenAI 家那个包，GPT 系列在用 |
| UL2 | **模型名** | 教材表格里出现的 Google 模型，跟分词算法无关 |
| UniLM | **模型名** | 微软一个模型，跟分词器无关 |
| DeepSeek Tokenizer | 产品实现 | 字节级 BPE 的一个具体做法，不是新算法 |

**主动纠正侃姐的记混**：她原话里有「UniLM/Unigram 打头的」。教材 2.3 节表格里出现的是 **UL2**（Google 的预训练模型），不是 UniLM；**UniLM 是微软 2019 年的模型，跟分词器毫无关系**。她大概率是把 UL2、Unigram、UniLM 三个名字揉在一起了。这不是小错——正好说明「不同类型的名字混排」有多误导人。

**「BPE 打头的一族」**（她说的"好多 BPE 打头的"）：BPE（本尊）、Byte-Level BPE / BBPE（起点换成字节）、SP-BPE（用 SentencePiece 这个库跑 BPE，Llama 2 用过）、BPE-dropout（训练时随机不粘某些对，让模型见过多种切法）、SuperBPE / BoundlessBPE（2025 年的改进研究）。**都是同一个"粘"的思路在换条件，不是五种算法。**

---

## 1 · 结构地图：这一章到底讲了什么

我把你给的 GitHub 页面抓下来核对过。**结论：这一章没有系统讲历史演进**，只有零散线索（"RNN 时代词级最主流"、"BPE 早期与部分 LLM 广泛采用"、T5/mT5/UL2 那段讲的是预训练范式演化，不是分词器）。

章节结构：`1 学习目标 → 2 训练分词器（2.1 准备语料 / 2.2 预分词 / 2.3 统计并迭代更新 / 2.4 输出产物） → 3 常用分词器（字符 / 字节 / 词级 / BPE） → 4 分析 DeepSeek 分词器 → 5 附录 7 个代码实验 → 6 总结与测试题 → 参考资料`。

**它要求动手的**：加载 DeepSeek Tokenizer、观察中文 token、可视化分词器、实现字符级/字节级/词级/BPE/DeepSeek 风格 Tokenizer、简易 BPE 训练、数据脱敏、Unicode 预分词、验证集统计、扩表回归测试。是 DIY 课程，动手为主。

**教材自己给的一个关键区分**（2.3 节 Tips）：「分词算法决定 token 的划分策略，而分词器则是把算法与词表、编码机制组合起来，形成完整处理流程。」——这句话就是上面分类表的依据，教材说了，但表格标题又写成「算法对比表」，自己把自己绕回去了。

---

## 2 · 时间线：四个痛点，四次改法

**贯穿例子**：产线语料里反复出现「夏天湿度影响烘箱温度」，某天又冒出一个词表里没有的新术语「虚拟调试」。

| 站 | 痛点 | 做法 | 留下什么 |
|---|---|---|---|
| **最早 · 按词切** | 词表爆炸；「虚拟调试」第一次出现就没编号，只能记成「不认识」，信息丢了。中文还得先吵「烘箱温度」算一个词还是两个 | 一个词一个编号 | 新词/术语/人名这个麻烦，至今没消失 |
| **退一步 · 按字切** | 什么都能表示，但一句话切成十几块，序列太长、算得慢、吃上下文窗口；单字又几乎没语义 | 一个字一块 | 「切细不丢东西但太长」这条跷跷板 |
| **1994→2015 · BPE** | 按词太粗、按字太细，能不能不靠人定 | 从单字起步，反复把最常挨着的一对粘成新块，记下顺序 | 合并顺序表（`merges`），成为今天主流 |
| **2012 / 2018 · 换挑法** | 「只数谁最常挨着」有点糙 | WordPiece 挑「粘了最划算」的；Unigram 反过来「先给一大堆、再删没用的」 | 一句话可有多种切法、各自带分数 |
| **2018 / 2019 · 降到字节** | 中文没空格要预分词；emoji、生僻字、代码缩进常没被覆盖 | SentencePiece（工具库，空格也当普通字符 `▁`）；GPT-2 把起点降到字节 | 今天形态：字节打底 + BPE 粘合 + 固定词表 |
| **2024 至今 · 想拿掉分词器** | 词表训练前定死、跟着模型一辈子；模型看不到字母、语言间不公平、罕见块闹鬼 | Meta BLT 直接读字节、动态分块；后续研究解决「吐字节太慢」 | 研究阶段，**不是生产现状** |

**几件值得记的事**：

1. **BPE 不是 AI 发明的**。1994 年 Philip Gage 在《C Users Journal》发 "A New Algorithm for Data Compression"，是压缩文件用的，图解压快、占内存小。2015 年 Sennrich / Haddow / Birch 在《Neural Machine Translation of Rare Words with Subword Units》（ACL 2016）借去解决翻译里的生僻词。**教材参考资料里的 `arXiv:1508.07909` 就是这次跨界。**
2. **WordPiece 的出身是日语/韩语语音搜索**（2012，Google，Schuster & Nakajima），因为这两种语言词边界模糊。很多分词器的进步是被「中文/日文没有空格」逼出来的。2018 年 BERT 用它，`##` 前缀就是它的记号。Google 没公开完整算法细节，教材里的 `score(A,B)=P(A,B)/(P(A)P(B))` 是 HuggingFace 那边的常用近似，教材自己也注明了。
3. **2018 年是同一个人（Taku Kudo）一口气给了两样东西**：Unigram 算法（arXiv:1808.06226）+ SentencePiece 工具库（arXiv:1804.10959，与 John Richardson）。所以 Unigram 和 SentencePiece 老是结伴出现——**不是两种算法，是「一个做法 + 装它的盒子」**。
4. **2019 GPT-2 把起点降到字节**，从此没有「没见过的字」。教材 4.2 节问「DeepSeek 为什么用 latin1」：因为字节级 BPE 要「把字节当字符来粘」，latin-1 是单字节编码，能把 0–255 每个字节机械映射成一个可显示字符，保证不丢数据。
5. **词表大小这三年一直在涨**（Llama 2 的 32K → Llama 3 的 128K → Gemini/Gemma 的 262K），动机之一是补多语言覆盖。GPT-4o 的 `o200k_base` 里西里尔字母 token 比 GPT-4 的 `cl100k_base` 多约 10 倍——这就是「补语料偏向」的具体动作。

---

## 3 · 四个好玩又有用的故事

- **分词器不是 AI 发明的**：压缩软件跨界。附录 6 让你手写的 `train_bpe` / `merges`，本质就是当年那张压缩表。
- **模型数不清 strawberry 里有几个 r**：不是笨，是它**看不到字母**，只看到切好的整块。等于让只看得见包装箱的人猜箱里几颗糖。拼写、倒着念、精确改字符天生吃亏。
- **中文比英文「贵」**：同一段意思，英文常被切成较少块，中文/印地语等往往更碎；API 按块计费、上下文按块算长度，于是同样内容非英语要多付钱、更占窗口。**不是模型偏心，是词表训练语料里英文占多数。** 对做企业 AI 交付，这条直接进成本与选型。
- **有些词块会「闹鬼」**：2023 年流传的 glitch tokens（最有名 `SolidGoldMagikarp`），某些极罕见 token 会让模型突然胡言乱语，因为训练时几乎没学好那个编号。**词表不是中性的字典，是有脾气的历史遗留物。**

---

## 4 · 现在到哪了（2026-11，诚实标注）

- **生产环境里跑的，几乎全是「字节级 BPE + 固定词表」这一代**：GPT 系列（tiktoken）、Llama 3、DeepSeek、Mistral 等。Google 系（T5 / mT5 / Gemma）多用 SentencePiece 里的 Unigram。BERT 系用 WordPiece。
- **研究线在往「不要分词器」走**：Meta **BLT**（2024-12，直接读字节、按预测难度动态分块，8B 规模与 Llama 3 相当，抗噪声与字符级任务更好）；2026-05 的 **Fast BLT**（并行/投机解码解决「一次吐一个字节太慢」，据称被 ICML 2026 接收）；2025 年还有 SuperBPE、BoundlessBPE 这类改进 BPE 本身的工作。
- ⚠️ **可信度标注**：BLT 2024-12 与字节级 BPE 的历史节点有多个来源交叉验证；**2025–2026 的具体会议、百分比、token 倍数来自二手资料（AI Wiki / 技术博客），我没逐篇回 arXiv 原文核对，别当硬结论引用**。尤其「某论文 33% fewer tokens / +4.0%」「英文 12 token vs 印地语 51 token」这类数字，用之前必须回原文。这符合笔记库的既有约定：**论文链接先查版本历史、数字回原论文取**。
- 一句话：**别拿论文结论当教材结论。** 你现在学的这一章，教的是仍然在服役的那一代。

---

## 5 · 可复用清单（逐条，不堆）

1. **看到一串陌生名字，先问「它是什么类型」**：算法 / 工具库 / 模型名 / 产品实现。四类混排是记不住的头号原因。（这一条不只用于分词器。）
2. **审任何 tokenizer，先问三件事**：切完之后一句话变几块？新术语/专有名词会不会被拆碎？换成中文/代码/emoji 会多出多少块？——分别对应效率、覆盖、成本。
3. **给客户解释成本时**：中文比英文占更多 token 是词表语料偏向造成的，不是模型能力差异；这个差异会同时打在 API 账单和上下文窗口上。
4. **读本章附录 6 时**：`merges` 表 = 「先粘哪对、后粘哪对」的顺序表，编码就是按这个顺序重放一遍；`</w>` 是词尾标记，保证能拼回原文（可逆）。这就是 BPE 的全部。
5. **评估一个分词器好坏**：教材 2.4 已经给了答案——平均 token 数、碎片化情况、跨语言 token 平衡度；扩表后必须做回归测试，确认还能还原原文、编号不冲突。

---

## 6 · 按目的的读法

| 目的 | 读什么 |
|---|---|
| 只把本章学完、能跑通代码 | 2.3（四算法对比）→ 3.4（BPE）→ 附录 5.3/5.4/5.6 → 4.2（DeepSeek 与 latin1） |
| 想搞懂「为什么这样设计」 | 本笔记第 2 节时间线 + 教材 2.2（预分词三种策略） |
| 想跟客户讲明白分词器的商业影响 | 本笔记第 3 节的第 2、4 个故事 + 教材 2.1（多语言语料配比 4:4:1:1） |
| 想追前沿 | 先别追。等本章代码跑通，再看 BLT 原论文；二手博客的数字一律回原文核 |
| 教材测试题里那两道开放题（视觉表征动态路由、可微分词器） | 是研究方向不是知识点，别当考点背 |

---

## 7 · 局限与待跟进

- 本笔记的历史年份经公开资料交叉核对，但**未逐篇读原始论文全文**；`arXiv:1508.07909` / `1804.10959` / `1808.06226` 都来自教材自己的参考资料，尚未逐篇 fetch（需要时按笔记库约定补）。
- 2025–2026 研究动态来自二手来源，可信度低于历史节点，已在第 4 节标注。
- 教材 2.3 的 WordPiece 公式是 HuggingFace 的近似说明，Google 未公开完整算法，别当官方定义。
- **待办**：侃姐跑附录代码若遇到「中文 token 显示像乱码」「`</w>` 怎么拼回去」这类具体问题，回来记进提问记录，用代码输出讲比用公式讲有效。

---

## 8 · 提问记录

> 侃姐问什么都可以，包括「这个词什么意思」「我不信这个结论」。小 Q 会把**原话 + 回答 + 时间**追加在下面，只追加、不改写、不替她总结。一段的 done = 她说「这段过了」或没新问题。无排期、不承诺下一期。

---

#### #1 · 2026-11-07 19:13

**侃姐原话**：
> 我现在在学 Datawell 的 DIY LLM，然后我会问你一些问题，咱们可以把这本书或者这个资料吃透一下。
> 我现在看到 tokenizer 分词器这块，想问一下：分词器应该也经历过很多故事吧？我看到有好多 BPE 打头的，还有 UniLM/Unigram 打头的，还有别的我都记不清了。这块应该有不少有趣的发展历史或者故事，你帮我整理一下讲给我听听

**小 Q 的回答**：见本笔记第 0–4 节与配套概念地图 [2026-11-07-tokenizer-history.html](2026-11-07-tokenizer-history.html)。核心 verdict 与三处纠正：

1. **不是散名词，是一条主线**：「以什么为单位切」被四个痛点逼着改了四次。按词 → 按字 → BPE 让语料自己决定 → 换挑法（WordPiece / Unigram）→ 降到字节 + SentencePiece → 现在有人想整个拿掉。
2. **她记不住的根源是类型混排**：教材把算法名（BPE / WordPiece / Unigram）、工具库名（SentencePiece）、模型名（UL2）、产品实现名（DeepSeek Tokenizer）放进同一张「算法对比表」。**SentencePiece 根本不是算法**。
3. **三处事实纠正**：她写的 Datawell 应为 **Datawhale**（GitHub 组织 `datawhalechina`）；她记的 **UniLM 是微软一个模型，与分词器无关**，教材表里出现的是 **UL2**，她大概把 UL2 / Unigram / UniLM 揉一起了；「好多 BPE 打头的」其实是同一个「粘」的思路换条件（BPE / BBPE / SP-BPE / BPE-dropout / SuperBPE），不是五种算法。
4. **最该记的一个故事**：BPE 是 1994 年一个压缩文件的小算法，2015 年被做翻译的人借走；教材参考资料 `arXiv:1508.07909` 就是这次跨界，附录 6 让她手写的 `merges` 就是当年那张合并顺序表。
5. **教材这一节没讲历史**（已抓原文核对），讲的是训练四步、四种分词器对比、动手实现、DeepSeek 分析；T5/mT5/UL2 那段是预训练范式演化，不是分词器历史。
6. **别拿论文结论当教材结论**：2024-12 BLT 起的研究线值得知道，但到 2026-11 生产环境仍是字节级 BPE；2025–2026 的二手数字未回原文核验，已标注。

---

#### #2 · 2026-11-07 19:30

> 这一段原话含**三件事**：讲法要求（要故事，不要逻辑线）、专有名词做成独立 token、把 ontology 做进 token。按「只追加、不改写、不替她拆问题」的原则，原话整段保留，回答分 A/B/C 三块。

**侃姐原话**：
> 我是想让你讲得比较有意思，就像我们在讲 2012 年 ImageNet 大赛，辛顿的团队用英伟达的 GPU 结合他们的神经网络算法大获全胜，用这种方式来讲。
> 再一个我有个问题：如果我做大模型微调，或者在做垂直模型的时候，能不能把行业里的专有名词直接做成独立的 token？这样一来 token 数会少很多，而且也便于理解。
> 另外，我在做 token 的时候，能不能把 ontology 也做出来？当然这是两个维度，但它们都是在划分词、给词做标记。如果我对类别、属性再建一层关系，是不是就直接在这个垂直模型里自带了这些东西？会不会更加专业一些？

**小 Q 的回答**：

##### A · 讲法：上一版给的是逻辑线，不是故事；这版按她要的讲法重讲

开场直接对标她给的 ImageNet 讲法（「分词器也有它的 2012」）：

| | ImageNet 2012 | 分词器 2015 |
|---|---|---|
| 被冷落的老东西 | 神经网络 | 1994 年一篇压缩文件的小算法 |
| 凑齐的条件 | 大数据集 + 英伟达 GPU | 够大的双语语料 + 「撞见生词就废」这个丢人痛点 |
| 人 | 辛顿团队 | Sennrich / Haddow / Birch 三个做翻译的人 |
| 结果 | 一夜改写整个领域 | 从此成了所有大模型开工前的第一道工序 |

**三幕**（人物少、不堆术语、每个出现的人名先说「这是人名」）：

1. **1994 · Philip Gage（人名，一个写程序的工程师）**：在程序员杂志发小文章讲怎么把文件压小、解压快 —— 数哪两个字节最常挨着，就发个新编号，反复做几千次。当年只在压缩圈流传，作者本人没想过 AI。留下的是一张「先粘哪对、后粘哪对」的顺序表。
2. **2015 · 三个做翻译的人（人名，爱丁堡大学）**：那时翻译系统碰到没见过的词直接吐「不认识」，整句废掉。他们把 21 年前那篇压缩文章翻出来，不压文件改压词，一试翻译质量明显往上跳。**教材末尾 `1508.07909` 是这次捡漏的现场记录；附录 6 让她手写的那张表就是 Gage 当年那张压缩表，一个字没改。**
3. **2018 · 所有人涌进来**：Google 给 BERT 配「挑最划算的一对粘」；Taku Kudo（人名）同一年给了两样东西；OpenAI 把起点降到字节，从此没有「没见过的字」。此后「先切块再训练」再没人质疑。

**翻车名场面**（故事下半句，对应「冠军在小水沟翻车」）：strawberry 数不清 r —— 不是笨，是它从没看见过字母，只看见切好的整块；中文悄悄多付钱；极少数没学好的编号一碰就胡言乱语。**赢了不等于地基对**，今天「想拿掉分词器」的研究都在补这一幕的账。

##### B · 专有名词做成独立 token：能做，第一半句对，第二半句不成立

**verdict**：能做，真有人做（叫「词表扩充」，一个做法的名字）；「块数会少」对 → 省上下文、省账单；「便于理解」**不成立**，而且只加不练会变差。

1. **省的是钱，不是懂。**「虚拟调试」从几块变一块，窗口占得少、账单少。像把一个长名字缩成一个工号，登记快了，不代表这人更懂业务。
2. **新编号是一张空白工牌。** 词表里多了个号，模型从没在这个号上学过任何东西（新编号的表示是随机给的）。直接拿去微调，可能输出乱码、连原有能力都受影响。得先拿大量行业文本让模型把这个号重新学一遍 —— **这已经不是微调，是接近重新预热**，成本高一个量级。
3. **反而少了猜的线索。** 切成几块时模型还能借「调试」两个字猜个大概；粘成一整块这点线索就没了。**懂不懂来自训练，不来自切法。**
4. **连锁反应**：加词会改变整段话的切法，原来那些块上积累的东西对不上；所以做完必须做回归检查 —— **老文本切出来的结果要跟以前完全一致**。
5. **今天加词的唯一理由是效率**：字节级起点已经保证「没有不认识的字」，生僻词只是切得碎、不会丢。行业里一句直白判断：「a domain has jargon」远不够格动词表；领域词被切成 3 块是正常运作，不是缺陷。

**真要做的做法**（她做垂直模型能用）：先按原样跑一版；只挑最高频、切得最碎的一小批（百来个到几百个，别上千）；新号的起点别随机发，用原来那几块的平均当起点（收敛快 2–3 倍）；必须扩首尾两处矩阵；中文友好的基座（Qwen 等）优先级更低；**只在「文本量大到上下文装不下、账单明显」时才动**。

##### C · 把 ontology 做进 token：方向对，位置不对

**先接住她的直觉**：她自己写的「当然这是两个维度」就是这题的答案，比很多做工程的人先想到。

**verdict**：垂直模型确实该带本体，但不该塞进编号；塞进去不会更专业，反而更脆。

1. **编号是死的，身份是活的。**「温度」在「烘箱温度偏高」里是被观察的量，在「把设定值拧到 78 度」里是我能动的旋钮，在「温度属于工艺参数」里是一类东西。一个固定编号装不下三种身份。→ **token 只回答「这是哪块字」，本体回答「这块字此刻是什么、跟谁有关系」。**
2. **类比**：token 像快递单上印的字，本体像仓库里的货架关系图。想让仓库变整齐，改快递单没用，得另立一套架子。
3. **行业知识偏偏会变**（产品族换、工艺改、类别合并）。把关系焊死在编号里，改一次就得重训一遍模型；挂在外面只改那层。
4. **业界真在做、做了很多年**，但做法一律「旁边另开一路」：输入时把关系额外喂进去（K-BERT / CoLAKE，都是论文或做法的名字，不是机构）、训练时多一个目标（KEPLER / ERNIE）、回答前先查一层 / 本体约束提示（OntoPrompt）。有个专门的词叫**「知识噪声」**：把关系硬拼进句子会和原句互相污染，还得再加隔离。**会被反弹，本身就说明不该硬塞。** 没有任何一条主流路线是改 tokenizer 编号。
5. **「自带」的正确形态**：不是把本体编进 token，是让模型**查得到**本体、输出**受它约束**。正落在她 FDE 路线图的「语义 / 数据治理」层，也接 klgwiki 的本体工作。

**一句可写进方案**：垂直模型的专业度 = 语料里术语用法一致 + 有一层可查可改的概念关系 + 输出被这层校验；**跟词怎么切基本无关**。词怎么切是「记账」的事，词是什么、跟谁有关系是「仓库」的事。

##### 本轮查证来源与可信度

- **B 的事实层**（多来源交叉，可信）：Distil Labs《Do You Need to Fine-Tune the Tokenizer?》(「几乎每种情况都不需要动 tokenizer」「新编号随机初始化、必须继续预训练」「字节级 BPE 已消除生词丢失」「领域词切 3 块是正常运作不是缺陷」)；CSDN/面试资料（新增词不 CPT 直接 SFT「输出乱码或破坏原有能力」、新增词控制在原词表 5%–20%、子词均值初始化、必须验证旧文本编码完全一致、中文友好基座优先级不高）；2025 COLING《Language Adaptation of LLMs: An Empirical Study on LLaMA2》（5B tokens、扩 2k 词、三种初始化在训练数据充足后差异很小）；arXiv:2608.03494（词表扩充必须配 CPT；WECHSEL / FOCUS / AdaptiVocab 等初始化研究）。
- **C 的事实层**：arXiv:2306.08302《Unifying LLMs and Knowledge Graphs: A Roadmap》v1/v2（输入层 / 中间层 / 目标层三类注入、K-BERT 的 visible matrix 与 knowledge noise、ERNIE / KnowBERT / KEPLER / CoLAKE / OntoPrompt 全是另开一路）；腾讯云 K-BERT 解析（soft-position / soft-mask 用来隔离知识噪声）。
- ⚠️ **未回原文核对的二手数字**：某医学团队「扩 500 词 → 吞吐 +15%、+4 AUROC」、1–5% 预训练成本、1M+ 样本门槛等，来自 AI 术语站与博客，**只当数量级直觉，不当硬结论引用**。沿用笔记库既有约定。
- **概念地图**：[2026-11-07-tokenizer-story-and-two-questions.html](2026-11-07-tokenizer-story-and-two-questions.html)（三幕 + 翻车名场面 + 两个 verdict，light editorial，真实 HTML 文件）。

---

#### #3 · 2026-11-07 19:39

**侃姐原话**：
> 那么现在大模型里面有自带 ontology 的吗？大模型里面它能建跟仓库有关的东西吗？

**小 Q 的回答**：

**先消歧义**：她说的「仓库」是上一轮那个**货架关系图的比喻**，不是真的成品仓库；若指真仓库（库位 / 批次 / 入库单），办法完全一样，只是货架上摆的东西换一组。不打断追问，两边一起覆盖。

##### 三个直接判断

1. **没有一个通用大模型把 ontology 装在自己里面。** 权重里的是「印象」，不是台账：读不出来、改不了、不保证前后一致、不能审计。
2. **但「平台打包一层」有，而且是 2026 年企业级 AI 的主流形态**：本体在中间、模型在边上，**模型可以换，架子不换**。
3. **「模型替你建一层」也有，是活跃方向**：能摆货、贴标签、连关系，但**格子得人先画、结果得人签字** —— 是理货员，不是仓库设计师。

##### 「自带」有三种意思，答案不一样（先分类型，她的老规矩）

| 「自带」指 | 有没有 | 白话 |
|---|---|---|
| 装在模型权重里 | **没有**（通用模型） | 像老师傅脑子里的经验 |
| 交付时打包一层 | **有**，2026 企业级主流 | 像仓库台账，跟今天雇哪个搬运工无关 |
| 模型自己从资料里建 | **有**，活跃方向 | 是理货员，不是仓库设计师 |

##### 为什么「模型里的印象」不算本体（烘箱例子贯穿）

模型读过几万篇工艺文档，问它「温度算什么」，答得像模像样；但**查不到**它归到哪一类、**改不了**（改了不全局生效，换个问法又变回去）、**保证不了**同一份数据前后一致、**说不清**凭什么。

- **老师傅的经验**：能猜，不能对账、不能追责。
- **仓库台账**：温度 → 工艺参数 → 属于烘箱 → 有设定值 / 量程 / 校准日期。能查、能改、能对账、能追责，改一次全局生效。

本体要的是后者。**这正是《Causal AI》那条「变量与结构必须显式」的同一句话**，也接上一轮 L1（看见）与 L2（我主动改）的分界：统计出来的关联再像也不是结构。

##### 模型能建仓库吗：分工（逐条配类比）

**理货员 · 能干**（从文档里把东西摆上架）：
- 有哪些东西：烘箱、传感器、批次、工位；
- 每样有什么属性：设定值、量程、校准日期；
- 谁跟谁有关系：湿度影响散热、传感器属于烘箱；
- 谁属于哪一类：温度和节拍都算工艺参数。
- 现实做法：**微软 GraphRAG**（一个做法的名字，2024-04 论文、2024-07 开源）—— 模型读文档抽实体与关系 → 连成图 → 自动聚类分组 → 写分组摘要；**OntoGPT / SPIRES**（一个开源工具 + 里面一个做法的名字，Monarch Initiative，2023 起）—— 给模板 + 文本，抽成结构化结果，可导出 OWL（一种本体文件格式）导进 Protégé / WebProtégé（她培训用的本体工具）。

**设计师 · 得人来**（四件模型做不了的事）：
1. **格子得人先画。** OntoGPT 要人先给一张「抽哪些类、哪些字段」的 LinkML 模板，模型才往里摆货；项目自述限制里明写 `Non-deterministic`（结果不稳定）、`Coupled to OpenAI`。→ **模型填表，不设计表。**
2. **「什么算一类」是约定，不是事实。**「不良率」算质量指标还是工艺结果？语料里两种写法都有，模型没法替你拍板，这是业务决策、要人签字。→ 分区是仓库老板定的，不是理货员看货摆得近就成一区。
3. **抽出的是说法，不是机制。** 它能读到「湿度高」和「不良率高」总一起出现，那是别人写在纸上的共现，不是验证过的因果。→ 回到 L1 vs L2 / `do`。
4. **架子会变，得能改、留版本、能回滚。** 挂在外面才做得到；焊进权重改一次就得重训。

**一个别被 demo 骗的代价**：自动建图的索引阶段要跑成百上千次模型调用，微软 GraphRAG 官方 Getting Started 自己警告「can consume a lot of LLM resources」；新增资料往往要重建社区摘要。2025–2026 一堆变体（LightRAG / LazyGraphRAG / 腾讯优图 Youtu-GraphRAG 2025-09 等）专门在降这块成本。→ **企业交付要把这笔钱写进报价口径。**

##### 对她业务最值钱的一段

2026 年企业级 AI 的架构共识反而是：**本体在中间，模型在边上，模型是可以换的零件。**

- **Palantir**（一家做企业 AI 平台的**公司**，不是模型公司）的 AIP 官方文档把那层叫 **Ontology system**：把「nouns（东西：对象 / 属性）+ verbs（动作：逻辑 / 规则）」+ 权限 + 安全 + 写回整合成企业决策的统一表示；AIP 可接 GPT / Gemini / Claude / Grok / Llama 等各家模型，**模型换，这层不动**。有分析直接称它为「企业的世界模型」—— 这里的「世界」是企业自己的对象、关系和规则，**不是能生成视频那种 world model**（接第 3 份笔记的四阵营辨析）。
- **跟她 FDE 路线图几乎同构**：语义层 / 受控写回 / 验证资产 / 安全合规。所以上一轮「会不会更专业」的答案是：**更专业的不是模型，是那层架子。押在模型上是押人人都能买到的东西，押在架子上是押只有你有的东西。**
- **审供应商三问**：① 架子在哪，能不能导出来看？② 谁定义的分类、改一次要多久、有没有版本？③ 换一个模型，架子还在吗？三问答不上就是话术。
- 一个有趣的呼应（二手，未回官方核）：2026 年有平台让 AI agent 参与持续优化这套系统、人审核后合并，名称里带 **FDE**（AIP Evolve，据称 2026-09-08 发布）—— 与她「Forward Deployed Engineering」能力路线同名，值得留意但别当硬事实。

##### 一句带走

**模型能当理货员，不能当仓库设计师；本体不该在模型里，该在模型旁边 —— 而且是你签字、能改、能审计的那一份。**

##### 本轮查证来源与可信度

- **一手（可信）**：Palantir Foundry 官方《AIP architecture》（Ontology system 定义、nouns/verbs、continuously integrating context into the Ontology、安全与治理、可接各家模型）；微软 GraphRAG 官方文档 / Edge et al.《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》arXiv 2024-04（2025-02 修订）—— 索引五步：切文本单元 → LLM 抽实体/关系/claims → Leiden 社区检测 → 社区摘要 → embed；官方 Getting Started 的成本警告；OntoGPT 项目 README 的 Limitations（Non-deterministic、Coupled to OpenAI、模板需人定义、嵌套不宜超过两层）。
- **二手（标注，不当硬结论引用）**：CIOAge《深度拆解 Ontology》（称 Ontology 是「企业世界模型」、2026-09 AIP 接入 GPT-5.6 系列、AIP Evolve 2026-09-08 发布）；TowardsAI / CAIO Weekly / Scrydon 的架构分析（「Ontology is the agent's brain, not the LLM」「模型可换、本体不可换」「bet on the ontology」）；AIpedia / graphwiz / 三个皮匠报告（GraphRAG 2–3× 准确率、单次查询约 610,000 tokens、2026 变体 99% 降本、Youtu-GraphRAG 构图省 30%+ / 准确率 +16% 等数字）。**这些百分比、日期、产品版本号均未逐条回原文核对** —— 沿用笔记库既有约定。
- **概念地图**：[2026-11-07-where-does-ontology-live.html](2026-11-07-where-does-ontology-live.html)（概念图 ⑤：三种「自带」对照 + 老师傅 vs 台账 + 理货员/设计师分工 + 三问，light editorial，真实 HTML 文件）。

---

#### #4 · 2026-11-07 19:46

> 这一轮不是概念题，是**商业判断**，而且是在反驳 #3 结尾「押在架子上是押只有你有的东西」。按她的层级偏好**停在判断层**：给 verdict、给分层、给可评判的判据，**不落执行方案 / 报价 / 排期 / 路线图改造**。

**侃姐原话**：
> 你比如说我看到西门子、达索，其实他们也有他们的本体论，但是他们好像建的是比较高层的那种大类，是吧？
> 那对于每一个不同的制造业、非标自动化或者其他行业，其实它的世界模型每个都不太一样，或者说会有一些大的规则，下面又会有一些细节的规则，这个其实恰恰是这些小企业数据的价值。
> 但是这些小企业的数据，它又有多少复用的价值在里面呢？如果复用价值不高，其实这个本体建起来，除了做知识库可能不会出错之外，并没有实现一个可以复制的价值

**小 Q 的回答**：

##### 先主动修正 #3 结尾我自己的一句话

我在 #3 说「押在架子上是押只有你有的东西」—— **一个具体的架子确实不可复制，她这句反驳成立。** 更准的说法是：**押在「能反复把架子搭出来的那套方法」上**。架子是给客户的，方法才是你的。

##### 核心 verdict

**她说对的那一半**：小企业的细节数据，复用价值确实低。
**需要修正的那一半**：把「数据」和「搭架子的方法」混在一起算了。可复制的从来不是那批数据，是**每次都要重做、却被你攒下来的那一部分**。所以「复用价值不高 → 没有可复制价值」这个推论不成立，它换错了被复用的对象。

##### 她那两个事实判断，都对（已查证）

1. **西门子 / 达索那层确实是跨企业通用的大类**：西门子工业本体覆盖数字线程对象（EBOM / MBOM / 变更 / 工艺清单 / 服务 BOM / 保修 / 库存 / IoT）；AAS（IEC 63278，IDTA 维护）是跨企业交换资产数据的容器标准，子模型模板是数字名牌、交接文档、技术数据、碳足迹、电池护照；IOF Core（OAGi + NIST，基于 ISO/IEC 21838-2 顶层本体）给通用制造概念 + 生产计划 / 维护 / 生物制药模块；ISA-95 管组织层级、OPC UA 管实时通信与信息模型。**一句分辨：OPC UA 告诉你机器现在在干什么，AAS 告诉你机器是什么 —— 它们都不管工艺机理。**
2. **更关键的是它们自己承认边界**：CleVR 综述原话「no predefined ontology knows your company. Your product families, naming conventions, plant-specific processes and in-house systems still have to be modelled. Predefined ontologies shift the work from **inventing to extending**, which is the difference between **months and weeks**.」→ **现成标准的价值是省时间，不是省掉工作**。它还给了一条与 L2/L3 相通的起手式：「Start from the decisions, not the data」、competency questions（先写下人和 agent 必须能回答的问题，这组问题就是测试集）、「Only model what makes your company different」；并指出自动化只能加速步骤 2–5，**决定业务是什么意思、谁负责，仍是人的活**（接 #3 的理货员/设计师）。Bosch 案例：自动把领域本体重塑成更精简的图 schema，焊接数据知识图谱生成快 7–8 倍（二手）。
3. **她说的「大规则下面有细节规则」，行业里几乎一字不差**：中国机械工程学会《制造业自动化》2026(5)〈面向工业PLC场景的隐性工艺知识工程方法〉原话「在非标产线设计场景中，**其底层功能单元具备可复用性**，实际开发过程中则需要面对大量个性化需求」；山东设计院非标装配那篇说「产品种类多、批量小、换型频繁，使得装配工艺需要反复重新设计，**历史工艺知识的复用率极低**」。**两句同时成立，正因为说的是不同的层。** 前者还指出 RAG 在工艺知识上的两层结构性障碍：知识可访问性（梯形图等图形化格式 + 无结构化索引）、功能关联完整性（一个完整功能块由若干代码段组成，语义上不必然关联，向量检索保证不了完整召回）→ 直接关联她的 klgwiki / 检索层。

##### 把「复用」拆成三层（判据：换一家厂，这句话还成立吗？）

| 层 | 烘箱 / 非标里的样子 | 换厂还成立 | 谁的 | 可复制的是什么 |
|---|---|---|---|---|
| **上层 · 通用大类** | 设备、工序、批次、工位、资产名牌、BOM 怎么交换 | 成立 | 厂商与标准组织 | 已商品化，**不是你的生意**；价值只是省时间 |
| **中层 · 骨架** | 需求→工艺路线→节拍→选型→虚拟调试；谁影响谁；验收口径；**怎么把老师傅说不清的经验问出来**；怎么验证、怎么改、怎么留版本 | 大部分成立 | **你** | **这才是资产**：问法、分层、验证与写回机制 |
| **下层 · 细节规则** | 78 度、25 秒节拍、不良分 7 类、第 3 类要班长签字 | 不成立 | 客户 | **本来就不该复制**；这是客户自己的差异 |

她自己写的「会有一些大的规则，下面又会有一些细节的规则」就是这张表的雏形，**她已经把分层说出来了，只是还没把「被复用的对象」从数据换成结构**。

##### 两个可评判的判据（不是执行方案，是验收口径）

1. **归属判据**：每写一条规则，问「换一家厂，这句话还成立吗」→ 成立进模板，不成立留在客户那一层、别往产品里塞。顺带解决「不用一次性把整个本体定死」：每条规则各有归属即可（**不劝收尾，只给分类**）。
2. **复利判据**：不要问「A 家的数据能不能给 B 家用」，要问「做第 2 家、第 3 家时，花的功夫有没有变少」。第 1 家 8 周 / 第 2 家 4 周 / 第 3 家 2 周是**示意不是实测**；要的是曲线往下走。**曲线往下＝在攒资产，一直是平的＝在做项目。** 这才是「可复制价值」真正的验收口径，接《AI Engineering》ch3–4 的评测流水线与 Albrecht slides 的基线自检：先定义什么算改善，再谈有没有改善。

##### 反直觉的两点

- **不可复用 ≠ 没价值，只是价值形态不是「卖副本」。** 对客户来说，恰恰因为只属于自己才值钱：把厂里那些别人没有的讲究写进本体，这就是差异本身。Palantir 官方《Integrated platforms》把目标写成「deliver non-standard results: extreme differentiation through maintainable customization」、要「infusing their **particularities** into their ontology」，甚至说每次部署的野心是成为企业「unique, **one-of-one**, ever-evolving operating system」；还用 alpha / beta 区分：围绕差异化构建是 alpha，一刀切 SaaS 的低垂果实是 beta。**谁都能复用的那一层是标准品，是西门子 / 达索的活；低复用是护城河，不是库存。**
- **真正的危险不是她担心的那个。** 不是「数据不能给下一家用」，是「**每次学到的东西没地方沉淀**」。Palantir 官方把 FDE 称做「human equivalent of backpropagation」（人类版反向传播）；行业里那句更准：「**gravel road to paved highway**」—— 给一家客户修的是碎石路，只有反复出现的模式才被铺成标准产品功能；Epic IT 那篇列了 FDE 成立的三个条件，第三条正是「**The platform existed to absorb the lessons. Every FDE engagement fed insights back into the core platform. Without that, the model degenerates into bespoke services with no compounding value.**」→ **没有回流，就退化成没有复利的一次性服务。** 这正是她最后那句疑虑的精确版，只是病灶不在数据层。
- 另外一个与她路线图直接相关的分工（Palantir 内部 / 澎湃转述）：**Echo = 一种能力服务多个客户；Delta = 一个客户调用多种能力**。可复制的那层是 Echo，不可复制的那层是 Delta，两者都是 FDE，不矛盾。Palantir 官方《AI FDE》文档还显示 2026 年 AI 已在做「creating or updating the objects, links, and actions that make up your ontology」，但默认走分支 + 人审查合并（接 #3 的理货员/设计师）。

##### 再拉回一句：她说「除了做知识库可能不会出错」

这个贬低是对的 —— 只做到「查得准」确实不值那个钱。**但那不是本体的天花板，是停在 L1 了。** 本体真正值钱的是能问以前不能问的问题：节拍 30→25 秒瓶颈移到哪、温度异常是传感器漂移还是上游工艺变了、换产品族哪些机制仍成立。这些是 L2 / L3（接第 2、3 份笔记与 Causal AI ch8–10）。→ **可复制性不在下层细节里，在中层骨架里；价值不在「不出错」里，在「能改、能推、能验」里。两件事都跟客户那批具体数据无关。**

##### 一句带走

**别问「这批数据能不能给下一家用」，要问「下一家我是不是少走了弯路」。前者是库存，后者是资产。**

##### 本轮查证来源与可信度

- **一手**：Siemens 官方 Teamcenter 博客（AAS = IEC 63278、IDTA 110+ 成员、跨企业互操作）；OPC Foundation OPC 30270 AAS 规范（元模型、一个 AAS 只表示一个资产）；Palantir 官方《Integrated platforms: AIP, Foundry, and Apollo》（FDE = 人类版反向传播、one-of-one、alpha/beta、把 particularities 注入本体）与《AI FDE》官方文档（本体编辑能力、分支 + 人审）；中国机械工程学会《制造业自动化》2026(5) 非标 PLC 隐性工艺知识（底层功能单元可复用 / 个性化需求、RAG 两层障碍）。
- **二手（标注，不当硬结论引用）**：CleVR 工业本体综述（西门子 Intelligence Center X / IOF Core / AAS 对照、months vs weeks、Bosch 7–8 倍、七步法）；山东设计院非标装配 / 非标产线两篇（复用率极低、隐性经验随人走）；澎湃〈爆火的 FDE〉与 fde-engineers.com（Echo/Delta、碎石路→高速、2025-04→2026-04 岗位 643→5330「+729%」、Palantir 2023 盈利的项目制→产品化跃迁）；Epic IT FDE 分析（三个条件、no compounding value）；夜雨聆风「工业技术软件化」博客（把选型公式 / 工艺约束 / 材料参数打包成参数化模板与组件库）。**这些数字、日期、公司叙事未逐条回原文核对**，沿用笔记库既有约定。
- **概念地图**：[2026-11-07-can-ontology-be-replicated.html](2026-11-07-can-ontology-be-replicated.html)（概念图 ⑥：三层复用性对照 + 两个判据 + 第 1/2/3 家曲线示意 + 反直觉两点 + L1/L2/L3 拉回，light editorial，真实 HTML 文件）。

---

#### #5 · 2026-11-07 20:58

**侃姐原话**：
> 我现在有个想法：前面讲 tokenizer 不是有好几种吗？其实我想知道每一种分出来的结果是怎样的，会有什么不同吗？
> 然后用代码实现一下，包括 DeepSeek 是怎么分的。它其实有一些现成代码，不过我需要你来做一下。
> 你能不能分出一个 SubAgent 来做这件事情？然后把它放到 D 盘「AI Coding」下面的「DIY LLM」里，在里面建一个「tokenizer」文件夹。这个项目后面肯定还有很多需要代码验证、或者做出容易理解的内容，到时候都放到里面

**小 Q 的回答**：

##### A · 每种分法分出来到底差在哪

**一句话判断**：差别不在名字，在三件事 —— **切得长还是碎、碰到没见过的词怎么办、能不能原样拼回来**。同一句 10 个汉字的「夏天湿度影响烘箱温度」，在不同分法下可以是 1 块、6 块、10 块，甚至 30 块。

**同一个例子贯穿到底**（沿用烘箱场景，不换场景）：

| 分法 | 「夏天湿度影响烘箱温度」切出来 | 块数 | 碰到「虚拟调试」 |
|---|---|---|---|
| 词级 · 基础正则 `\w+|.` | 中文没空格 → 整串当 1 块 | 1 | 词表没见过 → **「不认识」，信息丢** |
| 词级 · DeepSeek 风格简化正则 `\p{L}+` | 也是整串 1 块 | 1 | 同上 |
| 字符级 | 夏\|天\|湿\|度\|影\|响\|烘\|箱\|温\|度 | 10 | 拆成 4 个字，不丢 |
| 字节级 | 每个汉字 3 个 UTF-8 字节 | 30 | 12 个字节，绝对不丢 |
| BPE（自训） | 看语料里谁最常挨着，如 温度 / 湿度 粘成块 | 中间 | 拆成见过的零件 |
| WordPiece | 夏\|##天\|##湿…（`##` 表示「接在后面」） | 中间 | 同上，带前缀 |
| Unigram | 从一堆候选里按概率挑一种切法 | 中间 | 同一个词可以有多种切法 |
| Byte-level BPE（自训） | 从 30 个字节起步，把常见的粘回来 | 中间 | 没有「不认识的字」，只是碎 |
| **真实 DeepSeek-V3** | **夏天\|湿度\|影响\|烘\|箱\|温度** | **6** | **虚拟\|调试（2 块）** |
| **教材用的 DeepSeek-Coder** | 夏天\|湿\|度\|影响\|烘\|箱\|温度 | **8** | 虚\|拟\|调\|试（**4 块**） |

**三件真正要懂的事**：

1. **切得长还是碎**：词级最省块但会撞生词，字节级最稳但一块只装一个字节。BPE 一族就是在两头之间找位置 —— 让语料自己决定哪些字该粘成一块。
2. **碰到没见过的词怎么办**：这是三代做法的分水岭。词级直接认输（「虚拟调试」= 不认识）；字符 / 字节级硬拆，不丢但太长；子词级拆成见过的零件 —— V3 里「虚拟」「调试」都在词表里，所以 2 块就够，coder 版词表小、只认识单字，得 4 块。
3. **能不能拼回去**：字符级 / 字节级 / 官方 DeepSeek 都能无损还原（实测 8 句全部 `decode(encode(s)) == s` 为 True）。词级一旦出现「不认识」就拼不回去了。

**一个能直接记住的数字（中文为什么"贵"）**，用 V3 真实词表实测：

| 句子 | 字符数 | 块数 | 一块装几个字符 |
|---|---|---|---|
| Attention is all you need | 25 | 5 | **5.00** |
| 夏天湿度影响烘箱温度 | 10 | 6 | **1.67** |

同样一块，英文装的字数是中文的 3 倍。**中文更贵不是模型偏心，是词表训练语料里英文占多数** —— 这条可以直接写进企业交付的成本口径（接 #2 与《AI Engineering》ch10）。

**strawberry 那个梗的真实现场**：V3 把它切成 `st|raw|berry`，里头的 r 藏在块内部，模型从没单独看见过字母；句子末尾那个孤立的 `r` 倒真是单独一块。所以"数几个 r"天生吃亏，不是笨。

**数字也被规则管着**：V3 把 `82`、`78` 各当一块，`2026` 切成 `202|6` —— 因为官方预分词里有一条「数字最多 3 位一组」；教材用的 coder 版没有这条，`8|2`、`7|8`、`2|0|2|6` 全拆开。

**教材 4.3 那句「空格 ID 都是 223」，实测一半对**：
- **DeepSeek-V3 确实是 223**（`Hello, 世界!` 里那个单独成组的空格）；但**教材用的 coder 版是 207**，教材混淆了两个模型。
- 而且 223 只适用于「单独成一组」的空格：`a b` 里空格跟 b 粘成 `' b'`（ID 291），两个连续空格 `'  '` 是 ID 262 一整块。**教材漏了限定条件。**

**「显示乱码」不是丢数据**：单独 decode 一个 emoji 块会得到替换符号 `\ufffd`，因为一个 4 字节 emoji 被拆进好几个块，单看一块拼不出完整字符。整串 decode 全部能原样还原。这正是教材里"中文 token 显示像乱码"的真相 —— 是**查看方式**的问题，不是编码坏了。

**merges 就是那张「先粘哪对、后粘哪对」的顺序表**（真实文件，不是比喻）：

| 词表 | 总条数 | 前 5 条 | 后 5 条 |
|---|---|---|---|
| DeepSeek-V3 | 127741 | `Ġ t` `Ġ a` `i n` `Ġ Ġ` `h e` | `Ġpur ify` `ml ich` `èģļ å±ħ` `Ġbott oms` `å±ĭ æªIJ` |
| DeepSeek-Coder | 31757 | `Ġ Ġ` `Ġ t` `Ġ a` `i n` `h e` | `Ġd it` `ÑģÑĤ виÑı` `als a` `Ġcertain ty` `ĠSh an` |

`Ġ` 是空格在字节级里的可显示替身（教材 4.2 的 latin1 就是为了让 0–255 每个字节都能当字符来粘）。**教材附录 6 让手写的，就是这张表。**

**教材的简化正则 ≠ 真实实现**：教材用 `\p{L}+|\p{N}+|...`，会把整串汉字当成一个 chunk。真实 V3 的预分词是 4 步 —— ① `\p{N}{1,3}` 数字单独切；② `[一-龥぀-ゟ゠-ヿ]+` **把 CJK 汉字 / 日文假名单独切开**；③ GPT-2 式英文与标点正则；④ ByteLevel。差的就是「针对中文的那一步」。所以照教材代码能懂原理，但不能拿它的输出当 DeepSeek 的真实切法。

##### B · 代码交付

**项目专区（她指定的长期约定）**：`D:\AI Coding\DIY LLM\` = DIY LLM 这门课所有「需要代码验证、或者做出容易理解的内容」的专区，**按主题建子文件夹**，第一个是 `tokenizer/`。不散到会话目录，也不放进笔记库。已写进 `INDEX.md` 与项目长期记忆。

**按她要求分出了独立 agent**：它写出了一版完整的 8 种分法实现（`tokenizers_impl_subagent.py`，8 个方法 + `Seg` 结果对象 + 自检入口）；主链路 `tokenizers_impl.py` / `compare.py` / `bpe_train.py` / `deepseek_real.py` / `results.md` / `index.html` 由我同步落地。**过程中 agent 的版本覆盖了主链路模块导致接口冲突，我验收时抓到并修复了**：两套实现各自保留、各自能跑，另加一个 `compare_subagent.py` 让 agent 版在同一批 8 句上复算。

**环境**：零新增依赖、完全离线。本机已有 `transformers 5.17` / `tokenizers 0.23.2` / `tiktoken` / `regex`；`huggingface.co` 直连 SSL 握手失败，改走 `hf-mirror.com`（10 秒测速约 250KB/s）下载两个官方 `tokenizer.json` 落到 `data/`。

**产物**（`D:\AI Coding\DIY LLM\tokenizer\`）：
`README.md`（约定 + 怎么跑 + 限制）、`tokenizers_impl.py`（主实现）、`compare.py`（8 分法 × 8 句对比 + 词表查询 OOV 演示）、`bpe_train.py`（merges 顺序表）、`deepseek_real.py`（两版官方词表真实分词 + 教材纠错）、`tokenizers_impl_subagent.py` + `compare_subagent.py`（agent 版）、`index.html`（light editorial 可视化页，双击即开）、`results.md`（真实结果 + 白话解读）、`compare_output.txt` / `bpe_merges.txt` / `deepseek_output.txt` / `subagent_output.txt`（原始输出）、`data/SOURCES.md` + 两个 JSON。

**怎么跑**：在本目录 `python -X utf8 compare.py` / `bpe_train.py` / `deepseek_real.py` / `compare_subagent.py`；不想跑代码就双击 `index.html`。

**验收结果**：5 个脚本全部 `exit=0`；8 句语料对两个官方词表整串 `decode(encode(s)) == s` 全部 True；HTML 标签闭合检查通过。`results.md` 里的数字全部来自实际运行的 `.txt`，没有「预期输出」。

**跑出来的一个额外教学点**：主链路 BPE 做 60 次合并，把整句「夏天湿度影响烘箱温度」粘成 1 块（小语料过拟合）；agent 版只做 12 次合并，切出 7 块（`夏天湿度|影|响|烘|箱|温|度</w>`）。**两版互相反证：词表是语料的产物，不是字典。** 这也接回 #2 里「给垂直模型加专有 token 要谨慎」。

**带读状态**：这轮是她自己点名要动手验证，仍按老规矩 —— 不推进段落、不排期、不承诺下一讲。

---