系列第五篇，聊术语一致性（glossary）——这个功能用户看不见，但直接决定长文档翻译是「能用」还是「专业」。
为什么术语一致性难
模型翻译单句时，术语选择是自由的：orchestrator 译「编排器」或「调度器」都对。但一份文档里前后不一致，读者就会困惑这是不是两个概念。而翻译请求是无状态的——第二次请求不记得第一次的选择。
三种解法对比：
- 译文缓存复用：相同源文命中缓存。局限：只对完全相同的句子有效
- few-shot 示例：请求里带几个术语对照示例。局限：占用上下文、稳定性一般
- 显式 glossary 约束：请求携带「术语→译名」映射表，服务端在推理时做强约束
我们最终用 3 为主、1 为辅。
glossary 怎么构建
自动构建流水线：
- 文档预扫描，抽取高频名词短语（TF-IDF + 词性过滤）
- 对每个候选术语调一次「定译名」请求（带上下文，让模型给出该语境下的标准译名）
- 置信度低的（多义词、罕见词）进人工确认队列
- 定稿后随每次翻译请求下发
成本账：预扫描多花约 8% 的 token，换来的是整份文档译名统一。这笔账划算。
失效策略
glossary 更新后，已缓存的译文怎么办？我们的做法是版本化键控：缓存键里带 glossary 版本号，版本变了缓存自然失效，只重算受影响的批次。这样修正一个术语不用重翻整本书。
踩过的坑
- 术语表不能太大：超过一定规模后模型遵守度下降，实践中 200 条以内效果最好，按文档内频率截断
- 中文术语要标注词性歧义：同一个英文词在「名词语境」和「动词语境」译法不同（如 cache 作动词）
- 人名地名要单独一类：强制音译反而错，保留原文往往更好
结语
术语一致性是机器翻译从「demo 惊艳」到「生产可用」的分水岭。做翻译类产品的团队，这个功能值得优先投入。
（实践来自随心翻译的术语表模块。）
