LLM 批量翻译管线：防降权的重写式本地化

核心要点

• 降权元凶不是“翻译质量差”，是语言统计指纹——句长方差、虚词分布这些机器特征，Google 一嗅一个准。
• 重写式本地化：给 LLM 的任务是“用 Smallpdf 的语气重写”，不是“翻译”。
• 术语表是缰绳：每个工具页锁死行业惯用词，靠调低温度救不了术语漂移。
• 标签数偏差检测是最便宜的结构校验，源文 17 个标签、译文只剩 12 个，直接打回重跑。
• 双模型分工：服务器 GLM 管创作，本地 Qwen 管翻译，token 成本压到趋近于零。

---

凌晨一点，Search Console 的曲线像被人一刀砍断。前天还有日均两千的展示，今天 site: 一查，四十多个英文页只剩首页孤零零挂在那。

不是内容没价值，是被判了机翻站。这坑我踩过两回，被坑惨了才琢磨明白：Google 杀的不是“翻译”，是“翻译腔”。

一、Google 是怎么把机翻站揪出来的

先说人话：Google 的多语言垃圾检测，看的是统计指纹，不是逐句打分。

统计指纹：母语写作的句长方差大、虚词分布带毛刺；机翻产出句长均匀得像心电图直线，英语的 the/of/with 比例还会系统性偏离母语语料。

模板复用率：同一套中文模板直接翻成六种语言，跨语言的结构重复直接拉满，等于把“我是流水线产的”写在了脸上。

那翻译质量好一点能救吗？救不了。质量再高的直译，指纹还是直译的指纹，这是结构性硬伤。

二、重写式本地化，不是翻译

直译和重写式本地化的区别，一句话：直译是搬运句法，重写是搬运信息点。

直译：把中文的句子结构硬搬进英语，产出物语法没错，但母语读者一眼看出“这不是我们的人写的”。

重写式本地化：指令不是“翻译以下内容”，而是“你是英语母语编辑，参考这些信息点，用工具站的口吻重写”。

为什么对标 Smallpdf？因为它就是英语工具站的语气标杆：短句、动词开头、零废话。让模型抄语气模板，比让它“信达雅”有用十倍。

自问自答一下：重写会不会把关键信息改丢？会，所以信息点清单要自己控制——术语、参数、步骤一个不能少，语气随便它发挥。

三、术语表：每个工具一份行业惯用词表

批量翻译最阴险的坑不是翻错，是术语漂移。

术语漂移：同一个 merge，今天译成“合并”，明天译成“归并”，同一个站内自相矛盾，用户和算法都觉得不对劲。

解法很土但很稳：每个工具页配一份 JSON 术语表，硬塞进 system prompt。比如 PDF 合并工具页，锁定 merge→合并、split→拆分，PDF、API、JPG 这类词标注禁止翻译。

温度调到 0 能不能防漂移？防不住，别赌运气。术语表是硬约束，温度只是软倾向，两码事。

四、结构校验：标签数偏差检测

批量跑翻译，LLM 有个贱毛病：吃标签。

吃标签：模型翻译到一半把 <h2>、<li> 吞了，或者自作聪明编出源文没有的标签，页面结构直接烂掉。

我的拦截逻辑简单粗暴：正则数一遍源文和译文的标签数量，偏差超过 2 判定为烂翻译，自动打回重跑。

有人问我这么粗的校验有意义吗？有。它能拦掉九成的灾难级产出，剩下的一成语义问题靠术语表和抽检兜底。这可能是整条管线里性价比最高的二十行代码。

五、双模型分工：GLM 创作 + Qwen 翻译

跑通这套流程后我发现，创作和翻译根本不需要同一个模型。

服务器 GLM：管中文原文创作，吃的是推理和结构能力，这钱不能省，原文烂后面全白搭。

本地 Qwen：管批量翻译，Ollama 起个服务通宵跑，token 成本为零，翻废了重跑也不心疼。

这不是躺赚，躺赚的前提是管线稳定。前期校验和术语表没搭好就上量，那是突击套利思路，量越大死得越快。

顺带一个排查小技巧：批量任务的日志里全是 Unix 时间戳，对不上哪次运行出错的时候，我一般直接丢进本站的时间戳转换，秒级毫秒级都能转成可读时间，比在终端里心算快多了。

FAQ / 常见问题

直译站一定会被降权吗？

不一定，但统计指纹摆在那，等于裸奔。别赌运气，重写式的成本并没有高多少。

本地小模型翻译质量扛得住吗？

配合术语表 + 重写指令 + 标签校验，够用。裸着翻是硬伤，接盘之前先把约束搭好。

术语表要维护多少条才有效？

每个工具页 15–30 条高频词足够，覆盖标题、按钮、核心参数。求全求大反而难维护。