简介面向中文大模型落地行业场景的实用资源包专为AI算法工程师、数据科学家及企业技术决策者设计聚焦解决通用大模型向公司级/行业级大模型转化中的数据与训练方案问题。压缩包共8个文件包含3个jsonl微调数据集、3个json配置与标注文件、2个md说明文档整体大小3.44MB结构精炼便于快速查阅。内容覆盖中文指令微调、安全无害性提示词、开发者指令等典型数据可对接主流微调框架用于有监督微调、安全对齐、模型效果验证等关键环节为实际项目提供可直接参考的数据样例与处理思路。资源包能有效降低数据准备门槛帮助构建合规可用的行业训练集。目前已有208人学习特别适合需要搭建中文行业大模型、完善微调数据体系并落地生产环境的中高级从业者。1. 中文行业大模型落地的第一步先看数据再看模型一个反直觉的事实我在帮企业做行业大模型落地时真正卡住团队两三周的往往不是基座模型选型而是训练数据长什么样。这份《AI大模型应用》压缩包解压后最有价值的不是某个现成模型权重而是 instruction_data 目录下的六类中文指令数据——alpaca-zh 的两个分片、5K 条客服场景 SFT 数据、1K 条中文无危害性数据、12K1K 条安全提示集以及 developer_instruction.json。它解决的是微调前最缺原料的问题不用从零去爬语料、标指令直接把这批数据当成通用底料混入你自己的行业问答再做二次微调就能把通用大模型往公司级、行业级方向拉。适合正在做垂直行业模型的算法工程师也适合手里有真实业务场景、但没有高质量中文指令数据的技术负责人。2. 拆解指令数据包六个文件、两种格式、一套命名逻辑解压这个压缩包之后建议你先把“找训练脚本”的念头放一放包里没有完整的 train.py也没有部署配置文件核心资产就是 instruction_data 目录下的数据文件和 README。我先把文件清单列出来你对着看就知道每个文件能做什么。文件名格式内容定位落地用途alpaca-zh-data-part-00.jsonJSON 数组中文 Alpaca 指令数据上分片通用指令跟随底料alpaca-zh-data-part-01.jsonJSON 数组中文 Alpaca 指令数据下分片通用指令跟随底料cn-CS-APAT-sftdata-5K.jsonlJSONL 每行一条客服/业务场景 5K 条 SFT 数据垂直行业微调主力cn-Chinese-harmlessness-1K.jsonlJSONL 每行一条中文无危害性样本 1K 条安全对齐训练cn-Safety-Prompts-gpt12k_baichuan1K.jsonlJSONL 每行一条安全提示测试集 12K1K 条评测与红队测试developer_instruction.jsonJSON 数组开发者指令集代码、SQL 等开发场景微调2.1 JSON 和 JSONL两种格式决定了两种解析方式这个包故意把文件分成两种格式不是随手为之。JSON 是一个大数组整体存在一个文件里json.load 一次把所有样本读进内存JSONL 是每行一个完整 JSON 对象逐行读、逐行解析内存占用只取决于单行大小。工程上我更推荐把大文件转成 JSONL 再进训练流水线因为可以按行抽样、断点续读、出错时好定位到具体行。alpaca-zh 拆成 part-00 和 part-01 两个 JSON 分片大概率就是为了避免单文件过大导致编辑器或 Git 工具卡顿而安全类和客服类数据用 JSONL说明设计者在写这批数据时已经考虑了“逐行读取”的落地场景。2.2 alpaca-zh 两个分片怎么读alpaca-zh 是经典 Alpaca 指令数据的中文版本拆成两个分片后训练时可以当作同一份语料直接拼接。拿到文件第一件事是读第一条样本确认字段名不要凭经验猜。import json with open(alpaca-zh-data-part-00.json, encodingutf-8) as f: data json.load(f) print(总条数:, len(data)) print(json.dumps(data[0], ensure_asciiFalse, indent2))逻辑说明encodingutf-8 是必须的Windows 上 Python 默认用 GBK 解码文本文件不声明会直接报 UnicodeDecodeErrorjson.dumps 的 ensure_asciiFalse 让中文原样打印方便你直接看内容。Alpaca 风格数据常见字段是 instruction、input、output 三个input 可以为空字符串output 是标准回答。如果你看到的字段名是 prompt/response 或者 question/answer后面做字段映射时要改 key 名这一步别省。判断分片是否完整我一般打印 len(data) 后和文件大小做个交叉验证一个 100MB 的 JSON 文件解析出几千条是合理的如果只有几十条大概率是解压时文件损坏或编码转换出了问题。下面两个分片实际读出来如果是几万条的中文指令对说明数据量足够撑起通用能力微调。2.3 安全类数据训练数据和评测数据要分开用cn-Chinese-harmlessness-1K 和 cn-Safety-Prompts-gpt12k_baichuan1K 这两份容易混我把它们的用途拆开讲harmlessness 是“教模型拒答”的训练样本适合在 SFT 或对齐阶段小比例混入safety-prompts 是“测模型防线”的提示集适合当评测集或红队测试集。以 gpt12k_baichuan1K 命名来看里面大约有 12K 条由 GPT 生成的安全测试提示另加 1K 条和 Baichuan 生态相关的中文提示。行业落地时客服机器人、金融问答这类场景如果只追求“有问必答”很容易在恶意诱导下输出不合规内容这份数据就是用来测防线的。读取 JSONL 用这种流式写法import json path cn-Safety-Prompts-gpt12k_baichuan1K.jsonl count 0 with open(path, encodingutf-8) as f: for line in f: line line.strip() if not line: continue obj json.loads(line) count 1 print(总行数:, count)逻辑说明JSONL 文件整体不是合法 JSON不能直接 json.load必须逐行 strip 再解析line.strip() 去掉行尾换行符和可能的空白避免解析报错。if not line 跳过空行这是 JSONL 解析最常见的防御写法空行在文件末尾尤其容易混进来。读取后你会看到字段可能是 prompt/response也可能是 instruction/output先打印 keys 再写后续脚本。关于安全数据还有一个容易被忽略的点safety-prompts 里的提示本身是“问句”不是“标准答案”。如果把它们当训练集混入 SFT模型会把提示抄成回答等于教模型“遇到问题就防御式复述”这是后文避坑章节第 5.5 条会展开的重灾区。2.4 cn-CS-APAT-sftdata-5K 是垂直场景的重点文件名里的 CS 我按 Customer Service 客户服务来理解APAT 的全称包里没有写明按“业务助理/客服辅助”的定位去用不会错。这 5K 条是带业务色彩的指令对做垂直行业微调时价值最高。我一般会把它当成“行业锚点”先抽 20 条看业务术语和语气再决定要不要也加入你自己的实际客服对话记录。如果这份数据来自真实客服场景它的口吻和你业务的差距就是需要“补充覆盖”的方向。比如数据里如果写“亲这边为您查询”而你公司的客服标准是“您好为您核实”那就要在训练语料里加入自己口径的对话样本让模型输出收敛到你的业务语气。这里建议做一个覆盖度检查把 cn-CS-APAT-sftdata-5K 里的业务名词抽出来做成词表和你真实业务的高频词比对缺失率超过 40% 的时候光靠这份数据撑不起行业模型必须补你的业务语料。2.5 README 的价值先读说明少猜三天包里有个 README.md很多人在解压后直接忽略它。我吃过这个亏有一回我按常见字段名写清洗脚本跑了半小时报错最后发现 README 里明确写了字段定义和 Alpaca 原版不一样。正确姿势是解压后先打开 README把里面提到的字段确认、格式说明和注意事项摘出来再对照本章表格判断哪些文件进训练集、哪些进评测集。README 不算代码但它是这份资源里门槛最低、回报最高的部分建议花十分钟读完再动手。3. 把原始数据清洗成 SFT 训练格式字段映射、模板与去重解压出来的数据不能直接丢给训练框架因为 LLaMA-Factory、SWIFT、transformers 的 SFT 脚本对数据格式要求各不相同。这一章给出统一的清洗流程字段映射 → 模板化 → 清洗 → 去重 → 登记。每一步都卡住过实际项目我按顺序讲。3.1 字段映射先打印三条样本再写转换脚本我见过太多人直接复用上一个项目的字段名结果把 output 当成 instruction 拼进模板训出来的模型答非所问。正确姿势是先看三条原样样本。import json def brief(item): return {k: (v[:30] ... if isinstance(v, str) and len(v) 30 else v) for k, v in item.items()} with open(developer_instruction.json, encodingutf-8) as f: data json.load(f) print(json.dumps([brief(x) for x in data[:3]], ensure_asciiFalse, indent2))逻辑说明brief 函数把长字符串截断到 30 个字符避免终端被整条长文本刷屏打印前 3 条的结构就能确定字段名。中文指令数据常见的字段组合有 instruction/input/output、prompt/response、query/answer 三种这份包里不同文件的字段名不完全一致用脚本逐文件确认最稳妥。判断字段映射是否正确的标准只有一个转换后的样本把 user 连起来读能不能形成一句完整的人话。如果出现“输入无”或者“回答”这种半截内容说明 key 名映射错了。这个检查通常比看代码更快人也更容易理解。3.2 统一到 ChatML 对话模板现在主流微调框架都接受多轮对话格式我习惯统一成 ChatML 风格user 是拼接后的指令assistant 是期望回答一段样本就是一轮对话。input 为空时不要拼多余换行否则模型会学到“指令后总跟着空行”的错误模式。def to_chatml(item, instruction_keyinstruction, input_keyinput, output_keyoutput): instruction item.get(instruction_key, ).strip() input_text item.get(input_key, ).strip() output item.get(output_key, ).strip() if input_text: user f{instruction}\n\n{input_text} else: user instruction assert user and output, f空字段: {item} return {messages: [ {role: user, content: user}, {role: assistant, content: output}, ]}逻辑说明instruction 和 input 之间用空行隔开是为了让模型区分“指令主体”和“输入材料”这是 Alpaca 原版格式的做法。assert 会在某条样本缺字段时直接抛异常把脏数据暴露在清洗阶段而不是进了训练才崩溃。参数说明如果你的框架要 ShareGPT 格式把 messages 改成 conversations并把它内部的 role/content 改成 from/value内容字段不变。还有一个细节output 字段里如果包含换行或代码块不要在这一步做 strip只清理首尾的空格保持正文结构。代码样本的缩进是语义的一部分丢了缩进模型生成的代码就是乱的。3.3 清洗规则长度、空置与乱码清洗阶段只做三件事删掉 output 为空或过短的样本、删掉 instruction 为空的行、处理文件中混入的不可见字符。output 小于 8 个字符的多半是占位符或坏数据留下来只会教模型“敷衍回答”。MIN_OUTPUT_LEN 8 def clean(items): cleaned [] for it in items: output it.get(output, ) if not output or len(output.strip()) MIN_OUTPUT_LEN: continue it[output] output.strip() it[instruction] it.get(instruction, ).strip() cleaned.append(it) return cleaned逻辑说明continue 跳过的是“空回答”和“过短回答”两类坏样本strip 去掉首尾空白避免输出里残留 \t 和全角空格。如果输出里出现 \u3000也就是全角空格以及 \x00 空字符建议用正则替换掉因为这类字符在 tokenizer 里会被当作未知 token直接拉低生成质量。清洗之后做一个条数对比清洗前多少条、清洗后多少条中间少掉的部分人工抽查 20 条确认删掉的确实是坏数据。这个步骤看似笨实际上能帮你发现数据里潜藏的系统性问题比如某一段的 output 全是同一个占位符。3.4 内容级去重不要只看文件名不同分片之间可能存在重复样本比如 alpaca-zh 两个分片在数据生成时发生重叠。去重按内容哈希做不按文件名做。两个分片里可能有几十条完全相同的样本直接拼接会让这部分数据在训练时被重复计算变相改变了配比。import hashlib def data_hash(item): raw json.dumps(item, ensure_asciiFalse, sort_keysTrue) return hashlib.md5(raw.encode(utf-8)).hexdigest() def dedup(items): seen, result set(), [] for it in items: h data_hash(it) if h not in seen: seen.add(h) result.append(it) return result逻辑说明sort_keysTrue 让字段顺序不影响哈希结果同一语义的样本不管字段先后都算同一条用 md5 只做去重索引不涉及安全场景没问题。去重后打印前后条数对比如果重复率超过 5%说明原始数据有大量重叠值得再检查一遍源文件的生成方式。重复率过高时即使清洗脚本没错训练出来的模型也会对重复高频样本产生偏好。3.5 把清洗后的数据登记到训练框架清洗完成之后数据要进训练框架还要过一道“登记”关。以 LLaMA-Factory 为例它通过 data/dataset_info.json 来识别数据集格式大致是数据集名、文件路径、模板类型、列名映射。登记时最容易踩的坑是模板类型写错你前面用 ChatML 格式清洗这里就要写 chatml两边不一致训练时模型会在错误位置生成 EOS 标记。我一般会在登记后做一次加载自检调框架的加载函数读一遍数据打印 batch 里第一条样本的 input_ids 长度和文本内容确认标签和输入对得上。这个自检只要花两分钟能省掉训练跑到一半才发现数据格式错误的返工成本。4. 用数据包跑通最小微调闭环基座选型、混合配比与训练参数清洗完的数据要真正训出一个行业模型还需要选基座、定配比、调参数。这一章给最小闭环的完整链路。4.1 基座选型先确认 tokenizer 认识中文判断一个基座模型适不适合做中文行业模型先看三处词表对中文的分词粒度是否合理、是否覆盖你行业的专业词、上下文长度够不够你的业务长文。包里安全提示文件带 baichuan 字样说明数据来源围绕 Baichuan 生态但你不必局限于这一家。我一般优先试 Qwen 系列和 Baichuan 系列它们在中文指令数据上的表现比英文原版模型稳定得多。选型时还要看显存预算7B 参数做 LoRA 微调大约需要 16GB 以上显存13B 起步 24GB如果只有单卡 8GB就走 QLoRA 加 4bit 量化。分词粒度这一项可以直接测把“请统计一下最近七天的退款率”喂给 tokenizer看它切出来的中文字是否完整成词如果同一个业务词被切得七零八落说明这个基座的中文词表不够好换一个再测。4.2 混合配比四类数据怎么凑成一份训练集训练目标数据来源份数建议通用指令跟随alpaca-zh 两个分片6垂直业务理解cn-CS-APAT-sftdata-5K2安全拒答cn-Chinese-harmlessness-1K1开发与代码developer_instruction1配比是经验值不是定论。行业业务数据占总量的 20% 到 30% 是我常用区间占比太低模型学不到业务占比超过 40%通用能力会被洗掉出现“学新忘旧”。alpaca-zh 是基本盘保证模型还记得怎么好好说话harmlessness 控制在 5% 以内否则模型会变得过度谨慎什么都不敢答。实际操作时我建议先把四类数据各自清洗后的条数统计出来再按比例计算每类应该保留多少条。比如 alpaca-zh 有 40000 条、CS 有 5000 条想要 6:2 的配比就把 alpaca 抽 30000 条、CS 全量 5000 条再把安全数据限制在总样本的 5% 以内。抽样用 random 固定 seed保证每次训练前 shuffle 出来的组合可复现。4.3 训练参数与启动命令用 LLaMA-Factory 训练是最省事的方式因为它自带数据注册和模板对齐。数据登记完成后执行llamafactory-cli train \ --model_name_or_path Qwen/Qwen2.5-7B \ --dataset alpaca_zh,cs_apat_5k,harmlessness,developer \ --template chatml \ --stage sft \ --cutoff_len 2048 \ --learning_rate 5e-5 \ --num_train_epochs 3 \ --per_device_train_batch_size 4 \ --gradient_accumulation_steps 8 \ --lora_rank 32 \ --output_dir ./industry_model参数说明--template chatml 必须和你在第 3 章清洗时用的模板一致模板不匹配会出现 EOS 位置错乱模型生成到一半就断句--cutoff_len 2048 表示超过 2048 token 的样本会被截断如果你的业务问答经常超过 3000 字要调大到 4096--learning_rate 5e-5 是 LoRA 微调的常用起点全参微调改用 1e-5 到 2e-5--gradient_accumulation_steps 8 意味着实际 batch size 等于 4×832在显存不够时用来保证等效批次足够大训练更稳定。实际 batch size 越大loss 曲线越平滑但显存占用也线性上升需要根据卡的类型做取舍。训练时我习惯用 bfloat16 混合精度如果显卡不支持 bf16退回 fp16 并把 loss_scale 设为 dynamic。这里有个常见误区fp16 下 loss 尾部出现 NaN不一定是数据问题多半是精度溢出换 bf16 或者调低学习率就能解决。4.4 LoRA 配置与显存压缩LoRA 的 rank 决定微调时引入的可训练参数规模。rank 32 是平衡点rank 64 适合业务数据量特别大的情况rank 8 适合快速验证。QLoRA 则在加载模型时加 4bit 量化显存占用可以压到原来的三分之一左右代价是训练速度略慢。如果你的显存实在不够两个手段一起用QLoRA 替 LoRAcutoff_len 从 2048 降到 1024per_device_train_batch_size 降到 2再把 gradient_accumulation_steps 提高到 16。等效 batch 保持 32 不变训练稳定性不会受太大影响只是单条样本变短长文本业务效果需要另外验证。4.5 训练后的权重合并与导出LoRA 训练结束后适配器权重和基座权重是分离的部署前要合并。LLaMA-Factory 提供 export 命令合并时把 max_shard_size 设小一点方便后续拷贝和多卡加载。合并完成后加载一次做冒烟测试问一条训练集里出现过的业务问题确认模型真的记住了一部分行业表述如果回答和基座模型几乎一样说明训练环节有问题要回看 loss 曲线和配比表。这一步容易被跳过但它直接决定你能不能进入验证阶段。权重合并后测试和训练前测试用同一批问题对比输出差异才能判断微调到底有没有生效。5. 避坑与排查指令数据微调现场反复出现的六个事故5.1 现象loss 降得飞快问业务问题却答非所问原因行业数据占比太低。alpaca 通用数据太多模型把通用对话模式学得太熟垂直业务信号被稀释。解决把 cn-CS-APAT-sftdata-5K 的占比从 2 份提到 3 份并把业务样本做同义改写增强让行业问答在训练语料里出现频率更高。我一般会先算一下业务样本占总 token 数的比例低于 15% 就继续加权。改写时不要只替换主语要把整个句式和客服场景对齐不然模型学到的还是通用表达。5.2 现象数据明明只有 5 万条json.load 直接把服务器内存吃光原因alpaca-zh 分片是 JSON 数组json.load 一次性读进内存字段多、中文长文本多时5 万条可能吃掉十几 GB。解决把 JSON 转成 JSONL逐行读取。转换时用 json.dump 逐条写出每条后面加换行转完对比内存占用通常能降一个量级。转换后的 JSONL 还能享受按行抽样的好处后续调配比不用再全量加载。5.3 现象训练完中文对话正常代码场景里输出乱成一段原因developer_instruction.json 里的代码样本包含换行和缩进清洗时被 strip 或拼接模板时丢掉了缩进模型学到的是“无缩进代码”。解决代码类样本单独走一条清洗链路模板里的 content 要保留原始换行和缩进拼接模板时不要对 content 做 strip只清理行尾的 \r。代码类数据建议和通用数据分开配比文件方便单独调节比例。验证时用第 6 章的 round-trip 方法让模型复述一段生成过的代码看缩进是否完整。5.4 现象Windows 解压 zip 后打开 json 报 UnicodeDecodeError原因zip 解压后的文本文件可能被系统工具改写换行符为 \r\n或文件本身带 BOMPython 默认 utf-8 读取时碰到 \r 和 BOM 头直接报错。解决读取时统一用 encodingutf-8-sig它能自动跳过 BOM读 JSONL 时在 strip 之外再加一条 line.replace(\r\n, \n) 处理换行。实在不确定编码就先用 chardet 检测不要靠猜。这个问题在 Windows 环境下做数据工程时几乎必现提前把读取函数统一封装好能省很多事。5.5 现象微调后模型“太怂”什么都不敢答原因把 cn-Safety-Prompts-gpt12k_baichuan1K 当训练集混进去了。那份数据本质是测试提示没有标准答案把它当训练目标模型会学会遇到问题就防御式拒答行业场景没人要这种机器人。解决safety-prompts 只做评测集训练只用 cn-Chinese-harmlessness-1K配比控制在 5% 以内。评测时把 safety-prompts 里每条 prompt 喂给模型检查该回答的业务问题有没有被误拒。如果误拒率超过 20%回去把 harmlessness 的配比再调低或者直接用 alpaca-zh 分片重新平衡。5.6 现象一启动训练就 CUDA out of memory但显存明明没被占满原因多半是机器上有其他进程占了显存。跑训练前没看 nvidia-smi别人的 eval 任务或者上一次残留的训练进程还挂在卡上新任务一上来就撞车。解决启动前先看 nvidia-smi确认目标 GPU 的显存占用为 0在训练命令里显式指定 CUDA_VISIBLE_DEVICES0避免框架自动选到被占用的卡。训练中断后再次启动前先 ps 查一下有没有残留的 python 进程有就 kill 掉再跑。这算是环境问题里最常见的一种和 torch 版本无关。6. 训练后的验证闭环用 round-trip 和侧评集把效果钉死训练完先别急着上线我习惯跑一个三层验证第一层用 5 条盲测业务问题看第一反应第二层把 safety-prompts 当红队提示集看模型有没有误拒第三层做 round-trip 复述一致性。round-trip 的做法是把模型对某条业务问题的回答反过来再问一遍“请用另一种说法复述你刚才的回答意思不变。”如果复述内容和原回答语义漂移明显说明模型只是记得住片段没有真正理解业务逻辑。判断语义一致性可以用 embedding 计算余弦相似度也可以用最简单的人工目测——5 条盲测任何一条漂移超过阈值都要回到配比重训。questions [ 客户说发货晚了一个星期要求全额退款客服怎么回, 写一条 SQL统计近 7 天下单量前 10 的商品及数量。, ] for q in questions: answer tuned_model.chat(q) restated tuned_model.chat(f请换一种说法复述{answer}) print(原答:, answer) print(复述:, restated)逻辑说明questions 里我刻意混了业务客服和开发者指令两种场景对应数据包里的 cn-CS-APAT 和 developer_instruction如果业务场景答得不错但代码场景复述崩掉说明 developer 数据配比不足回到第 4 章的占比表调数字。tuned_model.chat 是占位调用实际项目里替换成你的推理封装。最后一步是把 base 模型和微调模型对同一批问题做逐条对比用 base 模型跑一遍 5 条盲测再把微调模型的回答贴出来人工给每条打“好/平/差”。这里不用搞复杂的自动评测行业落地最怕的其实是“看起来能聊一问正事就露馅”。我通常给项目组定的标准是盲测 5 条至少 4 条明显优于 base且没有出现拒答率和复述漂移的双双上升才算这个数据包真正被用上了。从那以后我每次做行业模型微调都强制自己先走一遍全套流程字段 inspect、模板统一、配比登记、5 条盲测、round-trip 复述。这套动作看起来慢实际能省掉后面“上线后发现模型乱说话”的大片返工时间。希望帮到你。本文还有配套的精品资源点击获取