用于 LLM 微调的本地数据准备管道

如果你为医疗、金融、法律或政府领域的企业交付微调或 AI 解决方案，你早就清楚那条约束：数据不能出楼。不能进云端 API，不能进 SaaS 标注平台，连供应商那套跑在别人机房里的「私有」实例也不行。

这条约束会重塑整条数据准备管道。多数开源工具默认你有云端访问、云端存储和云端算力。把这些前提抽掉之后，剩下的技术栈是零散的，维护成本高，而且很难交接给缺少 ML 工程背景的客户团队。

本指南讲的是如何为 LLM 微调搭建一条完整的本地数据准备管道：每条管道都绕不开的五个阶段、每个阶段真正可选的工具，以及零散的开源方案会在哪里失灵。

本地数据准备为什么对服务提供商格外重要

服务提供商，也就是咨询公司、系统集成商和小型 ML 团队，面对的是本地化难题的一个特殊版本。你要搭的是必须满足这些条件的管道：

跑在你无法掌控的客户基础设施里
产出能通过客户合规团队审查的审计链路
让领域专家（护士、律师、分析师）能上手操作，他们不会去写 Python 脚本
支持多种导出格式，因为下游模型和使用场景每个项目都不一样

医院系统请你把临床记录整理成微调数据时，管道要跑在他们自己的硬件上，日志要完整，他们的临床人员还要能复核和修正标签。银行请你做文档分类模型时，约束是同一套，只不过合规依据从 HIPAA 换成了 SOC 2 和 SR 11-7。

共同点就三条：零数据外泄、完整审计链路、非工程师也能用。

完整数据准备管道的 5 个阶段

用于 LLM 微调的数据准备管道都要走完五个阶段。少走一个，你就得花上几周去排查微调后的模型为什么表现不达标。

阶段 1：摄入

原始的企业文档，PDF、Word 文件、Excel 表格、扫描件、CAD 图纸，都需要先解析成结构化文本。这件事比听上去难。

1998 年的扫描版 PDF 要走 OCR。表格排版复杂的现代 PDF 需要版面感知的抽取。带修订记录的 Word 文档还要有一套逻辑来决定抽取哪个版本。企业规模的多格式摄入，意味着要稳定处理 50 种以上的文件类型。

关于摄入的难点和 OCR 方案的深入讨论，见我们的企业 AI 本地文档摄入设置指南。

阶段 2：清洗

摄入得到的文本很少能直接拿去训练。里面有重复记录、编码残留、必须脱敏的 PII／PHI、不一致的格式，还有会拖累模型表现的低质量段落。

清洗包括去重（完全重复，以及用 MinHash 找出的近似重复）、文本标准化、PII 识别与脱敏，还有质量过滤。每一步都必须在本地完成，不能为了识别 PII 就把文本发给云端 NER 服务。

我们的ML 训练数据集的本地数据清洗指南详细讲了去重、标准化和质量评分。

阶段 3：标注

微调需要带标签的数据：指令／回答对、分类标签、实体标注或偏好排序。规模化标注要么靠有领域经验的人工标注者，要么靠 AI 预标注加上人工复核。

用本地大模型做预标注现在已经很实用。通过 Ollama 跑一个 7B 的指令跟随模型，就能生成草稿标签交给领域专家修正，标注时间能压缩 40% 到 60%，而数据一步都没有离开本地。

技术细节见零数据外泄的本地大模型辅助数据标注。

阶段 4：增强

企业场景里数据集小是常态。一家医院可能只有 2,000 份相关的临床记录，一家律所可能只有 500 份对得上类型的合同。真实数据不够时，就靠合成数据来补：改写、从文档生成指令、构造 DPO 偏好对、扩展种子样本。

在气隙环境里，所有生成都得用本地模型。这把可选范围限制在开放权重模型上，但数据集的扩充幅度依然可观。

我们的气隙环境中的合成数据生成指南完整走了一遍这套流程。

阶段 5：导出

同一份准备好的数据集，往往要导出成好几种格式：给 LLM 微调用的 JSONL、给 RAG 管道用的分块文本、给计算机视觉用的 COCO 或 YOLO 标注、给传统 ML 用的 CSV，还有给智能体训练用的结构化 JSON。

多数工具只管一种导出格式。需要三种，你就得维护三个导出脚本，每一个都可能成为格式错误和数据漂移的源头。

完整拆解见从单一数据管道导出多种格式。

零散的开源技术栈：实际长什么样

2026 年最常见的本地数据准备技术栈，是把三到七个独立工具拼在一起：

阶段	常用工具	局限
摄入	Docling、Unstructured.io	不带清洗和标注；输出要自己写解析
清洗	Cleanlab、自研 Python 脚本	需要 ML 工程能力；没有图形界面
标注	Label Studio、Prodigy	要单独部署；没有原生的本地大模型集成
增强	Distilabel、自研脚本	只有流水线形态；需要熟练使用 Python
导出	每种格式一套自研脚本	临时维护；不带校验

这套能用。每天都有团队靠它交付项目。但代价是实打实的：

集成税：每个工具都有自己的数据格式、配置方式和部署要求。数据从 Docling 的输出经 Cleanlab 进到 Label Studio，再喂给自研的导出脚本，每一个衔接处都要写胶水代码并长期维护。

没有统一的审计链路：合规团队问「把 #4,721 号记录经历过的每一次转换都列给我看」的时候，你得从五个工具各自的日志里把答案重新拼出来，前提还是它们记录的粒度都够细。

领域专家用不了：护士跑不了 Cleanlab 的去重流程，合同律师配不来 Distilabel 的改写生成。这条管道只有 ML 工程师在操作时才转得动，于是形成瓶颈，每一轮迭代都被拖慢。

可复现性有缺口：六个月后重跑这条管道，输出还一样吗？五个工具停在五个不同版本上，答案通常是「不一样」。

其他可选方案

有几个项目试图解决其中一部分问题：

IBM Data Prep Kit 提供了一套模块化的数据准备框架，重点面向企业场景。它覆盖摄入和部分清洗步骤，但不包含标注、增强和多格式导出。它是代码优先的，对 ML 工程师好用，领域专家却上不了手。

OnPrem.LLM 专注于在本地跑 LLM 推理来处理文档。它能做一部分摄入和生成任务，但本质是一个库，而不是完整的管道工具。没有审计链路，没有图形界面，也没有导出校验。

Argilla 提供标注和反馈收集，带一些质量评分能力。标注阶段它做得不错，摄入、清洗和导出则不在覆盖范围内。

这些方案各自覆盖一到两个阶段。没有哪一个提供统一的管道：同一套数据模型、一致的审计日志，再加上一个非工程师也能操作的界面。

本地数据准备管道的架构

设计得当的本地管道具备这几项架构特征：

统一的数据模型：每条记录都在同一个系统里走完五个阶段。工具之间不做文件格式转换，阶段边界上也不做数据的序列化和反序列化。

不可变的审计日志：每一次转换都带时间戳、操作者和前后状态记入日志，包括文件解析、重复移除、标签应用、合成样本生成和导出创建。这份日志可查询、可导出，直接用于合规审查。

本地大模型集成：AI 辅助功能（预标注、质量评分、合成生成）通过 Ollama 或 llama.cpp 调用本地模型推理，不需要任何网络请求。机器有没有联网，系统的行为完全一致。

基于角色的权限：ML 工程师配置管道各阶段，领域专家复核和修正标签，项目经理跟进进度并导出报告。每个角色看到的都是与其专业相称的界面。

带校验的多格式导出：从同一个项目导出 JSONL、COCO、YOLO、CSV、分块文本或结构化 JSON，导出定稿之前先做 schema 校验，确保格式无误。

Ertas Data Suite 把这套架构实现成了一个用 Tauri 2.0（Rust + React）构建的原生桌面应用。它完全在本地运行，运行时不需要联网，把五个管道阶段整合进同一个工具，并提供零散技术栈缺失的审计链路和领域专家可用性。它支持 64 种以上文件类型的摄入，内置去重和质量评分，通过 Ollama／llama.cpp 支持本地大模型辅助的标注与增强，并能从同一个项目导出到所有主流格式。

实用建议

如果你在为受监管行业的客户搭建本地数据准备管道：

把项目时间的 60% 到 70% 留给数据准备。 这是企业 AI 项目实测下来的平均值。
选客户团队在你撤出之后还能继续操作的工具。 如果只有你的 ML 工程师跑得动这条管道，客户每次更新数据集都得再找你一次，对收入也许是好事，对关系不是。
审计链路从第一天就建起来。 等管道跑起来之后再补数据血缘，既贵又容易出错。合规团队一定会要，提前规划。
尽早测试导出格式。 别等到要开始微调了才发现格式有问题。管道搭建阶段就按每种目标格式各导出一小批，拿到下游验证一遍。
用本地大模型给标注提速。 就算用较小的模型，AI 预标注带来的效率提升也很明显。让 7B 模型先生成草稿标签、再由领域专家修正，比领域专家从零开始快得多。

这件事在全局里的位置

对受监管的企业客户来说，本地数据准备是让后面所有环节成立的地基，微调、部署、监控都建在它上面。训练数据不干净、标签不到位、格式不对，再多的 GPU 硬件、再精巧的模型架构，也做不出能在生产环境里跑得住的模型。

本指南是一个系列的中心页，系列里每篇深入讲一个管道阶段。摄入、清洗、标注、增强、导出和质量评分的技术细节，见文中各处链接的专题指南。