"AI 工程师不是炼丹师"
很多人以为做 AI 工程师就是 fine-tune 模型。99% 场景你不需要 fine-tune。
理由：
- Fine-tune 一次几千刀（OpenAI / Anthropic 都开了 fine-tune API，但贵）
- 改数据要重训
- 不容易回滚
- 把推理成本拉高（用 fine-tuned 模型 token price > 通用模型）
- 大概率被一个新版本基础模型反超（GPT-4 fine-tune 投入很大的项目，GPT-5 一出全废）
先用 RAG + Prompt Engineering 把效果做到 80%，剩下 20% 真的需要再考虑 fine-tune。 而 80% 通常已经够用。
什么时候真的需要 Fine-tuning
只有满足以下任一才考虑：
① 风格 / 格式要求极严
法律文书、医疗报告、品牌一致的客服回复——必须每次都用某种特定格式 + 行话。Prompt 里写"请用 XX 格式"模型只能学个大概，fine-tune 才能稳定。
② 调用 latency 要 < 200ms
聊天产品要"打字一样的速度"出回复。Sonnet 已经几百毫秒，要更快只有：
- 用 Haiku（但能力降一档）
- Fine-tune Haiku 让它在你的特定任务上表现接近 Sonnet
- 自己部署小开源模型（Llama 3.3 8B fine-tune）
③ 强 domain knowledge 必须 baked-in
医学影像描述、法律条款解析、特定行业 jargon——这些不在通用训练数据里，RAG 又没办法 "教会" 模型术语。这种场景 fine-tune 真的有用。
④ Privacy 不能调云端 API
客户数据不能出公司。本地部署 Llama / Qwen，再 fine-tune 适配业务。澳洲很多保险 / 医疗客户走这条路。
Fine-tune 不解决的问题（别幻想）
- ❌ "模型不知道我公司新闻" → 用 RAG，fine-tune 不解决实时性
- ❌ "幻觉太多" → fine-tune 反而可能加剧（数据有 bias 时）
- ❌ "回答不准" → 通常是 prompt / RAG 检索的问题，不是模型能力问题
Fine-tune 实操
如果你确定要做：
Step 1：准备数据
至少 100 条标注数据起步（OpenAI 推荐 50-100，匠人实践 200+ 才稳定）。每条 JSONL 格式：
{"messages":[{"role":"system","content":"..."},{"role":"user","content":"..."},{"role":"assistant","content":"理想回复"}]}
数据质量 >>> 数据数量。100 条精挑细选 > 5000 条噪声大的。
Step 2：起 fine-tune job
import openai
client = openai.OpenAI()
file = client.files.create(file=open('train.jsonl', 'rb'), purpose='fine-tune')
job = client.fine_tuning.jobs.create(
training_file=file.id,
model='gpt-5-mini',
hyperparameters={'n_epochs': 3}
)
# 等几小时～几天
print(job.fine_tuned_model) # ft:gpt-5-mini:my-org::abc123
Step 3：用 fine-tuned model
client.chat.completions.create(
model='ft:gpt-5-mini:my-org::abc123',
messages=[...]
)
价格通常是 base model 的 2-3 倍（GPT-5 mini fine-tune ≈ $1.5/1M input vs 原 $0.5）。
开源路径（本地 fine-tune）
如果数据敏感不能上云，用 Hugging Face / Unsloth 在本地 fine-tune Llama 3.3 8B 或 Qwen 2.5 7B：
- GPU 需求：单张 A100 80G 可以跑 Llama 3.3 8B QLoRA
- 训练时间：5K 样本约 4-8 小时
- 推理部署：vLLM 起服务，单机 4×H100 跑 Llama 70B QLoRA fine-tuned
匠人 LLM Lab 有完整本地 fine-tune 教程。
Eval 体系：AI 产品的"测试"
不写测试的代码不能 ship，不做 eval 的 AI 产品也不能 ship。但很多团队 ship 了再说——后果就是 prompt 改了一次性能从 90% 掉到 70% 没人发现，用户投诉才知道。
为什么 LLM 需要专门的 eval
传统 unit test：input 给定 → output 必须严格相等。
LLM 的 output 是自然语言，没有单一正确答案：
- "马尔代夫在哪？" → "印度洋上" / "南亚地区印度洋" / "印度西南方的群岛国家" 都对
- 不能用
assert output === "印度洋上"
需要更柔性的判断方法。
三档 eval 方法
Tier 1：Golden Set + 关键词检查（最便宜）
50-100 个手工挑的 case，每个有"必须包含的关键词" + "禁止出现的关键词"：
{
"input": "马尔代夫在哪？",
"must_contain": ["印度洋"],
"must_not_contain": ["大西洋", "太平洋"]
}
跑完检查每个 case 命中率。这种 eval 适合事实性任务（QA / 提取 / 分类）。
Tier 2：LLM-as-a-Judge（最实用）
用一个更强的 LLM 给被测模型的输出打分。Anthropic / OpenAI 自己 paper 都用这个方法。
judge_prompt = """
你是一个公正的评估员。下面是用户问题、参考答案、被测答案。
问题：{question}
参考答案：{reference}
被测答案：{actual}
请按以下维度打 1-5 分：
- 准确性：被测答案和参考答案的事实一致性
- 完整性：被测答案是否包含所有关键信息
- 清晰度：表达是否清楚
只返回 JSON：{"accuracy": int, "completeness": int, "clarity": int}
"""
result = await judge_llm.create({
model: "claude-opus-4-7",
system: judge_prompt.format(...),
...
})
关键：judge model 要比被测 model 强。用 Opus 评 Sonnet ✓；用 Sonnet 评 Sonnet 自己 ✗。
LLM-as-a-judge 准确率 80-90%（和人工 inter-rater agreement 差不多）。生产 eval 默认就用这个。
Tier 3：人工评审（最准但最贵）
抽样让真人打分。适合：
- 上线前最后一道关
- 对比新旧 prompt 时一锤定音
- 用户反馈"答得不好"的 case 找根因
每个 case ≈ 5-10 min 人工时间。50 个 case 一次评审 1 个工时。
工具
| 工具 | 主打 | 价格 |
|---|---|---|
| Langfuse | 开源、自托管、track + eval 一站式 | Free / 自部署 |
| Braintrust | SaaS、UI 漂亮、CI 集成好 | $39+/月 |
| OpenAI Evals | 开源框架、很多内置 eval | Free |
| DeepEval | 开源 Python lib | Free |
| Phoenix (Arize) | 开源 + 商业版 | Free / 商业 |
起手推荐 Langfuse：免费、能 self-host、log 和 eval 一起做。匠人内部用 Langfuse track 所有 LLM 调用 + 跑 daily eval。
Regression Test：每次改 prompt 必跑
CI 里加一步：每次 prompt 文件改了，自动跑 golden set + LLM-as-judge：
# .github/workflows/llm-eval.yml
on:
pull_request:
paths:
- 'src/common/prompts/**'
jobs:
eval:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm install
- run: npm run eval
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
- name: Comment PR with eval results
run: # post results to PR
匠人内部 prompt 改动必须过 eval baseline 才能 merge。这是把"AI 质量"工程化的关键 lever。
Eval 不止改 prompt 时跑
生产监控里每天定时跑 eval：
- 同样的 50 个 query，每天跑一遍
- 模型升级 / Anthropic 自己改了底层模型 → eval 分数漂移
- 提前发现"还没人投诉但效果偷偷下降"
匠人有一个 daily-eval cron，每天早上 9 点跑，分数低于 baseline 5% 就 page on-call。
实战 Eval 例子（匠人简历分析功能）
数据
50 条真实简历样本（脱敏 + 标注后人工标准答案）。
Eval 维度
metrics = {
"技能提取准确率": "提取的技能列表 vs 真实技能列表（F1）",
"工作年限误差": "abs(predicted_years - actual_years)",
"教育背景分类": "exact match",
"总评质量": "LLM-as-judge 1-5 分"
}
跑 eval（伪代码）
for case in golden_set:
output = analyze_resume(case.resume)
metrics["技能提取准确率"].append(f1_score(output.skills, case.expected_skills))
metrics["工作年限误差"].append(abs(output.years - case.expected_years))
metrics["教育背景分类"].append(output.education == case.expected_education)
judge_score = await llm_judge(case.expected, output)
metrics["总评质量"].append(judge_score)
print(aggregate_metrics(metrics))
结果（真实数据）
| Prompt 版本 | 技能 F1 | 年限 MAE | 教育 acc | 总评（1-5） | Cost/1K calls |
|---|---|---|---|---|---|
| v1.0 (Sonnet, no few-shot) | 0.71 | 1.3 | 0.83 | 3.4 | $4.50 |
| v1.1 (+ 5 few-shot) | 0.85 | 0.8 | 0.91 | 4.1 | $4.80 |
| v1.2 (+ XML output) | 0.89 | 0.7 | 0.94 | 4.2 | $4.80 |
| v2.0 (Haiku, ported) | 0.84 | 0.9 | 0.92 | 4.0 | $1.20 |
最终上 v2.0：质量略降但成本降到 1/4，性价比最优。没有 eval 你做不出这种决策。
本章小结
- 99% 场景不要 fine-tune，优先 RAG + Prompt
- 真要 fine-tune：风格严 / 极低 latency / 强 domain / privacy 必本地
- Eval 三档：golden set 关键词 → LLM-as-judge → 人工
- LLM-as-judge 必须用更强的模型评，否则有偏
- prompt 改 / 模型变 / 上线前都跑 regression eval
- 工具默认 Langfuse 自托管，CI 集成跑 eval
下一章讲生产部署：latency / cost / observability / safety 四件套。
