简介本文介绍了如何通过Dify平台构建一个多领域AI客服系统以解决传统AI客服在复杂业务场景中回答不准确的问题。该系统将客服模块按售前、售后和日常业务划分利用Dify的API进行集成和调用并通过知识库提供上下文支持确保精准回应。架构设计中首先部署Dify创建并配置AI应用编写提示词管理知识库封装API接口实现问题分类与转发逻辑。最终通过日志记录测试过程验证系统的有效性。此方案适用于希望提升AI客服效果的企业。一、引子AI客服的概念早已不再新鲜随着自然语言处理技术的不断进步越来越多的企业尝试将 AI 客服引入实际业务中。然而尽管大模型具备强大的语言理解能力受限于业务场景的复杂性和大模型自身的局限性AI 客服在许多企业中的应用落地效果并不理想。尤其是在面对多领域、多场景的客户需求时单一的 AI 模型往往难以提供精准且符合上下文的回答进而影响了用户体验和企业的运营效率。二、业务梳理业务场景的多样性使得客户问题不仅限于某一个方面。客户可能会询问产品信息售前、订单和退换货等服务售后以及公司政策或流程等日常事务业务支持。面对这些高度垂直化的需求传统的 AI 客服难以兼顾各个领域导致服务体验割裂、回答不准确。为了解决这一问题我们采用了一种更为灵活的方式将客服系统按照业务维度进行划分拆解为多个专门负责不同领域的 AI 客服模块。比如可以按照问题类型分别构建售前、售后和日常业务三大问题领域的AI客服对于用户发送的问题首先通过一个中转服务利用AI进行判断属于那个领域的问题再转发到适配的客服。三、架构设计在本次的设计中我们需要用到一个平台 - Dify我们通过它去连接大模型可以单独部署AI应用这样在项目里只需要封装API进行调用即可把业务系统与AI应用进行解耦。因此我们可以抽象出业务架构图如下过架构图可以看出我们这个系统需要4个AI应用来支持,每个应用的开发和维护都通过Dify进行我们的业务系统直接调用即可。四、技术实现部署Dify本文对Dify的部署不予演示感兴趣的同学直接去官网下载即可部署非常简单通过docker可以一键部署。创建应用接下来开始创建AI应用应用开发的重点在提示词的编写。我们先以判断客户需求的AI客服为例如下提示词如下提示词编写完成后可以在右侧测试效果同时记得点击发布如下同理另外三个业务客服都采用上述方式创建。这里我以业务客服为例给大家展示下提示词如下可以看到提示词里提到了知识库知识库简单地说可以为AI提供一些上下文比如我们客服的场景里就可以把相关客服的培训手册提供给应用。我们可以通过Dify直接管理知识库也可以通过API操作我们这里方便管理直接上传即可。如下我们可以在知识库里可以直接创建如下可以看到知识库文本的格式支持很广泛如下我这里为了方便演示就直接建一个客服中心的word文档输入以下内容如下数据的清洗和分段都可以自动进行我们这步也不做什么调整直接下一步就行如下最后为我们的应用关联上我们可以测试下开发票的效果可以看到它根据知识库的内容回答如下API封装Dify已经对API封装的格式做了说明如下这里需要说明下我们在每个应用里创建的API-Key都是调用这个应用的凭证所以在项目里调用应用都需要先生成它的Key并把它配置在项目里如下public class DifyServerConstants { /** * The base URL of the Dify API. */ public static final String BASE_URL https://dify.xxxxxxxx.com.cn/v1; /** * XX应用api key */ public static final String APP_API_KEY XXXXXXXXXX; }在实际中根据自己的应用使用情况可以把key都统一管理起来常量类是种实现写在配置文件里也是。然后我们基于官方的文档简单封装下代码如下private String getResultByDify(String text, String BearerAuth) { //设置请求体 JSONObject body new JSONObject(); body.put(query, text); body.put(response_mode, blocking); // 注这个userId是调用dify应用的必须参数一般取当前登录用户即可如没有特殊要求也可随意指定 Long userId LoginHelper.getUserId(); body.put(inputs, ); // 封装请求体和请求头 String jsonString body.toJSONString(); //发送post请求阻塞式 HttpHeaders headers new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); headers.setAccept(List.of(MediaType.APPLICATION_JSON)); headers.setBearerAuth(BearerAuth); // 封装请求体和请求头 HttpEntityString entity new HttpEntity(jsonString, headers); //url String url DifyServerConstants.BASE_URL /chat-messages; //发送请求 ResponseEntityString stringResponseEntity restTemplate.postForEntity(url, entity, String.class); //获取answer字段 if (ObjectUtil.isNotEmpty(stringResponseEntity.getBody())) { JSONObject jsonObject JSONObject.parseObject(stringResponseEntity.getBody()); String answer jsonObject.getString(answer); //去掉markdown answer StrUtil.removeAll(answer, json); answer StrUtil.removeAll(answer, ); return answer; } return null; }我们可以把它声明为一个接口或者工具类只需要传入问题和应用的key就可以实现通用调用了如下String answer getResultByDify(question, DifyServerConstants.XXX_KEY);转发逻辑实现编写一个接口用来接收用户输入的问题代码如下/** * 根据问题分类并调用相应的Dify服务获取答案 * * param userQuery 用户提出的问题 * param BearerAuth Dify的Bearer token * return Dify返回的答案 */ public String handleUserQuery(String userQuery, String BearerAuth) { // 调用分类模型获取类型 String domainJson getResultByDify(userQuery, BearerAuth); // 解析结果json并返回类型 int domainType extractTypeFromJson(domainJson); ​ // 根据分类结果调用不同的Dify服务 switch (domainType) { case 1: return getResultByDify(userQuery, BearerAuth); // 售前 case 2: return getResultByDify(userQuery, BearerAuth); // 售后 case 3: return getResultByDify(userQuery, BearerAuth); // 日常业务 // 后续可扩展的其他领域如技术支持 default: return 抱歉我无法识别您的问题类别。; } }另外还需要对AI返回的结果解析下,代码如下/** * 从分类结果的JSON中提取领域类型 * * param jsonResponse 分类结果的JSON字符串 * return 领域类型数字 */ private int extractTypeFromJson(String jsonResponse) { JSONObject jsonObject JSONObject.parseObject(jsonResponse); return jsonObject.getInteger(type); }至此我们就简单地实现了这个AI客服智能分发系统我们通过日志记录下一次测试过程如下五、小结其实上述的这个小demo仅仅依靠dify的工作流就可以实现多应用的协作但实际业务中我们可能会遇到在现有的客服系统中去集成AI或者我们的系统需要先接入AI客服但客户问题并未得到解决再接入人工客服自然就需要我们需要相应的服务管理。因此本文重点在实现的思路和方案上希望对大家有所帮助