模型选型与微调个人笔记

日期：2026-06-12，由于各家模型迭代速度越来越快，特点特性快速更新，版本与特性变化频繁，建议根据场景和需求、时效性(即时各家模型版本特性)选择合适的模型。

---

目录

1. 主流模型对比与选型
2. 微调 vs RAG vs Prompt Engineering 决策框架
3. LoRA / QLoRA 微调实践
4. 模型评估与基准测试
5. 私有化部署 vs API 调用决策框架
6. 总结与最佳实践

---

1. 主流模型对比与选型

1.1 2026年主流模型概览

模型	厂商	定位	多模态	开源	价格定位
GPT	OpenAI	通用旗舰	是	否	高
Claude Sonnet	Anthropic	长文本+安全	是	否	中高
Claude Opus	Anthropic	深度推理旗舰	是	否	高
Gemini Pro	Google	超长上下文	是	否	中
DeepSeek	DeepSeek	旗舰	否	是	极低(API)
Llama	Meta	开源通用	是	是	免费(自部署)
Mistral Large	Mistral	欧洲合规	是	是	中

1.2 各模型核心能力对比(纯个人感受，完全不准，千万不要借鉴)

多语言（中文）

中文能力排名：
1. DeepSeek V4 (发文当前版本是V4-pro)（中文流畅度极高）
2. Qwen（中文训练数据多，文化理解深）
3. Claude 系列（中文安全对齐好）
4. GPT（中文综合能力不错）
5. Gemini Pro

安全与合规

安全合规排名：
1. Claude 系列（Constitutional AI，安全对齐最严格）
2. GPT（安全体系成熟）
3. Gemini Pro
4. Qwen3 / DeepSeek（开源模型需自建安全层）

1.3 场景化选型策略(具体选型不做推荐，根据特性选择即可，每家模型更新迭代速度越来越快了，很多特性更新也极快)

场景	理由
严肃金融/医疗	安全对齐最严格，合规优先
代码生成/审查	代码能力公认最强
中文场景	中文训练数据和文化理解
长文档分析	1M上下文独一档
数学/逻辑推理	推理特化，CoT能力强
成本敏感	性价比极高
数据不出域	开源可私有化
多模态	原生多模态支持
多轮对话/Agent	指令遵循和工具调用稳定
创意写作	文风自然，有深度

1.4 模型组合策略（多模型路由）

实际生产中很少只用单一模型，更常见的做法是按任务类型路由。具体可以看一下另一篇笔记：
https://blog.csdn.net/qq_43081349/article/details/161931971

---

2. 微调 vs RAG vs Prompt Engineering 决策框架

2.1 三种方案的本质区别

Prompt Engineering:  不改模型，改输入
RAG:                 不改模型，改上下文（注入外部知识）
Fine-tuning:         改模型，让它学会新知识/新行为

维度	Prompt Engineering	RAG	Fine-tuning
改什么	输入文本	检索上下文	模型权重
知识更新	每次改Prompt	更新知识库即可	需重新训练
实时性	即时	即时（知识库更新后）	延迟（需训练）
成本	极低	中（检索基础设施）	高（GPU训练）
幻觉控制	弱	中（有来源引用）	中（可能学到错误知识）
风格/格式控制	中	弱	强
领域知识注入	弱	强	强
新能力获取	弱	弱	强

2.2 决策框架

你需要解决什么问题？
|
+-- 让模型遵循特定输出格式/风格？
|     |
|     +-- 格式简单固定 -> Prompt Engineering（Few-shot示例）
|     +-- 格式复杂，需要大量示例 -> Fine-tuning
|
+-- 让模型知道你的私有数据/知识？
|     |
|     +-- 数据频繁更新 -> RAG
|     +-- 数据相对稳定 -> RAG（首选）或 Fine-tuning
|     +-- 需要深度理解领域术语和推理模式 -> Fine-tuning + RAG
|
+-- 让模型获得新能力（如新语言、新任务类型）？
|     |
|     +-- 必须 -> Fine-tuning
|
+-- 降低成本和延迟？
|     |
|     +-- 用大模型生成训练数据，微调小模型 -> Fine-tuning（蒸馏）
|
+-- 提高特定任务的准确率？
    |
    +-- 先试 Prompt Engineering（成本最低）
    +-- 不够 -> 加 RAG
    +-- 还不够 -> Fine-tuning
    +-- 终极方案 -> Fine-tuning + RAG

2.3 组合策略：Fine-tuning + RAG

实际生产中，最优方案往往是组合：

用户Query
    |
    v
意图识别（Fine-tuned 小模型，快且准）
    |
    v
检索增强（RAG，注入最新知识）
    |
    v
生成回复（Fine-tuned 大模型，风格可控）
    |
    v
输出校验（规则 + 模型）

2.4 各方案适用场景速查

场景	推荐方案	原因
客服FAQ	RAG	知识库频繁更新
合同审查	Fine-tuning + RAG	需理解法律术语 + 引用条款
代码生成	Prompt Engineering	模型已足够强
金融研报生成	Fine-tuning + RAG	格式固定 + 数据实时
医疗问诊	RAG（优先）	医学知识需实时更新
翻译（小众语言）	Fine-tuning	基座模型能力不足
情感分析	Fine-tuning（小模型）	任务明确，可蒸馏
创意写作	Prompt Engineering	无需特定知识

---

3. 模型评估与基准测试

3.1 评估维度体系

模型评估
+-- 能力评估（能不能做）
|   +-- 通用能力：MMLU, HellaSwag, ARC
|   +-- 推理能力：GSM8K, MATH, HumanEval
|   +-- 代码能力：HumanEval, MBPP, SWE-bench
|   +-- 中文能力：C-Eval, CMMLU, SuperCLUE
|   +-- 长文本：Needle-in-a-Haystack, LongBench
+-- 安全评估（安不安全）
|   +-- 有害内容：HarmBench, AdvBench
|   +-- 越狱抵抗：JailbreakBench
|   +-- 偏见检测：BBQ, WinoBias
+-- 业务评估（好不好用）
|   +-- 任务准确率：自建测试集
|   +-- 用户满意度：A/B测试, NPS
|   +-- 成本效率：Token消耗, 延迟
+-- 微调效果评估（改没改好）
    +-- 基座 vs 微调对比
    +-- 灾难性遗忘检测
    +-- 过拟合检测

3.2 核心基准测试详解

基准	测试内容	题目数	指标	适用场景
MMLU	57学科知识问答	14K	Accuracy	通用知识
GSM8K	小学数学应用题	8.5K	Accuracy	数学推理
MATH	竞赛级数学	12.5K	Accuracy	高等数学
HumanEval	Python代码生成	164	pass@k	代码能力
SWE-bench	真实GitHub Issue修复	2K+	resolve rate	软件工程
C-Eval	中文多学科	13.9K	Accuracy	中文知识
SuperCLUE	中文综合能力	多维度	综合分	中文通用
Needle-in-Haystack	长文本检索	可配置	Recall	长上下文
IFEval	指令遵循	500+	严格/宽松	指令遵循

3.3 自建业务评估集

(探索中，待验证)

3.4 评估工具推荐

工具	用途	特点
lm-evaluation-harness	通用基准测试	支持200+基准，一键评估
OpenAI Evals	自建评估集	OpenAI官方，模板化
DeepEval	单元测试风格	类似pytest的LLM测试
PromptFoo	对比评估	多模型/多Prompt对比
LangSmith	全链路评估	线上数据标注+评估
Ragas	RAG评估	检索+生成质量评估

---

4. 私有化部署 vs API 调用决策框架

4.1 核心对比

维度	API 调用	私有化部署
数据安全	数据出域，依赖厂商安全承诺	数据完全内控
合规性	需审核厂商资质和数据处理协议	完全自主可控
成本结构	按量付费（$0.1-15/1M tokens）	固定硬件成本 + 运维
初始投入	零	高（GPU服务器 10-200万+）
运维负担	零	高（需MLOps团队）
模型更新	自动获取最新模型	需手动升级
延迟	受网络和API负载影响	可控，可优化
定制化	仅 Prompt 层面	可微调、量化、剪枝
可用性	依赖厂商SLA	自主保障
吞吐量	受API限流影响	可无限扩展（加硬件）

4.2 决策框架

约束条件是什么？
|
+-- 数据绝对不能出内网？
|     +-- 是 -> 私有化部署（唯一选择）
|     +-- 否 -> 继续判断
|
+-- 需要深度定制（微调/量化/剪枝）？
|     +-- 是 -> 私有化部署
|     +-- 否 -> 继续判断
|
+-- 日均调用量？
|     +-- < N Mtokens/天 -> API 调用（成本更低）
|     +-- N-NN Mtokens/天 -> 需要计算盈亏平衡点
|     +-- > NN Mtokens/天 -> 私有化部署（成本更低）
|
+-- 团队有MLOps能力？
|     +-- 否 -> API 调用（避免运维负担）
|     +-- 是 -> 可以考虑私有化
|
+-- 对延迟有严格要求（< 200ms）？
|     +-- 是 -> 私有化部署（可控延迟）
|     +-- 否 -> API 调用

4.3 成本盈亏平衡计算

需要根据个人/团队成本，需求，所选模型API计费(输入，输出，思考，缓存等)进行计算。

4.4 混合部署策略

实际生产中，最佳方案往往是混合部署：

                    敏感数据？
                   /        \
                 是          否
                 |            |
          私有化部署      高频调用？
                        /        \
                      是          否
                      |            |
                私有化部署    API 调用
                （降成本）   （灵活方便）

4.5 私有化部署技术栈

组件	推荐方案	说明
推理引擎	vLLM / TGI / SGLang	高吞吐推理
模型量化	AWQ / GPTQ / GGUF	降低显存需求
服务编排	K8s + GPU Operator	弹性伸缩
模型管理	HuggingFace Hub / 私有Registry	版本管理
监控	Prometheus + Grafana	延迟/吞吐/显存
API网关	Kong / Nginx + LiteLLM	限流/路由/认证

---

5. 总结与最佳实践

5.1 核心原则

1. 先选场景再选模型：没有最优的模型，只有场景下最优模型
2. 从简单开始：Prompt Engineering -> RAG -> Fine-tuning，逐级升级
3. 多模型组合优于单一模型：按任务类型路由到最优模型
4. 评估先行：没有评估就没有优化方向
5. 成本意识：计算盈亏平衡点，避免过度投入

5.2 与 RICE 框架的关系

模型选型与微调直接服务于 RICE 框架的大模型层：

RICE 大模型层
  |
  +-- 模型选型：按场景路由到最优模型
  |     +-- 严肃业务 -> 一般来说当前贵的，安全与合规性高的(比如Claude Fable 5，ChatGpt 5.5)
  |     +-- 代码任务 -> 代码任务专用模型（如Claude Sonnet）
  |     +-- 中文任务 -> DeepSeek / Qwen3
  |     +-- 长文本   -> DeepSeek V4
  |
  +-- 能力增强：Fine-tuning + RAG 组合
  |     +-- 领域知识 -> RAG
  |     +-- 领域风格 -> Fine-tuning
  |     +-- 新能力   -> Fine-tuning
  |
  +-- 部署策略：混合部署
        +-- 敏感数据 -> 私有化
        +-- 通用任务 -> API

额外附赠. LoRA / QLoRA 微调实践 (此部分完全借助AI产生，请仔细甄别可行性与风险)

额外附赠.1 核心概念

为什么需要 LoRA？

全量微调（Full Fine-tuning）的问题：

• 更新所有参数（70B模型 = 140GB显存）
• 需要多张 A100/H100
• 训练成本高（卡卡卡卡贵贵贵贵）
• 每个微调版本存储一份完整模型（70B x N个版本 = 灾难）

LoRA（Low-Rank Adaptation）的核心思想：

• 冻结原始模型权重
• 在特定层插入可训练的低秩矩阵
• 只训练这些低秩矩阵（参数量通常 < 原始模型的 1%）

原始权重矩阵 W (d x k，冻结)
    +
低秩分解 A (d x r) x B (r x k)（可训练，r << min(d,k)）
    =
微调后的权重 W' = W + A x B

LoRA vs QLoRA

维度	LoRA	QLoRA
基座模型精度	FP16/BF16	4-bit 量化(NF4)
显存需求(7B模型)	~16GB	~6GB
显存需求(70B模型)	~160GB	~48GB
训练速度	快	慢(量化/反量化开销)
模型质量	无损	略低于LoRA(差距很小)
硬件要求	至少一张A100	一张RTX 3090/4090即可

额外附赠.2 完整实践流程

Step 1：环境准备

pip install transformers peft accelerate bitsandbytes datasets trl
pip install torch --index-url https://download.pytorch.org/whl/cu121

Step 2：加载基座模型（QLoRA 4-bit量化）

import torch
from transformers import (
    AutoModelForCausalLM, AutoTokenizer,
    BitsAndBytesConfig, TrainingArguments,
)
from peft import LoraConfig, get_peft_model, prepare_model_for_kbit_training
from datasets import load_dataset

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_quant_type="nf4",
    bnb_4bit_compute_dtype=torch.bfloat16,
    bnb_4bit_use_double_quant=True,
)

model_name = "Qwen/Qwen2.5-7B-Instruct"
model = AutoModelForCausalLM.from_pretrained(
    model_name,
    quantization_config=bnb_config,
    device_map="auto",
    trust_remote_code=True,
)
tokenizer = AutoTokenizer.from_pretrained(model_name, trust_remote_code=True)
model = prepare_model_for_kbit_training(model)

Step 3：配置 LoRA

lora_config = LoraConfig(
    r=16,               # 低秩维度（常用 8/16/32/64）
    lora_alpha=32,      # 缩放因子（通常 alpha = 2 * r）
    target_modules=[    # 目标模块（不同模型不同）
        "q_proj", "k_proj", "v_proj", "o_proj",
        "gate_proj", "up_proj", "down_proj",
    ],
    lora_dropout=0.05,
    bias="none",
    task_type="CAUSAL_LM",
)

model = get_peft_model(model, lora_config)
model.print_trainable_parameters()
# 输出: trainable params: 41,943,040 || all params: 7,657,299,968 || trainable%: 0.5478%

Step 4：准备训练数据

def format_instruction(sample):
    messages = [
        {"role": "system", "content": "你是一个金融分析助手。"},
        {"role": "user", "content": sample["instruction"]},
        {"role": "assistant", "content": sample["output"]},
    ]
    return {"text": tokenizer.apply_chat_template(
        messages, tokenize=False, add_generation_prompt=False
    )}

dataset = load_dataset("json", data_files="train_data.json")
dataset = dataset.map(format_instruction)

def tokenize(sample):
    result = tokenizer(sample["text"], truncation=True, max_length=2048)
    result["labels"] = result["input_ids"].copy()
    return result

dataset = dataset.map(tokenize, remove_columns=["text"])

训练数据示例（train_data.json）：

[
  {
    "instruction": "分析茅台2024年Q3财报的营收增长原因",
    "output": "茅台2024年Q3营收增长主要来自三个方面：1）直销渠道占比提升至45%..."
  },
  {
    "instruction": "对比宁德时代和比亚迪的电池技术路线",
    "output": "宁德时代主打三元锂电池和麒麟电池，优势在于能量密度..."
  }
]

Step 5：配置训练参数

training_args = TrainingArguments(
    output_dir="./qwen2.5-7b-finance-lora",
    num_train_epochs=3,
    per_device_train_batch_size=4,
    gradient_accumulation_steps=4,    # 有效 batch_size = 16
    learning_rate=2e-4,
    warmup_ratio=0.03,
    lr_scheduler_type="cosine",
    logging_steps=10,
    save_steps=200,
    save_total_limit=3,
    bf16=True,
    optim="paged_adamw_8bit",
    report_to="wandb",
)

Step 6：训练与保存

from trl import SFTTrainer

trainer = SFTTrainer(
    model=model,
    args=training_args,
    train_dataset=dataset["train"],
    tokenizer=tokenizer,
    max_seq_length=2048,
    dataset_text_field="text",
)
trainer.train()

# 只保存 adapter（几MB），不保存基座模型（十几GB）
model.save_pretrained("./finance-adapter")
tokenizer.save_pretrained("./finance-adapter")

Step 7：推理

from peft import PeftModel

base_model = AutoModelForCausalLM.from_pretrained(
    model_name, device_map="auto", torch_dtype=torch.bfloat16,
)
model = PeftModel.from_pretrained(base_model, "./finance-adapter")

messages = [
    {"role": "system", "content": "你是一个金融分析助手。"},
    {"role": "user", "content": "分析腾讯2024年财报的亮点"},
]
inputs = tokenizer.apply_chat_template(messages, return_tensors="pt").to("cuda")
outputs = model.generate(inputs, max_new_tokens=1024, temperature=0.7)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

额外附赠.3 关键超参数调优指南

参数	推荐范围	说明
r (rank)	8-64	越大越强但越慢，16是常用平衡点
lora_alpha	r x 2	缩放因子，通常设为 2*r
learning_rate	1e-4 ~ 5e-4	QLoRA 可用稍高学习率
epochs	1-5	小数据集多用，大数据集少用
batch_size	4-16(有效)	通过 gradient_accumulation 调整
lora_dropout	0.05-0.1	数据少时提高防止过拟合
target_modules	至少 q_proj, v_proj	覆盖越多效果越好但参数越多

额外附赠.4 常见问题与解决

问题	原因	解决
训练loss不下降	学习率太低/太高	尝试 1e-4 到 5e-4
过拟合（训练loss低，验证loss高）	数据太少/epoch太多	减少epoch，增加dropout
显存不足(OOM)	batch_size太大	减小batch_size，增加gradient_accumulation
微调后模型变笨	灾难性遗忘	减少epoch，混合通用数据
生成重复内容	训练数据有重复模式	清洗数据，降低epoch

---