附录A：工具与框架速查表¶
A.1 附录定位¶
本附录面向整本书的工程落地环节，目标不是罗列“所有常见工具”，而是回答一个更实际的问题：当团队已经明确要做数据采集、清洗、评测、实验追踪、开放发布和教学复现时，应该如何在不同阶段选择合适的工具栈，并理解它们之间的职责边界。
在真实项目里，工具选型最常见的失败方式不是“选错了某一个框架”，而是把不同层的问题混在一起。例如，团队本来缺的是版本治理，却试图通过再加一个数据处理脚本来补；本来缺的是评测可复查性，却把预算继续砸在训练上；本来缺的是教学镜像与课程环境，却误以为只要开源仓库公开了就等于“可复现”。因此，本附录采用“数据工程生命周期”组织工具，而不是按社区热度或厂商名称组织。
阅读时建议始终记住三条原则。第一，工具不是流程的替代品，流程不清时，换工具通常只会把混乱迁移到新的界面。第二，数据工程最重要的是接口与边界，即采集、清洗、标注、评测、发布和回流之间各自负责什么。第三，越靠近开放基准与高校合作场景，越要优先考虑可审计、可移交与可教学复现，而不是只看单次吞吐或单次跑分。这里的“可审计”也包括对数据集、模型和数据卡片的结构化说明；Datasheets for Datasets、Model Cards 和 Data Cards 分别提供了可借鉴的文档化框架（Gebru et al. 2021; Mitchell et al. 2019; Pushkarna et al. 2022）。
A.2 生命周期视角下的工具总览¶
表 A-1 给出一个尽量“能直接落地”的粗粒度映射。它不是单一标准答案，但足以帮助团队先把问题放到正确的层次上。
| 阶段 | 主要目标 | 常见交付物 | 优先工具类别 | 典型风险 |
|---|---|---|---|---|
| 数据接入 | 把外部来源转成可管理输入 | 抓取结果、原始文件、接入日志 | 抓取框架、连接器、对象存储 | 来源不可追溯、采集口径不一致 |
| 数据清洗 | 去噪、去重、标准化、去污染 | 清洗规则、异常样本池、质量报告 | 批处理框架、规则引擎、质量校验工具 | 清洗动作不可复现、误删高价值样本 |
| 标注与增强 | 形成可训练监督信号 | 标注任务、QA 流程、增强产物 | 标注平台、审阅系统、合成生成框架 | 口径漂移、审阅链断裂 |
| 训练准备 | 打包成模型可消费格式 | JSONL/Parquet/Arrow、split、索引 | 数据格式库、分词与打包工具 | 训练输入和评测输入不一致 |
| 评测归因 | 建立可比较实验 | 指标脚本、切片报告、归因台账 | 评测框架、实验追踪、可视化面板 | 只看平均分、不保留证据 |
| 开放发布 | 形成可复用资产 | Card、license、baseline bundle | 数据卡片、模型卡片、版本发布工具 | 版本不可回滚、基线失效 |
| 教学与复现 | 让他人能稳定重现 | 教学镜像、实验说明、固定版本 | 容器、环境管理、课程仓库 | 学期中环境漂移、脚本失效 |
这张表最重要的作用，不是让团队“立刻决定用什么”，而是先确认我们现在到底在解决哪一类问题。很多争论一旦从“我更喜欢哪个框架”转回“这一步的交付物究竟是什么”，决策会容易很多。
A.3 数据接入、存储与版本治理工具¶
A.3.1 接入层工具首先解决的是来源标准化¶
如果团队的数据来源跨网页、文档库、企业表格、对象存储和第三方开放集，就不可能长期依赖纯手工下载加脚本拼接。接入层最重要的不是花哨，而是把“从哪来、什么时候来、用什么规则来”固定下来。
| 类别 | 代表工具/框架 | 适用场景 | 优势 | 需要额外注意的问题 |
|---|---|---|---|---|
| 网页抓取 | Scrapy、Trafilatura | 公网文本、资讯、知识库 | 生态成熟、易定制 | robots、版权、更新频率 |
| API/DB 连接器 | Airbyte、Fivetran 类连接器 | SaaS、数据库、内部业务源 | 接入规范化、易做增量 | 字段变更管理、权限最小化 |
| 文档导入 | Unstructured、Apache Tika | PDF、Office、扫描件 | 快速统一文档入口 | OCR 误差、版面解析偏差 |
| 对象存储接入 | S3/OSS/MinIO SDK | 图片、音频、视频、大文件 | 适合湖仓与离线处理 | 生命周期策略与成本控制 |
对于本书关心的大模型数据工程，接入层最好始终保留两份记录。一份是原始入口记录，说明数据从哪来、拉取时间、授权口径、过滤条件。另一份是工程化入口记录，说明进入下游前是否做过格式转换、脱敏、切片或抽样。没有这两份记录，后面的清洗、评测和合规很难说清边界。
A.3.2 存储层的关键不是“大”，而是可分层¶
很多团队早期会把所有东西都堆在一个对象存储桶里，短期看很省事，长期会迅速出现两个问题：没人说得清“哪一层是原始层、哪一层是清洗层”，也没人说得清“哪个版本被下游消费过”。因此，存储层至少要有分层意识。
| 分层 | 推荐承载方式 | 说明 |
|---|---|---|
| Raw 层 | 对象存储原样保存 | 保留最原始来源，不轻易覆盖 |
| Staging 层 | Parquet/JSONL/Arrow 中间格式 | 面向清洗、抽样、质检 |
| Curated 层 | 可训练/可评测标准集 | 进入训练与评测的正式版本 |
| Release 层 | 发布包、Card、baseline bundle | 面向外部使用或课程复现 |
对象存储本身只负责“放着”，并不自动提供版本语义。若团队明确要做长期演进，最好再叠加版本化工具，例如 DVC、lakeFS 或者带 snapshot 能力的数据湖方案。这样做的价值不在于“显得更专业”，而在于后续能够回答现实的问题：某个实验到底消费了哪一版数据，某个公开榜单是否能追溯到对应 split，某学期课程环境是否锁定在发布时的那一版。
A.3.3 版本治理工具更像团队记忆系统¶
Git 适合管理文本配置与脚本，但不天然适合直接管理大体量数据资产。因此，数据工程里往往会把 Git 用作控制平面，把大文件版本系统用作数据平面。
| 工具 | 更适合管理什么 | 典型用途 |
|---|---|---|
| Git | 代码、配置、schema、文档 | 流程定义、评测脚本、发布说明 |
| Git LFS | 中等规模二进制文件 | 小规模模型文件、示例数据 |
| DVC | 大文件与数据版本引用 | 数据集版本、实验输入绑定 |
| lakeFS | 面向对象存储的分支与提交 | 湖仓式数据治理、团队协作 |
| Delta Lake / Apache Iceberg | 表格式大规模数据治理 | 大批量结构化样本与元数据管理 |
如果团队处在“跨机构共建数据集 + 公开评测 + 教学复现”的复合场景，最推荐的不是单纯追求某个单一最优工具，而是建立一个最小组合：Git 管脚本与规范，DVC 或等价系统管数据版本，对象存储管大文件，发布页管对外说明。这套组合最容易交接、最容易课程复现，也最容易和第八篇、第十二篇形成一致治理语言。具体的数据版本命令、远端配置和流水线写法应以 DVC 官方文档为准（DVC Contributors 2026）。
A.4 清洗、校验与训练准备工具¶
A.4.1 批处理框架的选择要围绕“数据形态”¶
清洗工具最容易陷入“统一用一个大框架”的惯性，但文本、表格、文档图像、音频和 Agent 轨迹对处理模式的要求差异很大。更有效的原则是按数据形态分工：
| 数据形态 | 推荐处理方式 | 常见工具 |
|---|---|---|
| 大规模文本行级处理 | 批式 map/filter/reduce | Spark、Ray Data、Beam |
| 文档与表格解析 | 流式抽取 + 结构校验 | Unstructured、Pandas、Arrow |
| 多模态样本 | 元数据批处理 + 文件引用 | Ray、PyArrow、对象存储索引 |
| 音视频 | 离线转码与特征提取 | FFmpeg、torchaudio、decord |
| Agent 轨迹 | 结构事件流与 replay | JSONL、Parquet、定制验证器 |
Spark 的优势在于成熟稳定，适合重批处理与企业数据平台；Ray Data 更适合与 Python 生态、模型推理和多模态处理靠近；Beam 更适合需要统一批流模型的场景。对大多数图书配套项目、实验室和课程项目来说，不要把“是否足够分布式”误当成首要问题。更常见的瓶颈其实是数据约定不清、字段不稳、异常样本无回收路径。
A.4.2 质量校验工具要服务于“可解释失败”¶
质量校验不是为了追求“0 错误”，而是为了把错误分门别类，并形成后续回写动作。像 Great Expectations 这类数据质量框架，适合管理结构化规则；而对于文档、多模态和推理数据，更常见的是自定义校验器。
| 校验层 | 需要回答的问题 | 工具形态 |
|---|---|---|
| 结构层 | JSON/表字段是否完整 | schema validator、Pydantic |
| 统计层 | 分布是否漂移、异常值是否暴涨 | profiling、仪表盘 |
| 语义层 | 样本是否自洽、是否答非所问 | LLM judge、人工抽检 |
| 任务层 | 是否仍满足训练/评测协议 | 专项脚本、任务验证器 |
对于第十二篇的专项数据集案例，质量校验器最好最终能把输出写成三类对象：失败样本池、失败原因分类、对应修复建议。这样一来，清洗不再只是“删掉低质量数据”，而是变成“把问题转译成后续行动”的过程。
A.4.3 去重、去污染与切分要分开治理¶
不少团队把去重、去污染和 train/val/test 切分混在同一步做，这会给后续解释带来巨大困难。更稳妥的做法是三步拆开：
- 先做近重复与完全重复检测。
- 再做评测污染与基准隔离检查。
- 最后做正式切分与版本冻结。
文本任务里常见 MinHash、SimHash、n-gram overlap；文档与图像任务需要同时考虑视觉近重复与版式近重复；代码与推理任务还要关注模板污染、题库污染和评测提示泄漏。真正成熟的流程，应该让后续读者能够明确区分：这个样本是因为重复被排除，还是因为污染被排除，还是因为版本切分策略没有纳入。
A.5 标注、实验追踪与评测工具¶
A.5.1 标注平台选型首先看 QA 链是否完整¶
标注平台的核心并不是界面漂不漂亮，而是能否支撑任务定义、审阅链、仲裁和回写。对于指令、偏好、多模态和语音任务，这一点尤其重要。
| 场景 | 更看重的能力 | 常见平台方向 |
|---|---|---|
| 文本分类/抽取 | 规则化标注、质检抽样 | Label Studio、Doccano |
| 偏好/排序 | 成对比较、仲裁、审阅 | 定制平台、问卷式标注系统 |
| 文档/多模态 | 区域级标注、框选、OCR 联动 | Label Studio、CVAT 类工具 |
| 语音 | 波形播放、切片、说话人与情绪标记 | 语音专用标注平台 |
如果项目后续要变成开放基准或课程实验，标注平台至少要保留四类信息：标注版本、说明文档版本、审阅结论、争议样本列表。只保存最终标签而不保存过程，会让后续很难重建为什么某个边界样本会被那样定义。
A.5.2 实验追踪工具最重要的是绑定“数据版本”¶
MLflow、Weights & Biases 一类工具，最常见的误用方式是只记录模型参数和指标，却不绑定数据版本、切片结果和评测脚本版本。这样一来，实验日志看似丰富，实际上无法解释提升来源。若使用 MLflow 作为实验追踪入口，运行记录、artifact 管理和模型注册等细节应参照 MLflow 官方文档（MLflow Authors 2026）。
建议实验追踪最少绑定以下字段：
| 字段 | 说明 |
|---|---|
| dataset_version | 训练或评测数据版本号 |
| split_version | 切分策略版本 |
| eval_script_version | 指标脚本版本 |
| prompt_or_template_version | 提示或模板版本 |
| slice_report_uri | 切片报告位置 |
| writeback_decision | 是否回写数据策略 |
当这些字段被稳定记录后，实验追踪才真正从“记录跑过什么”升级为“记录为什么跑、为什么变好、为什么值得相信”。
A.5.3 评测框架要能支撑切片与证据保存¶
面向大模型评测的工具越来越多，但第十二篇强调的工程诉求与单次 benchmark 不同。我们更需要的是：指标可复现、切片可解释、证据可保存、版本可追溯。也就是说，评测框架最好具备以下能力：
- 支持多指标并行，而不是只吐一个总分。
- 支持切片报告和错误样本导出。
- 支持评测输入与输出的结构化保存。
- 支持重复运行与历史版本对比。
只有具备这些能力，评测结果才有可能进入附录 B 的上线检查和附录 C 的成本预算环节。
A.6 多模态、RAG 与 Agent 场景的专项工具¶
A.6.1 文档与多模态工具链要明确“解析”和“判定”不是一回事¶
在文档理解、表格解析、图表推理和多模态 RAG 场景里，团队很容易把 OCR、版面分析、检索和最终问答混成一个大模型不可解释状态。工具链上更好的做法，是把四类能力拆开：
| 能力层 | 作用 | 常见工具方向 |
|---|---|---|
| 解析层 | 从原始文件中抽取文本、区域和结构 | OCR、文档解析库、版面分析模型 |
| 存储层 | 保存 chunk、bbox、页码、证据元数据 | 向量库、对象存储、结构表 |
| 检索层 | 召回候选证据束 | BM25、向量检索、混合检索 |
| 判定层 | 组织答案、拒答、给出证据引用 | LLM、规则校验、judge |
这样拆开的好处是，团队可以明确知道问题究竟出在“没抽出来”“没召回到”还是“召回到了但没用对”。这与第十二篇中对证据完整性、越权正确和行为稳定性的讨论是完全一致的。
A.6.2 Agent 数据工具链要把轨迹视为正式资产¶
Agent 工具调用数据与普通问答数据最大的不同，是其中的中间状态本身就是训练资产。凡是会影响模型后续行为的事件，例如函数选择、参数、观察结果、错误恢复、停止条件，都不应只被当作临时日志。
因此，Agent 场景的工具选型要特别看重：
- 能否保存完整事件序列。
- 能否重放关键步骤。
- 能否把 observation 与最终答案一起绑定。
- 能否抽取失败轨迹形成专项评测集。
如果这些能力缺失，团队后续即使拿到了不错的最终准确率，也很难解释行为是否稳定，更难把结果转成教学实验。
A.7 可直接落地的最小组合方案¶
为了避免“选型过度设计”，这里给出三套足够实用的最小组合。
A.7.1 实验室/课程型最小组合¶
- 代码与规范：
Git - 数据版本：
DVC - 存储：对象存储或网络盘
- 清洗处理：
Python + Ray/Pandas - 标注：
Label Studio或Doccano - 实验追踪：
MLflow - 发布：
Hugging Face Hub或项目主页
这套组合最适合跨机构专项数据集、课程复现实验和中等规模研究项目。它的优点是不重，交接成本相对低。若数据集采用 Hugging Face Datasets 生态组织和分发，加载脚本、数据集卡片和 split 配置应参照 Hugging Face Datasets 官方文档（Hugging Face 2026）。
A.7.2 企业数据平台型组合¶
- 工作流调度：
Airflow - 分布式处理：
Spark - 湖仓治理：
Iceberg/Delta - 质量校验：
Great Expectations - 实验追踪：
MLflow或企业内部平台 - 对外发布：内外部分级仓库与审计面板
这套组合的重点不在“单次开发快”，而在“多人协作下边界稳定”。
A.7.3 多模态与 Agent 强耦合型组合¶
- 文件与元数据：对象存储 + 结构表
- 批处理：
Ray Data - 文档解析：OCR / Unstructured / 定制管线
- 检索与证据：向量库 + 规则索引
- 轨迹记录：JSONL/Parquet + replay 工具
- 评测归因：专项脚本 + 实验追踪平台
这一组合尤其适合第十二篇 Ch38-Ch41 的问题空间，因为它天然支持文档、表格、图表、多模态和 Agent 工具轨迹的统一治理。
A.8 工具选型时最值得问的十个问题¶
工具真正应该围绕问题被选择，而不是反过来让问题去适应工具。下面十个问题，基本可以作为大多数团队的初筛问卷。
- 这个工具解决的是采集、治理、评测还是发布问题？
- 它能否和现有版本系统稳定对接？
- 失败样本能否被单独导出与回收？
- 是否支持固定版本供教学复现？
- 权限、审计和最小暴露原则是否容易实现？
- 是否支持结构化元数据而不只是文件堆放？
- 能否支撑多模态或多轮轨迹，而不只是一行文本？
- 当团队成员更替时，交接成本高不高？
- 是否存在被厂商或单个工程师深度锁定的风险？
- 如果一年后要做公开基准，它还能不能继续承载？
只要这十个问题里有四五个答不上来，说明当前并不适合立刻大规模铺开，而应该先补流程设计。
A.8.1 典型选型误区速查¶
除了“选什么”，团队还应学会识别“哪些选型理由本身就不成立”。真实项目中常见的四类误区如下：
| 误区 | 表面理由 | 实际问题 |
|---|---|---|
| 用一个大平台解决所有问题 | 统一更省事 | 不同阶段的边界被平台 UI 掩盖 |
| 只看吞吐和 benchmark | 工具越快越先进 | 忽略审计、交接、教学复现与失败样本回收 |
| 只听单个工程师经验 | 某人过去项目用得顺手 | 缺少组织级知识沉淀与替代预案 |
| 先上工具后补流程 | 先运行起来再说 | 后续接口越来越乱，返工成本高 |
这些误区之所以危险，不是因为它们完全错误，而是因为它们都带有一部分真实诱因。平台统一确实可能减少初期集成成本，单个熟练工程师也确实能提升短期效率，吞吐指标也确实值得关注。但如果这些理由替代了对资产生命周期的完整判断，团队就很容易在两三个版本之后失去治理能力。
A.8.2 面向项目、专项数据集与附录模板的推荐映射¶
将正文中的项目实践、专项数据集案例与附录模板连在一起看，可以形成一套更明确的工具落点图。这个映射的目的不是为工具排序，而是帮助读者判断每类任务最应优先补齐哪一层工程能力。
- 面向预训练与后训练配方，优先强调批处理、版本治理、实验追踪和数据卡片。
- 面向推理、多模态与生成场景，优先强调轨迹记录、评测切片、存储分层和推理服务。
- 面向专项数据集案例，优先强调事实核验、样本 schema、构建流水线、评测协议、合规审计和复现边界。
- 面向附录 A-H，重点承担“把这些工具能力转化为可执行清单和模板”的职责。
这样的映射提醒读者，附录并不是正文之外的次要补充，而是把正文里出现过的工程能力重新整理成能被项目经理、助教、平台工程师和维护者直接调用的操作层语言。
A.9 本附录建议长期维护的速查字段¶
为了让本附录不只是书上的说明，而能直接转成团队资产，建议维护一份工具清单表，每季度更新一次。正式维护表中的每个工具条目至少应统一给出官网或官方文档入口、建议版本或验证版本、许可证或使用条款，以及适用篇章或项目范围。表 A-9 给出了推荐字段。
| 字段 | 说明 |
|---|---|
| tool_name | 工具名称 |
| official_site_or_docs | 官网、官方文档或稳定发布页 |
| recommended_version | 本书示例建议版本、最低兼容版本或最近验证版本 |
| license_or_terms | 开源许可证、商业授权、服务条款或使用限制 |
| applicable_chapters | 适用篇章、章节、项目或附录 |
| stage | 所属阶段 |
| primary_use | 在数据工程生命周期中的主要用途 |
| owner | 责任人或责任组 |
| current_version | 当前使用版本 |
| replacement_plan | 替代或升级计划 |
| dependency_risk | 外部依赖风险 |
| teaching_ready | 是否可进入课程镜像 |
| public_release_ready | 是否适合开放发布 |
这份速查字段的价值，在于它能把“工具认知”变成“组织记忆”。一年之后，即使参与人员有变化，团队仍能快速理解为什么当时这样选型、哪里可以替换、哪里绝对不能随意动。
A.10 本附录小结¶
本附录从生命周期出发整理了数据工程常见工具与框架。核心结论有三条。
第一，工具选型的前提不是热度，而是先说清当前阶段的交付物与失败模式。
第二，真正长期有效的工具组合，通常不是单一大平台，而是“版本控制 + 数据存储 + 批处理 + 质检 + 评测追踪 + 发布治理”的边界化组合。
第三，对于高校合作、开放基准和教学复现场景来说，可交接、可复现、可审计 往往比单次吞吐更重要。
参考文献¶
Gebru T, Morgenstern J, Vecchione B, Vaughan J W, Wallach H, Daumé III H, Crawford K (2021) Datasheets for Datasets. Communications of the ACM 64(12): 86-92. https://doi.org/10.1145/3458723.
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.
DVC Contributors (2026) Data Version Control Documentation. https://dvc.org/doc.
MLflow Authors (2026) MLflow Documentation. https://mlflow.org/docs/latest/.
Hugging Face (2026) Hugging Face Datasets Documentation. https://huggingface.co/docs/datasets.