专场：智能运维与 SRE 变革：Agent 驱动的稳定性保障
.......
专场出品人：
....
.......
罗岚丹
bilibili 测试开发工程师
测试开发工程师，硕士毕业于西南交通大学，主要研究方向为自然语言处理（NLP），主攻实体、关系抽取与知识图谱补全。现就职于哔哩哔哩，主要负责车载端业务测试（涵盖Android与Web应用）及客诉AI自动处理系统的开发与质量保障工作。在工程落地中，设计了结合BM25与向量混合检索、需求RAG防误判、Badcase自动化回归及高可用降级机制。立足于一线测试开发实践，持续探索大模型与RAG技术在质量保障右移与智能运维中的落地价值。
待定
待定
基于混合检索与 LLM 双轨决策的智能客诉闭环实践：
从精准分流到高置信自动化处置
议题背景：
随着哔哩哔哩智能终端（大屏TV端、车载IoT端、手表等）业务快速扩展，用户客诉量剧增。传统排查面临三大痛点：
1.历史相似问题重复排查，排查经验无法沉淀；
2.业务设计变更导致的非缺陷反馈识别难，严重挤占研发精力；
3. TV、车载等通常因为反馈路径复杂，客诉零星且分布多端，难以大批量聚集告警，易导致个别严重反馈处理不及时；
4.AI研发背景下代码变更频繁，线上故障预防与快速止损变得尤为重要；
为此，我们规范了Fawkes工单处理流转规范，并构建了结合案例知识库_x0005_与企业级向量数据库（RAG需求库）的双轨检索及LLM决策机制，通过动态门控与高置信自动处置，实现客诉从智能分流、精准诊断到工单系统自动化闭环，从而提高高优问题识别率和解决率。
内容大纲：
1. 背景与线上痛点：复杂业务场景下的客诉治理困境
随着哔哩哔哩智能终端（大屏TV端、车载IoT端、手表等）业务快速扩展，用户客诉量剧增。传统排查面临三大痛点：
1.历史相似问题重复排查，排查经验无法沉淀；
2.业务设计变更导致的非缺陷反馈识别难，严重挤占研发精力；
3. TV、车载等通常因为反馈路径复杂，客诉零星且分布多端，难以大批量聚集告警，易导致个别严重反馈处理不及时；
4.AI研发背景下代码变更频繁，线上故障预防与快速止损变得尤为重要；
为此，我们规范了Fawkes工单处理流转规范，并构建了结合案例知识库_x0005_与企业级向量数据库（RAG需求库）的双轨检索及LLM决策机制，通过动态门控与高置信自动处置，实现客诉从智能分流、精准诊断到工单系统自动化闭环，从而提高高优问题识别率和解决率。
内容大纲：
1. 背景与线上痛点：复杂业务场景下的客诉治理困境
1.1 多终端异构环境下的客诉排查瓶颈
痛点：TV端与车载端客诉较多，需要研发与QA手动进行分析与排查，浪费人力。
现象分析：超50%的客诉为历史重复出现问题，但传统方式依赖人工记忆检索，耗时耗力，效率低，导致重复排查。
现象分析：超50%的客诉为历史重复出现问题，但传统方式依赖人工记忆检索，耗时耗力，效率低，导致重复排查。
1.2 质量与安全红线：线上自动化处置的风险控制
Fawkes自动写回机制与零误判红线：客诉信息绝对不能误判，会严重影响用户体验
1.3 传统规则引擎与关键词匹配方式的缺点
正则表达式与简单关键词无法匹配多样的自然语言描述，高误报率会导致研发产生警报疲劳。
1.4 Fawkes工单传统流转不规范与追溯难题
传统工单人工随意派发、处理过程无统一标准结论沉淀，缺少标准化流转规则与智能协同通知手段。
2. 核心架构设计：混合检索召回与大模型双轨决策引擎
2.1 召回三阶段流水线
阶段一（BM25词面粗筛）：基于中文2-gram与3-gram切词，保留词频信息，从全库筛选出Top20候选案例，避免直接全库向量扫描带来的性能开销。
阶段二（向量语义重排）：基于text-embedding-v3向量模型，仅对Top20候选计算余弦相似度（Cosine Similarity），取Top5精选候选。
阶段三（Semantic Guard防误判）：校验硬件设备、播放场景与动作冲突，剔除强违和案例。
阶段二（向量语义重排）：基于text-embedding-v3向量模型，仅对Top20候选计算余弦相似度（Cosine Similarity），取Top5精选候选。
阶段三（Semantic Guard防误判）：校验硬件设备、播放场景与动作冲突，剔除强违和案例。
2.2 动态门控降低Token成本
门控机制设计：计算候选案例最高词面分TopLexical，当分值<0.30时判定为无候选或弱匹配，自动触发门控去查业务逻辑知识库，补充查看是否为业务逻辑变更导致，最终分析客诉根因。
开销优化效果：强匹配场景下不查需求库，Prompt无增量，降低Token消耗与延迟。
开销优化效果：强匹配场景下不查需求库，Prompt无增量，降低Token消耗与延迟。
2.3 需求RAG实现业务逻辑补充
将TAPD平台的需求文档向量化，成功识别版本变更、流程调整等业务设计变更，避免将其误判为软件缺陷。
2.4 自动分发与智能路由分级逻辑
规范化录入与触发：
客服在Fawkes平台录入客诉（包含终端类型、版本、描述及截图），AI自动进行分析。
结构化原因自动附带：
AI分析完成后，自动将匹配的相似案例、推荐处理动作及分析理由作为结构化内容附带写入Fawkes工单。
高置信自动处置级（置信度≥90%）：
动作明确时（如确定为解决或拒绝），调Fawkes OpenAPI直接执行resolve、reject或跟进跟进。
中置信智能分发级（相似但未达自动处置线）：
四级分发策略：
1. 第一级（领域专业分发）：先识别问题属性，如果是算法模型、产品需求或运营进稿类问题，直接精准派发给具体的算法、产品或运营接口人；
2. 第二级（业务模块路由）：如果属于通用功能缺陷，按模块关键字（如播放、支付、车载终端）派发给对应模块的研发负责人；
3.第三级（历史处理人兜底）：如果模块规则没命中，去历史案例库找最相似问题的历史排查人员兜底转交；
4.第四级（当值人员保底）：如果前面规则全没砸中，直接派给当天值班的研发人员进行人工排查。
自动转交与推送：调Fawkes OpenAPI将流程transfer转交给指定责任人，并在企微群推送告警，附带一键采纳链接，点击即可网页或抽屉弹窗一键采纳AI建议。
客服在Fawkes平台录入客诉（包含终端类型、版本、描述及截图），AI自动进行分析。
结构化原因自动附带：
AI分析完成后，自动将匹配的相似案例、推荐处理动作及分析理由作为结构化内容附带写入Fawkes工单。
高置信自动处置级（置信度≥90%）：
动作明确时（如确定为解决或拒绝），调Fawkes OpenAPI直接执行resolve、reject或跟进跟进。
中置信智能分发级（相似但未达自动处置线）：
四级分发策略：
1. 第一级（领域专业分发）：先识别问题属性，如果是算法模型、产品需求或运营进稿类问题，直接精准派发给具体的算法、产品或运营接口人；
2. 第二级（业务模块路由）：如果属于通用功能缺陷，按模块关键字（如播放、支付、车载终端）派发给对应模块的研发负责人；
3.第三级（历史处理人兜底）：如果模块规则没命中，去历史案例库找最相似问题的历史排查人员兜底转交；
4.第四级（当值人员保底）：如果前面规则全没砸中，直接派给当天值班的研发人员进行人工排查。
自动转交与推送：调Fawkes OpenAPI将流程transfer转交给指定责任人，并在企微群推送告警，附带一键采纳链接，点击即可网页或抽屉弹窗一键采纳AI建议。
3. 工程落地与实战踩坑
3.1 踩坑1：向量数据库高并发限频与响应卡死
现象：知了平台单Token具有6QPS限频限制，大批量同步时易返回429，且偶发网络超时拖死主流程。
解决方案：在客户端设计指数退避重试，并使用线程池隔离与hard_timeout=4.0s硬超时，一旦超时自动触发Fail-Open降级，保证主流程秒级返回。
解决方案：在客户端设计指数退避重试，并使用线程池隔离与hard_timeout=4.0s硬超时，一旦超时自动触发Fail-Open降级，保证主流程秒级返回。
3.2 踩坑2：多源数据同步擦除人工资产
现象：从Fawkes全量拉取数据同步案例库时，自动同步的数据会将排查人员手工润色、精简后的crash_reason与solution冲掉。
解决方案：引入preserve_edited保护机制与数据版本标识，保证人工改过的数据不被后续同步覆盖。
解决方案：引入preserve_edited保护机制与数据版本标识，保证人工改过的数据不被后续同步覆盖。
3.3 大模型踩坑3：大模型幻觉与凭空虚构解决结论
现象：当候选案例只有故障现象但缺少真实排查结论时，模型容易产生幻觉，凭空捏造未曾验证过的排查方案或误将关联度较低的排除项当作根本原因。
解决方案：设计Prompt约束与后处理校验，强制要求模型必须基于案例库真实的crash_reason与solution生成建议；无真实结论时强行兜底归一化为need_manual人工排查。
解决方案：设计Prompt约束与后处理校验，强制要求模型必须基于案例库真实的crash_reason与solution生成建议；无真实结论时强行兜底归一化为need_manual人工排查。
3.4 大模型踩坑4：需求文档冗长导致Token暴涨与上下文溢出
现象：TAPD需求文档字数较多，且与客诉无关内容较多，若将全篇文档一次性喂给AI，会造成巨大的Token浪费，甚至超出模型上下文窗口。
解决方案：编写清洗脚本，将需求文档中不相关的内容（如实验、背景、变更说明等）去除，仅保留逻辑，再使用大模型提取关键变更内容，其后再存入知识库，并且按照业务、端（服务端和客户端）、版本号做区分，检索时先按照对应的维度做匹配，能够减小大模型上下文与token消耗50%。
解决方案：编写清洗脚本，将需求文档中不相关的内容（如实验、背景、变更说明等）去除，仅保留逻辑，再使用大模型提取关键变更内容，其后再存入知识库，并且按照业务、端（服务端和客户端）、版本号做区分，检索时先按照对应的维度做匹配，能够减小大模型上下文与token消耗50%。
3.5 大模型踩坑5：RAG检索时延过高与加速响应策略
现象：每次分析都发起知了向量检索（单次约2秒），会导致全流程时延达到3-5秒，批量任务严重堆积。
解决方案：词面门控拦截：通过BM25词面分（阈值0.30）实施门控拦截，70%以上的强匹配客诉直接跳过向量检索，响应速度提升至毫秒级。
解决方案：词面门控拦截：通过BM25词面分（阈值0.30）实施门控拦截，70%以上的强匹配客诉直接跳过向量检索，响应速度提升至毫秒级。
3.6 大模型踩坑6：模型版本切替换代中的置信度漂移
现象：模型从qwen3.6-plus切到qwen3.8-max或DeepSeek时，输出的confidence置信度数值分布发生整体漂移（模型变得过于自信），导致原本低置信客诉误推过了90%自动处置线。
解决方案：基于Badcase回归集建立模型切换时的置信度映射校准表，动态调整自动处置阈值。
解决方案：基于Badcase回归集建立模型切换时的置信度映射校准表，动态调整自动处置阈值。
4. 测开视角：AI分析结果的自动化评测与基准回归体系
4.1 Badcase自动化基准回归集建设
准备固定 Badcase 列表（20+ 条，覆盖节目缺失、Tab缺失、收藏不展示、推荐不准等常见客诉场景）。
每次调整Prompt、更换模型版本或修改后端的检索逻辑后，透传force=true强制重跑，绕过已有缓存影响。
每次调整Prompt、更换模型版本或修改后端的检索逻辑后，透传force=true强制重跑，绕过已有缓存影响。
4.2 Badcase 回归校验
核对相似度与置信度：检验AI输出的similarityduplicate/similar/new与confidence 数值是否与人工预期一致，不一致的针对性对系统做出相应调整。
抽样核对召回质量：抽样查看日志中的[CaseSuggest][BM25]Top20与 [CaseSuggest][Vector] Top5，确认召回的候选案例中是否包含了人工认可的历史案例。
核对自动处置一致性：核对满足高置信度（≥90%）时，自动触发Fawkes跟进或解决的处置动作是否与AI的disposition保持一致。
抽样核对召回质量：抽样查看日志中的[CaseSuggest][BM25]Top20与 [CaseSuggest][Vector] Top5，确认召回的候选案例中是否包含了人工认可的历史案例。
核对自动处置一致性：核对满足高置信度（≥90%）时，自动触发Fawkes跟进或解决的处置动作是否与AI的disposition保持一致。
5. 落地收益与未来展望
5.1 量化收益
客诉平均响应与排查时延降低70%。
AI分流准确率达90%+。
人力节约50%+。
AI分流准确率达90%+。
人力节约50%+。
5.2 演进方向
Token消耗与实时Usage监控。
历史排查案例摘要的自动抽取沉淀。
基于人工采纳反馈数据的在线路由模型微调。
历史排查案例摘要的自动抽取沉淀。
基于人工采纳反馈数据的在线路由模型微调。
听众收益：
1. 掌握一套可落地的混合检索(BM25+向量)+需求RAG+LLM智能治理架构，学会通过低成本、高召回的技术组合拳解决复杂业务下的文本分类与归因问题。
2. 收获高风险线上自动化场景的防御性工程实践，获取在第三方API限频、网络超时、大模型幻觉及线上数据写回等场景下的限速、Fail-Open降级与数据保护方案。
3. 获取一套实用的客诉AI分析评估与Badcase回归校验方法，通过真实Badcase回归与单元测试保障AI分析逻辑的稳定迭代。
敬请期待
......
.....
待定
待定
敬请期待
....
关注QECon公众号
关注QECon视频号
商务合作
151-2264-3988 木子
票务联系
159-0126-5561 小娟
媒体合作
135-1619-6409 皮皮
购票咨询
小娟 15901265561
