AI翻译在通用文本上表现不错，但一旦涉及垂直领域，输出常常令人头疼。同一个英文缩写，前面翻译成“联合影像专家小组”，后面变成“JPG格式”，品牌商标被强行意译，功能描述因为脱离前后句而扭曲原意。这类问题不是模型能力不够，而是输入侧缺乏约束。通过给翻译系统补充术语表和上下文，可以在不微调模型的前提下大幅修正结果。
术语表的设计与接入方式
术语表本质上是一份词对齐清单，用来告诉模型哪些词必须直译或锁定为特定中文。最简单的形式是键值对：源语言术语对应目标语言术语。比如在医疗项目中，CT不能翻成“计算机断层扫描”而应保持“CT”，EGFR必须写为“表皮生长因子受体”。如果用语义模糊的提示词要求“不要翻译专有名词”，模型仍可能自作主张，结构化术语表则消除了这种不确定性。
以常见的翻译接口为例，很多平台支持上传 glossary 文件。下面是一段 Python 调用示例，展示如何把术语表随请求一起发送。注意术语表应为 UTF-8 编码的 CSV 或 JSON，且区分大小写。
import requests
url = "https://api.ipipp.com/v1/translate"
glossary = {
"CT": "CT",
"EGFR": "表皮生长因子受体",
"AI": "人工智能"
}
payload = {
"text": "The AI model uses CT to detect EGFR mutations.",
"target_lang": "zh",
"glossary": glossary
}
resp = requests.post(url, json=payload)
print(resp.json())
当术语表达到一定规模，建议按模块拆分，例如“影像科术语”“病理科术语”，在翻译不同章节时动态加载。这样能避免无关词干扰，也方便非技术人员维护。实践中，百条左右的术语表即可消灭八成以上的专有词错误，性价比极高。
上下文补充的具体手法
很多翻译偏差来自单句孤立处理。比如“He returned the book to the window”在软件手册里可能是“他把书退回窗口”，但在图书管理系统需求中应是“他将该记录退回窗口组件”。补足上下文就是在待译句周围拼上背景。一种做法是前置一段角色说明：“以下内容来自图书馆系统的用户操作日志，window 指界面窗口组件而非建筑窗户。”
另一种做法是提供平行示例。给模型一句已译好的相似句，它就能类比出新句的正确译法。下面用伪代码展示如何在批量翻译时自动插入上下文模板。我们把上下文放在 context 字段，与原文合并提交。
const context = "本文档为银行APP帮助中心，card 指银行卡，not a physical greeting card。";
function buildInput(sentence) {
return context + "n" + sentence;
}
const src = "Tap the card to view balance.";
const input = buildInput(src);
// input: 本文档为银行APP帮助中心，card 指银行卡，not a physical greeting card。
// Tap the card to view balance.
console.log(input);
上下文不是越长越好。冗余背景会稀释关键约束，建议控制在三句内，且明确写出易错词的定义。对比发现，仅加术语表不改写句子，某些指代仍会翻错；而术语表加一句场景说明，准确率能从七成提升到九成五。团队应将这两种手段组合使用，而非二选一。
常见误区与效果验证
不少人认为“在提示词里写‘请准确翻译’”就能解决问题，这是典型误区。模型对模糊指令遵从度低，不如直接给词表。还有人把术语表写成整段解释，例如“AI是人工智能的简称，请不要翻译”，这会被当成普通文本而非强约束。正确写法就是干净的对换表，让解析逻辑可机器读取。
验证优化效果不能靠肉眼抽看。建议抽取五十句含专有词和指代的样本，人工标注标准答案，再计算术语一致率和语义错误数。下表列出某团队优化前后的对比：
| 方案 | 术语一致率 | 语义错误句数 |
|---|---|---|
| 无术语表无上下文 | 62% | 18 |
| 仅术语表 | 91% | 9 |
| 术语表加上下文 | 98% | 2 |
从数据看，组合策略把需人工返工的量降到最低。后续可把术语表沉淀为团队资产，每次新项目基于旧表增删，形成正向循环。当业务扩展至多语言时，同一份英文术语表可映射不同目标语言，维护成本进一步摊薄。