翻译记忆库、术语表和缓存有什么区别？选型与复用工作流指南
区分句段记忆、术语约束与请求缓存，讲解精确匹配、模糊匹配、上下文审校、来源隔离和复用收益评估，避免把命中当成质量保证。
一段文字以前翻译过，是否可以直接复用？答案取决于你找到了什么：一条术语规则、一段经过审校的译文，还是一次旧 API 请求的响应。它们都能减少重复劳动，却不能用同一套标准判断是否适合当前任务。
翻译记忆库、术语表和缓存经常被混为一谈。结果可能是把未经审校的缓存长期当作标准译文，或把模糊匹配的高分误认为质量保证。本文从实际复用决策出发，建立三类资产的边界，并给出可追踪的组合流程。
一、三类资产分别回答什么问题
| 资产 | 保存的核心内容 | 主要问题 | 不能自动证明 |
|---|---|---|---|
| 翻译记忆库 | 原文句段与对应译文 | 相似内容以前怎么翻译 | 当前语境一定适用 |
| 术语表 | 概念与认可名称 | 这个概念应该叫什么 | 整句话已经正确 |
| 请求缓存 | 请求条件与旧响应 | 相同计算是否做过 | 响应经过人工审校 |
记忆库的基本单位可以是句子，也可以是有明确边界的短段。欧盟联合研究中心的DGT 翻译记忆库说明介绍了原文片段与译文配对的形式。它展示了句段资产的组织方式，不意味着其中的领域表达适合所有产品。
术语表通常更短、更强调概念定义；缓存则更接近工程基础设施。最好在系统界面上明确标识来源，避免审校者看到一段译文时，不知道它是正式资产还是临时机器输出。
二、先保存来源，再讨论复用
建议记忆条目至少保留原文、译文、语言方向、内容领域、源版本、审校状态、来源位置和更新时间。有上下文依赖的句子，还应保存邻近标题或相关界面位置。不能只记录一对字符串和一个匹配分数。
“已审校”也要说明审校范围。只检查拼写不等于核对事实；仅用于内部理解的译文，不应无条件成为公开产品页面的推荐答案。记录接受标准，才能判断历史成果是否满足当前交付要求。
导入第三方资产前，应核对使用条件、来源可信度和领域适配。公开可访问不等于可以忽略许可或来源声明，更不意味着内容没有错误。对不确定的条目，保留隔离状态，先评估再启用。
三、精确匹配仍然需要语境检查
相同原文可能对应不同含义。英文“Open”可以是按钮上的动作，也可以是工单的状态；“Free”可能表示免费，也可能表示空闲。原文字节完全一致，只证明字符串相同，不能证明当前界面需要同一个译法。
因此，复用条件应包含语言地区、产品模块和内容类型。对高风险内容，审校者还应确认前后文、数字和条件没有改变。历史段落从说明文移动到确认弹窗，可能需要更明确的表达，即使原文没有修改。
不要用“100% 匹配”代替“已批准用于本位置”。前者是检索结果，后者是发布决策。把这两个状态分开，团队才能发现哪些内容只是被找到，哪些内容真正完成了验收。
四、模糊匹配分数不是正确率
考虑两个原创示例：“You may cancel before shipment.”与“You may not cancel before shipment.”。只有一个词变化，但允许取消和不允许取消的意义相反。一个字符或词级相似度很高的候选，仍可能包含最危险的差异。
数字、否定词、比较符号、单位和范围变化应突出显示。审校者先核对这些内容，再考虑复用其余句式。不能把旧译文整体粘贴过来，只修改几个表面上的名词。
不同工具的相似度计算和上下文加权可能不同。不要把某个工具的阈值直接移植到另一个工具，并宣称风险相同。先用自己的内容样本观察误用类型，再决定哪些匹配可以自动预填，哪些必须人工确认。
五、让缓存服从完整的请求条件
缓存用于避免重复计算，应根据实际影响结果的条件设计键。除了原文和语言方向，还可能包含租户、内容类型、术语版本、模型或引擎配置，以及相关语境的版本。忽略这些条件，就可能在不适合的场景返回旧响应。
不建议把所有缓存响应自动同步到已批准记忆库。机器输出可以进入待评审区，但需要经过相应验收，才成为团队长期复用的资产。相反，人工修改了译文后，也应考虑失效旧缓存，避免修正被旧响应覆盖。
缓存过期与内容废弃是两种不同事件。缓存删除后，已批准译文仍可作为内容存在；术语或事实发生变化时，即使缓存没有过期，旧译文也可能需要停止使用。工程细节可参考翻译缓存实战。
六、设计一条可解释的组合流程
先确认内容的权限范围、语言方向与版本，再查询适用的术语规则。随后检索同领域记忆条目，展示匹配来源和差异；合格候选可以预填，但保留待确认状态。
没有可用候选时，调用已批准的翻译服务，并把机器输出与人工批准内容明确区分。审校完成后，将最终译文与来源版本写入正式资产，再更新服务当前内容的缓存。每一步都应有可恢复状态，避免中途失败让部分内容看起来已经发布。
对于 TranslateHub，具体调用方式以API 文档为准。本文描述的是应用侧资产管理，不代表接口内置记忆库检索、术语审批或质量评分服务。把职责拆开，后续更换供应商也不必搬走全部内容资产。
七、用一个假设项目计算复用收益
假设一个帮助中心有 1,000 个待处理句段，其中 300 个找到语境合适的已批准译文，200 个只有需要编辑的相似候选，剩余 500 个需要新翻译。这只是说明计算方法的示例，不是行业平均值。
不要据此直接声称节省了 50% 的成本。不同句段长度不同，模糊匹配需要的编辑时间也不同；资产维护、格式回填和最终验收仍会消耗时间。应分别记录复用句段数、实际处理字符量、编辑分钟数和返工次数。
更有意义的比较是，在同一交付标准下，使用资产前后的总耗时与缺陷数量如何变化。若预填增加了误信旧译文的风险，表面上减少的新翻译量可能被后续返工抵消。
八、交换格式不等于完整迁移
TMX 常用于交换翻译记忆，DGT 的官方说明也介绍了其 TMX 数据。实际迁移前，应验证目标工具是否保留你需要的语言标签、内联标记、上下文、审批状态和自定义字段，不能仅凭“支持导入”认定语义完全保留。
先导出少量具有代表性的条目，再导入测试环境，逐条比较原文、译文和重要元数据。包含换行、格式标签、占位符和不同地区语言的样本，比只有简单句子的样本更能发现问题。
同时保留原始导出和迁移映射。若目标系统不支持某类字段，应决定把它放入外部关联表，还是禁止相关条目自动复用；不要悄悄丢弃后继续使用原来的可信等级。
九、隔离、清理与版本治理
客户专属术语、未公开产品名和包含个人信息的句段，不应因为“提高命中率”被混入所有项目共享的库。先定义共享范围，再选择检索源。测试数据也应使用授权内容或虚构样本。
对过期政策、已撤销承诺和错误译文，应支持停用与反向定位。记录哪些页面使用了某条资产，才能在修正时生成影响清单。只修改库里的句子，不会自动修复已经发布的副本。
维护者可以定期检查低质量重复项、冲突译法和无人负责的条目。遇到冲突时，依据当前产品事实和批准规则选择，而不是简单使用最近导入或出现次数最多的版本。
十、常见问题
小团队是否需要同时建设三套系统？
不一定。可以从一个有审校状态的句段表和一份术语表开始。出现真实的重复请求成本后，再引入缓存；先保持职责清楚，再增加工具复杂度。
精确匹配能否自动发布？
只有在项目明确允许，且语境、版本和风险条件都满足时才考虑。对于敏感承诺或重要操作提示，仍应保留人工确认，不能只根据字符串相同做决定。
记忆库能够代替翻译吗？
不能。新概念、变化的语境和新增句段仍需要翻译与审校。记忆库擅长减少重复工作，而不是创造所有未知内容的正确答案。
