附录F：术语表与中英文对照¶
F.1 附录定位¶
本附录用于统一全书高频术语、缩写和中英文对照，尤其是那些在正文里会反复出现、但在不同篇章中容易被不同团队用不同说法描述的概念。
对于一本文档跨度很大的工程书来说，术语不统一本身就是一种成本。它会导致同一个东西在不同章节被叫成不同名字，读者、编辑、讲师和项目组在对齐时需要额外翻译，最终增加理解摩擦。所以本附录的任务不是“词典化”，而是为全书建立一个稳定的工程词汇底座。
术语表的作用也不只是“翻译”。在数据工程、治理、评测、Agent 和隐私技术这些主题里，很多词看起来像同义词，实际上却有明确边界。比如“脱敏”“匿名化”“可用”“可发布”并不是一回事；“联邦学习”“隐私增强技术”“安全多方计算”也不是随便互换的。词用错了，读者就会把工程约束误读成法律结论，或者把研究原型误读成生产方案。围绕基础模型透明度、语言模型风险和可信评测的近年研究都强调，概念边界不清会直接影响风险识别、责任分配和结果解释（Bommasani et al. 2023; Weidinger et al. 2022; Liang et al. 2023）。
F.2 术语使用原则¶
- 优先使用全书统一术语。
- 首次出现需给出中英文全称。
- 同义词只在解释历史或兼容外部文献时出现。
- 对容易混淆的缩写，要给出使用边界。
- 对跨篇高频术语，要给出推荐译法。
- 同一章节内不要频繁切换中英文顺序。
- 如果缩写可能歧义，优先写全称。
一个实用的判断标准是：读者离开这一页后，能不能用同一套词再和别人复述。如果不能，说明术语还不够稳定。
F.3 核心术语对照表¶
| 中文术语 | 英文/缩写 | 说明 |
|---|---|---|
| 数据工程 | Data Engineering | 面向数据生命周期的工程组织方式 |
| 数据治理 | Data Governance | 数据使用、权限、责任与边界管理 |
| 数据资产 | Data Asset | 可复用、可追踪、可维护的数据对象 |
| 数据卡片 | Data Card | 记录数据集来源、范围、限制与版本 |
| 模型卡片 | Model Card | 记录模型用途、限制、风险与评测 |
| 版本冻结 | Version Freeze | 固定数据或配置以保证复现 |
| 污染 | Contamination | 训练、评测或任务间的信息泄漏 |
| 切片 | Slice | 按子群体、条件或场景拆分评估 |
| 回写 | Write-back | 把评估或运营结果回流到数据侧 |
| 谱系 | Lineage | 记录数据与动作的来源和路径 |
| 闸门 | Gate | 在关键步骤实施控制与审批 |
| 轨迹 | Trajectory | Agent 或推理过程的事件序列 |
| 合成数据 | Synthetic Data | 由模型或规则生成的数据 |
| 隐私增强技术 | PETs | Privacy Enhancing Technologies |
| 联邦学习 | Federated Learning | 在不集中原始数据的情况下联合训练 |
| 差分隐私 | DP | Differential Privacy |
| 安全多方计算 | MPC | Secure Multi-Party Computation |
| 可信执行环境 | TEE | Trusted Execution Environment |
| 同态加密 | HE | Homomorphic Encryption |
| 访问控制 | Access Control | 对数据和工具的可操作边界管理 |
| 审批流 | Approval Flow | 对敏感操作的分级确认机制 |
| 留痕 | Audit Trail | 可追溯的操作记录 |
| 法域 | Jurisdiction | 适用的法律和监管范围 |
F.4 容易混淆的术语¶
F.4.1 “脱敏”与“匿名化”¶
脱敏是降低识别风险的一组工程处理，匿名化则更强调不可逆识别。二者在实践中都很常见，但不能互相替代。对于本书内容，建议优先用“脱敏”描述工程处理，用“匿名化”描述更强的身份不可识别目标，并在必要时说明所依据的法域与业务要求。涉及个人信息或跨域共享时，术语应服务于风险评估和控制说明，而不能替代具体合规判断；语言模型风险分类研究也把隐私泄露、滥用和信息安全风险区分为不同风险族，不能混作一个词处理（Weidinger et al. 2022）。
F.4.2 “可用”与“可发布”¶
可用于内部实验，不代表可以公开发布。公开发布通常还涉及许可、边界、审查、可逆风险、撤回机制和责任归属。写作时不要把“内部可用”写成“可公开”，也不要把“已发布”写成“已合规”。
F.4.3 “评测分数”与“工程质量”¶
评测分数只是质量的一部分。版本稳定、样本覆盖、证据链完整和失败可回滚，同样属于工程质量。若只写分数，读者会误以为工程目标只有一个指标。
F.4.4 “Agent 轨迹”与“日志”¶
轨迹是面向决策和复现的结构化事件链，日志只是其中的一种记录载体。并不是所有日志都能直接构成轨迹，只有能够表达状态变化、工具调用、输入输出和结果回写的记录，才足以支持复现。
F.4.5 “数据资产”与“数据集”¶
数据集更偏集合概念，数据资产更强调可治理、可复用、可追踪、可维护。一个数据集只有在有稳定来源、版本、责任人和使用边界后，才更接近“资产”。
F.5 中英文书写建议¶
| 推荐写法 | 不建议写法 |
|---|---|
| 联邦学习（Federated Learning, FL） | Federated Learning / 联邦学习 混写无首次定义 |
| 隐私增强技术（PETs） | PETs、隐私技术、隐私计算混用不说明 |
| 数据保护影响评估（DPIA） | 只写 DPIA 不给全称 |
| 数据卡片（Data Card） | 数据说明、卡片、dataset note 混写 |
| 谱系（Lineage） | 血缘、来源链、路径记录混用 |
书写上还有几个细节：
- 首次出现时尽量“中文在前，英文在后”。
- 同一段落里不要重复切换简称和全称。
- 如果一个缩写跨章出现频繁，建议在章节开头再补一次全称。
- 表格里可以保留英文，但正文最好保持统一中文主称。
- 对读者不熟悉的缩写，宁可多写一次，也不要赌他们记得。
F.6 术语维护规则¶
建议每次全书修订时同步检查三件事：
- 新增术语是否进入本表。
- 旧术语是否出现了多个译法。
- 章节中的缩写是否与本表一致。
如果是多人协作写作，最好指定一个术语负责人。这个角色不是做“语言审美”的，而是做一致性守门人，负责处理：
- 新术语是否真的需要收录。
- 某个词是否已经有全书既定写法。
- 某个缩写是否在不同章节中被误用。
- 哪些术语需要随法规或行业惯例更新。
F.7 补充术语说明¶
F.7.1 数据治理相关¶
数据治理不是“管数据的人比较多”，而是围绕权限、责任、边界、审计和变更形成的一整套制度化安排。它和工程实现是互相依赖的：没有工程落地，治理只是口号；没有治理边界，工程会变成临时拼装。
F.7.2 隐私技术相关¶
PETs 是一组方法的总称，联邦学习、差分隐私、MPC、TEE 和同态加密都可能属于这个范畴，但它们的约束条件不同，成本模型也不同。写作时应避免把“用了 PETs”当成“一次性完成的隐私保证”。
F.7.3 版本与复现相关¶
版本冻结、快照、回滚、谱系、留痕，这几个词常常一起出现，但关注点不同：版本冻结强调固定，快照强调状态截面，回滚强调恢复，谱系强调来源，留痕强调审计。把它们混写会让读者无法判断系统究竟在做什么。
F.8 术语示例页¶
在正文中，推荐这样首次引入术语：
本章使用“数据卡片（Data Card）”记录数据集来源、范围、限制和版本；使用“谱系（Lineage）”记录数据流转路径；使用“闸门（Gate）”表示在关键节点进行的审批或控制。
这样的写法有两个好处：一是读者第一次看就知道缩写对应什么；二是后文可以统一用中文主称，减少页面噪声。
如果一个章节会反复提到同一组概念，也可以在章节开头集中定义：
本章中，“可用”仅指内部实验可用，“可发布”指满足审查、边界、回滚和责任要求后的公开发布。
这样做能有效减少后文的歧义。
F.9 术语更新流程¶
如果把术语表当成“写完就结束”的静态页面，它很快就会过时。更合理的做法，是把它当成全书的共同配置，并建立一套轻量但稳定的维护流程。
建议每次修订时按下面顺序处理：
- 先扫正文，找出新增的高频术语和缩写。
- 再看旧术语是否出现了第二种译法。
- 检查表格、图注、章节标题和正文是否统一。
- 对争议术语先定主词，再定别名。
- 把影响范围写进修订说明，避免其他章节悄悄分叉。
对于多人协作，最好把术语变更也纳入评审流程。一个常见做法是：术语负责人先提议，章节作者确认语义，编辑确认写法，最后由全书维护者统一发布。这样做的目标不是增加手续，而是减少“本章改好了、别章又改坏了”的回头路。
F.9.1 术语收录标准¶
不是所有词都值得进入术语表。建议优先收录以下几类：
- 全书反复出现的核心概念。
- 容易混淆的缩写或译法。
- 会影响合规判断的边界词。
- 会影响工程实施路径的术语。
- 正文中已出现三次以上的高频词。
反过来，偶尔出现一次、且语义不难理解的普通词，一般不必收录。术语表的价值在于稳定关键词，而不是把词典无限扩张。
F.9.2 术语冲突处理¶
当两个术语都“看起来对”时，优先看三个维度：
- 读者是否更容易理解。
- 是否与行业惯例一致。
- 是否能和全书其他章节保持统一。
例如，某些场景里“匿名化”“脱敏”“去标识化”都可能出现，但如果全书主线是工程控制和发布边界，那么“脱敏”通常更适合作为主称；如果讨论的是法律意义上的不可识别，则应明确切换到更严格的语义，并补充法域说明。
F.9.3 术语表与章节标题¶
章节标题里尽量使用全书主词，而不是临时拼接的新说法。因为标题会进入目录、索引、交叉引用和检索结果，一旦标题分叉，后续维护成本会比正文高得多。标题中的术语最好满足两个条件：
- 是全书统一主词。
- 能概括本章核心内容。
如果标题必须保留某个行业习惯说法，建议在正文第一段立刻补全全称，并说明本书采用的写法。
F.10 附录使用清单¶
在正式写作前，建议作者过一遍这份简短清单：
- 关键术语是否已在本表中找到统一写法。
- 首次出现时是否给了中英文全称。
- 缩写是否可能与别的章节冲突。
- 表格和正文是否使用同一主称。
- 术语是否涉及合规、隐私或法域边界。
- 如果术语会影响实现，是否在正文说明了工程含义。
- 如果术语会影响评审，是否在图注或脚注中补了定义。
这一页的目的，是让写作者在动笔前就先把词说稳。词说稳了，内容才更容易稳。
F.11 附录小结¶
术语统一不是排版问题，而是团队协作问题。词汇稳定，结构才稳定；结构稳定，工程才容易复用。对于整本书来说，本附录的意义不在于“记住更多词”，而在于让所有章节说同一种工程语言。
F.12 扩展术语补充表¶
为了让正文更容易统一，下面补充一组常见但容易写散的术语。
| 中文术语 | 英文/缩写 | 说明 |
|---|---|---|
| 数据快照 | Snapshot | 某一时点的数据截面 |
| 数据版本 | Data Version | 可追踪的数据状态标识 |
| 配置版本 | Config Version | 可追踪的配置状态标识 |
| 回归测试 | Regression Test | 验证旧问题是否重新出现 |
| 抽检 | Sampling Audit | 对样本进行有限检查 |
| 证据链 | Evidence Chain | 支撑判断的完整材料链 |
| 审批门禁 | Approval Gate | 需要确认后才能继续的步骤 |
| 上下文窗口 | Context Window | 模型或工具可见的信息范围 |
| 失败回退 | Fallback | 主路径失败时的替代路径 |
| 发布窗口 | Release Window | 允许变更发布的时间段 |
这张补充表的作用，是覆盖正文中那些“不是主概念，但经常要写”的词。很多文章写乱，不是因为大词没定义，而是小词没有统一。
F.13 术语写作边界¶
有些词不能只按字面意思写，要先看它们在本书里的功能。
F.13.1 “模型”与“系统”¶
在很多章节里，真正被交付的不是模型本身，而是包含模型、数据、规则、缓存、接口和监控在内的系统。写作时如果只写“模型”，读者会误以为问题全部在算法上。
F.13.2 “准确率”与“可用性”¶
准确率是指标，可用性是体验。一个系统可能准确率不错，但因为延迟高、回退差或权限复杂而不可用。反之亦然。
F.13.3 “安全”与“合规”¶
安全更偏技术防护，合规更偏制度约束。二者相关，但不能互相替代。写作时如果把安全控制直接等同于合规满足，会让读者误判边界。DecodingTrust 对可信大模型的评估把隐私、鲁棒性、安全性、偏见和伦理等维度分开考察，也说明“安全”“合规”“可信”不能在正文中随意互换（Wang et al. 2023）。
F.13.4 “隐私”与“保密”¶
隐私通常涉及个体可识别性和使用边界，保密更强调信息不外泄。二者在某些场景重叠，但不是一回事。
F.14 译法选择原则¶
同一个英文术语可能有多个中文译法。选择时建议遵循以下顺序。对于已经在评测、透明度或风险研究中形成稳定用法的术语，应优先保持全书一致；对于带有治理或法律含义的术语，应保留使用边界说明（Liang et al. 2023; Bommasani et al. 2023）：
- 以全书一致性优先。
- 以行业惯例为其次。
- 以读者理解成本再其次。
- 以法域或标准要求为特殊例外。
例如，某些词在学术界和工业界存在不同译法，若全书已经约定主译法，就不要在后文随意换掉。对于跨章出现频繁的词，统一比“每章都觉得自己更顺口”更重要。
F.15 章节写作中的术语检查点¶
在每章定稿前，建议至少检查以下位置：
- 章节标题。
- 首段定义。
- 图题和图注。
- 表头和表注。
- 公式前后的变量说明。
- 引用里的缩写和全称。
- 脚注中的补充解释。
很多术语问题并不出现在正文段落里，而是出现在图表和脚注中。尤其是技术书，图表里的词一旦写散，读者会在翻阅时丢失上下文。
F.16 合规相关术语提醒¶
本书里涉及合规与隐私的词尤其要谨慎，因为这些词常常同时具有工程含义和法律含义。风险分类和透明度研究通常先界定系统能力、利益相关方、使用场景和披露范围，再讨论控制措施；因此术语表中的“合法”“授权”“可共享”等词都应被理解为需要上下文确认的判断项，而不是默认状态（Weidinger et al. 2022; Bommasani et al. 2023）。
F.16.1 “合法”¶
合法不是工程默认状态，而是需要按法域、用途、数据类型和处理方式逐项确认的结论。写作时不要把“实现了控制”直接等同于“已经合法”。
F.16.2 “授权”¶
授权不只是“能不能访问”，还包括“能不能用于当前目的”。权限和用途是两条线，不能混写。
F.16.3 “可共享”¶
可共享通常还要附带范围、条件、审查和撤回机制。单写“可共享”往往会让人误会成无条件开放。
F.17 附录使用示例¶
如果某一章讲的是数据卡片、谱系和门禁，推荐这样写：
本章将“数据卡片（Data Card）”用于记录数据集来源、范围和限制，将“谱系（Lineage）”用于记录流转路径，将“闸门（Gate）”用于表示关键步骤的控制点。
如果某一章讲的是隐私计算，推荐这样写：
本章采用“隐私增强技术（PETs）”作为统称；当具体讨论联邦学习、差分隐私或安全多方计算时，再分别给出其边界与适用场景。
这样写的好处是，读者不会在同一页面里同时面对三个互相竞争的叫法。
F.18 附录补充小结¶
术语表的扩充不是为了让文字更重，而是为了让全书更稳。对工程书来说，词是接口，接口统一了，章节之间才能真正联通。
F.19 章节标题的术语统一¶
章节标题是术语表最容易被忽视、但最容易失控的地方。因为标题一旦写散，目录、搜索和交叉引用都会跟着分叉。
建议标题遵循三个原则：
- 优先使用全书主词。
- 尽量避免同一概念在标题里换说法。
- 如果标题必须兼顾读者理解，可以在副标题中补充说明，但主词不要变。
例如，如果全书统一使用“数据卡片”，标题里就不要一会儿写“数据说明”，一会儿写“dataset note”。标题稳定，后面的术语维护成本会小很多。
F.20 图表中的术语写法¶
图题、图注和表头比正文更容易出错，因为它们常常是临时补的。
建议遵循：
- 图题尽量短，但主词要准确。
- 图注第一次出现时补全全称。
- 表头尽量使用统一主词。
- 图内标签尽量少换简称。
如果图太复杂，宁可拆成两张，也不要在一张图里塞进三个不同叫法。图一旦写乱，读者就得来回翻正文找词。
F.21 缩写的收录与淘汰¶
缩写不是越多越好。判断一个缩写是否应该保留，主要看四点：
- 是否在全书中反复出现。
- 是否确实比全称更省认知。
- 是否不会和别的缩写混淆。
- 是否已经被行业普遍接受。
反过来，如果某个缩写只在一两处出现，或者会和其他术语撞车，最好少用甚至不用。少一个缩写，通常比多一个猜谜游戏更好。
F.22 额外常见术语¶
| 中文术语 | 英文/缩写 | 说明 |
|---|---|---|
| 检索增强生成 | RAG | Retrieval-Augmented Generation |
| 数据运维 | DataOps | 面向数据链路的运维方式 |
| 机器学习运维 | MLOps | 面向模型生命周期的运维方式 |
| 大模型运维 | LLMOps | 面向大模型应用的运维方式 |
| 特征存储 | Feature Store | 用于管理特征的共享层 |
| 访问控制 | RBAC/ABAC | 基于角色或属性的访问控制 |
| 个体信息 | PII | Personally Identifiable Information |
| 数据处理协议 | DPA | Data Processing Agreement |
| 数据保护影响评估 | DPIA | Data Protection Impact Assessment |
这些术语在技术书里很常见，但含义并不总是一致。最稳妥的做法，是在首次出现时给出全称，并在本书语境下定义使用范围。
F.23 术语表维护流程¶
术语表也需要版本管理。基础模型透明度和整体评测框架都提示，模型、数据、风险与评测口径会随着系统版本变化而变化，因此术语表也应像其他治理材料一样保留修订记录、影响范围和最终裁决机制（Bommasani et al. 2023; Liang et al. 2023）。建议每次修订时做四步：
- 扫描新增术语。
- 检查旧术语是否出现新译法。
- 核对图表、标题和正文是否一致。
- 记录本次改动的影响范围。
如果多人共同维护，最好指定一个最终裁决人。否则术语表会越改越多，但越改越散。
F.24 面向本书主线的扩展术语¶
结合本书当前的章节主线，下面这组术语建议直接纳入统一口径。
| 中文术语 | 英文/缩写 | 说明 |
|---|---|---|
| 推理 | Inference | 模型根据输入生成结果的过程 |
| 轨迹 | Trace / Trajectory | 记录 Agent 或流程的事件路径 |
| 检索增强生成 | RAG | 把检索与生成结合的方案 |
| 大模型应用 | LLM Application | 面向业务落地的应用层系统 |
| 多模态模型 | Multimodal Model | 同时处理文本、图像等多种模态 |
| 视觉语言模型 | VLM | Vision-Language Model |
| 文生图 | T2I | Text-to-Image |
| 文生视频 | T2V | Text-to-Video |
| 数据运营 | DataOps | 面向数据链路的运营与运维 |
| 隐私保护 | Privacy Protection | 涉及访问、使用和发布边界 |
| 风险评估 | Risk Assessment | 对失败、滥用和合规风险的判断 |
这些词如果不统一，最容易在章节标题、图题和表格里出现分叉。建议正文一律用主称，英文只在首次出现时保留。
F.25 术语在章节中的落地¶
一个术语要真正稳定下来，不能只存在于表里，还要体现在正文里。建议每章至少做两件事：
- 在首段定义本章主词。
- 在图表里保持同一叫法。
例如，讲 Agent 的章节就不要一会儿写“智能体”，一会儿写“代理”，一会儿又写“助手”，除非你明确在讨论不同层级。讲多模态内容的章节也要注意，VLM、T2I、T2V 这些词最好在前面先统一，否则读者会误以为它们是同一类东西。
F.26 术语表的三种常见误用¶
F.26.1 把英文缩写当成中文替代词¶
缩写是为了便于沟通，不是为了增加神秘感。正文里如果可以直接用中文主词，就不要一直堆缩写。
F.26.2 把同义词同时当主词¶
同一个概念如果同一章里写了两个主词，读者就会开始怀疑是不是有两个不同对象。术语表的目标恰恰是避免这种分裂。
F.26.3 把工程概念写成法律结论¶
尤其在隐私、合规和发布边界上，术语很容易从工程描述滑向法律判断。写作时要明确区分“系统做了什么”和“法律上是否满足要求”。
参考文献¶
Bommasani R, Klyman K, Zhang D, Liang P (2023) The Foundation Model Transparency Index. arXiv preprint arXiv:2310.12941.
Gebru T, Morgenstern J, Vecchione B, Vaughan J W, Wallach H, Daumé H, Crawford K (2021) Datasheets for Datasets. Communications of the ACM 64(12):86-92. https://doi.org/10.1145/3458723.
Liang P, Bommasani R, Lee T, et al. (2023) Holistic Evaluation of Language Models. Transactions on Machine Learning Research. arXiv:2211.09110.
Mitchell M, Wu S, Zaldivar A, Barnes P, Vasserman L, Hutchinson B, Spitzer E, Raji I D, Gebru T (2019) Model Cards for Model Reporting. In: Proceedings of the Conference on Fairness, Accountability, and Transparency, pp 220-229. https://doi.org/10.1145/3287560.3287596.
Pushkarna M, Zaldivar A, Kjartansson O (2022) Data Cards: Purposeful and Transparent Dataset Documentation for Responsible AI. In: Proceedings of the 2022 ACM Conference on Fairness, Accountability, and Transparency, pp 1776-1826. https://doi.org/10.1145/3531146.3533231.
Wang B, Chen W, Pei H, et al. (2023) DecodingTrust: A Comprehensive Assessment of Trustworthiness in GPT Models. In: Advances in Neural Information Processing Systems 36. https://doi.org/10.52202/075280-1361.
Weidinger L, Uesato J, Rauh M, Griffin C, Huang P-S, Mellor J, Glaese A, Cheng M, Balle B, Kasirzadeh A, Kenton Z, Brown S, Hawkins W, Stepleton T, Birhane A, Haas J, Rimell L, Hendricks L A, Isaac W, Legassick S, Irving G, Gabriel I (2022) Taxonomy of Risks posed by Language Models. In: Proceedings of the 2022 ACM Conference on Fairness, Accountability, and Transparency, pp 214-229. https://doi.org/10.1145/3531146.3533088.