1. 从“词”的困境说起：为什么非拉丁语系在LLM里总是“支离破碎”？
如果你最近在本地部署过大语言模型，并且尝试用它来处理中文、日文或者阿拉伯文，大概率会遇到一个让你头疼的问题：模型输出的文本，尤其是涉及专业术语、人名地名或者新词时，经常会变得“支离破碎”，出现一些莫名其妙的字符片段，或者干脆胡言乱语。这背后的核心症结，就是我们今天要深入探讨的“分词碎片化”问题。对于英语、法语等拉丁语系语言，主流的大语言模型（LLM）在预训练阶段通常采用像BPE（Byte Pair Encoding）或WordPiece这样的子词分词算法，这本身没什么问题。但当模型面对中文、日文（假名与汉字混合）、泰文、阿拉伯文等非拉丁语系语言时，这套“西方中心”的分词方案就水土不服了。
问题的根源在于，这些分词算法本质上是一种基于统计的压缩算法。它们的目标是找到一个平衡：既要让词汇表大小可控（比如3万到10万），又要尽可能覆盖训练语料中的常见字符序列。对于英语，单词之间有空格天然分隔，BPE可以很优雅地从字母开始，逐步合并出“ing”、“tion”、“un-”等高频子词，最终形成“understandable”这样的完整词。但中文没有空格，一个句子就是一连串的字符。BPE处理中文时，会从单个汉字开始合并。由于汉字本身是语素，且组合灵活，算法很容易产生一些不符合语言直觉的“碎片”。例如，它可能把“人工智能”拆成“人工”和“智能”，这还算好；但也可能把“巧克力”拆成“巧克”和“力”，或者把“清华大学”拆成“清华”和“大学”，而“清华大学”作为一个专有名词，在语义上是一个不可分割的整体。更糟糕的是，对于训练语料中罕见的专有名词、科技术语或网络新词，模型可能从未见过其完整形式，只能将其拆解为更细碎、语义模糊的片段，比如把“Transformer架构”拆成“Trans”、“former”、“架”、“构”。这些碎片作为模型的输入，其向量表示无法准确承载原词的完整语义，导致模型在理解、生成、推理等下游任务上表现不佳。
这不仅仅是美观问题，它直接影响模型的能力上限。当我们在探讨大语言模型能否实现AGI（通用人工智能）时，一个基本前提是它必须能无歧义地理解和生成人类的所有主要语言。分词碎片化就像给模型戴上了一副布满裂痕的眼镜去看世界，它看到的“信息图景”本身就是扭曲和断裂的。因此，解决非拉丁语系的分词问题，不是简单的工程优化，而是提升LLM多语言能力、迈向更通用智能的关键一步。最近学术界和工业界开始关注这个问题，并提出了一些方法，其中一种思路清晰、颇具潜力的方案就是“FragMend”。
2. FragMend的核心思想：不是替换，而是“修补”与“解释”
在深入FragMend的细节之前，我们先要理解它解决问题的哲学。面对现有分词器的缺陷，最直接的想法可能是“推倒重来”：为中文专门设计一个更好的分词器，或者训练一个全新的多语言分词模型。但这面临着巨大的工程和生态迁移成本。几乎所有主流LLM（如GPT系列、LLaMA系列）都深度耦合了其预训练阶段使用的分词器（如GPT-2/3/4用的BPE，BERT用的WordPiece）。更换分词器意味着要重新对海量语料进行分词并重新预训练模型，这几乎是不可承受之重。
FragMend选择了一条更巧妙、更实用的路径：它不尝试替换或修改模型原有的分词器，而是在分词结果“之后”、模型理解“之前”，插入一个“修补”层。这个修补层的目标，是将那些被错误切分的、碎片化的子词（Token）序列，重新“粘合”成具有完整语义的单元，并将这个“粘合”过程以一种可解释、可计算的方式，注入到模型的推理过程中。
我们可以用一个类比来理解：想象原始的分词器是一个固执的切菜工，不管食材是什么，都只用一种刀法（BPE算法）来切。面对一根完整的胡萝卜（一个完整词汇），他可能切成丁、切成条，甚至切成不规则碎块（碎片化子词）。FragMend则像是一位经验丰富的厨师，他接收这些形状不一的胡萝卜块，能快速识别出它们原本属于同一根胡萝卜，并在脑海中（模型的计算图里）将它们“虚拟地”重组回完整的胡萝卜，再基于完整的胡萝卜来思考这道菜怎么做。这个“识别”和“虚拟重组”的过程，就是FragMend要做的。
具体来说，FragMend方法通常包含两个核心阶段：
- 碎片检测与候选生成：给定一个输入文本，经过原始分词器得到一串子词序列。系统需要检测其中哪些子词序列很可能是某个完整词汇的碎片。例如，对于子词序列
["清华", "大学"]，系统应能检测到这是一个候选的完整词“清华大学”。这个过程需要借助外部知识源，如大规模词典、领域术语库，或通过神经网络模型来预测子词之间的粘合概率。 - 可解释性融合：仅仅检测出候选完整词还不够，关键是如何让大语言模型“接受”并使用这个信息。FragMend的核心创新在于，它不直接修改输入的Token序列，而是生成一种“可解释的提示”或“语义补丁”。例如，它可能会向模型的输入中注入一段特殊的指令或上下文，如：“注意：接下来的片段‘##清华’和‘##大学’在本文中指代的是‘清华大学’这个实体。”或者，它通过修改注意力机制中的某些权重，让模型在计算时，对“清华”和“大学”这两个Token给予更强的关联性注意力，模拟它们作为一个整体被处理的效果。这个过程是“可解释”的，因为我们可以追溯是哪个规则或哪个检测器触发了这次“粘合”，以及“粘合”后形成的语义单元是什么。
这种方法的好处显而易见：轻量、非侵入、可插拔。它不需要改动预训练模型的任何参数，可以作为一个预处理模块或一个小型适配器，灵活地接入现有的LLM服务管道。这对于当前火爆的“本地部署大语言模型”场景尤其友好，用户可以在不重新训练庞大基座模型的情况下，显著提升模型对特定语言（如中文）或特定领域（如医疗、法律）文本的处理能力。
3. 实现FragMend：从词典匹配到神经感知的融合策略
理论听起来很美，但具体如何实现一个FragMend系统呢？根据其核心思想，我们可以设计一个从简到繁、逐步增强的实施方案。这里我结合常见的工程实践，拆解几个关键模块。
3.1 基础层：基于外部词典的精确匹配与替换
这是最直接、最快速见效的一步。你需要为你的目标语言（如中文）构建一个高质量、覆盖广泛的词汇表。这个词表不仅包含通用词典，还应纳入：
- 领域术语：你业务场景中的专业词汇（如“Transformer架构”、“随机梯度下降”）。
- 实体名词：高频人名、地名、机构名（如“OpenAI”、“清华大学”）。
- 网络新词与流行语：动态更新的词库。
实现流程：
- 预处理与分词：用户输入文本，首先用LLM原有的分词器（如
tiktokenfor GPT,sentencepiecefor LLaMA）进行分词，得到一个Token序列及其对应的字符串。 - 滑动窗口与查询：设计一个滑动窗口（例如，窗口大小从2到4个Token），遍历Token序列。对于每个窗口内的Token字符串进行拼接，然后在你的外部词典中进行查询。
- 冲突消解与最长匹配：一个字符串可能被多种方式匹配。例如，“人工智能智能”可能匹配“人工”（2字）、“人工智能”（3字）和“人工智能智能”（4字，如果词典里有这个生造词）。这里需要采用“最长匹配”原则，优先匹配更长的、更完整的词汇单元，这是中文分词领域的经典策略。
- 生成修补指令：一旦匹配成功，比如窗口
["人工", "智能"]匹配到词条“人工智能”，系统会生成一个“修补记录”。这个记录不会直接修改Token序列，而是包含：原始Token索引范围（如索引1-2）、对应的完整词汇“人工智能”、以及该词汇的语义类型（如“技术术语”）。
# 一个非常简化的概念性代码示例 class DictionaryFragMend: def __init__(self, dictionary_path): self.vocab = self.load_dictionary(dictionary_path) # 加载词典 self.max_word_len = max(len(w) for w in self.vocab) # 词典中最长词的长度（按字计） def mend(self, tokenized_text): """ tokenized_text: 列表，每个元素是(token_id, token_string) 返回: 修补记录列表 [(start_idx, end_idx, merged_word), ...] """ chars = ''.join([t[1] for t in tokenized_text]) # 将token字符串拼接回原始文本（近似） records = [] i = 0 while i < len(chars): matched = None # 从长到短尝试匹配 for l in range(min(self.max_word_len, len(chars) - i), 0, -1): candidate = chars[i:i+l] if candidate in self.vocab: matched = candidate # 需要找到这个candidate对应了哪几个token，这里涉及token到字符的映射，略复杂 # 假设我们有一个函数能完成这个映射：find_token_indices start_idx, end_idx = self.find_token_indices(tokenized_text, i, i+l) records.append((start_idx, end_idx, matched)) i += l # 跳过已匹配的部分 break if not matched: i += 1 # 未匹配，移动一个字符 return records注意：这里有一个关键的技术细节——对齐。原始分词后的Token和原始文本的字符不是一一对应关系（特别是BPE可能产生
##开头的后缀）。在实际操作中，你需要精确维护Token到原始文本字符偏移量的映射，才能进行准确的匹配和范围定位。这是第一个容易踩坑的地方。
3.2 增强层：融入统计与神经语言模型
仅靠静态词典远远不够。语言是活的，新词不断涌现，且同一个字串在不同语境下是否成词也不确定。例如，“苹果”可能是一个水果，也可能是“苹果公司”。这就需要更智能的判定。
- N-gram统计：利用大规模语料库，计算任意字串的共现频率。如果“巧克”和“力”在大规模文本中总是紧挨着出现，且其组合频率远高于它们各自与其他字搭配的频率，那么它们构成一个完整词“巧克力”的概率就很高。这可以作为词典匹配的补充评分。
- 神经序列标注模型：训练一个小型的、高效的神经网络模型（如BiLSTM-CRF或轻量级Transformer），将其作为一个“碎片探测器”。它的任务是进行序列标注：输入是原始分词后的Token序列，输出是每个Token的标签，例如
B（词汇开始）、I（词汇中间）、E（词汇结束）、S（单字词）。这样，模型就能学习到更深层的语法和语义规律，识别出那些词典未收录但符合语言习惯的词汇片段。- 训练数据：可以用正确分词的中文语料（如人民日报语料）来构造训练数据。先对语料用目标LLM的分词器进行“错误”分词，得到碎片化的Token序列作为输入，以正确分词边界作为标签。
- 优势：此模型能处理歧义和未登录词，泛化能力更强。
3.3 融合层：将“修补信息”注入LLM推理
这是FragMend最具挑战性也最核心的一环。检测出了碎片和其对应的完整词，如何让LLM“买账”？目前有几种主流思路：
- 提示工程法：最简单的方法，将修补信息作为系统提示或用户上下文的一部分。例如，在用户问题前加上：“请特别注意：下文中的‘##Trans’和‘##former’指的是‘Transformer’模型。” 这种方法零成本，但效果有限，严重依赖模型对指令的遵循能力，且会占用宝贵的上下文窗口。
- 注意力偏置法：在模型计算注意力时，对属于同一个完整词的Token对（如“清华”和“大学”）添加一个偏置项（bias），增加它们之间的注意力权重。这相当于在模型内部软性地提示“这些Token关系密切”。实现上需要能干预模型注意力计算的过程，对于开源模型（如LLaMA）可以通过修改推理代码实现，对于闭源API则无法使用。
- 虚拟Token注入法：这是一种更“硬核”的方法。在模型的嵌入层（Embedding Layer）之前，我们不直接输入原始Token的ID，而是输入一个“扩展词汇表”。这个扩展表里包含了我们检测出的完整词（如“
<清华大学>”）。系统会为这个新词动态生成一个嵌入向量，这个向量可以由其组成子词的嵌入向量通过某种方式（如平均、加权和）聚合而成。然后，在模型前向传播时，用这个虚拟Token的嵌入来替代原来碎片Token序列的嵌入。这种方法效果可能最好，但实现复杂，需要更底层的模型接入，并且要处理动态词汇表带来的序列长度变化问题。
在实际工程中，我通常会采用混合策略：对于高频、确定的词汇（来自高质量词典），采用提示工程或注意力偏置；对于歧义大或新发现的候选词，则利用神经探测器的置信度分数，只有分数高于阈值时才进行干预，避免引入噪声。同时，所有干预行为都需要记录日志，形成可解释的报告，方便后续分析和优化。
4. 实战评估与效果边界：FragMend不是银弹
任何技术方案都有其适用范围和局限性，FragMend也不例外。部署之后，我们需要一套严谨的方法来评估其效果，并明确它的能力边界。
4.1 如何评估FragMend的效果？
不能只靠“感觉”，需要设计可量化的评估任务：
词汇完整性感知测试：
- 任务：给模型输入一个包含碎片化专有名词的句子，让其进行填空、释义或问答。
- 示例：
- 输入（经原分词器）：
“##Trans ##former 架构在自然语言处理中非常流行。” - 问题：
“上文提到的架构是什么？” - 未启用FragMend：模型可能回答“former架构”或产生混淆。
- 启用FragMend后：理想答案是“Transformer架构”。
- 输入（经原分词器）：
- 指标：回答的准确率、精确匹配率。
下游任务性能提升：
- 在中文阅读理解（如CMRC）、命名实体识别（如MSRA-NER）、文本分类等标准数据集上，对比启用FragMend前后模型性能的变化。重点关注那些包含大量未登录词、专业术语的样本。
- 在代码生成任务中，如果处理的是中文注释或变量名，观察代码正确率是否有提升。
生成文本质量评估：
- 让模型进行中文创作（写故事、写邮件）。人工或使用评估模型（如GPT-4作为裁判）从“流畅度”、“用词准确性”、“专业术语使用正确性”等方面进行打分对比。碎片化减少后，生成文本的连贯性和专业性应有显著改善。
4.2 FragMend的局限性：哪些坑需要注意？
- 过度修补（Over-mending）：这是最大的风险。如果碎片检测过于激进，可能会把不该合并的Token合并。例如，在句子“美国会通过法案”中，“美国”和“国会”都是词，但“美国会”合并在一起就是错误。这要求我们的检测器必须有很高的精确率，而非单纯追求召回率。我的经验是，宁可漏修，不可错修。一次错误的合并可能彻底改变句意，导致灾难性后果。
- 语义稀释：即使正确合并，通过平均子词向量得到的完整词向量，其语义表示可能不如在大量语料中直接训练得到的词向量精准。对于核心关键词，这种语义上的微小偏差可能在复杂的推理任务中被放大。
- 计算与延迟开销：碎片检测、词典查询、神经模型推理都会增加预处理时间。对于高并发、低延迟的在线服务，需要仔细优化这部分代码，可能需要对高频词进行缓存，或使用更快的检测模型（如ONNX加速）。
- 领域适应性：为一个通用场景构建的FragMend系统，在切换到医疗、金融等垂直领域时，效果可能下降。因为领域内有大量特有的术语和缩写。解决方案是支持领域词典的热加载，让系统能够根据不同场景动态切换或融合词库。
- 与模型提示的冲突：如果用户在提示词中故意使用了碎片化的写法来测试模型，或者在某些特定语境下碎片化才是正确的（比如讨论分词算法本身时），FragMend的自动修补可能会干扰用户的原始意图。因此，系统最好能提供一个开关，或设计一种更智能的语境感知机制。
5. 从FragMend看LLM多语言处理的未来
FragMend为我们提供了一个解决LLM分词偏见的务实思路。它本质上是一种“后处理”或“中间件”式的补偿策略。但放眼未来，这应该只是一个过渡方案。根本的解决之道，仍然在于预训练阶段。
- 更公平的多语言分词预训练：下一代LLM的预训练，应该在更平衡、质量更高的多语言语料上进行，并设计更能适应不同语言特性的分词算法。例如，对于中文，可以探索将汉字部首、笔画等特征融入分词决策；或者采用“双流”分词，一种针对语义单元（词），一种针对语法单元（字），在模型内部进行融合。
- 词汇表动态扩展能力：让模型本身具备在推理时学习和吸收新词汇的能力，而不是依赖外部模块。这类似于让模型拥有一个“短期记忆”或“工作词典”，能够根据上下文即时创建和使用新的词汇单元。
- 基于语义而非统计的分词：最终极的方向，或许是让模型完全摆脱对表面形式（字符串）的依赖，直接学习到更深层的语义单元。但这依赖于我们对语言和认知本质的更深刻理解。
回到我们本地部署LLM的实践场景。在当前阶段，实现一个类似FragMend的词汇扩展与碎片修补模块，是性价比极高的投入。它不需要你动辄花费数万美金去重新训练模型，却能显著提升模型在处理中文等非拉丁语系任务时的表现。你可以从构建一个领域词典开始，逐步加入统计方法和轻量级模型，持续迭代。这个过程本身，也能让你更深入地理解你所使用的LLM的内部工作机制。
在我自己的项目中，为中文知识问答系统引入一个简易的FragMend层后，在涉及专业术语的问答准确率上提升了约15%。最关键的是，它减少了那些让用户感到困惑和不可信的“胡言乱语”式输出，极大地提升了产品的可用性和专业感。这个小小的“修补匠”，在通往更通用、更公平的多语言大模型的路上，扮演了一个不可或缺的角色。