1. 模型为什么会在承载方式这种词上翻车1.1 一个让我盯了很久的bad case早前我在调一个客服工单分类任务六分类订单修改、物流查询、发票问题、退换货、支付失败、账户安全。模型用预训练做微调整体准确率看着还行但只要把错误样本捞出来问题就藏不住了。有一条工单是这么写的用户要求把订单的承载方式从快递改成门店自提发票抬头需要改成子单位名称。人工标注是订单修改。模型却给成了退换货。问题出在哪承载方式这个词在候选类别里根本没出现模型在预训练的时候也大概率没见过它没法把承载方式和订单怎么送达建立起关联。子单位名称更麻烦这通常是发票字段里的业务概念通用文本里出现频率极低。模型不是笨它是真的不知道这些词在你们业务里是什么意思。这种bad case不是调一个阈值、换一个分类器就能解决的。因为模型缺的不是拟合能力而是业务背景知识。我当时的第一反应是上更大的预训练模型但仔细一想更大的模型参数里也不会有你们部门的黑话手册。真正缺的那部分信息放在模型外部——业务文档、字段说明、客服FAQ、历史工单——也就是外部知识库里。1.2 预训练模型的知识边界和外部知识库的定位预训练模型本质上是从海量文本里学统计关联。它知道快递和配送经常一起出现知道发票和抬头关系紧密但它不知道你们系统里承载方式对应的值域是快递、门店自提、上门配送。这种知识属于特定业务体系预训练语料覆盖不到或者覆盖得非常稀疏。外部知识库的作用不是替代模型而是给模型递一张小抄。它把概念定义、别名、属性、适用场景这些额外信息显式写出来让模型在做预测时能参考。打个比方一个记忆力很好的实习生刚入职你问他对业务术语有什么理解他说不出所以然但你把部门术语手册放在他手边他看一眼就能干活。外部知识库就是那本术语手册。明白了这一点后面的问题就变成了怎么把知识库里的信息用模型能理解的方式送进去。这比想象中复杂因为直接塞一段文字进去往往无效甚至有害。接下来我会拆三种主流路线并给出我实际落地的选择逻辑。2. 三种知识注入路线的取舍拼接、检索优先还是图谱对齐2.1 Prompt拼接轻量方案但别贪多最直觉的做法是把知识库里的相关条目和原始文本拼到一起再交给模型。比如人工构造一条提示承载方式表示订单的履约方式值包括快递、门店自提……然后接上工单文本让模型判断类别。优点很明显实现简单、可控性强知识写错了一眼就能看到。缺点是上下文空间有限一个小型知识库也许塞得下但知识条目稍微多一点就会挤占真正的任务输入。更关键的是无差别地把所有知识都塞进去模型会分不清哪些信息对当前样本真正有用噪声一大反而会把原来能判对的样本带偏。所以我通常只在知识量很小、最多几十条时会考虑纯拼接。一旦知识点超过这个量级就必须走检索。2.2 检索增强按需捞知识落地性价比最高所谓检索增强是让系统先根据当前输入文本从知识库里召回一小部分相关条目再拼接进提示文本。拆开看是四个动作把知识条目做成可检索的片段对当前输入做召回对命中的知识排序并截断把最终结果结构化拼进提示。它的优势在于按需取用。一百条知识不用全上每次顶多取三五条上下文压力小知识命中率也更容易控制。而且可解释性强模型预测错了我们能直接看到是哪些知识条目把模型带偏了方便回溯修库。缺点是整套效果的上限取决于召回质量该召回的没召回后面所有环节都白搭召回了无关内容又会引入噪声。这两年在做知识增强方向的项目我最常用的是这类路线。原因很简单它对知识库本身的格式要求不高能从几十条小知识库起步做起来见效快后续再逐步加语义检索。2.3 知识图谱注入关系密集型任务再上第三种路线是知识图谱注入。它和检索增强最大的不同在于不只是把知识文本拼进输入而是先做实体链接把文本里的实体对齐到知识图谱节点上再用图结构中的邻居、属性、关联关系去增强模型的表示。典型使用场景是命名实体识别、关系抽取这种对实体边界和关系敏感的任务。比如要识别工单里的承载方式发票抬头到底是什么类型的业务实体知识图谱中用边连接起来的关系比一段自然语言描述更精确。但这套方案工程开销大需要有人维护图谱 schema、做实体对齐、训练图编码模块。如果只是做文本分类投入产出比通常不高。我的建议是没有现成的领域知识图谱就先别碰已经有了可用的图谱再重点考虑它。路线典型做法适用场景上下文开销工程成本可控性Prompt拼接所有条目拼进提示知识量小、任务简单高低高检索增强召回TopN再拼接知识量大、长尾场景低中中高知识图谱注入实体对齐图表示增强实体/关系类任务低高中综合来看文本分类、问答、摘要这类入口任务从检索增强起步通常是最稳妥的。接下来我详细拆一下从原始知识库到模型输入中间要过的四道工序这也是最容易踩坑的一段。3. 从原始资料到模型输入四道加工工序3.1 知识采集与清洗先解决脏数据进脏数据出外部知识库这个名字听起来很高级但落到实际前期拿到的往往是客服话术、产品文档、FAQ、数据库字段说明形态非常乱。如果直接把这种原始文本拼进模型提示模型很难判断哪些是事实、哪些是口语铺垫。我在一开始就吃过这个亏。从客服聊天记录里捞了一段用户说的配送方式就是咋给他送货快递啊自提啊上门啊都算原样拼上去模型输出反而更飘。原因很直接这段描述里有大量冗余词而且快递、自提、上门这些值没有和业务概念显式绑定。清洗的目标是把每条知识整理成统一结构我习惯用类似这样的格式{ concept: 承载方式, aliases: [配送方式, 收货方式], attrs: { 定义: 订单履约方式表示商品如何送达用户, 值域: 快递、门店自提、上门配送 }, scenario: 订单修改 }每条知识必须回答三个问题这个概念是什么、它有哪些别名、在什么业务场景下会被用到。前两个问题解决模型不识字的问题第三个问题解决模型不知道该往哪个类别上靠的问题。3.2 实体对齐与候选召回先让知识能关联上文本知识清洗完后下一个问题是怎么知道一条工单文本和哪些知识条目相关。最简单也最可靠的做法是别名匹配。把知识库里所有别名放进一个词典扫一遍输入文本命中了就作为候选条目。比如工单里有配送方式知识库里承载方式的别名包含它就可以把这组概念捞出来。但纯别名匹配会遇到几个麻烦。一是别名覆盖不全比如工单写自提知识库里只有门店自提就命不中。二是有歧义抬头在发票语境和普通语境里含义不同。我的处理方式是先做一层轻量归一把常见简写补进别名表再给重要概念设置匹配权重。如果知识库规模很大词法匹配漏召不可避免我还是会建议加一层向量召回。把知识条目做语义向量化把输入文本也做语义向量化用相似度捞回一批词法上不匹配但语义上相关的条目再做融合排序。不过这一步不要一开始就上先用词法匹配跑通流程看漏召回比例再说。3.3 知识块排序与截断宁要三条完整的不要十条截断的匹配完成后一个输入可能命中十几条知识。全塞进去肯定不行必须做排序和截断。排序的规则不复杂我会分三个信号别名命中数量越多越靠前业务场景和任务类型匹配的越靠前长尾概念优先级高于常见概念。实际用下来别名命中数和场景匹配的权重最大。截断要特别小心。很多人直接把所有知识拼起来再按字符数硬切结果一条知识被切到一半后面的关键属性丢了。我建议先限定每条知识的最大长度再限定返回条数最后限制总长度。宁可只给三条结构完整的知识也不要给十条被切得七零八落的残句。在我的工单场景里通常取前5条每条不超过80个字符总长度控制在150字以内。这个量足够模型理解业务背景又不至于喧宾夺主。3.4 注入模板设计让模型分得清资料和任务知识选好了怎么拼接进提示也有讲究。一个清晰的提示结构能让模型更快识别哪些是参考材料哪些是需要处理的内容。我用的模板大致长这样【任务】判断工单所属类别候选类别订单修改、物流查询、发票问题、退换货、支付失败、账户安全。 【参考资料】 - 承载方式订单履约方式包含快递、门店自提等别名配送方式、收货方式。 - 子单位名称发票开票主体通常指申请开票的公司分部。 【待处理文本】 用户要求把订单的承载方式从快递改成门店自提发票抬头需要改成子单位名称。 【输出】【参考资料】和【待处理文本】之间的分隔一定要显眼这样模型能明确感知到两者身份不同。我还习惯在参考资料里显式写如果参考资料和文本无关请忽略参考资料这能减少模型强行套知识的倾向。到了这一步从知识库到模型输入的加工链路就通了。下面看一个完整实验包括数据、知识库、检索逻辑和最终效果。4. 一次完整的工单分类增强实验4.1 任务设置与基线这个实验我用的是模拟工单数据共300条六个类别分布不均订单修改和退换货偏多支付失败和账户安全偏少。为了不涉及真实业务所有工单文本都是脱敏重写过的但保留了典型的业务黑话。基线做法很常规把工单文本输入一个预训练分类模型做微调评估方式按类别加权算准确率最终结果是78.3%。这个基线有几个典型错误模式凡是出现承载方式子单位名称开票主体这类词模型基本靠猜文本越长越容易偏类别边界模糊的样本比如改了收货方式还要换发票抬头模型只会挑一个高频类别输出。这些都指向同一个根因缺少业务概念映射。4.2 模拟知识库的构建针对基线错误我整理了一个很小的知识库先不管全量覆盖只把高频黑话收录进去。结构就按前面说的统一schema一共30条。挑几条代表性的给你看概念别名关键属性适用场景承载方式配送方式、收货方式订单履约方式值包含快递、门店自提订单修改开票主体发票抬头、单位名称发票上显示的公司名称发票问题子单位名称子公司名称、开票主体单位发票抬头的一种需要申请方指定发票问题门店自提自提、上门自提无需快递配送用户自行到店取货订单修改售后单退货单、退款单发起退换货流程的凭证退换货注意这里有一条一开始就埋了坑的子单位名称标成了发票问题。事实上如果一个工单只说发票抬头改成子单位名称归到发票问题没问题但如果同时改承载方式整体业务动作其实是订单修改。这种知识条目里的场景字段会直接影响模型判断后面在bad case复盘里我会再说。4.3 检索注入的落地过程检索逻辑不复杂我用的是一个纯词法版本。代码大概长这样def load_kb(): return [ {concept: 承载方式, aliases: [配送方式, 收货方式], attrs: 订单履约方式包含快递、门店自提等, scenario: 订单修改}, # 其余条目略 ] def match_entries(text, kb, top_k5): scored [] for entry in kb: hit_aliases [alias for alias in entry[aliases] if alias in text] if not hit_aliases: continue score len(hit_aliases) * 1.0 scored.append((score, entry)) scored.sort(keylambda x: x[0], reverseTrue) return scored[:top_k] def build_prompt(text, kb_entries): reference \n.join( f- {e[concept]}{e[attrs]} for e in kb_entries ) prompt ( 【任务】判断工单所属类别候选类别订单修改、物流查询、发票问题、退换货、支付失败、账户安全。\n f【参考资料】\n{reference}\n f【待处理文本】\n{text}\n 【输出】 ) return prompt实际实验里我做了三组对比。第一组是仅做推理时注入微调模型结构不动但输入加上了检索到的知识块第二组是在推理注入的基础上用少量带知识块的样本继续微调让模型真正学会读参考资料第三组是我在后面修正知识库之后重跑的版本。这里要说明一下第一组提升有限。模型在没见过参考资料这种输入格式时并不一定懂得利用它。真正拉开差距的是第二组让模型在训练阶段就见过知识文本的拼接模式它才会把参考资料当成可利用的信号。4.4 效果对比和经验总结实验结果如下方案准确率说明基线普通微调分类器78.3%业务黑话大量误判推理时检索注入不继续微调82.4%有提升但模型不太会用资料注入后继续微调少量步数86.7%模型学会依赖参考资料修正知识库后再跑88.5%减少错误知识条目的干扰两个提升的关键点一是从基线到检索注入提升的样本多数集中在工单里出现明确业务黑话的场景二是从推理注到继续微调提升来自模型学会了把参考资料的场景字段和候选类别对齐。bad case方面我复盘了两个典型。第一个是门店自提在工单里被简写成自提知识库别名没覆盖导致该召回的知识没召回模型退回到基线水平。修法是给所有概念补一轮简写别名。第二个是前面说的子单位名称场景字段错误模型本来判断为订单修改却被错误的场景映射拽到发票问题。修法是把该条目的scenario改成订单修改并在模板里加了一句当参考资料内多个场景冲突时以承载方式变更作为主流程判断依据。这一步做完我对知识增强这件事的看法有了变化知识库不是一次性建完就完事的它和模型一样需要持续迭代而且很多问题不是模型造成的是知识本身写错了。5. 决定知识增强上限的三个调优细节5.1 知识条目要有一致的结构化schema最开始我把知识写成一段段自然语言比如子单位名称这东西是发票抬头的一种一般用户要求改的时候……模型并不是完全不会用但效果很不稳定。后来统一改成概念、别名、属性、适用场景的结构后准确率又上了一个台阶。原因也好理解结构化文本里的键值对比如值域快递、门店自提比有快递啊自提啊这些更容易让模型识别为事实陈述。属性名本身也在帮模型理解语义比如适用场景订单修改几乎等于直接告诉模型该往哪个类别靠。这里有个小技巧属性名不要用数据库字段名要用业务人员嘴上会说的词。框架叫delivery_type业务叫承载方式模型能理解的肯定是后者。5.2 检索结果宁缺毋滥控制知识噪声我做过一组对比TopK从3调到5再调到8。TopK3和TopK5差距不大TopK8准确率明显下降。原因是多出来的条目里有一部分和当前工单弱相关模型会把弱相关条目当成强证据用。所以检索阈值比数量更重要。命中分数低于某个值的条目宁可不注入。一个很直观的原则是如果一段参考知识让模型对当前样本的判断变犹豫了那不如不提供。模型的注意力资源有限给太多参考物反而会分散它的判断焦点。5.3 建一个知识依赖诊断集别只看总准确率如果你只盯整体准确率很难定位问题在模型还是知识库。我的做法是从训练集里挑出25条必须依赖知识库才能判对的样本单独组成一个诊断集。每一句我都预先标好需要哪条知识。每次改知识库后先跑这个诊断集统计正确命中知识条目的比例和最终预测正确的比例。第一步能定位检索和知识库的问题第二步能定位模型利用知识的能力。有一次诊断集准确率下降了但总分却突然上升一查是模型学会了在知识缺失时猜高频类别这其实说明知识注入的边际收益在减少得回去补知识覆盖。做完这些调优后我现在做新的NLP任务会先问一句这个领域里有多少模型没见过的黑话如果有先把它们整理成一张可检索、可追溯的知识表再考虑要不要换更大的模型。最后再说一个很小的技巧知识库里每个条目都带上来源编号比如[N1][N2]模型输出时如果能把引用的知识号带出来排错会轻松很多哪怕现在只是做分类任务这个习惯也值得提前养成。