大模型和算力的快速发展，促进了很多行业的变革，即使目前AI仍然处于“自主行动”的初级阶段，即“辅助人”的阶段，其巨大的潜力和演进路径却是相对明确的。
客服领域，作为最早使用“智能能力”的领域，也随着LLM的发展有了新的生命力。
我们先来看下智能客服的发展。
一、基于NLP的传统机器人客服
曾经以“NLP”、“规则引擎”、“知识库”为基础构建的上一代“机器人客服”，给更加传统的“人工客服”带来了一次“跃进”。但是其意图理解差（多意图理解更难、甚至需要定向训练）、维护成本高（冷启动成本大、知识维护成本大）、对话能力弱（几乎为0的泛化能力、回答生硬、指代消解能力差），也给“机器人客服”带来了不少诟病。这一阶段的客服运营（本文指机器人客服方面的运营，非排班、培训、质检、考核等人工客服方面的运营）重点工作内容为：
知识库建设（FAQ喂养）： 将常见的客户问题整理成“问题-答案”对； 同义词和规则配置： 为每个问题配置大量可能的关键词和同义句。例如，为“如何退款”配置“想退货”、“钱怎么退”、“不要了”等； 对话流程设计： 设计复杂的、树状的对话流程（SOP、决策树等），例如，“用户选择A -> 跳转到流程A1 -> 询问信息A2...”； 监控与维护： 监控哪些关键词被触发，哪些问题未被识别，然后不断打补丁，添加新规则；
语言是无限的，但规则是有限的。客服运营团队永远在追赶用户层出不穷的新问法，陷入“猫鼠游戏”，疲于奔命。更加心碎的是无论怎么优化，机器人的智能水平上限在设计之初就被规则库的规模锁死了，无法处理规则外的问题。
二、基于RAG的智能客服
大模型的快速发展，重新定义了“机器人客服”，使其向“智能客服”前进了一大步。我们对于LLM在客服上的应用，最开始是从RAG（RAG现在都被说烂了，但还是得说下）作为切入点进入的，目的是为了提升文档问答的准确率、降低知识的运营成本。
RAG为什么有效，因为它既不是单纯的
更不是
而是从“知识库”中找出最相关的内容，将“检索到的信息”和“用户问题”打包成一个超级提示词，LLM 扮演“专家助理”，而非“专家本人”。它既有更加准确的知识作为供给，也能经过LLM的润色表达的更加自然。
在检索（Retrieval）方面，作为RAG质量生命线的检索，向量化检索方式的引入，弥补了传统关键词和搜索引擎检索的不足（ES方式），能够有效提升召回率。
ES方式：
向量化方式：
RAG中常将两者融合处理：
在增强（Augmentation）方面，将检索到的信息片段和用户问题，精心组装成一个LLM能理解的"提示词"，为生成环节奠定基础。这又包括两方面内容：
信息组装：
在工程侧，将检索环节得到的候选知识分片，按相关性排序，结合历史对话内容拼接成一个完整的"上下文背景信息"；
提示词工程，这是"增强"环节的灵魂，通常包含以下部分：
系统角色： 定义LLM的身份。例：“你是一个专业的客服助手，严格根据提供的背景信息回答问题”； 背景信息/指令： 明确告知LLM答案的来源和规则。例：“请严格根据以下用```标记的背景信息来回答最终的问题。如果背景信息中没有答案，请直接说'根据现有信息，我无法回答这个问题'，不要编造信息”； 背景信息内容： 前面提到的上下文； 用户问题： 放入原始的用户问题； 输出格式要求（可选）： 要求LLM以特定格式（如Markdown、带项目符号的列表）输出，或要求其引用来源。 在生成（Generation）方面，将组装好的提示词发送给大语言模型。LLM会基于其强大的语言理解和生成能力，执行以下核心操作：
理解指令： 识别自己的角色和回答规则； 关联信息： 在提供的背景信息中，定位与问题直接相关的部分； 总结和生成： 对找到的信息进行归纳、总结和重新组织，用更自然、流畅的语言表达出来，而不是简单地复制粘贴。
引入RAG之后，我们的机器人客服主链路如下：
RAG的能力，让机器人客服的知识来源从之前较为单一的FAQ维度，跃迁到了整篇的文档维度（doc、pdf、ppt、表格等），对于机器人知识问答场景的影响非常大。
虽然彼时的LLM还没有像现在这么强悍，它能支持的上下文token量级也很有限，所以不少工作（意图理解、多轮的支持、RAG结果的精排等）还是由工程侧和小模型的协作才能完成，但这足以让客服运营的工作内容发生了很大的变化，也使得冷启动、知识维护的成本得到一定程度的降低，毕竟上传知识文档比配置一系列的FAQ要容易很多。客服运营可以将精力放到业务sop流程的构建、知识文档的保鲜上。
三、基于AI原生的智能客服
LLM经历了2022年底的闪耀登场、到2023年的百模大战、再到2024年的AI应用涌现，迎来了2025年的智能体蓬勃发展。随着基模的能力越来越好，可以把更加复杂的逻辑交给LLM理解，甚至可以借助MCP让LLM直接调用外部工具、借助Function-Call的能力实现本地服务数据的动态利用，这让“传统研发”的工程同学可以直接通过对基模的调用（比如基于百炼）手搓完整的机器人客服链路，让基于AI原生的智能客服可以落地。
基于AI原生的智能客服主链路：
链路中使用模型的地方都切换为了LLM，根据使用的场景的不同采用了不同尺寸的LLM，比如改写会使用参数小一点的模型（7b），而规划和决策就会使用参数量大一些的模型（max、32b）。同时因为是对话场景，对于耗时比较敏感，需要权衡LLM的选型和响应时间，一般模型参数越大，效果越好，但是响应时间也会变长。
因为基模的强大，我们可以把更多的内容让LLM去推理判断（相比之前，进化很多），比如可以把复杂的业务逻辑，通过自然语言描述成“如果xxx，那么xxx”这种格式，结合上下文信息，让LLM决策该走什么样的逻辑分支，我们把它称之为“智能SOP”。智能SOP（依然存在很大的优化空间）中需要动态调用LLM以外的内容，可以通过Function-Call的方式实现。
对于知识类的问答，RAG仍然必不可少，而且也在不断进化：
四、对话效果如何评测
基于AI原生搭建的对话链路，做个Demo没问题，但是如果要商业化交付，就得关注实际的效果，本文要讨论的重点内容来了，该如何观测其效果？
虽然整个链路很多环节都用到了LLM，但我们关注的是端到端的机器人回答效果，单纯对LLM本身的评测不是我们的目标。
传统做法是运营人员通过指定评测集，或者从生产环境抽取服务记录，线下进行人工标注看效果。如果发现问题，需要单独记录，找技术进行定位，是问答链路中哪个环节可能出了问题导致了BadCase，修复方案可能是需要运营介入、也可能是技术介入就够了，修复之后再重新评测看结果，整个过程费时、费力。
机器人对话都可以基于AI原生实现了，那么对话链路的效果评估，是不是也可以利用AI原生的能力实现，节省人工参与的成本？
答案是肯定的，我们经过不断地摸索和实践，建设了"评估-诊断-优化"三位一体的运营Agent平台（一个垂类Agent），结合知识Agent和对话中控Agent，一起构建了智能化的AI原生服务闭环体系，实现客服机器人服务质量的持续进化。
在KA客户的实际应用中，服务记录BadCase发现的准确率85%+，根因归类和优化建议生成的准确率80%+，机器人客服的运营同学可以根据运营Agent的产出结果来定向操作，节省了很大的成本。同时，该能力也应用到了ToB的产品中，目前评测能力的综合准确性达到85%+。
五、评测怎么落地
首先，评测能力目标的确认，要识别出AI原生客服机器人的回答准确性，对BadCase需要根因的归类，能够对BadCase自动生成优化建议、优化建议具备自动执行的能力。 为了实现上述目标，我们需要对完整的对话链路进行拆解，按照功能模块的粒度进行关键信息的落数（DB or 日志），我们就可以根据服务记录的ID，把接收到Query到产出Answer的关键链路都能串联起来。
其次，定义效果评测的主框架脉络：
其中：
评测集的构建，为了适配不同情况的评测，我们既提供了根据知识内容自动生成评测集的能力，也提供了文件方式上传原声评测集的能力；同时针对已经使用AI原生机器人客服的场景，支持动态根据多种组合条件，从生产环境直接筛选服务记录作为评测集的能力 我们的思路是首先根据评判的规则，端到端的看机器人回答的内容是否符合期望（即命中规则），不符合期望的视为BadCase，有了BadCase就缩小了目标范围，为后面进一步进行根因归类和优化建议生成提供了可能性。规则的定义很重要，直接影响BadCase的产出，我们从语义相关性、表达质量、内容合规性、信息完整性等几个维度来评估，每个大的维度下又包含各自更加细致的子维度。 根因的归类，会直指BadCase的核心，我们根据上面拆解的对话链路关键环节，从知识的角度、对话中控决策的角度、大模型推理生成的角度出发，定义了十几种根因的类别，包括粗召检测问题、精排问题、生成错误问题、生成幻觉问题等。根因类别的定义越细致，越能更加精准的找到问题、以及解决问题。 BadCase的根因被识别出来后，部分类别是可以自动生成优化建议、并且自动执行。比如缺少知识的根因类别，可以结合对话上下文自动触发从互联网检索关联知识；粗召遗漏的场景、精排遗漏的场景，可以对识别出的关联分片信息增加相似问，以期再遇到类似Query时增加被召回的概率。我们实际使用下来，自动生成相似问的场景更加容易落地一些。 基于AI原生的对话链路，为了保证性能和体验，其使用的LLM参数尺寸都不是特别大。而我们建设的评测能力也是基于AI原生，并且能对同样基于AI原生的对话链路起到“裁判”评测的效果（准确率85%+），有两个和LLM本身的特点很重要，那就是我们在很多环节使用了更大尺寸的LLM，并且针对性开启了思考模式，这就使得LLM的推理能力和判断能力有了更大的发挥空间，同时作为输入给到LLM的关联内容（对话上下文、参考知识、业务规则等）也更加全面，让LLM的思考基础更加充分。
最后，提出搭建平台的思路和理论并不困难，尤其还是基于AI原生的场景，但是如果要达成目标，还是得在实践中不断发现问题、思考问题、解决问题，才能提升评测的最终效果。
六、遇到了哪些难题
建设运营Agent进行对话效果评测的过程是痛苦的，规则如何准确生效、上下文怎么设计、怎么降低LLM的抽风等，下面介绍下我们在实践中通过踩坑积累的一点经验，抛砖引玉吧。
6.1 正向评判还是负向评判
要评判机器人吐出答案是不是符合预期，首先就得定义出来“规则”是什么。我们最开始的想法是搞几个通用的规则，每个规则都有分数，让LLM根据输入的Query和机器人吐出的答案Answer，判断Answer是否命中规则。每个规则项根据权重设定了不同的分数，比如“语义相关性”维度分值最大（50分），而“表达质量”维度分值设置的比较低（20分），所有评判维度总分加起来是100分。
这里的分值判断，不是让LLM只做“正向判断”，或者只做“负向判断”，而是一种混合的做法。因为“纯负向”的判断会让LLM过度关注缺陷，忽略整体的价值；而“纯正向”的评判又比较宽松，可能遗漏问题。
我们采用“混合策略”的方式，分层评估，既有明确的红线扣分点，也会给LLM的发挥空间，在一定分值波动阈值内进行综合判断，LLM的思考过程就会变为“找优点 → 找缺点 → 综合权衡”，更接近人类的全面评估。
6.2 业务场景的强依赖
有了上面的评判规则后，我们在实操过程中，发现对于有些服务记录的评判，总是达不到期望的效果，例如当用户咨询“课程取消规则”，机器人在回答时需要进一步澄清明确是哪种类型的课程，才能给出对应的内容，因为不同类型的课程，在使用规则上会有差异（如「A」类型的课程可以上课前2小时取消，而「B」类型的课程需要提前3小时取消），运营Agent如果不知道不同种类的明细规则、不清楚客户的真实诉求，就会导致误判。
因此，在运营Agent进行Judge服务记录对话内容是否为BadCase之前，我们需要做两件事情：1、识别出客户的诉求；2、根据客户诉求获取强关联的业务内容作为参考知识给LLM。
6.2.1 客户诉求
如何准确的识别出客户的诉求？依靠LLM对当前Query内容进行提取会存在准确性的问题，如果涉及到多轮对话，更需要结合历史对话内容一起才能提取诉求，因为诉求可能会变、也可能多句内容综合起来才能识别出完整的诉求（比如上面的例子）。
更加重要的一点，一些商家的业务场景是比较复杂的，比如某健身企业，包含多种健身品牌，每种品牌下又都有类似名称的课程（比如私教课、团课），每种课程下又有类似的子场景（比如预约课程、取消课程等），这些细分的子场景有些描述内容是比较接近的，会影响客户诉求的识别。
客户的问法千奇百怪，而一个企业客户服务的业务范围是明确的、可枚举的，我们设计了两个层级的关联：业务品类和业务场景。
业务品类类似于“业务线”的概念，类似蚂蚁花呗业务、借呗业务。
业务场景，属于业务二级分类，比如“如何开通借呗服务”、“借呗如何还款”等
我们通过对服务记录数据的分析、以及和业务同学的沟通，梳理出上述KA健身企业7个业务品类、40多个业务场景信息，作为输入内容放入Prompt中，结合历史对话内容，让LLM把Query信息和品类/场景信息做映射判断，同时兼顾了历史诉求的延续、新诉求的产生等，从而识别出客户的当前最新诉求是什么。
如以下案例，
{ "customerQuery": "转让", "robotAnswer": "请问您是想咨询哪种类型的课程转让呢？例如私教课或其他类型？"}, { "customerQuery": "会员卡", "robotAnswer": "请问您是想咨询关于会员卡转让的具体问题吗？"}用户提问单纯是「会员卡」三个字的话，历史情况下非常容易识别为会员卡咨询等意图，产生误判。经过上述逻辑的处理后，我们能有效地识别用户意图为后续的根因归类、优化建议产出准确性提供了保障。
{ "customerDemand": "会员卡转让咨询", "brand": "**健身会员卡", "scene": "会员卡转让场景", "thought": "客户当前问题为'会员卡'，结合历史对话中客户连续提及'转让'和'会员卡'，且客服明确询问'是否咨询会员卡转让问题'，可判定客户诉求聚焦于会员卡转让。根据品类信息列表匹配规则，'会员卡'属于xx健身的业务种类且未提及其他品牌，品牌xxx，结合业务种类记录为'xxxx'。场景匹配【场景信息】列表第28项'会员卡转让场景'的核心词'转让卡'、'会员卡转让'。"}业务品类和业务场景信息（或者称为“意图分层体系”）可以通过自动化的方式来抽取，但是也需要人工的介入进行保鲜：
6.2.2 参考知识
评测，需要用“怀疑”的视角看待对话链路中的每一个环节，比如RAG检索到的知识是不是ok的，有没有可能漏掉一些分片信息？
这就和上文中的对话链路的梳理进行了关联，我们和知识Agent、对话Agent约定，将每个中间环节的输出结果进行持久化保存，比如知识Agent在做检索的时候，需要把粗召的结果分片信息保存、精排的结果也需要保存，运营Agent会对每个阶段的结果数据进行判断，如果发现有候选分片在粗召结果中未出现，就会把根因归类视为“粗召遗漏”；或者目标分片在粗召的结果数据中存在，但是在精排的结果分片中却消失了，就会把根因归类视为“精排遗漏”。根据上面这个逻辑，现在就有了一个首要问题，如何知道和Query关联的所有的目标知识分片？
Query或者服务记录，是和某一个客服机器人强绑定的，并且只属于一个机器人，我们一开始的想法，是把和当前机器人绑定的所有知识文档作为候选知识，用Query、历史对话、提取出来的业务品类/业务场景/客户诉求，综合作为输入信息，让LLM校验候选知识中哪些分片内容是和Query强关联的目标分片知识。
这种方式，对于机器人绑定的资料比较少的情况下，是可以适用的，会对机器人绑定资料的每一个分片都做检查，找出目标分片。但是当机器人绑定的资料多的时候就不适合了，因为太慢了！
正常的RAG问答链路中，也会根据设定的阈值从知识库中召回TopN的知识内容，我们在这个基础上，把阈值适当降低，扩大TopN的数量，尽可能的使得和Query相关的内容都被获取到。而且这个召回的数量就不再是全部的文档分片信息了，在性能上也会得到提升。
6.2.3 豁免
由于一些业务场景的特殊性，客户的Query会被规则命中后走特殊的逻辑，比如触发机器人转人工、或者机器人吐出固定的话术等，即使这些机器人回答的内容并不能解决客户的诉求，但是在这种特殊场景下，它的回答内容是符合业务预期的，就不能被判为BadCase，应该被豁免。
最初这个豁免的判断，是和BadCase的发现的逻辑放在一个Prompt中灌输给LLM，符合豁免规则的对话内容不被标记为BadCase。但是实操下来，发现识别会有偏差，为了避免“误杀”，我们把豁免判断抽成了独立的逻辑，先进行豁免的检测，再进行BadCase的识别。
6.3 LLM的对抗
大模型本身也是一种概率性的模型，也就是说即使给定了它“确定”的Prompt，但是它吐出的结果却具有“随机性”。有了前面的规则、数据，我们在让LLM进行BadCase识别的时候就遇到了这种“随机性”导致的问题，这个问题体现在了两个方面：
（1）使用同一个LLM（业界头部的LLM）、相同的Prompt，多次调用，LLM输出的结果并不完全一样；
（2）相同的Prompt，不同的LLM（业界头部的LLM），输出的结果也不完全一样，结果甚至相反；
6.3.1 第一个问题
针对第一个问题，核心在于LLM的“随机采样”，随机性本身不是一个问题，这其实是LLM推理性、多样性的来源。大模型生成结果（文本内容为例），是一个自回归的过程，是一个token一个token进行的。当你输入一个Prompt后，模型会执行如下几个步骤：
step1：处理输入内容； step2：计算出所有可能的下一个token的概率分布； step3：从这些分布中选出一个token，作为输出； step4：把这个新生成的token追加到原有上下文中，再重复上述过程，生成下一个token，如此循环；
关键在于第2步和第3步。
在第2步中，LLM会为给每一个可能的词（姑且把token这么认为）计算分数（logit），然后通过一个叫做 Softmax 的函数，将这些分数转换成概率分布。例如，假设Prompt是“今天的天气真好，我们一起去...”，LLM要预测下一个词，它计算出的原始分数（logits）和经过Softmax后的概率可能如下：
如果没有随机性，模型总是选“公园”，那每次输出都一样，会很死板。为了增加随机性，LLM使用了两个重要的参数：Temperature 和 Top-P
Temperature（温度）
温度是一个在Softmax计算之前应用的参数，它直接重塑概率分布（我个人的粗浅理解）：
概率 = Softmax(原始分数 / Temperature)低温度（如 0.1）： 除以一个很小的数，会放大高分数和低分数之间的差距；
效果：让高概率的词（如“公园”）概率更高，低概率的词（如“飞翔”）概率更低。模型输出变得更确定、保守； 在上例中，“公园”的概率可能从65%上升到95%，其他词被严重压制；
高温度（如 1.5）： 除以一个大于1的数，会缩小分数之间的差距；
效果：让概率分布变得更平缓。低概率的词（如“吃饭”、“飞翔”）机会变大了； 在上例中，“公园”的概率可能从65%降到40%，“散步”升到30%，“吃饭”升到20%，“飙车”升到10%。输出变得更多样、更有创意，但也更不稳定。
Top-P
Top-P是在Softmax计算之后应用的筛选机制，它将候选词按概率从高到低排序，然后只保留一个最小集合，使得这个集合中所有词的概率之和刚刚超过Top-P中的P（例如 p=0.9）。Top-P概要过程如下：
排序： 公园(65%)，散步(24%)，吃饭(9%)，飙车(2%)……；计算累积概率： 公园(65%)，公园+散步=89%，公园+散步+吃饭=98%（已经 > 90%）；筛选：只保留 {公园， 散步， 吃饭}。概率极低的“飙车”被剔除； 重新归一化：将这三个词的概率重新缩放，使其和为100%（例如：公园 ~66%，散步 ~25%，吃饭 ~9%）； 最后，从这个新的、筛选后的集合中进行随机采样。
由此可见，只要 Temperature > 0 或 Top-P < 1.0，模型在每一步都面临随机的结果，而一次完整的结果生成又是顺序的过程，每一步的随机选择都会影响后续步骤：
P(全文)=P(x1)⋅P(x2∣x1)⋅P(x3∣x1,x2)⋯P(xn∣x1,……,xn−1)
每一步的微小随机差异通过这个链式法则被指数级放大，导致最终结果的显著不同。
6.3.2 第二个问题
为什么相同的Prompt，不同的LLM输出结果却可能不同（即使都是国内顶流的LLM）？这主要是分词和训练参数的差异导致。
- 分词差异
LLM不是直接理解我们输入的文字内容的，它会先将文本拆分成“Token”，不同模型的分词器（Tokenizer）不同，比如“unstable”这个词，分词器A可能拆成 "un" 和 "stable"，分词器B可能直接视为一个整体 "unstable"。这导致LLM接收到的初始输入序列就不同，后续的推理计算自然也不同。
- 训练参数差异
LLM的核心是千亿甚至万亿个参数，这些参数是从大量的数据中通过训练学到的，不同的LLM其训练的过程和训练的参考数据都不尽相同。而这些参数决定了LLM如何处理上面通过“分词”得到的输入Token，并计算出我们刚才在“第一问题”中提到的那个“原始分数（logits）”。
另外，LLM的指令微调和RLHF也千差万别，这也是不同LLM的输出结果存在差异性的原因。
6.3.3 怎么解决
对于第一个问题，在调用LLM的时候，可以通过尝试调整Tempture和Top-P的值来解决（阿里云百炼的SDK支持动态设置），虽然不能完全避免它随机性导致的问题，但是可以降低发散的概率。对于第二个问题，我们采用了多个LLM对抗的方式来解决，即BadCase在识别的时候，通过两个、三个LLM执行相同的Prompt，采用统计学的方式得到最终结果（需要对LLM的执行耗时不是非常敏感）。
LLM判断为BadCase的结果示例：
{ "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进行的推理分析场景包括前文描述的BadCase识别、还有BadCase根因的归类、BadCase优化建议的产出，逻辑都比较复杂，即使我们在Prompt中特意强调了“让我们一步一步分析”等COT的方式，但是LLM也不是每次推理都能输出准确的结果。
这就涉及到LLM的思考模式问题。开启LLM的深度思考模式后（比如百炼可以通过sdk的enableThinking参数控制），与普通的“链式思考”相比，“深度思考”可以理解为启动了一个高级的、内置的“系统Prompt”，这个Prompt专门指示模型做如下事情：
问题解析与规划：不要急于回答，先彻底理解问题的核心、边界条件等； 多路径推理：构思多种解决方案或思路，并比较它们的优劣点差异； 逐步执行与验证：严格的、一步一步的执行计划，每一步都进行自我检查，确保逻辑和事实的正确性； 自我批判与修正：主动寻找自己推理中的漏洞、假设或可能错误的地方，并尝试修正它们； 最终整合：在确认推理过程没问题后，给出一个精炼、准确的最终答案；
我们在实际使用中，既在Prompt中详细描述了让LLM执行操作的步骤，同时也根据场景复杂度开启了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”，出现张冠李戴的问题（当给到LLM的prompt内容Token量少的时候，基本不会出现这个问题）。
6.5.1 为什么会这样
LLM的“记忆力”完全依赖于工作记忆（Working Memory），也就是通常说的“上下文窗口”。可以把大模型想象成一个拥有海量长期记忆（从训练数据中学到的知识）但只有极短的工作记忆（上下文窗口）的机器人，它的思考过程完全依赖于当前上下文窗口中的信息，一旦超出窗口，它就“看不见”了，而即使是窗口内的信息，处理机制也因为底层架构的注意力机制而存在局限性。
LLM底层的（Transformer）注意力机制，是通过计算所有输入Token之间的注意力权重，来决定在生成下一个Token时，应该“关注”上下文中的哪些部分（注意，这里和前文描述的输出Token逻辑不同，是指的输入处理阶段）。这个机制的内部逻辑，当上下文内容过长时会存在如下3个局限性：
- 注意力权重稀释
LLM在计算注意力时，会为上下文中的每一个Token分配一个权重，权重之和为1。随着上下文长度的增加，模型需要处理的Token数量也是同步增加，当大量不相关或低相关性的信息涌入上下文时，这些信息会瓜分掉本应属于关键信息的注意力权重，进而导致重要信息的权重被稀释。
- 缓存局限
为了高效生成，LLM会使用缓存来存储之前所有Token的中间计算结果，避免重复计算。这个缓存就是模型当前的“短期记忆”，缓存的大小是固定的，等于上下文窗口长度。当新Token进入时，最老的Token会被挤出缓存，被遗忘掉了，这就是最直接的“上下文丢失”。模型无法像人类一样有选择地将重要信息从“短期记忆”转存到“长期记忆”。
- 位置编码局限
另外，LLM需要知道每个Token在上下文序列中的绝对位置和相对位置（比如旋转位置编码RoPE），在超长上下文中，位置编码可能会失去区分度。例如，第20000个Token和第20100个Token的位置编码可能非常相似，导致模型难以精确区分它们的位置关系，从而引发上下文混淆。
上面的三点会给使用LLM时带来一些问题，可以粗略概括为上下文失效的四个场景（参考《How Long Contexts Fail》一文）：
（1）上下文冲突场景
即上下文中包含了相互矛盾的信息或指令，LLM输出混乱或偏向某一方。
- 近因效应与首因效应：
注意力机制在实践中常常表现出“近因效应”，即更关注上下文尾部信息。这是因为在训练和生成过程中，序列末尾通常与当前要预测的Token关系最直接。 同时，也存在一定的首因效应，即开头的指令（如系统提示）也占有重要权重。 近因效应和首因效应并非逻辑上的矛盾，而是注意力机制在不同力量影响下表现出的两种竞争性偏好，首因效应是“规则和背景”的守护者，近因效应是“当前和具体”的响应者。我们在上面BadCase识别场景中，发现把最重要的规则写在prompt的前面，会让LLM更加重视！
- 注意力竞争：
当两条冲突（或者不同维度）指令A和B分别位于上下文的不同位置时，模型会陷入“注意力内战”。最终的输出取决于哪条指令的综合“注意力得分”更高。这个得分受多种因素影响：
位置：末尾的指令（近因效应）通常占优。 显著性：被强调（如加粗、重复）的指令更容易获得高权重。 与查询的相关性：与当前生成任务在语义上更匹配的指令会获得更高权重。
LLM没有一个内部的“逻辑仲裁器”，它只是在做基于统计的加权平均。当两种力量势均力敌时，输出就会显得矛盾和不确定，就会出现“冲突”！
（2）上下文混淆场景
即LLM混淆了不同实体、概念或话题的来源。例如，将用户A说过的话安在用户B身上。比如上文中我们遇到的chunkId内容混淆问题就属于该场景。
- 注意力泛化：
注意力机制本质是基于相似度的。当上下文中出现多个相似实体（如多个人物、多个名称、多个相似格式的ID）时，模型在计算注意力时可能会发生“张冠李戴”。例如，在生成关于“张三说了什么”的回应时，由于“李四”的发言在语义和主题上与当前查询高度相似，模型错误地给“李四”的KV对分配了过高的权重。
- 位置编码模糊：
如前所述，在长文本中，精确的位置信息可能变得模糊。如果张三和李四的发言在位置上很接近，模型可能更难依靠微弱的位置差异来正确区分他们。
- 缺乏实体追踪：
模型没有内置的、符号化的“实体状态追踪表”。它纯粹依靠前文Token的分布来隐式地建模关系。当关系复杂时，这种隐式建模就容易出错。
（3）上下文干扰场景
即无关紧要的背景信息或之前的失败案例影响了LLM当前的表现。
注意力稀释：
见前文局限性描述
激活值的传播：
在Transformer的前向传播中，每一层的输出都是下一层的输入。无关信息会通过注意力机制和FFN层，将其“激活模式”传播到后续的计算中。即使模型试图忽略它们，这些噪音的“回声”依然存在于整个计算图中，污染了纯净信息的处理过程。
指令遵循的脆弱性：
即LLM忘记了上下文窗口开头部分的内容。
- 缓存的先进先出：
这是最直接的原因。当输入内容长度达到上下文窗口上限时，生成下一个Token时，最老的Token的缓存会被丢弃。见前文LLM局限性的描述。
- 注意力权重衰减：
即使在窗口内，随着输入内容变长，开头部分的Token获得的注意力权重也会系统性降低。大模型更倾向于关注局部的、临近的信息。因此，即使开头的Token理论上还存在，它们在功能上已经被“边缘化”了。
6.5.2 怎么解决
文章《How to Fix Your Context》针对上面的四种问题，提出了作者认为的上下文管理策略：
RAG 工具装载 上下文隔离 上下文修剪 上下文总结 上下文卸载
有兴趣的可以看下原文，我们在实践中感触比较深的是“上下文修剪”。其实整个“上下文工程”的核心，就是给LLM在合适的场景、提供的合适的内容，这个目标说起来容易，做起来难。针对在机器人对话效果评测场景中遇到的问题，我们所做和上下文相关的主要工作如下：
（1）逻辑的分拆
在设计之初，我们高估了LLM的能力，把大量复杂的逻辑写在一个Prompt中，让LLM去分析。比如在做BadCase根因归类的时候，我们把所有的根因归类及其规则描述都放在了一个Prompt中，示例：
…………## 【问题种类】：根据【用户提问】、【回答内容】、【知识粗召结果】、【知识精排结果】进行综合分析，判断当前【回答内容】视为badcase的归因类型，归因类型如下：### 精排问题（1）「类型code」：SORT_INACCURATE（2）「规则描述」：xxxxxxx### 生成时幻觉问题（1）「类型code」：GENERATE_ILLUSION（2）「规则描述」：xxxxxxx### 生成内容错误（1）「类型code」：GENERATE_WRONG（2）「规则描述」：xxxxxxx### 操作行为超出范围（1）「类型code」：NO_TOOL_MATCH（2）「规则描述」：xxxxxxx### 缺少知识（1）「类型code」：NO_KNOWLEDGE（2）「规则描述」：xxxxxxx### 用户提问没有全部得到回答（1）「类型code」：INCOMPLETE_ANSWER（2）「规则描述」：xxxxxxx…………
结合Prompt中输入的历史对话等上下文，让LLM判断当前的BadCase属于哪种根因，这个模式其实类似于Function-Call。
实际运行发现会有误判根因的情况，我们根据前文的分析做了逻辑的拆分，把每一种根因归类都单独拆出来，由一次大模型调用，改为多次调用，降低每次给LLM任务的复杂度，拆分之后的LLM识别效果要比混在一起好很多。
（2）内容精简
明确告诉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的长度。
（3）强制性的约束
我们期望LLM执行完后吐出固定的格式，就需要明确出来
# 输出规范（请严格按照标准的json格式输出!） 请严格遵循：## 直接输出纯净JSON对象，禁止包含```json等代码块标识符## 使用标准JSON格式：### 取消所有换行符，保持单行结构### 必须使用双引号### 结尾不要带多余符号## 错误示例： x ```json\n{\n...}\n``` （含代码块标识） x {'tasks': [...]} （单引号非法）## 输出必须为正确可解析的json格式(严禁多余、缺少和错误的{}和`符号和多余的json字母)# 禁止行为× 使用非工具库中的工具× 情感化表达或主观猜测× 非标准JSON格式的输出
（4）Few-Shot
在Prompt中添加适当的Few-Shot，可以有效引导大模型参考我们给出的示例、思考步骤进行推理，对于提升整体的推理准确性效果是有很大帮助的。
因为大模型已经“学会”了推理，在预训练阶段，大模型“阅读”了海量的互联网文本，其中包含了无数的数学题解、逻辑论证、计划步骤等，模型内部已经存储了如何进行推理的“知识”或“模式”。但如果没有引导，它可能不知道在当下这个时刻需要调用这种模式。而Few-Shot的示例可以作为“触发器”，引导大模型如何正确地使用它已经掌握的知识。
6.6 并发和限流
我们主要通过百炼进行LLM的调用，而且多是集中式的调用，即创建对话效果的评测任务后，就开始大量并发的方式调用LLM进行BadCase识别、根因归类和优化建议的自动生成。百炼平台上对每个LLM的调用都有流速控制，一方面是LLM调用频次的QPM限流控制，一方面是Token量的限流控制TPM，两种限流触发的异常我们在开始的阶段频繁遇到：
com.alibaba.dashscope.exception.ApiException: {"statusCode":429,"message":"Requests rate limit exceeded, please try again later.","code":"Throttling.RateQuota","isJson":true,"requestId":"********"}com.alibaba.dashscope.exception.ApiException: {"statusCode":429,"message":"Allocated quota exceeded, please increase your quota limit.","code":"Throttling.AllocationQuota","isJson":true,"requestId":"********"}对于QPM的限流，我们只有控制线程调用的并发数。同时我们观察到，当并发调用大的时候，即使还没达到限流的阈值，也会影响并发调用LLM的响应速度，甚至几十秒才返回结果，虽然可以改为LLM流式的输出，但是对我们的场景而言，是需要获取到完整的结果才能知晓对错。
对于TPM的限流，不仅是输入的Token会有影响，如果开启了思考模式，输出的时候思考过程数据的输出，也会占用TPM的阈值，输出Token量可以通过max_tokens的参数来进行限制。
6.7 中断及恢复
运营Agent执行的效果评测的任务，是需要长时间运行的，每一个任务都包含了很多服务记录的检测，每一条服务记录又包含多个阶段的逻辑处理。
如果遇到服务重启或者其他原因，运行中的任务就会被中断。这种异常的中断，会影响使用体验，因为是长时间运行的任务，当用户察觉到异常时已经滞后了，重新开始运行又要耗费大量时间，更不要说LLM的重复调用（Token的浪费）。
我们设计了一套任务的checkpoint机制，在避免频繁扫表（DB）的情况下，可以主动发现异常中断的任务、并且会自动根据当前中断的阶段进行重新运行，并不会盲目的全部从“初始化阶段”开始。
核心思路就是每个阶段运行的时候，该阶段中每条服务记录在做逻辑处理时都会上报心跳，更新该对应任务的最新状态，定时任务会轮询当前超期的任务，将未开始、失败的服务记录进行重新该阶段逻辑的执行。
七、效果
一些指标性的结果在前面第4小节中已经做了概要的描述（BadCase发现的准确率85%+、根因归类和优化建议生成的准确率80%+等）。
找出BadCase的根因只是第一步，更进一步的事情是如何解决？
有些根因是需要运营协作才能解决，比如转人工策略的优化等。
举例，客户多次询问类似问题，并且有情绪化的表达，但是没有触发转人工，运营Agent可以提取出此类场景，给出优化建议（如下样例）到运营同学参考：
通过对内容的分析，客户在历史对话中已多次表达转人工诉求（共4次提及），且当前问题仍聚焦于会员卡退卡处理。机器人客服在对话中未有效解决客户诉求，针对退卡问题未提供实质性解决方案，反而在回答中持续引导购买季卡等无关信息，导致客户情绪升级并反复强调转人工需求，符合反复追问强调、客服未有效回答及强烈转人工诉求三个场景。需优化服务策略以提升响应有效性。
有些根因需要技术协作才能解决，比如生成内容的prompt优化等。
举例1，客户咨询了多个问题，而机器人只回答了其中的一个问题，会被识别为“回答内容不完整根因”，该根因需要技术协助才能解决，运营Agent给出优化建议（如下样例）到技术同学：
通过对内容的分析，客户问题包含「退款申请」和「扣款原因咨询」两个诉求，场景为「退款咨询场景」。客服回答内容包含「自动续费订单退费登记」和「会员卡退款申请流程」，对应「退款操作指引场景」和「自动续费场景」。虽然客服回答覆盖了退款操作路径，但未对客户提出的「扣款原因咨询」诉求作出任何解释，也未明确说明扣款依据或提供查询渠道。因此客服回答未解决客户全部诉求，标记为回答不完整。
举例2，我们在一次运营Agent任务结果中发现BadCase的会话量突然暴增，如下图：
而这其中大部分的BadCase的根因都是属于“回答内容不完整”，经过和对话Agent的同学一起分析后，发现是某链路的Prompt的内容有调整，一条比较重要的规则调整到了Prompt的后面，导致LLM识别出现了偏差（见本文前面“上下文工程”中描述的“近因效应”），经过重新调整Prompt内容后，对话效果得到了恢复：
还有一些场景，运营Agent可以直接给出优化建议：
如“粗召遗漏问题根因”、“精排遗漏问题根因”等，这些根因我们可以理解为和Query相关的内容确实已经存在于知识库中了，但是召回的时候因为相似度等原因导致在最后的环节没有被用上，我们给出的优化建议一般是给强关联的候选分片增加“相似问”，可以自动入库生效，也可以运营审核之后入库生效。
举例，给符合意图的知识分片增加相似问内容，如下：
{"客户": "麻烦看一下我的连续包月后续每个月多少钱","机器人": "请问您是想咨询关于连续包月的什么问题呢？"}根因归类：粗召遗漏问题根因归类描述：分片标题为【一、卡种介绍, 1.1通用卡, 1.1.2自动续费】的分片，在问答链路的粗召环节没有被召回，其内容和用户意图强相关优化建议：增加相似问优化建议内容：如何查看自动续费的下次扣费金额
又例如“缺少知识”等根因，运营Agent会根据当前服务记录的上下文和客户意图，自动从互联网检索相关知识，并且对检索到的知识内容进行二次校验，将高度匹配的内容抽取成知识自动入库，或者运营审核之后入库（但是客服场景，从互联网抓取到高匹配内容的概率还是比较小，绝大部分情况都是运营Agent把意图和业务场景提供出来，让运营同学手动补充相关知识）。 运营Agent也间接推动了知识Agent的逻辑优化。我们在最开始执行“增加相似问”优化建议的时候，发现即使给对应知识分片添加了符合预期的由运营Agent产出的“相似问”内容，在进行二次Check优化建议是否生效的时候，仍然无法将对应的分片内容召回。通过和知识Agent的同学一起分析后，发现之前RAG在做融合召回的时候，而相似问作为检索条件只用在了兜底处理的逻辑中，即只有当向量化（标题、正文的向量化）召回的数量，达不到设定的阈值时才会使用搜索引擎召回作为补充，这个设计存在一定的漏召场景。后面优化RAG逻辑，将相似问内容也纳入到向量化（标题、正文、相似问）和搜索引擎（标题、正文、相似问）的多路召回逻辑中，才解决了这个问题。
八、还能做什么
如果将关注点从BadCase的粒度放大到整个服务链路，AI还能做什么？
从服务爬坡阶段（非初始化冷启动）的提效（满意度、服务成本等）角度来看，一般期望通过机器人承担更多的客户服务，减少人工服务，只有机器人服务不了的，才通过转人工服务来兜底承接。量化这个“期望的效果”一般有两个指标，机器人回答准确率、机器人解决率。
- 机器人回答准确率
准确，一般指机器人的回答内容是否符合预期；
- 机器人回答解决率
解决，一般指机器人回答的内容，解决了客户的咨询问题；
但是准确率其实并不等于解决率，即使机器人按照运营（业务）的要求吐出了符合预期的回答内容，但是并不一定能解决客户的问题，客户还是要转人工；而机器人即使没有吐出预期的答案，比如用词不是很恰当、引用的参考知识不全等，但是客户觉得ok，能解决他的问题；更有甚者，客户因为个人心智原因，一接通就转人工，不给机器人回答的机会。
一通转人工的服务（转人工，就视为机器人服务未解决客户问题）具体是哪方面原因导致的？我们利用AI建设了服务分析的能力，帮助运营同学可以从三个方面来分析其原因：
（1）服务策略的配置导致触发转人工
运营人员可以配置拦截策略，命中策略的客户咨询内容，会中断机器人服务，触发转人工请求。如果一段时间内，忽然有大量的转人工请求出现，也可能是因为某个策略异常变动导致，运营Agent也可以发挥能力，做到自动分析识别。
同时结合复访的数据和6.2.1小节中描述的“业务品类”、“业务场景”等信息，以及人工服务阶段的对话内容，利用LLM分析出复访客户的归属场景，如果某个场景有异动，就可以进一步定位具体原因。
（2）客户心智问题
用户心智导致的转人工，比如客户不说话，或者只表达“转人工”等内容，属于心智问题。这种场景机器人服务阶段很难做功，它间接决定了“解决率”的上限。
不过，仍然可以根据“是否复访”拆解出有多少是之前没有服务好、导致本次服务客户一接通就想转人工。
另外可以结合用户的个人最近的订单记录、咨询记录，以及当前整体Top的问题，把“猜问”进一步个性化，理论上也可以起到正向的效果。
（3）机器人的回答内容不能解决客户问题
机器人按照预期提出了回答内容，但是客户仍然触发了转人工，运营Agent需要深度分析这种场景。
它可能是机器人问答链路的问题导致，结合前文大篇幅描述的对话效果评测内容；也可能是机器人覆盖范围受限制导致，需要利用LLM，结合机器人服务对话内容和人工服务对话内容，分析出机器人给的方案和人工服务阶段给的方案的差异性，根据进一步下钻的分析调整机器人所能服务的覆盖业务、知识内容等。
也可能是业务本身的异动，如大促活动等。
九、总结
在客服运营领域，AI能力的加持，可以细粒度的进行机器人服务对话效果的全链路评测分析，给机器人对话能力、知识能力带来正向反馈；也可以站在更加宏观的视角，综合业务数据、人工服务对话数据等，给机器人服务解决率的提升带来参考方向。
