知识入库从 11 分钟到 3 秒：一次词库回填的批量化改造

客服机器人的知识问答效果一大半取决于知识库覆盖度。我们把客户积累的话术词条做成了一键导入Excel 进来清洗、入库、生效全程自动。功能上线那天没人觉得慢直到一位词条量偏大的客户登录后界面卡了十来分钟——排查到最后问题不在算法在一个典型的 N1 式请求模式上。本文复盘这次从 108 个请求压缩到 4 个的完整过程。现象登录后的十分钟静默期系统的词条回填逻辑是登录成功后比对本地词库与云端词库的差异把本地新增或变更的条目逐条同步上云云端再负责向量化与检索服务更新。小数据量下这条链路毫无问题几十条词条两三个请求就完事用户无感。问题出在词条上千的客户身上。登录后的十分钟里界面没有卡死进度提示也在动但问答能力的升级迟迟不生效。客户端日志显示回填还在进行每一轮都在一条条地 POST。把日志里的请求数一数108 个。词条规模约百级加上分批与校验每个条目都要经历提交、等对端处理、确认的完整往返。单次往返两到六秒串行乘下来就是十分钟量级。排查先排除嫌疑大的对象遇到登录慢直觉方向是登录鉴权链路和网络环境。我们先把这两条排除了鉴权本身的耗时在日志里是毫秒级同一账号换网络环境慢的时长几乎不变——耗时和条数成正比而不是和带宽成反比。这说明瓶颈在服务端处理模式不在传输。顺着条数往下挖找到了真正的放大环节云端收到词条后会同步调用对端的向量检索服务做更新。也就是说链路上每一跳都在等下一跳客户端等云端云端等向量服务。逐条 POST 的模式下这条串行等待被乘上了词条数量。对端服务本身没有故障单次处理的耗时也正常。它只是被我们的调用方式用错了——一个为批量索引设计的下游被喂成了逐条点射。这里值得多说一句N1 这个坑在数据库查询、ORM、HTTP 编排里反复出现形态不同、本质一致——把与集合规模成正比的往返留在了用户必然等待的关键路径上。识别它的信号也很统一耗时与数据条数近似线性、与网络质量弱相关。对上了这个信号基本可以直接锁定调用模式问题。根因定位之后先想清楚为什么不能只是调快一点确认根因后有人提议给回填请求加并发逐条不变同时发十条。我们否掉了理由有三对端向量服务按请求计量计费并发只是把十分钟压成一分钟账单上的请求数一分不少。规模再涨十倍问题原样回来。并发写同一批词条会引入乱序与竞争本地和云端的最终一致性更难保证。请求数与数据规模解耦才是治本。并发是缓解批量才是解法——目标应该是不管词条是一百条还是一万条请求数恒定在个位数。改造方案把逐条点射合并成批量提交拆成三层来做。接口层。词库比对结束后把所有差异条目收集成一个增量集合调用云端的批量提交接口一次 HTTP 请求body 里装整个增量。服务端落库即返回向量化改为服务端异步批量下发——对端调用的次数从每词条一次变成每批次一次计费与压力同步下降一个数量级。客户端层。收集差异、分片打包、失败重试。批量请求失败的代价高一车全退所以每个分片携带校验摘要服务端按条目返回逐条结果客户端只对失败的条目做精准重试不重放整批。批量的副作用是失败面变大所以幂等要前置设计每条目带内容摘要作幂等键服务端遇重复键直接跳过。重试因此变得安全——整个请求重放也不会产生脏数据。逐条时代这条要求形同虚设批量时代它是地基。进度层。改造后登录不再被十分钟回填拖住回填挪到后台执行前端用同步进度条把当前阶段比对、提交、生效显式化用户可以一边用一边等。回填期间产生的问答仍走本地词库不阻塞业务。灰度上线前我们做了一次双写对照同一批增量同时走旧路径逐条与新路径批量事后拉两边的落库结果做集合比对确认条目零丢失、内容零差异才把旧路径下线。批量改造动的是钱袋子路径上的一环对照成本很低值得花。踩到的坑一个 TypeScript 闭包引出的重复提交方案本身不复杂真正花时间的是一次线上复测时发现的重复提交同一批词条被提交了两次第二次还是旧内容。代码检查下来问题出在一个很不起眼的重构上。原来有一段逐条处理的逻辑被搬进一个循环闭包搬运时把一个共享的缓冲变量留在了闭包外面。循环体内对这个变量的读写全部指向同一块内存上一轮的残留数据混进了下一轮的 payload触发服务端按幂等键去重后又因为内容不一致产生告警——看起来像重复提交其实是脏数据混批。教训很直白批量化改造时逐条路径的变量不能原样搬进循环闭包每一批的状态必须每轮新建。这类 bug 单测很容易漏因为单测通常只造一批数据它只在多批 跨批复用缓冲的形态下显形。所以我们给批量路径加了针对性测试三批连续提交断言每批 payload 只含本批条目。测试补上后同型问题在后续迭代里再没出现过。效果与边界实测词条回填从十分钟量级降到秒级请求数从 108 降到个位数对端调用量下降一个数量级计费同步下降。更重要的是这条链路的耗时不再随词条规模线性增长——客户数据涨十倍登录体验不变。两点边界要说清楚。批量不等于无限大单次请求装几千条词条会让服务端处理压力和失败代价都变大所以按固定上限分片请求数仍是常数级百条量级一两个分片。批量的失败语义也比单条复杂部分成功是常态接口必须按条目返回结果客户端按条目重试否则一次网络抖动就会重放大批数据。这两条是批量接口从快走向稳的必要条件。复盘回头看这次优化的难点从来不在写代码——批量接口的实现在总工时里占比很小。值得记下的反而是三件小事一是耗时与条数成正比、与网络无关这个信号值得形成肌肉记忆它能让你在十分钟里锁定别人排查一天的方向二是加并发这种看起来在解决问题的方案要先问它把问题推远了还是消除了——我们的账单替我们回答了三是重构搬运代码时变量的作用域边界比变量的名字更重要。慢不可怕可怕的是慢得有规律却没人在找规律。参考文章微信 AI 客服自动回复怎么做2026 年 5 种方案全景盘点智能客服自动回复话术模板售前/议价/物流/售后 30 例