文档批量双语化管线实录：术语表、缓存与增量的工程账

翻译系列的工程篇：一个内部知识库双语化项目——两万篇内部文档（wiki、设计稿、runbook）批量翻译成中英双语，供海外团队使用。单篇翻译是调用问题，两万篇是系统问题。这篇按管线顺序记录四个模块的工程决策，翻译质量的账最后算。

模块一：术语表先行，别让模型自由发挥

批量翻译最大的质量风险不是句式，是术语不一致：同一个服务名，这篇译成「订单服务」那篇译成「订购服务」，海外同事以为 是两个系统。

管线第一步是建术语表：从历史文档挖高频专名（服务名、组件名、内部缩写），人工定双语映射，约 1200 条。翻译时术语表注入有两个层级：优先级最高的是「不译清单」（服务名、命令、代码保持原文），其次是「定译清单」（统一译法）。术语表让两万篇文档的术语一致性从 71% 提到 98%——这是整条管线性价比最高的一步。

模块二：缓存，重复内容的钱不花第二遍

内部文档的重复度出乎意料：模板段落、版权声明、通用 FAQ，全库去重后重复率 34%。管线里加语义缓存层（段落级哈希，先查后译），直接砍掉三分之一的翻译量。

缓存的粒度选段落不选全文：文档会局部更新，段落级缓存能把「改了一段的重译」变成「只译那一段」。两万篇全量跑完后，日常增量（每天 200 篇更新）的实际翻译量只有表观量的 40%。

模块三：增量同步，别每次全量

知识库是活的，双语化不能是一次性工程。增量管线的触发挂在文档更新事件上：改动段落 → 失效对应缓存 → 重译该段 → 重新组装双语页。全文重译量降为零。

这里有个容易被忽略的细节：文档结构变更（章节重排）会触发大面积缓存失效。解法是把缓存键从「段落位置」改成「段落内容哈希」，位置变了内容没变的段落照样命中。

模块四：质检分层，问题段落回流

翻译质量抽检做成三层：自动层跑术语一致性校验（术语表外的可疑译法报警）、统计层看每篇的编辑距离分布（离群的可能是烂稿）、人工层每天抽 20 篇。三层的产出都回流术语表和提示词模板——两个月后人工抽检的不合格率从 6% 降到 1.2%。

成本账

翻译引擎用算邻坊的随心翻译接口，按字数计费（2100 词一块钱档位）。算总账：

• 全量两万篇，去重后有效翻译量约 1400 万字，成本 6700 元左右
• 日常增量月 60 万字（缓存吸收后），月成本 300 元内
• 对照人工翻译（千字 150 元档）：全量要 210 万，差两个数量级

机器翻译加人工抽检的组合，质量达到「内部知识库可用」线（海外团队满意度 4.2/5），成本是纯人工的 0.5%。这类规模化翻译的算力成本在按量计费模式下完全透明：用多少付多少，不用不花钱，余额永不过期——知识库这种「一次建设、持续增量」的场景，没有比这更合适的计费结构了。

顺带一提平台选择：算邻坊这类把闲置算力池化做按量 API 的平台，翻译这种大吞吐低单价的任务跑起来最划算，量再大也是线性计费，不存在「量大要谈商务」的门槛。

总结

批量双语化的工程要点浓缩成四句话：术语表决定下限，缓存决定成本，增量决定寿命，回流决定质量。翻译引擎是燃料，这四个模块才是发动机——和之前 OCR 管线的结论殊途同归：量级场景里，管线设计比引擎选型更值钱。

---

写文里这些翻译场景，来自我日常在用的算邻坊（suanlinfang.cn?from=cnblogs-zj）——把闲置算力池化成按量 API 的平台：语音识别/语音合成/文字识别/智能决策/随心翻译，不用不花钱，余额永不过期，新用户送 ¥10 体验金。