企业官网建设流程全解析

模型微调的效果，既依赖于基座模型的能力，也和用于后训练的数据集有很大关系。

在大模型没有出现的时代，从零制作一份高质量的数据集的SOP是这样的：人工收集语料->搭建标注平台->人工标注->人工审核->最终导出，低效、昂贵且痛苦。

而现在受益于大模型能力的飞升， 依托于 LLM 的数据集构建工作流，理论上可以帮助我们节省数据工程 90% 的工作量。

1. 整体流程

Pipeline:

原始文档 → 格式解析 → 文本清洗 → 文本分割 → 问题生成 → 答案生成 → 质量过滤 → 格式导出

1. 原始文档采集：确定领域范围，收集 PDF/Markdown/DOCX/TXT 等格式的文档。医疗领域如临床指南、医学文献、病历模板等。
2. 格式解析：将不同格式统一转为纯文本/Markdown。PDF 是最复杂的，可选方案包括PyMuPDF提取、MinerU解析、或使用视觉 LLM(GLM-OCR) 将 PDF 转为 Markdown。
3. 文本清洗：去除页眉页脚、乱码、参考文献格式噪声、重复段落等。
4. 文本分割（Chunking）：将长文档切分为适当大小的文本块，每个块作为后续问答对的"上下文"。
5. 问题生成：使用 LLM 对每个文本块生成多样化的问题，覆盖不同角度和难度层级。
6. 答案生成：基于文本块内容，让 LLM 生成准确的答案，并提取思维链（COT）。
7. 质量过滤：去重、规则检查、LLM 质量评分，过滤低质量 QA 对。
8. 格式导出：根据微调框架要求导出为Alpaca或ShareGPT格式。

Easy Dataset提供了以上流程的完整功能，需要注意的点：每个环节的质量都会传递给下一环节，前期文本分割效果不好，后续生成的问答对质量也会受到影响。

2. 文本分割方式及其使用场景

文本分割是整个 pipeline 的基础，直接决定后续微调数据集（问答对）的质量。

chunk_size 选择依据：

实践经验：中文文本一般设置 500-1000 字，英文 300-800 tokens。医疗领域建议偏小（500-800 字），因为医学知识密度高，单个知识点即可构成完整 QA。

overlap 选择：通常设为 chunk_size 的 10-20%。作用是保留边界上下文，避免关键信息恰好被切断。过大浪费 token，过小可能丢失边界信息。

分割方式对比：

3. 数据质量和多样化

如何让生成的微调数据集更多样化，Prompt的设计很关键，一般从以下几个角度入手：

• 约束条件

• 基于原文：“所有问题必须严格依据原文内容，不得添加外部信息”，防止幻觉和事实错误的核心约束
• 去元信息：“禁止输出与材料元信息相关的问题（如作者、章节）”，避免生成无价值的 QA
• 自然表述：“问题不得包含’报告/文章/文献中提到’等总结性陈述”，确保问题自然流畅和防止内容理解型错误
• 数量控制：按照 chunk 长度动态计算问题数量（如每 500 字生成 1 个问题），挖掘尽可能多的有价值问题

• MGA（Genre-Audience，体裁-受众）方法： 即使在同一垂直领域内，不同的角色、不同的任务也会导致同一主题的相关问题拥有不同的数据分布，通过同一垂直领域内的多个角色、多种任务可以从多个视角获取到该领域的多样化训练数据。

  核心思路：同一个文本块，针对不同的"体裁"和"受众"组合，可以生成完全不同风格和角度的问题。

  举例——假设有一段关于"二甲双胍治疗 2 型糖尿病"的医学文本：

  体裁	受众	生成的问题风格
  临床指南	医生	“二甲双胍的起始剂量和最大剂量分别是多少？”
  科普文章	患者	“吃二甲双胍为什么刚开始会觉得肠胃不舒服？”
  药品说明书	药师	“二甲双胍与碘造影剂同时使用的禁忌机制是什么？”
  学术论文	研究者	“二甲双胍激活 AMPK 通路的具体分子机制是什么？”

  工作流程：

  重点关注：

  (1) 识别问题的核心概念、事实与逻辑结构（问题的核心概念及其衍生问题，比如有哪些糖皮质激素药物，有什么主治功能，有哪些副作用）(2) 设计具有明确答案指向性的问题（多角度，比如临床医疗领域内医生角度、患者角度）(3) 控制问题难度与类型，保证多样性与代表性（是/否类（单选题）、满足哪些条件类（多选题）、哪些药物、症状、疾病史（填空题））

1. 对每个文本块，LLM 分析内容并生成 1-5 个 GA 配对（Genre-Audience pairs）

2. 问题生成时，将激活的 GA pair 注入 Prompt：

   体裁：临床指南受众：医生确保：问题风格、深度与指定体裁匹配；从该受众的视角和需求出发提问

• 多样性控制

• 在约束中明确要求"覆盖文本的不同主题、层级或视角，避免集中于单一片段"
• 使用MGA方法从不同视角生成多个问题
• 可以先要求 LLM 先生成问题类型分布（比如题型类别：单选题、多选题、填空题，或者是任务类型：事实型、推理型、比较型、应用型），再逐类生成具体的问题

• 类型扩展

  比如关注的是高血压这个问题，就需要围绕这个主题进行多类型的扩展，比如：

• 什么是高血压？
• 高血压的症状？
• 高血压的常用治疗药物？
• 患者是否患有高血压

• 输出格式控制

  要按照问题和答案的格式约束生成，以便于后处理环节能将所有生成的数据正确地处理为Alpaca和ShareGPT格式的数据集。

4. 数据清洗和过滤

数据清洗是确保数据集质量的关键环节，具体地可以分为分为基于规则的方法、基于统计的方法和基于模型的方法。

• 基于规则的方法

• 基于统计的方法：

• **MinHash + LSH**：大规模近似去重，适合百万级数据
• **Embedding 向量相似度**：计算 QA 对的语义相似度，过滤高度相似的冗余数据（SemHash）
• **N-gram 重复度**：检测答案中是否包含过多重复 n-gram

• 基于模型的方法

• 检查答案与问题的相关性
• 评分并过滤低质量 QA 对

5. 数据去重

数据去重是防止模型过拟合到重复样本、浪费训练算力的重要步骤。

• 字面重复去重：

• 精确匹配：完全相同的 instruction+input+output 直接删除
• 编辑距离（Levenshtein Distance）：两个文本的最少编辑次数，阈值通常设为文本长度的 5-10%
• Jaccard 相似度：n-gram 集合的交集/并集，适合检测部分重叠

• **语义重复去重：**字面不同但语义相同的 QA 对，如：

  两条问答字面不同，但问的是同一个问题。这类重复会让模型在训练时获得双倍梯度信号，相当于对这条知识过拟合。

• “二甲双胍的起始剂量是多少？”
• “刚开始吃二甲双胍应该吃多少毫克？”

• 去重方案：

  文本 → embedding 模型编码 → 向量相似度计算 → 相似度 > 阈值 → 保留质量更高的一条

  常用 embedding 模型：bge-large-zh、Qwen3-Embedding-8B等。

• tips：

• 先做字面去重（快），再做语义去重（准）
• 相似度阈值一般设 0.75-0.95，过高漏杀、过低误杀
• 数据量不大的时候，建议每一条都是用基于模型的方法判断是否去重
• 临床医疗领域需注意：看似相似但细节不同的 QA 不能去重（如"成人和儿童的二甲双胍剂量"受体不同，导致意义不同）

6. 数据集配比

数据配比直接影响微调后模型的能力分布。

• 领域配比（Domain Balancing）：

  如果目标是在保持通用能力的同时增强医疗能力：

  如果目标是纯医疗垂域模型：

• 按科室/疾病类型均匀采样，避免常见病样本过多而罕见病几乎没有

• 通用数据：70-80%（防止灾难性遗忘）

• 医疗领域数据：20-30%

• 难度配比（Difficulty Balancing）:

遵循"金字塔配比"——基础知识是底座，越高难度占比越少，确保模型先学会"记住"再学会"推理"。

3. 指令类型配比：

各类型取中间值时加总为 100%（如 55/12/13/13/7），按目标场景在区间内调整即可，不必都顶到上限。

7. Alpaca和ShareGPT格式

Alpaca 格式：

{ "instruction": "请解释二甲双胍的作用机制", "input": "", "output": "二甲双胍主要通过以下机制发挥作用：1. 抑制肝脏糖异生...", "system": "", "history": []}

• 单一三轮结构，适合单轮指令微调
• input 字段可存放额外上下文（可为空）
• system 字段存放系统提示词
• 兼容性最广，几乎所有微调框架都支持

ShareGPT 格式：

{ "conversations": [ {"from": "human", "value": "请解释二甲双胍的作用机制"}, {"from": "gpt", "value": "二甲双胍主要通过以下机制..."}, {"from": "human", "value": "那它有哪些副作用？"}, {"from": "gpt", "value": "常见副作用包括..."} ], "system": ""}

• 多轮对话原生支持，通过 messages 数组承载
• 更接近 ChatML 格式，适配 Chat 模型
• 适合多轮对话场景，可包含任意轮次的对话历史

选择建议：

8. 数据蒸馏

数据蒸馏（Data Distillation）是在没有现成文档的情况下，从零构建领域数据的方法。

核心流程：

输入主题 → LLM 生成标签树 → 逐标签生成问题 → 逐问题生成答案 → 质量过滤 → 数据集

Step 1：生成知识标签树

输入主题"2型糖尿病诊疗"，LLM 生成层级标签：

2型糖尿病诊疗├── 病因与发病机制│ ├── 胰岛素抵抗│ └── β细胞功能减退├── 诊断标准│ ├── 空腹血糖│ ├── OGTT试验│ └── HbA1c├── 药物治疗│ ├── 二甲双胍│ ├── 磺脲类│ └── SGLT-2抑制剂└── 并发症管理 ├── 糖尿病肾病 └── 糖尿病视网膜病变

Step 2：基于标签生成问题

对每个叶子标签，LLM 按照指定数量和类型生成问题：

• "二甲双胍"标签 → “二甲双胍的推荐起始剂量是多少？”“二甲双胍禁用于哪些患者？”

Step 3：基于问题生成答案

与正常流程相同，但此时没有参考文本——LLM 依靠自身知识回答。这意味着：

• 优点：可以快速生成大量数据
• 风险：LLM 的知识可能不准确、过时，需要更严格的质量校验

适用场景：

• 快速搭建领域数据集的初始版本
• 作为种子数据，后续用真实文档补充
• 知识覆盖面广但深度要求不高的场景

tips：蒸馏数据适合作为"骨架"，真实文档生成的 QA 作为"血肉"

有技术底子的人，正站在AI大模型开发的黄金入口

先问自己一个问题：

你写了这么多年代码，薪资是不是已经很久没动了？

面试的时候，“会Spring Boot”“会Vue”"会MySQL"已经变成了基本操作，没有人在乎了。大家都会的东西，就不值钱了。

但另一边，有人在疯狂涨薪
拉勾、BOSS直聘上，“AI应用开发”“大模型开发”"Agent开发"的岗位数量在过去一年翻了3倍，薪资中位数比同级别后端开发高出 40%-60%。

不是因为他们比你聪明，而是因为他们踩对了赛道。

你可能觉得：我又不是搞算法的，大模型跟我有什么关系？

这就是最大的误区。

AI大模型应用开发 ≠ 训练大模型
说清楚一点：训练大模型的是那几家大厂，但用大模型做应用的，是千千万万的普通企业和团队。

而这些团队需要的，不是PhD，而是——

能用大模型API搭出可用产品的应用开发者
能设计Agent工作流、调用工具链的Agent工程师
能把RAG、Function Calling、多轮对话落地到真实业务的AI全栈
这些活儿，有编程基础的你，完全能干。

你需要补的不是"算法基础"，而是"AI开发的技术栈和工程思维"。

Agent开发，为什么是程序员最好的切入点？
因为Agent开发本质上就是"用自然语言编程"——而这恰恰需要你已有的工程能力：

你有代码功底 → 理解Function Calling、工具调用、API集成，比零基础快10倍
你有系统设计经验 → 设计多Agent协作架构、状态管理、错误处理，逻辑一脉相承
你懂工程化 → 部署、监控、性能优化，这些AI项目同样需要
你理解数据 → RAG系统的数据清洗、向量检索、效果调优，你的DB经验直接复用
说白了，你已有的能力是资产，不是沉没成本。差的只是"AI这一层"的认知和工具链。

学完之后，你值多少钱？
转型 从传统后端/前端转AI应用开发，打开薪资天花板，跳槽议价权拉满
升职 在现有团队主导AI项目落地，从"写代码的"变成"定方向的"
独立 用Agent开发能力做SaaS产品、接AI外包项目，技术变现多一条腿
不可替代 当AI能写CRUD了，你是那个"用AI写代码"的人，而不是"被AI替代"的人
这不是危言耸听。GitHub Copilot已经能写出70%的CRUD代码了，纯执行层面的程序员价值在快速缩水。但"能用AI构建AI应用"的人，目前严重不够用。

这门课会教你什么？
面向有编程基础的开发者，从AI大模型应用开发的工程实践出发：

✅ 大模型API调用与Prompt工程实战
✅ RAG系统搭建：从数据处理到向量检索全流程
✅ Agent开发：Function Calling、工具链、多步推理
✅ 多Agent协作与工作流编排
✅ 真实项目落地：从需求到部署的完整工程链路
不讲虚的，全是能直接用在项目里的东西。

🚀 AI大模型应用开发课程

有编程基础？这就是你的下一个赛道

“程序员最大的风险，不是技术过时，而是用旧技术赚新钱的心态。”

你可能还在想"再等等看"——但AI这个赛道，窗口期就这么长。

等大模型开发变成"标配技能"的时候，你就不是先行者了，而是追赶者。

你有技术底子，这是你最大的优势。别浪费它。