Tokenization：RAG系统的隐形胜负手
你给AI投喂了一段"完美"的知识库。
段落清晰、内容详实、甚至还贴心地排了版。
结果它答非所问。
你开始怀疑模型是不是"傻"。
但问题可能出在：喂进去的内容，被切成了错误的形状。
这就是今天要聊的：Tokenization对Prompt、RAG和长文本处理的影响。
上篇文章我们算了算Token的账，搞清楚了上下文窗口和费用之间的关系。
但你有没有想过：同一个意思，切法不同，效果天差地别？
分词：同一句话，拆法不同命运就不同
先说个冷知识。
"今天天气真好"——这句话，英文是7个字符。
但转成Token，可能变成6个。
中文呢？"今天天气真好"是6个字符。
但切完，可能是2个Token，也可能是8个。
看你用的是哪个分词器。
这就是Tokenization的本质：把文本拆成模型认识的"最小单元"。
不同的拆分方式，直接决定了两件事：
一，你花了多少Token。
二，模型能不能准确理解你的意思。
三种主流分词器，你用的是哪一种？
BPE、WordPiece、SentencePiece——这三个名字你可能见过，但不一定清楚区别。
简单说：
BPE像个贪心的厨师，从单个字符开始，每次把最常一起出现的两个"食材"合并成一个新词。
WordPiece更像谨慎的经理，它合并的依据是"这个词能不能让整个句子更可能是对的"。
SentencePiece则是个实用主义者，它不管语言边界，直接根据频率统计来切分。
对中文来说，这三种切法差异巨大。
"机器学习"四个字：
BPE可能切成"机"、"器"、"学"、"习"——4个Token。
SentencePiece可能切成"机器"、"学习"——2个Token。
差了整整一倍。
你的Prompt用了多少Token、模型理解了多少、最终输出质量如何，全看这一步。
RAG的命门：你的知识库是怎么被"大卸八块"的？
说完了基础分词，现在聊RAG。
RAG是什么？检索增强生成。
说人话就是：AI回答问题之前，先去知识库里翻一翻，找到相关材料，再组织答案。
这个"翻一翻"的动作，就是检索。
而检索的前提是——知识库被切成了合适的块。
这一步叫分块，英文chunking。
分块策略选错了，检索就变成了大海捞针。
为什么？
想象你去图书馆找"红烧肉的做法"。
如果书被拆成了单字索引——"红"、"烧"、"肉"、"的"、"做"、"法"——你翻到的是一整页包含这些字的内容，什么都有，什么都不精确。
如果书被拆成了整章——整本《中国菜大全》——你找到的是目录，但具体做法藏在几千字里，AI可能漏掉关键步骤。
最理想的情况是：书被拆成了菜谱级别的段落。
每块讲一道菜，有标题、有步骤、有配料。
检索命中率高，AI理解起来也轻松。
所以啊，分块大小直接决定了检索质量。
太小了，上下文丢失。
太大了，噪声太多。
那多大才算"刚刚好"？
sentence transformers对单句处理效果更好。
text-embedding-ada-002在256或512个Token时达到最优性能——这是OpenAI自己文档里写的。
太短，单句信息不足。
太长，语义稀释。
找到这个平衡点，是RAG系统的关键。
三种RAG范式：选对策略比努力更重要
光知道要切分块还不够。
你怎么"用"这些块，决定了系统的上限。
这里有三种主流范式。
初级RAG：直来直去
用户问一个问题，系统去知识库里检索相关内容，然后直接喂给模型生成答案。
简单直接，适合简单场景。
但问题也很明显：用户的问法和知识库的表述方式可能不匹配。
用户问"怎么提高模型准确性"，知识库里写的是"模型性能优化方法"。
检索不到，答非所问。
这就是语义鸿沟。
高级RAG：多层过滤
针对初级RAG的缺点，高级版加了几个步骤：
先做查询重写，把用户的口语转化成更适合检索的表述。
再做混合搜索，结合关键词匹配和语义理解。
最后多步检索，先粗筛再精筛。
这就像图书馆的 librarian 不再只是找包含关键词的书，而是先理解你到底想干什么，再帮你定位到最相关的章节。
适合复杂查询，但实现成本更高。
模块化RAG：灵活组装
到了这个级别，RAG变成了一个乐高系统。
你可以根据场景自由组合：
查询重写模块、子问题分解模块、多跳推理模块、假设答案增强模块……
不同任务用不同组合，像搭积木一样构建专属的RAG系统。
适合多样化需求，但需要更强的工程能力。
从初级到高级到模块化，本质上是在解决一个问题：
怎么让检索结果更贴近用户真正想要的答案。
选哪个？不是越复杂越好。
简单问答用初级RAG就够了。
需要精准的复杂任务，上高级RAG。
你的系统要服务多种场景？考虑模块化。
量体裁衣，够用就行。
让检索更准的技术
聊完范式，再看几个具体技术。
HyDE：用假设答案去找答案
与其猜测用户想问什么，不如直接生成一个"正确答案"的样子，然后用它去检索。
这是HyDE的核心思路。
用户问"怎么写好Prompt"。
系统先根据这个问题，生成一段"高质量Prompt示例"。
然后把这段假设答案向量化，去知识库里检索真正相关的内容。
最后用真实内容回答。
为什么效果好？
因为一个好的Prompt示例，和知识库里的优质内容，在向量空间里更接近。
你用"标准答案的形状"去捞，比用"问题"去捞更准。
子问题分解：化整为零
复杂问题往往不是一句话能回答的。
"机器学习在医疗领域的应用现状和未来趋势"——这个问题包含两个部分：现状和趋势，领域是医疗。
子问题分解的做法是：把大查询拆成小问题。
子问题1：机器学习在医疗领域的应用现状？
子问题2：机器学习在医疗领域的未来趋势？
每个子问题去不同的数据源检索。
最后把答案合并。
查询嵌入转换：对齐向量空间
有时候问题出在"表达方式不同"上。
用户说"电脑太卡了"，知识库里写的是"系统响应延迟"。
意思一样，但向量表示可能差很远。
查询嵌入转换的作用是：把用户的查询向量，映射到更接近知识库内容的向量空间。
技术上可以是微调的嵌入模型，也可以是提示词工程。
本质就一句话：让问的人和答的人，说的是同一种语言。
长文本处理的三个坎儿
RAG系统处理长文本，会遇到三个问题。
问题一：上下文窗口越来越大
GPT-4支持128K Token，Claude支持200K Token。
上下文窗口大了，理论上能处理更多内容。
但实际上，模型对"中间位置"的内容注意力会下降。
这叫"中间迷失"问题。
怎么解决？RAG系统需要更智能地选择要放进上下文的片段。
不是把所有相关的内容都塞进去，而是选择最关键、最相关的那部分。
这对分块策略提出了更高要求。
你需要知道：哪一块内容最可能回答用户的问题？
问题二：处理矛盾信息
知识库里的内容可能过时了，甚至有错误。
用户问的是2024年的最新进展，但RAG检索出来的是2022年的旧资料。
AI可能把过时的信息当成正确答案。
怎么解决？
需要引入信息时效性评估机制。
给每块内容加上"时间戳"标签，优先检索最新内容。
或者在Prompt里明确要求：只基于以下材料回答，如果材料过期请注明。
问题三：RAG和微调的结合
RAG是动态检索知识，微调是固化能力到模型里。
两者结合效果更好，但怎么做？
目前没有标准答案。
有的做法是：微调一个"判断"模型——判断当前问题是否需要检索，检索什么关键词。
有的做法是：用RAG生成的数据微调模型，让模型学会更好地利用上下文。
这个方向挺有意思的，值得关注。
怎么找到你的最优分块策略
说了这么多理论，怎么落地？
语义分块：让段落自己"说话"
传统分块就是按固定长度切，比如每512个字符一切。
但语义分块不同。
它先识别文本中的语义边界——哪里是段落、哪里是主题转换、哪里是完整句子。
然后按照语义单元来切分。
每个块内部语义连贯，和其他块之间有明确的边界。
这样检索的时候命中的内容更完整。
递归检索：小中见大
怎么决定分块大小？
有个策略叫递归检索。
先从小片段开始检索。
如果召回的内容太少或太碎片，扩到大一级的块。
再不够，继续扩大。
直到找到"刚刚好"的那个粒度。
就像用筛子筛东西，先用细筛，漏掉的再用粗筛。
调优四步法
第一步：确定目标。
你想优化的是准确率、召回率还是响应速度？
目标不同，策略就不同。
第二步：选择初始分块大小。
根据上文说的，256或512个Token是个不错的起点。
第三步：A/B测试。
准备两套知识库切片，分别部署，对比效果。
第四步：迭代优化。
根据测试结果调整粒度、优化检索策略。
这可能需要几轮实验，但每一步都值得。
因为最终的效果提升，可能超过你的预期。
最后
写了这么多，回到一个根本问题：
为什么Tokenization这么重要？
因为它是AI系统的"基础设施"。
你用的Prompt、分块的知识库、检索的结果、生成的答案——
这一切的起点都是：文本怎么被拆成Token。
上篇文章我们算了Token的成本。
这篇文章我们看了Token的质量。
成本和质量加在一起，才是Token的完整故事。
你可能觉得这些都是"底层细节"，不重要。
但我之前做过一个RAG项目，同样的架构、同样的模型，换了一套分块策略，效果差了30%多。
这才意识到：细节决定成败，在AI系统里体现得淋漓尽致。
接下来，你可以带着这些视角，重新审视自己的AI应用。
问题也许不在模型本身，而在那些容易被忽视的细节里。
下次见。