1. 微调之后，为什么“感觉变好了”最不靠谱
你拿 LLaMA-Factory 跑完一轮 LoRA，loss 曲线漂亮得像教科书，推理几条样例也像模像样，于是心里默认“这波稳了”。可一旦把模型丢进真实业务流量，问题立刻现形：该引用条款的地方开始编造，该输出 JSON 的地方夹带解释性文字，多轮对话到第三轮就忘了用户前面说过的约束。这不是模型没学会，而是你根本没有一套能证伪“它变聪明了”的评估链路。
大模型微调后的能力验证，本质是一个对照实验问题。你需要回答三件事：微调后的模型相比基座模型，在哪些任务上确实提升了；提升幅度是否稳定，而不是靠某几条样例的运气；有没有在没训练过的任务上出现能力回退。LLaMA-Factory 负责把模型训出来，OpenCompass 负责把“聪明”翻译成可复现的分数，中间缺的那一环，就是评测集选择、指标解读和结果对比的方法论。
这套流程适合三类人：刚用 LLaMA-Factory 跑通第一个 LoRA 的算法同学，需要向业务方证明微调价值的工程同学，以及准备把模型接入生产、必须做上线前质量门禁的团队。下面我按“准备评测环境 → 配置 OpenCompass → 跑通验证请求 → 解读结果 → 排查常见错”的顺序，把可复制的骨架交给你。
2. 前置准备：把 LLaMA-Factory 产物接进 OpenCompass
2.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 python=3.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( type=HuggingFacewithChatTemplate, abbr='llama3-8b-lora-merged', path='outputs/llama3-8b-lora-merged/', max_out_len=1024, batch_size=8, run_cfg=dict(num_gpus=1), ), dict( type=OpenAI, abbr='baseline-api', path='gpt-4o-mini', key='YOUR_TAOTOKEN_API_KEY', openai_api_base='https://taotoken.net/api', max_out_len=1024, batch_size=4, ), ]注意path字段在 OpenAI 类型里填的是模型名，openai_api_base指向 TaoToken 的 API 地址。这样你就能在同一份报告里看到微调模型和基线的分数差异。
3.2 数据集配置：通用能力与业务能力分开
from opencompass.datasets import CEvalDataset, GSM8KDataset datasets = [ dict( type=CEvalDataset, abbr='ceval', path='opencompass/ceval', name='ceval', reader_cfg=dict(input_columns=['question'], output_column='answer'), infer_cfg=dict( prompt_template=dict( type='PromptTemplate', template=dict(round=[ dict(role='HUMAN', prompt='{question}\n答案：'), ]), ), retriever=dict(type='ZeroRetriever'), inferencer=dict(type='GenInferencer'), ), eval_cfg=dict( evaluator=dict(type='AccEvaluator'), ), ), ]业务私有评测集可以写成自定义 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_map='auto') prompt = '判断以下用户反馈属于哪类：咨询/投诉/建议。反馈：你们这个功能怎么又崩了？' inputs = tokenizer(prompt, return_tensors='pt').to(model.device) outputs = model.generate(**inputs, max_new_tokens=64) print(tokenizer.decode(outputs[0], skip_special_tokens=True))如果输出是“投诉”，说明模型加载和推理链路正常。如果输出乱码或重复，先检查 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 模型对话，适合快速验证单条样例。评估链路跑顺之后，你会发现“变聪明”不再是一种感觉，而是一组可复现、可对比、可归档的数字。
