生成式AI在客服场景的系统化实践 03 ｜ 从规则到生成式（三）： 通过知识工程构建可持续的能力底座

全文共 5367 字，预计阅读时间 15 分钟

前言

在前两篇里，我更多讨论的是如何做设计分层、如何评测、如何构建上线指标和目标。

但实际上对于客服产品而言，有一个问题更值得被解答：模型回答的内容，究竟依赖什么？

在客服升级项目当中，我们很快意识到，大模型客服的上限，往往不取决于模型版本，而取决于知识工程的质量。很多关于知识治理的判断，来自团队负责人的复盘与讨论。在这一篇，我会把这些经验一点点串联起来，去理解它们背后的逻辑。

------

一些关于知识工程的认知变化

我想大多数人对企业知识的理解是直觉式的：资料越全越好，文档越多越保险。

但实践很快会给出反例。

大量给人阅读的文档、音视频材料、表格数据等，如果不经过筛选和结构化处理，直接喂给模型，效果往往适得其反。模型并不会自动区分“核心规则”和“历史讨论”，也不会天然理解哪一条信息在当前具有有效性。在没有治理意识的情况下，知识越多，噪声越多。

这种现象在客服场景尤其明显。规则版本更新频繁，历史补充说明不断叠加，FAQ 长期累积但未清理。模型在检索阶段如果命中多个相似条款，很容易生成模糊或冲突的回答。

基于先前做规则客服的经验，团队负责人很快就提出了一个重要认知：知识工程的第一步不是“补充知识”，而是“整理知识”。

这件事和做 FAQ 的直觉其实很像。客服场景高度符合二八定律。真正带来大部分咨询量的，往往是那 20% 的高频问题。维护好这部分核心知识，比先追求大而全的知识库更有价值。

与其追求覆盖所有边缘场景，不如先保证高频场景表达清晰、规则一致、结构稳定。知识的质量远比数量重要。

但知识工程本身，同样存在长尾。

某种意义上，知识工程本身也遵循二八定律。这代表前期整理 20% 的核心知识，收益最明显；后期进入长尾治理阶段，收益节奏会放缓；这些问题单次频率不高，却可能带来投诉或风险。知识治理逐渐进入一个长期过程——线上反馈、业务收集、抽象。从团队的长期规划来看，知识工程更像一项长期基础建设，而不是阶段性优化任务。

某种程度上，我越来越倾向于认为，知识工程会成为未来智能客服系统的重要护城河。模型能力可以替换，接口可以迁移，但经过长期整理与抽象的知识结构，很难被复制。

当然，这项工作并不光鲜。梳理数据、清洗旧规则、对齐历史口径，这些往往都是脏活累活，却是我们不得不跳过的一项重要工作。

着手构建高质量知识工程的四条经验

经验一：做好模块化

在真正参与知识整理之后，我开始意识到，有些经验其实是从规则客服阶段直接延续下来的。

其中最重要的一点是模块化。

规则时代，我们就已经习惯将知识按意图、场景或业务线拆分。目的很简单——缩小匹配范围，减少歧义。到了大模型阶段，这种思路反而更加重要。虽然模型具备更强的理解能力，但在高并发客服场景下，我们依然希望它在尽可能小的知识范围内做判断。

划分的方式可以很多样。可以按意图拆分，也可以按任务类型、业务线甚至场景节点拆分。关键不是“怎么分”，而是避免一个知识块同时承载过多无关信息。模块越清晰，召回范围越小，生成的稳定性就越高。

经验二：关注主题而非问题

但也有一个明显的变化，是规则时代的经验不再完全适用。

在规则客服阶段，我们维护了大量“问题”和“相似问”。产品和运营会反复揣摩用户可能的表达方式，尽量把问题变体都覆盖进去。这种做法在关键词匹配逻辑下非常必要。

例如在 O2O 货运场景中，常见的问题可能包括：

为了覆盖表达差异，产品和运营会不断补充相似问：

在规则时代，这是必须的。系统依赖关键词匹配和相似句判断，如果没有穷举问题表达，命中率就会下降。但到了 LLM 阶段，这种思路开始显得成本过高。

问题是用户的表达形式，而主题才是业务的真实结构。

在做业务梳理的时候，上述的问题可以归纳成以下的主题：

当我们仍然以“问题”为知识单元时，每增加一个相似问，就意味着一条新的知识记录。时间一长，知识库会变成大量高度重复的条目，逻辑高度冗余。

而当我们改为以“主题”为单元时，结构会完全不同。

例如，“订单履约异常”作为一个主题，可以结构化为：

<主题 名称="订单履约异常">

  <定义>
    <!-- 说明什么属于“履约异常”，本主题的覆盖范围 -->
  </定义>

  <适用范围>
    <场景>司机迟到</场景>
    <场景>司机爽约/未到场</场景>
    <场景>临时改约</场景>
    <场景>拒单/无法履约</场景>
  </适用范围>

  <判定条件>
    <条件 编号="1">
      <!-- 例如：超过约定时间X分钟仍未开始服务 -->
    </条件>
    <条件 编号="2">
      <!-- 例如：司机主动取消或长时间无响应 -->
    </条件>
  </判定条件>

  <处理流程>
    <步骤 顺序="1">
      <!-- 核实订单信息：订单号、时间、位置、沟通记录 -->
    </步骤>
    <步骤 顺序="2">
      <!-- 校验订单当前状态 -->
    </步骤>
    <步骤 顺序="3">
      <!-- 提供解决方案：改派、取消、补偿申请等 -->
    </步骤>
    <步骤 顺序="4">
      <!-- 是否需要转人工或升级处理 -->
    </步骤>
  </处理流程>

  <用户权益>
    <权益 编号="U1">
      <!-- 满足条件可申请补偿 -->
    </权益>
    <权益 编号="U2">
      <!-- 满足条件可取消订单且免除违约金 -->
    </权益>
  </用户权益>

  <司机责任>
    <责任 编号="D1">
      <!-- 爽约责任认定逻辑 -->
    </责任>
  </司机责任>

  <平台边界>
    <可以做>
      <事项>查询订单状态</事项>
      <事项>发起补偿流程</事项>
    </可以做>
    <不可做>
      <事项>承诺具体赔偿金额</事项>
      <事项>超出规则范围的免单保证</事项>
    </不可做>
  </平台边界>

  <特殊说明>
    <情况>节假日高峰期处理规则</情况>
    <情况>恶劣天气影响履约说明</情况>
  </特殊说明>

  <问题映射>
    <!-- 仅用于召回归类，不作为知识主体 -->
    <示例问题>司机迟到了怎么办？</示例问题>
    <示例问题>司机爽约会赔偿吗？</示例问题>
    <示例问题>超时能不能取消不扣钱？</示例问题>
  </问题映射>

  <元数据>
    <业务线>搬家</业务线>
    <标签>履约</标签>
    <标签>异常</标签>
    <标签>取消</标签>
    <生效时间>2024-01-01</生效时间>
    <版本号>V3.2</版本号>
    <负责人>XXX</负责人>
    <最后更新时间>2024-05-01</最后更新时间>
    <变更记录>
      <!-- 记录规则调整说明 -->
    </变更记录>
  </元数据>

</主题>

我们可以看到在这份结构化的知识点当中，知识不再围绕问题为中心，问题只是作为辅助召回的示例存在；另外一个特点是标签本身自带语义，例如 <处理流程>、<判定条件> ，他们更容易被擅长语义理解的大模型捕捉。

而传统的QA对和相似问知识也并非毫无用武之地，它们则被放在 <问题示例>当中。

做这件事其实并不轻松，事实上；相较于传统的基于规则的智能客服，这种转变带来的最大变化，不在于减少工作量，而在于统一口径。

过去围绕问题组织知识时，不同问法对应的答案可能略有差异，甚至随着版本演进出现历史遗留冲突。而主题化组织会倒逼产研和业务团队先把规则本身梳理清楚，再由模型的语义理解能力去穷举用户表达。

从某种意义上说，大模型把“揣摩用户相似问”的压力，从产品侧转移到了模型能力上。但与此同时，也把“规则结构是否清晰”的压力放大了。指望在大模型时代能够在知识工程这件事上省事的人恐怕要失望了。

此外，我还总结了一些制作结构化知识点的实践经验：

经验三：元数据同样重要

另一个逐渐被重视的点则是元数据。这里所谓的元数据，简单说，就是“关于数据的数据”，它不是规则本身，而是描述规则的信息。如业务线、适用时间范围、同义词、使用到的业务术语和相关的定义口径等。

举个更贴近业务的例子，假设有两份关于“取消订单是否扣费”的说明。一份是去年的版本，一份是最新版本。如果没有明确标注生效时间和版本号，模型在检索阶段可能同时命中两条规则。生成时，它并不知道哪一条是当前有效的，最终给出的回答就可能模糊甚至冲突。

再比方说货运场景中，订单状态的枚举值如果不统一—— 有的文档写“已接单”，有的写“司机接单成功”，有的写“已开始服务”，有的写“运输中”。这些差异在人工阅读时问题不大，但在检索阶段可能会造成召回偏差。

这些问题在规则时代也存在，只是影响范围相对有限。而在大模型场景中，一丝一毫的不规范都会被放大。因为生成式AI本身是基于概率的，它不会主动帮我们消除歧义。如果知识口径不一致，模型只是在这些不一致之间做选择。

这要求团队在做知识整理时，需要在一开始把元数据当作和正文同等重要的一部分来处理。每一条主题知识，不仅要写清楚规则内容，还要写清楚：

这些信息大多数都不会直接展示给用户，但它们决定了模型能否在正确的语境下使用这条知识。

经验四：知识工程本质上也是组织协作能力的考验

把多年积累的传统知识全部重构成结构化格式，本身就是一项大工程。它不是“写几条规则”，而是涉及口径对齐、版本确认、字段统一、业务复盘，往往牵动多个团队。站在产品和项目管理的角度看，如果一开始就试图做大动作去重构并不现实。

因此，团队第一件承认的事情就是：知识工程本身也要分阶段。

在模型刚上线、效果还在验证阶段时，没必要对全部历史知识做一次性重构。更现实的做法，是围绕高频场景优先改造。正如我们前面所说，客服场景天然符合二八定律，20%的核心业务往往覆盖80%的咨询量。先把这部分知识模块化、结构化、补充元数据，确保模型在主干路径上稳定运行，收益远高于分散精力处理长尾。

第二是要允许“新旧并存”的阶段存在。

过渡期不可能立刻把所有知识迁移完成，新进入模型链路的知识，要使用新的结构标准；历史低频知识暂时保留旧格式，通过检索策略做范围控制。这样既不会扰乱业务节奏，也能逐步积累结构化的新资产。

此外，从项目管理角度看，知识重构必须和业务共建，而不是产品单向推进。

企业的知识工程往往涉及历史规则解释权。很多条款之所以“写得乱”，是因为背后有业务演进的痕迹。如果没有业务方参与确认，很容易在重构过程中改错口径。过渡期更需要明确一种协作或者共识机制，例如：为每一种知识主题明确主题负责人，设定统一的结构模板，每一次大型变更要及时做小范围的试点验证，并将评测结果及时反馈给业务方。

还有一个容易被忽视的点，是要给知识工程设定合理目标，而非“做科研式”的彻底改造。所谓合理的目标，一是要符合团队能力，二是要能得到正向的ROI，三是一定要有可量化、可阶段验收的指标。

否则，知识工程一旦变成“无限期优化任务”，团队很容易失去耐心。

在继续往下之前，先做一个小声明：下面的部分更偏工程细节，很多做法也谈不上“最佳实践”。一方面受限于篇幅，没法把每个点展开到实现层；另一方面我并未深度参与技术团队的方案讨论，接触到的更多是团队在过渡期里的一些取舍和尝试，有些结论也还在持续验证中。因此这里更多是把我们踩过的一些坑、以及当时比较有效的处理方式记录下来，仅供参考。

善用章节摘要

在实际检索里，块和块之间的上下文丢失是常见问题，尤其是业务 Wiki 这种“章节式写作”的内容。如果能在每个章节切分时额外补一段“章节摘要”，通常会让召回更稳定——因为摘要天然包含了章节的关键词和核心语义，检索时更容易被命中。

摘要怎么来？一种可行路径是用专门的摘要模型去离线跑一遍，成本可控、效果也更稳定。市面上也有一些对“摘要类模型”做过整理的文章可以快速选型，例如 SiliconFlow 对开源摘要模型做过对比盘点：[https://www.siliconflow.com/articles/en/best-open-source-llms-for-summarization]()

如何初步解决图文混排问题

客服知识库里经常有截图、示意图等；如果这些图片不做处理，检索基本就“看不见”。我们比较务实的一种办法是：用 VLM （视觉语言模型）把图片先转成简短的描述性摘要，作为图片索引写回文档或单独入库。

这样做的好处是立竿见影——至少检索能命中这张图所表达的内容；代价也很明确：多模态理解会带来额外成本，尤其当图片量大、更新频繁时，需要评估 ROI。

图文混排里有一个更特殊的情况是流程图。O2O 业务的服务流程、异常处理流程，往往就是一张图。对模型来说，流程图最怕的不是“看不懂”，而是“无法引用”：它没有清晰的可检索文本结构。我们更倾向于把流程图转成 Mermaid 这类“可读可搜”的文本化表达，让流程成为结构化节点与边的集合。一旦变成代码，既可以渲染成图，也能作为文本参与检索，还方便做版本管理。

Mermaid 的语法和 flowchart 的表达方式官方文档里也比较清晰。实际操作的时候可以使用AI辅助转换：[https://mermaid.ai/open-source/syntax/flowchart.html]()

留心不适合做语义匹配的内容

向量检索擅长找相似，但它天生不擅长“一个字符都不能错”的东西。客服里这种信息很多：产品名、型号、编号、活动 code、某些固定字段名，甚至是业务里约定俗成的缩写。

对于这类问题，我们在知识侧会做一些“显式标记”，比如把关键字段前后加引号、用固定字段名包裹、或统一成可解析的 key-value 形式。它的目的不是让模型更聪明，而是告诉检索系统：这类 token 更像标识符，需要走更强的精确约束（比如关键词检索/过滤），而不是纯相似度匹配。

减少噪声

在客服知识中，合规条款往往存在高度重复和历史叠加问题。重复段落越多，召回噪声越大，模型生成阶段的不确定性也越高。

因此在过渡期，知识治理的重点是要合并重复条款、确认唯一权威版本、删除历史遗留副本。

同时要处理指代问题，例如“该服务”“上述情况”“其责任”等模糊表达。在人工阅读时可以通过上下文理解，但在 chunk 化后，这类指代可能失去指向对象。工程上最简单的解决方案就是将模糊的指代显式展开为具体的指代名词，让每个知识块尽可能具备独立的可理解性。

这里的经验很朴素：减少噪声，比增加知识更能提升稳定性。

明确知识库与 RAG 不擅长的任务

从实践来看，在企业智能客服场景中，有几类任务并不适合交给知识库去处理：

第一类，是跨度很长的总结任务。

比如“总结近三个月平台关于赔付规则的所有调整”，这类问题往往需要跨多个主题、跨多个版本汇总信息。RAG 天生是分块召回，很难保证看到的是完整全局，它更适合回答“某一条规则是什么”这种问题。

第二类，是复杂关系推理。

当用户问的不是某条规则本身，而是要把多个实体串起来推导结果。比如“某个订单在某个时间点是否满足赔付条件”，即使模型具备一定推理能力，在复杂路径推导场景中，也容易出现遗漏或错误关联。

需要说明的是，这类问题并不是完全做不了。有些情况下，通过补充更细的规则和结构化字段，确实可以覆盖一部分推导路径，但这样做的成本也是极高的。

这也是为什么业界会出现 Graph RAG、知识图谱增强检索这类方案。它们的思路大概是：先把“关系”变成可查询的结构，再把查询结果交给模型生成。

但它同时把难点前移到了知识图谱本身。

高质量的实体关系构建成本并不低，尤其在业务快速变化的阶段。自动抽取实体与关系看似省事，实际很容易引入大量噪声：有些关系只是“看起来像”，但并非业务真实约束；有些关键条件在文本里是隐含的，抽取模型反而会忽略掉。所以即便选择 Graph RAG，也必须非常谨慎地做质量治理。

所以在实际应用中，我们需要做一些取舍；好在这类问题往往不属于高频场景。客服业务依然符合二八法则——真正占据大部分咨询量的，还是诸如规则解释、流程说明等可结构化内容。

第三类，是精确计算。

这是团队先前在构想理赔计算器这个需求时候遇到的卡点；理赔金额往往和基础运费、超时比例、封顶规则、优惠抵扣等多种因素相关。如果让模型直接根据规则文本去算金额，稳定性是不可控的。更合理的方式是：模型负责解释“怎么算”，真正的金额由后端公式计算。

千万不要幻想知识库能解决一切问题。正如贯穿本文全篇的“二八定律”，智能客服不必解决所有问题，但要优先保证稳定地解决那 20% 的核心问题。

结语

这一篇更多讨论的是知识工程本身。其中涉及到的——模块化、主题化组织、元数据治理等，这些工作都谈不上“创新”，甚至很多属于重复、琐碎的整理工作，但对于落地到真实业务场景，这些工作又至关重要。

同时，本文也讲了能力边界的问题——哪些问题适合交给智能客服，哪些问题更适合人工链路处理。明确“不做什么”，往往比盲目扩展能力更重要。这和前篇所强调的“让合适的问题流转到合适的处理方式上去”这一观点也是不谋而合的。

如果说前三篇更多围绕客服机器人本身，那么下一篇会把视角再拉高一点。生成式 AI 带来的改变，并不仅仅是 C 端机器人的服务质量更好。还有一些重要重构，发生在内部工具和中后台当中，这些地方不是用户与企业的直接交互触点，但在客服体系降本提效当中发挥着“幕后英雄”的作用。