在《采纳率从3%到80%：智能单元测试生成的进化之路》中，快手研发效能团队分享了如何通过智能单测架构的多次演进升级，将AI从提效工具进化为质量伙伴。当AI成功在代码源头构筑起质量防线后，如何让它继续向下游延伸，解决工程师在日常运维中的“后顾之忧”，便成为我们探索的下一个关键命题。
在企业级软件研发与维护的全生命周期中，技术值班（Oncall）是保障业务稳定的第一线，却也因大量琐碎、重复的咨询和频繁的上下文切换，成为吞噬研发效率的“黑洞”。为此，快手研发效能团队建设了智能Oncall系统：KOncall。经过多轮实践及技术演进，智能机器人已介入85%的值班场景，拦截率从15%提升至55%，累计自动化处理11.6万次咨询，显著释放了研发人力。
本文将复盘KOncall平台在智能问答领域的演进历程，即从早期的NLP分词方案，升级至当前的RAG+大模型架构。团队通过构建知识运营体系、优化智能问答核心链路以及私域模型微调，使系统在语义理解与召回精度上取得了突破。此外，团队进一步挖掘了Oncall数据的长尾价值，实现从被动响应到源头治理的转变。
一、背景：快手技术Oncall的现状与挑战
快手内部调研数据显示，研发人员在Oncall上的精力投入长期处于5%-15%之间，这部分高昂的隐性成本严重挤占了业务开发的资源。深入调研发现，现有的Oncall体系主要面临“渠道碎片化”与“缺乏智能拦截”两大核心挑战：
1.1 渠道碎片化：找人如“开盲盒”，处理被频繁打断
在早期阶段，公司内部缺乏统一的技术Oncall平台，不同技术产品各自维护着独立的Oncall路径：有的通过私聊熟人，有的需要在文档平台中检索对应的支持群，还有的依赖各类临时工具进行沟通。这种多入口、弱规范的现状，使Oncall逐渐演变为一种“经验驱动”的过程。尽管部分团队尝试引入流程化工具来规范处理，但由于缺乏统一的平台级整合，反而进一步加剧了入口的分散。这种碎片化带来了多重负面影响：一方面，问题发起人需要耗费大量时间“找对人”；另一方面，处理人被拉入大量点对点私聊，频繁受到打断；同时，处理过程作为公司知识资产分散在不同平台，难以沉淀与复用；管理者也难以从全局视角评估真实的Oncall投入成本。
1.2 缺乏智能拦截：线上化不等于智能化，拦截能力薄弱
即便部分团队已经实现了Oncall流程的线上化，但整体仍停留在“流程驱动”阶段，缺乏真正的智能能力。现有方案大多依赖关键词或规则匹配，在面对口语化表达、语义模糊或复杂问题时，泛化能力极其有限，难以有效理解用户意图。因此，系统拦截率长期徘徊在约15%，绝大多数问题仍需人工介入处理，并未从根本上缓解一线研发人员的负担。
为了解决这个问题，我们着手建设KOncall，主要解决内部技术平台的Oncall问题。在建设初期，我们就明确做一款AI Native的Oncall工具，既搭建覆盖全流程的Oncall标准化体系，更深度融合智能问答能力，切实为一线Oncall工程师减负提效。本文重点讲述智能问答的演进过程，即我们如何从技术和运营两个方面共同做功，实现快手智能Oncall拦截率从15%到55%的跃迁。
二、实践
2.1 架构跃迁构建智能基座，拦截率从15%到25%
核心策略：引入LLM+RAG（检索增强生成）架构，并复用已有知识资产，构建了AI拦截与转人工无缝衔接的业务架构，并在落地过程中，建立了基于Redis pub/sub的流式输出架构，有效解决流式输出多端重连的问题。
2.1.1 构建AI拦截与转人工无缝衔接的业务架构
为解决原有Oncall业务体系自动拦截主要依赖NLP，回复僵硬、泛化能力差的问题，我们在整体Oncall链路中引入了智能问答机器人，通过RAG召回知识，由大模型总结后回复用户，在AI未能准确回答的情况下，也允许用户一键转人工，由服务目录值班人进行人工服务。
这个链路主要解决两个问题：
尽可能覆盖更多问答入口。智能问答降低的人工单量=全部Oncall单数量x智能问答介入百分比x机器人拦截率。为了让智能问答机器人覆盖更多的用户提问入口，我们建立了一系列消息号，开发了IM群侧边栏入口和Web页智能问答SDK，在IM私聊、IM群聊、产品WEB页面这三个用户高频提问场景，都引导提问人先与机器人聊天。通过一段时间的治理，我们的智能问答介入百分比从最开始的40%提升到85%。
尽可能复用已有知识资产。智能客服机器人早期最严重的问题是缺少知识，经过梳理，我们发现公司已有的产品知识主要有以下三种形式。
以文档的形式放在Docs、Techlink等文档平台。
以QA对的形式存在于客服号等已有Oncall工具中。
以客服聊天记录的形式存在于客服号、啄木鸟等已有Oncall工具中。
针对这几种知识，我们先后打通文档平台，协助用户导入导出QA知识，并建立了从客服聊天记录总结提炼QA的Agent，经人工确认后以QA对的形式导入知识库。通过尽可能复用已有知识资产，我们建立起一个不完善但相对可用的知识库。智能问答拦截率从原有基于NLP时代的15%，提升到25%左右。
2.1.2 基于Redis Pub/Sub，构建多端、流式、可重连的对话管理基座
在智能问答链路建设早期，我们的问答链路仅支持KIM（内部IM平台），且整体设计比较简单，整体时序图如下：
在消息队列的选型中，我们首先考虑了Kafka，但在初步尝试后，我们就发现Kakfa并不适合这个场景，最终经过调研，切换到了基于Redis的pub/sub方案，主要原因是：
极低延迟与即时分发：Kafka基于磁盘存储与批处理机制，端到端延迟较大。Redis基于全内存操作，采用Fire-and-Forget模式，能实现Token级的毫秒级实时推送，响应延迟明显比kafka要低。
消除头部阻塞（HOL Blocking）：Kafka为保证消息顺序必须限制分区（Partition）并发，导致长文本请求阻塞同分区的后续请求。Redis Pub/Sub以SessionID为频道（Channel），实现会话级的天然隔离与并行处理，无重平衡开销。
降低计算与存储资源成本：问答流数据具有瞬时性，无需Kafka提供的持久化存储与多副本冗余，强行使用Kafka本身就是一种浪费。Redis的Pub/Sub模式下，消息推完即弃，极大地降低了磁盘I/O压力与存储成本，单机支撑并发能力提升一个量级。
原生支持多端状态同步：Kafka的消费组模型在处理 PC/移动端同时在线时逻辑复杂。Redis Pub/Sub原生支持多订阅者模式，不同端只需订阅同一频道即可实现实时、一致的内容渲染，架构逻辑大幅简化。
高并发下的线程效率：Redis的Pub/Sub支持响应式编程，这样极少的线程就可以支撑很大的并发容量，考虑到大模型推理较慢，一个SSE连接时长要保持2-5分钟，同时保持的连接数量可能较多，Redis的响应式IO避免了建立一个超大线程池，规避了 Kafka的线程切换瓶颈与内存损耗。
在简单的测试中，Kafka消息的发布端、接收端延迟常在10ms-20ms上下， 而redis pub/sub的发布端、接收端延迟基本在1ms以内。在后续压测中，我们的服务端仅用4个线程，就可以在压测过程中逼近推理集群的极限，初期合理的技术基建为后续平台扩量打下了坚实的基础，后续智能问答数量从日均100条上升到日均1300条，从未遇到因为流式输出导致的性能问题。
2.2 知识运营做功，拦截率从25%到35%
2.2.1 企业内部知识建设现状
在上一个阶段，我们通过复用存量知识资产与大模型原生的推理能力，初步构建了智能问答的基础链路，将拦截率提升至25%。但在随后的 Badcase分析中，我们发现剩余未能拦截或误答的案例，核心瓶颈在于模型侧缺乏领域知识或获取的知识可靠性不足。
通过对公司内部业务平台的深度复盘，我们识别出阻碍智能化进阶的三大“知识顽疾”，并摸索出对应的解决方案。
显性文档滞后： 内部产品处于高频迭代状态，缺乏专职维护人力，导致文档平台的内容往往“上线即过时”。这种“文档失鲜”现象让模型在检索时陷入“无米下炊”的窘境；
隐性知识流失：海量的长尾问题解决方案散落在历史工单和日常群聊的对话流中，因缺乏高效的回收机制，这些宝贵的经过人工校验的“领域经验法则”沦为无法利用的废弃资产；
基于文档切片的知识无法解决幻觉问题：虽然模型能力一直在进步，但只要经过大模型总结，幻觉问题就难以避免，而内部技术平台大多是运维、部署、技术中间件，一旦幻觉误导没有经验的用户，就可能造成严重的后果。
2.2.2 FAQ类型知识的重新引入
经过探索，我们认为应当拓宽知识来源渠道，从历史工单的处理群聊记录中提取知识，同时，应当引入FAQ知识格式，以解决基于知识切片的幻觉问题。
首先，历史工单群聊记录有以下优势：
被复用的可能性高：Oncall中绝大部分问题都是简单而重复的，文档中不一定有某个场景的具体使用方式、某个报错的具体处理措施，但Oncall几乎一定处理过，而且处理过的问题往往会被重复问起。
时效性很强： 内部工具迭代极快，文档往往严重滞后。而群聊中的问答直接反映了最新的业务逻辑和“隐性知识”。
天然语义完整： 文档切片（Chunking）的传统方式，很容易造成语义断裂，有可能被分到同一个块中的内容完全是两个主题，而同一主题的内容却被切分为多个块导致漏召回，而群聊记录一般是针对一个问题的完整处理链路，语义上天然很完整。
准确性较高：因为Oncall单的关闭一般都要经过发起人和处理人双方确认，一般确实是解决了用户问题，其在特定场景下的准确性很高。
经过一段时间的摸索，我们建立起一套从Oncall处理群聊记录中总结提炼FAQ，并经人工确认后置入知识库的闭环知识补充链路。其整体时序图如下：
其次，我们将FAQ定位为高准确度的核心知识资产，因此引入了人工确认机制。在Oncall工单关闭后，系统自动执行群禁言并拉取群聊记录，经总结提炼后推送至处理人进行最终确认。处理人若判定该问题无需沉淀，可直接丢弃；若认为具备留存价值，则仅需进行简易修订即可保存。
与此同时，我们构建了一套知识去重逻辑。在知识入库前，系统会计算新生成QA与现有知识库的向量相似度（Embedding Similarity。若相似度超过0.9，系统即判定为“重复知识”，并自动关联展示已存在的相似条目，引导处理人进行差异比对与确认。通过人机协同的决策机制，由人来决定是“覆盖”还是“手动合并”，在有效规避知识冗余的同时，防止误杀有价值的补充信息。
基于FAQ知识本身的优点，我们还建立了将高频召回的文档知识总结为FAQ，并经人工确认后落库的链路，极大提升了FAQ知识的覆盖度。配合扎实的运营手段，FAQ知识的入库路长期保持在20%左右，形成了“发现Badcase->补充 FAQ->提升拦截率”的正向闭环，FAQ知识占比从最初5%提升到67%，用户点击FAQ后转人工的概率降低15%，整体拦截率从25%提升到35%左右。
2.3 智能问答核心链路优化，拦截率从35%到48%
在上个阶段，通过构建“SOP标准库+FAQ自进化”的双引擎体系，我们成功解决了“没有知识”的难题，将拦截率稳步提升至35%，但我们很快发现，大量的失败案例并非因为知识库缺失，而是因为用户提问方式的复杂性导致系统“看不懂”或“找不准”。主要包含以下几种情况：
图片无法识别：用户只发图不加任何文字解释，大模型理解不了图片、也无法进行知识召回，只能直接拒绝回答。
用户意图难以理解：用户描述过于简单，意图识别困难，FAQ匹配命中率也显著下降。
知识库召回范围过于宽泛：较复杂业务的智能机器人对应的知识库一般非常庞大，包含多个领域的知识，而用户的问题召回了多个看起来相似但实际跨领域的知识，导致回答混淆。
实时数据缺乏：部分Oncall问题的解决依赖于实时数据，特别是故障排查场景，如消息队列延迟、容器部署失败等，静态知识库无覆盖。
为此，我们对问答核心链路进行了架构升级，引入了前置责任链，并总结推广了复杂Agent限定知识召回范围、召回动态知识的最佳实践，在复杂业务方进行推广。
2.3.1 攻克视觉盲区：基于拦截器架构的OCR多模态解析
我们在历史工单中发现，用户在Oncall时有极强的“贴图习惯”——直接扔一张报错截图问“这个怎么解”，而往往不附带任何文本描述。经过一段时间的线上数据分析，我们发现绝大多数截图都包含一些有用的文字信息，主要是web页报错截图、shell脚本报错截图。由于早期的处理链路仅支持纯文本，传统模型无法读取图片中的 `Error Code` 和 `Stack Trace`，导致即使知识库中有完美答案，也因为提取不到检索关键词而无法召回，最终造成拦截失败。
为此，我们在前置责任链中增加了OCR识别环节，并将结果自动追加到用户问题中，最终提问大模型的用户问题会变成“XXXX（用户原始问题）同时用户提供了一张图片，OCR解析的结果是：XXXX”，经过反复测试，“同时用户提供了一张图片，OCR解析的结果是” 这个语句片段能够有效提升大模型的表现，比直接将OCR结果拼接到用户问题后面效果要好。
2.3.2 攻克意图模糊：基于责任链的相似问推荐与 Ranking 进化
在KOncall建设初期，我们尚未充分认识到QA知识的特殊价值，较为依赖大模型的总结提炼能力，将包括从客服号导入的FAQ在内的所有知识均作为普通文本碎片存入知识库。然而实践表明，FAQ作为经人工校验的高精度知识，不仅在抑制模型幻觉方面效果显著，其QA结构中的问题部分也更利于澄清用户意图。为此，我们针对FAQ知识增设了专用处理链路。在进入大模型生成环节前，该拦截器会先行计算用户Query与标准FAQ库的匹配度；一旦命中高置信度问题，便直接“短路”后续生成流程，返回标准问题列表供用户选择。
为了让这个拦截器真正“懂”用户，我们的核心匹配算法经历了从“关键词”到“私域模型微调”的三次关键迭代：
v1.0关键词检索（ES时代）： 初期我们利用ElasticSearch进行关键词召回。
缺陷： 极度依赖用户的精准输入。用户问“挂了”而库里是“宕机”，因词汇不重叠导致无法召回，拦截器形同虚设。
v2.0向量化语义匹配（Embedding时代）： 我们将策略升级为“Query-to-Question”的向量检索。通过计算用户提问向量与FAQ标准问题向量的余弦相似度（Cosine Similarity），使用向量模型是bge-m3，设定0.8为推荐阈值。
收益：解决了同义词泛化问题。
新痛点（语义冲突）：向量模型存在“词袋模型”的局限性。如用户问“如何申请权限”，向量检索可能会高分召回“如何回收权限”。两者关键词高度重叠且向量空间极度接近，但业务意图完全相反。这种错误的推荐不仅没能拦截问题，反而给用户造成了误导。
v3.0架构升级：引入Rerank重排序（粗排+精排）：为了解决v2.0中的语义冲突问题，我们在向量召回（粗排）之后，新增了二次精排（Rerank）环节。
策略：引入通用的bge-m3 Rerank模型。不同于向量检索计算空间距离，Rerank模型采用Cross-Encoder架构，能够对“问题-答案”对进行深度的语义交互比对，试图剔除那些“形似而神不似”的错误召回。
(注：虽然架构升级，但通用Rerank模型在特定业务场景下依然存在水土不服，这也直接推动了我们在STEP 4进行私域微调。)
2.3.3 攻克噪音过大：意图分流与知识剪枝
通过OCR和推荐算法，我们让系统具备了基础的感官和语感。但随着知识库规模指数级膨胀至数万篇文档，我们撞上了新的瓶颈——全库检索（Global Retrieval）的信噪比断崖式下跌。大模型在处理相关性极低（Low Correlation）的上下文时，极易产生“逻辑拼凑”式的幻觉。针对这类问题，我们与几个业务较为复杂、知识库庞大的业务方进行了共建，摸索出一套意图分流和知识剪枝的工作流编排最佳实践并推广业务使用，其整体逻辑如下：
在上述的例子中，当识别到意图为“数据库异常”时，路由会瞬间屏蔽掉非DBA领域的干扰文档。这种限定范围检索（Scoped Retrieval）不仅让检索速度更快，更重要的是，它为大模型提供了一个“干净”的上下文环境。通过这种“先分类、再检索”的模式，我们成功解决了大模型因背景噪音过多而导致的逻辑误判，显著降低了幻觉率，让回答更具专业确定性。
2.3.4 攻克动态知识缺失：工作流Agent与动态工具链
至此，针对所有“已记录在案”的静态知识，我们的拦截体系已取得显著成效。然而，运维场景中仍有约30%的问题无法仅靠静态知识解决，必须引入动态知识查询工具。典型场景包括容器云部署失败的原因排查，或系统突发性能下降的故障诊断。显然，传统的RAG系统仅能检索静态文档，其回复往往流于形式，例如建议用户“登录监控平台查看”，这种“正确的废话”既无法切实解决用户问题，有时也难以直接暴露内部数据。为此，我们与容器云团队展开共建，探索出了动态知识引入的最佳实践。
引入动态知识查询Tool
在天琴容器云部署失败的诊断场景下，引入动态知识后的拦截率达到了99%，其交互流程如下：
SOP知识的引入与应用
然而在推广天琴的实践中，我们发现其他业务方往往难以像天琴一样一次性提供完整的上下文信息，更多时候需要依赖多轮追问。若仅泛泛地指示大模型“在信息不全时追问用户”，由于缺乏明确的追问目标，模型往往意图模糊，导致要么沉默不语，要么陷入无休止的提问。为解决这一难题，我们在复杂场景下引入SOP知识，即明确规定在特定场景下需遵循的步骤及收集的上下文信息，引导模型在信息缺失时反复询问直至补全。这种SOP知识的理念与Anthropic后续提出的Skills思路高度契合，两者均旨在通过详细描述问题解决过程，赋予大模型处理复杂问题的能力。
2.4 介入微调让模型更懂快手知识，拦截率从48%到52%
通过持续优化智能问答核心链路，我们将智能问答的拦截率提升至52%的最优水平。然而，FAQ推荐环节的精准度一直备受用户诟病。在部分场景下，不准确的推荐不仅未能解决问题，反而消耗了用户的注意力资源；特别是当用户仔细查阅推荐列表却发现无一匹配时，会严重影响使用体验。
经深入分析，我们发现在FAQ召回后的Rerank环节，通用的bge-m3-reranker模型表现欠佳。例如，“重启实例”与“重建实例”在通用语义空间中极度接近，被模型判定为强相关，但在实际业务语义中两者却是互斥的。为此，我们与算法团队展开合作，利用Qwen-Reranker模型优于传统判别式模型（如BERT-based）的指令遵循与逻辑推理能力，启动了专项微调。
2.4.1 数据工程：从“自动化迷信”到“人机协同”
数据质量是本次优化的核心胜负手。我们完整经历了从低成本自动化到高质量精细化的认知迭代：
自动化标注的局限性： 为了降低数据获取成本，我们初期尝试使用DeepSeek进行全自动样本标注，将线上收集到的用户问题和可能匹配的FAQ问题一并交给大模型来进行相似度打分，本意是通过大模型来生成训练数据。但实际结果惨淡，主要原因是大模型其实本身也缺乏业务领域知识。Prompt中如果要求区分度高一些，那么他就会为大量正例打很低的相关度分，如果要求区分度低一些，大量反例又会获得很高的相关度分。最终我们不得不承认，业务场景中微妙的“意图匹配”包含大量隐性上下文，通用LLM无法替代人工判断。
高质量数据清洗：吸取教训后，我们转向人机协同策略。首先用Qwen-Reranker模型对相似度进行打分，之后人工校准，专门针对开源模型判断错误（High Confidence, Wrong Prediction）的Case进行特殊标注，并将Good:Bad比例严格控制在1 : 1.4，重点强化模型对“形似神似”但“意图相反”样本的判别能力，最终构建出3672对训练数据。
2.4.2 训练实战与模型效果
训练配置： 基于`ms-swift`框架，采用全量微调 (Full Fine-tuning) 策略，训练8个 Epoch，并使用`Pointwise Loss`作为优化目标。
离线指标对比：
2.4.3 线上业务收益
该Rerank模型上线后，FAQ推荐率从33.53%降至21.86%，但点击后的拦截率从50.38%大幅跃升至66.37%，说明推荐系统表现呈现出“更克制，但更精准”的特征，不再强行推荐低置信度的答案，减少了对用户的无效打扰。
2.5 避免重复性问题，拦截率从52%到55%
在日常运营分析中，我们发现部分工具的Oncall量居高不下，并非源于问答链路的不足，而是产品本身存在缺陷或设计不合理（易用性差）。例如，某产品线上发版引入的一个微小缺陷，虽不阻塞核心流程且难以复现，却导致该产品Oncall拦截率急剧下跌，且工单中出现大量与该缺陷关联的重复问题。一般缺陷的修复周期较短，影响持续时间有限；但产品易用性问题往往因其他高优先级需求的挤压，长期无法排期治理，这类问题在Oncall中反复出现，对拦截率造成持续负面影响。为此，我们构建了一套自动化的“问题聚类与洞察流水线”，推动产研侧的源头治理，将Oncall问题“左移”。
首先，我们允许Oncall工程师通过自定义筛选器，基于时间范围、问题分类字段等维度，精准定位需要分析总结的Oncall工单数据。获取目标工单后，我们将工单描述、群聊记录、已确认的FAQ等信息进行结构化梳理，调用大模型对该工单处理过程中涉及的产品易用性问题或缺陷进行摘要提炼。随后，我们对摘要数据进行Embedding处理，对所有工单进行语义聚类，通过计算向量间的余弦相似度（阈值设为0.8），将零散工单聚合为若干“问题簇”，并再次调用大模型对每个“问题簇”进行总结，提炼出核心易用性问题或缺陷摘要。生成问题后，我们根据问题簇包含的工单数量，对易用性问题或缺陷摘要进行优先级分级，将高优先级的聚类结果推送给平台产研团队，并附上具体的修改建议，推动问题从源头解决。
【全链路治理演示表】
三、展望
KOncall系统将拦截率从15%推至55%，累计处理11.6万次咨询——这个数字本身不是终点。真正值得追问的是：当机器接管了重复性问答，下一步该往哪里走？
我们的答案是：让Oncall系统从“问题终点”变为“能力起点”。
3.1 让经验成为系统能力
今天，一个复杂问题的排查往往依赖"老员工直觉"——某条报错的典型根因、某个配置的隐藏坑点、某种场景的排查捷径。这些经验散落在群聊记录里，随着人员流动而流失。
我们在做一件事：把这些隐性知识显性化。系统将从历史工单中自动提炼高频问题的标准化排查路径，形成可复用的Oncall Skills。当同类问题再现时，系统不再只是"回答问题"，而是引导用户完成一整套诊断流程——让机器具备"老员工的判断力"。
3.2 让问题止于源头
拦截率的提升解决了"怎么答得更快"，但更upstream的问题是"为什么这么多人来问"。
我们发现，Oncall量居高不下的根因，往往藏在产品设计里：一个易错流程、一段模糊文案、一个缺位的引导。系统现在能自动聚类高频问题簇，识别背后的产品缺陷或易用性问题，并推送诊断报告至产研侧。Oncall数据不再是"运维记录"，而是"产品改进的路标"。
3.3 让知识不再流失
新员工入职的Oncall学习成本，本质是组织记忆的断裂。未来系统将自动汇聚团队内部的文档、经验、坑点，构建团队专属知识库。新人面对问题时，系统能推荐历史方案、提示潜在风险——让"经验传承"从人际依赖变成系统内置能力。
我们的目标，不是做一个更聪明的客服机器人。而是让Oncall这件事，从"人力黑洞"变成"能力沉淀"，把研发人员真正解放到创造价值的地方去。
