原文链接：https://mp.weixin.qq.com/s/53KZsrAIGCAdF1_LZ5ORPw

大模型和算力的快速发展，促进了很多行业的变革，即使目前AI仍然处于“自主行动”的初级阶段，即“辅助人”的阶段，其巨大的潜力和演进路径却是相对明确的。

让AI评测AI：构建智能客服的自动化运营Agent体系

一、基于NLP的传统机器人客服

传统机器人的工作重点：

1. 知识库建设： 将常见的客户问题整理成“问题-答案”对；
2. 同义词和规则配置： 为每个问题配置大量可能的关键词和同义句。例如，为“如何退款”配置“想退货”、“钱怎么退”、“不要了”等；
3. 对话流程设计： 设计复杂的、树状的对话流程（SOP、决策树等），例如，“用户选择A -> 跳转到流程A1 -> 询问信息A2...”；
4. 监控与维护： 监控哪些关键词被触发，哪些问题未被识别，然后不断打补丁，添加新规则；

机器人的智能水平上限在设计之初就被规则库的规模锁死了，无法处理规则外的问题。

二、基于RAG的智能客服

：为了提升文档问答的准确率、降低知识的运营成本
RAG从“知识库”中找出最相关的内容，将“检索到的信息”和“用户问题”打包成一个超级提示词，它既有更加准确的知识作为供给，也能经过LLM的润色表达的更加自然。

• 在检索（Retrieval）方面, 引入向量化检索方式

  
  
  ES方式与向量方式.png

• 在增强（Augmentation）方面，将检索到的信息片段和用户问题，精心组装成一个LLM能理解的"提示词"，为生成环节奠定基础

  • 信息组装：在工程侧，将检索环节得到的候选知识分片，按相关性排序，结合历史对话内容拼接成一个完整的"上下文背景信息"
  • 提示词工程，这是"增强"环节的灵魂，通常包含以下部分：
    • 系统角色： 定义LLM的身份。例：“你是一个专业的客服助手，严格根据提供的背景信息回答问题”；
    • 背景信息/指令： 明确告知LLM答案的来源和规则。例：“请严格根据以下用```标记的背景信息来回答最终的问题。如果背景信息中没有答案，请直接说'根据现有信息，我无法回答这个问题'，不要编造信息”；
    • 背景信息内容： 前面提到的上下文；
    • 用户问题： 放入原始的用户问题；
    • 输出格式要求（可选）： 要求LLM以特定格式（如Markdown、带项目符号的列表）输出，或要求其引用来源。

• 在生成（Generation）方面，将组装好的提示词发送给大语言模型。

  • 理解指令： 识别自己的角色和回答规则；
  • 关联信息： 在提供的背景信息中，定位与问题直接相关的部分；
  • 总结和生成： 对找到的信息进行归纳、总结和重新组织，用更自然、流畅的语言表达出来

RAG机器人客服主链路.png

三、基于AI原生的智能客服

AI原生的智能客服主链路.png

链路中使用模型的地方都切换为了LLM。因为基模的强大，我们可以把更多的内容让LLM去推理判断（相比之前，进化很多），比如可以把复杂的业务逻辑，通过自然语言描述成“如果xxx，那么xxx”这种格式，结合上下文信息，让LLM决策该走什么样的逻辑分支，我们把它称之为“智能SOP”。智能SOP（依然存在很大的优化空间）中需要动态调用LLM以外的内容，可以通过Function-Call的方式实现。

对于知识类的问答，RAG仍然必不可少，而且也在不断进化：

RAG进化.png

四、对话效果如何评测

是运营人员通过指定评测集，或者从生产环境抽取服务记录，线下进行人工标注看效果。如果发现问题，需要单独记录，找技术进行定位，是问答链路中哪个环节可能出了问题导致了BadCase，修复方案可能是需要运营介入、也可能是技术介入就够了，修复之后再重新评测看结果，整个过程费时、费力。

结合知识Agent和对话中控Agent，构建智能化的AI原生服务闭环体系

"评估-诊断-优化"三位一体的运营Agent平台.png

五、评测怎么落地

• 识别出AI原生客服机器人的回答准确性
• 对BadCase需要根因的归类
• 对BadCase自动生成优化建议、优化建议具备自动执行的能力。

完整的对话链路.png

效果评测的主框架脉络

效果评测的主框架脉络.png

• 评测集的构建

  • 根据知识内容自动生成评测集
  • 文件上传原声评测集
  • 支持动态根据多种组合条件，从生产环境直接筛选服务记录作为评测集

• 评判的规则

  • 语义相关性
  • 表达质量
  • 内容合规性
  • 信息完整性

• 根因归类

  • 粗召检测问题
  • 精排问题
  • 生成错误问题
  • 生成幻觉问题

• 自动生成优化建议、并且自动执行

  • 缺少知识的根因类别，可以结合对话上下文自动触发从互联网检索关联知识
  • 粗召遗漏的场景、精排遗漏的场景，可以对识别出的关联分片信息增加相似问，以期再遇到类似Query时增加被召回的概率。实际使用下来，自动生成相似问的场景更加容易落地一些。

• 为什么起到“裁判”评测的效果

  • 更大尺寸的LLM，并且针对性开启了思考模式
  • 输入给到LLM的关联内容（对话上下文、参考知识、业务规则等）也更加全面

六、遇到了哪些难题

建设运营Agent进行对话效果评测的过程是痛苦的，规则如何准确生效、上下文怎么设计、怎么降低LLM的抽风等

6.1 正向评判还是负向评判

“纯正向”的评判比较宽松，可能遗漏问题。
“纯负向”的判断会让LLM过度关注缺陷，忽略整体的价值

正向与负向判断.png

采用“混合策略”的方式，分层评估，既有明确的红线扣分点，也会给LLM的发挥空间，在一定分值波动阈值内进行综合判断，LLM的思考过程就会变为“找优点 → 找缺点 → 综合权衡”，更接近人类的全面评估。

混合策略的分值判断.png

6.2 业务场景的强依赖

AI不懂业务怎么办？比如用户问“怎么退课”，A课和B课规则不同。AI不知道用户是哪种课，就容易瞎判。

在运营Agent进行Judge服务记录对话内容是否为BadCase之前需要做两件事情：

1. 识别出客户的诉求
2. 根据客户诉求获取强关联的业务内容作为参考知识给LLM

6.2.1 客户诉求

如何准确的识别出客户的诉求？

• 对当前Query内容进行提取会存在准确性的问题
• 涉及到多轮对话，更需要结合历史对话内容一起才能提取诉求
• 业务场景是比较复杂的，

  某健身企业，包含多种健身品牌，每种品牌下又都有类似名称的课程（比如私教课、团课），每种课程下又有类似的子场景（比如预约课程、取消课程等），这些细分的子场景有些描述内容是比较接近的，会影响客户诉求的识别。

• 客户的问法千奇百怪，而一个企业客户服务的业务范围是明确的、可枚举的

构建“意图分层体系”（业务品类 -> 业务场景）。

• 业务品类类似于“业务线”的概念，类似蚂蚁花呗业务、借呗业务。
• 业务场景，属于业务二级分类，比如“如何开通借呗服务”、“借呗如何还款”等

通过对服务记录数据的分析、以及和业务同学的沟通，梳理出上述KA健身企业7个业务品类、40多个业务场景信息，作为输入内容放入Prompt中，结合历史对话内容，让LLM把Query信息和品类/场景信息做映射判断，同时兼顾了历史诉求的延续、新诉求的产生等，从而识别出客户的当前最新诉求是什么。

案例

{
  "customerQuery": "转让",
  "robotAnswer": "请问您是想咨询哪种类型的课程转让呢？例如私教课或其他类型？"
},
{
  "customerQuery": "会员卡",
  "robotAnswer": "请问您是想咨询关于会员卡转让的具体问题吗？"
}

用户提问单纯是「会员卡」三个字的话，历史情况下非常容易识别为会员卡咨询等意图，产生误判。经过上述逻辑的处理后，能有效地识别用户意图为会员卡转让咨询

{
  "customerDemand": "会员卡转让咨询",
  "brand": "**健身会员卡",
  "scene": "会员卡转让场景",
  "thought": "客户当前问题为'会员卡'，结合历史对话中客户连续提及'转让'和'会员卡'，且客服明确询问'是否咨询会员卡转让问题'，可判定客户诉求聚焦于会员卡转让。根据品类信息列表匹配规则，'会员卡'属于xx健身的业务种类且未提及其他品牌，品牌xxx，结合业务种类记录为'xxxx'。场景匹配【场景信息】列表第28项'会员卡转让场景'的核心词'转让卡'、'会员卡转让'。"
}

意图分层体系构建

意图分层体系构建.png

6.2.2 参考知识

评测，需要用“怀疑”的视角看待对话链路中的每一个环节，比如RAG检索到的知识是不是ok的，有没有可能漏掉一些分片信息？

对话链路.png

这就和上文中的对话链路的梳理进行了关联，我们和知识Agent、对话Agent约定，将每个中间环节的输出结果进行持久化保存，比如知识Agent在做检索的时候，需要把粗召的结果分片信息保存、精排的结果也需要保存，运营Agent会对每个阶段的结果数据进行判断，如果发现有候选分片在粗召结果中未出现，就会把根因归类视为“粗召遗漏”；或者目标分片在粗召的结果数据中存在，但是在精排的结果分片中却消失了，就会把根因归类视为“精排遗漏”。

根据上面这个逻辑，现在就有了一个首要问题，如何知道和Query关联的所有的目标知识分片？

把和当前机器人绑定的所有知识文档作为候选知识，用Query、历史对话、提取出来的业务品类/业务场景/客户诉求，综合作为输入信息，让LLM校验候选知识中哪些分片内容是和Query强关联的目标分片知识。

知识召回.png

这种方式，对于机器人绑定的资料比较少的情况下，是可以适用的，会对机器人绑定资料的每一个分片都做检查，找出目标分片。但是当机器人绑定的资料多的时候就不适合了，因为太慢了！

正常的RAG问答链路中，也会根据设定的阈值从知识库中召回TopN的知识内容，我们在这个基础上，把阈值适当降低，扩大TopN的数量，尽可能的使得和Query相关的内容都被获取到。

6.2.3 豁免

由于一些业务场景的特殊性，客户的Query会被规则命中后走特殊的逻辑，比如触发机器人转人工、或者机器人吐出固定的话术等，即使这些机器人回答的内容并不能解决客户的诉求，但是在这种特殊场景下，它的回答内容是符合业务预期的，就不能被判为BadCase，应该被豁免。

最初这个豁免的判断，是和BadCase的发现的逻辑放在一个Prompt中灌输给LLM，符合豁免规则的对话内容不被标记为BadCase。但是实操下来，发现识别会有偏差，为了避免“误杀”，我们把豁免判断抽成了独立的逻辑，先进行豁免的检测，再进行BadCase的识别。

6.3 LLM的对抗

“随机性”导致的问题

• 使用同一个LLM（业界头部的LLM）、相同的Prompt，多次调用，LLM输出的结果并不完全一样；
• 相同的Prompt，不同的LLM（业界头部的LLM），输出的结果也不完全一样，结果甚至相反；

6.3.1 第一个问题

当你输入一个Prompt后，模型会执行如下几个步骤：

• step1：处理输入内容；
• step2：计算出所有可能的下一个token的概率分布；
• step3：从这些分布中选出一个token，作为输出；
• step4：把这个新生成的token追加到原有上下文中，再重复上述过程，生成下一个token，如此循环；

关键在于第2步和第3步。为了增加随机性，LLM使用了两个重要的参数：Temperature 和 Top-P
Temperature（温度）

• 温度是一个在Softmax计算之前应用的参数，它直接重塑概率分布概率 = Softmax(原始分数 / Temperature)
• 低温度（如 0.1）： 除以一个很小的数，会放大高分数和低分数之间的差距；
  效果：让高概率的词（如“公园”）概率更高，低概率的词（如“飞翔”）概率更低。模型输出变得更确定、保守；
• 高温度（如 1.5）： 除以一个大于1的数，会缩小分数之间的差距；
  效果：让概率分布变得更平缓。低概率的词（如“吃饭”、“飞翔”）机会变大了；输出变得更多样、更有创意，但也更不稳定。

Top-P
Top-P是在Softmax计算之后应用的筛选机制，它将候选词按概率从高到低排序，然后只保留一个最小集合，使得这个集合中所有词的概率之和刚刚超过Top-P中的P（例如 p=0.9）。
过程如下：

• 排序：公园(65%)，散步(24%)，吃饭(9%)，飙车(2%)……；
• 计算累积概率：公园(65%)，公园+散步=89%，公园+散步+吃饭=98%（已经 > 90%）；
• 筛选：只保留 {公园， 散步， 吃饭}。概率极低的“飙车”被剔除；
• 重新归一化：将这三个词的概率重新缩放，使其和为100%（例如：公园 ~66%，散步 ~25%，吃饭 ~9%）；
• 最后，从这个新的、筛选后的集合中进行随机采样。

由此可见，只要 Temperature > 0 或 Top-P < 1.0，模型在每一步都面临随机的结果，而一次完整的结果生成又是顺序的过程，每一步的随机选择都会影响后续步骤。

6.3.2 第二个问题

为什么相同的Prompt，不同的LLM输出结果却可能不同（即使都是国内顶流的LLM）？这主要是分词和训练参数的差异导致。

• 分词差异：不同模型的分词器（Tokenizer）不同
• 训练参数差异：不同的LLM其训练的过程和训练的参考数据都不尽相同
• LLM的指令微调和RLHF也千差万别

6.3.3 怎么解决

对于第一个问题，在调用LLM的时候，可以通过尝试调整Tempture和Top-P的值来解决（阿里云百炼的SDK支持动态设置），虽然不能完全避免它随机性导致的问题，但是可以降低发散的概率。

对于第二个问题，我们采用了多个LLM对抗的方式来解决，即BadCase在识别的时候，通过两个、三个LLM执行相同的Prompt，采用统计学的方式得到最终结果（需要对LLM的执行耗时不是非常敏感）。

示例

{
  "qwen3-235b-a22b" : "{\"score\":30,\"thought\":\"1. **内容合规性**：客服回答未直接处理客户因店面装修申请停卡的诉求，且未正确引用参考知识中关于特殊情况（如装修）需联系人工或店长的规则，违反了特殊场景需转人工的合规要求，扣20分。\\\\n2. **语义相关性**：客户明确诉求为停卡一周，但客服未提供有效解决方案（如指引停卡路径或确认资格），仅重复引导选择订单或转人工，未解决实际问题，扣30分。\\\\n3. **表达质量**：语言结构合理，但未明确说明停卡规则，导致信息模糊，扣5分。\\\\n4. **信息完整性**：未提及停卡条件（如需备注原因、审核时间等）或操作路径（如链接申请），核心信息缺失，扣15分。\\\\n综合评分：100-20-30-5-15=30\"}",
  "deepseek-r1" : "{\"score\":60,\"thought\":\"客户诉求识别：客户问题'店面还在装修，申请停卡一周'为肯定句式，但含业务动词'申请停卡'，根据规则视为明确诉求（停卡申请）。参考知识分析：分片'我可以停卡一周吗？'直接匹配客户问题，chunkContent明确'不支持自定义停卡时长或指定到某一时间'，仅支持无理由停卡30天或特殊情况需证明。客服回答让客户'返回订单列表选择订单'或'转人工'，未引用该核心知识，且与参考知识中自助停卡路径（如分片1的链接）矛盾，内容合规性扣20分。语义相关性：参考知识有完全匹配分片，但客服回答缺失核心信息（不支持自定义时长），扣10分；历史对话显示客户重复诉求（多次'转人工'），但回答包含转人工语义，不额外扣分，得40分。表达质量：语言流畅，无语法错误或质疑语句，得10分。信息完整性：未提供停卡规则（如时长限制）或自助路径，核心信息缺失，扣10分，得10分。总分：0（合规性）+40（相关性）+10（表达）+10（完整性）=60。\"}"
}

两个LLM虽然给的判断分值不同的，但是都远小于我们设定的BadCase阈值，最终结果为45分（求的均值），准确识别为BadCase，符合预期。

6.4 深度思考模式

开启LLM的深度思考模式后（比如百炼可以通过sdk的enableThinking参数控制），与普通的“链式思考”相比，“深度思考”可以理解为启动了一个高级的、内置的“系统Prompt”，这个Prompt专门指示模型做如下事情：

• 问题解析与规划：不要急于回答，先彻底理解问题的核心、边界条件等；
• 多路径推理：构思多种解决方案或思路，并比较它们的优劣点差异；
• 逐步执行与验证：严格的、一步一步的执行计划，每一步都进行自我检查，确保逻辑和事实的正确性；
• 自我批判与修正：主动寻找自己推理中的漏洞、假设或可能错误的地方，并尝试修正它们；
• 最终整合：在确认推理过程没问题后，给出一个精炼、准确的最终答案；

在实际使用中，既在Prompt中详细描述了让LLM执行操作的步骤，同时也根据场景复杂度开启了LLM的“深度思考模式”，因为“深度思考模式”不仅仅是执行我们给的步骤，它包含了更高层次的推理执行：

• 理解“为什么”要这么做：即使你列出了步骤，模型也可能不理解每一步的意图，开启“深度思考”会迫使它去理解其背后的逻辑，从而在执行时更不容易出错（注意，也是无法完全避免）；
• 自我验证：我们给的步骤可能本身就有漏洞，或者模型在执行某一步时可能出错，“深度思考”模式下的LLM自我批判机制能主动发现并纠正这些错误；
• 处理模糊和意外情况：如果你的步骤描述不够精确，或者问题中出现意外情况（例如数据单位不统一），开启深度思考的模式会更有可能发现并处理这些歧义，而关闭模式则可能直接导致错误（这一点很重要）

需要注意的是

• LLM的响应时间也会显著变长，需要结合自己的场景看能否接受
• “深度思考模式”也不是一开启就能带来明显的效果，对于事实查询、摘要、简单分类、格式转换，“深度思考”模式是可以关闭的
• 对于需要LLM进行复杂推理分析、需要得到高可靠性的输出结果时，“深度思考模式”的开启通常会带来不错的效果。

6.5 上下文工程

通过上面的一系列处理，有了让LLM执行的规则、操作步骤、参考数据，还有了运行态的动态参数调整（Tempture等），LLM理论上可以按照我们的期望进行推理、输出结果了，实则不然，还有很多事情需要做，这就是上下文工程（Context Engineering），而且需要持续去做。

之前有个概念叫“Prompt Enineering”，我理解其实属于现在这个“Context Engineering”概念的子集，前者更关注如何与LLM沟通，后者在此基础上，更关注提供合适的、有效的信息给LLM。这个概念之所以大受关注，本质上在于给到LLM的上下文内容，太长或太短都会出问题。

在实际使用中发现，很多LLM号称窗口可以支持几十万、上百万的Token量级，但实际也仅是能“支持”而已，“效果”会得不到保证。

案例
因为要提供很多参考知识（和Query相关的文档分片内容、智能SOP内容、FAQ内容等），让LLM进行推理判断，而分片的内容本身包含很多的文字，加上其他的内容（规则、步骤、历史对话、Few-Shot等），这些累加起来每次需要大几万的Token，LLM在思考的时候就会时常出现推理错误的情况（即使开启了上文描述的“深度思考模式”也不可避免）

{
  "chunkContent": "xxxxxxxxxxxxxxxxxxxxxxxxxxx，上百个字符)",
  "chunkId": "123456789034576961536",
  "chunkRelatedQuestion": [
    "aaaaaaaaaaaaa，几十个字符"
  ],
  "chunkTitle": "aaaaaa"
}
……
……
{
  "chunkContent": "yyyyyyyyyyyyyyyyyy，上百个字符)",
  "chunkId": "123456789034576961578",
  "chunkRelatedQuestion": [
    "bbbbbbbbbbbb，几十个字符"
  ],
  "chunkTitle": "ccccccc"
}

LLM会把chunkId为“123456789034576961536”的数据，误认为是“1920679034576961578”，出现张冠李戴的问题

6.5.1 为什么会这样

LLM的“记忆力”完全依赖于工作记忆（Working Memory），也就是通常说的“上下文窗口”。可以把大模型想象成一个拥有海量长期记忆（从训练数据中学到的知识）但只有极短的工作记忆（上下文窗口）的机器人，它的思考过程完全依赖于当前上下文窗口中的信息，一旦超出窗口，它就“看不见”了，而即使是窗口内的信息，处理机制也因为底层架构的注意力机制而存在局限性

• 注意力权重稀释
• 缓存局限
• 位置编码局限

上下文失效的四个场景

• 上下文冲突场景
  即上下文中包含了相互矛盾的信息或指令，LLM输出混乱或偏向某一方。
  • 近因效应与首因效应：
  • 注意力竞争
    当两条冲突（或者不同维度）指令A和B分别位于上下文的不同位置时，模型会陷入“注意力内战”。
  • LLM没有一个内部的“逻辑仲裁器”
• 上下文混淆场景
  即LLM混淆了不同实体、概念或话题的来源。例如，将用户A说过的话安在用户B身上。比如上文中我们遇到的chunkId内容混淆问题就属于该场景。
  • 注意力泛化
  • 位置编码模糊
  • 缺乏实体追踪
• 上下文干扰场景
  即无关紧要的背景信息或之前的失败案例影响了LLM当前的表现。
  • 注意力稀释
  • 激活值的传播
  • 指令遵循的脆弱性
• 上下文丢失
  即LLM忘记了上下文窗口开头部分的内容。
  • 缓存的先进先出
  • 注意力权重衰减

6.5.2 怎么解决

整个“上下文工程”的核心，就是给LLM在合适的场景、提供的合适的内容

• 逻辑的分拆
  在设计之初，我们高估了LLM的能力，把大量复杂的逻辑写在一个Prompt中，让LLM去分析。比如在做BadCase根因归类的时候，我们把所有的根因归类及其规则描述都放在了一个Prompt中，结合Prompt中输入的历史对话等上下文，让LLM判断当前的BadCase属于哪种根因，这个模式其实类似于Function-Call。

实际运行发现会有误判根因的情况，我们根据前文的分析做了逻辑的拆分，把每一种根因归类都单独拆出来，由一次大模型调用，改为多次调用，降低每次给LLM任务的复杂度，拆分之后的LLM识别效果要比混在一起好很多。

• 内容精简

  • 明确告诉LLM需要“请一步一步进行分析”等类似的语句，是十分必要的；
  • 根据上文LLM注意力机制的分析，降低Prompt的长度（目前5w以内，该值不固定，LLM也在发展ing）；
  • 将重点的规则描述放到了Prompt的头部。比如我们将“内容合规性”的判断放到了BadCase识别规则中靠前的位置，降低该规则放到后面时被LLM漏掉的概率，因为“合规”是底线；
  • Prompt中只包含必要的信息，尤其给LLM的参考知识内容比较多的时候，减少冗余信息，就是减少对LLM的干扰。比如文档分片包含了很多属性，分片名称、相似问、分片ID、标签、创建时间、修改时间、创建人、修改人、状态、来源等等，我们只把最重要、最需要的ID、名称、内容、相似问信息给到LLM，其他冗余信息全部丢弃。
  • 压缩数据。一些id、变量名等信息等需要传递给LLM，但是其原始格式受上游系统的设计原因，可能很长（例123456789066515357696），这些长ID所占用的Token就会很多，我们在组装Prompt内容之前，先对这些数据做了一把映射，比如“1123456789515357696”映射为“1”，“123456789515357697”映射为“2”，映射的时候保证唯一性，这样也会大大减少Prompt的长度。

• 强制性的约束
  期望LLM执行完后吐出固定的格式，就需要明确出来

# 输出规范（请严格按照标准的json格式输出!） 请严格遵循：
## 直接输出纯净JSON对象，禁止包含```json等代码块标识符
## 使用标准JSON格式：
    ### 取消所有换行符，保持单行结构
    ### 必须使用双引号
    ### 结尾不要带多余符号
## 错误示例： x ```json\n{\n...}\n``` （含代码块标识） x {'tasks': [...]} （单引号非法）
## 输出必须为正确可解析的json格式(严禁多余、缺少和错误的{}和`符号和多余的json字母)

# 禁止行为
    × 使用非工具库中的工具
    × 情感化表达或主观猜测
    × 非标准JSON格式的输出

• Few-Shot
  在Prompt中添加适当的Few-Shot，可以有效引导大模型参考我们给出的示例、思考步骤进行推理，对于提升整体的推理准确性效果是有很大帮助的。

6.6 并发和限流

对于QPM的限流，我们只有控制线程调用的并发数。同时我们观察到，当并发调用大的时候，即使还没达到限流的阈值，也会影响并发调用LLM的响应速度，甚至几十秒才返回结果，虽然可以改为LLM流式的输出，但是对我们的场景而言，是需要获取到完整的结果才能知晓对错。

对于TPM的限流，不仅是输入的Token会有影响，如果开启了思考模式，输出的时候思考过程数据的输出，也会占用TPM的阈值，输出Token量可以通过max_tokens的参数来进行限制。

6.7 中断及恢复

运营Agent执行的效果评测的任务，是需要长时间运行的，每一个任务都包含了很多服务记录的检测，每一条服务记录又包含多个阶段的逻辑处理。

如果遇到服务重启或者其他原因，运行中的任务就会被中断。这种异常的中断，会影响使用体验，因为是长时间运行的任务，当用户察觉到异常时已经滞后了，重新开始运行又要耗费大量时间，更不要说LLM的重复调用（Token的浪费）。

中断与恢复.png

核心思路就是每个阶段运行的时候，该阶段中每条服务记录在做逻辑处理时都会上报心跳，更新该对应任务的最新状态，定时任务会轮询当前超期的任务，将未开始、失败的服务记录进行重新该阶段逻辑的执行。

七、效果

一些指标性的结果在前面第4小节中已经做了概要的描述（BadCase发现的准确率85%+、根因归类和优化建议生成的准确率80%+等）。

找出BadCase的根因只是第一步，更进一步的事情是如何解决？

• 有些根因是需要运营协作才能解决，比如转人工策略的优化等。

• 有些根因需要技术协作才能解决，比如生成内容的prompt优化等。

• 还有一些场景，运营Agent可以直接给出优化建议：

  • 如“粗召遗漏问题根因”、“精排遗漏问题根因”等，这些根因我们可以理解为和Query相关的内容确实已经存在于知识库中了，但是召回的时候因为相似度等原因导致在最后的环节没有被用上，我们给出的优化建议一般是给强关联的候选分片增加“相似问”，可以自动入库生效，也可以运营审核之后入库生效。
  • 又例如“缺少知识”等根因，运营Agent会根据当前服务记录的上下文和客户意图，自动从互联网检索相关知识，并且对检索到的知识内容进行二次校验，将高度匹配的内容抽取成知识自动入库，或者运营审核之后入库（但是客服场景，从互联网抓取到高匹配内容的概率还是比较小，绝大部分情况都是运营Agent把意图和业务场景提供出来，让运营同学手动补充相关知识）。

八、还能做什么

如果将关注点从BadCase的粒度放大到整个服务链路，AI还能做什么？

从服务爬坡阶段（非初始化冷启动）的提效（满意度、服务成本等）角度来看，一般期望通过机器人承担更多的客户服务，减少人工服务，只有机器人服务不了的，才通过转人工服务来兜底承接。量化这个“期望的效果”一般有两个指标，机器人回答准确率、机器人解决率。

机器人回答准确率
准确，一般指机器人的回答内容是否符合预期；
机器人回答解决率
解决，一般指机器人回答的内容，解决了客户的咨询问题；
但是准确率其实并不等于解决率，即使机器人按照运营（业务）的要求吐出了符合预期的回答内容，但是并不一定能解决客户的问题，客户还是要转人工；而机器人即使没有吐出预期的答案，比如用词不是很恰当、引用的参考知识不全等，但是客户觉得ok，能解决他的问题；更有甚者，客户因为个人心智原因，一接通就转人工，不给机器人回答的机会。

一通转人工的服务（转人工，就视为机器人服务未解决客户问题）具体是哪方面原因导致的？我们利用AI建设了服务分析的能力，帮助运营同学可以从三个方面来分析其原因：

转服务的原因.png

• 服务策略的配置导致触发转人工
  运营人员可以配置拦截策略，命中策略的客户咨询内容，会中断机器人服务，触发转人工请求。如果一段时间内，忽然有大量的转人工请求出现，也可能是因为某个策略异常变动导致，运营Agent也可以发挥能力，做到自动分析识别。
• 客户心智问题
  用户心智导致的转人工，比如客户不说话，或者只表达“转人工”等内容，属于心智问题。这种场景机器人服务阶段很难做功，它间接决定了“解决率”的上限。

不过，仍然可以根据“是否复访”拆解出有多少是之前没有服务好、导致本次服务客户一接通就想转人工。

另外可以结合用户的个人最近的订单记录、咨询记录，以及当前整体Top的问题，把“猜问”进一步个性化，理论上也可以起到正向的效果。

• 机器人的回答内容不能解决客户问题

机器人按照预期提出了回答内容，但是客户仍然触发了转人工，运营Agent需要深度分析这种场景。

它可能是机器人问答链路的问题导致，结合前文大篇幅描述的对话效果评测内容；也可能是机器人覆盖范围受限制导致，需要利用LLM，结合机器人服务对话内容和人工服务对话内容，分析出机器人给的方案和人工服务阶段给的方案的差异性，根据进一步下钻的分析调整机器人所能服务的覆盖业务、知识内容等。
也可能是业务本身的异动，如大促活动等。

人工处理与机器处理的对比.png