客服机器人的说明书，为什么会越改越差？

你有没有遇到过这种情况：客服机器人第一次回答你的问题时，答得挺像那么回事，可你追问一句，它立刻露馅了。

更麻烦的是,如果这个机器人的"知识库"是靠AI自己不断修改升级的,你可能会发现一个诡异的现象：改了几轮之后,它反而比最开始更笨了。

这不是危言耸听。腾讯云的一个技术团队在给云服务客服系统做智能升级时,就撞上了这堵墙。他们给客服机器人配备的知识手册,业内管这个叫"Skill"

**Skill**：可以理解成是一份浓缩了某个领域全部专业知识和处理流程的说明书,机器人接到问题后先翻这本手册,再决定怎么回答用户

一开始靠人工写,后来想用AI自动优化,结果发现,AI改着改着,手册反而变得又臃肿又不准确。这篇论文要讲的,就是他们怎么把这件事修好的。

问题出在哪：第一轮之后,机器人就不进步了

先说一个反直觉的事实。

你可能以为,只要给AI一套"出题—打分—改进"的机制,它就能像学生刷题一样越改越好。但腾讯团队发现的现实是:目前业内主流的做法,恰恰在第二轮以后就卡住了,分数曲线像撞到了天花板一样,死活上不去。

问题的根源在于"出题"的方式。

之前的做法大多是单轮问答式评测:给机器人扔一个完整的问题,机器人答一次,系统判断对错,然后照着错误的地方去修手册。这套方法在论文里被称为"single-turn QA"

**single-turn QA**：单轮问答评测,就是提一个完整问题,机器人回答一次,评测就此结束,不再追问

单轮问答有个天生的毛病。一个用户在向客服提问时,通常不会把所有诉求一次性说完。真实场景里,用户往往是先问一个开头,得到回应后再往下追问,甚至会因为不满意而反复确认、抱怨、绕回原来的问题。这些追问里藏着的坑,单轮问答根本挖不出来。

论文里做了个实验对比,结果相当扎心。用单轮问答驱动改进的方法,机器人的任务解决率(论文叫TSR)

**TSR**：任务解决率,英文Task Success Rate的缩写,衡量机器人有多大比例真正解决了用户问题

从58.9一路爬到66.4就再也上不去了,四轮迭代下来只涨了7.5个百分点。而这篇论文提出的方法,同样从59.4起步,四轮之后冲到了81.8,涨了22.4个百分点。差距一目了然。

这就好比你请了一个家教帮你补习,家教只按照你在考试第一题上暴露的问题去讲课,讲完你确实会做第一题了,但试卷后面还有八道题目,那些题目里的知识漏洞,家教压根没看见过,自然也没法帮你补。而如果这个家教能跟着你一起做完整张卷子,做错一题就追问你"为什么这么想",那么每往后推进一步,他就能看见更深一层的知识盲区。如果家教只看第一题,你的成绩必然卡在某个分数线附近不再提高,这不是家教不够用心,而是他看到的信息本来就不够。

这篇论文的核心判断是:决定AI知识库能不能持续进化的,不是编辑能力强不强,也不是改了多少轮,而是反馈信号本身够不够"新鲜"、够不够可信。

围绕这个判断,团队搭了一套叫SkillEvo的系统。

**SkillEvo**：论文提出的技能自我进化框架,靠两根支柱撑起来,一是让反馈信号持续更新的多轮交互机制,二是主动修复知识库结构性问题的治理层

第一根支柱:让追问自己"生长"出新的反馈

SkillEvo做的第一件事,是把"多轮对话模拟"从一个单纯的考试环节,改造成一台能持续产出反馈的发动机。

具体怎么做?团队设计了一个受约束的虚拟用户,这个虚拟用户不是随便瞎聊,而是严格按照一套状态机来推进对话。

**意图状态机**：一种追踪机制,记录用户每个关键诉求有没有被提出来、有没有被真正解决,只有全部满足才允许对话正常结束

这套状态机的作用,是防止虚拟用户"偷懒"。如果虚拟用户提前结束对话,或者绕开了某个关键问题,系统会强制它继续追问,直到把用户真正关心的所有点都摸清楚。

这里有个很关键的设计,叫"双侧正交评估"。

**双侧正交评估**：把评测拆成两条互不干扰的线,一条评价虚拟用户有没有把该问的都问到,另一条评价机器人对已经被问到的问题回答得准不准

为什么要拆开评估?因为一次对话失败,原因可能出在两个地方:要么是虚拟用户根本没把用户的真实诉求问出来,是模拟本身出了偏差;要么是虚拟用户问对了,但机器人答错了,是知识库本身有缺口。如果混在一起打一个总分,你永远搞不清楚该修的是模拟脚本还是知识手册。

论文里给出了具体数字。团队让虚拟用户在98个知识文件覆盖的场景里跑,结果关键意图的覆盖率达到98.9%,也就是说几乎把用户该问的都问全了。为了验证这个数字不是自吹自擂,团队还找了两位业务专家,盲测200段模拟对话,对照真实工单打分,吻合度达到95.3%。这说明虚拟用户模拟出来的对话,和真人提问的方式相当接近,不是机械地照着清单念题。

在这个前提下,机器人对已经暴露出来的意图的回答准确率是71.1%。这个数字才是真正驱动后续修改的信号来源。

这里还有个环节容易被忽略,叫"归因"。

**归因**：判断一次失败到底是不是知识库能修好的问题,论文里分成三类,知识缺口、能力局限、评估噪声

不是所有失败都值得拿去改手册。有的失败是因为机器人压根没有权限查某些后台数据,这种叫"能力局限",改手册没用;有的失败是评测本身出了偏差,比如虚拟用户没把话说清楚,这叫"评估噪声",也不该算进去。只有真正因为知识手册里缺了某条规则、某个链接、某个操作路径而导致的失败,才算"知识缺口",才会被送去修改。

这个归因机制像什么呢?像医院里的分诊台。病人来了不能一股脑全推进手术室,得先分清楚是感冒还是骨折还是纯粹挂错科室。如果不分诊,直接把所有病人都往一个方向治,轻则浪费资源,重则真正需要开刀的病人被耽误。SkillEvo的归因就是这个分诊台,把不该治的病例挡在门外,让手术刀真正落在能治好的伤口上。

数据也验证了这套机制的价值。同一轮里如果出现多个指向同一个知识缺口的失败案例,系统会把它们合并成一条反馈信号,而不是逐条修改造成冗余。

第二根支柱:光会改还不够,还得防止改坏

反馈信号解决了"往哪改"的问题,但另一个更隐蔽的麻烦冒出来了:改着改着,手册本身会"病变"。

论文里总结了三种典型病变。

第一种叫知识膨胀,手册里的内容越堆越多,冗余信息稀释了关键路由的精准度。第二种叫引用断裂,文件之间原本互相指向的链接失效了,变成孤立的"死档案"。第三种最隐蔽,叫事实过度泛化,原本写得清清楚楚的具体数值、版本号、规则,被改成了含糊其辞的"请参考官方文档"这种空话。

这三种病变有个共同的特点:传统的打分机制根本看不出来。

之前很多同类工作的做法是,给修改后的手册打一个总分,分数低了就打回重做。可这就像给一个病人量体温,体温正常不代表内脏没出问题。一份手册整体读起来还算通顺,分数也不低,但里面可能悄悄丢了三个关键数字,埋了两个死链接。总分这种"标量门"能拒绝一份差的答卷,却指不出问题具体在哪一页、哪一行。

所以SkillEvo专门配了一个独立的治理层,把"事实一致性"当成硬约束,把"结构一致性"当成软约束来分别处理。

**事实一致性**：要求修改后的手册至少保留生产版本里已经验证过的稳定事实,不能丢

这里有个巧妙的设计,叫"双锚点"。

**双锚点**：治理层同时对照两个参照物来检查修改,一个是最初的生产基线版本,专门抓丢失了哪些老知识;另一个是上一轮修改结果,专门抓这一轮新引入了什么错误

为什么非要两个锚点?如果只对照最初版本,你能发现"丢了什么",但没法判断这个丢失是这一轮造成的还是很多轮前就丢的,修复方向就模糊了。双锚点相当于同时保留了"案发现场"和"最近一次变动记录",破案的时候才知道该往哪个方向查。

这就好比一栋老房子请装修队一轮一轮翻新。如果装修队只看最初的图纸,他知道墙被拆了,但不知道是这次拆的还是上次拆的,修复起来就会瞻前顾后。而如果同时留着最初图纸和上一次装修完的照片,一对比就能精确定位,这堵墙是这一次施工时被误拆的,那就该恢复;那面墙是三次前就没了,而且已经用别的方式补上了,那就不用管。

结构一致性则是软约束,不会直接判定修改失败,而是生成一份治理建议,合并进下一轮的修改任务里,让结构问题一轮一轮被消化掉,而不是一次性推倒重来。

数据上看,这套治理机制的效果相当直观。有治理层保驾护航的情况下,知识库累计膨胀率只有2.8%,而且增长主要集中在第一轮补充知识的时候,之后就趋于平稳;没有治理层的情况下,膨胀率高达16.2%,是前者的将近六倍。任务解决率提升了51.8个百分点,而文档体积几乎没怎么变,这说明能力提升靠的是把已有知识改对,而不是靠往里塞更多字。

论文里还有一个指标叫"跨轮回归率"。

**跨轮回归率(RegR)**：衡量上一轮本来答对了、这一轮反而答错的比例,数值越低说明修改越稳定

这个指标从第一轮到第二轮的28.2%,一路降到第三轮到第四轮的21.1%,首尾相差7.1个百分点,说明治理层确实在压制"改了新的、丢了旧的"这种拆东墙补西墙的现象。

三种方法摆在一起,差距是怎么拉开的

论文把三种方案放在同一个跑道上比赛:完全没有评测反馈、只靠模型自我反思瞎改的方法(Self-Reflection);单轮问答驱动的方法;还有SkillEvo这种多轮交互驱动的方法。四轮迭代,结果如下。

| 方法 | 初始值 | 第1轮 | 第2轮 | 第3轮 | 第4轮 |

| 原始手册 | 30.0 | — | — | — | — |

| 自我反思 | 30.0 | 59.2 | 58.7 | 57.4 | 58.8 |

| 单轮问答驱动 | 30.0 | 58.9 | 64.5 | 65.7 | 66.4 |

| SkillEvo | 30.0 | 59.4 | 71.3 | 77.9 | **81.8** |

自我反思这条线的表现最能说明问题。没有任何外部评测介入,模型自己反思自己修改,四轮下来分数在58分附近来回晃悠,几乎没有实质性进步。这说明单纯依赖模型自我判断是靠不住的,它分不清哪些是真正的知识漏洞,哪些只是自己臆想出来的问题。

单轮问答驱动的曲线呈现出典型的"前快后慢",第一轮涨得挺猛,从30到58.9,但后面三轮加起来只涨了7.5个百分点,边际收益急剧递减。

SkillEvo的曲线则是稳步攀升,每一轮涨幅都不小,四轮下来涨了51.8个百分点。

论文还专门做了消融实验,把多轮交互换成单轮问答,其他环节(归因、修改、治理)全都不动,结果分数直接掉回66.4,和单轮问答基准完全一致。这证明SkillEvo领先的15.4个百分点,确实是多轮交互反馈这一个改动带来的,不是别的环节顺带产生的效果。

再把治理层单独拿掉,分数从81.8掉到78.6,只降了3.2分,比拿掉多轮交互的降幅小得多。这也印证了一件事:治理层的价值不在于让分数冲得更高,而在于防止分数在冲高的过程中因为副作用被拖累回去。

一个真实案例:错误的知识比没有知识更危险

论文里举了一个具体的工单案例,读起来挺有意思。

用户问的是云存储流量包续费的问题:续费之后是马上生效,还是要等原来的套餐用完才生效。

机器人第一轮回答是:续费立刻生效,流量马上叠加到当前套餐里,不用等原套餐到期。

这个回答听起来相当自信,而且逻辑自洽。但真实的规则恰恰相反:续费只是延长有效期,新一轮的流量额度要等到重置日那天才会生效,在这之前用完的部分要按量计费,而不是立刻叠加。

评测系统给这次回答打了10分(满分100),判定为严重错误。归因结果显示这是一个典型的"知识缺口":手册里根本没有写清楚续费的生效规则。

这个案例特别值得说道的地方在于,虚拟用户没有在第一轮就放弃对话。因为机器人给出的答案听起来挺像那么回事,虚拟用户信以为真,顺着这个错误的前提继续往下问:"如果套餐用完了会不会被停服"。这一连串追问,恰恰是单轮问答永远看不到的层次。

这就是论文反复强调的一个道理:错误的知识比缺失的知识更具欺骗性。一个"不知道"的机器人会诚实地说"我不清楚",用户至少知道该去别处求证;但一个自信地给出错误答案的机器人,会把用户带偏,而且这种偏差往往要靠后续的多轮追问才能暴露出来。

针对这个问题,团队只往手册对应章节加了几行文字,补充续费延长有效期而非叠加额度的规则,以及原套餐用完后按量计费不停服的说明,其余十三个段落原封不动。修改之后再跑同一个场景,机器人第一句话就答对了规则,评分从10分直接跳到92分。

这个案例也侧面印证了"有界编辑"

**有界编辑**：修改知识库时只针对已验证的具体缺口打补丁,不引入没有证据支撑的内容,同时锚定生产基线版本,防止新知识覆盖掉已经验证过的老知识

的意义。团队没有让AI"顺便"把整个续费章节重写一遍,而是精确定位到缺失的三条规则,做最小化的补充。这种克制,恰恰是防止知识膨胀的关键一环。

这套系统真的在跑,而不只是纸上谈兵

这套框架不是停留在实验室里的构想,而是部署在腾讯云的实际生产环境里,覆盖了六大类云服务、9个正在使用的客服知识库,一共98份参考文件。

数据集本身也很有意思。所有测试用的工单,都是曾经被人工客服接手过的真实案例,大约四成是用户一上来就转人工的,剩下六成是机器人折腾了好几轮没解决、最后才转人工的。也就是说,这些数据本质上就是"现有机器人系统的失败清单",每一条都对应着一个真实用户已经暴露、但当前系统还没能覆盖的知识空白。

为了保证评测结果可信,团队还专门抽样让人工专家复核评测系统的判断,吻合度超过90%。这个数字支撑了后续所有基于自动评测的结论。

论文也没有回避风险。任何自动往生产环境写知识的系统,都有一个隐患:一次错误的修改一旦合并进去,就会直接影响真实用户。团队的应对方式是,治理层把事实一致性当作硬性门槛,拒绝任何删除稳定事实的修改候选;同时任何版本上线前都必须经过人工确认,这个环节不是可选项,而是被明确写进流程里的必要一环。

写在后面

读这篇论文的时候,我一直在想一个问题:为什么"越改越差"这件事,在很多AI自我进化系统里都会反复出现,却很少有人认真去拆解它的根源。

大部分团队遇到类似问题,第一反应往往是加强编辑模型的能力,或者多跑几轮迭代。但这篇论文的判断反过来:如果反馈信号本身是失真或者枯竭的,再强的编辑能力也只是在原地打转。这个思路挺值得记住,遇到一个系统"改不动"了,先别急着换更强的模型,先问问反馈信号是不是提前枯竭了。

另一个让我印象深刻的细节,是那个续费规则的案例。机器人说错话的自信程度和它说对话时几乎没有区别,这种"自信的错误"在很多场景里都比"诚实的沉默"更危险,只是很少有评测体系能把这种危险量化出来。

多轮追问能揪出这种深层错误,而单轮问答几乎注定看不见它。这是不是意味着,所有依赖"一次性打分"来评估AI系统的场景,都可能藏着类似的盲区?这个问题留给你自己想。

Q&A

Q1：SkillEvo是什么？

A：SkillEvo是腾讯云团队提出的一套让客服知识库自动持续改进的框架,核心是通过模拟多轮用户对话不断生成新的反馈信号,再配合一个专门的治理层修复知识库结构性问题,避免改动过程中知识越改越乱。

Q2：为什么单轮问答驱动的改进方法会失效？

A：因为真实用户提问往往是分层次逐步暴露诉求的,单轮问答只能看到用户开场白里的问题,第一轮改进之后能看到的漏洞就修完了,后续没有新的反馈来源,分数曲线很快就会停滞,论文实验里四轮迭代只涨了7.5个百分点。

Q3：SkillEvo怎么防止知识库越改越臃肿？

A：SkillEvo设置了独立的治理层,用双锚点方式对照生产基线和上一轮版本检测知识丢失和结构问题,把事实一致性当作硬约束直接拒绝违规修改,把结构问题作为建议合并进下一轮修改,实验显示有治理层时知识膨胀率只有2.8%,没有治理层则高达16.2%。