聊一聊关于chat在线智能对话系统的推荐的事情。要先把概念拆开来、凑合着看，里面究竟有什么东西呢？外面的说法很多，线上的客服、智能问答机器人、对话式的AI等等，其实指的是差不多的东西，底层逻辑就是让机器听得懂人的语言，然后再用人的语言来回复给机器。再加上推荐系统的后缀，那么这不仅仅是一个简单的对话框出现在网页的一个角落上而已，而是在于如何去从中选择出最适合自己的那一套配置。比如买手机的时候，并不是说“想要一个可以打电话的”，而是要看信号频段、处理器、摄像头模组是否适合自己日常使用的那些APP。

打开之后的第一层就是所谓的在线智能对话系统，它的核心就是两个机制互相配合运行。一套管理系统，将用户的敲进来的大白话、错别字、倒装句转换为机器可以理解的指令代码。另外一套管生成，从知识库中提取出与之相关的答案片段，并且按照事先设定好的规则来组织语言并推出出去。其中包含有意图识别、实体抽取、多轮对话状态跟踪等一系列的技术步骤。在推荐的时候不能仅仅依靠谁家演示视频里对答如流来判断，要仔细查看它所支持的业务场景数量。有的系统在售后咨询的时候顺手，在售前导购时就会出现卡壳的情况，这是因为背后的知识图谱构建思路完全不同。售后问答链比较短，并且答案都是固定的；售前导购链路很长，需要引导、提问、比较参数、计算折扣。

第二层就是部署形式了。有的人才认为SaaS云服务一挂就完事了，有的人则一定要进行私有化部署，在机房里把服务器锁起来。这里面没有绝对的好坏之分。SaaS版更新速度快、算法迭代厂商兜着走，公有云版本一般三个月之内意图识别准确率可以提升七到十五个百分点。依靠的是大量的交互数据不断输入到模型中去。

私有化部署的优势就是数据不外泄，在金融、医疗等需要严格遵守规定的行业中没有选择余地。混合部署已经出现苗头了，在核心和敏感的数据上要留在本地，在闲聊天气的时候可以查询到物流信息，并且这些信息都会通过API进行连接。在推荐的时候要先弄清楚自己公司的数据合规红线在哪里，否则方案上报给法务后会被直接否决。

第三层涉及到交互端载体的问题。网页悬浮窗是最传统的做法了。正规的推荐方案要包括微信公众号、企业微信、小程序、APP内嵌以及WhatsApp、Line等海外渠道。不同的载体消息格式有不同的限制，在微信中不能发送大的表格，但是在APP中可以上传富文本卡片并带有跳转链接。系统的后台最好是有一个知识库，并且可以实现多端同步分发的功能，否则的话运营团队就需要在三个不同的后台之间来回倒腾同一个回复话术了，人力成本会成倍增长。全渠道接入能力直接影响到客服团队每天多花两个小时或者少花两个小时在重复配置上面。

第四层就是冷启动带来的困扰。新的系统在上线后的第一个月是最难过的。没有历史对话日志，意图识别模型就像一个新入职的实习生一样，看到“改地址”、“换地方收件”可能会认为是两件完全不相关的事务来处理。在推荐环节要问清楚厂家是否有行业的预训练模型来兜底。比如在零售业中已经预设了“退换货”、“优惠券核销”、“物流时效”等几百个高频意图模板，在客户进来的时候就可以拦截掉七八成的普通咨询。剩下的20%刁钻长尾问题还需要依靠人工进行标注，并且需要经过长时间的磨合。如果没有行业的预置包的话，在上线前三个星期的时候准确率可以降到百分之六十以下，客服后台转人工的比例也会上升很多，相当于花钱买了一个摆设。

第五层是指和现有的业务系统进行连接的程度。如果对话系统的订单中心不能实时显示订单的状态，那么当用户询问“我的快递在哪里？”时，系统只能回答“请提供单号人工查询”，这样智能二字就打上了折扣。在使用推荐系统的的时候一定要把技术负责人叫过来核对一下API对接清单、CRM是否要打通、工单系统要不要嵌入、库存数据要不要露出来。打通一条数据源之后，对话机器人有效闭环的比例会提高一些。对接ERP、订单系统等的成本有时候会高于购买对话系统本身许可证费用的时候多了很多，前期算账容易忽略掉这一块。

第六层为运营后台顺手的程度。最后天天使用该后台的是客服主管以及一线坐席，并非程序员。如果推荐界面需要使用正则表达式来配置新的问答，则不到两周的时间内，整个团队就会放弃使用这个功能，并且重新回到用Excel记录话术的老路上去了。好的运营台一般都支持Excel批量导入FAQ，并且可以提供话术版本管理功能，可以把相似的问题自动聚类推送给用户审核，还可以对高热度未被覆盖的问题进行优先补充答案。厂商展示的时候这些细节都不会出现，在自己亲自使用账号之后仅仅两三个小时就直接被锁门了。

第七层就是推荐过程中容易被人忽视的语言支持。有的系统只是对简单的中文进行了校准，在用户夹着繁体字或者英文品牌名来询问的时候，分词一乱回答就飘。跨境业务或者是外资在中国设立的分公司，需要对这一块进行测试。分别提出两个问题：“iPhone15充电发热正常吗？”、“iPhone15充电发热正常吗？”然后观察到回复是否为同一个标准答案。对于多语言支持能力较差的系统来说，它会直接把繁体的问题扔到“未识别”的池子里去晾晒。

第八层就是收费方式对于长久使用的后果。按照使用量来收费的版本，在头半年可能会比较划算，但是随着交互量增加之后，账单就会翻倍。按照坐席账号收费的话，如果转人工率无法降低，则相当于机器人和人工各出一半的钱。按照年度的方式提供包含一定的调用量配额的服务现在已经比较普遍了。在推荐的时候可以做一个半年的人工客服会话量的大致估计，然后把厂商报价公式代入其中来计算出一年半的费用曲线，高峰月份数量超过配额之后阶梯价格有时候会使得全年的预算超出三成。

第九层和合规安全是绑定在一起的。欧盟GDPR以及我国个人信息保护法对于对话数据的保存期限和脱敏方法都做了明确规定。用户不小心在对话框中输入了手机号或者身份证号，系统后台在存储的时候是以明文还是掩码的形式呢？日志保存多少天呢？三十天还是九十天。在推荐书中要单独列出一页合规checklist，并且由信息安全部门审核盖章。省略掉这一环节之后后面被通知整改的时候才知道疼。

第十层为语音转文字插件的发展程度。有的用户不愿意打字，直接发送语音到系统中去，系统要先运行一次ASR引擎把语音转换成文字之后再进入对话流程。在推荐的时候可以询问清楚语音识别引擎是自主研发还是外挂第三方，方言识别准确度是多少，嘈杂环境下降噪处理达到何种程度。在外卖快递这样的骑手端使用场景中，语音消息占比较大，一般会超过四成；而当语音消息识别错误率上升时，相应的投诉数量也会增加。

第十一层就是数据分析师看板的地方。对话系统的自带分析后台能查到“用户问完优惠活动之后没有下订单就离开了”的这样的业务侧断层吗？还是只会给出冰冷的数据、匹配率和转人工率等等。有用的统计数据就是高频未命中问题群，可以倒推出运营部门对页面文案或产品的功能进行调整。在推荐的时候可以让厂家打开真实的客户后端数据面板截屏，看看他们是怎么用这些数据进行迭代的，并不是只看PPT上所展示的图示。

第十二层为系统的迁移费用。已经存在了旧版问答库使用的状况，新的系统能否把老的数据无损地导入过来。FAQ条目少则几百条、多则数万条，人工搬运不可行。在做推荐之前要有一份数据迁移方案文档，看清楚字段映射关系、富文本格式保留程度、关联问题链的继承逻辑。迁移过程中如果没有保留好问题之间的父子关系，在上线之后就需要花费几周的时间来重新整理。

第十三层为小语种及垂直行业的专业词汇匹配。在医疗行业中，“心衰分级”与“心功能不全分期”这两个概念是否会被当作同义词来对待呢？在法律行业中，“合同解除”与“合同终止”的区别是什么？通用的大模型遇到专业的术语很容易张冠李戴。垂直领域的对话系统，在算法架构上并不比其他系统更先进，在行业的词库积累程度以及人工标注精细度方面才是其最大的障碍。

第14层为多轮对话记忆深度。用户上一句是“我要改航班”，下一句又说是“后天那班就行”。那么系统是否记得前面提到的是哪一个订单、哪一趟航班呢？记忆窗口长度设置得过短的话，用户就会多打出一些字来忘记掉前面的内容。在推荐的时候可以举一个具体的业务场景来走一遭长链路，看看走到第七步的时候系统还记着第一项订单号没有。

第15层为移动端兼容性。网页版对话框在小屏幕上有没有做自适应，按钮大小够不够手指去点击，键盘弹起的时候输入框会不会被遮挡。大部分对话都在手机上进行，如果交互体验出现问题，那么桌面端再好也没有用了。用不同的手机真机来测试一下，把浏览器兼容性范围写到合同附件里去。

第十六层为厂商持续服务的能力。购买系统并不是一次性的交易，在之后的模型优化、新功能更新、行业包迭代等过程中都离不开厂商的人力资源支持。在推荐之前要查看下该厂家最近一年的产品更新日志，如果更新频率低于一季度一次的话就有可能存在内部资源倾斜的情况。再看看客户的案例中是否有和自己一样大小、行业连续使用两年以上的情况，短期POC测试效果好但是长期发展就会落后一些的例子很多。

第17层为转人工机制的顺滑程度。机器人回答了一半的时候，用户就喊出“转人工”的字样来，那么系统是否可以将前面对话语段进行总结并带到人工坐席的工作台上去呢？还是说人工需要重新从头开始询问一遍。转人工体验差会使得用户每次接到机器人的时候就直接要求跳过，整个系统形同虚设。在推荐的时候要考虑到会话移交的时候上下文携带字段的数量以及格式。

第18层为可以进行主动触达的消息能力。系统是否可以当订单的状态发生变化的时候，主动地给用户提供一条信息，“您的包裹已经到了驿站取件码为xxxxx”，而不仅仅是被动地回应。主动消息要和业务系统更紧密地耦合起来，触发规则设计得比较灵活一些，不要变成骚扰推送。当主动消息功能被开启之后，客服每天被动接到的电话数量可以降低15%左右，但是推送频率没有把控好的话，投诉率也会随之上升。

第19层就是版本管理对于大团队协作所起的作用。FAQ话术更新之后可以先放到灰度环境中进行测试，确保没有问题后再一键上线。可以回滚到之前的版本吗？多人同时修改同一个问题的答案的时候会有什么样的冲突提示呢？在一百人以上的客服团队中，这些都是必需的功能，对于一个小团队中的一个人来说，可能根本不需要使用。在推荐的时候不要给不需要的功能多付钱。

二十层就是最后的质量验收标准该怎么确定。除了要看应答准确率这个数据之外，厂家还会自己报出一些动辄百分之九十左右的数据来。查看没有转人工成功的会话比例、看用户主动结束对话之前对满意度进行打分、看同一个会话中重复提问的数量。这几个数字比较实际一些。使用系统的目的是为了减少人们接到不必要的重复电话的情况，并不是为了让机器来展示出对答如流的能力。推荐过程中的每一环节都把这四点放在前面当作硬性指标来谈论，在SLA中也有体现，只有这样，后期运维才有抓手。