1. 为什么通用模型总差最后一公里1.1 通才的天花板在哪里我最早对微调产生执念是因为一个做企业知识库的朋友。他拿通义千问跑内部文档问答提示词工程写了一整页RAG 也接上了但回答总带着一股教科书味——行业黑话不生、格式不齐、该给结论的地方绕圈子。后来我们换了路子把不到一千条业务问答整理成 SFT 数据用 LoRA 微调了一个周末效果立刻拉开差距。这件事给我的印象很深大模型本身是通才什么都懂一点但离专才之间隔着的正是微调这最后一公里。一个大模型在互联网规模的数据上预训练完它的强项是广度而非深度。它能写代码、能翻译、能聊天但如果你让它按你们公司的验收规范生成一份工程变更单它大概率会给你一份看起来很像、细节全不对的东西。原因很直接预训练阶段模型学到的是一般规律而行业内的私有术语、固定的输出格式、特定的判断口径这些长尾知识几乎不会在海量语料里以足够高的密度出现。这类问题有几个典型信号模型对行业缩写总是自己去猜十个里有三个猜错同一个任务你让它跑十次格式能给你变出五个花样明明是固定流程的活儿它非要自由发挥加一句不在范围内的话。这些都是通才能力边界的外在表现不是模型智商不够而是它压根没见过你们这一行的标准答案长什么样。1.2 解决问题的三张牌提示词、RAG 与微调遇到领域适配问题手上其实有三张牌可以打先别急着上微调。第一张是提示词工程。成本最低改改上下文马上生效适合约束输出结构、给一两个 few-shot 示例。但提示词的容量有限上下文窗口再大也没法靠几句话把一整套行业规则塞进模型脑子里。第二张是 RAG把外部知识在推理时检索出来拼进上下文。适合知识频繁更新、答案依赖具体文档的场景比如客服知识库、政策问答。但 RAG 解决不了语气不像、格式不对、行为不一致这类偏风格和习惯的问题因为模型的参数里没变它只是读到了不是学会了。第三张才是微调。微调直接改变模型权重让模型在某个方向上的行为成为本能。适合三类硬需求输出格式和风格必须绝对统一、领域术语必须零错误、某个任务模式高频重复且规则稳定。我常用一个类比来说明三者的分工提示词是给模型写临时工合同RAG 是给模型配资料员微调是把模型送去岗位培训班。方案改变什么成本最佳场景提示词工程输入上下文低快速约束、少量示例、临时任务RAG推理时检索上下文中知识频繁更新、大量私有文档微调模型权重高风格术语固定、输出结构统一、行为一致这里必须泼一盆冷水如果你的领域知识每天都在变微调不是首选RAG 才是。微调适合知识相对稳定、行为标准明确的活儿。把实时变化的内容硬做成训练数据只会让你陷入今天训完明天又要重训的循环。1.3 几种必须微调的信号结合我接手过的项目出现下面这些信号就该认真考虑微调了。第一同一个任务要重复跑成百上千次且每次输出必须符合固定规范。比如周报生成、缺陷单转写、工单摘要这类任务靠提示词也能跑但模型偶尔灵感来了就会破坏格式微调后基本能压到 100% 合规。第二领域词汇错误率降不下来。提示词里反复强调也没用因为模型底层对某类词就是没有正确的先验。第三需要模型具备某种稳定的人格或语气比如企业对外客服的亲和风格、内部审计的严肃措辞。第四RAG 检索质量已经很高但生成端仍然照着检索内容乱发挥那就是生成能力的问题该微调的是怎么用找到的材料。反过来如果只是偶尔问一次、数据只有几十条、任务形态千变万化那微调纯属浪费算力。做技术选型最重要的不是能微调就微调而是想清楚这个任务到底缺的是什么。2. 微调方案选型全参、LoRA 与 QLoRA 的真实差距2.1 全参数微调先算清显存这笔账很多人一上来就说我要微调但没想清楚用哪种方式。全参数微调是最原始也最贵的方式模型中所有参数全部参与更新。以 7B 模型为例光算静态开销就很吓人——bf16 权重占 14GB梯度占 14GBAdamW 优化器需要保存 FP32 的动量、方差和主权重又是 42GB 起步这还没算激活值。实际的工程经验是7B 全参微调单卡基本别想至少需要 4 张 80GB 的 A100 或者 2 张 H100 才能跑得舒服。全参微调的好处是上限高对数据利用最充分模型对任务的适配是全方位的。但它的劣势也非常现实成本高、周期长、灾难性遗忘风险大。一旦训练数据里有噪声整个底座都可能被带偏。我的判断标准很简单除非你有高质量的万级数据、企业级 GPU 集群、并且这个模型要长期固定服务一个核心业务否则别碰全参。大多数个人开发者和小团队LoRA 才是那个性价比之王。2.2 LoRA低秩适配器的工程智慧LoRA 的核心洞察很有意思大模型在微调时权重更新的有效秩其实非常低。既然要学的东西本质上是低维的那就不必更新整个大矩阵而是把更新量拆成两个小矩阵的乘积。假设输入维度是 dLoRA 用两个矩阵 Ad×r和 Br×d来近似权重的增量r 远小于 d。这样需要训练的参数从几亿骤降到几百万通常只占模型总参数的 0.1% 到 2%。用生活化的方式理解全参微调是把一本字典重新编一遍LoRA 是在字典页边贴满便签只改该改的地方字典正文原封不动。这个特性带来两个巨大的工程红利一是显存占用大幅下降7B 模型在 24GB 单卡上就能跑 LoRA二是适配器可以随时插拔同一个底座可以挂多套不同任务的 LoRA部署时切换 adapter 就行不必为每个任务保存一份全量模型。LoRA 里有三个参数值得记牢rank秩、alpha、target 模块。rank 决定适配器的容量一般 16 到 64 足够绝大多数任务并不是越大越好rank 过大会引入噪声还容易过拟合。alpha 是缩放系数经验法则设成 rank 的两倍左右比如 rank 64 配 alpha 128。target 模块选哪些线性层早期做法是挑 attention 的 q、k、v、o现在更省事的做法是直接 all让模型自己决定在哪注入知识。2.3 QLoRA4bit 量化把门槛压到消费级QLoRA 是在 LoRA 前面加了一步先把底座模型量化到 4bit 再挂 LoRA。量化后 7B 模型的底座只占 4GB 左右加上 LoRA 参数、优化器状态和激活值16GB 显存的消费卡也能勉强塞下。这意味着什么以前微调是大厂专属现在一张 4090、甚至 4060Ti 16GB 都能在家完成 7B 模型的微调实验。代价是训练速度变慢。4bit 底座在每次前向反向时都需要反量化计算吞吐量明显低于 bf16。质量上QLoRA 在多数任务上已经很接近 LoRA但如果你对输出风格的一致性要求苛刻bf16 LoRA 仍然会更稳一点。所以我的建议是显存 24GB 以上优先 bf16 LoRA显存只有 12GB 到 16GB 就踏踏实实用 QLoRA先把流程跑通质量后面再优化。方案训练参数量7B 最低显存参考训练速度适用硬件全参数微调100%100GB慢A100/H100 集群LoRA约 0.1%-2%24GB 可跑中等单张 4090 / A6000QLoRA约 0.1%-2%12-16GB 可跑中等偏慢消费级显卡2.4 从热门话题看大家真实的选型偏好我刷到大量与大模型微调相关的实践讨论发现三件事高度一致底座模型大家普遍选 7B 左右的国产开源模型比如 Qwen2.5-7B、DeepSeek 系列工具链基本都往 LLaMA-Factory 收敛很少有人再自己写 Trainer部署端则分两派生产环境用 vLLM边缘和本地场景用 Ollama 加载 GGUF。还有人在讨论用 AMD 的 RX 6750 GRE 这种消费级 A 卡训练大模型。说实话A 卡在 ROCm 下能跑 PyTorchLoRA 训练也没有原则性障碍但生态成熟度和速度都跟 NVIDIA 差距明显。如果你手头只有 A 卡建议把目标定在 QLoRA 加小 batch卡在 12GB 显存就老老实实选 3B 或 0.6B 级别的小模型。小模型微调并非没有价值那些跑在终端设备上的轻量任务本来就是小模型的天下。3. 数据准备微调质量的隐形天花板3.1 微调数据到底长什么样几乎每一个微调崩了的案例最后追根溯源都会发现数据先崩了。数据是微调的天花板同样的底座、同样的 LoRA 参数数据好的人三五个 epoch 就看见质变数据烂的人训到第十个 epoch 只会把模型越带越偏。SFT 微调数据的本质是指令-回答对。有两种主流组织方式Alpaca 格式用三个字段承载指令ShareGPT 格式则用 messages 数组表达多轮对话。前者简单直接适合单轮问答后者适合带上下文的客服、助手类场景。无论哪种格式最终在训练时都会被套进模型的 chat template。以 Qwen 系列为例模板是|im_start|user和|im_start|assistant这类特殊 token 包裹的数据准备阶段必须保证跟模型的 template 一致否则模型会在推理时把对话结构弄乱。{instruction: 请根据材料提炼关键信息。, input: ..., output: ...}{messages: [{role: user, content: ...}, {role: assistant, content: ...}]}在 LLaMA-Factory 里你需要把数据集注册进dataset_info.json把字段映射到它认识的prompt、query、response上{ industry_qa: { file_name: industry_qa.jsonl, columns: { prompt: instruction, query: input, response: output } } }3.2 数据量、多样性与配比的经验值关于数据量业内的经验区间很清晰。只想让模型改变语气或输出格式500 到 1000 条高质量数据就够想让模型掌握一门行业知识并稳定作答至少准备 2000 到 10000 条要改变更复杂的行为模式比如让模型学会一套完整的业务推理流程那需要更多并且每一条都要精雕细琢。但数量永远排在质量后面。我见过有人从网上抓了十万条问答直接喂进去结果模型不仅没变强反而学会了语料里的重复句式和错误常识。判断数据质量有一条捷径随机抽 50 条问自己如果我是一个新人看了这 50 条能不能学会这个岗位的核心工作如果答案是不能那数据量再大也只是在放大噪声。多样性比数量更重要。同样一千条数据如果来自一百份文档、覆盖二十种提问方式效果远超一千条都长一个模子的数据。我建议在构造数据时有意识地覆盖几种问法直接问、反着问、给场景问、要求对比问、要求按角色回答等等。很多新手只写问题-答案这种最朴素的形态导致模型训练完只会那种固定提问方式换种说法就懵。3.3 从 txt 文档到 JSON 数据集的脚本化流程经常有人问怎么把一堆 txt 资料做成微调用的 JSON 数据集。最省事的路线是用本地 Ollama 起一个教师模型让大模型帮忙生成问答对你负责抽检把关。下面这段脚本我一直在用逻辑很直白读目录下所有 txt按句子切成块逐块调用 Ollama 生成问答对最后写出 JSONL。import json import re import urllib.request from pathlib import Path def chunk_text(text: str, max_len: int 600) - list[str]: text re.sub(r\s, , text).strip() sentences re.split(r[。], text) chunks, buf [], for s in sentences: if not s.strip(): continue if len(buf) len(s) 1 max_len: chunks.append(buf.strip()) buf buf s 。 if buf.strip(): chunks.append(buf.strip()) return chunks def make_qa_with_ollama(chunk: str, model: str qwen2.5:7b, base_url: str http://localhost:11434) - dict: 调用本地 Ollama让教师模型生成一组问答对。 payload { model: model, messages: [ {role: system, content: 你是数据标注员。根据材料生成一组问答对只输出JSON包含question和answer字段。}, {role: user, content: chunk}, ], format: json, stream: False, } req urllib.request.Request( base_url /api/chat, datajson.dumps(payload, ensure_asciiFalse).encode(utf-8), headers{Content-Type: application/json}, ) with urllib.request.urlopen(req, timeout120) as resp: body json.loads(resp.read().decode(utf-8)) qa json.loads(body[message][content]) return {instruction: qa[question], input: , output: qa[answer]} def build_dataset(txt_dir: str, out_path: str): items [] for fp in sorted(Path(txt_dir).glob(*.txt)): text fp.read_text(encodingutf-8) for chunk in chunk_text(text): try: items.append(make_qa_with_ollama(chunk)) except Exception as e: print(f跳过一条{fp.name}{e}) with open(out_path, w, encodingutf-8) as f: for item in items: f.write(json.dumps(item, ensure_asciiFalse) \n) print(f生成 {len(items)} 条数据 - {out_path}) if __name__ __main__: build_dataset(docs, train.jsonl)用教师模型自动生成数据有一个坑必须提醒教师模型的噪声会被学生模型原封不动学走。所以自动生成之后一定要做一轮人工抽检和修正。我习惯把生成结果按完全可用、需要改、不可用三档抽样如果不可用比例超过两成就先不要进训练回去改 prompt 或者换更强的教师模型。另外宁可保留 500 条干净数据也不要为了凑数把疑似错误的样本硬塞进去。3.4 数据污染与投毒测试大模型投毒测试现在是个热门话题大家开始意识到训练数据本身可能是攻击面。有人会往公开数据集里混入精心构造的毒样本让模型在特定触发词出现时产生预设的恶意外输出这种攻击被称为后门攻击。放在你自己的微调项目里最现实的威胁是数据来源不可控。如果你从网上爬语料、从第三方买标注数据一定要做三件事。第一抽样人工审计重点看有没有隐藏指令、异常重复、莫名插入的长文本。第二做数据去重重复数据不仅浪费算力还会放大其中携带的噪声。第三留一份干净的、绝对不进入训练集的测试集训完专门用触发样本探测模型有没有被带偏。我见过一个案例某数据包里混入了几十条恶意注入样本模型微调后只要看到特定关键词就会输出错误答案要不是提前做了触发测试这个问题上线后几乎不可能被发现。4. 一次完整微调实操环境配置、训练监控、合并部署4.1 环境准备清单数据备好之后先把环境跑通。我的推荐配置是一张 24GB 显存的 RTX 4090 或 A6000 跑 bf16 LoRA16GB 显存就上 QLoRA系统盘预留 50GB模型目录预留 30GB 以上。推荐用 conda 建独立环境避免把系统 Python 搞乱。安装顺序是 Python 3.10、PyTorch、LLaMA-Factory然后下载底座模型。我现在的标准命令是这样的conda create -n finetune python3.10 -y conda activate finetune pip install torch --index-url https://download.pytorch.org/whl/cu121 git clone https://github.com/hiyouga/LLaMA-Factory.git cd LLaMA-Factory pip install -e .模型下载方面国内网络环境用 ModelScope 会比 HuggingFace 顺很多命令行直接拉pip install modelscope modelscope download --model Qwen/Qwen2.5-7B-Instruct --local_dir ./models/Qwen2.5-7B-Instruct这里有个容易忽略的细节下载完检查一下模型目录里的config.json和tokenizer文件是否齐全缺一不可。LLaMA-Factory 加载模型时会严格检查这些文件缺了会在启动报错而报错信息往往不够直观。4.2 训练参数每一行的意图数据放进data/目录并注册好dataset_info.json之后接着写训练配置。LLaMA-Factory 支持命令行参数也支持 YAML 配置我用 YAML 居多因为可复现性更好每一次实验留一份 YAML 文件比在终端敲一长串参数强多了。model_name_or_path: ./models/Qwen/Qwen2.5-7B-Instruct stage: sft finetuning_type: lora dataset: industry_qa template: qwen cutoff_len: 2048 learning_rate: 1.0e-4 num_train_epochs: 3.0 per_device_train_batch_size: 4 gradient_accumulation_steps: 8 lr_scheduler_type: cosine warmup_ratio: 0.1 bf16: true logging_steps: 10 save_steps: 500 lora_rank: 64 lora_alpha: 128 lora_target: all output_dir: outputs/qwen25_7b_industry_lora几个关键参数我说下背后的理由。cutoff_len控制单条样本的最大截断长度2048 对 7B 模型是个平衡点太短会截断长材料里的关键证据太长会显著增加显存和训练时间。learning_rate1e-4 是 LoRA 的常见起点往上升到 2e-4 就开始有崩的风险往下调到 2e-5 更稳但收敛慢。per_device_train_batch_size乘gradient_accumulation_steps才是真正的全局 batch size这里 4×832对 7B 模型是合理的。数据量大、样本难度高时建议适当把全局 batch 提到 64效果会更稳。4.3 训练日志怎么看什么才算训好了训练开始后最需要盯的是 loss 曲线。一个正常的 LoRA 训练loss 会从 1.x 快速降到 0.3 到 0.5 附近然后缓慢趋稳。如果你的 loss 卡在 0.8 下不去大概率不是训练轮数不够而是数据本身难度高或者有噪声盲目加 epoch 只会过拟合。llamafactory-cli train config.yaml日志里每 10 步会打印一次重点关注两个指标loss 的下降趋势和 learning_rate 的调度曲线。loss 偶尔抖动很正常但出现 NaN 就必须立即停。训练中途我强烈建议做一件事每保存一个 checkpoint就用它生成五条固定 prompt 的冒烟测试。固定 prompt 要设计成最能暴露任务质量的比如格式要求最严格的那一种。很多新手只看 loss最后训完一测loss 是下来了模型却开始满嘴胡话——因为 loss 下降只能说明模型在拟合训练集而你在意的输出格式和业务逻辑必须实际生成才看得到。4.4 LoRA 合并、转 GGUF 与 Ollama 部署训练完成后LoRA 适配器还不能直接服务于常规推理框架需要先合并回底座模型。合并这一步会把底座权重和适配器做一次真正的融合之后就能像普通模型一样被 vLLM、llama.cpp 加载。llamafactory-cli export \ --model_name_or_path ./models/Qwen/Qwen2.5-7B-Instruct \ --adapter_name_or_path outputs/qwen25_7b_industry_lora \ --template qwen \ --finetuning_type lora \ --export_dir ./models/qwen25_7b_industry_merged \ --export_size 4合并完的模型如果只想做本地私有化部署最省事的路径是转成 GGUF 再交给 Ollama。转换用 llama.cpp 的脚本git clone https://github.com/ggerganov/llama.cpp python llama.cpp/convert_hf_to_gguf.py ./models/qwen25_7b_industry_merged \ --outfile qwen-industry.gguf --outtype q8_0然后写一个简单的 ModelfileFROM ./qwen-industry.gguf接着执行ollama create qwen-industry -f Modelfile再ollama run qwen-industry就能本地对话了。这条路线尤其适合Android App 集成大模型 GGUF这类端侧需求模型文件拷到手机上用 Ollama 的移动端能力就能跑起来。如果想走生产级 API 服务vLLM 是更主流的选择一行命令启动兼容 OpenAI 协议的接口pip install vllm vllm serve ./models/qwen25_7b_industry_merged --port 80004.5 效果验证别靠感觉靠测试集我每次微调结束都会做一套固定的验收流程。从业务数据里单独留出 30 到 50 条打死不进入训练集的测试样本人工逐条标注理想答案然后拿微调前后的模型分别跑一遍从四个维度打分关键要素准确率、格式合规率、语气一致性、幻觉率即答案里有没有测试材料里不存在的信息。这套验收流程看起来笨但效果极其明显。有一次测试显示格式合规率从 62% 提升到了 98%而幻觉率只降了一点这让我意识到问题不在生成能力而在 RAG 的检索环节于是把重心转去优化检索。如果没有这套量化对比我很可能对着模型试半天也找不到真正该改的环节。5. 训崩了不丢人微调故障排查的完整链路5.1 崩溃的几种典型面目目标检测模型微调崩了这类话题常被刷到其实不只是视觉模型NLP 微调同样会崩只是症状不同。见得最多的有四种训练 loss 飞成 NaN模型开始无限重复比如输出一整页好的好的好的通用能力严重退化微调之后连基础问答都做不好输出格式全面崩溃所有答案都变成一个固定模板。这些症状的根因排序按我踩坑的积累大概率是数据偏置大于学习率过大大于轮数过多大于 rank 设置不当。很多人第一反应是调学习率但我建议先检查数据。5.2 一次完整的排查过程从症状到根因我接手过一个真实案例某团队微调模型做结构化报告摘要训练三四个 epoch 后loss 很漂亮但模型对任何输入都会先输出一句根据上述分析——哪怕输入是一段压根不需要分析的代码。团队当时觉得是模型问题准备换底座重训。我让他们做的第一件事是把训练数据按输出首句聚个类。一查就笑了两千条数据里有一千八百条标注答案的开头都是根据上述分析。这根本不是模型崩了而是数据集体携带了同一种模板模型只是在忠实地学习这个规律。修正方式很简单从数据里去掉这个前缀或者改成多样化的开头短语然后降低学习率和 epoch 数重训症状立刻消失。这个案例说明排查微调崩了不能靠猜要按固定链路走先看数据分布和模板化程度再看学习率是不是过高或过低然后看 epoch 数是不是太多最后才考虑模型结构和 rank。每走一步都做单变量对照实验只改一个变量别同时动三处。5.3 灾难性遗忘模型变专了其他全忘了灾难性遗忘是微调最隐蔽的问题。模型确实把业务任务学好了但你拿一个通用数学题去问它它开始胡言乱语。本质原因是微调过程中模型对某些通用能力的记忆被新任务覆盖了。有三条对策按性价比排序。第一条坚持用 LoRA 而不是全参微调底座的通用能力本来就不可动变的只是适配器遗忘风险天然小很多。第二条在训练数据里混入一定比例的通用语料我习惯按 8:2 或 9:1 的领域数据与通用指令数据比例混合相当于给模型做岗位培训时不忘复习基础知识。第三条降低学习率、缩短 epoch、早停少学几轮有时远比多学几轮效果好。5.4 微调崩了之后最有效的复活姿势如果模型已经崩了不要急着从头再来。LoRA 的最大红利是你随时可以拔掉适配器底座模型还是原封不动。我的复活流程是固定的先滚回到最后一个还正常的 checkpoint然后把学习率降到原来的十分之一再砍掉一半 epoch 数同时去检查训练数据里最可疑的那一批。如果四步做完仍然崩才考虑换数据或调 rank。这套流程救回来过好几个项目核心思路其实就一句话故障发生时先用最保守的配置把流程跑通再逐步放开参数逼近最优解。一上来就追求第二天上线的心态反而是崩掉的原因。6. 进阶方向多模态微调、知识抽取与组合拳实战6.1 多模态视觉层微调以驾驶员要素提取为例有不少人在尝试多模态大模型的微调比如做视觉层微调用于驾驶员要素提取这类任务。背景很典型通用视觉语言模型看得懂图片但不够懂行比如看不出方向盘上的手势是不是疲劳驾驶的征兆。解决思路是对视觉编码器或视觉语言对齐层做 LoRA 微调让模型把注意力集中在驾驶场景的关键区域。在多模态微调里一个常见的工程选择是冻结视觉编码器只微调语言部分。原因很实际视觉编码器已经在海量图文对上学会了通用视觉特征微调它容易破坏这些特征而驾驶行为的判断逻辑主要发生在语言和推理层。数据集的组织和单模态略有不同训练样本通常是图片 URL 或本地路径 文本指令 期望输出比如输入行车记录仪截图输出驾驶状态疲劳置信度0.92。这类微调的坑集中在标注一致性上同一个画面不同人标注差异很大建议标注完先做一轮去重和统计再进训练。6.2 提示词、RAG 与微调的组合拳把三种技术组合起来通常能得到远比单独微调更稳的系统。我的推荐架构很明确底座负责通用能力微调负责固定风格和业务行为RAG 负责实时知识提示词负责临时约束和输出格式兜底。举个例子一个企业客服机器人微调层让模型学会企业规定的回应结构和礼貌语气RAG 层挂最新的产品手册和活动规则保证信息不过时提示词层写清楚遇到投诉必须先致歉再给出解决方案这类动态策略。三层各司其职任何一个坏了都能单独替换而不是把所有期望压在一次微调上。6.3 用知识抽取框架加速数据集构建微调数据集的构建是可以被工具加速的。开源社区有 OneKE 这类专注知识抽取的模型和框架能从非结构化文档里抽出实体、属性和关系输出结构化的知识三元组。这些三元组再往后加工就能变成高质量问答数据的原料。一般的工作流是文档清洗之后先用知识抽取框架抽出关键实体和关系再基于这些结构化信息生成问答对最后做人审核。比起直接拿原始文档让大模型生成 QA这多了一道结构化中间层能显著减少问答对里的幻觉和事实漂移。我用这个方法把原来一个耗时两周的数据集构建任务压缩到三天而且数据质量更干净。6.4 这几条经验是踩过坑以后才信的最后分享几条用真金白银换来的经验。第一微调项目一定要做实验记录把每次训练的 YAML 配置、数据版本、随机种子、loss 曲线截图存到一个实验日志文件里。没有记录你调了三版之后根本不知道哪版用了什么参数一切回到原点。第二正式跑全量之前先拿 200 条数据、1 个 epoch 做冒烟实验确认数据格式、模型加载、训练链路都没问题再上全量。这个习惯能省掉无数个训练到第五个小时才报错的夜晚。第三永远留一份不进入训练集的评估集微调是一门工程不是玄学好坏要用数据说话。我现在做微调项目的固定流程已经变成习惯先问业务场景缺的是知识还是行为再选 LoRA 还是 QLoRA然后用脚本把数据变成 JSONL跑冒烟实验出第一版结果量化对比后再决定要不要调数据。这条路走通之后你会发现大模型从通才到专才的距离其实没有想象中那么远。