本期作者
一、 前语
一直以来，面向运营运用的活动渠道，在运营运用过程中会偶发出现一些疑难问题，比如运营对某个组件功用的运用有疑问，或许线上的活动表现不符合预期，运营期望产研帮忙排查。面临这些场景，活动渠道保护了一个千人以上的产研运“救火群”，运营有问题会在群里发问，当周研发值勤会担任重视群里的问题，并作出呼应答复，一起为了了解每周问题情况，值勤需求手动记载每周问题excel。
尽管这种做法在很大程度上包办处理了大部分的运营问题，但这种模式仍旧有一些问题：
- 问题及处理计划得不到自动沉积，假如想沉积faq，依靠值勤手动进行记载，耗时耗力。
- 问题解答要求值勤同学对问题所涉范畴有满意了解，才干找到具体对接同学定位问题。
- 群音讯内容繁杂，音讯有时简单吞没，依靠值勤同学“爬楼有道”。
可见，依靠人工干预和手动记载，不只耗费大量时刻和人力，并且简单犯错和遗失，基于此，一个可智能对话、可针对性一键拉群、支撑FAQ沉积的智能客服体系诞生了。本文就将带你一起了解下面向渠道的智能客服体系的落地实践之心路历程。
二、 我是什么样子的客服体系？
作为一个智能客服体系，现在的我长这样：
我主要包含以下几部分构成：
- 对话界面
- 会话状况机
- 数据源模型
- 计算汇总后台
- 接入装备
- 对话界面
想要搜集运营问题，供应给运营的对话界面不可少。经过对运营运用习气调研，大部分运营更愿意运用企微原生功用完结对话，而跳转到第三方网页或许在活动后台敞开对话窗口的方式，运营都不愿意接受，这也不难理解，毕竟企微是咱们日常沟通的集散地。企微现在支撑服务号/运用号两种不同的可供应对话页面的方式，因为受限于服务号的“无音讯回调”，“人工座席与智能服务不能共存”等问题，最终咱们挑选了运用号作为人工客服的主要对话进口。
（对话界面）
经过在运用号上绑定回调接口的方式，咱们可以将用户在运用号上的所有操作（包含自动的对话音讯）都使用回调接口进行接纳，解密后对用户的发问音讯进行理解及二次处理。特别想指出，在测试环境进行调试时，遇到微信无法访问UAT域名的问题，处理这个问题，咱们架了一层署理，敞开callback-api服务接口，将外网请求直接转发到uat环境域名上。并且在整个流程中都会带有部分flag(小红旗)，完结了不同部分间的流程和数据的阻隔。
（音讯接纳&解析）
- 会话状况机
后端保护了一整套会话办理体系，会话状况由会话敞开、进行中(转人工、未转人工)、已完毕组成，每次会话在运营向运用号发音讯时敞开，在谈天过程中，运用号与后端服务进行交互，经过不同类型的音讯事情，触发敞开会话、自动搜集会话信息、会话辨认、会话FAQ匹配、回复用户答案等流程，保护会话状况，并对用户一键拉群、完毕会话等请求进行呼应。一起，会话状况机保护一个状况的延时音讯队列，在用户长时刻无呼应时进行自动二次确认，并保存对会话自动关闭的机制。
（状况流通）
其间在会话坚持进行中的状况时，用户可以根据需求，进行一键转人工服务，现在咱们会保护活动渠道的值勤信息，在用户请求转人工后咱们会一键拉群，拉齐发问用户及本周研发和产品值勤同学，在群里对问题进行闭环处理。
- 数据源模型
这儿所说的数据源模型，主要是指在辨认用户音讯内容后，针对音讯内容，进行合理回复的底层数据源选型模型，现在本套智能客服回复支撑两种模型，一种是基于ES查找的，另一种是基于类似ChatGPT的专业范畴学习模型，运用OpenAI API对用户的问题进行向量分析并答复。
（智能答复流程图）
基于ES查找的数据源模型，咱们选用Elasticsearch内置的分词器(Tokenizer)和过滤器(Token Filter)对用户问题进行拆分辨认，并匹配FAQ库中匹配度最高的答案，给予回来。
另一种基于天然言语处理和机器学习的问答处理模型，其特征便是问题答复更天然、更人性化，它可以对用户问题进行预处理，对原始答案进行加工。可是其缺点在咱们的智能客服项目中也体现的比较显着，在咱们FAQ库、对话信息搜集不满意丰富的情况下，模型练习的准确性并不高，乃至模型会有“自由发挥”空间，这对于咱们听话的运营来说实属灾祸，可想，运营跟着智能客服一顿操作，最终发现原来这都是智能客服的YY时，大约运营心中会有一万只羊驼经过吧。
基于此，咱们调整了模型思路，基于已有信息进行类似度模型练习，咱们在这儿引入simbert模型，其最大的优势在于在特定专业学习范畴里，准确率比其他模型都高，天然咱们也不会放弃“ChatGPT”，只不过它更多的是在练习数据满意的情况下，对问题进行极限兜底。
一起，为了确保练习数据的补给，咱们也打通了一条离线数据补给流，对话界面搜集到的FAQ及对话信息会经过离线任务同步给练习模型，让练习模型不断“精进自我”，进步答复的准确率。
现在智能客服支撑两种数据模型的开关操控，随时随地随意切换。
- 计算汇总后台
为了方便对所有会话数据进行办理、review、计算，咱们供应了一套可视化的办理后台，这个后台的特征有几点：
一是lowcode，运用我司LEGO体系，在后端同学一顿拖拖拽拽，稍微改动后，一整套可克隆的后台就生成了；
二是后台体系供应了会话概况检查功用，方便对用户问题进行review；
三是可以在后台对每一条会话进行补白及状况流通；
四是可以对会话直接一键上传FAQ，FAQ数据将供应给ES及言语练习模型，真实完结全流程的闭环及可持续发展。
后台运用这一套技术计划最大的长处在于，不废前端人力，一起一键克隆功用真的很香。
- 接入装备
事实上，在做完这套智能客服体系之后，整个体系规划受到了很多兄弟团队的喜爱，比如日常也要处理用户问题的前端基建团队，数据库DBA团队，看来咱们对于日常FAQ搜集、用户问题解答等工作都在寻求更加低本钱、可持续的处理计划。所以咱们在Q2对整套体系进行了敞开化开发，敞开后咱们支撑多团队运用号接入，所有团队具有相同的会话状况机办理、底层数据源的灵敏挑选，并完结了各团队数据阻隔，可一键克隆后台办理页面等功用。
现在在接入流程上，主要有如下几步：
- 供应装备信息；比如：企微运用号AppSecret等根本信息，这主要是为了方便运用企微供应的API接口完结音讯解析与回复，一起需求供应一键拉群的值勤信息、问题搜集模板装备等。
- 回调接口绑定；假如接入团队想要运用运用号作为对话界面，则需求将统一的回调接口绑定在企微运用上，方便对对话进行搜集、解析、回复。当然，咱们的接口，也供应给有定制化对话窗口开发的团队，方便对websocket等方式的对话界面进行开发。
- 一键克隆后台办理页面；对后台办理界面进行克隆并稍加修正，便能满意团队大部分诉求。
至此，稍加调试，其他团队就可以方便的接入智能客服，完结一系列日常问题处理的闭环工作，包含智能会话办理、问题FAQ搜集、言语模型练习等。
三、实践
自体系上线以来，历经几次迭代，从支撑单部分到敞开至多部分，底层数据源从ES迭代到ChatGPT，智能客服已经成功实践在以下运用中：
（运用中）
（已接入）
运用以来，活动渠道姬共处理约1000例运营线上问题，日均处理运营5例咨询问题，ChatGPT上线一个月后，问题智能处理率进步挨近7%。
四、展望
对智能客服现在的运用趋势及运用反应进行分析，咱们也畅想了下未来发展：
-
更加敞开，可以使用企微运用号的回调才能开发智能客服体系，但一起也供应SDK服务，将才能供应给所有有需求的公司内部团队运用，不限于帮助团队灵敏的进行对话界面的定制化开发。
-
接入渠道化，现在要接入整个智能客服体系，需求人工对接，后续把对接流程线上渠道化，增加一些审阅机制，就可以方便的完结服务一键接入。
-
对转人工进行优化，假如团队运用企微运用号方式进行接入，那么就一定会受限于企微的既有功用，在用户转人工后，需求单独拉群间接完结摇人，整个对话无法在运用号内完结闭环处理，跳出带来的一是用户体验，二是拉群太多增加了办理本钱。这一部分咱们考虑“花钱”处理，比方说能否以公司身份出面向企微提需，供应更加灵敏的功用。
五、意外之喜
对智能客服的整体技术完结，并没有做花里胡哨的“过度规划”，简简单单的微服务范畴驱动模型，使用接口抽象其根本才能，供应对话接纳、音讯解析、问题答复、列表展示等才能，底层表结构保护了支撑长时间发展的分表会话表、对话记载表、FAQ表，便完结了整套智能客服会话体系，而体系的会话流通经过同步与异步相结合的方式，将用户界面功用与会话流通进行了解藕，确保每个体系的单一责任。一起体系以接口维度作为输出单元，进口简单，接入方便。使用这个项目真实的实践了一把MVA（最小可行架构），规划之初就限制新功用的范围，尽量解耦和简化体系组件，在保存功用和数据的完整性、可扩展性的一起，让代码简练、功用明了。可谓由简入奢易、由奢入简难，什么才是真实好的架构，这趟智能客服项目之旅，让我真实考虑了一番工程师之道。
最终感谢咱们耐心的读到了这儿，期望你能有所收获，哪怕一点点，哈哈。
