Cohere North Small Translate 是什么？中文翻译、许可、部署与验收指南

一、这次发布真正改变了什么

North Small Translate 是 North 家族中的首个专用翻译模型，而不是通用聊天模型临时承担翻译任务。专用模型的价值不只是“能把中文变成英文”，而是把输入语言、目标语言、术语、文档边界、批处理和评测变成稳定接口。Cohere 官方发布页把它定位为主权 AI 与企业翻译基础设施的一部分，并提供 API、公开权重和商业部署三条路径。对采购者而言，最重要的变化是可以在同一个候选上比较托管调用与私有部署，而不是被迫在完全不同的模型之间迁移。

需要把发布时间与能力边界记入评估卡。官方博客日期为 2026 年 9 月 10 日，文档中的模型 ID 为 north-small-translate-1-0。模型支持文本输入和文本输出，没有把图片、音频或扫描 PDF 直接当作翻译输入。扫描文件仍然需要 OCR，版式文件仍然需要解析和重排，字幕仍然需要时间轴处理。把这些上游能力误算成模型能力，会让试点在演示阶段看起来顺利，却在真实生产文件上失败。

二、规格表：哪些是已核对事实，哪些仍需自己验证

上表的第二列来自 Cohere 的模型文档与发布说明。第三列才是项目验收的核心：官方规格只能证明厂商公开了什么，不能证明你的语言对、文档类型、术语库、硬件和安全策略一定合适。评审会议应把“规格核对”和“业务验证”分成两张证据表，避免用一个漂亮的总分替代真实错误分析。

三、中文是否支持：不要只看语言名单

官方支持列表同时包含 Chinese (Simplified) 与 Chinese (Traditional)，因此可以确认简体和繁体属于标称支持范围。但“支持中文”并不能回答中文用户真正关心的问题：简繁转换是否保持专有名词，中文到英文时是否擅自补充主语，英文到中文时是否把产品名意译，金额与日期是否按地区格式重写，技术文档中的命令和占位符是否被破坏，客服语气是否符合品牌规范。这些差异必须通过自己的测试集观察。

建议把中文至少分成八类：大陆简体说明文、繁体中文说明文、客服口语、法律与隐私条款、制造业操作步骤、软件界面短句、包含 Markdown 或 HTML 的技术文本、包含人名地名和型号的混合文本。每类准备普通样例、边界样例与拒绝样例。普通样例验证基本可用性，边界样例暴露数字、否定词、嵌套结构和长上下文问题，拒绝样例验证系统在输入缺失、语言标错或文本不可解析时是否明确报错。

还要区分“翻译质量”和“格式保真”。一段文字语义正确，但丢失列表序号、变量名、脚注引用或表格单元格，同样不能进入生产。评测记录中应分别设置语义、术语、数字、格式、语气、遗漏、增译七个字段；任何一个关键数字、否定词或安全步骤发生错误，就应该触发人工复核，而不是被平均分掩盖。

四、API 路径怎样开始，怎样避免演示代码变成生产事故

官方文档给出的模型 ID 可以通过 Cohere 的聊天接口调用。开发者首先在隔离测试环境创建可撤销、最小权限的密钥，只把密钥放在进程环境或受管密钥服务中，绝不写进脚本、仓库、截图和报告。请求要显式保存模型 ID、源语言、目标语言、提示版本、输入摘要、响应摘要、耗时、错误码与重试次数。真实文本可能包含客户信息或合同内容，默认日志不应保存全文。

from cohere import ClientV2
client = ClientV2()  # 从安全环境读取 CO_API_KEY
response = client.chat(
    model="north-small-translate-1-0",
    messages=[{"role": "user", "content": "Translate to English: 设备断电后再进行维护。"}],
)
print(response.message.content[0].text)

这段代码只说明调用形状，不是本站已执行的性能证明。实际接入要加入超时、指数退避、并发上限、幂等任务 ID、长度预检和人工复核路由。不要对同一失败请求无限重试；如果限额、认证或输入长度错误是确定性错误，重试只会扩大费用和队列堵塞。生产调用还应记录请求对应的业务文档版本，保证日后能找到“哪一段原文被哪一版模型怎样翻译”。

免费到限额也不是预算策略。应在试点前设置每天最大文档数、最大 token、最大失败重试量和异常停机阈值。即使当前 API 不收费，工程、人审、日志、网络、数据处理和迁移仍然产生成本；未来费率或免费政策变化时，只有保存了真实输入输出 token 与任务数量，才能重新计算单位成本。

五、公开权重、自托管与 Model Vault 怎么选

公开权重路径给团队更多运行位置控制，但同时把推理服务、驱动、量化、补丁、容量、监控和故障恢复交给自己。Cohere 推荐的 2×H100 或 1×B200 是起点，不是容量承诺。实际显存会受到权重格式、KV 缓存、批量大小、上下文长度、并行策略和服务框架影响。采购硬件前，先用可获得的目标量化在同代环境运行固定负载，再决定是否需要冗余和横向扩容。

Model Vault 更接近受管商业部署：企业通过商业许可使用模型，并获得隔离运行与运维能力。它是否满足某个组织的合规要求，仍需核对地区、子处理者、密钥控制、网络边界、日志保留、删除流程、可用性承诺和退出时权重或数据如何处理。供应商页面上的“私有”或“安全”字样不能替代合同与技术验证。

托管 API 适合最小试点，能够快速验证语料和任务分布；公开权重适合合法的研究、教学或非商业实验；商业私有部署适合数据驻留、稳定吞吐和网络隔离要求较高的组织。正确顺序通常是先用脱敏小样本确认任务价值，再让法务和安全决定可接受路径，最后才做硬件或长期合同承诺。不要先下载大权重，再补问能否商用。

六、CC BY-NC 4.0 到底意味着什么

Creative Commons 的许可说明允许在遵守署名等条件下复制、分享和改编材料，但限定为非商业目的。许可文本对“非商业”的判断关注主要目的是否指向商业优势或金钱补偿，不是简单看组织是否盈利。公司内部概念验证、为客户提供翻译、用输出支持付费产品、由商业部门运行评测等情形都可能需要专业法律判断。

因此，项目卡应记录：下载日期、模型仓库、具体提交或文件摘要、许可文件副本、使用主体、使用目的、是否面向客户、是否产生收入、输出如何分发、署名放在哪里、是否进行了改编。法务批准要关联到这组事实，而不是笼统写“开源模型已批准”。若用途从研究转成商业，审批状态必须自动失效，重新走商业许可流程。

也不要把开放权重与开放源代码混为一谈。权重可下载只说明模型参数可获得；训练数据、完整训练代码、评测数据、推理优化与商业权利可能分别采用不同条款。本文只根据发布时的模型文档和许可页面说明公开权重的使用边界，不替代法律意见。任何正式采购应以签署时的合同和完整许可原文为准。

七、如何阅读 Cohere 的 83.6 分

Cohere 报告 North Small Translate 在其 WMT26 全语言评测中取得 83.6，Agentic 变体为 84.36，并给出与多个闭源和开放权重系统的对比。这个结果可作为候选信号，但只能写成“Cohere 报告”或“厂商评测”，不能改写成独立事实。发布页说明整体评测使用 GPT-5.6-Sol 作为裁判；自动裁判可能受到提示、模型偏好、长度和语言覆盖影响。

厂商还报告在相同硬件和并发设置下，相比某一 Gemma 配置获得更高输出吞吐，并给出长上下文与单任务成本数字。这些数据依赖特定量化、硬件、输入、并发、计价方式和评测集。它们不能直接预测你的 PDF 翻译速度，也不能证明中文法律条款质量。可信的文章必须同时呈现结果和条件，而不是只摘取最高百分比。

复核时至少问六个问题：测试集是否公开；测试语言与你的语言对是否重合；裁判是人工、参考指标还是模型；比较对象是否采用相近配置；成本是否包含提示、输出、重试和硬件利用率；是否报告失败案例与方差。答不出的部分标记“未验证”，不要填入猜测。WMT 项目本身提供机器翻译评测背景，可从WMT 官方页面了解任务，但厂商自己的具体跑法仍需独立复现。

八、本站提供的可复现中文验收卡

为了不让评测停留在“感觉不错”，本文配套定义一张逐条记录的验收卡。每个样例必须有稳定 ID、使用授权、源语言、目标语言、领域、原文、不可改变片段、期望术语、风险级别与人工参考。模型输出另外保存模型 ID、请求时间、提示摘要和解码设置。敏感原文用内部受控存储，公开报告只保留脱敏片段和汇总。

样本不应只选短而清晰的句子。最低集合应包含：四条简体中文到英文、四条英文到简体中文、两条繁体中文双向、两条混合文本；同时覆盖长句、表格、HTML、Markdown、变量、电话号码、金额、时区、否定指令和专有名词。每个高风险领域再增加真实分布样例。模型版本或提示变化后必须整套重跑，不能只看新增样例。

九、评测指标不要只剩一个平均分

自动指标适合发现大范围回归，但不适合单独批准高风险翻译。BLEU、chrF、COMET 或模型裁判各有偏差：词面相似不代表数字正确，语义流畅不代表法律条件未被反转，裁判分数也可能偏好更长或更像自身风格的文本。至少并列报告自动分数、关键错误率、术语命中率、格式保持率、人工接受率和人均修改时长。

采用配对比较而不是只看两个平均值。对每个样例记录旧系统与候选系统谁更好、是否相同、是否都失败。这样可以看见候选模型新增了哪些收益，又引入了哪些回归。如果候选在普通文本提高很多，却在安全步骤上出现一次否定反转，它仍然不能通过高风险门禁。权重应该由业务风险决定，而不是由样本数量决定。

置信度也要被记录。样本太少时，不应写“提升 20%”，而应写清分子、分母和样本来源。例如“12 个固定样例中，候选胜出 3 条、回归 1 条、持平 8 条”，比一个没有区间的百分比更可审计。扩大流量前增加来自最近业务周期的盲测样本，并让评审者不知道输出来自哪个系统，减少品牌偏见。

十、术语库与上下文切分是生产成败点

企业翻译常见失败不是整句完全错误，而是同一个词在不同段落被译成不同名称。术语库要为每个词保存源语言、目标语言、批准译法、禁用译法、领域、大小写、可变形规则、示例和所有者。发布术语库时同样需要版本号和回滚。提示中塞入几千条无关术语会挤占上下文并降低遵循度，应该按文档领域和命中候选检索相关子集。

长文档不能机械按字符切开。标题、列表、表格、代码块、脚注与交叉引用应作为结构单元；切分窗口要保留必要上下文，并给每个片段稳定序号。翻译后先检查片段数、顺序和哈希映射，再重组文档。跨片段的人名、产品名和代词需要文档级一致性检查。16K 上下文提供空间，但不意味着一次塞满就一定比结构化切分更好。

原文更新时只重译变化片段，还要判断变化是否影响后文指代与术语。翻译记忆库可减少成本，但必须区分机器草稿、人工批准和已废弃版本。任何旧译复用都应保留来源，避免把过期安全步骤复制到新版手册。这些工程控制通常比更换一个模型带来的平均分差异更重要。

十一、数据安全与隐私检查

第一步不是询问模型是否“企业级”，而是盘点数据：公开内容、内部内容、个人信息、合同秘密、受监管数据分别允许进入哪些环境。API 试点默认使用合成或脱敏样本；需要真实数据时，先确认传输区域、保留期限、训练使用、人工访问、删除能力和事件通知。自托管也不自动安全，运维日志、对象存储、缓存和备份都可能留下原文。

密钥必须最小权限、按环境隔离、可轮换和可撤销。调用服务只接受业务系统签发的短期任务，不把供应商密钥发给浏览器或终端用户。日志以任务 ID、长度、语言对、状态、耗时和哈希为主；只有获批的故障样本进入受控调试区，并设置自动删除。导出评测报告前再次做个人信息扫描。

翻译输出仍然可能泄露输入事实，也可能生成输入中不存在的信息。对客户、员工、医疗、法律、金融和安全操作文本，模型输出只作为草稿。必须由具备语言和领域能力的人审核，且保留审核人、时间、修改差异和批准版本。若无法提供适当的人审资源，项目不应因模型分数较高而自动上线。

十二、从试点到灰度上线的六道门

门一：范围。写清语言对、文档类型、读者、数量、更新频率与不可接受错误。门二：许可。保存许可和用途审批，区分非商业权重与商业生产。门三：离线质量。固定样本、盲评、关键错误零容忍。门四：运行。验证吞吐、超时、限额、监控与成本。门五：安全。完成数据流、权限、保留和事件演练。门六：灰度。小比例真实任务、人审兜底、自动停止和可验证回滚。

每道门都要有负责人和证据链接，而不是会议口头确认。灰度初期只处理低风险文本，并与旧流程并行；候选输出不能覆盖原文和已批准译文。观察窗口至少跨越一个真实业务周期，覆盖高峰并发和常见异常。只有错误率、人工修改量、单位成本和队列时延同时满足阈值，才能扩大范围。

停止条件要在上线前写好，例如：出现关键数字错误、否定反转、敏感数据进入错误区域、连续超时、人工接受率低于阈值、单位成本超过预算或无法回滚。停止后保存证据、撤回未批准输出、恢复旧路径并通知负责人。没有停止机制的“灰度”只是小规模冒险。

十三、成本模型如何算

API 成本应以每个完成任务而不是每百万 token 的单价呈现。单任务成本包含输入、输出、系统提示、术语上下文、失败重试、人工复核和存储；批处理还要计入队列与峰值容量。自托管成本包含 GPU 折旧或租赁、低利用率、冗余、网络、工程值班、镜像维护、安全审计和升级回归。商业许可与 Model Vault 则要加入合同费用和迁移退出成本。

建议同时计算三种负载：日常平均、月底高峰、故障降级。平均负载决定基础成本，高峰决定容量，故障场景决定是否要双供应商或人工缓冲。对每种路径记录假设与数据来源，任何未知项标为区间。不要拿 Cohere 发布页的单任务估算直接替换自己的账单，因为厂商测试的平均 token、硬件、并发和比较价格可能与你的任务不同。

收益也应可测：翻译周转时间、人均修改分钟、术语错误返工、客户投诉和已批准内容复用率。若模型便宜但人审时间增加，总成本可能更高。项目决策应该基于相同样本和相同质量门槛下的总拥有成本，而不是只比较模型调用价格。

十四、常见失败以及怎样恢复

语言方向错误：源语言识别不可靠时要求调用方显式传入，不允许模型猜测后直接写回。格式损坏：先把标签、变量和代码替换成受保护占位符，翻译后校验数量和顺序再还原。术语漂移：缩小术语集合、提供正反例并在输出后做确定性扫描。长文遗漏：按结构切分并核对片段清单，而不是盲目增大上下文。

幻觉增译：设置句段对齐与长度异常检测，要求人工检查无对应原文的内容。限额或拥塞：将任务进入有界队列，按照错误类型重试，达到阈值转旧系统或人工。版本变化：模型 ID、镜像摘要、提示和术语库任一变化都触发回归集。许可用途变化：从研究走向商业时立即停止公开权重路径，重新取得授权。

恢复演练要真的执行：随机抽取一个灰度任务，证明能在目标时间内找到原文、上一批准译文、模型版本和审核记录；再关闭候选路由，确认新任务回到旧流程。只有文档写着“可回滚”而没有演练记录，不能算通过。

十五、与通用大模型和传统翻译平台怎样比较

通用大模型适合翻译与摘要、问答或改写组合的任务，但可能更容易改变格式、扩写或解释。专用翻译模型通常更容易约束为源到目标映射。传统翻译平台提供术语管理、翻译记忆、项目协作、文件解析和人工供应链，开箱能力可能比裸模型完整。North Small Translate 是核心引擎候选，不自动等于一套完整本地化平台。

比较时统一输入、术语、目标格式和人工标准，不要给某个系统额外提示后直接比较。至少保留当前生产基线、一个成熟翻译平台和一个通用模型。对每个系统记录质量、时延、成本、数据边界、许可、集成工作量和退出难度。若现有方案已稳定满足要求，新模型只有在真实指标上带来明确收益才值得迁移。

如果团队需要的是网页即时双语浏览，可先阅读站内的本地模型运行边界指南理解本地服务并不自动安全；做模型选择时参考大模型基准避坑指南建立配对回归；涉及组织级风险时使用AI 风险管理检查框架。这些内部资料解决不同层级的问题，不应由一个“最强翻译模型”榜单取代。

十六、30 分钟评审会议可以直接用的清单

1. 确认模型 ID、文档日期、权重版本与五个以上一手来源。
2. 写清非商业研究、托管 API或商业私有部署中的唯一目标路径。
3. 列出语言对、文档类型、峰值数量、敏感级别和人工审核者。
4. 准备固定样本与授权记录，覆盖中文简繁、数字、否定、术语和格式。
5. 设定关键错误零容忍、总体指标阈值、预算和观察窗口。
6. 保存模型、提示、术语库、解析器和评测集版本。
7. 验证超时、限额、重试、日志、删除、密钥轮换和故障降级。
8. 先离线盲评，再影子运行，最后才让低风险任务进入灰度。
9. 任何高风险输出保留人工批准，禁止模型直接发送或覆盖原文。
10. 执行一次停止与回滚演练，把证据附在发布审批单。

如果以上任何一项没有负责人或证据，结论应写“暂不进入生产”，而不是“基本通过”。如果公开权重路径的商业用途不清晰，先暂停并咨询法务。如果团队没有目标硬件，也不要根据建议配置直接采购，应先通过合规托管试点或可撤销的短期环境获取自己的负载数据。

十七、信息来源、版本变化与本文边界

本次核对使用了 Cohere 的发布博客、模型说明与实现文档、发布记录、Cohere 的安全说明、Creative Commons 的完整许可文本以及 WMT 的评测背景。模型仓库由官方发布页给出，但本轮自动化抓取返回需要授权，因此没有把该链接作为实页可达性证据。本站未使用厂商新闻稿以外的转述来确定规格，也没有把搜索摘要当成证据。

本文完成的是“当前官方事实核对 + 部署和许可决策框架 + 可复现验收协议”，不是付费 API 性能测试、GPU 吞吐测试、中文翻译质量认证或法律意见。Cohere 的 83.6、吞吐、长文和成本数字均属于厂商公布结果。读者若执行评测，应在自己的环境保存输入授权、输出、指标、硬件、日志和失败案例，再决定是否采用。

模型、费率、限额、许可与支持语言可能变化。正式决策前重新打开官方文档，核对模型 ID、更新时间和合同；将变化写入评估卡并触发回归测试。一个可持续的翻译系统不是“选中一次模型”就结束，而是持续管理证据、版本、人工责任和回滚能力。

十八、最终建议

North Small Translate 值得进入候选名单的原因，是它把专用翻译、公开权重选择、企业私有部署和多语言覆盖放在同一个模型上；它不能直接获批的原因，是公开权重有非商业限制，厂商基准尚未证明你的中文任务质量，推荐硬件也不是你的容量数据。对研究团队，可以在许可范围内用脱敏固定集复现；对商业团队，应先确认商业授权，再进行小规模托管或隔离试点。

最稳妥的下一步不是下载模型或宣布迁移，而是用本文的验收卡建立 12 至 50 条高代表性样例，冻结当前系统基线，记录每条收益与回归。若候选在关键错误、人工修改时间、单位成本和数据边界上同时通过，再进入影子流量；否则保留现状。这样的结论可能没有排行榜醒目，却能被采购、法务、安全、工程和内容团队共同复核。

十九、六个容易被忽略的评审问题

模型能否直接翻译 PDF、图片和字幕文件？

不能只凭模型支持文本就推断它完整支持这些文件。PDF 需要区分可提取文本与扫描页，图片需要 OCR，字幕需要保留时间轴，Office 文档需要保护样式、批注和嵌入对象。上游解析质量会限制最终翻译质量。验收时应把原始文件解析、模型翻译与重建输出分别打分，并保存中间结构；否则出现漏页时无法判断是解析器、模型还是重建器造成。

16K 上下文是否足够整本手册？

通常不足，而且即使勉强装入也不代表应该一次调用。token 数与字符数并不等同，中文、英文、表格和代码的占用不同；提示、术语和格式指令也会消耗上下文。长手册更适合按章节与结构切分，再用文档级术语和一致性检查连接。必须在发送前估算 token，并给输出预留空间，超限时明确拆分而不是截断。

Agentic 版本分数更高，是否应该直接选它？

厂商说明 Agentic 变体会发现并修正翻译错误，但额外步骤可能改变延迟、成本和错误形态。分数更高不证明所有语言对都更好，也不证明修正过程不会擅自改写。若该变体可用，应与标准版本在相同样本、提示和人工标准下配对，单独记录第一次输出与修订输出，让评审者看到它究竟修复了什么，又新增了什么。

免费 API 是否可以直接接生产？

免费到速率限制只描述当前计费与限额的一部分，不等于可用性承诺、长期价格承诺或商业许可结论。生产还需要容量、支持、数据条款、故障恢复和预算上限。可以把免费额度用于受控验证，但调用服务仍须有超限处理和关闭开关；任何采购文档都应把价格核对日期与限额来源写明。

怎样判断 12 条样例不是为了凑数？

12 条只是最小结构检查，不是统计充分的质量认证。每条都要对应真实风险类别，并覆盖双向中文、简繁、数字、否定、术语、结构和格式。完成最小集后，应从最近真实业务周期分层抽样扩大集合，并冻结测试集版本。若只挑模型容易的营销短句，样本再多也没有代表性。

什么时候应该放弃这个候选？

当商业许可不清、目标硬件不可行、关键错误无法通过规则和人审控制、单位总成本高于现有系统、数据区域不满足要求或回滚演练失败时，都应停止。停止不是项目失败，而是评测产生了有效结论。保存失败样例与环境，等模型或条件发生可验证变化后再重新评估，避免团队反复做同一轮没有新证据的演示。

二十、怎样建立真正可维护的翻译样本库

样本库不是从网上随便摘几十句话。第一步是获得文本使用授权并确定保存范围；第二步按业务来源分层，例如产品帮助、客服回复、内部制度、技术手册与安全说明；第三步在每层中保留常见样例、困难样例和过去真实出错样例。每条记录至少包含稳定编号、来源日期、语言方向、领域、风险、原文版本、参考译文版本、术语版本、格式约束与审批人。原文发生业务修订时，旧样本不能被静默覆盖，而要创建新版本并说明变化。

参考译文也不是天然真值。它可能来自旧供应商，包含历史术语或错误。建立样本时应由两名具备目标语言能力的评审者独立检查高风险项目，对分歧记录理由；普通内容可以抽查，但数字、否定、权限、安全步骤和合同义务需要逐项确认。评测者看到的页面要隐藏模型名称与输出顺序，避免“新模型一定更好”或偏好某个厂商文风。评分后才揭盲，并保留原始判断，不能为了让结果好看而事后改规则。

样本库要反映输入分布，而不是永久冻结。每月从人工返工、客户投诉和模型拒绝中抽取新案例，先进入挑战集，不立即混入用于历史比较的核心集。核心集用来观察长期回归，挑战集用来暴露新问题。两者都要去除重复和近似重复，防止某一类错误被大量相似句子放大。若样本含个人信息或商业秘密，评测平台必须遵守同样的数据访问、保留和删除规则，不能因为它叫“测试集”就降低保护。

二十一、上线后的质量监控不能只看接口成功率

接口返回二百状态只证明服务响应，不证明翻译正确。运行看板应同时展示请求成功率、端到端完成率、排队时间、各语言对延迟、输入与输出长度分布、截断次数、重试次数、人工接受率、关键错误数、术语违规数和回滚次数。自动检测发现数字数量不一致、占位符丢失、输出语言错误或长度异常时，应把任务送入人工队列并标注原因，而不是悄悄重试到某次看似成功。

质量抽样必须按风险与语言分层。流量最大的英语对不能掩盖低资源语言的问题，低风险营销文案也不能稀释安全手册错误。每个周期为高风险、低流量语言保留最低抽样量，并比较模型版本、提示版本与术语库版本。指标突然改善时也要调查：可能是真实优化，也可能是输入变短、难例减少、人工拒绝未计入分母或监控规则失效。所有指标都要写清分母和缺失数据。

建立用户反馈闭环时，不要把“点赞”直接等同于准确。使用者可能只看到流畅度，无法发现源文遗漏。反馈表应允许标记术语、数字、格式、语义、语气和隐私问题，并关联任务编号。高风险反馈立即触发停机审查；普通问题进入周度分析，判断是单例、人为参考错误、解析器问题还是系统性模型回归。只有确认根因后才调整提示或规则，调整后回放受影响样本。

二十二、提示、解码和后处理应该怎样版本化

即使模型 ID 不变，提示变化也可能造成生产回归。系统提示应明确目标语言、只翻译不解释、保留结构、禁止增删、如何处理不可译片段和术语冲突。每次调整使用版本号与变更说明，并在固定集上配对测试。不要把所有行业规则堆进一条超长提示；通用安全规则保持稳定，领域术语与文风按任务注入。提示中若包含内部制度，同样按配置秘密管理，不随客户端请求公开。

温度、最大输出、停止条件和批量策略都需要记录。翻译任务通常追求稳定，但不能只把温度设低就认为结果可复现；服务端更新、硬件实现和并行仍可能带来差异。重要文档要保存最终批准文本，而不是假设将来重新调用能得到同样结果。最大输出过小会截断，过大则可能掩盖异常扩写，因此应根据输入与历史比例设置告警，而不是使用一个覆盖全部文档的常量。

后处理只能做确定性且可解释的修复，例如恢复受保护占位符、验证标签配对、统一已批准术语和检测数字差异。不要让第二个通用模型无记录地“润色”翻译，否则责任链变得更复杂，原模型评测也失去意义。任何自动修改都保存前后差异、规则版本和命中原因；当规则无法确定正确答案时，转人工而不是猜测。后处理失败时保留原始输出供诊断，但不得进入发布内容。

二十三、供应商和自托管的退出计划

采用前就要设计退出。托管方案应确认能否导出术语、翻译记忆、任务日志、人工修改与质量标签，导出格式是否开放，合同结束后多久删除数据。自托管方案应保存镜像、配置、驱动和权重摘要，但只有在许可允许的范围内保留和迁移。业务系统不要直接绑定供应商响应结构，应通过内部翻译任务接口隔离模型，使旧系统、候选系统和人工流程可以切换。

退出演练至少包含三步：暂停新任务进入候选模型；把队列中未完成任务安全转移或取消；从原文与已批准译文恢复对外输出。然后检查缓存、搜索索引、对象存储与下游发布系统是否仍引用未经批准的候选结果。演练要设定恢复时间目标，并真实记录耗时。若只能关闭 API 却无法找回哪些页面用了模型输出，退出计划仍然不完整。

还要考虑人员知识退出。运行手册应让未参与试点的工程师能够找到密钥轮换、监控、故障队列和回滚入口；语言负责人能够找到术语审批与样本库；法务能够找到许可版本和用途范围。供应商改变模型、费率、区域或条款时，由明确负责人评估影响。没有负责人时，系统会在最需要决策的时刻停留在无人维护状态。

二十四、面向中文团队的最终验收记录模板

最终记录页应先写结论：通过、限范围通过或不通过；随后写允许的语言、文档、风险等级、调用环境、流量上限和有效期。证据区链接到官方来源快照、许可审批、样本集版本、盲评结果、负载测试、安全评审、预算计算与回滚演练。限制区明确没有验证的能力，例如扫描识别、整本书翻译、专业法律准确性或某个低资源语言。任何人只看这一页，就应知道模型能用在哪里、不能用在哪里。

“限范围通过”必须是机器可执行的范围，而不是一句“谨慎使用”。例如只允许简体中文到英文的公开帮助文档，每天不超过一定任务量，全部进入人工审批，不允许个人信息和合同条款。网关根据这些字段拒绝越界请求，日志记录拒绝原因。范围扩大时创建新审批版本并重新验证新增风险，不能在聊天群中口头放宽。

记录还应有到期时间。即使没有主动变化，模型服务、许可、业务语料和审核团队都会变化。到期前重新核对官方文档和合同，抽取近期样本回归，检查密钥、权限、删除与回滚。若没有完成复审，系统自动退回更保守的流量或暂停新增任务。把证据有效期纳入运行规则，才能让一次评测变成持续治理，而不是发布当天的文件装饰。