为什么微调而不是大模型 + Prompt？正确率如何得到，是否过拟合？

第40题：为什么微调而不是大模型 + Prompt？正确率如何得到，是否过拟合？

1. 核心回答

我不会先假设微调一定优于"大模型 + Prompt"。

更合理的实验顺序是：

text 复制代码

Base Model + Prompt
        ↓
建立 Baseline
        ↓
SFT / LoRA Fine-tuning
        ↓
同一 Test Set、同一评测标准比较
        ↓
判断微调是否产生足够增量

如果大模型通过 Prompt 已经能够稳定达到任务要求，我会优先保留 Prompt 方案，因为它：

开发迭代快；
不需要训练数据；
没有额外训练成本；
修改任务规则更方便。

如果任务具有稳定、重复的输入输出模式，同时 Prompt 方案长期存在：

准确率不足；
输出格式不稳定；
指令遵循不稳定；
需要很长 Few-shot Prompt；
推理 Token 成本较高；
较小模型经过微调后可以达到目标；

那么微调才有充分理由。

最终选择应该比较：

Quality+Stability+Latency+Cost Quality + Stability + Latency + Cost Quality+Stability+Latency+Cost

而不能只比较模型参数规模。

2. 为什么先做 Prompt Baseline

微调需要：

构造数据；
数据清洗；
训练；
超参数搜索；
GPU 资源；
模型版本管理；
训练后回归测试。

Prompt 的试错成本通常更低。

因此我的第一步会是建立一个较强的 Prompt Baseline：

text 复制代码

Base Model
+
System Prompt
+
Task Instruction
+
必要的 Few-shot Examples

然后在固定测试集：

Dtest D_{\text{test}} Dtest

上得到：

Mprompt M_{\text{prompt}} Mprompt

这个结果构成后续微调的基线。

只有微调后的：

MFT M_{\text{FT}} MFT

在关键指标上具有稳定提升，微调才产生了可以量化的价值。

3. 什么场景更适合 Prompt

如果任务本身已经处于基础模型能力范围内，而且规则经常修改，Prompt 通常值得优先尝试。

例如：

文本总结；
通用问答；
格式要求较简单；
少量分类；
临时业务规则；
需求快速迭代。

假设任务规则每周都变化。

Prompt 方案只需要修改：

text 复制代码

Instruction V1
→
Instruction V2

微调方案则可能涉及：

text 复制代码

重新构造数据
→
重新训练
→
重新评测
→
重新发布模型

因此任务变化频率也是方案选择条件。

4. 什么情况下我会选择微调

我会重点考虑以下情况。

4.1 任务分布比较稳定

例如长期都在处理：

text 复制代码

安全告警 → 风险分类

或者：

text 复制代码

漏洞描述 → 固定JSON Schema

输入输出模式长期稳定，更适合让模型通过训练学习这种映射。

4.2 Prompt 已经达到瓶颈

先充分优化：

System Prompt；
Instruction；
Few-shot Example；
Output Constraint；

之后，验证集性能仍然无法达到目标。

例如：

F1Prompt=0.82 F1_{\text{Prompt}}=0.82 F1Prompt=0.82

而业务要求：

F1≥0.90 F1\ge0.90 F1≥0.90

此时继续增加 Prompt 复杂度的边际收益可能已经很低。

4.3 输出格式需要高度稳定

例如必须输出：

json 复制代码

{
  "risk_level": "...",
  "attack_type": "...",
  "evidence": [...]
}

如果 Prompt 方案频繁出现：

缺字段；
字段名称错误；
多余自然语言；
Schema 不合法；

那么可以通过高质量 SFT 数据强化这种稳定输出行为。

4.4 有足够高质量的任务数据

例如已经积累：

D={(xi,yi)}i=1N D= \{(x_i,y_i)\}_{i=1}^{N} D={(xi,yi)}i=1N

并且：

标签可靠；
数据覆盖真实分布；
没有明显泄漏；
样本数量足够支持训练。

此时微调才具有良好的数据基础。

5. 为什么不能通过模型大小直接决定

"大模型 + Prompt"和"较小模型 + Fine-tuning"的结果具有任务依赖性。

已有实证研究在代码生成、代码总结、代码翻译等任务上发现：

一些任务中 Prompted Large Model 更好；
一些任务中 Fine-tuned Model 更好；
一些任务中双方接近。

所以不能简单推出：

Larger Model⇒Always Better \text{Larger Model} \Rightarrow \text{Always Better} Larger Model⇒Always Better

或者：

Fine-tuning⇒Always Better \text{Fine-tuning} \Rightarrow \text{Always Better} Fine-tuning⇒Always Better

最终需要实验回答：

MetricPromptvs.MetricFT Metric_{\text{Prompt}} \quad vs.\quad Metric_{\text{FT}} MetricPromptvs.MetricFT

6. 怎样公平比较 Prompt 和微调

我会尽量固定：

Test Set；
输入信息；
最大上下文；
解码参数；
最大输出长度；
工具权限；
评测程序；
任务定义。

然后比较至少两个系统：

text 复制代码

A：Base Model + Strong Prompt

B：Fine-tuned Model + Fixed Prompt

如果条件允许，再增加：

text 复制代码

C：Fine-tuned Model + Optimized Prompt

最终报告：

指标	Prompt	Fine-tuning
Accuracy / F1	实测	实测
Format Pass Rate	实测	实测
P95 Latency	实测	实测
Input Tokens	实测	实测
Output Tokens	实测	实测
Cost / Request	实测	实测

这样"为什么选择微调"就可以由数据回答。

7. 正确率到底怎么得到

首先要看任务是什么。

如果是标准分类任务，Accuracy 定义很直接。

假设测试集包含：

N N N

条样本。

预测正确：

Ncorrect N_{\text{correct}} Ncorrect

条。

那么：

$$

Accuracy

\frac{N_{\text{correct}}}{N}

例如： N=1000 N=1000 N=1000 正确： Ncorrect=910 N_{\\text{correct}}=910 Ncorrect=910 则： Accuracy=91% Accuracy=91\\% Accuracy=91% 这里必须强调： **这些样本应该来自独立的 Test Set。** *** ** * ** *** ### 8. 分类任务为什么不能只看 Accuracy 如果类别严重不平衡，Accuracy 可能产生误导。 例如： ```text 正常样本：990 恶意样本：10 ``` 模型全部预测： ```text 正常 ``` 仍然有： ##

Accuracy

\frac{990}{1000}

99%

但恶意样本 Recall 是： 0 0 0 所以分类任务通常还需要： ##

Precision

\frac{TP}{TP+FP}

##

Recall

\frac{TP}{TP+FN}

##

\frac{

Precision\cdot Recall

}{

Precision+Recall

}

类别不平衡时，我通常会重点看： * Precision； * Recall； * F1； * Macro-F1； * PR-AUC。 具体使用哪个指标由任务错误成本决定。 *** ** * ** *** ### 9. 生成任务的"正确率"怎么定义 生成任务经常没有唯一标准答案。 例如： ```text 请分析这段漏洞代码。 ``` 模型可能生成多种都正确的答案。 因此不能直接使用字符串完全相等作为全部评价标准。 需要先定义评测器。 *** ** * ** *** ### 10. 有确定答案的生成任务 如果任务可以自动验证，优先使用规则。 例如数学： ```text Predicted Answer == Ground Truth ``` 可以计算： ##

Accuracy

\frac{

\text{最终答案正确的题目数}

}{

\text{全部题目数}

}

代码生成可以使用： ```text Compilation + Unit Test ``` 例如： ##

PassRate

\frac{

\text{通过全部测试的代码数}

}{

}

结构化输出可以用： ```text JSON Schema Validation ``` 计算： ##

FormatPassRate

\frac{

N_{\text{valid JSON}}

}{

}

这些自动验证方式通常比单纯的文本相似度更直接。 *** ** * ** *** ### 11. 开放式回答如何评估 对于开放式生成，我会先定义 Rubric。 例如： ```text Correctness 0~4 Completeness 0~4 Instruction 0~4 Faithfulness 0~4 Format 0~4 ``` 然后由： * 人工专家； * 规则程序； * LLM Judge； 进行评分。 如果最终希望报告一个"通过率"，可以先定义： Score≥τ Score\\ge\\tau Score≥τ 代表任务通过。 那么： ##

PassRate

\frac{

N_{\text{pass}}

}{

N_{\text{test}}

}

这里必须提前确定： * Rubric； * Threshold； * Judge； * Test Set。 不能看到模型结果以后再修改评分标准。 *** ** * ** *** ### 12. 正确率必须来自什么数据 理想情况下数据分成： ```text Train Set Validation Set Test Set ``` 三个部分。 #### 12.1 Train Set 用于： 更新模型参数 \\text{更新模型参数} 更新模型参数 #### 12.2 Validation Set 用于选择： * Learning Rate； * Epoch； * LoRA Rank； * Checkpoint； * Prompt； * Early Stopping。 #### 12.3 Test Set 只用于： **最终一次泛化能力评估。** 因此： ```text Train → 学参数 Validation → 做选择 Test → 最终报告 ``` 这是正确率可信的基本前提。 *** ** * ** *** ### 13. 为什么 Test Set 不能参与调参 假设测试集有： 1000 1000 1000 条。 你训练模型 A： Accuracy=87% Accuracy=87\\% Accuracy=87% 看到测试结果以后调整 Prompt。 模型 B： Accuracy=89% Accuracy=89\\% Accuracy=89% 继续根据测试结果改数据。 模型 C： Accuracy=92% Accuracy=92\\% Accuracy=92% 此时这个： 92% 92\\% 92% 已经不能很好地代表真正未见数据上的性能。 因为开发过程已经不断从 Test Set 获取信息。 这相当于： Test Information→Model Development Test\\ Information \\rightarrow Model\\ Development Test Information→Model Development 形成 Data Leakage。 scikit-learn 官方文档明确指出，测试数据参与模型选择会产生过度乐观的性能估计。 *** ** * ** *** ### 14. 还要防止样本级数据泄漏 即使 Train 和 Test 文件不同，仍然可能发生泄漏。 例如： ```text Train: 如何使用LoRA微调Llama模型？ Test: Llama模型如何通过LoRA进行微调？ ``` 这两个样本语义高度相似。 模型测试时可能主要是在回忆训练样本。 因此我会检查： * Exact Duplicate； * Near Duplicate； * 同一个原始文档； * 同一个用户； * 同一个项目； * 同一个代码仓库； * 同一个漏洞； * 同一个模板。 必要时使用 Group Split 或 Time Split。 *** ** * ** *** ### 15. 如何判断是否过拟合 最典型的现象是： 训练集继续改善： Ltrain↓ L_{\\text{train}}\\downarrow Ltrain↓ 但验证集开始恶化： Lval↑ L_{\\text{val}}\\uparrow Lval↑ 或者： Metrictrain↑ Metric_{\\text{train}}\\uparrow Metrictrain↑ 而： Metricval↓ Metric_{\\text{val}}\\downarrow Metricval↓ 例如： | Epoch | Train Loss | Val Loss | Val F1 | |-------|-----------:|---------:|-------:| | 1 | 1.2 | 1.1 | 0.78 | | 2 | 0.8 | 0.82 | 0.84 | | 3 | 0.5 | 0.74 | 0.87 | | 4 | 0.3 | 0.81 | 0.84 | | 5 | 0.2 | 0.95 | 0.80 | 这里 Epoch 3 之后： TrainLoss TrainLoss TrainLoss 仍然下降，但： ValLoss ValLoss ValLoss 开始上升，同时 Val F1 下降。 这就是比较典型的过拟合信号。 *** ** * ** *** ### 16. 为什么只看 Train Loss 不够 假设训练最终得到： TrainAccuracy=99.9% TrainAccuracy=99.9\\% TrainAccuracy=99.9% 这只能说明模型对训练数据拟合得很好。 如果： TestAccuracy=70% TestAccuracy=70\\% TestAccuracy=70% 则存在明显的 generalization gap： ##

Gap

99.9%-70%

29.9%

真正需要关注的是： Generalization Generalization Generalization 也就是模型面对未见样本时是否仍然有效。 因此训练过程中我会同时监控： ```text Train Loss Validation Loss Validation Task Metric ``` 最终再看独立 Test Metric。 *** ** * ** *** ### 17. 过拟合之前先排查数据问题 看到： Train≫Validation Train\\gg Validation Train≫Validation 时，我不会立即修改模型结构。 首先排查： #### 17.1 数据重复 Train 中是否存在大量重复数据。 #### 17.2 Label Noise 训练标签是否错误或冲突。 #### 17.3 Train / Test Leakage 训练和测试是否存在： * 重复； * 改写； * 同源数据。 #### 17.4 Distribution Shift 训练数据和验证数据是否来自完全不同环境。 例如： ```text Train：GitHub开源代码 Test：企业内部代码 ``` 性能差距可能包含明显的域偏移因素。 这些问题和传统意义上的模型容量过大需要分别诊断。 *** ** * ** *** ### 18. 如何降低过拟合 如果确认主要是模型训练过度，我会依次尝试以下方法。 #### 18.1 Early Stopping 如果 Epoch 3 验证集最好： ##

Metric_{val}^{(3)}

\max_t Metric_{val}^{(t)}

就保存 Epoch 3 的 checkpoint。 无需继续训练到 Epoch 10。 #### 18.2 减少 Epoch 例如： 5→3 5 \\rightarrow 3 5→3 降低模型重复记忆同一数据的程度。 #### 18.3 降低 Learning Rate 学习率过大可能产生不稳定更新。 对于 Fine-tuning，可以测试更小的学习率。 #### 18.4 增加高质量训练数据 尤其增加： * 边界样本； * 长尾任务； * Hard Examples； * 不同来源的数据。 可以提高训练分布覆盖。 #### 18.5 去重 减少模型反复看到同一模式。 #### 18.6 Weight Decay / Dropout 根据模型和训练方法使用正则化。 #### 18.7 降低可训练容量 如果使用 LoRA，可以在验证集上测试更小的： r r r 或者减少： ```text target_modules ``` 但具体是否有效仍要通过实验判断。 *** ** * ** *** ### 19. 如何更强地证明没有严重过拟合 单一随机 Test Split 的证据仍然有限。 如果任务允许，我会进一步测试： #### 19.1 Time Split ```text 过去数据 → Train 较新的数据 → Validation 未来数据 → Test ``` 测试时间泛化。 #### 19.2 Group Split 例如： ```text Project A/B/C → Train Project D → Test ``` 测试跨项目能力。 #### 19.3 Domain Split 例如： ```text 公开代码 → Train 另一来源代码 → Test ``` 测试跨环境鲁棒性。 如果这些更严格的切分下仍然保持稳定提升，微调的泛化证据会更强。 *** ** * ** *** ### 20. 最终实验应该怎样设计 我会形成如下实验矩阵： | 方法 | Train | Validation | Test | 主要目的 | |-----------------|-------|------------|------|-------------------| | Base + Prompt | 否 | 调 Prompt | 最终测试 | Prompt Baseline | | Base + Few-shot | 否 | 调 Example | 最终测试 | 强 Prompt Baseline | | Fine-tuning | 训练 | 调超参 | 最终测试 | 验证训练增益 | 固定： ```text Dataset Evaluation Inference Configuration Information Visibility ``` 最终比较： ##

\Delta Metric

Metric_{\text{FT}}

Metric_{\text{Prompt}}

同时比较：

ΔLatency \Delta Latency ΔLatency

ΔCost \Delta Cost ΔCost

ΔFormatPassRate \Delta FormatPassRate ΔFormatPassRate

这样可以直接回答：

微调到底给系统带来了什么。

21. 怎样回答"为什么不用更大的模型"

如果面试官继续问：

那我直接调用更强的大模型不就行了吗？

我会回答：

我会把更强模型作为 baseline。如果更强模型通过 Prompt 就能达到任务要求，并且成本和延迟能够接受，那么没有必要为了使用微调而强行微调。

我最终采用微调，需要有明确实验依据。例如微调后的较小模型在独立测试集上已经达到相同或更好的任务指标，同时输出格式更稳定，平均输入 Prompt 更短，并且推理延迟或成本更符合系统要求。

所以这里的选择依据来自端到端实验，而不是模型大小或者技术路线本身。

22. 面试时可以压缩成下面这段

我会先做一个强的大模型 + Prompt Baseline，然后再判断微调有没有必要。Prompt 方案迭代快，如果基础模型已经能够稳定完成任务，我会优先保留它。微调更适合输入输出模式长期稳定、有高质量训练数据，而且 Prompt 已经出现准确率、格式稳定性或者成本瓶颈的场景。

正确率必须在独立 Test Set 上计算。分类任务可以直接算 Accuracy=Ncorrect/NAccuracy=N_{correct}/NAccuracy=Ncorrect/N，类别不平衡时我还会看 Precision、Recall、F1。对于开放式生成，我会提前定义 Exact Match、规则验证、Unit Test 或人工/模型 Rubric，再计算 Pass Rate。

数据会严格分成 Train、Validation 和 Test。Train 用来更新参数，Validation 用来调 learning rate、epoch、rank 和 checkpoint，Test 只做最终评估。同时做去重和 group/time split，避免同源样本泄漏。

判断过拟合时，我主要观察 Train/Validation 曲线。如果 train loss 持续下降，而 validation loss 上升或者 validation F1 开始下降，就是典型信号。我会先排查数据泄漏和重复，然后根据情况采用 Early Stopping、减少 epoch、降低学习率、增加高质量数据、正则化或者降低可训练容量。

最终我会在同一测试集比较：

Base+Promptvs.Fine-tuned Base+Prompt \quad vs.\quad Fine\text{-}tuned Base+Promptvs.Fine-tuned