AI Radar
Theme
Color
June 27, 2026 评论

一个 7B 业务模型微调实践

大模型微调LoRAQLoRALLaMA-Factory业务场景模型

很多企业开始做大模型应用时，第一反应是：“要不要训练一个自己的模型？”多数情况下，并不需要从零训练一个通用大模型。更现实的做法，是把已有开源基座模型调成一个更稳定、更符合业务口径的场景模型。

本文用一个 7B 级别开源指令模型举例，说明业务场景微调到底在做什么，适合放在研发链路的哪个位置，以及如何用 LLaMA-Factory 跑通一轮可复现的 LoRA/QLoRA。

这里讨论的是业务后训练，不是从零预训练。示例场景是脱敏后的企业评估任务，所有数据、模型名称和路径都只是示意，不对应真实业务项目。

微调不是重新训练一个 ChatGPT

通用大模型在预训练阶段已经学到了语言、知识、代码和推理模式。业务微调通常不是重新创造这些能力，而是让模型在指定场景里更稳定地做一类任务。

对企业评估类模型来说，微调更像是在训练模型形成一组稳定习惯：

目标含义
任务形态看到企业资料后，知道要做风险归纳、证据说明和尽调建议
输出格式能稳定输出摘要、风险点、证据边界、后续问题等固定结构
业务口径使用审慎、可复核、不过度下结论的表达方式
边界意识对未提供、未验证、非公开的信息不编造
评测适配面对不同问法时，仍能保持格式和边界稳定

如果把大模型看成一个已经具备通用能力的分析助手，微调更像岗前培训：让它按这个岗位的规范写，而不是重新培养一个人。

微调在研发链路中的位置

大模型研发通常不是一个单独训练任务，而是一条工程链路。

flowchart LR
  A[需求定义] --> B[数据工程]
  B --> C[基座模型选择]
  C --> D[继续预训练/CPT]
  D --> E[SFT 微调]
  E --> F[评测]
  F --> G[部署优化]
  G --> H[反馈闭环]

其中，预训练、继续预训练和微调解决的问题并不相同。

阶段主要目标常见数据是否直接学习业务回答
预训练学习通用语言、知识和推理模式网页、书籍、论文、代码、大规模文本否
继续预训练熟悉特定领域语料分布行业报告、制度文件、公告、长文本资料通常否
SFT 微调学习业务任务、输出格式和回答口径instruction + input + output 样本是
偏好/边界训练学习更偏好的答案和不可答边界偏好对、拒答样本、失败样本是
flowchart TD
  A[预训练<br/>学习通用语言和知识] --> B[继续预训练<br/>熟悉领域语料分布]
  B --> C[SFT 微调<br/>学习业务任务和输出方式]
  C --> D[偏好/边界训练<br/>学习什么该答和怎么答]

如果目标是让模型熟悉大量制度文件、年报文本和行业术语，继续预训练可能有价值。如果目标是让模型按固定格式输出企业风险初筛报告，SFT 往往更直接。

微调适合解决什么

业务微调解决的是“模型怎么完成任务”，不是“系统如何拥有所有事实”。

适合用微调解决不适合只靠微调解决
固定报告结构实时事实查询
风险线索归纳方式数据库权限控制
证据边界表达企业最新经营状态同步
多种问法下的口径一致性审批流和审计留痕
常见错误回答修复凭空补足缺失材料
可答/不可答样式训练替代正式授信决策

在企业评估场景里，模型可以根据已提供材料生成初筛意见、列出风险线索、提示证据缺口，也可以生成后续尽调问题。但它不应该在没有材料的情况下编造财务断裂风险、真实授信额度、担保关系或最终审批结论。

示例场景：金融信贷风控企业评估

这里用一个抽象的企业评估场景。假设我们要做一个评估助手，帮助业务人员基于公开资料和内部授权材料生成初筛分析。

输入可能包括：

数据类型示例
企业基本信息注册资本、成立年限、行业分类、经营范围
经营摘要营收趋势、利润趋势、现金流摘要
信用线索逾期记录、诉讼记录、行政处罚、负面舆情
交易记录采购、销售、回款、合同履约摘要
行业信息行业周期、价格波动、政策变化
人工补充客户经理备注、尽调访谈摘要

期望输出不是“是否放款”的最终结论，而是类似这样的辅助分析：

输出部分作用
企业概况摘要压缩输入资料，形成可读摘要
主要风险线索归纳现金流、诉讼、行业、履约等风险点
正向支撑因素说明经营稳定性、客户结构、历史履约等有利信息
证据边界明确哪些结论仅基于已提供材料
尽调问题生成后续需要人工核验的问题清单

这类模型的价值不是替代审核人员，而是把大量材料整理成结构化、可复核、便于继续审查的初筛文本。

为什么从 7B 模型开始

7B 不是能力最强的参数规模，但很适合做业务验证的起点。

维度7B 模型的优势
训练成本可用 4-bit QLoRA 在较低显存下训练
迭代速度数据、参数和评测调整的反馈周期更短
部署成本推理显存和并发压力相对可控
工程风险比更大模型更容易定位训练和部署问题
业务验证足以验证数据设计、任务形态和评测体系

对多数垂直业务场景，第一阶段的问题往往不是模型参数不够大，而是任务定义不清、样本不稳、评测指标不贴近业务。先用 7B 模型把数据闭环和评测方法跑通，通常比直接上更大模型更稳。

硬件与训练环境

本文讨论的训练资源是 7B 级别开源基座模型的业务微调环境，不是从零预训练环境。

项目示例配置
GPU2 x NVIDIA RTX 3090
单卡显存24GB
CPU常规多核服务器 CPU
内存建议 128GB 以上
CUDACUDA 12.x
训练框架LLaMA-Factory
训练方式4-bit QLoRA + LoRA adapter
基座模型7B 级别开源指令模型
典型任务SFT 指令微调、格式学习、边界表达修复

在这类资源配置下，7B 模型的 4-bit QLoRA 微调是可行的。它适合业务场景验证、分阶段 SFT、失败样本修复和小规模迭代，不适合承担大规模预训练。

不同训练方式对资源的压力差异很大：

训练方式资源压力适用场景
全参数微调高预算充足且需要整体更新模型参数
LoRA中保留基座能力，只训练少量 adapter 参数
QLoRA较低显存有限时微调 7B/14B 级模型
继续预训练中到高需要模型熟悉大量领域文本分布
SFT 指令微调中学习业务任务、输出格式和回答边界

硬件能跑通训练，不代表模型能直接上线。能不能用，还是取决于数据质量、评测集设计、失败样本修复和上线后的反馈闭环。

数据设计比参数更关键

业务微调最容易被低估的是数据设计。模型学到的不是“金融风控”四个字，而是样本里反复出现的任务结构、表达方式和边界习惯。

一条典型 SFT 样本可以写成 Alpaca 风格：

{
  "instruction": "请根据以下公开资料生成企业信贷风险初筛报告。",
  "input": {
    "企业名称": "示例科技有限公司",
    "成立年限": "8 年",
    "近三年营收趋势": "连续增长",
    "现金流情况": "经营现金流波动较大",
    "诉讼记录": "存在 2 条合同纠纷",
    "行业": "制造业"
  },
  "output": "该企业具备一定经营稳定性，近三年营收连续增长是正向因素。但经营现金流波动较大，且存在合同纠纷记录，建议进一步核验回款周期、主要客户集中度、涉诉金额和合同履约情况。以上判断仅基于已提供资料，不能替代正式授信审批。"
}

这里模型学的不是“示例科技有限公司真实风险如何”，而是看到这类材料时，如何组织分析、如何表达不确定性、如何提示人工复核。

微调数据通常需要覆盖几类样本：

样本类型作用
标准任务样本学习正常企业评估报告写法
风险线索样本学习如何归纳现金流、诉讼、行业和履约风险
证据缺口样本学习资料不足时如何说明边界
格式约束样本学习 JSON、表格、短答等固定输出
反例修复样本修复编造、过度结论、格式不稳定等问题
验证集样本用于观察泛化，而不是继续训练

如果训练集只有“完美输入”和“完美输出”，模型很容易在真实问题里失控。业务样本必须包含资料缺失、问题模糊、字段冲突、无法判断和需要人工复核的情况。

7B 微调路线

稳妥的业务微调通常不是一次训练完，而是分阶段迭代。

flowchart LR
  S1[Stage 1<br/>任务形态] --> S2[Stage 2<br/>风险归因]
  S2 --> S3[Stage 3<br/>格式稳定]
  S3 --> S4[Stage 4<br/>失败样本修复]
  S4 --> E[业务评测]

可以把 7B 微调拆成四个阶段：

阶段目标数据重点验证重点
Stage 1建立任务形态企业资料到初筛报告输出是否像业务助手
Stage 2强化风险归因风险线索、证据缺口、尽调问题是否基于材料分析
Stage 3强化格式稳定JSON、短答、固定模板、多问法是否稳定遵循格式
Stage 4修复失败样本编造、过度结论、过度拒答、漏答回归是否改善

Stage 1 解决“模型知道自己要做什么”。这个阶段的样本应该覆盖主要业务任务，例如企业风险摘要、经营稳定性分析、负面线索解释、尽调问题生成。

Stage 2 解决“模型能不能基于证据分析”。这个阶段重点增加证据不足、字段缺失、结论不确定的样本，让模型学会把不确定性写出来。

Stage 3 解决“模型能不能稳定输出”。业务系统经常需要 JSON、固定字段或短回答，如果模型一会儿输出 Markdown，一会儿输出自然语言，一会儿多加解释，后续集成会很困难。

Stage 4 解决“真实失败样本”。评测和试用中发现的典型失败样本，不应该简单堆进训练集，而要先归因：是数据缺失、指令不清、模型编造、格式不稳，还是任务本身不该由模型回答。

LLaMA-Factory 配置示例

LLaMA-Factory 的训练入口比较直接。基础命令通常是：

llamafactory-cli train examples/train_qlora/business_7b_lora_sft.yaml

一个脱敏后的 7B QLoRA SFT 配置可以类似这样：

### model
model_name_or_path: Qwen/Qwen2.5-7B-Instruct
trust_remote_code: true

### method
stage: sft
do_train: true
finetuning_type: lora
lora_target: all
lora_rank: 16
lora_alpha: 32
lora_dropout: 0.05

### quantization
quantization_bit: 4

### dataset
dataset: finance_risk_sft_demo
template: qwen
cutoff_len: 4096
max_samples: 10000
overwrite_cache: true
preprocessing_num_workers: 8

### output
output_dir: saves/business-7b/lora/stage1
logging_steps: 10
save_steps: 200
plot_loss: true
overwrite_output_dir: true

### train
per_device_train_batch_size: 1
gradient_accumulation_steps: 8
learning_rate: 2.0e-4
num_train_epochs: 2.0
lr_scheduler_type: cosine
warmup_ratio: 0.03
bf16: true

### eval
val_size: 0.1
per_device_eval_batch_size: 1
eval_strategy: steps
eval_steps: 200

实际配置要根据显存、上下文长度、数据规模和模型模板调整。对于 2 x 24GB 显存，4-bit QLoRA 通常比全参数微调更适合快速业务迭代。

训练完成后，可以用 LoRA adapter 进行推理验证：

llamafactory-cli chat examples/inference/business_7b_lora_sft.yaml

也可以导出合并后的模型，但合并和量化要单独验证，不能把“训练成功”等同于“部署成功”。

评测不要只看 loss

训练日志里的 train_loss 和 eval_loss 有用，但不能直接代表业务质量。不同阶段的数据分布不同，loss 也不能简单横向比较。

业务评测更应该看这些问题：

指标问题
任务完成度是否完成了企业评估、风险归纳、尽调建议等任务
输出格式有效率JSON 是否可解析，字段是否齐全
证据边界表达率是否说明结论基于哪些材料
幻觉率是否编造未提供的企业事实
过度结论率是否直接给出最终授信、审批或准入结论
拒答准确率不该回答的问题是否能拒绝或转为边界说明
过度拒答率正常可答问题是否被错误拒绝
人工可读性业务人员是否能继续使用输出

一个简单的评测集可以包含：

评测子集用途
标准企业资料验证正常任务能力
缺字段资料验证证据边界
高风险线索验证风险归因
无关问题验证任务边界
格式输出题验证 JSON 或固定模板
历史失败样本验证修复是否有效

不要只用训练集附近的样本做评测。更有价值的是 held-out 样本、人工构造的边界样本，以及试用过程中收集到的失败样本。

失败样本如何进入下一轮

业务模型的迭代靠失败样本闭环。

flowchart LR
  A[失败样本] --> B[人工归因]
  B --> C[进入评测集]
  B --> D[补充训练集]
  C --> E[回归评测]
  D --> F[重新微调]
  F --> E
  E --> G[版本冻结]

失败样本不一定都该进入训练集。先归因更稳：

失败类型处理方式
输出格式不稳增加格式样本，或在推理侧增加 schema 校验
编造企业事实增加证据边界样本和反例样本
正常问题被拒答增加可答样本，明确可答边界
敏感结论过度直接增加审慎表达和人工复核样本
问题缺少必要输入训练模型要求补充材料，而不是自行补全

如果不做归因，只是把失败样本反复加入训练，模型可能在一个问题上变好，却在另一个问题上退化。

常见经验

第一，业务微调不是知识库。模型可以学习回答方式，但不应该承担所有事实存储职责。实时、精确、可追溯的事实，应由数据库、检索系统或业务系统提供。

第二，数据里的边界表达很重要。企业评估场景最常见的风险不是模型不会写，而是写得太像确定结论。训练样本要反复出现“基于已提供材料”“需要进一步核验”“不能替代正式审批”。

第三，小规模修复样本有用，但不能解决所有系统性问题。如果模型在某类问题上持续失败，要检查任务定义、prompt、输出格式、数据配比和评测口径，而不是只增加同类样本。

第四，7B 模型适合快速建立业务闭环。它不一定是最终形态，但适合验证数据工程、训练流程、评测指标和部署成本。等任务边界和评测体系稳定后，再考虑更大模型会更稳。

第五，训练完成只是中间节点。一个业务场景模型能不能用，取决于数据、模型、评测、推理服务和人工流程能不能形成闭环。

结论

业务场景微调不是重新训练一个通用大模型，而是把已有基座模型调成稳定、可控、符合业务口径的任务模型。

对企业评估这类场景，7B 模型配合 4-bit QLoRA 已经可以完成不少有价值的业务后训练实验。重点不是让模型“敢下结论”，而是让模型基于证据组织信息、说明不确定性、输出可复核建议，并在资料不足时守住边界。

如果从零开始做业务场景模型，先用 7B 跑通四件事：数据样本设计、分阶段 SFT、业务评测集和失败样本闭环。等这些基础稳定后，再扩大参数规模才有意义。

参考项目

评论

评论由 GitHub Issues 提供支持，需要登录 GitHub。