文章目录项目背景技术选型架构设计核心实现1. 混合检索式知识库的实现2. 基于Rasa的、可对接业务API的对话流踩坑记录效果对比项目背景在上一家公司我们团队负责的电商业务线客服压力巨大。高峰期用户咨询从App、小程序、官网、电话、社交媒体等十几个渠道涌来客服团队疲于奔命重复问题如“订单到哪了”、“怎么退货”占了70%以上。更头疼的是各渠道数据割裂用户从微信转到电话客服得重新问一遍情况体验极差。老板下了死命令既要降本控制人力成本增长又要增效提升响应速度和满意度。我们评估后决定自研一个AI智能客服中台目标很明确用一个统一的大脑服务所有渠道把简单重复的问题交给AI复杂问题无缝转人工。技术选型这个项目核心是“智能”与“中台”。技术选型上我们放弃了从零训练模型这种“重炮打蚊子”的方案而是基于成熟组件做集成和优化。对话引擎AI核心方案采用Rasa开源框架微调后的BERT语义匹配模型。原因Rasa提供了一套完整的对话管理Dialogue Management框架支持自定义意图Intent、实体Entity和复杂的对话流Story。它的优势在于本地部署、数据隐私可控、且高度可定制不像某些SaaS API有调用限制和数据风险。我们用BERT来增强Rasa的NLU自然语言理解模块提升对用户相似问法的泛化理解能力。知识库与问答方案ElasticsearchSentence-BERTSBERT向量检索。原因对于标准的商品、物流、售后政策等知识我们采用“检索式QA”。Elasticsearch负责关键词快速召回SBERT生成的句向量负责语义精排。这种“粗排精排”的混合搜索比单纯的关键词搜索准确率高出一个量级。渠道网关中台关键方案基于Spring Cloud Gateway自研统一接入网关。原因这是“中台”的入口。所有渠道微信、APP、网页等的客服请求都通过这个网关进行协议转换、鉴权、路由统一发给后端的对话引擎。这样后端AI服务只需要开发一套接口大大降低了维护成本。会话管理与转人工方案Redis存储会话状态WebSocket实现实时对话流。原因客服对话是有状态的。Redis能快速存储和读取用户当前的对话上下文如正在处理的订单号。当AI无法处理或用户要求转人工时通过WebSocket将当前完整的会话历史context推送给客服坐席的PC端坐席能立刻接续实现“无缝衔接”。架构设计我们的整体架构遵循“前后端分离、中台聚合”的思想下图是核心架构简图[ 用户端 ] (微信/APP/网页...) | v [ 统一渠道网关 ] (Spring Cloud Gateway) —— 协议转换、路由、限流 | v [ AI智能客服中台 ] |----------------|------------------| v v v [ 对话管理服务 ] [ 知识库服务 ] [ 会话状态服务 ] (Rasa Core) (ESSBERT) (Redis) | | | v----------------v------------------v [ 统一业务逻辑层 ] | v [ 后端业务系统 ] (订单/物流/用户...)核心流程用户在任何渠道发送消息。渠道网关将其转换为标准格式的请求转发给“对话管理服务”。对话管理服务调用NLU理解意图如果是闲聊或简单QA直接由Rasa的策略Policy决定回复或调用知识库如果是需要查订单、改地址等需要对接后端业务系统的操作则通过“统一业务逻辑层”调用对应API获取结果后组织语言回复。整个会话的上下文用户ID、当前意图、槽位信息等实时存入Redis。当触发转人工规则如用户连续三次未得到满意答案、或发送“转人工”会话状态连同历史记录通过消息队列推送给客服工作台客服介入。核心实现这里我挑两个最有挑战性的核心模块讲讲具体实现和代码。1. 混合检索式知识库的实现这是提升答案准确率的关键。我们不是简单地把问题丢给ES而是做了分层处理。# 知识库检索服务核心代码片段importjiebafromsentence_transformersimportSentenceTransformerimportelasticsearchclassHybridQAService:def__init__(self):self.eselasticsearch.Elasticsearch()self.sbert_modelSentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2)# 轻量级多语言模型self.index_namefaq_knowledge_basedefsearch(self,query:str,top_k:int5):# 阶段一关键词粗排 (Elasticsearch)# 使用结巴分词并增加同义词扩展提高召回率wordsjieba.cut_for_search(query)expanded_queryself._expand_synonyms( .join(words))es_body{query:{match:{question:expanded_query}},size:top_k*3# 多召回一些供精排筛选}es_resultsself.es.search(indexself.index_name,bodyes_body)candidate_docs[hit[_source]forhitines_results[hits][hits]]ifnotcandidate_docs:return[]# 阶段二语义精排 (SBERT)# 将用户问题和候选问题列表转换为向量query_vectorself.sbert_model.encode([query])doc_vectorsself.sbert_model.encode([doc[question]fordocincandidate_docs])# 计算余弦相似度fromsklearn.metrics.pairwiseimportcosine_similarity similaritiescosine_similarity(query_vector,doc_vectors)[0]# 结合ES分数和语义相似度分数进行综合排序加权平均scored_docs[]fori,docinenumerate(candidate_docs):es_scorees_results[hits][hits][i][_score]semantic_scoresimilarities[i]# 简单加权权重可根据业务调优combined_score0.3*es_score0.7*semantic_score scored_docs.append((combined_score,doc))# 取Top-Kscored_docs.sort(keylambdax:x[0],reverseTrue)return[docfor_,docinscored_docs[:top_k]]def_expand_synonyms(self,text):# 简单的同义词映射例如“怎么付款” - “如何支付 怎么付款”synonym_map{怎么:如何,付款:支付,物流:快递}# ... 实际应用会更复杂可能使用词林或自己构建的业务同义词库returntext关键点粗排保证召回不让可能的答案漏掉精排保证精度把最相关的答案排到最前面。权重0.3和0.7需要根据实际业务日志中的点击/满意率进行A/B测试调整。2. 基于Rasa的、可对接业务API的对话流Rasa的强大在于其可定制的Actions。我们通过自定义Action来桥接AI和业务系统。# Rasa domain.yml 部分配置intents:-query_order_status:# 查询订单状态意图triggers:action_query_order# 意图触发后直接运行此action-faq_return_policy:# 退货政策FAQ意图triggers:respond_faq# 触发回复FAQ的actionactions:-action_query_order-respond_faq-...# 其他自定义actionresponses:utter_ask_order_id:-text:“请问您的订单号是多少呢”# actions.py 中的自定义Actionfromrasa_sdkimportAction,Trackerfromrasa_sdk.executorimportCollectingDispatcherimportrequestsclassActionQueryOrder(Action):defname(self)-Text:returnaction_query_orderasyncdefrun(self,dispatcher:CollectingDispatcher,tracker:Tracker,domain:Dict[Text,Any])-List[Dict[Text,Any]]:# 1. 从对话上下文的槽位slot中提取实体如订单号order_idtracker.get_slot(order_id)ifnotorder_id:# 如果槽位为空说明用户还没提供则反问dispatcher.utter_message(templateutter_ask_order_id)return[]# 2. 调用后端订单系统API这里是模拟try:# 通过我们中台的“统一业务逻辑层”调用而非直接调用order_infoself._call_order_service_api(order_id)# 3. 组织自然语言回复status_map{1:已发货,2:配送中,3:已签收}statusstatus_map.get(order_info.get(status),未知状态)msgf您的订单{order_id}当前状态是{status}。物流单号{order_info.get(tracking_no,暂无)}dispatcher.utter_message(textmsg)exceptExceptionase:# 4. 异常处理例如系统异常友好提示并建议转人工dispatcher.utter_message(text抱歉系统暂时无法查询到您的订单信息。您是否需要转接人工客服进一步处理)# 这里可以设置一个标志提高下次转人工的优先级return[SlotSet(need_human_help,True)]return[]关键点自定义Action是Rasa与真实世界交互的“手”。通过它对话机器人不再是“纸上谈兵”而是能真正查询数据、办理业务的智能助手。踩坑记录冷启动问题初期没有足够多的用户对话数据来训练NLU模型导致意图识别不准。解决我们用了“三步走”a) 先用规则正则表达式覆盖最高频的20个问题保证基础可用。b) 收集线上真实query人工打标每周迭代训练一次模型。c) 利用无监督聚类方法对未识别的query进行聚类发现新的意图模式。上下文保持难题用户对话经常跳跃比如“帮我查下订单”提供订单号A“那另一个呢”指订单号B。AI需要记住之前的上下文。解决深度利用Rasa的Tracker和Slots。除了订单号我们把用户最近询问的“实体类型”如“订单”、“商品”、“售后单”也存入槽位。当用户说“另一个”我们检查最近提到的实体类型然后去追问对应类型的ID。逻辑变复杂了但体验提升明显。渠道特性适配微信有表情、语音、菜单APP可以发卡片、图文。统一的文字回复在所有渠道体验不佳。解决在渠道网关层做渲染适配。中台核心只输出标准的结构化数据如{“type”: “text/rich_text”, “content”: {...}}由网关根据渠道能力将结构化数据转换成微信的图文消息、APP的Native卡片或网页的纯文本。这是中台架构灵活性的体现。效果对比项目上线半年后数据对比非常直观成本客服团队在业务量增长50%的情况下人员零增长。人力成本节省预估每年超过200万。效率首次响应时间从平均45秒缩短到2秒内AI自动回复。70%的常见咨询被AI自动解决。体验用户满意度CSAT上升了15个百分点。关键在于“无缝转人工”用户不再有被AI“踢皮球”的挫败感。数据价值所有渠道的客服对话数据首次统一沉淀到中台我们利用这些数据做舆情分析、产品问题挖掘反哺到了产品和运营部门。这个项目让我深刻体会到AI项目成功的秘诀往往不在于用了多炫的模型而在于如何将AI能力与现有业务系统、业务流程优雅且扎实地集成起来解决真实的痛点。智能客服中台核心是“中台”智能是让它如虎添翼的手段。如有问题欢迎评论区交流持续更新中…