四款新发布模型同题翻译一封涉及延期与违约金争议的商务函件，均分从 0.98 一路掉到 0.46。最低分不是英文写得差，而是连一封完整信函都没有交付。这次模型实测把「能翻译」和「能交付商务邮件翻译」区分开了。
这次测了什么：一封不能软也不能硬的函件
题目给的是一封华岭精密制造有限公司发给 Averlane Systems Ltd. 采购总监的商务函件。核心争议是 DK-7 号生产线的交付日期：原合同约定 11 月 30 日交付，但以对方在 10 月 1 日前提供全部技术参数为前提；实际参数 10 月 9 日才到，交付日期顺延至 12 月 9 日。对方来函要求按日 0.3% 计收违约金，我方明确拒绝，并主张加急费用 RMB 480,000 由对方承担。
这题的约束很细。措辞强度即立场：「须先行说明」是郑重声明，「恕难同意」是礼貌但明确的拒绝，「尽量」不构成承诺，「只能承诺／无法保证」的承诺边界一寸都不能移。还要沿用对方英文原文里的 liquidated damages at 0.3% per day 和 acceptance criteria，日期用 12 October 2026 体例。同事草译提供了干扰项：we cannot fully agree 弱化了拒绝，we will ensure the schedule is shortened 把「尽量」强化成了保证。
难点就在这里：既不能升级冲突，也不能把合同立场翻软了。
评测流水线：并发调用与断点续跑
四个参赛模型给同一份完整 prompt，输出按行写入 jsonl，每次启动先跳过已完成模型。这样同题评测不会因为改 prompt 破坏可比性。脚本如下：
python
import os
import json
import time
from concurrent.futures import ThreadPoolExecutor, as_completed
from openai import OpenAI
client = OpenAI(
api_key=os.environ['SILVAMUX_API_KEY'],
base_url='https://www.silvamux.com/api/v1',
)
models = [
'glm-5.3-flash',
'minimax-m3',
'kimi-k3',
'deepseek-v4-pro',
]
task_prompt = '''你是一位商务与法务方向的中英译者......（完整任务、原文、背景与硬性约束）'''
output_path = 'runs/email_translation_runs.jsonl'
os.makedirs('runs', exist_ok=True)
def load_done():
done = set()
if os.path.exists(output_path):
with open(output_path, encoding='utf-8') as f:
for line in f:
try:
done.add(json.loads(line)['model'])
except json.JSONDecodeError:
continue
return done
def run_one(model, prompt):
started = time.perf_counter()
resp = client.chat.completions.create(
model=model,
messages=[{'role': 'user', 'content': prompt}],
)
elapsed = time.perf_counter() - started
return {
'model': model,
'elapsed_sec': round(elapsed, 2),
'content': resp.choices[0].message.content,
'finish_reason': resp.choices[0].finish_reason,
}
done = load_done()
todo = [m for m in models if m not in done]
with ThreadPoolExecutor(max_workers=4) as ex:
futures = {ex.submit(run_one, m, task_prompt): m for m in todo}
for fut in as_completed(futures):
result = fut.result()
with open(output_path, 'a', encoding='utf-8') as f:
f.write(json.dumps(result, ensure_ascii=False) + chr(10))
print('done', result['model'], result['elapsed_sec'], 's')脚本做的事不复杂：模型列表固定，断点续跑靠读取输出文件里已有的 model；客户端初始化只改 base_url 和 api_key，其余沿用 OpenAI SDK。并发用四路线程足够。
四个样本跑完后，交给不参赛的裁判模型按七个维度打分，每个维度 0-1 分。完整结果如下。
| 模型 | accuracy | completeness | fluency | 格式 | judgment | register | terminology | 均分 |
|---|---|---|---|---|---|---|---|---|
| GLM-5.3 | 0.97 | 1.00 | 0.97 | 0.99 | 0.95 | 0.98 | 0.99 | 0.98 |
| MiniMax-M3 | 0.97 | 0.99 | 0.88 | 0.48 | 0.94 | 0.78 | 0.97 | 0.86 |
| Kimi K3 | 0.86 | 0.66 | 0.55 | 0.08 | 0.72 | 0.69 | 0.93 | 0.64 |
| DeepSeek-V4-Pro | 0.68 | 0.18 | 0.22 | 0.05 | 0.78 | 0.48 | 0.83 | 0.46 |
GLM-5.3 靠 completeness 1.00 和格式 0.99 坐稳第一。第二名 MiniMax-M3 accuracy 0.97、terminology 0.97 都不低，但格式分只有 0.48。后两名更明显：Kimi K3 格式 0.08，DeepSeek-V4-Pro 格式 0.05，同时 completeness 也只有 0.66 和 0.18。速度上，MiniMax-M3 44.53s 最快，DeepSeek-V4-Pro 193.93s 最慢，速度和得分并不线性。这也是这类模型实测要保留耗时列的原因。
翻车现场：DeepSeek-V4-Pro 的 0.05 格式分
最低分来自 DeepSeek-V4-Pro。裁判给它的最强维度是 terminology 0.83，理由摘录是：准确保留了指定术语 liquidated damages at 0.3% per day 和 acceptance criteria，并提出 re-certification、third-party inspection body 等合适译法，但因没有最终定稿，术语选择未落实为统一成品。
格式分 0.05 的理由更直接：未按要求输出称呼、对应正文段落、结尾敬语与落款组成的信函，而是输出内部分析，且结尾明显截断。
作品节选能看出问题。开场不是 Dear Sir or Madam，而是：
我们需要回答用户翻译任务。需要仔细阅读中文原文、背景要求和干扰草译。需要翻译成英文商务函件，保持强度。需要注意格式......
坑在这里：交付物必须是成品信函。这还只是开头，后面继续用中文复述原文、逐段推敲，直到输出被截断。对读者来说，它把翻译过程当成了交付物。Kimi K3 同样掉在交付形式上，格式分只有 0.08。它的作品节选开头是：
Let me analyze this translation task carefully. The task is to translate a Chinese business letter into English. The letter concerns delivery delays ...
不是信函正文，而是分析语态。术语分 0.93 并不低，说明它知道关键表达，但没把能力落到最终格式上。
高分范本：GLM-5.3 为什么能拿 0.98
最高分 GLM-5.3 强在交付完整。裁判给出 completeness 1.00，理由摘录：原文各项信息均已译出，包括第七条第二款、第三方重新认证需三周及 so as not to affect the delivery arrangements 的目的状语，无实质遗漏。
作品节选开头整段如下：
Dear Sir or Madam,
We acknowledge receipt of your letter of 12 October 2026. With regard to the delivery date of the DK-7 production line, we must first state the following: the contractual delivery date of 30 November 2026 was expressly conditional upon your providing all technical parameters by 1 October 2026. The parameters were in fact received on 9 October 2026, and accordingly, the delivery date is extended to 9 December 2026, as expressly provided in Article 7, Clause 2 of the Contract.
这段就是一份可以直接进入商务排版的函件：日期体例一致，条款引用完整，金额、比例对应没有出错。裁判的唯一扣分点在 judgment 0.95。理由是正确处理了「恕难同意」「只能承诺／无法保证」等强度，并避免直译「顺颂商祺」；但 use our best efforts 在合同语境中可能带有较强的努力义务色彩，略强于普通的「尽量」。换句话说，它已接近可用终稿，只剩这一处需要人工复核措辞强度。
选型建议：按格式分和术语分做两件事
如果输出要直接投递或进入模板，先把格式分和 completeness 当硬门槛。表格里只有 GLM-5.3 的格式 0.99、完整性 1.00 同时过关。MiniMax-M3 的术语和准确度不差，但格式 0.48，更适合做初稿后做剥离处理，不适合把原始输出直接发出。
如果只做术语对齐或片段初译，DeepSeek-V4-Pro 的 terminology 0.83 仍有参考价值，但 completeness 0.18 表明中间会断在分析阶段，不能省掉二次成稿。
遇到强商务邮件翻译任务，judgment 和 register 两个维度要单独看。Kimi K3 的 register 0.69、DeepSeek-V4-Pro 的 register 0.48，意味着语气和称呼体系不稳定；GLM-5.3 的 register 0.98 是四款里最高。
常见问题
1. 裁判打分可靠吗？
裁判模型也有偏好，分数更适合同一裁判、同一 prompt 下的横向排序，不宜当绝对值。0.98 和 0.86 的差距不算大，但 0.46 明显是交付失败。
2. 温度参数怎么设？
强约束的商务邮件翻译建议先保持平台默认值，不急着调 temperature。若模型支持而且输出发散，再逐步降到低位。评测时保持所有参赛模型同一参数，才能比。
3. 为什么有的模型输出是思考过程？
本次翻车的两款模型直接把内部分析放进了 content 字段，而不是只交信函。调用时如果 max_tokens 太小还会截断成中英混杂片段。更可靠的方法是要求模型先输出最终信函，再用固定规则判断是否包含称呼、正文、结尾敬语。
以上脚本在 OpenAI 兼容端点下验证，四个参赛调用名为 glm-5.3-flash、minimax-m3、kimi-k3、deepseek-v4-pro。遇到非 200 响应时先看响应头 X-Request-Id，再去 silvamux.com/docs 的错误处理页核对 code。本次横评通过千木SilvaMux网关跑完并发调用，裁判模型未计参赛成绩。
