大语言模型微调实战：从领域适配到生产部署

1. 项目概述：当大模型不再“通用”，而是真正听懂你的业务语言

你有没有遇到过这样的场景：花大价钱部署了一套行业领先的大语言模型，结果一线销售拿它写客户跟进邮件，AI生成的文案满篇“赋能”“抓手”“闭环”，客户看了直皱眉；技术团队用它读内部API文档，它能复述接口名，却总在关键参数类型上出错；甚至法务部门让它审合同，它能把“不可抗力”定义背得滚瓜烂熟，但对自家合同里那条模糊的“交付延迟补偿条款”视而不见。这不是模型能力不行，而是它根本没学过你的语境、你的规则、你的“行话”。Fine-Tuning LLMs: Use Case Examples这个标题，说的正是解决这类问题的最务实路径——不靠玄学提示词工程，也不靠堆算力硬扛，而是让模型真正“入职”你的组织，用你的真实数据、你的业务逻辑、你的成败标准，完成一次精准的“岗位培训”。它不是教模型“怎么说话”，而是教它“说什么、对谁说、为什么这么说”。我做过27个不同行业的微调项目，从三甲医院的病历结构化提取，到长三角小家电厂的BOM表纠错，再到跨境物流公司的多语种提单审核，所有成功案例都指向一个核心：微调不是技术炫技，是业务问题的翻译过程——把人脑里的隐性知识，变成模型可学习、可泛化、可验证的显性信号。如果你正被“模型很聪明，但总差点意思”困扰，或者团队还在用几十轮提示词迭代去逼近一个基础功能，这篇就是为你写的实操手册。它不讲抽象理论，只拆解真实战场上的决策链、踩坑点和可抄作业的配置项。

2. 微调的本质与选型逻辑：为什么不是所有场景都该微调？

2.1 微调不是“重训练”，而是“精准校准”

很多人一听到“微调”，下意识就想到“从头训一个模型”，这完全误解了它的定位。Fine-tuning 的本质，是利用预训练模型已有的海量世界知识（world knowledge）和语言理解能力（linguistic competence），仅针对特定任务目标，调整其输出行为的“权重偏向”（weight bias）。这就像给一副顶级光学镜头（预训练模型）加装一个可更换的滤镜组（微调权重）：镜头本身的解析力、进光量、色准都没变，但通过滤镜，你可以让它专拍红外热成像、专捕高速运动轨迹、或专做天文深空摄影。微调不改变模型的“硬件”，只优化它的“应用模式”。

提示：微调 ≠ 重训练。重训练需要数万张GPU小时和TB级清洗数据；微调通常只需几块A100，几天时间，几百条高质量样本。混淆二者，会导致资源错配和项目夭折。

2.2 三大不可替代的微调价值场景

并非所有需求都值得微调。根据我经手的项目数据，以下三类场景，微调带来的ROI（投资回报率）远超提示词工程或RAG：

1. 领域术语与实体识别精度要求极高
   比如医疗场景中，“CA125”是肿瘤标志物，“CA-125”是同一指标的规范写法，“ca125”可能是患者手写误录，“Ca125”可能是检验科报告缩写。通用模型会把它们当成不同实体。微调时，用100条标注了“CA125/CA-125/ca125/Ca125 → 同一医学概念”的样本，模型就能学会这种映射关系。而提示词工程需要反复强调“请将所有变体统一为CA125”，且每次调用都可能失效。

2. 输出格式与结构有刚性约束
   制造业的设备故障报告必须包含“故障代码|发生时间|影响产线|建议措施”四字段，缺一不可，且“影响产线”只能填“A线/B线/C线”三个选项。通用模型常自由发挥，生成“影响很大”“波及范围广”等无效描述。微调时，用50条严格按此JSON Schema格式标注的样本，模型输出合规率从32%跃升至98.7%。这是提示词无法保证的确定性。

3. 业务逻辑嵌入与决策链建模
   金融风控场景中，“客户近3个月月均流水＜5000元”且“征信查询次数＞5次”才触发高风险预警。通用模型可能只关注单个条件，或错误关联“查询次数多=信用好”。微调时，我们不喂原始数据，而是喂“条件组合→决策标签”的逻辑链样本（如：“流水4800+查询7次→高风险”、“流水6200+查询2次→低风险”），模型学到的是业务规则本身，而非表面特征。

2.3 为什么RAG和提示词工程在此失效？

• RAG（检索增强生成）的瓶颈在于“检索即幻觉”。当用户问“对比A型号和B型号在高温环境下的MTBF差异”，RAG需先从知识库检出两份PDF，再让模型比对。但若PDF中A型号写的是“MTBF≥5000h”，B型号写的是“平均无故障时间不低于5000小时”，检索模块大概率因关键词不匹配而漏检B型号文档。微调则让模型内化“MTBF=平均无故障时间”这一等价关系，直接处理原始文本。

• 提示词工程的致命伤是“状态不可继承”。你花了2小时调出完美提示词：“你是一名资深半导体工艺工程师，请用3句话解释PECVD镀膜厚度不均的原因，每句不超过15字，禁用英文缩写”。但下次用户问“如何调整RF功率解决该问题”，模型又回到“通用工程师”状态，需重新注入全部约束。微调是一次性固化，所有后续调用自动继承。

2.4 微调方案选型：LoRA、QLoRA、Full Fine-tuning 如何抉择？

选型不是看谁“高级”，而是看谁“够用且省事”。我用一张表总结三年实战经验：

注意：LoRA的秩（rank）不是越大越好。我曾用rank=128微调客服对话模型，效果反而比rank=64差0.8%。因为过高的秩会让适配器“学偏”，过度拟合训练集噪声。经验法则：从rank=8起步，每轮增加8，直到验证集loss不再下降，取前一轮值。

3. 四大高频用例深度拆解：从数据准备到效果验证

3.1 用例一：电商客服对话意图识别（提升工单分类准确率）

业务痛点：某母婴电商平台日均2.3万咨询，原系统用规则+关键词匹配，将“奶粉罐子漏粉”归为“物流问题”，实际应属“商品质量”。导致售后响应延迟，客诉率上升17%。

微调目标：构建高精度意图分类器，将用户原始消息映射到12个标准意图（如“商品质量-包装破损”、“物流-配送延迟”、“售后-退换货”）。

数据准备实操细节：

• 不是简单收集聊天记录：我们剔除了所有带客服回复的上下文，只保留用户首条消息（因首条决定初始路由）。共清洗出8,421条有效样本。
• 标注策略反常识：未采用“一句话一标签”，而是按语义原子切分。例如用户说：“昨天收到的飞鹤奶粉罐子漏粉，快递盒也压扁了，能换一罐新的吗？”，我们标注为3条：
  [飞鹤奶粉罐子漏粉] → 商品质量-包装破损
[快递盒也压扁了] → 物流-包装破损
[能换一罐新的吗] → 售后-换货
  这让模型学会解耦复合诉求，避免“漏粉+压扁”被强行归为单一意图。
• 数据增强技巧：对“包装破损”类样本，用同义词替换（“漏粉→渗粉/溢粉/洒粉”）、句式变换（“罐子漏粉”→“打开发现奶粉从罐口漏出”），但严禁机器翻译扩增——非母语表达会污染模型对真实用户语感的学习。

模型与训练配置：

• 基座模型：Qwen2-1.5B（轻量、中文强、推理快）
• 微调方法：LoRA（rank=32, alpha=64, dropout=0.1）
• 关键参数：max_length=512（覆盖长投诉）、batch_size=16（A100×2）、learning_rate=2e-4
• 训练监控重点：不只看准确率，更盯F1-macro（防止单一高频意图主导评估）。当验证集F1-macro连续2轮不升，立即停止。

效果验证与上线：

• 线下测试：准确率从72.3%→94.1%，F1-macro从68.5→92.7
• A/B测试：新模型路由的工单，首次解决率提升23%，平均处理时长缩短4.2分钟
• 上线避坑：未直接替换旧系统，而是部署为“第二意见模块”。当原系统置信度＜85%时，调用微调模型二次判断。这避免了冷启动风险，也让我们收集到更多边界case用于迭代。

3.2 用例二：制造业设备维修报告生成（替代人工撰写）

业务痛点：某汽车零部件厂，维修技师现场用平板录入故障，原系统生成报告需手动填写17个字段（故障代码、部件号、更换件、工时等），平均耗时8分钟/份，且常漏填“安全注意事项”字段，导致安全部门抽检不合格。

微调目标：输入技师语音转文字的口语化描述（如：“曲轴箱盖螺丝全滑丝，拧不紧，旁边油渍一大片，估计是上次保养没上扭矩”），自动生成结构化维修报告（JSON格式）。

数据准备实操细节：

• 源头数据即黄金：我们不找NLP工程师编造样本，而是从历史合格报告中反向提取。随机抽取300份已通过QA审核的报告，用正则提取每个字段值，再用TTS合成对应语音，最后ASR转回文字。得到300条“真实口语→标准报告”的配对数据。
• 强制结构化标注：报告JSON schema固定为：

  { "fault_code": "string", "part_number": "string", "replaced_parts": ["string"], "labor_hours": "float", "safety_notes": "string" }

  标注时，对“安全注意事项”字段，要求必须包含“⚠️”符号开头（如“⚠️操作前断开蓄电池负极”），确保模型学会该格式约束。
• 对抗噪声设计：在训练数据中，故意加入10%的ASR错误样本（如“曲轴箱”→“曲轴箱”，“扭矩”→“扭距”），提升模型鲁棒性。

模型与训练配置：

• 基座模型：ChatGLM3-6B（对中文结构化生成稳定，支持长上下文）
• 微调方法：LoRA（rank=64, alpha=128）
• 关键参数：max_length=1024,batch_size=8,learning_rate=1e-4,warmup_ratio=0.1
• 损失函数定制：在标准交叉熵损失上，对safety_notes字段的预测，额外加权2倍损失（因其业务重要性最高）。

效果验证与上线：

• 字段填充完整率：从61%→99.2%（仅safety_notes仍偶有遗漏）
• 人工复核时间：从8分钟→47秒（主要检查safety_notes是否合理）
• 关键收益：安全部门抽检合格率从76%→100%，因safety_notes字段填充率100%，且内容符合SOP。

3.3 用例三：律所合同关键条款抽取（降低尽调风险）

业务痛点：某红圈所处理并购尽调，需从数百页PDF合同中提取“控制权变更条款”、“竞业禁止期限”、“赔偿上限金额”等12类条款。原用OCR+规则引擎，对扫描件模糊、表格跨页、手写批注等情况识别率不足40%，律师需人工复核80%内容。

微调目标：输入PDF文本（含OCR识别结果），输出结构化JSON，精确抽取指定条款原文及位置（页码+行号）。

数据准备实操细节：

• 放弃“端到端OCR”幻想：我们不微调OCR模型，而是将OCR结果作为输入。数据标注基于真实OCR输出（含错别字、乱序、缺失），而非理想化clean text。例如OCR将“赔偿上限为交易对价的20%”识别为“赔偿上限为交易对价的20%”，标注时仍标为正确原文，并记录OCR错误位置。
• 位置信息必须可验证：每条样本标注包含"text": "原文", "page": 12, "line_start": 3, "line_end": 5。我们开发了校验脚本，自动用PDF阅读器跳转到指定位置，确认原文是否匹配。不匹配的样本直接剔除（占初筛数据的18%）。
• 长文本截断策略：PDF文本常超2000字。我们采用“滑动窗口+中心聚焦”：以目标条款为中心，向前取500字，向后取500字，形成1000字上下文。窗口外内容丢弃，但标注时注明“条款位于文档中后部”，防止模型只学局部模式。

模型与训练配置：

• 基座模型：Qwen2-7B（长文本理解强，支持128K上下文）
• 微调方法：LoRA（rank=64），额外启用FlashAttention-2（加速长文本训练）
• 关键参数：max_length=2048,batch_size=4,learning_rate=5e-5,gradient_accumulation_steps=4
• 位置预测技巧：不直接预测页码数字，而是将页码离散化为100个桶（1-100页），用分类损失；行号同理分为50桶。这比回归预测更稳定。

效果验证与上线：

• 条款抽取F1：从38.2%→89.6%（“赔偿上限金额”单项达94.3%）
• 位置准确率（页码±1页内）：92.1%
• 律师反馈：最惊喜的是对“手写批注”的处理。OCR将批注识别为乱码，但模型能从上下文推断“此处有修改”，并准确定位到主文对应条款。这是纯规则引擎永远做不到的。

3.4 用例四：跨境电商多语种产品描述生成（提升转化率）

业务痛点：某深圳3C配件卖家，需将中文产品描述（如“Type-C接口，支持100W快充，兼容PD3.0协议”）生成英/德/日/西四语版本。原用Google Translate，德语版将“快充”译为“schnelle Aufladung”（字面快充），但德国消费者搜索习惯是“Schnellladung”，导致搜索曝光降35%。

微调目标：输入中文描述，输出目标语言描述，要求符合当地搜索习惯、平台合规要求（如亚马逊禁止“best”“#1”等绝对化用语）、且保持技术参数零误差。

数据准备实操细节：

• 拒绝机器翻译数据：我们雇佣4国本地化专员，每人负责一种语言。要求他们：
  (1) 阅读中文原文，理解技术含义；
  (2) 查阅亚马逊/当地主流平台TOP10竞品页面，记录高频词汇；
  (3) 撰写符合平台规则的描述（如德语禁用“schnellste”，改用“sehr schnelle”）。
  共获2,100条高质量人工翻译对。
• 参数一致性校验：对“100W”“PD3.0”等关键参数，建立白名单。标注时，若译文将“100W”写成“100 Watt”或“100 watt”，视为错误（因平台搜索区分大小写）。我们用正则强制校验，错误样本返工。
• 文化适配标注：日语样本中，要求添加“※本製品は○○規格に準拠”（※本产品符合○○标准）等日本消费者信任要素；西班牙语样本中，要求使用“carga rápida”（而非“carga veloz”）等拉美通用词。

模型与训练配置：

• 基座模型：Qwen2-7B（多语言能力强，中文到小语种迁移效果好）
• 微调方法：LoRA（rank=64），启用多任务学习：同时训练中→英、中→德、中→日、中→西四个方向，共享LoRA适配器，仅最后分类头不同。
• 关键参数：max_length=256,batch_size=16,learning_rate=1e-4,label_smoothing=0.1（防止单一token过拟合）
• 解码策略：线上服务用beam_search（beam=4），禁用temperature（避免创造性错误）。

效果验证与上线：

• 人工评测（5人盲评）：语法正确率99.1%，技术参数准确率100%，本地化适配得分（1-5分）平均4.6分
• A/B测试：德语页面转化率提升22.3%，日语页面搜索自然流量提升31.7%
• 意外收获：模型学会了“参数前置”规则。中文描述“兼容PD3.0协议，支持100W快充”，德语自动输出“100W Schnellladung mit PD3.0-Kompatibilität”，将消费者最关心的“100W”放在句首——这是人工翻译常忽略的细节。

4. 实操全流程：从环境搭建到生产部署的每一步

4.1 环境准备：避开CUDA与PyTorch的“经典死亡组合”

微调失败，70%源于环境配置。我列出2024年最稳的组合（已实测）：

• CUDA版本：12.1（绝不用12.2+，因HuggingFace Transformers 4.41对12.2支持不全，训练中偶发cudaErrorIllegalAddress）
• PyTorch版本：2.3.0+cu121（pip install torch==2.3.0+cu121 torchvision==0.18.0+cu121 --extra-index-url https://download.pytorch.org/whl/cu121）
• 关键依赖：transformers==4.41.2,peft==0.10.0,bitsandbytes==0.43.3（QLoRA必需），accelerate==0.30.1
• GPU驱动：≥535.104.05（NVIDIA官方推荐，低于此版本在A100上易出现显存泄漏）

提示：用nvidia-smi确认驱动版本后，务必执行sudo apt-get update && sudo apt-get install -y nvidia-cuda-toolkit，否则nvcc --version可能显示旧版，导致编译失败。

4.2 数据预处理：清洗比建模更重要

我见过太多团队把80%时间花在调参，却用10分钟草草清洗数据。以下是血泪教训总结的清洗清单：

1. 去重硬规则：

   • 完全相同文本（字符级）：删除重复样本
   • 语义重复（用sentence-transformers/all-MiniLM-L6-v2计算余弦相似度＞0.95）：保留标注质量更高者
   • 警惕“伪去重”：用户说“手机充不进电”和“手机无法充电”，语义相同，但若前者标注为“电池故障”，后者为“充电器故障”，则不能去重——这反映的是标注歧义，需QA介入。

2. 长度过滤：

   • 设min_length=10（防止单词如“good”被误标）
   • max_length按基座模型定：Qwen2-1.5B用512，Qwen2-7B用1024
   • 关键技巧：对超长样本，不简单截断，而用“摘要+关键句保留”：先用TextRank提取3个关键句，再拼接摘要，确保核心信息不丢失。

3. 特殊字符处理：

   • 删除不可见Unicode字符（\u200b,\ufeff等）
   • 将全角标点（，。！？）转半角（，。！？）
   • 保留业务符号：电商数据中的“¥”、法律数据中的“§”、制造数据中的“±”，这些是模型理解领域的关键锚点，绝不删除。

4.3 训练脚本核心代码与参数详解

以下是我们生产环境使用的LoRA微调脚本核心片段（基于HuggingFace Trainer），附关键参数说明：

from transformers import TrainingArguments, Trainer from peft import LoraConfig, get_peft_model # LoRA配置 - 这是效果核心 peft_config = LoraConfig( r=64, # rank，64是7B模型黄金值 lora_alpha=128, # alpha，通常设为r的2倍，平衡更新强度 target_modules=["q_proj", "v_proj", "k_proj", "o_proj"], # Qwen2的注意力层模块名 lora_dropout=0.1, # 防止过拟合，0.1是经验值 bias="none", # 不训练bias，节省显存 task_type="CAUSAL_LM" # 因果语言建模，适用于生成任务 ) # 训练参数 - 直接决定收敛质量 training_args = TrainingArguments( output_dir="./results", num_train_epochs=3, # 通常3轮足够，过拟合风险高 per_device_train_batch_size=8, # A100×2时，总batch_size=16 gradient_accumulation_steps=4, # 模拟更大batch，稳定训练 learning_rate=1e-4, # LoRA专用学习率，比Full小10倍 warmup_ratio=0.1, # 前10%步数线性增大学习率，防震荡 weight_decay=0.01, # L2正则，抑制过拟合 logging_steps=10, # 每10步打日志，监控loss save_steps=500, # 每500步存checkpoint，防中断 evaluation_strategy="steps", # 每500步验证，及时发现过拟合 eval_steps=500, load_best_model_at_end=True, # 训练结束加载最优checkpoint metric_for_best_model="eval_loss", # 用验证loss选最优 greater_is_better=False, # loss越小越好 report_to="none", # 关闭wandb，避免网络问题中断 fp16=True, # 启用混合精度，提速30%，显存减半 optim="adamw_torch_fused", # 新版AdamW，比默认快15% )

为什么learning_rate=1e-4是LoRA的黄金值？
我做过梯度实验：在Qwen2-7B上，lr=5e-5时loss下降慢；lr=2e-4时，第1轮loss骤降但第2轮剧烈震荡；lr=1e-4时，loss平滑下降，且验证集指标最稳。这是因为LoRA的更新量是delta_W = A * B（A、B为低秩矩阵），lr需匹配这个增量尺度。1e-4是大量实验验证的平衡点。

4.4 效果验证：超越Accuracy的多维评估体系

微调不是“训练完就上线”，验证才是成败关键。我们坚持四维评估：

特别提醒：不要迷信自动化指标！我曾有个项目BLEU-4达72.3，但业务方反馈“生成的维修步骤顺序全是错的，按它操作会烧毁电路板”。原因在于BLEU只看n-gram重叠，不看逻辑顺序。必须加入业务逻辑校验——我们为此开发了“步骤依赖图谱”，自动验证生成步骤是否满足“先断电→再拆壳→最后检测”的强制顺序。

4.5 生产部署：从Checkpoint到API服务的无缝衔接

训练完的.bin文件不是终点，而是服务的起点。我们的标准部署流程：

1. 模型合并：用peft.merge_and_unload()将LoRA权重合并到基座模型，生成标准HF格式模型。

   注意：合并后模型体积增大（Qwen2-7B+LoRA约15GB），需确认存储空间。

2. 量化压缩（可选）：对推理延迟敏感场景，用bitsandbytes进行4-bit量化：

   from transformers import AutoModelForCausalLM model = AutoModelForCausalLM.from_pretrained( "./merged_model", load_in_4bit=True, bnb_4bit_compute_dtype=torch.float16 )

   量化后显存占用从14GB→6GB，推理速度提升2.1倍，精度损失＜0.5%（经业务验证）。

3. API封装：用vLLM（非FastAPI）部署，因其专为LLM推理优化：

   python -m vllm.entrypoints.api_server \ --model ./merged_model \ --tensor-parallel-size 2 \ # A100×2 --dtype half \ --max-model-len 2048

   关键优势：vLLM的PagedAttention机制，使吞吐量比HuggingFace原生推理高3-5倍，且支持动态batch，高峰请求自动排队。

4. 监控告警：在API层埋点，监控：

   • p95_latency（毫秒）：＞2000ms触发告警
   • error_rate（%）：＞0.5%触发告警
   • gpu_memory_utilization（%）：＞90%触发扩容
     所有指标接入Grafana，告警发企业微信。

5. 常见问题与独家排查技巧实录

5.1 “训练loss不降反升”——90%是数据泄露

现象：训练loss从1.2一路涨到3.5，验证loss同步飙升。
错误归因：调小learning_rate、加大dropout。
真实原因：训练集混入了验证集样本（如文件复制时重命名失误）。
排查技巧：

1. 用md5sum对所有训练/验证文件逐行计算哈希；
2. 用comm -12 <(sort train_hashes) <(sort val_hashes)检查交集；
3. 终极验证：临时将验证集loss计算改为train_loss，若此时验证loss也暴跌，100%确认泄露。
   解决方案：彻底清洗数据源，重建数据集。切勿用“早停”掩盖此问题——泄露的数据会让模型学到虚假规律。

5.2 “生成结果全一样”——LoRA适配器未生效

现象：所有输出都是“好的，我明白了。”或重复第一句。
错误归因：模型坏了、数据太少。
真实原因：target_modules配置错误，LoRA未注入到正确层。
排查技巧：

1. 加载模型后，运行：

   for name, module in model.named_modules(): if "lora" in name.lower(): print(name) # 应看到q_proj.lora_A等

2. 若无输出，检查target_modules是否匹配基座模型实际模块名（Qwen2是q_proj/v_proj/k_proj/o_proj，Llama3是q_proj/k_proj/v_proj/o_proj）。
   解决方案：打印模型结构print(model)，找到准确模块名，修正配置。

5.3 “中文输出夹杂乱码”——Tokenizer未对齐

现象：生成中文时，突然出现``或「等符号。
错误归因：训练数据有乱码。
真实原因：微调时用了错误的tokenizer，或tokenizer未随模型保存。
排查技巧：

1. 检查训练脚本中tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2-7B")是否与基座模型完全一致；
2. 验证tokenizer能否正确encode/decode：

   text = "你好世界" ids = tokenizer.encode(text) decoded = tokenizer.decode(ids) assert decoded == text, f"Decode error: {decoded}" # 必须通过

解决方案：始终用AutoTokenizer.from_pretrained()加载，绝不用from_pretrained("./my_tokenizer")（除非你明确重训了tokenizer）。

5.4 “微调后效果反而变差”——灾难性遗忘

现象：微调后，通用能力大幅下降（如问“地球周长多少”答错）。
错误归因：微调破坏了模型。
真实原因：训练数据过于单一，模型“忘记”了通用知识。
解决方案：

• 混合训练：在业务数据中，按10%比例掺入通用指令数据（如alpaca的中文版）；
• 渐进式微调：先用通用指令微调1轮（warm-up），再用业务数据微调；
• 我的实测效果：混合训练使通用问答准确率保持在92%（纯业务微调后为68%），业务任务F1仅降0.3%，完全可接受。

5.5 “显存OOM”——最常被忽视的Batch Size陷阱

现象：CUDA out of memory，即使batch_size=1也报错。
错误归因：GPU不够。
真实原因：gradient_accumulation_steps设置过大，或max_length超出显存承载。
排查技巧：

1. 用nvidia-smi监控，看OOM前显存是否接近100%；
2. 临时将max_length设为128，若不OOM，则确认是长度问题；
3. 计算理论显存：显存(GB) ≈ 2 * model_params(GB) * (1 + seq_len / 512)（粗略公式）。
   解决方案：

• 优先调小max_length（用滑动窗口截断）；
• 其次减少gradient_accumulation_steps；
• 最后考虑QLoRA（但牺牲精度）。

6. 经验之谈：那些没人告诉你的“潜规则”

6.1 数据质量 > 模型大小 > 训练技巧

我做过对照实验：用同一套LoRA配置，分别微