爬取的翻译与 LLM 共识：一项盲测基准

我们的领域术语表在非母语术语方面有两个可能的来源：一是抓取领域所有者自行发布的多语言官方页面，二是使用双模型 LLM 共识管道生成翻译。直觉告诉我们，官方页面必定是事实标准。我们对此进行了评测，结果表明直觉是错误的：在对每一处分歧进行的盲评中，LLM 的输出以 9:1 的比例胜出。本文将详细介绍实验设计、实际数据、为什么抓取的“官方”翻译会败下阵来，以及我们如何在不中断线上服务的情况下弃用爬虫。

构建多语言术语表的两种方法

领域术语表将源语言中的概念（如流程名称、产品、症状）映射到其在各个目标语言中的显示形式。术语的召回至关重要：当术语缺失时，下游的译员会退而求其次，使用通用措辞，从而失去该领域的专业语域。

第一种处理流程会抓取配对的页面。对于每个网站，我们注册其源语言 URL 和每个翻译版的 URL，以相同的预算抓取两侧内容，利用嵌入相似度对齐文本块，并将高置信度的锚点对直接提升到术语表中。这种方法在理论上很有吸引力，因为网站所有者大概率已经审校过他们自己的译文。

第二种处理流程从不查看翻译好的页面。它接收源语言术语，要求两个不同的 LLM 提供商独立翻译（彼此看不到对方的输出），并且只有当两个答案在经过归一化处理后一致，或处于一个很小的嵌入距离之内时，才接受该结果。通过筛选的术语随后会经过一个回译关卡：使用一个普通的 NMT 服务将候选译文回译到源语言，并要求其要么与原文精确归一化匹配，要么余弦距离低于按语言设置的阈值，而处于灰色地带的情况则由第三方判断来解决。

实验：盲审评委与相同条件

要公正地比较各个流程，意味着除了源文本之外，要移除所有变量。 我们抽样了 136 个术语表条目，这些条目被网络爬虫提升为主要显示形式，涵盖了爬取实际奏效的三种语言（分别有 60、50 和 26 个条目）。对于每个条目，我们都在相同条件下使用共识流程重新生成了译文：使用其在生产环境中使用的两个相同的生成器模型、完全相同的生产提示以及相同的批量大小上限，因此比较的是源文本，而不是设置。

然后我们对两项内容进行了评分。

首先是“一致率”：在经过归一化（大小写转换、全半角归一化、空白和标点符号清理、脚本层面统一）后，双模型共识本身能多大程度上准确复现爬取的形式？

其次，对于共识流程生成的结果与爬取形式不同的每一种情况，我们都进行了盲审。每个冲突项都成了一个 A/B 对，源文本被隐藏，顺序被确定性地打乱，这样评委就无法得知“A 代表爬虫”之类的信息。两个更强的模型（均未参与生成过程）根据一份旨在评估术语表适用性的评分标准独立进行评判：这个术语是专业人士会实际使用的、没有营销噪音的术语吗？只有当两位评委都同意时，我们才计为一个胜者。

数据说明了什么

标题结果，按其令我们惊讶的程度排序：

四分之三的情况下，两个无法访问官方页面的独立模型，其生成结果完全收敛于网站所有者发布的字符串。仅此一点就说明，共识机制在从未见过“官方”术语的情况下，也能够将其恢复出来。

分歧之处，情况发生了反转。在 19 个冲突中，盲审员一致偏好抓取形式的情况仅有一次。有九次他们偏好 LLM 的形式，其余九次则是平局或被判定为同样可接受。抓取方不仅仅是打平；它失去了争议阵地。

覆盖率决定了最终的选择。抓取流水线仅在网站实际发布了翻译页面的情况下才能运作，在我们的领域中，这意味着有三种语言具有实际体量，而八种语言几乎一无所有。共识流水线则为列表中的每一种语言生成内容。在测量时，它产出的已接受主要条目数量，是多年抓取所积累数量的 16.6 倍。

为什么官方页面会输：噪音是结构性的

逐一查看这 19 个冲突项就解释了失败的原因。抓取到的形式并非错误的翻译。在很多情况下，它们根本就不是翻译：

• 语言代码被捕获为术语：“body shape”的词汇表条目以字面字符串“en”作为其显示形式，这是从语言切换器中抓取到的。
• 菜单项串联：两个相邻的导航项合并成一个字符串，产生了一个看似合理但实际不存在的复合术语。
• 促销内容拼接：“300 shots”这类数量前缀被粘合到操作名称上，因为价格表紧挨着标题。
• 属于营销文案而非术语的括号旁注和成分后缀。

重点是：这些噪音在清理后依然存在。几个月前，我们已经对抓取的数据进行了一次专门的噪音清除处理，并移除了数百个受污染的行。上述例子就是那次清理工作后残留下的内容。抓取噪音是结构性的，因为页面布局会不断地产生它，而生成式管道从一开始就不会输出导航栏。

有一个需要坦诚说明的例外情况。抓取数据唯一胜出的案例是一个品牌设备的本地首选音译，这类音译由营销团队决定，模型无法推断出来。如果你的词汇表主要由具有官方本地拼写的品牌音译组成，请为这些条目保留一个手动覆盖层。我们的系统就有一个，并且在迁移过程中保留了它。

取代了爬虫的共识门

该替换流水线的描述与运行成本都很低：

term -> generator A (model 1)   -> agree after normalization? -> accept
     -> generator B (model 2)   -> else: embedding distance <= 0.20? -> accept
accepted -> back-translate -> exact match OR cosine <= threshold(lang)
         -> gray zone (<= 0.50) -> single judge yes/no -> insert or drop

在实践中很重要的设计选择：

• 两个生成器独立运行，从不查看对方的输出。 通过复制达成的一致不是真正的一致。
• 比较前的归一化可以吸收无意义的差异：全半角、大小写、空格、脚本层面的等价形式。若不这样做，一致率会下降，并且您需要为错误的不一致付出代价。
• 回译门控可以捕捉到看似可信的胡言乱语。两个模型可能会在某个流畅但错误的翻译上达成一致；通过一个普通的 NMT 服务进行一次往返翻译就能暴露这个问题，因为错误的翻译结果无法回译成源术语。
• 丢弃操作会通过一个尝试计数器来记录。一个失败三次的槽位会离开总体，这样夜间批处理就不会为了永远重复争论同一个难题而耗尽预算。当我们后来升级生成器模型时，我们选择性地只重置了那些最后一次失败原因是“不一致”或“回译失败”的槽位，而让“两个模型都认为是噪音”和“重复”的丢弃槽位保持关闭状态。升级后的模型在第一次运行时就从这次重置中恢复了 297 个额外的条目。

在实时服务运行期间停用一个爬虫

测量结果让我们做出了决定；迁移仍然需要避免破坏一个实时读取术语表的服务。操作的顺序最终比任何单个步骤都更重要：

1. 首先，发布并部署将爬虫从夜间计划任务中移除的代码。如果你在旧爬虫仍在计划任务中时删除数据，下一次运行时它会重新抓取并重新提升你刚刚删除的所有内容。
2. 在重新生成之前，将批处理工作器上的模型名称环境变量指向新的生成器，否则夜间作业将悄悄地用旧模型填充缺失的槽位。在这里，静默回退到默认模型是需要警惕的故障模式，因此我们在处理完第一个小批量后，验证了审计日志中记录的模型标签。
3. 对你将要删除的每一行进行数据库级别的备份，包括外键级联将随之删除的行。主表的 CSV 文件并不是一个回滚计划。
4. 使用锁超时分批删除，然后重新生成，再重新运行你的回归基准测试。我们的测试结果精确地保持在迁移前的值（配对命中率为 0.88），这个数字让我们得以宣布迁移完成。

常见问题解答

为什么不只使用一个强大的模型，而不是两个？ 单个模型没有“我正在猜测”的内部信号。两个独立的模型恰好在发生猜测的条目上存在分歧，而这种分歧就是过滤器。在我们的数据中，放弃存在分歧的内容并对剩余内容进行门控，将污染降至几乎为零，代价是每轮跳过大约 40% 的候选条目，而其中大部分条目在后续尝试中会成功。

这种方法可以推广到术语表之外吗？ 该模式（独立双重生成、归一化一致性、往返验证、有界重试）适用于任何输出是简短、可检查字符串的任务：实体名称、代码标识符、类别标签。它不适用于输出是长篇自由文本的情况，因为在这种情况下，归一化后的一致性不再有意义。

网络抓取是否还有价值？ 是的，对于源语言端来说是这样。官方页面仍然是了解某个领域存在哪些概念的良好来源，我们的替代方案仍然会抓取源语言页面以发现新术语。我们不再做的是将这些页面的翻译版本视为基准真相。

对于网站从未发布过的语言怎么办？ 这才是决定性的论据。网络抓取工具无法生成网站未发布的内容。在我们的十一个目标语言中，有八个的可抓取覆盖率几乎为零，因此选择并非“抓取质量与生成质量”之争，而是“生成覆盖与一无所有”之争。