借助 LLM 翻译古代天文文献：专业术语是最大的坑
一、让大模型翻译《天官书》，结果把星宿名当成了小说人物
《史记·天官书》是中国古代天文学的重要文献。其中一段文字描述："太微者，天帝南宫也。朱鸟权衡，衡，太微，三光之廷。"对于不具备古代天文知识的现代读者来说，这段文字几乎是不可读的。
一个自然的想法是：用大模型翻译。输入原文，要求模型翻译为现代汉语。实际结果是：模型把"太微"理解为"太微弱的信号"，把"朱鸟权衡"翻译成"用红色的鸟来权衡事务"。完全错误。
这个案例说明了：大模型在翻译古代专业文献时，术语的语境理解是核心瓶颈。模型对常见现代词汇有丰富的语义理解，但对古代专业术语缺乏足够的训练数据覆盖。"太微"是一个星官名，"朱鸟"是二十八宿中南方七宿的总称，"权衡"在这里指的是轩辕星座中的星宿。这些术语中任何一个处理错误，整段翻译都会失去意义。
见证奇迹的时刻在于：当通过少样本提示和多轮验证的方式引导模型进行术语对齐后，翻译结果从"完全不可用"变成了"基本可信"。这个转变的关键，不是模型的参数量更大，而是对术语语义的精确锚定。
二、专业术语对齐的技术框架
古代天文文献翻译的核心挑战可以分解为三个子问题：术语识别、术语消歧和语境锚定。
graph TD A[原始古文] --> B[术语识别模块] B --> B1[基于知识库的术语词典匹配] B --> B2[基于上下文的未登录术语发现] B1 --> C[术语消歧模块] B2 --> C C --> C1{语义判定} C1 -->|天文学含义| C2[映射到现代术语] C1 -->|非天文学含义| C3[标记为普通语义] C2 --> D[语境锚定模块] D --> D1[少样本 Prompt 注入术语映射表] D --> D2[多轮对话确认术语理解] D1 --> E[LLM 翻译] D2 --> E E --> F[术语后校验] F --> F1[{目标术语是否保留?}] F1 -->|否| F2[回退到逐字翻译 + 术语标注] F1 -->|是| G[输出译文] style B fill:#e1f5fe style C fill:#fff3e0 style D fill:#e8f5e9 style F fill:#fce4ec术语识别是预处理阶段，需要建立古代天文术语的知识库。这个知识库需要包含：术语名称、朝代/文献来源、现代对应概念、以及同术语在不同语境下的不同含义。
术语消歧是关键环节。"太微"在《天官书》中是星官名，但在其他文献中可能指"太微垣"。如果不做消歧，模型可能将同一个术语在相邻句子中翻译为不同的概念。
语境锚定是在 Prompt 中显式注入术语的语义映射。例如：在请求翻译时，附上一段说明——"太微: 星官名，五帝座之一；朱鸟: 二十八宿中的南方七宿（井、鬼、柳、星、张、翼、轸）的总称"。这些映射相当于给模型建立了术语字典。
三、基于知识库增强的术语对齐实现
以下代码实现了术语对齐的核心逻辑。
""" 古代天文术语对齐翻译框架 设计原因：通用 LLM 对古代专业术语的理解是不可靠的， 需要在 Prompt 中显式注入领域知识来引导翻译方向。 """ # 古代天文术语知识库（精简示例） ASTRO_TERMS = { "太微": { "category": "星官", "modern": "太微垣（Supreme Palace Enclosure）", "context_note": "三垣之一，位于紫微垣之南，代表天帝的南宫", "related": ["五帝座", "内屏", "三台"] }, "朱鸟": { "category": "星宿统称", "modern": "朱雀 / 南方七宿（Vermilion Bird）", "context_note": "二十八宿中南方七宿的总称，非指单一星体", "related": ["井宿", "鬼宿", "柳宿", "星宿", "张宿", "翼宿", "轸宿"] }, "权衡": { "category": "星宿", "modern": "轩辕星座中的星宿（Steelyard stars）", "context_note": "在《天官书》中特指天文学概念，非度量工具", "related": ["轩辕", "摄提"] }, "三光": { "category": "天文现象统称", "modern": "日、月、星辰（Sun, Moon, Stars）", "context_note": "古代天文学中对三种发光天体的统称", "related": ["日", "月", "星"] }, } def build_term_glossary(text: str) -> str: """扫描文本中的天文术语并构建术语表 设计原因：在翻译前显式告知 LLM 术语的语义， 避免模型依赖训练数据中的统计性理解。 统计性理解在低频专业术语上不可靠。 """ found_terms = [] for term, info in ASTRO_TERMS.items(): if term in text: entry = ( f"- {term}：{info['category']}，" f"对应 {info['modern']}。" f"注意：{info['context_note']}" ) found_terms.append(entry) if not found_terms: return "" return "## 术语映射表\n" + "\n".join(found_terms) def build_translation_prompt(source_text: str) -> str: """构建带术语对齐的翻译 Prompt 设计原因：多层 Prompt 结构—— 1. 角色设定：明确 LLM 的身份和任务边界 2. 术语映射：注入领域知识（核心） 3. 翻译要求：格式和质量约束 4. 原文：待翻译内容 """ glossary = build_term_glossary(source_text) prompt = f"""你是一位古代天文学文献翻译专家。 任务：将以下古文翻译为现代汉语，保留天文学术语的原意。 {glossary} 翻译要求： 1. 术语必须严格按术语映射表中的定义翻译，不可自行揣测。 2. 遇到术语映射表中未收录的天文术语，用【原文术语(暂未识别)】标记。 3. 译文后附术语对照表，列出文中的所有天文术语及其现代含义。 4. 对于多义词，默认优先取天文学含义。 ## 原文 {source_text} ## 译文 """ return prompt def verify_terminology_preservation( source: str, translation: str ) -> tuple: """验证术语是否在译文中保留 设计原因：即使在 Prompt 中注入了术语映射， 模型仍有可能输出不一致的结果。 后校验是必要的质量保障。 """ missing = [] for term in ASTRO_TERMS: if term in source: modern_ref = ASTRO_TERMS[term]["modern"] if term not in translation and modern_ref not in translation: missing.append(term) correctness_rate = 1 - len(missing) / len( [t for t in ASTRO_TERMS if t in source] ) if any(t in source for t in ASTRO_TERMS) else 1.0 return missing, correctness_rate上述实现的关键设计决策：
- 术语知识库独立于 Prompt，通过
build_term_glossary动态组装。这允许在不修改 Prompt 模板的情况下更新术语库。 - 对于术语库中未收录的术语，要求模型标记而不是猜测。错误标注比完全跳过更危险——错误的术语翻译会让读者形成错误认知。
- 后校验阶段检查术语是否在译文中保留。这是自动化的质量保障环节，可以发现模型输出与指令不一致的情况。
四、LLM 翻译专业文献的能力边界
LLM 翻译古代天文文献有明确的能力边界，不能无限制信任。
适用场景（可行）：
- 术语可以建立明确的现代映射。古代天文术语中约 60%~70% 可以与现代天文学概念对应。
- 原文句式相对规整，可以通过术语替换完成翻译。
- 翻译的目的是辅助理解而非学术引用。
不适用场景（不可行）：
- 术语的现代对应关系不确定。部分古代天文学概念在学术上仍存在争议，LLM 无法替学者做出选择。
- 原文涉及复杂的数理推算。部分古代天文文献包含历法计算，这些需要数理验证而非语义翻译。
- 需要学术级准确性。LLM 的翻译结果需要专家审校后才能用于学术引用。
幻觉风险评估：
| 术语类型 | 幻觉风险 | 建议策略 |
|---|---|---|
| 常见古代星官（如北斗、三垣） | 低 | 可直接信任 |
| 较少见的星宿 | 中 | 需要术语映射表指引 |
| 古代历法专用术语 | 高 | 必须人工确认 |
| 多义词（如权衡） | 极高 | 必须上下文消歧 |
见证奇迹的时刻不在于 LLM 能完美翻译古文，而在于它作为一个加速工具——将翻译初稿时间从数小时压缩到数分钟，然后把省下的时间投入到术语准确性的审校上。工具的角色是提升效率，而不是取代专业判断。
五、总结
利用 LLM 翻译古代天文文献的关键瓶颈在于专业术语的准确对齐，而非通用语言能力。有效的解决方案需要在 Prompt 中显式注入术语映射表（知识库），并通过多轮验证确认术语翻译的一致性。术语知识库应独立于 Prompt 模板，支持动态更新；未收录的术语应采用标记策略而非猜测策略；译后检验环节是必要的质量保障。LLM 的翻译结果适用于辅助理解和初稿生成，但不能替代学术审校。当术语对应关系存在争议或涉及复杂数理推算时，LLM 的翻译结果需要人工确认。
