58.8% 的胜率，为什么我还是没有上线这个翻译方案
做 AI 产品时，有一种结果比失败更难处理：它看起来有效，却没有好到足以让人放心。
最近我为 OnlyTranslate 做了一轮翻译质量实验。最好的候选方案在 165 组配对比较中取得了 58.8% 的得分率，平均质量分也比现有方案高了 0.23 分。
如果只看汇总表，这很像一个应该上线的功能。它赢得更多，平均分也更高，而且方向符合直觉：给模型更多上下文，译文理应更准确。
但最后，我没有把它做成默认翻译方案。
这篇文章想记录的不是一次 Prompt 调优，而是一个更难的问题：当实验结果总体更优时，怎样判断它是否已经好到可以交给所有用户？
一个听上去很合理的假设
Section titled “一个听上去很合理的假设”浏览器翻译经常面对缺少语境的文本。
一个标题可能没有主语，一个短句可能依赖上文，一个单词在技术文档和新闻报道中的含义也可能完全不同。于是，一个很自然的想法是：不要只把待翻译文本交给模型，同时提供页面标题、所在段落和目标文本的位置。
同类产品也越来越多地提供“AI 翻译增强”“高质量翻译”或“语义重写”。这些功能通常会强调上下文、自然表达和自我检查。它们很有吸引力，我也一直想让 OnlyTranslate 的翻译质量更进一步。
但我在早期尝试中就遇到过一个问题：结果很飘。
同一套 Prompt 换一个模型，效果可能完全不同；给某个模型增加几句要求，质量明显提高，换到另一个模型却可能不升反降。有时标题和上下文能帮助消歧，有时它们反而会把模型带偏。
几句出彩的译文很容易让人兴奋，却无法证明一套方案真的更好。
所以这一次，我决定先把“可以上线”说清楚，再开始实验。
我给新方案设了什么门槛
Section titled “我给新方案设了什么门槛”我不希望默认翻译变成一条不断堆叠模型调用的流水线。
多数时候，用户只是想顺畅读完一篇文章，并不需要把每个段落都加工到可以出版。如果为了偶尔更自然的一句话，让所有内容都多调用一次模型，延迟、Token 和接口成本都会明显增加。
因此，候选方案需要同时满足几项要求：
- 默认仍然只调用一次模型；
- 不增加需要用户理解的新配置；
- 不依赖某个专用翻译模型；
- Token 和延迟不能发生质的变化；
- 在不同通用模型上，都能稳定、明显地优于现有方案。
最后一条最重要。
如果新方案只是“有时更好”，那它增加的首先是系统复杂度，而不是可靠的产品收益。
第一轮：660 次翻译，没有一个方案过线
Section titled “第一轮：660 次翻译，没有一个方案过线”第一轮实验以 OnlyTranslate 1.8.2 的简单翻译方式作为基线 L，同时准备了三套候选方案：
- A：结构化上下文。 分开提供页面标题、目标文本和所在段落；
- B：精简上下文与自检。 缩短 Prompt，同时要求模型兼顾准确、自然，并在输出前自行检查；
- C：原位标记目标。 在原段落中标出待翻译文本，帮助模型理解指代和词义。
测试材料来自 11 篇真实文章，每篇选取 5 个片段，共 55 个测试单元。我选择了 3 个通用模型，让它们分别运行 L、A、B、C 四套方案，温度和调用参数保持一致。
最终一共执行了：
55 个片段 × 3 个模型 × 4 套方案 = 660 次翻译评分时，方案名称会被随机替换为匿名标签。每个模型生成的译文，再交给另外两个模型独立排序，允许并列。我也会抽查争议译文，并记录 Token、延迟、重大错误和格式异常。
相对基线 50% 的持平线，结果如下：
| 方案 | 相对基线得分率 | 暴露出的主要问题 |
|---|---|---|
| A：结构化上下文 | 53.0% | 95% 置信区间仍跨过 50%，平均总 Token 从约 100 增至 234 |
| B：精简上下文与自检 | 50.0% | 不同模型上的效果方向会反转，重大错误率达到 15.2% |
| C：原位标记目标 | 31.8% | 格式失败率达到 42.4%，弱模型容易输出标记或错误格式 |
这里的 53.0% 不是“质量提高了 3%”。它只表示 A 在这套比较方法中略占上风，但差距不足以确认它真的优于基线。
第一轮没有任何一个方案达到上线门槛。
A 的方向最好，却让 Token 增加了一倍多；B 说明“更自然”和“输出前自检”并不是跨模型都有效的指令；C 在理论上可以让目标位置更明确，但只要模型不能稳定遵守输出协议，它就会从质量优化直接变成产品故障。
这轮实验让我第一次比较清楚地看到：上下文能帮助某些句子，不等于把上下文加入默认流程就能提高整体体验。
第二轮：终于得到 58.8%，然后呢？
Section titled “第二轮：终于得到 58.8%，然后呢？”我没有马上停止实验。
第一轮的问题也可能不是上下文本身，而是上下文太多、结构太复杂，或者 Prompt 同时要求模型完成了太多事情。
第二轮把方案收敛得更克制：完整段落仍然是翻译单元，只在标题、划词和孤立短句中补充更有针对性的语境；Prompt 回到一次调用、准确优先、不得增删的简单约束。
这一次继续使用相同的 11 个来源、55 个片段和 3 个模型，只比较基线与新的候选方案：
55 个片段 × 3 个模型 × 2 套方案 = 330 次翻译它们组成 165 组一一对应的比较。胜、平、负分别计 1、0.5、0 分，50% 代表候选方案与基线总体持平。
结果是：
| 比较结果 | 数量 | 占比 |
|---|---|---|
| 候选方案更好 | 52 | 31.5% |
| 两者持平 | 90 | 54.5% |
| 基线更好 | 23 | 13.9% |
按这套规则计算，候选方案取得了 58.8% 的得分率。平均质量分提高 0.23 分，满分为 5 分。
这是整个实验中最有希望的结果。
但当我重新阅读这些译文，问题也变得更具体：超过一半的比较没有明显差别；同一句话换一个模型，优劣方向仍可能反转；另外 23 组退步会直接表现为误译、遗漏或生硬改写。
也就是说，汇总数字告诉我“它总体更好”，实际阅读却告诉我“用户未必能稳定感受到它更好”。
这两句话并不矛盾。
平均更优，不等于适合成为默认值
Section titled “平均更优，不等于适合成为默认值”离线实验关心的是：在一批样本上，候选方案是否拿到了更多分。
产品默认值还要回答另外几个问题：
- 用户能否感知到提升？
- 退步发生时，代价有多大？
- 换模型、换网页、换语言后，方向是否仍然一致？
- 为了这点提升，系统承担了多少成本和故障面？
假设一个方案在 100 个段落里让 20 个略微变好，却让 5 个出现明显误译。平均分可能仍然上升，但连续阅读时，那 5 次错误很可能比 20 次细微改善更容易被用户记住。
翻译也不是一个“赢了就结束”的排序游戏。用户真正关心的不是某个方案在匿名评测中拿了多少比较积分，而是能不能相信页面上的译文。
因此，58.8% 对我来说是一个“值得继续研究”的信号，却不是一个“应该替换默认值”的结论。
我也试过把增强做成一个按钮
Section titled “我也试过把增强做成一个按钮”既然全局增强不够稳定，另一个自然的想法是按需处理：普通翻译保持不变，用户觉得某一段不好时，再点击“精译”或“优化译文”。
这样可以把额外调用限制在少数段落，不会拖慢整篇文章。
但做下去之后，我发现它只是减少了成本，并没有解决质量判断：
- 模型经常只是换一种说法，并没有发现和修正明确的问题；
- 标题、卡片、导航和 GitHub 首页都可能出现短文本，很难决定按钮应该放在哪里；
- 如果只在正文段落提供入口，就必须先可靠判断什么是正文；
- 即使增加“先审校、再决定是否修改”的结构化输出，最终仍要依赖模型不稳定的判断。
一个按钮很容易做出来，但要证明它按下去之后大多数时候真的更好，并不容易。
所以我最后也放弃了这个入口。
最后的产品选择：把难点交给划词
Section titled “最后的产品选择：把难点交给划词”OnlyTranslate 现在采用了一个更简单的方案：
- 普通网页翻译继续优先保证稳定和速度；
- 页面标题只作为弱上下文，模型只能输出待翻译文本；
- 遇到不满意或难理解的内容时，由用户主动划词翻译；
- 划词只处理被选中的词、短语或句子，并使用所在段落的局部语境。
划词翻译并不是换了名字的“高质量模式”。它解决的是另一个问题：用户已经明确指出了哪里需要更多帮助。
这个信号非常重要。系统不再需要猜测每个段落是否值得付出更多成本，也不必把实验中的不稳定性扩散到整篇页面。只有真正遇到理解困难的地方，用户才会主动请求更丰富的语境。
它未必是最炫的方案，却更符合我对默认功能的要求：可预测、可解释，而且失败范围有限。
这次实验留下的四个判断
Section titled “这次实验留下的四个判断”1. 先写上线标准，再看漂亮样例
Section titled “1. 先写上线标准，再看漂亮样例”如果没有提前设定“跨模型稳定、明显优于基线”的门槛，我很可能会在看到 58.8% 时说服自己上线。
目标在实验之后才定义，实验就很容易变成给既定结论寻找证据。
2. 模型差异不是噪音，而是产品现实
Section titled “2. 模型差异不是噪音，而是产品现实”如果功能允许用户填写自己的模型和接口，那么跨模型波动就不能在评测中被平均掉。某套 Prompt 只在一个模型上表现好，不是通用方案，只是一个模型适配。
3. 协议失败也是质量失败
Section titled “3. 协议失败也是质量失败”原位标记方案也许在“理解上下文”这件事上有价值，但 42.4% 的格式失败已经让它失去产品意义。
在真实系统里，模型输出多一个标记、少一段文字或破坏既定格式，都不是外围工程问题，而是最终质量的一部分。
4. 没上线的实验也减少了未来的决策成本
Section titled “4. 没上线的实验也减少了未来的决策成本”这次没有得到一个新功能，却排除了几条看似合理的路线：复杂上下文、通用自检指令、依赖输出协议的原位标记，以及没有明确改善判断的“精译”按钮。
负结果并不等于没有产出。它们让下一次实验不必从同一个直觉重新开始。
AI 产品很容易陷入一种节奏：模型又进步了，竞品又增加了一个入口，我们也应该尽快跟上。
但一个功能是否值得存在，不能只看它能不能做出来，也不能只看最佳样例有多惊艳。它还要看普通样例中是否有稳定收益，失败时会伤害什么，以及它是否让整个产品变得更可信。
这次实验让我更愿意接受一种不那么兴奋的结论：暂时不做，也可以是一次完整的产品工作。
58.8% 不是失败。它只是还没有好到足以替代一个简单、稳定、已经被用户理解的默认方案。
OnlyTranslate 是我正在开发的开源双语阅读浏览器扩展，支持网页正文、视频字幕和本地 EPUB：
如果你也在做 AI 功能评测，我很想知道你如何定义“足以上线”的门槛，尤其是当平均指标变好、个体失败却仍然明显的时候。