1. 微调之后为什么“感觉变好了”最不靠谱你拿 LLaMA-Factory 跑完一轮 LoRAloss 曲线漂亮得像教科书推理几条样例也像模像样于是心里默认“这波稳了”。可一旦把模型丢进真实业务流量问题立刻现形该引用条款的地方开始编造该输出 JSON 的地方夹带解释性文字多轮对话到第三轮就忘了用户前面说过的约束。这不是模型没学会而是你根本没有一套能证伪“它变聪明了”的评估链路。大模型微调后的能力验证本质是一个对照实验问题。你需要回答三件事微调后的模型相比基座模型在哪些任务上确实提升了提升幅度是否稳定而不是靠某几条样例的运气有没有在没训练过的任务上出现能力回退。LLaMA-Factory 负责把模型训出来OpenCompass 负责把“聪明”翻译成可复现的分数中间缺的那一环就是评测集选择、指标解读和结果对比的方法论。这套流程适合三类人刚用 LLaMA-Factory 跑通第一个 LoRA 的算法同学需要向业务方证明微调价值的工程同学以及准备把模型接入生产、必须做上线前质量门禁的团队。下面我按“准备评测环境 → 配置 OpenCompass → 跑通验证请求 → 解读结果 → 排查常见错”的顺序把可复制的骨架交给你。2. 前置准备把 LLaMA-Factory 产物接进 OpenCompass2.1 确认微调产物的两种形态LLaMA-Factory 训练结束后产物通常有两种一种是合并后的完整权重目录里直接有config.json、model.safetensors另一种是 LoRA adapter只有adapter_model.safetensors和adapter_config.json需要和基座模型配合加载。OpenCompass 对这两种形态都支持但配置写法不同。合并权重最省事adapter 方式更省显存你可以按部署方式选。先确认目录结构合并权重长这样ls outputs/llama3-8b-lora-merged/ # config.json generation_config.json model.safetensors tokenizer.json tokenizer_config.jsonadapter 产物则是ls outputs/llama3-8b-lora/ # adapter_config.json adapter_model.safetensors README.md2.2 安装 OpenCompass 与推理后端OpenCompass 本身是评测调度框架真正跑推理要靠后端。最轻量的组合是 OpenCompass HuggingFace 后端适合单卡或双卡验证如果模型较大可以换成 vLLM 后端提升吞吐。安装命令如下conda create -n opencompass python3.10 -y conda activate opencompass pip install opencompass pip install torch transformers accelerate如果你打算用 API 方式评测比如把模型部署成 OpenAI 兼容接口再让 OpenCompass 调用那还需要一个稳定的 API 入口。TaoToken 的 API 地址是https://taotoken.net/api兼容 OpenAI 协议可以在 OpenCompass 里作为openai类型后端接入适合做基线模型对比。API Key 在控制台创建入口在 TaoToken API Keys。2.3 准备评测集别拿训练集当考题评测集必须和训练集零重叠这是底线。实操上分三步先从业务原始数据里预留 10% 到 20%训练前就切分好并锁死再针对核心场景人工构造边缘 case比如空输入、超长输入、多约束指令最后可以用强模型批量生成一批候选问题但必须人工审核修正不能直接信。OpenCompass 内置了大量公开数据集比如ceval、gsm8k、humaneval适合验证通用能力是否回退。但业务能力必须用你自己的私有评测集格式推荐 JSONL每行一个样本{question: 根据以下合同条款判断违约责任方, answer: 甲方} {question: 把这段用户反馈归类为咨询/投诉/建议, answer: 投诉}3. 可复制配置OpenCompass 评测骨架3.1 模型配置本地权重与 API 基线并列OpenCompass 的配置是一个 Python 文件核心是models和datasets两部分。下面这份配置同时挂载了微调后的本地模型和一个 API 基线方便横向对比from opencompass.models import HuggingFacewithChatTemplate, OpenAI models [ dict( typeHuggingFacewithChatTemplate, abbrllama3-8b-lora-merged, pathoutputs/llama3-8b-lora-merged/, max_out_len1024, batch_size8, run_cfgdict(num_gpus1), ), dict( typeOpenAI, abbrbaseline-api, pathgpt-4o-mini, keyYOUR_TAOTOKEN_API_KEY, openai_api_basehttps://taotoken.net/api, max_out_len1024, batch_size4, ), ]注意path字段在 OpenAI 类型里填的是模型名openai_api_base指向 TaoToken 的 API 地址。这样你就能在同一份报告里看到微调模型和基线的分数差异。3.2 数据集配置通用能力与业务能力分开from opencompass.datasets import CEvalDataset, GSM8KDataset datasets [ dict( typeCEvalDataset, abbrceval, pathopencompass/ceval, nameceval, reader_cfgdict(input_columns[question], output_columnanswer), infer_cfgdict( prompt_templatedict( typePromptTemplate, templatedict(round[ dict(roleHUMAN, prompt{question}\n答案), ]), ), retrieverdict(typeZeroRetriever), inferencerdict(typeGenInferencer), ), eval_cfgdict( evaluatordict(typeAccEvaluator), ), ), ]业务私有评测集可以写成自定义 dataset或者先用CustomDataset加载 JSONL再配AccEvaluator或SubjectiveEvaluator。通用集看回退业务集看提升两者缺一不可。3.3 运行评测python run.py configs/eval_llama3_lora.py --work-dir outputs/eval_results跑完后outputs/eval_results下会生成summary目录里面有 CSV 和 Markdown 报告每个数据集一行每个模型一列直接对比。4. 验证请求确认评测链路真的跑通了4.1 先用单条推理验证模型加载在跑全量评测前先确认模型能正常加载和推理避免跑了几小时才发现权重路径写错。用 HuggingFace 直接加载from transformers import AutoModelForCausalLM, AutoTokenizer model_path outputs/llama3-8b-lora-merged/ tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModelForCausalLM.from_pretrained(model_path, device_mapauto) prompt 判断以下用户反馈属于哪类咨询/投诉/建议。反馈你们这个功能怎么又崩了 inputs tokenizer(prompt, return_tensorspt).to(model.device) outputs model.generate(**inputs, max_new_tokens64) print(tokenizer.decode(outputs[0], skip_special_tokensTrue))如果输出是“投诉”说明模型加载和推理链路正常。如果输出乱码或重复先检查 tokenizer 是否和基座一致。4.2 用 API 方式验证基线对比如果你用 TaoToken 作为基线可以先单独发一条请求确认连通curl https://taotoken.net/api/chat/completions \ -H Authorization: Bearer YOUR_TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4o-mini, messages: [{role: user, content: 判断以下用户反馈属于哪类咨询/投诉/建议。反馈你们这个功能怎么又崩了}] }返回正常后再把它写进 OpenCompass 配置。这样评测报告里就有“微调模型 vs 强基线”的对照而不是自己和自己比。4.3 成功结果的形态一次成功的评测报告里应该能看到微调模型在业务私有集上的准确率显著高于基座模型比如从 62% 提升到 81%在通用集ceval上没有明显回退波动在 1 到 2 个百分点以内在gsm8k这类推理集上如果下降超过 5 个百分点就要警惕灾难性遗忘。这些数字才是“变聪明”的证据。5. 本篇常见错排查5.1 评测分数异常高接近满分大概率是评测集和训练集重叠了。检查方法把评测集的问题逐条和训练集做文本相似度比对超过 0.9 的样本直接剔除。另一个可能是 prompt 模板和训练时不一致导致模型“背题”。LLaMA-Factory 训练时的 template 要和 OpenCompass 推理时的 template 对齐比如训练用alpaca评测也要用alpaca。5.2 模型输出全是重复或空先看max_out_len是否太小生成被截断。再看 tokenizer 是否加载错adapter 模型必须用基座的 tokenizer。如果是 vLLM 后端检查tensor_parallel_size是否超过实际 GPU 数。还有一种情况是 chat template 没生效模型把整段 prompt 当普通文本续写输出自然不对。5.3 API 基线报 401 或超时401 通常是 Key 写错或没带Bearer前缀。超时先检查网络再确认openai_api_base是否写成了https://taotoken.net/api不要多加/v1或漏掉协议头。批量评测时把batch_size调小避免触发限流。如果持续失败去 TaoToken 接入文档 核对参数格式。5.4 通用能力回退严重LoRA 微调如果 rank 太大、训练轮数太多容易把基座能力覆盖掉。排查方法把 LoRA 权重关掉只跑基座模型对比同一套评测集。如果基座分数正常说明是微调过度。解决方向是降低学习率、减少 epoch、或者混入一部分通用指令数据。评估的意义就在这里它让你在模型上线前就发现回退而不是等用户投诉。6. 把评估变成上线前的固定动作微调不是一锤子买卖评估也不该是一次性脚本。你可以把 OpenCompass 配置和评测集一起放进代码仓库每次训练产出新权重就自动跑一遍把报告归档。业务私有集的分数作为主指标通用集分数作为回退监控指标API 基线作为外部参照。三者都达标才允许进入下一轮人工盲测。如果你还在用零散脚本手动对比模型输出建议先把 OpenCompass 的配置骨架跑通再逐步替换成自己的业务评测集。需要长期做编码类或 Agent 类微调验证的可以了解 TaoToken Coding Plan把模型对话和 API 调用统一到一个入口评测和日常调试共用一套 Key省去反复切换的麻烦。模型对话入口在 TaoToken 模型对话适合快速验证单条样例。评估链路跑顺之后你会发现“变聪明”不再是一种感觉而是一组可复现、可对比、可归档的数字。