notes · books

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

2026-11-07-diy-llm-ch2-tokenizer.md

起于 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-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。核心 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（三幕 + 翻车名场面 + 两个 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（概念图 ⑤：三种「自带」对照 + 老师傅 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（概念图 ⑥：三层复用性对照 + 两个判据 + 第 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 要谨慎」。

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

查看原始文件：2026-11-07-diy-llm-ch2-tokenizer.md · 回书架
同目录：AI Engineering（Chip Huyen）— 读书笔记 · Becoming an AI Researcher — 讲座 slides 读书笔记 · Causal AI（Robert Osazuwa Ness）— 读书笔记 + 世界模型辨析 · 带读笔记：X-Mobility v3 + ReMEmbR 原论文 · 四份机器人基础模型材料：ReMEmbR / X-Mobility / 综述 / NVIDIA 博客