【AI工程实践】本地大模型RAG系统的中文分词优化实战

本地 RAG 系统跑通之后，英文文档检索基本可用，换成中文就出了岔子。检索结果要么太泛要么偏题，调向量模型和搜索策略也没什么效果。最后发现问题出在分词上。中文没有天然的词边界，分词工具怎么处理，Embedding 模型就怎么理解。

中文分词为什么影响 RAG？

大模型的理解依赖词边界。英文天然有单词分隔，中文没有。如果分词工具把专业术语拆散，Embedding 模型就无法生成准确的向量表示。

举个例子，"RAG系统" 这个词组：

jieba 默认模式会拆成 "RAG" + "系统"，如果文档库里没有独立的 "RAG" 词条，检索时会漏掉大量相关结果。更复杂的场景比如 "知识图谱增强生成"，被拆成 "知识" + "图谱" + "增强" + "生成" 四个通用词，语义信息严重流失。

实测数据：用同一个 BGE-M3 Embedding 模型，同一组中文问答，jieba 默认分词 vs 不做分词直接按字符切，召回率差距接近 20%。不是分词本身不好，而是默认分词的方式不适合 RAG 场景。

三种主流分词方案实测

jieba 仍然是使用最广的中文分词库。它的词典覆盖日常用词没问题，技术文档就不太够用了——"自然语言处理" 这种词大概率被拆成 "自然"、"语言"、"处理"。自定义词典可以补，但维护成本跟着文档规模上涨。

PaddleNLP 走的是深度学习路线。不靠词典匹配，靠模型判断词边界。实测在技术文档场景下准确率高 8-12%，代价是推理速度大约只有 jieba 的三分之一，部署还要带上 PaddlePaddle 框架。

pkuseg 的思路不同：支持用你自己的文档训练领域专属模型。北大计算语言学研究所开发，训练一次大概 30 分钟，之后推理速度跟 jieba 差不多。如果你有一批稳定文档要做 RAG，这条路投入产出比最高。

怎么选

通用中文文档，jieba 加一份自定义词典就够用。把项目里的术语、产品名、缩写丢进用户词典，维护成本可控。

文档技术性强且不想训练模型，PaddleNLP 开箱即用。文档域明确而且长期使用，pkuseg 的领域训练一次投入，长期受益。

不一定非要分词。BGE-M3 这类多粒度 Embedding 模型，直接拿字符级输入效果并不差。实测字符级切分比 jieba 分词在问答准确率上差距不到 3%，省了分词环节，链路也更短。

几个建议

先跑基准测试。拿自己的文档和查询集分别试 jieba 默认分词、字符级切分、PaddleNLP 分词，对比召回率和生成准确率。网上的通用 benchmark 参考价值有限，你的文档域很可能和测试集完全不同。

维护术语表。不管选哪种方案，一份项目专属的术语表几乎跑不掉。把它交给分词工具当用户词典，比指望通用模型自动识别靠谱。

考虑直接跳过分词。如果你的 Embedding 模型支持字符级编码，先试最简方案，效果往往不差。