拦截率从15%到55%：智能Oncall系统的演进与实践

在企业级软件研发与维护的全生命周期中，技术值班（Oncall）是保障业务稳定的第一线，却也因大量琐碎、重复的咨询和频繁的上下文切换，成为吞噬研发效率的“黑洞”。快手内部调研数据显示，研发人员在Oncall上的精力投入长期处于5%-15%之间，这部分高昂的隐性成本严重挤占了业务开发的资源。

核心挑战：渠道碎片化与智能拦截不足

为解决这一痛点，快手研发效能团队构建了智能Oncall系统KOncall。该系统采用RAG+大模型架构，通过引入检索增强生成技术，结合私域模型微调，实现了智能问答能力的跨越式提升。经过多轮技术演进，智能机器人已介入85%的值班场景，拦截率从15%提升至55%，累计自动化处理11.6万次咨询，显著释放了研发人力。

架构升级：从NLP到RAG+大模型

在建设初期，团队深入调研发现现有Oncall体系面临两大核心挑战。首先是渠道碎片化问题：企业内部缺乏统一的技术Oncall平台，不同技术产品各自维护着独立的Oncall路径，导致找人如“开盲盒”，处理人被拉入大量点对点私聊，频繁受到打断。其次是缺乏智能拦截能力：即便部分团队已实现流程线上化，但整体仍依赖关键词或规则匹配，在面对口语化表达、语义模糊或复杂问题时泛化能力有限，系统拦截率长期徘徊在约15%。

技术架构的关键演进

团队首先引入LLM+RAG架构，复用已有知识资产，构建AI拦截与转人工无缝衔接的业务架构。在具体实施中，通过建立消息号、开发IM群侧边栏入口和Web页智能问答SDK，将智能问答介入百分比从40%提升至85%。针对知识资产分散的问题，团队打通了文档平台，协助用户导入导出QA知识，并建立了从客服聊天记录总结提炼QA的Agent，初步构建了可用的知识库，拦截率提升至25%。

流式输出的技术基建

在智能问答链路建设早期，团队遇到了流式输出的技术挑战。通过对比Kafka和Redis pub/sub方案，最终选择Redis pub/sub方案，主要基于以下考量：Redis基于全内存操作实现Token级毫秒级实时推送，延迟比Kafka低一个数量级；通过SessionID实现会话级天然隔离，消除头部阻塞问题；无需持久化存储，大幅降低资源成本。在后续压测中，服务端仅用4个线程即可支撑日均1300条智能问答，从未遇到性能问题，为平台扩量打下坚实基础。

如有侵权，请联系删除。