拦截率从15%到55%：快手智能Oncall系统演进与落地实践

快手研发效能团队用KOncall系统，把拦截率从15%一路拉到了55%。这可不是一个简单的数字跳变，背后是从被动堵漏到源头治理的彻底转身——智能机器人已经能覆盖85%的值班场景，累计自动处理了11.6万次咨询，实实在在把研发人力从重复劳动中解放了出来。

在上一篇关于智能单元测试的文章中，我们聊过如何让AI从工具进化为质量伙伴。当代码源头的那道防线建立起来之后，一个自然的追问是：能不能让AI继续往下游走，去解决工程师在运维值班里的那些“后顾之忧”？这就是KOncall的起点。

企业内部的技术值班（Oncall），说得好听是保障业务稳定的第一线，但说穿了，它经常是一个吞噬研发效率的“黑洞”——大量琐碎、重复的咨询，加上没完没了的上下文切换，让人精疲力竭。这篇文章就来复盘一下，KOncall是怎么从早期的NLP分词方案，一步步演进到“RAG+大模型”架构的，以及团队如何在技术和运营两个维度同时发力，最终让拦截率实现了跃迁。

一、背景：快手技术Oncall的现状与挑战

内部调研的数据很直白：研发人员在Oncall上的精力投入，长期在5%到15%之间晃荡。这笔隐性成本不低，而且严重挤压了做业务的时间。深挖下去，问题主要卡在两个点上。

早期公司内部没有统一的技术值班平台。不同产品各搞一套：有人靠私聊熟人，有人在文档平台上翻群二维码，还有人用各种临时工具凑合。多入口、弱规范，让Oncall变成了一件“经验驱动”的事。结果就是，提问的人得花半天找人，处理的人被拉进无数个点对点私聊，频繁打断。更糟糕的是，处理过程的记录散落在不同地方，沉淀不下来，管理者也很难看清真实的投入成本。

有些团队实现了流程线上化，但说白了还停留在“流程驱动”阶段。现有方案大多是关键词或规则匹配，面对口语化的提问、模糊的表述，泛化能力非常有限。系统拦截率长期在15%左右徘徊，绝大多数问题还得人上。所以，真正的问题没有解决。

为了解决这些，我们开始建设KOncall。从第一天起，目标就很明确——做一款AI Native的Oncall工具。既要搭建覆盖全流程的标准化体系，又要深度融入智能问答能力，切实为工程师减负。下面重点讲讲，智能问答这块是怎么一步步从技术到运营做透的。

二、实践

核心思路很简单：引入LLM+RAG架构，把已有的知识资产用起来，构建一个AI拦截和转人工无缝衔接的业务框架。同时，为了解决流式输出的多端重连问题，落地了基于Redis pub/sub的方案。

老方案主要靠NLP，回复僵硬，泛化也差。新链路简单说就是：用户提问后，系统先通过RAG召回知识，由大模型总结后给答案；如果AI拿不准，用户也能一键转人工，交给值班团队处理。

这个链路重点解决两件事：

智能问答能降低多少人工单，取决于“全部Oncall单数量 x 智能问答介入百分比 x 机器人拦截率”。为了让更多人愿意先跟机器人聊，我们搞了消息号、IM群侧边栏入口和Web页面SDK。一段时间的治理下来，智能问答的介入百分比从最初的40%提升到了85%。

早期最大的痛是缺知识。梳理之后发现，公司里的产品知识主要以三种形式存在：一个是文档平台的文档，一个是历史Oncall工具里的QA对，还有一个是客服聊天记录。针对这些，我们打通了文档平台，帮用户导入导出QA知识，还开发了一个能从客服聊天记录里自动提炼QA的Agent——提炼后经人工确认，再入库。这套操作下来，一个不完美但总算可用的知识库建起来了，拦截率从15%提到了25%。

初期链路只支持内部IM，而且设计比较简单。测试阶段暴露出几个问题：用户可能在机器人回答过程中切换对话，切回来后重连导致回答从头开始；PC端和手机端同时打开同一个会话时，系统会并发两次请求，结果不一致。

为了解决这些问题，我们引入了消息队列。最初试了Kafka，但很快就发现不太适配。最后换成了基于Redis的pub/sub方案，原因主要有几点：

• 低延迟，即时分发。
  Kafka基于磁盘存储和批处理，端到端延迟较大。Redis全内存操作，毫秒级实时推送，响应快得多。

• 消除头部阻塞。
  Kafka为保证消息顺序得限制分区并发，长文本请求会堵住同分区的后续请求。Redis以SessionID为频道，会话级天然隔离，无重平衡开销。

• 节省资源。
  问答流数据瞬时性很强，不需要Kafka的持久化存储和多副本。Redis消息推完即弃，磁盘I/O和存储成本都省了。

• 原生多端同步。
  不同端只需订阅同一频道就能实现实时、一致的内容渲染，架构简单很多。

• 高并发线程效率。
  支持响应式编程，极少线程就能支撑很大并发。大模型推理本来就慢，一个SSE连接要维持2-5分钟，Redis的响应式IO避免了建超大线程池。

简单测一下：Kafka的发布端到接收端延迟10-20ms，Redis基本在1ms以内。后续压测时，服务端只用4个线程就逼近了推理集群的极限。从日均100条到1300条的量级增长，从来没出过流式输出的性能问题。初期技术选型的正确，为后面的扩量打下了很扎实的基础。

第一阶段把拦截率拉到了25%，但Badcase分析后发现，剩下的问题核心瓶颈还是“缺知识”或“知识不可靠”。复盘下来，公司内部平台普遍有三大“知识顽疾”：

• 显性文档滞后：
  产品迭代太快，文档往往“上线即过时”。模型检索时常常“无米下炊”。

• 隐性知识流失：
  大量长尾问题的解法散落在历史工单和群聊里，没有高效的回收机制。

• 文档切片导致幻觉：
  只要经过大模型总结，幻觉就很难避免。对于运维、部署这类技术平台，一旦误导用户，后果可能很严重。

怎么解决？得从历史工单和群聊记录里“挖”知识，同时引入FAQ这种知识格式来对抗幻觉。

历史工单群聊记录有几个天然优势：

• 复用可能性高：
  Oncall里大部分问题就是简单重复的，文档不一定有某个场景的解法，但Oncall几乎肯定处理过，而且大概率会被反复问起。

• 时效性强：
  文档严重滞后，群聊里的问答直接反映最新的业务逻辑。

• 语义完整：
  文档切片容易造成语义断裂，而群聊记录通常是针对一个问题的完整处理链路。

• 准确度高：
  Oncall单关闭前需要双方确认，所以解决方案在特定场景下是靠谱的。

基于这些，我们建立了一条“从群聊记录提炼FAQ -> 人工确认 -> 入库”的闭环链路。工单关闭后，系统自动拉取群聊记录，总结成FAQ推给处理人确认。处理人觉得没用就丢弃，觉得有价值就简单改改入库。

另外，我们还做了知识去重。新QA入库前，系统会算一下和现有知识的向量相似度。超过0.9就判定为重复，然后展示相似条目，让处理人决定是覆盖还是手动合并。这样既避免了冗余，也不会误杀有价值的补充。

通过这套运营手段，FAQ知识的入库率长期保持在20%左右，形成了一个“发现Badcase -> 补充FAQ -> 提升拦截率”的正向闭环。FAQ知识占比从5%涨到了67%，用户点击FAQ后转人工的概率降了15%，拦截率从25%提到了35%。

知识库有了，但新问题来了：很多失败案例不是因为知识库缺东西，而是用户问得太“玄”导致系统“看不懂”或“找不准”。主要有几种情况：

• 只发图不说话，大模型看不懂图片，无法召回知识。
• 描述太简单，意图识别困难。
• 知识库太大，召回范围太宽，跨领域知识混在一起导致回答混淆。
• 有些问题依赖实时数据（如故障排查），静态知识库覆盖不了。

为了解决这些，我们对问答核心链路进行了架构升级，引入了前置责任链，并总结出复杂Agent限定知识召回范围、召回动态知识的最佳实践。

用户有极强的“贴图习惯”，直接扔个报错截图，一个字不写。早期链路只支持纯文本，导致即使知识库里有答案，也因为没有关键词而召回不了。我们在前置责任链里增加了OCR环节，把识别结果自动拼到用户问题后面。经过反复测试，用“同时用户提供了一张图片，OCR解析的结果是：XXXX”这种表述效果最好。就这么一个小改动，很多原本无法处理的场景被盘活了。

初期对FAQ知识的使用方式比较粗糙，直接当普通文本碎片扔进知识库。实践后发现，FAQ这种高精度知识，不但能抑制幻觉，它里面的问题部分对澄清用户意图也特别有用。所以我们给FAQ开了条专用处理链路：在进入大模型前，先算一下用户提问和标准FAQ库的匹配度；命中高置信度的，就直接返回标准问题列表给用户选，不再走后续的生成流程。

为了让这个拦截器更“懂”用户，匹配算法经历了三次迭代：

• v1.0 关键词检索：
  用ElasticSearch做关键词召回。问题很明显：用户说“挂了”而库里是“宕机”，词不重叠就召不回。

• v2.0 向量化语义匹配：
  升级为向量检索，解决了同义词泛化问题。但新问题是，向量模型有“词袋”局限，比如“如何申请权限”和“如何回收权限”在向量空间里极度接近，但业务意图完全相反。

• v3.0 引入Rerank重排序：
  在向量召回之后，新增二次精排环节。用Cross-Encoder架构的Rerank模型做深度语义交互，试图剔除那些“形似而神不似”的错误召回。

随着知识库膨胀到数万篇文档，全库检索的信噪比开始断崖式下跌。大模型拿到一堆相关性极低的上下文，很容易产生“逻辑拼凑”式的幻觉。针对这个问题，我们和几个业务复杂、知识库庞大的团队共建，摸索出一套“先分类、再检索”的模式：比如识别出意图是“数据库异常”，路由就瞬间屏蔽掉非DBA领域的文档。限定范围检索不仅更快，更重要的是给了大模型一个干净的上下文。幻觉率明显降下来了。

静态知识搞定了，但运维场景里还有大约30%的问题离不开动态知识查询。比如容器云部署失败的原因排查，传统的RAG只能建议“登录监控平台查看”，这种“正确的废话”解决不了问题。我们和容器云团队共建，探索出了一套动态知识引入的最佳实践。

以天琴容器云为例，引入动态知识后，部署失败的诊断拦截率达到了99%。用户点击诊断瞬间，系统自动透传Pod名称、IP等参数，Agent并行调用监控API拿实时数据，同时从故障库里检索错误码解释，大模型再结合两者输出故障原因和解决步骤。整个过程一气呵成。

但在推广过程中发现，其他业务方往往没办法像天琴一样一次性提供完整上下文，更多时候得靠多轮追问。我们引入了SOP知识——明确规定在特定场景下需要遵循的步骤和收集的上下文信息，引导大模型在信息缺失时反复询问直到补全。这个思路和Anthropic后来提出的Skills理念很接近，本质就是通过详细描述解决过程，让模型具备处理复杂问题的能力。

链路优化把拦截率推到了52%左右，但FAQ推荐的精准度一直是个“槽点”。用户花时间看推荐列表，结果一个都匹配不上，体验很差。深入分析发现，Rerank环节使用的通用模型存在“水土不服”——例如“重启实例”和“重建实例”在通用语义空间里极度接近，但在业务语境里完全是两码事。

于是我们和算法团队合作，用Qwen-Reranker模型启动了专项微调。这个模型比传统判别式模型更擅长指令遵循和逻辑推理，正好切中痛点。

数据质量是胜负手。初期尝试过用DeepSeek做全自动样本标注，结果很惨——大模型本身就缺领域知识。阈值设高了，正例被大量误杀；设低了，反例又混进来。最后不得不承认，业务场景里那些微妙的“意图匹配”，通用大模型替代不了人工。转向人机协同策略后，先用Qwen-Reranker打分，然后人工校准，重点标注那些“高置信度但错误”的Case。训练数据的Good:Bad比例控制在1:1.4，专门强化模型对“形似但意图相反”样本的判别能力。最终构建了3672对训练数据。

训练基于ms-swift框架，全量微调，8个Epoch，用Pointwise Loss。离线指标上，微调后的Rerank模型在Recall、Precision、MAP、MRR上都有明显提升。上线后，FAQ推荐率从33.53%降到了21.86%，但点击后的拦截率从50.38%飙升到了66.37%。推荐系统变得“更克制，但更精准”，不再强行推低置信度的答案，对用户的无效打扰大大减少。

在日常运营中发现，有些工具的Oncall量居高不下，根子不在问答链路，而是产品本身有问题。比如某个小缺陷虽不阻塞核心流程，但导致大量重复提问；或者产品易用性差，这类问题因为优先级被挤压，长期得不到处理。为此，我们建了一套自动化“问题聚类与洞察流水线”，把Oncall问题“左移”到产研侧做源头治理。

流程很简单：允许工程师自定义筛选器定位需要分析的工单，再把工单描述、群聊记录、FAQ等结构化，让大模型提炼出涉及的产品易用性问题或缺陷。然后对所有摘要做Embedding，进行语义聚类（余弦相似度阈值0.8），零散工单被聚合为“问题簇”。最后再让大模型总结每个簇的核心问题，按工单数量分优先级，推送给产研团队并附上修改建议。这个机制把很多隐藏在产品里的“定时冲击波”提前排掉了。

【全链路治理演示表】

三、展望

把拦截率从15%推到55%，累计处理11.6万次咨询，这个数字不是终点。真正值得想的是：当机器把重复性问答都接了，下一步该往哪走？

答案很明确——让Oncall系统从一个“问题终点”，变成“能力起点”。

现在复杂问题的排查，往往靠“老员工直觉”。某条报错的典型根因、某个配置的隐藏坑点，这些经验散落在群聊里，随着人员流动而流失。我们在做的事，就是把这些隐性知识显性化。系统自动从历史工单里提炼高频问题的标准化排查路径，形成可复用的Oncall Skills。当同类问题再现时，系统不再只是“回答问题”，而是引导用户完成一整套诊断流程——让机器具备“老员工的判断力”。

拦截率提升解决的是“怎么答得更快”，但更上游的问题是“为什么这么多人来问”。Oncall量居高不下的根因，往往藏在产品设计里：一个易错流程、一段模糊文案、一个缺位的引导。系统现在能自动聚类高频问题簇，识别背后的产品缺陷或易用性问题，推送到产研侧。Oncall数据不再是“运维记录”，而是“产品改进的路标”。

新员工入职的Oncall学习成本，本质是组织记忆的断裂。未来系统会自动汇聚团队内部的文档、经验、坑点，构建团队专属知识库。新人面对问题时，系统能推荐历史方案、提示潜在风险——让“经验传承”从人际依赖变成系统内置能力。

目标不是做一个更聪明的客服机器人。而是让Oncall这件事，从一个“人力黑洞”变成“能力沉淀”，把研发人员真正解放到创造价值的地方去。