从毕业参加工作至今，一直从事AI相关的项目，更是一直深耕在智能客服领域，今天想记录一下自己对智能客服的一些总结和想法，也可作为反思。
今天重点讨论文本类的智能客服，不涉及语音助手类的客服机器人，其实工作原理是一致的（文本类的智能客服不包含ATR和TTS两个模块，但是和语音助手核心的处理逻辑是一致的）。
为什么要做智能客服？它的作用和价值是什么？
场景一：企业/人工客服：降本增效，工具替代人力
你开了一家淘宝店，生意非常好，而且又正值618大促，这时你为了更好的提高营业额（购买转化），维系好忠实客户（客户粘性），处理好不满意的客户使之成为忠实客户（促活留存）你需要随时陪伴客户，解答客户各类问题。但是人的精力总是有限的，此时你肯定想复制十个百个自己来陪伴客户，这时智能客服可以帮助或者辅助你解决上面遇到的问题，回答客户从售前（询问商品是否有折扣啊；商品是否包邮啊）、售中（询问商品物流；能否更换收货地点）、售后（询问收到的物品有损耗，该怎么处理啊；商品合适如何退款退货啊）的各类问题。
场景二：客户：快速消除疑惑，快速解决问题
当客户服务体验不完美或遇到待解决的问题时，此时会希望有人能快速消除疑惑，能帮助客户快速高效的解决问题，提升服务体验。
智能客服场景描述
用户会通过在线打字寻求服务，当用户进入到智能客服服务页面后，先是用户表达需求，然后是智能客服响应需求，过程中机器人先要理解问题，比如如何修改密码、如何购买某某增值服务等等，继而机器人尝试自助解决。如果解决不了，再及时地流转到人工进行兜底服务。最后，当用户离开服务时，系统会发送一系列的反馈动作，评判是否真正解决问题。
对话交互技术概述
按场景来划分，智能客服常见的对话方式分为：
闲聊型、任务型、问答型、混合型
按技术实现的方式来划分，智能客服常见的对话方式分为：
智能客服主要是以混合型（任务型+问答型）的方式进行实际的应用，通常是基于pipeline（在大模型能力崛起后，将大模型应用在智能客服领域后学术上又称为Agent，其实我个人理解两者没有任何差别，Agent核心思想就是pipeline）的方式进行构建，具体为：
自然语言理解（NLU）、对话状态追踪（DST）及对话策略（DPL）合称为对话管理（DM），以及自然语言生成（NLG）
随着大模型能力的崛起前，越来越多企业开始利用LLM能力来构建智能客服，下面我将通过传统的技术方案和基于LLM的方案谈谈如何构建任务型智能客服。
智能客服对话时的流程：
以一个外卖行业智能客服为例，当用户进入到咨询服务门户或平台后，先选择了一个推荐的问题“如何联系外卖骑手”【意图识别/问题理解】，机器人给出了联系方式致电骑手。同时为了进一步厘清场景，询问用户是否收到了餐品，当用户选择“还没有收到”的时候，结合预计送达时间和当前时间（API接口）【对话管理，预设TaskFlow】，发现还未超时，给出的方案是“好的，帮用户催一下”，或者是“我再等等吧”，这时候用户选择了“我再等等吧”。【答案生成】
这个例子背后智能客服是怎么工作的呢？首先当用户输入query“如何联系骑手”的时候，问题理解模块将识别用户意图。然后对话管理模块根据意图“如何联系骑手”触发相应的任务流程，先查询订单接口，获取骑手电话号码，进而输出对话状态给到对话策略用于答案生成模块，根据预设好的流程，模板生成最终结果，在这个过程中涉及到要先有意图体系、定义好Task流程，以及订单的查询接口，这些都是业务强相关的，主要由各业务的运营团队来维护。那么，对话系统要做的是什么呢？一是将用户的输入与意图体系中的标准问进行匹配识别出问句的意图，二是完成多轮交互里面的调度。
问题理解（NLU 模块）
NLU 模块是对话系统的关键部分，它负责解析用户的输入并识别出用户的意图和相关实体（即动作）。
解析用户的问题，明确用户问题的意图是什么，类比人与人之间沟通，为了能更通畅的交流，我们需要理解对方对话时的句子含义，知道问题的意图后，还需要知道问题的关键信息，因为只要了解问题的关键信息后才能针对性的沟通和回复。
另外，为了更好的理解意图和响应问题，一般在意图识别前会有一个顶级的的意图识别（或称为领域识别），在实际的意图分类任务中，不同意图之间可能存在从属关系，既可能是显式的层级关系，也可能是隐式的语义关联。例如 "查实时天气"，"查未来天气" 都属于更广义的 查天气" 意图的子类，它们之间存在着明确的层级从属关系。会出现意图混淆的情况。如果待分类的意图中存在层次关系，我们可以采用分层式的模型架构，先对更广义的大类意图进行分类，再细化到具体的子类意图上。另外考虑到响应的及时性及性能关系，通过最上游的领域识别可以路由到不同的任务上，而不是一股脑的进行判断，提高模型的响应速度。
针对问题理解，传统方案一般分为两种方案，一种是通过有监督学习的方式构建模型，另一种方式是通过检索匹配的方式。
问题理解是对话系统的核心，用于理解用户的需求，它需要从用户的消息和上下文中提取出至少以下两个信息：
用户意图 (Intent) ，指的是用户语句背后的目的和需求，如查询天气、预订机票等。正确识别用户意图对于系统给出恰当响应至关重要。
槽位 (Slot) ，指包含在用户语句中的某些关键信息单元，如时间、地点等，是完成用户需求所必需的补充信息。
基于有监督学习的方式构建具体包含两种方式：一种是解耦的方式训练两个模型，即领域分类模型+意图/实体联合模型，另一种是训练一个三元组模型，即一个模型就能输出（领域、意图、实体）三个重要信息。
训练时需要注意：
构建高质量、全面覆盖各类意图场景的数据集
保持训练数据的平衡和选择合适的模型
我们需要采取有效措施来平衡不同意图类别的样本分布。常用的方法包括对小样本意图类别进行过采样，对大样本意图类别进行欠采样，以及在损失函数中赋予不同权重等。通过这些措施，可以减小不同意图类别之间的样本数量差异，提高模型对小样本意图的识别能力，从而获得更加均衡、稳定的意图分类模型。
意图识别和槽位提取两个任务可采用联合模型同时完成，也可选择独立的序列分类和序列标注模型分别优化每个子任务的性能。针对意图分类和槽位提取任务，其目标都是将自然语言输入映射到意图类别标签或序列标注的槽位标记上。当然，因为这两个任务之间密切相关，也可以采用 Joint 模型同时完成（例如 JointBert），利用联合学习的方式让两者相互约束和辅助、捕捉语义关联。相较于基于大模型的方案，这类方案能够额外输出置信度信息，通过设置置信度阈值以及通过人机交互机制确认低置信度结果，NLU 的稳健性得到了进一步提高。
通过检索匹配的方式：通过检索的方式指利用提前准备好的意图知识体系进行匹配，最终输出意图，通常将用户的query与知识库中的拓展问进行匹配，进而得到对应的标准问即意图。
这里的方案实际是要做召回和精排两件事情。召回更多地是用现有检索引擎实现，技术上更多地关注精排。在BERT未出现之前，常用的模型是DSSM，BERT出现后会利用其框架训练出一个基于双塔结构的相似句模型，另外还可在此基础上可通过多任务学习（各业务在上层为独立任务）以及多域学习（Query与拓展问匹配，改为与拓展问、标准问和答案的整体匹配）的方式进行优化。
基于LLM的NLU方案
利用 LLM 直接执行 NLU 任务是一种先进而高效的方法。通过设计恰当的Prompt，能够直接让 LLM 完成意图识别和关键信息提取，无需对大量特定领域数据进行微调。这种做法可以最大限度利用 LLM 广博的知识，提高对话理解的整体水平。如需融入更多领域知识，可采用 RAG技术，根据用户查询从知识库中检索相关文本作为辅助信息提供给LLM。这种架构使 NLU 模块能够从相关的上下文中更深入的理解意图，从而增强对话智能。相比传统的数据驱动方法，基于 LLM 的 NLU 范式更高效灵活，能快速在多个场景 (如智能家居、客服等) 间迁移和复用。
<Persona>你是一个用户意图分类器，你需要返回给定的用户文本的分类结果，分类候选包括[开灯，开空调]<Retrieved shots>天黑了 -> 开灯天好热 -> 开空调<Instruction>热死了 ->
对话管理 （ 对话状态追踪（DST）及对话策略（DPL））
理解了用户意图后，有些问题是可以直接给出答案解决的，而有些问题则需要进一步厘清。比如说“如何申请餐损”这个例子，不是直接告诉申请的方法，而是先厘清是哪一个订单，是否影响食用，进而厘清一些用户的诉求是部分退款还是想安排补送，从而给出不同的解决方案。这样的一个流程是跟业务强相关的，需要由业务的运营团队来进行定义。
对话状态跟踪模块需要结合历史数据和当前输入更新成最新的对话状态，这个环节需要注意的是：
指代消解
在多轮对话过程中，人们常常在下文采用简称或代称来代替上文已经出现的某一词语。
如：
人称代词：【李明】怕高妈妈一人呆在家里寂寞，【他】便将家里的电视搬了过来。
指示代词：【很多人都想创造一个美好的世界留给孩子】，【这】可以理解，但不完全正确
有定描述：【贸易制裁】似乎成了【美国政府在对华关系中惯用的大棒】。然而，这【大棒】果真如美国政府所希望的那样灵验吗？
指代消解：形式上，将代表同一实体的不同指称划分到一个等价集合（指代链）的过程称为指代消解。指代消解能够有效解决文本当中的指代不明问题，是NLP领域一项基础性研究，在机器阅读理解，信息抽取，多轮对话等任务中都起到重要作用
传统的对话管理模块
通过当前当前状态的更新+有限状态机的方式进行规则设计，通过预先设计好的taskflow完成对应的多轮对话。
如上示图，在这种情况下，有限状态自动机中每一个对话状态S表示一种系统动作，本例中系统动作共有3种，分别是两种问询动作：“询问时间”（Ask Date）和“询问地点”（Ask Location），以及最后的系统回复“回答天气”（Answer）动作。有限状态自动机中状态的迁移则是由槽位的状态变化，即“用户动作”引起的。
基于LLM的对话管理Agent
利用prompt+工具+api+RAG的方式
基于构建多个Agent的方式可实现多轮对话管理，LLM根据对话状态和用户意图为系统分配合理的行为策略 (Action)。提高系统的适应性和智能化水平。可以设计了多种策略以应对不同情况
对话终止策略，通过综合分析用户意图、任务状态等多个维度的信息，对话终止策略判断是否需要结束当前对话。例如用户长时间无响应、明确表达结束意图或关闭对话界面等，均可视为终止对话的触发条件。合理的终止策略可以避免不必要的冗长交互，提升用户体验。
对话转移策略，当前对话 Agent 无法完全解决用户问题时，对话转移策略将决定是否需要将对话转移给其他 Agent 或人工客服。这需要 Policy 模块能够准确评估当前 Agent 的能力边界，并作出合理的转移决策,从而为用户提供更完整的解决方案。
追问槽位策略，追踪并补全对话中遗漏的关键槽位信息是槽位追踪策略的核心职责。该策略需要基于 NLU 模块的理解结果，通过巧妙设计的提示语引导用户补充遗漏的槽位，以确保获取任务所需的全部信息。优秀的追踪策略可显著提高任务完成率。假设用户想要订购外卖，但未提供送餐地址这一关键槽位信息。对话 Agent 可以根据槽位追踪策略生成 Prompt 进行追问。
意图和槽位确认策略，为应对 NLU 模块中存在的不确定性，需要引入意图和槽位确认策略。当模型对用户意图或提取的槽位的置信度较低时，该策略会发起与用户确认的文本回复，以保证对话 Agent 正确理解语义，从而提高对话质量。确认策略需要合理计算置信度阈值，并设计自然的确认交互方式。
触发下游动作策略，触发下游行为策略旨在根据特定的对话状态、用户意图等条件，为 Agent 分配合适的下游行为，如向后端系统发起请求、生成特定响应、执行一系列复杂操作等。通过明确的策略规则，可确保 Agent 及时执行正确的下游行为，提高系统效率。
额外补充一下关于RAG相关的设计
LLM崛起之后在实际的落地应用中并不能直接拿来使用，因为LLM无法解决时效性和领域性的问题，因此会对LLM进行一系列的优化，其中RAG是常用而高效的解决方式。
延伸到智能客服领域，基于LLM的方案中RAG 是对话 Agent 中重要的生成模块，通过结合检索和生成的方式，实现更智能、个性化的回复。在应用中，有以下关键点：
选择合适的 Embedding 模型，如果是对话的场景是通用领域，可使用预训练好的 Embedding 模型，如在多语言场景下表现较好的 E5 系列模型，在中文场景下表现不俗的 BGE 系列模型等。它们能提供不错的语义表征能力。在检索任务中，我们主要关注模型在 Pair Classification 维度上的得分，即给定模型输入，模型将输入相关的内容全部检索出来的能力。如果对话场景是特定领域（例如对话中涉及较多的行业黑话或专业名词），建议在预训练模型的基础上进行进一步微调，以更好地捕捉领域特征。我们需要准备高质量的领域语料（Monologue 或 Dialogue ），对 Embedding 模型进行微调。
权衡检索召回率与准确率，如果模型分析和推理能力很强，可以适当的降低相似度阈值，将可能与用户问题相关的内容全部检索到并放入 Prompt 中交给大模型来分析具体什么内容可以参考，什么内容与用户的问题相关；但相对而言，如果基础大模型的分析能力不够强，这时候就需要尽量提高相似度阈值，过滤掉容易干扰模型分析思考的内容，进而降低模型出现幻觉的概率。
优化用于检索的 Query，这一点至关重要，因为这里需要根据当前的query去检索相关的知识，这里不仅仅是在对话管理中记录和跟新对话状态，而且根据当前query再结合历史对话生成一个新的富含所有信息的query，在多轮对话的场景中，用户当前轮的消息可能会存在缺少主语导致检索内容不完整的情况。而如果单纯将多轮消息直接拼接用于检索内容，又会降低检索内容的准确率，两种情况都会影响 LLM 最终回复内容的准确性。这里可以引入一个多轮转写模型，将用户的对话历史输入到模型，模型能够自动补齐当前用户消息中的主语，忽略掉与当前轮用户消息无关的信息。
对话生成（NLG)
传统的对话生成
主要是基于固定的对话模板，拿到对话的全部信息后给到答案生成模块，根据模板生成最终结果，传统的对话生成输出的答案无论从个性化和风格都比较固定和单一。
基于LLM的对话生成
在实现文本回复时，强调回复的正确性、自然性以及用户体验。
基于LLM应用时需要关注以下两个方面：
合理定义 Agent 个性和角色，为对话 Agent 设计鲜明个性和身份认同至关重要。这需要根据应用场景量身定制。例如，在客户服务中，Agent 应展现同情心和专业性，以缓解用户不满并树立信任；在智能助手中，Agent 应表现高效和灵活，快速解决问题和处理复杂任务；在教育领域，Agent 需要耐心、严谨和权威，引导学生探索新知识；在娱乐领域，Agent 应诙谐幽默、活泼生动，提供有趣的体验。合理的人格设计不仅增强 Agent 的身份认同感，还为用户提供更沉浸和契合的对话体验，提升友好度和接受度。需要注意的是，设计时应避免过度夸张或不当设定。
平衡回复的拟人性和模型幻觉（Hallucinations），大规模语言模型（LLM）使 Agent 的语言表达更拟人化和自然，但也带来生成幻觉的风险。在任务导向的场景中，回复时需在避免幻觉和保持拟人性之间取得平衡，尤其是在使用推理能力较弱的小参数模型时。如果提示词过于复杂（即指令中包含大量需要大模型分析和推理的内容），需特别注意防范模型幻觉的发生。
智能调用功能的设计范式
智能调用功能是任务型对话 Agent 与外界交互的重要模块，负责将用户意图和槽位值转化为具体操作，以满足用户需求。为了实现高效准确的智能调用，我们需要关注以下两个设计范式：
意图与行为的映射
在智能调用过程中，需要将识别出的意图和槽位值映射到后端系统中的具体操作。这通常需要构建一个意图-操作的映射表，并为每个槽位值确定相应的参数。例如，如果用户的意图是“预订酒店”，映射表应指明该意图对应的操作是调用酒店预订系统，而槽位值如“日期”和“房间类型”等作为调用参数。
槽位标准化
用户提供的槽位值常使用非标准或口语化表达，如“三块五毛”、“九月十五号”等。对于这些简单的数字、日期等槽位值，可以通过同义词词典或正则表达式进行标准化替换。然而，在复杂业务场景下，用户可能使用功能名称的简称或描述性句子表达需求，此时词典和正则表达式显得不足。需要引入模糊搜索算法和接口来支持这些复杂槽位值的标准化处理。
E2E的任务型智能客服
上面讲到的方案都是基于pipeline的方式来构建智能客服，随着LLM能力的发展，利用LLM的能力构建基于E2E的任务型智能客服一定会得到快速的应用和发展。
基于E2E的任务型智能客服需要基于数据驱动来fine-tuning，因此模型训练的数据集是核心而关键的一步，在LLM能力未挖掘前主要还停留在以学术研究为主，未见成熟的应用案例，但是现在拥有了LLM能力以后，LLM 在这一过程中扮演了至关重要的角色。可以利用 LLM 的强大生成能力来模拟用户的提问和系统的追问，生成接近真实对话的训练数据。我相信在未来E2E的任务型智能客服会有质的飞跃。
通过模拟用户的对话并结合 LLM 的能力来构建训练数据集；最后通过微调构建任务型对话 Agent。该方案允许用户快速创建出能够精准调用外部工具的 Agent。
构建训练集主要考虑如下几点：
包含用户的所有行为，训练集中应该包含所有智能客服可能需要处理的任何回答，例如，考虑一个酒店预订任务，可能的关键信息包括「入住日期」、「退房日期」 和 「房间类型」。构建训练集时需要考虑缺少不同关键信息时智能客服应该怎么回答的所有情况，这样不仅增加了对话样本的多样性，也使得训练数据集更加贴近真实世界的对话情况。
对上下文理解能力，在实际对话中，用户通常不会在每个回合都重复提供所有相关信息。相反，他们会根据上下文，利用代词、省略或简化的表述来替代之前已经提及过的内容。为了让对话系统能够正确理解这种上下文依赖的表达方式，我们需要在训练数据中构建这类训练数据。
