哔哩哔哩基于云的客服架构体系

1. 吕帆哔哩哔哩

2. 目录

3.

4. 传统架构的局限性分析新一代客服系统的转型方向

5. 原系统来自外部采购，外部代码，部署物理机，单体架构系统稳定性差扩展能力受限通信不即时丢消息智能化水平低

6. 1 2 3 全云化架构智能化云化与智能化的结合分布式部署，弹性扩展，高可用性和多活的容灾能力智能问答，智能检索，智能坐席调度弹性智能资源调度，数据驱动的智能决策

7. 云客服整体架构资源部署和微服务服务拆分多活

8. 接入层网关层权限校验参数校验 API管理通用配置业务方管理流量控制分布式架构可拓展应用层用户入口智能问答坐席调度客服工作台 IM 系统客服知识库客服质检客服工单稳定性提升易部署云存储/计算 Mysql ES Boss文件存储 Redis MQ Taishan KV 支撑层算法 Docker LLM Milvus 故障隔离 K8S Embeding Faiss 复杂度降低

9. • 整个架构上可以多机房部署 • CDN流量可随时切换 • Pod可随时扩容 • 缓存/数据库等也可以随时扩容

10. 分布式微服务部署网关服务智能问答 IM 工单 • 故障彼此隔离 • 发布彼此隔离向量检索大模型坐席调度工单调度知识库工作台工单工作台 • 资源彼此隔离

11. 网关服务智能问答用户咨询量占比：占比70% IM 工单占比20% 占比10%

12. 读场景多活部署网关服务智能问答向量检索大模型知识库

13. 写场景多活部署网关服务 IM 工单坐席调度工单调度工作台工单工作台

14. 系统稳定性提升拓展能力提升复杂性降低容灾能力提升

15. 云广播机制和轮询机制实现云IM总体架构设计和核心流程

16. C端 B端 IM通信

17. • Server和Client该如何即时通讯 • 消息如何不丢失 • 多端之间消息如何同步

18. • 新客服系统采用广播+轮询机制来解决 • 本质还是消息推模式和拉模式的结合 • 当有新消息时，广播推送给移动端，由移动端主动发起轮询，可以及时刷新- • 对广播未送达进行消息补偿，移动端使用服务端下发的轮询周期取拉取新消息，刷新状态- • 同时这种轮询模式也解决了

19. 接入层 1.发送消息网关服务器欢迎语推荐问题智能问答转人工排队工单评价系统提醒消息系统 2.送至消息服务分发处理 3.处理消息网关服务器 4.存储消息 5. 广播推送网关服务器同步新消息 7. &更新会话列表用户+商家A 消息1 消息2 用户+商家B 消息1 消息2 6.读消息&会话用户+商家C 消息1 消息2 . . . 消息3 ...... 消息3 ...... 消息3 ......

20. • 对网络环境要求高：长连接依赖稳定的网络环境，如果网络不稳定，可能会导致连接中断，影响消息传递 • 维护复杂开发成本高：长连接需要维护客户端和服务器之间的连接状态，以及重连，保活；多端同步更是导致开发成本高 • 资源消耗大：长连接需要在客户端和服务器之间保持连接，这会占用一定的系统资源，尤其是当并发连接数较多时

21. 消息即时不丢消息消息共享

22. 知识库构建基于向量检索的智能问答基于知识库构建的RAG 多轮问答的实现

23. 问题:xxx 答案:xxx 知识库

24. 用户问题 B站的成立时间是什么时候？标准问题 B站成立时间答案哔哩哔哩成立于 2009年6月26日，被网友亲切的称为 “B站”

25. 用户问题相似问题标准问题答案 bilibili成立时间哔哩哔哩成立时间 B站的成立时间是什么时候？阿B成立时间 b站哪年成立的 ... B站成立时间哔哩哔哩成立于2009 年6月26日，被网友亲切的称为“B站”

26.

27. 根据用户的问题找到最相似的问题文本相似度计算

28. 文本是一种非结构化的数据信息，是不能直接被计算的

29. Word Embeding 词义相似时，在空间上也近似

30.

31. 整体流程用户的问题搜索模型 Embeding Embeding 用户返回TopN 相似问训练基于Faiss框架知识库

32. • 不够拟人化，回答比较生硬，机器人满意度比较低 • 只能做到单轮对话，不考虑上下文 • 如果进一步提升拦截率，面临满意度的降低的风险

33. 用户用户的问题 query改写： • Re-writing • 向上泛化 • 分解子查询向量检索关键词检索训练索引 Data Store 返回TopN 问题和答案上文大语言模型（经过prompt+综合处理）输出答案机器人知识库领域知识库业务知识库聊天记录

34. 领域知识库构建知识库历史聊天记录各类业务文档人工 LLM 拆分人工运营FAQ LLM挖掘FAQ 业务知识领域知识库

35. 双路召回+重排

36. query改写： • 指代消解补全query • memory信息补全query

37. query改写： • • 向上泛化提出更基本概念，获取相关背景信息，补充query

38. query改写： • • Sub-query 分解子查询

39. 安全性保障 • 知识库更新 • 默认一小时自动更新一次 • 也可手动实时更新 • 拒答机制 • 匹配度 • 黑名单 • 信息溯源机制 • 答案均可溯源 • 有助于问题排查 • 人工回查/质检

40. 可用性保障 • 大模型耗时多 • 超过一定时间，走向量检索兜底 • 用户连续多次发问 • 将问题和答案对应，记录每个问题的回答情况 • 如果都没有超时，对最后一条提问回答 • 对于超时未收到回复的用户，只会对他发的最后一条消息走向量检索兜底回答 • 收到最后一条回答后，不会再对它之前未生成回答的提问生成兜底回答

41. 拦截率提升好评率提升智能化水平整体提升

42. 知识库基于向量和关键词的双路召回云坐席智能调度

43. 传统的文本检索（包括精确检索、模糊检索、分词检索等），往往通过基于关键词的全文检索实现 “天气很好” 在全文检索场景下只能搜索到具有“天气”、“很好”或者其他词汇的结果但语义检索还可以搜索到 “万里无云”、“阳光明媚”等结果

44. ES(8.0)可以实现基于BM25下的全文检索+向量召回, 可以实现更优的检索效果

45.

46.

47.

48. 当前的问题 • 根据现行业务逻辑，所有排队用户均会被客服接待 • 这导致用户在被接待时，很多排队已久用户早已离线，而客服仍需接待，造成资源浪费 • 在BW/BML售票期间，用户排队现象普遍，排队名次超过千人，客服处理问题到凌晨

49.

50. 第一次BW&BML(2024.06.29)抢票无效会话占比： 30.7% 第二次BW&BML(2024.07.06)抢票无效会话占比： 11.8%

51.

52. • 多模态 • 目前图片还无法理解 • 视频也无法理解

53. Agent智能体交互 • • • • 能够根据环境或数据的变化规划拆解任务能集成多个API和工具，如数据库、企业系统（CRM、ERP）可以拆解复杂任务可以实现任务的长期记忆和信息积累，帮助用户实现更持久的个性化服务

54.

55. 大模型正在重新定义软件 Large Language Model Is Redefining The Software