如果你已经读完了前面几篇关于环境、原理和数据规范的铺垫那这篇就是正式动手的那一步。零基础大模型微调实战教程走到第6篇不再讲概念而是带着你完成第一个完整的微调项目——情感分析助手。它的功能很直观输入一段中文文本模型输出三个东西情感标签正向/负向/中性、判断理由、以及一个简短的结论。别觉得这个任务太简单它背后藏着所有微调项目都会遇到的环节数据构造、训练参数选择、效果评估、踩坑排查。把这套流程走一遍后续你换到客服问答、文案生成、意图识别都只是换数据和模板的事。我尽量把这篇写成即使你跳过了前面几章也能直接看懂的独立教程。不依赖深度学习的进阶背景不需要你手写反向传播只需要有Python基础、能安装环境跟着一步步操作就能跑通从数据准备到模型推理的整个闭环。1. 起手式先想清楚这个微调项目要什么1.1 输入一条评论输出一个标签和一段理由先给“情感分析助手”一个明确的输入输出定义。比如我输入“手机用了三天就卡客服还一直推诿”我希望模型输出负面理由用户对手机性能不满意同时抱怨售后推诿整体体验较差。再比如输入“配送很快包装很严实”模型应该输出“正面理由用户认可配送速度和包装质量”。这里特意让模型输出“理由”而不是只输出一个标签。因为微调生成式模型的价值就在这里它不只是做一个分类而是能给出解释。这对业务场景很重要比如电商评论监控里运营人员希望快速知道“用户到底在抱怨什么”而不只是一个负面标记。如果你只想做标签分类传统的小模型方案效率更高根本不需要大模型。我们之所以选择用大模型微调来做就是看中了“可解释、可泛化、能适应复杂表达”的长处。1.2 为什么第一个项目要选它我几乎每次带新手入门都建议从这类任务开始原因有四个。第一数据好做。情感分析不需要领域专家参与标注。正负中三类的判断普通人一看就明白你可以在一小时之内手工造几十条质量不错的数据。第二效果直观。训练前后一对比立刻能看出模型有没有发生改变这种正反馈对建立信心非常重要。第三链路完整。从数据清洗、格式化、加载模型、配置LoRA、启动训练、加载checkpoint、写推理函数到算准确率、分析bad case微调项目的核心环节全都覆盖到了。第四成本可控。这类任务对模型参数量的要求不高一个1B到3B的中文底座模型在消费级显卡上就能跑通不用纠结算力不够。等你把这个项目从头到尾跑完再去看其他复杂微调任务至少在工程框架上不会发怵了。剩下的问题主要是数据质量和业务理解深度。1.3 技术选型小底座模型 LoRA 本地训练零基础最容易犯的错是一上来就打算全参数微调一个几十B的大模型。这不光需要大量算力对新手来说调试难度也很高。我的推荐方案是三板斧小底座模型、LoRA、本地训练。全参数微调的意思是把底座模型的全部参数都放到训练中梯度更新和显存占用都很夸张。LoRA则是冻结住原始模型的大部分参数只训练少量新增的低秩旁路参数。你可以这么理解全参数微调像把整本书重新抄一遍而LoRA像是给书里的重点章节加便签和索引书的内容没动只是多了几条轻量的标记通路。效果上LoRA未必输给全参数微调训练成本却低一个数量级零基础完全没必要绕开它去硬扛全参数微调。底座模型选哪家、选多大这里不点名某个具体产品只说判断标准选一个主流的中文开源底座的指令微调版本参数量在1B到3B之间最佳如果想挑战7B那就配合4bit量化使用。关键是要有完整的本地推理和微调支持而且你下载到的路径里要包含分词器文件和模型权重文件。不要选几十B的大家伙第一个项目没必要。训练框架直接用开源生态里常见的组合transformers负责模型与训练流程peft提供LoRA实现datasets处理数据accelerate负责分布式和混合精度。这些都是现成的轮子不需要自己造。1.4 硬件和环境准备显卡、CPU都能跑理论上一张显存8GB以上的消费级显卡训练1B到3B级别的底座模型就非常舒服了。显存12GB以上可以尝试7B级别加4bit量化。如果没有独立显卡纯CPU也能跑但速度很慢建议只用来验证流程、把数据量控制在20条以内。环境安装没什么花活创建一个干净的Python环境再安装核心依赖conda create -n sft python3.10 -y conda activate sft pip install torch transformers datasets peft accelerate如果打算做4bit量化训练再补一个量化相关依赖即可。版本上特别提醒一句torch和transformers的版本要匹配最好安装一套在当前时间点稳定的组合不要贪新也不要所有库都追最新版。装完后可以跑一句快速验证python -c import torch; print(torch.cuda.is_available())输出True说明GPU环境正常输出False就老老实实用CPU跑小规模Demo。2. 数据准备12条数据也能训练先把格式弄对2.1 明白大模型微调吃的“标准餐”微调数据最常用的组织格式是JSONL每行一个JSON对象。对指令微调任务来说每条样本通常包含三个字段instruction、input和output。举个例子{instruction: 判断下面文本的情感倾向输出正向、负向或中性并说明理由。, input: 手机用了三天就卡客服还一直推诿。, output: 负面。理由用户对手机性能不满意同时抱怨售后推诿整体体验较差。}模型训练时看到的是“指令输入标准答案”拼接后的完整文本学习的目标是让模型在看到同样指令时习惯性地输出接近标准答案的内容。所以output字段必须是一个完整自然的中文回答不能只写一个孤零零的标签也不能是机器腔太重的模板句。2.2 手写一份最小可用的情感数据集第一版不需要追求量大。我带你构造12条数据覆盖正、负、中三个类别每个类别4条。领域上故意混合手机、外卖、耳机、酒店、电影、快递这样才能让模型学到的不是一个领域的特化表达。类别输入输出负面手机用了三天就卡客服还一直推诿负面。理由用户对手机性能不满意同时抱怨售后推诿整体体验较差。负面外卖送到时汤全洒了骑车小哥还让我自己联系商家负面。理由配送过程导致餐品损坏且责任转移给用户体验糟糕。负面酒店房间隔音特别差凌晨还能听到走廊脚步声负面。理由隔音问题直接影响休息质量用户给出差评。负面蓝牙耳机用了两周就单侧无声申请售后还要自费寄回负面。理由产品质量不稳定且售后流程不合理。正面配送很快包装很严实拆开一点磕碰都没有正面。理由用户认可配送速度和包装质量。正面这家餐厅的牛肉面汤底很浓面条劲道值得再来正面。理由用户对菜品口味给予好评并愿意复购。正面客服响应特别及时半夜提问也有人在十分钟内回复正面。理由客服响应用及时让用户感到安心。正面电影节奏紧凑反转不突兀全程没有玩手机正面。理由剧情引人入胜用户观影体验良好。中性这家店的营业时间是早上九点到晚上六点中性。理由只是客观陈述营业时间没有情感倾向。中性手机包装盒里附赠了一条充电线中性。理由陈述配件情况不带评价色彩。中性快递预计明天送达具体要看当地天气中性。理由信息类表述无明显正面或负面态度。中性酒店离地铁站步行大约十分钟中性。理由陈述地理位置不含主观评价。构造数据时留意三个细节一是标签数量平衡别让负面占一大半二是理由的句式要多样避免每一条都说“用户对……不满意”否则模型会把理由写成复读机三是训练时别只挑很极端的表达适当放一些需要推理才能判断的句子比如“价格不便宜但品质确实值了”这种混合倾向或者带转折的句子。2.3 数据清洗与自检训练前多花5分钟数据文件准备好之后我强烈建议先跑一个自检脚本而不是直接丢给训练程序。脚本做三件事检查字段完整性、统计标签分布、打印拼接后的训练文本。import json samples [] with open(emotion_data.jsonl, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue obj json.loads(line) assert {instruction, input, output} set(obj.keys()), 字段缺失 samples.append(obj) from collections import Counter labels [] for s in samples: label s[output].split(。)[0].replace(负面, 负面).replace(正面, 正面).replace(中性, 中性) labels.append(label) print(Counter(labels)) def build_prompt(instruction: str, input_text: str) - str: return f【任务】{instruction}\n【文本】{input_text}\n【分析】 print(build_prompt(samples[0][instruction], samples[0][input]) samples[0][output])这里的build_prompt函数是整个项目的关键。训练时怎么拼接prompt推理时就要一模一样地拼接一个词都不能差。我在后面的章节还会反复提这件事因为这是新手最容易翻车的地方没有之一。3. 训练脚本拆解手把手把第一个微调跑起来3.1 加载模型与分词器先把“骨架”放到显存里训练脚本的第一步是加载底座模型和分词器。这里用一个占位路径实际使用时替换成你本地下载好的模型目录。import torch from transformers import AutoTokenizer, AutoModelForCausalLM base_model_path ./your_base_model tokenizer AutoTokenizer.from_pretrained(base_model_path, trust_remote_codeTrue) if tokenizer.pad_token is None: tokenizer.pad_token tokenizer.eos_token model AutoModelForCausalLM.from_pretrained( base_model_path, torch_dtypetorch.bfloat16, device_mapauto )有两个技术上必须做的事要说明。第一给tokenizer设置pad_token。因为训练时一个batch内样本长度不同需要padding对齐到相同长度。如果pad_token为空批量训练直接报错。这里通常用eos_token充当pad_token计算loss时会忽略掉padding部分不会引入额外噪声。第二模型加载时用bfloat16精度能在几乎不掉点的前提下大幅降低显存占用。如果你的显卡比较老不支持bfloat16可以退一步用float16。设备映射部分device_mapauto的意思是框架自动判断模型放哪张卡单卡环境下就是全部放到GPU。加载完成后建议打印一下模型参数量确认本地文件没问题total sum(p.numel() for p in model.parameters()) print(f模型总参数量: {total / 1e9:.2f}B)3.2 配置LoRA和训练参数懂参数比懂代码更重要主体模型加载完成后就是给模型套上LoRA配置。下面这个配置是我在情感分析这类任务上的常用起点from peft import LoraConfig, get_peft_model, TaskType lora_config LoraConfig( r8, lora_alpha16, lora_dropout0.05, target_modules[ q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj ], task_typeTaskType.CAUSAL_LM, biasnone, ) model get_peft_model(model, lora_config) model.print_trainable_parameters()这几个参数的含义要搞清楚因为后面调优全靠它们参数作用调整倾向r低秩矩阵的秩控制新增参数规模r越大表达能力越强但过大会导致过拟合和显存上涨8是一个稳妥起点lora_alpha缩放系数影响LoRA模块的更新幅度通常设为r的2倍左右和r保持相对关系lora_dropout防止LoRA旁路过拟合的随机丢弃比例数据量少时可以适当调大比如0.1target_modules要对哪些模块施加LoRA覆盖注意力与前馈网络的核心矩阵均衡性好用我这次贴的target_modules列表等于把模型的大部分线性投影层都加了LoRA。代价是训练参数量会稍微多一些但对1B到3B的小模型来说无关痛痒。如果是性能焦虑可以只保留q_proj和v_proj效果会略降但显存压力更小。接下来是训练参数。这部分我用的是零基础也能安全的配置from transformers import TrainingArguments training_args TrainingArguments( output_dir./sft_emotion_ckpt, per_device_train_batch_size4, gradient_accumulation_steps8, learning_rate2e-4, num_train_epochs3, lr_scheduler_typecosine, warmup_ratio0.03, logging_steps10, save_strategysteps, save_steps50, eval_strategysteps, eval_steps50, bf16True, weight_decay0.01, )对每个关键参数我解释一下为什么这么设。学习率为什么是2e-4而不是更小的1e-5因为LoRA只更新很小一部分新增参数它的大多数权重仍然被冻结因此可以用比全参数微调更大一些的学习率。全参数微调常用1e-5到5e-5LoRA则常见2e-4。这个数值不需要从一个很夸张的值开始2e-4已经是很安全的起点。如果训练中loss震荡厉害可以降低到1e-4。梯度累积为什么是8单卡batch_size设4显存够用但4这个数值太小会导致梯度更新方向不稳定。gradient_accumulation_steps8表示每8个小batch才真正更新一次权重等效batch size是4×832。这个等效值对大多数微调任务是一个均衡选择。轮数为什么是3情感分析数据量小3轮足够让模型学到格式和分类逻辑再多容易过拟合。如果你数据量只有十几条甚至2轮就够了。3.3 数据Tokenizer与Trainer把数据集送进模型数据加载部分先把JSONL读进来转成datasets的Dataset对象然后做训练集和验证集划分。最关键的是tokenize函数它决定模型到底学什么。from datasets import Dataset with open(emotion_data.jsonl, r, encodingutf-8) as f: samples [json.loads(line) for line in f if line.strip()] dataset Dataset.from_list(samples) dataset dataset.train_test_split(test_size0.1, seed42) train_ds, eval_ds dataset[train], dataset[test] def tokenize_func(data): prompt build_prompt(data[instruction], data[input]) answer data[output] text prompt answer model_inputs tokenizer(text, max_length512, truncationTrue) input_ids model_inputs[input_ids] labels input_ids.copy() prompt_ids tokenizer(prompt, add_special_tokensFalse, max_length512, truncationTrue)[input_ids] labels[:len(prompt_ids)] [-100] * len(prompt_ids) model_inputs[labels] labels return model_inputs tokenized_train train_ds.map(tokenize_func, remove_columnstrain_ds.column_names) tokenized_eval eval_ds.map(tokenize_func, remove_columnseval_ds.column_names)这里的核心思路是模型输入的完整文本是“prompt answer”但计算loss时只对answer部分计算prompt部分全部被mask成-100。这么做的原因是我们想让模型学会的是“如何生成对问题的回答”而不是“把用户输入重新背一遍”。如果不做这个mask训练目标变成了让模型逐字预测整段文本模型很容易学到复述输入的坏习惯推理时看起来就像“答非所问还废话连篇”。Tokenizer拼接的细节也值得留意。中文tokenizer有时prompt和answer会被合并切分到同一个token导致按token数切分边界不够精确。对零基础项目来说这个误差通常在可接受范围内先跑通整个流程更重要。后面如果要做更严格的长文本任务再引return_offsets_mapping等机制去精确对齐。然后定义Trainer开始训练from transformers import Trainer, DataCollatorForSeq2Seq trainer Trainer( modelmodel, argstraining_args, train_datasettokenized_train, eval_datasettokenized_eval, tokenizertokenizer, data_collatorDataCollatorForSeq2Seq(tokenizer, paddingTrue), ) trainer.train() trainer.save_model(./sft_emotion_final)DataCollatorForSeq2Seq的作用是自动把一批样本填充到相同长度并生成attention_mask。运行训练后日志会持续输出loss{loss: 2.31, learning_rate: 1.8e-4, epoch: 0.2} {loss: 0.85, learning_rate: 8.5e-5, epoch: 1.4} {loss: 0.38, learning_rate: 1.2e-5, epoch: 2.7}loss从2点多一路往下走最终稳定在0.3到0.5之间说明模型在正常学习。如果loss完全纹丝不动请直接跳到第5章排查。3.4 启动训练前先确认这些细节在真正开始跑训练之前有三个细节必须要确认否则很容易挫伤自信心。第一确认你的训练代码里只训练LoRA参数。可以在trainer.train()之前加一句模型打印model.print_trainable_parameters()它会输出类似“trainable params: 4M || all params: 1.2B || trainable%: 0.33”这样的信息。如果可训练参数占比是0%说明LoRA配置没有生效如果占比是100%说明你忘了加get_peft_model变成了全参数微调显存分分钟爆掉。第二确认数据量别被验证集切没。总共12条数据test_size0.1会切出1到2条验证集训练集只剩下10到11条。这没关系目的只是为了跑通链路。等后面数据量加到几百条时验证集比例可以设在0.05到0.1之间。第三训练脚本要保存好prompt模板。建议把build_prompt函数单独放到一个util.py文件里训练和推理共用而不要在训练脚本和推理脚本里各自复制一份。复制粘贴一时爽模板分叉火葬场。推理时如果模板跟训练时不一致再好的权重也白搭。4. 推理和验证让情感分析助手说出判断理由4.1 加载训练好的LoRA适配器训练完成后output_dir下会保存checkpoint包括模型权重和适配器配置。推理时需要先加载底座模型再把LoRA适配器load进来from peft import PeftModel base_model AutoModelForCausalLM.from_pretrained( base_model_path, torch_dtypetorch.bfloat16, device_mapauto ) model PeftModel.from_pretrained(base_model, ./sft_emotion_ckpt/checkpoint-150) model model.merge_and_unload() model.eval()merge_and_unload会把LoRA权重合并回底座模型。合并之后模型从结构上变回一个普通模型推理速度更快也方便导出。如果不合并也可以但不合并时推理多一层适配器调用速度略慢。要注意的是merge操作只影响当前内存里的模型不会动你磁盘上的checkpoint所以想回滚随时可以重建。4.2 一个直接能用的推理函数写一个封装好的推理函数避免每次手动拼promptdef predict(text: str): prompt build_prompt( 判断下面文本的情感倾向输出正向、负向或中性并说明理由。, text ) inputs tokenizer(prompt, return_tensorspt).to(model.device) outputs model.generate( **inputs, max_new_tokens128, do_sampleFalse, temperature1.0, ) response tokenizer.decode(outputs[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue) return response这里的do_sampleFalse是关键。评估场景下我们不需要随机性贪婪解码能让输出稳定可复现。max_new_tokens128对情感分析任务足够理由说得太长反而不好。测试几个例子tests [ 快递到了但箱子被压扁了里面的东西倒没坏。, 这支笔写起来很顺滑但用两天就断墨了。, 电影票已经出票了座位号在短信里。, ] for text in tests: print(文本, text) print(结果, predict(text)) print()第一个例子是混合倾向句子注明了“东西没坏”但用户开头强调的是箱子被压扁模型应该判断为负面或偏中性。第二个例子是优点加缺点的组合模型要识别出整体体验并不好。第三个例子是事实陈述应判中性。你用训练数据里的句子测试时模型输出会跟标注非常接近这是正常的因为那些句子它已经背下来了。真正判断效果要看这些没见过的句子。4.3 用数据说话准确率和bad case单看几个例子不够做一个简单评估脚本准备20条带着标准标签的测试样本批量调用predict再做规则判断输出文本中是否出现了“正面”“负面”“中性”标签词跟标准答案比对。labels [] preds [] for sample in test_data: resp predict(sample[input]) label resp.split(。)[0].strip() preds.append(label) labels.append(sample[label]) correct sum(a b for a, b in zip(labels, preds)) print(f准确率: {correct / len(test_data):.2%})准确率只是一个粗糙的指标因为标签词出现的位置不一定固定模型可能把“理由”部分放在前面。所以我更推荐你在算完准确率之后把所有bad case打印出来逐个看。所谓bad case就是模型判断错误的样本。看多了你会发现错误往往不是模型“不会判断情感”而是以下几种典型情况输入里有明显的转折结构模型忽略了后半句的否定。输入是问句或陈述句情感依上下文而定模型默认按负面处理。训练数据里同类表达太少模型没见过类似的措辞。理由写得通顺但标签给错了或者标签对了但理由逻辑不对。这种人工分析比数字更能指导下一步优化要么补数据要么调prompt要么调整标签粒度。5. 踩坑记录零基础最容易在哪儿翻车5.1 显存不够怎么救训练报错最常见的就是CUDA out of memory。不用慌按优先级逐步处理。第一减小per_device_train_batch_size从4改成2。第二减小max_length512改成256。绝大多数情感分析文本根本不到256个token过长限制只是给padding浪费显存的机会。第三如果前两步都不行考虑换更小的底座模型或者给模型做4bit量化。第四确认你只训练了LoRA参数没变成全参数微调。还有一个容易被忽略的点batch内样本长度差异过大时padding会补齐到最长序列造成大量浪费。短文本任务里max_length设置合理能直接解决这个问题。5.2 损失不下降的排错顺序如果loss卡在某个数值附近不动按顺序检查。先检查数据拼接。模型是否真的能看到标准答案很多人写tokenize函数时只把prompt放进去没拼answer模型训练目标变成预测空白loss当然不降。再检查学习率。2e-4是LoRA的稳妥值但如果设成1e-6训练几百步也未必能降多少。反过来设成1e-3loss可能疯狂震荡。找到合适区间后固定住。接着检查prompt模板。模板里有没有额外的换行、分隔符差异一个多余的“”都可能影响学习效果不过这个因素通常只影响微调质量的细微差别不会导致完全不学习。最后用下面这段代码确认可训练参数for name, param in model.named_parameters(): if param.requires_grad: print(name)如果输出只有少量且名字里带lora说明LoRA生效。如果输出里面有大量embedding、lm_head这类名字说明训练范围失控回看第3.2节。5.3 模型变成“复读机”了怎么办训练好的模型拿到新输入后不管问什么都输出同一句话或者把输入倒回去。最常见的原因是推理参数设置不对do_sampleTrue且temperature过高或者max_new_tokens太小导致回答被截断。先切回do_sampleFalse试一下。如果还是复读检查prompt模板是否和训练时一致模板不匹配的典型表现就是模型乱接上下文。还有一种隐蔽情况是训练数据里answer部分长度很短模型只学会了输出“负面”两个字其它全被当作噪声忽略掉。解决办法是在构造数据时让理由部分内容丰富一些句式多样一些模型的表达能力才会被调动起来。5.4 训练后模型“变笨”了一个1B的小底座原本能回答常识问题微调后反而连加减法都不会了。这确实发生了原因在于微调数据太单一模型把大量权重资源往情感分析方向倾斜覆盖了通用能力。要缓解这件事记住几个经验值r值不要求大8就够了。target_modules不要每次都全部覆盖可以先试q_proj和v_proj。训练数据里适当混入少量通用对话样本能显著降低灾难性遗忘。评估时除了看业务准确率也留几条常识题做通用能力抽检。这些都不是玄学核心逻辑是控制“模型改动幅度”。LoRA本质上是给模型加旁路旁路权重越强大对原模型输出行为的覆盖就越严重。小任务用大旁路就像小水管接了消防水龙头很容易冲坏原有结构。最后分享一个我特别推荐的工作习惯。每次跑微调项目先写一个before.txt把测试集里的文本在原始底座上的输出保存下来。训练完成后再跑一轮生成after.txt。两个文件放在一起对比模型到底学会了什么、丢掉了什么、有没有产生诡异的偏好都一目了然。我第一次把情感分析助手跑通时数据只有二三十条效果谈不上惊艳但就是通过这种前后对比确切看到了模型从“不会按格式回答”到“能输出标签和理由”的变化那一刻我才真正觉得微调不再是一个抽象的概念而是一条自己能够完整掌控的流水线。希望这篇教程也能帮你迈过那道坎把第一个微调项目稳稳落地。
如果你已经读完了前面几篇关于环境、原理和数据规范的铺垫那这篇就是正式动手的那一步。零基础大模型微调实战教程走到第6篇不再讲概念而是带着你完成第一个完整的微调项目——情感分析助手。它的功能很直观输入一段中文文本模型输出三个东西情感标签正向/负向/中性、判断理由、以及一个简短的结论。别觉得这个任务太简单它背后藏着所有微调项目都会遇到的环节数据构造、训练参数选择、效果评估、踩坑排查。把这套流程走一遍后续你换到客服问答、文案生成、意图识别都只是换数据和模板的事。我尽量把这篇写成即使你跳过了前面几章也能直接看懂的独立教程。不依赖深度学习的进阶背景不需要你手写反向传播只需要有Python基础、能安装环境跟着一步步操作就能跑通从数据准备到模型推理的整个闭环。1. 起手式先想清楚这个微调项目要什么1.1 输入一条评论输出一个标签和一段理由先给“情感分析助手”一个明确的输入输出定义。比如我输入“手机用了三天就卡客服还一直推诿”我希望模型输出负面理由用户对手机性能不满意同时抱怨售后推诿整体体验较差。再比如输入“配送很快包装很严实”模型应该输出“正面理由用户认可配送速度和包装质量”。这里特意让模型输出“理由”而不是只输出一个标签。因为微调生成式模型的价值就在这里它不只是做一个分类而是能给出解释。这对业务场景很重要比如电商评论监控里运营人员希望快速知道“用户到底在抱怨什么”而不只是一个负面标记。如果你只想做标签分类传统的小模型方案效率更高根本不需要大模型。我们之所以选择用大模型微调来做就是看中了“可解释、可泛化、能适应复杂表达”的长处。1.2 为什么第一个项目要选它我几乎每次带新手入门都建议从这类任务开始原因有四个。第一数据好做。情感分析不需要领域专家参与标注。正负中三类的判断普通人一看就明白你可以在一小时之内手工造几十条质量不错的数据。第二效果直观。训练前后一对比立刻能看出模型有没有发生改变这种正反馈对建立信心非常重要。第三链路完整。从数据清洗、格式化、加载模型、配置LoRA、启动训练、加载checkpoint、写推理函数到算准确率、分析bad case微调项目的核心环节全都覆盖到了。第四成本可控。这类任务对模型参数量的要求不高一个1B到3B的中文底座模型在消费级显卡上就能跑通不用纠结算力不够。等你把这个项目从头到尾跑完再去看其他复杂微调任务至少在工程框架上不会发怵了。剩下的问题主要是数据质量和业务理解深度。1.3 技术选型小底座模型 LoRA 本地训练零基础最容易犯的错是一上来就打算全参数微调一个几十B的大模型。这不光需要大量算力对新手来说调试难度也很高。我的推荐方案是三板斧小底座模型、LoRA、本地训练。全参数微调的意思是把底座模型的全部参数都放到训练中梯度更新和显存占用都很夸张。LoRA则是冻结住原始模型的大部分参数只训练少量新增的低秩旁路参数。你可以这么理解全参数微调像把整本书重新抄一遍而LoRA像是给书里的重点章节加便签和索引书的内容没动只是多了几条轻量的标记通路。效果上LoRA未必输给全参数微调训练成本却低一个数量级零基础完全没必要绕开它去硬扛全参数微调。底座模型选哪家、选多大这里不点名某个具体产品只说判断标准选一个主流的中文开源底座的指令微调版本参数量在1B到3B之间最佳如果想挑战7B那就配合4bit量化使用。关键是要有完整的本地推理和微调支持而且你下载到的路径里要包含分词器文件和模型权重文件。不要选几十B的大家伙第一个项目没必要。训练框架直接用开源生态里常见的组合transformers负责模型与训练流程peft提供LoRA实现datasets处理数据accelerate负责分布式和混合精度。这些都是现成的轮子不需要自己造。1.4 硬件和环境准备显卡、CPU都能跑理论上一张显存8GB以上的消费级显卡训练1B到3B级别的底座模型就非常舒服了。显存12GB以上可以尝试7B级别加4bit量化。如果没有独立显卡纯CPU也能跑但速度很慢建议只用来验证流程、把数据量控制在20条以内。环境安装没什么花活创建一个干净的Python环境再安装核心依赖conda create -n sft python3.10 -y conda activate sft pip install torch transformers datasets peft accelerate如果打算做4bit量化训练再补一个量化相关依赖即可。版本上特别提醒一句torch和transformers的版本要匹配最好安装一套在当前时间点稳定的组合不要贪新也不要所有库都追最新版。装完后可以跑一句快速验证python -c import torch; print(torch.cuda.is_available())输出True说明GPU环境正常输出False就老老实实用CPU跑小规模Demo。2. 数据准备12条数据也能训练先把格式弄对2.1 明白大模型微调吃的“标准餐”微调数据最常用的组织格式是JSONL每行一个JSON对象。对指令微调任务来说每条样本通常包含三个字段instruction、input和output。举个例子{instruction: 判断下面文本的情感倾向输出正向、负向或中性并说明理由。, input: 手机用了三天就卡客服还一直推诿。, output: 负面。理由用户对手机性能不满意同时抱怨售后推诿整体体验较差。}模型训练时看到的是“指令输入标准答案”拼接后的完整文本学习的目标是让模型在看到同样指令时习惯性地输出接近标准答案的内容。所以output字段必须是一个完整自然的中文回答不能只写一个孤零零的标签也不能是机器腔太重的模板句。2.2 手写一份最小可用的情感数据集第一版不需要追求量大。我带你构造12条数据覆盖正、负、中三个类别每个类别4条。领域上故意混合手机、外卖、耳机、酒店、电影、快递这样才能让模型学到的不是一个领域的特化表达。类别输入输出负面手机用了三天就卡客服还一直推诿负面。理由用户对手机性能不满意同时抱怨售后推诿整体体验较差。负面外卖送到时汤全洒了骑车小哥还让我自己联系商家负面。理由配送过程导致餐品损坏且责任转移给用户体验糟糕。负面酒店房间隔音特别差凌晨还能听到走廊脚步声负面。理由隔音问题直接影响休息质量用户给出差评。负面蓝牙耳机用了两周就单侧无声申请售后还要自费寄回负面。理由产品质量不稳定且售后流程不合理。正面配送很快包装很严实拆开一点磕碰都没有正面。理由用户认可配送速度和包装质量。正面这家餐厅的牛肉面汤底很浓面条劲道值得再来正面。理由用户对菜品口味给予好评并愿意复购。正面客服响应特别及时半夜提问也有人在十分钟内回复正面。理由客服响应用及时让用户感到安心。正面电影节奏紧凑反转不突兀全程没有玩手机正面。理由剧情引人入胜用户观影体验良好。中性这家店的营业时间是早上九点到晚上六点中性。理由只是客观陈述营业时间没有情感倾向。中性手机包装盒里附赠了一条充电线中性。理由陈述配件情况不带评价色彩。中性快递预计明天送达具体要看当地天气中性。理由信息类表述无明显正面或负面态度。中性酒店离地铁站步行大约十分钟中性。理由陈述地理位置不含主观评价。构造数据时留意三个细节一是标签数量平衡别让负面占一大半二是理由的句式要多样避免每一条都说“用户对……不满意”否则模型会把理由写成复读机三是训练时别只挑很极端的表达适当放一些需要推理才能判断的句子比如“价格不便宜但品质确实值了”这种混合倾向或者带转折的句子。2.3 数据清洗与自检训练前多花5分钟数据文件准备好之后我强烈建议先跑一个自检脚本而不是直接丢给训练程序。脚本做三件事检查字段完整性、统计标签分布、打印拼接后的训练文本。import json samples [] with open(emotion_data.jsonl, r, encodingutf-8) as f: for line in f: line line.strip() if not line: continue obj json.loads(line) assert {instruction, input, output} set(obj.keys()), 字段缺失 samples.append(obj) from collections import Counter labels [] for s in samples: label s[output].split(。)[0].replace(负面, 负面).replace(正面, 正面).replace(中性, 中性) labels.append(label) print(Counter(labels)) def build_prompt(instruction: str, input_text: str) - str: return f【任务】{instruction}\n【文本】{input_text}\n【分析】 print(build_prompt(samples[0][instruction], samples[0][input]) samples[0][output])这里的build_prompt函数是整个项目的关键。训练时怎么拼接prompt推理时就要一模一样地拼接一个词都不能差。我在后面的章节还会反复提这件事因为这是新手最容易翻车的地方没有之一。3. 训练脚本拆解手把手把第一个微调跑起来3.1 加载模型与分词器先把“骨架”放到显存里训练脚本的第一步是加载底座模型和分词器。这里用一个占位路径实际使用时替换成你本地下载好的模型目录。import torch from transformers import AutoTokenizer, AutoModelForCausalLM base_model_path ./your_base_model tokenizer AutoTokenizer.from_pretrained(base_model_path, trust_remote_codeTrue) if tokenizer.pad_token is None: tokenizer.pad_token tokenizer.eos_token model AutoModelForCausalLM.from_pretrained( base_model_path, torch_dtypetorch.bfloat16, device_mapauto )有两个技术上必须做的事要说明。第一给tokenizer设置pad_token。因为训练时一个batch内样本长度不同需要padding对齐到相同长度。如果pad_token为空批量训练直接报错。这里通常用eos_token充当pad_token计算loss时会忽略掉padding部分不会引入额外噪声。第二模型加载时用bfloat16精度能在几乎不掉点的前提下大幅降低显存占用。如果你的显卡比较老不支持bfloat16可以退一步用float16。设备映射部分device_mapauto的意思是框架自动判断模型放哪张卡单卡环境下就是全部放到GPU。加载完成后建议打印一下模型参数量确认本地文件没问题total sum(p.numel() for p in model.parameters()) print(f模型总参数量: {total / 1e9:.2f}B)3.2 配置LoRA和训练参数懂参数比懂代码更重要主体模型加载完成后就是给模型套上LoRA配置。下面这个配置是我在情感分析这类任务上的常用起点from peft import LoraConfig, get_peft_model, TaskType lora_config LoraConfig( r8, lora_alpha16, lora_dropout0.05, target_modules[ q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj ], task_typeTaskType.CAUSAL_LM, biasnone, ) model get_peft_model(model, lora_config) model.print_trainable_parameters()这几个参数的含义要搞清楚因为后面调优全靠它们参数作用调整倾向r低秩矩阵的秩控制新增参数规模r越大表达能力越强但过大会导致过拟合和显存上涨8是一个稳妥起点lora_alpha缩放系数影响LoRA模块的更新幅度通常设为r的2倍左右和r保持相对关系lora_dropout防止LoRA旁路过拟合的随机丢弃比例数据量少时可以适当调大比如0.1target_modules要对哪些模块施加LoRA覆盖注意力与前馈网络的核心矩阵均衡性好用我这次贴的target_modules列表等于把模型的大部分线性投影层都加了LoRA。代价是训练参数量会稍微多一些但对1B到3B的小模型来说无关痛痒。如果是性能焦虑可以只保留q_proj和v_proj效果会略降但显存压力更小。接下来是训练参数。这部分我用的是零基础也能安全的配置from transformers import TrainingArguments training_args TrainingArguments( output_dir./sft_emotion_ckpt, per_device_train_batch_size4, gradient_accumulation_steps8, learning_rate2e-4, num_train_epochs3, lr_scheduler_typecosine, warmup_ratio0.03, logging_steps10, save_strategysteps, save_steps50, eval_strategysteps, eval_steps50, bf16True, weight_decay0.01, )对每个关键参数我解释一下为什么这么设。学习率为什么是2e-4而不是更小的1e-5因为LoRA只更新很小一部分新增参数它的大多数权重仍然被冻结因此可以用比全参数微调更大一些的学习率。全参数微调常用1e-5到5e-5LoRA则常见2e-4。这个数值不需要从一个很夸张的值开始2e-4已经是很安全的起点。如果训练中loss震荡厉害可以降低到1e-4。梯度累积为什么是8单卡batch_size设4显存够用但4这个数值太小会导致梯度更新方向不稳定。gradient_accumulation_steps8表示每8个小batch才真正更新一次权重等效batch size是4×832。这个等效值对大多数微调任务是一个均衡选择。轮数为什么是3情感分析数据量小3轮足够让模型学到格式和分类逻辑再多容易过拟合。如果你数据量只有十几条甚至2轮就够了。3.3 数据Tokenizer与Trainer把数据集送进模型数据加载部分先把JSONL读进来转成datasets的Dataset对象然后做训练集和验证集划分。最关键的是tokenize函数它决定模型到底学什么。from datasets import Dataset with open(emotion_data.jsonl, r, encodingutf-8) as f: samples [json.loads(line) for line in f if line.strip()] dataset Dataset.from_list(samples) dataset dataset.train_test_split(test_size0.1, seed42) train_ds, eval_ds dataset[train], dataset[test] def tokenize_func(data): prompt build_prompt(data[instruction], data[input]) answer data[output] text prompt answer model_inputs tokenizer(text, max_length512, truncationTrue) input_ids model_inputs[input_ids] labels input_ids.copy() prompt_ids tokenizer(prompt, add_special_tokensFalse, max_length512, truncationTrue)[input_ids] labels[:len(prompt_ids)] [-100] * len(prompt_ids) model_inputs[labels] labels return model_inputs tokenized_train train_ds.map(tokenize_func, remove_columnstrain_ds.column_names) tokenized_eval eval_ds.map(tokenize_func, remove_columnseval_ds.column_names)这里的核心思路是模型输入的完整文本是“prompt answer”但计算loss时只对answer部分计算prompt部分全部被mask成-100。这么做的原因是我们想让模型学会的是“如何生成对问题的回答”而不是“把用户输入重新背一遍”。如果不做这个mask训练目标变成了让模型逐字预测整段文本模型很容易学到复述输入的坏习惯推理时看起来就像“答非所问还废话连篇”。Tokenizer拼接的细节也值得留意。中文tokenizer有时prompt和answer会被合并切分到同一个token导致按token数切分边界不够精确。对零基础项目来说这个误差通常在可接受范围内先跑通整个流程更重要。后面如果要做更严格的长文本任务再引return_offsets_mapping等机制去精确对齐。然后定义Trainer开始训练from transformers import Trainer, DataCollatorForSeq2Seq trainer Trainer( modelmodel, argstraining_args, train_datasettokenized_train, eval_datasettokenized_eval, tokenizertokenizer, data_collatorDataCollatorForSeq2Seq(tokenizer, paddingTrue), ) trainer.train() trainer.save_model(./sft_emotion_final)DataCollatorForSeq2Seq的作用是自动把一批样本填充到相同长度并生成attention_mask。运行训练后日志会持续输出loss{loss: 2.31, learning_rate: 1.8e-4, epoch: 0.2} {loss: 0.85, learning_rate: 8.5e-5, epoch: 1.4} {loss: 0.38, learning_rate: 1.2e-5, epoch: 2.7}loss从2点多一路往下走最终稳定在0.3到0.5之间说明模型在正常学习。如果loss完全纹丝不动请直接跳到第5章排查。3.4 启动训练前先确认这些细节在真正开始跑训练之前有三个细节必须要确认否则很容易挫伤自信心。第一确认你的训练代码里只训练LoRA参数。可以在trainer.train()之前加一句模型打印model.print_trainable_parameters()它会输出类似“trainable params: 4M || all params: 1.2B || trainable%: 0.33”这样的信息。如果可训练参数占比是0%说明LoRA配置没有生效如果占比是100%说明你忘了加get_peft_model变成了全参数微调显存分分钟爆掉。第二确认数据量别被验证集切没。总共12条数据test_size0.1会切出1到2条验证集训练集只剩下10到11条。这没关系目的只是为了跑通链路。等后面数据量加到几百条时验证集比例可以设在0.05到0.1之间。第三训练脚本要保存好prompt模板。建议把build_prompt函数单独放到一个util.py文件里训练和推理共用而不要在训练脚本和推理脚本里各自复制一份。复制粘贴一时爽模板分叉火葬场。推理时如果模板跟训练时不一致再好的权重也白搭。4. 推理和验证让情感分析助手说出判断理由4.1 加载训练好的LoRA适配器训练完成后output_dir下会保存checkpoint包括模型权重和适配器配置。推理时需要先加载底座模型再把LoRA适配器load进来from peft import PeftModel base_model AutoModelForCausalLM.from_pretrained( base_model_path, torch_dtypetorch.bfloat16, device_mapauto ) model PeftModel.from_pretrained(base_model, ./sft_emotion_ckpt/checkpoint-150) model model.merge_and_unload() model.eval()merge_and_unload会把LoRA权重合并回底座模型。合并之后模型从结构上变回一个普通模型推理速度更快也方便导出。如果不合并也可以但不合并时推理多一层适配器调用速度略慢。要注意的是merge操作只影响当前内存里的模型不会动你磁盘上的checkpoint所以想回滚随时可以重建。4.2 一个直接能用的推理函数写一个封装好的推理函数避免每次手动拼promptdef predict(text: str): prompt build_prompt( 判断下面文本的情感倾向输出正向、负向或中性并说明理由。, text ) inputs tokenizer(prompt, return_tensorspt).to(model.device) outputs model.generate( **inputs, max_new_tokens128, do_sampleFalse, temperature1.0, ) response tokenizer.decode(outputs[0][inputs[input_ids].shape[1]:], skip_special_tokensTrue) return response这里的do_sampleFalse是关键。评估场景下我们不需要随机性贪婪解码能让输出稳定可复现。max_new_tokens128对情感分析任务足够理由说得太长反而不好。测试几个例子tests [ 快递到了但箱子被压扁了里面的东西倒没坏。, 这支笔写起来很顺滑但用两天就断墨了。, 电影票已经出票了座位号在短信里。, ] for text in tests: print(文本, text) print(结果, predict(text)) print()第一个例子是混合倾向句子注明了“东西没坏”但用户开头强调的是箱子被压扁模型应该判断为负面或偏中性。第二个例子是优点加缺点的组合模型要识别出整体体验并不好。第三个例子是事实陈述应判中性。你用训练数据里的句子测试时模型输出会跟标注非常接近这是正常的因为那些句子它已经背下来了。真正判断效果要看这些没见过的句子。4.3 用数据说话准确率和bad case单看几个例子不够做一个简单评估脚本准备20条带着标准标签的测试样本批量调用predict再做规则判断输出文本中是否出现了“正面”“负面”“中性”标签词跟标准答案比对。labels [] preds [] for sample in test_data: resp predict(sample[input]) label resp.split(。)[0].strip() preds.append(label) labels.append(sample[label]) correct sum(a b for a, b in zip(labels, preds)) print(f准确率: {correct / len(test_data):.2%})准确率只是一个粗糙的指标因为标签词出现的位置不一定固定模型可能把“理由”部分放在前面。所以我更推荐你在算完准确率之后把所有bad case打印出来逐个看。所谓bad case就是模型判断错误的样本。看多了你会发现错误往往不是模型“不会判断情感”而是以下几种典型情况输入里有明显的转折结构模型忽略了后半句的否定。输入是问句或陈述句情感依上下文而定模型默认按负面处理。训练数据里同类表达太少模型没见过类似的措辞。理由写得通顺但标签给错了或者标签对了但理由逻辑不对。这种人工分析比数字更能指导下一步优化要么补数据要么调prompt要么调整标签粒度。5. 踩坑记录零基础最容易在哪儿翻车5.1 显存不够怎么救训练报错最常见的就是CUDA out of memory。不用慌按优先级逐步处理。第一减小per_device_train_batch_size从4改成2。第二减小max_length512改成256。绝大多数情感分析文本根本不到256个token过长限制只是给padding浪费显存的机会。第三如果前两步都不行考虑换更小的底座模型或者给模型做4bit量化。第四确认你只训练了LoRA参数没变成全参数微调。还有一个容易被忽略的点batch内样本长度差异过大时padding会补齐到最长序列造成大量浪费。短文本任务里max_length设置合理能直接解决这个问题。5.2 损失不下降的排错顺序如果loss卡在某个数值附近不动按顺序检查。先检查数据拼接。模型是否真的能看到标准答案很多人写tokenize函数时只把prompt放进去没拼answer模型训练目标变成预测空白loss当然不降。再检查学习率。2e-4是LoRA的稳妥值但如果设成1e-6训练几百步也未必能降多少。反过来设成1e-3loss可能疯狂震荡。找到合适区间后固定住。接着检查prompt模板。模板里有没有额外的换行、分隔符差异一个多余的“”都可能影响学习效果不过这个因素通常只影响微调质量的细微差别不会导致完全不学习。最后用下面这段代码确认可训练参数for name, param in model.named_parameters(): if param.requires_grad: print(name)如果输出只有少量且名字里带lora说明LoRA生效。如果输出里面有大量embedding、lm_head这类名字说明训练范围失控回看第3.2节。5.3 模型变成“复读机”了怎么办训练好的模型拿到新输入后不管问什么都输出同一句话或者把输入倒回去。最常见的原因是推理参数设置不对do_sampleTrue且temperature过高或者max_new_tokens太小导致回答被截断。先切回do_sampleFalse试一下。如果还是复读检查prompt模板是否和训练时一致模板不匹配的典型表现就是模型乱接上下文。还有一种隐蔽情况是训练数据里answer部分长度很短模型只学会了输出“负面”两个字其它全被当作噪声忽略掉。解决办法是在构造数据时让理由部分内容丰富一些句式多样一些模型的表达能力才会被调动起来。5.4 训练后模型“变笨”了一个1B的小底座原本能回答常识问题微调后反而连加减法都不会了。这确实发生了原因在于微调数据太单一模型把大量权重资源往情感分析方向倾斜覆盖了通用能力。要缓解这件事记住几个经验值r值不要求大8就够了。target_modules不要每次都全部覆盖可以先试q_proj和v_proj。训练数据里适当混入少量通用对话样本能显著降低灾难性遗忘。评估时除了看业务准确率也留几条常识题做通用能力抽检。这些都不是玄学核心逻辑是控制“模型改动幅度”。LoRA本质上是给模型加旁路旁路权重越强大对原模型输出行为的覆盖就越严重。小任务用大旁路就像小水管接了消防水龙头很容易冲坏原有结构。最后分享一个我特别推荐的工作习惯。每次跑微调项目先写一个before.txt把测试集里的文本在原始底座上的输出保存下来。训练完成后再跑一轮生成after.txt。两个文件放在一起对比模型到底学会了什么、丢掉了什么、有没有产生诡异的偏好都一目了然。我第一次把情感分析助手跑通时数据只有二三十条效果谈不上惊艳但就是通过这种前后对比确切看到了模型从“不会按格式回答”到“能输出标签和理由”的变化那一刻我才真正觉得微调不再是一个抽象的概念而是一条自己能够完整掌控的流水线。希望这篇教程也能帮你迈过那道坎把第一个微调项目稳稳落地。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
