背景介绍
客服介绍
FAQ：Frequent Asked Question，问答咨询场景。
任务型：对话形式完成任务，例如取消订单、开发票等。
AI客服：利用人工智能技术，为客户提供交互式服务的智能客服系统，主要目的是提高客户服务效率和质量，同时降低企业的运营成本。选车助手是AI客服咨询中的一个子场景。
选车助手概况
上下滑动查看更多
存在问题
1. 只能收集预设的类别，货物信息不足导致推荐不准确
2. 点选方式收集，交互方式不灵活，不支持复杂表达
3. 回复冗长，缺乏拟人化能力
4. 咨询主流程外问题，机器人持续识别错误，体验差
技术背景
– 目前主流商业方案，都是重可控性，轻灵活性，需要客服先配置复杂冗长的流程图和规则，系统严格根据配置执行，导致用戶体验差，转人工率高，增加客服成本。
– 在过去的一年中，大模型技术飞速发展，正在掀起一场技术革命，基于大模型的智能体表现出实现通用人工智能（AGI）的巨大潜力。同时，货拉拉内部也成功自研了货运大模型。
系统框架
下面是整个选车助手服务的系统架构
图1 客服选车助手系统框架图
服务的系统架构从上到下分为以下几层：
交互层：与用户交互的渠道，包含web、app、小程序等。
应用层：服务相关应用，包含IM后台、websoket网关系统。
逻辑层：对会话进行管理，由DM对话机器人系统控制。
算法层：核心服务层，包含Multi-Agent框架，以及内部机器学习平台（海豚平台）进行模型的管理、发布。
算法方案
经过线上数据分析，我们发现用户在使用选车助手的过程中，行为不受控制，并不只会根据流程引导来进行答复，用户还会在沟通过程中询问其他信息，如：
FAQ
– “平台上有优惠券提供吗？”
– “货拉拉都有哪些车型可以选择？”
闲聊
– “今天天气怎么样？”
– “你是美女客服吗？”
如何通过流程引导，将对话主动拉回到主流程也是我们面临的一个难点。此外，用户需要运送的货物多种多样，用户对于货物信息的表达方式也多种多样，导致语义理解困难，这也加大了我们解决问题的难度。
针对上面提到的现状和问题，我们结合大模型来进行客服方向的探索，使用大模型的优势如下：
LLM-based多智能体系统
为了在项目中使用Agent的能力，同时让LLM Agent更可控，本项目通过使用SOP来对任务进行分解，实现对Agent的细粒度控制，并且更容易落地实现。
图2 LLM-based多智能体系统图
使用单一智能体难以完成复杂的任务，因此使用NLG Agent和NLU Agent两个智能体，NLG Agent负责问题回答、工具调用、流程引导，NLU Agent负责对货物信息进行提取。
NLG Agent
当NLG Agent接收到用户的query输入后，首先会对用户的query进行思考，判断用户的query类型，再根据不同的类型执行不同的action，图3为一个示例。除用户的输入query外，NLG Agent还会与Memory，Tools和NLU Agent产生交互。
图3 NLG Agent示例
Memory
图4 Memory模块图
Memory模块储存先验知识，包含通用知识库、FAQs和长短记忆三块。
通用知识库
能够在用户提供某些货物名称后自动补全货物信息，辅助推荐车型。如用户需要运输电动车，电动车尺寸、重量较为固定，不需要继续询问详细货物信息即可根据先验知识补全。
FAQs
当NLG Agent检测到用户在询问FAQ问题时，提供正确FAQ答案回复用户。如用户需要联系热线客服，就向用户提供客服电话。
长短记忆
存储对话历史信息，进而控制NLG Agent的行为，从而更好的和用户、工具、NLU Agent进行交互。
Tools
图5 Tools模块图
Tools模块负责与外部工具进行交互，包含车型推荐接口、敏感词过滤接口、业务SOP以及流程引导模块。
车型推荐接口
根据NLU Agent收集到的货物信息，准确推荐车型。
敏感词过滤接口
对会话中涉及的敏感词进行过滤，防止出现安全问题。
业务SOP
根据业务流程不同，指导会话进行，防止长时间停留在闲聊等阶段。
流程引导
NLG Agent根据各个模块收集到的信息，判断下一步操作（回复FAQ问题、收集货物信息和推荐车型等），对用户进行流程引导。
NLU Agent
客服选车助手的主要任务就是根据用户提供的货物信息准确地推荐车型，因此，就需要对货物的尺寸、重量、运输方式等信息进行收集。然而用户的表达复杂多变，在对话过程中往往存在以下几种情况：
提供单个货物的部分信息
“我要拉一个箱子，长1米”
需要运输多个相同货物，但只提供了单个货物信息
“我要拉20个1m*1m*1m的箱子”
需要运输多个不同货物，但只提供了某个货物信息
“我要拉1.8m的床和冰箱”
表示不清楚货物具体信息
“长1.8m，重量不清楚”
如何准确提取用户提供的货物信息就成了我们面临的难点和重点，NLU Agent就主要负责对用户对话中提及的货物信息进行提取。经典的NLU方法通过命名实体识别（NER）的方式，对货物信息进行提取，需要标注样本进行训练，需要耗费的时间周期长，且存在大量实体嵌套问题，导致效果不佳。
因此，我们使用自研货运大模型进行尝试，最初的Baseline在内部测试集上只有50%的准确率，经过prompt调优，最好的一组也只能达到60%的准确率。经过bad case分析，我们发现模型对某些相似表述的识别效果较差，如“不清楚多重”、“外机700×400×500”等。为了进一步提高货物信息识别的准确率，我们尝试检索增强生成（RAG）技术来帮助模型认识上述bad case。
图6 RAG基本流程图
我们在召回部分采用多路召回的方式，主要使用向量召回和货物名称召回等方式来生成候选集，再对候选集进行排序取top10结果作为上下文传入货运大模型。
向量召回
用于召回相似表述的query，该类数据常常会包含一些隐藏的常识信息，不在query中直接表示，如“1.5长 70cm高 74宽”，用户没有将单位完整表述，根据常识可知货物信息为“长：1.5米，宽：74厘米，高：70厘米”。
货物名称召回
用于召回相同货物名称的query，该类数据有具体的货物名称，同类的货物有相似的货物信息特点，如“你好，那个微面的货车能拉60寸的液晶电视吗”，用户在描述电视大小时常用尺寸表达，可知货物信息为“名称：电视，尺寸：60寸”。
经过多路召回RAG后，我们将货物信息识别的准确率提升至80%。
此外，在第n轮对话中，添加上下文（context）也就是n-1轮对话时收集的货物信息作为参考，对模型效果也有大幅的提升。我们还发现对话中一些复杂表述比较固定，而这部分表述模型提取效果一般，我们就加入了一些规则（rules）处理来提升模型效果。最终，我们在内部测试集上的货物信息识别准确率达到90%。
表1 迭代效果对比展示
效果展示
示例1
上下滑动查看更多
效果分析
1. 流程引导：回答用户问题后，继续返回主流程
2. 拟人化回复：基于全局的信息理解，回复精简拟人化
3. 上下文理解：用户纠正货物信息后，更正推荐车型
示例2
上下滑动查看更多
效果分析
1. 多物品信息理解
2. 具备常识
– 对七十寸的电视机不再询问重量，可以自动计算
– 桌子的重量不清楚，模型会自动推理获取
总结展望
本文阐述了大模型在货拉拉业务中的实践，针对遇到的问题与挑战，我们结合货拉拉内部自研的货运大模型的能力，采用了多智能体的形式，成功实现了基于LLM的AI客服选车助手。未来，我们将持续关注技术优化迭代升级，将大模型能力推广到更多的应用场景中。
