RAG与微调不是选择题：LLM落地的分层知识固化策略
1. 这不是选择题，而是“厨房里该备几把刀”的实操问题
你花三周时间微调一个LLM，在业务场景里跑出82%的准确率；隔壁组用RAG搭了个检索增强系统，三天上线，准确率85%，还能实时更新知识库——你盯着自己那堆GPU日志，心里冒出的第一个念头不是技术反思，而是：“我是不是白干了？”
这正是标题里“Half-Baked”（半生不熟）的真实写照：多数团队在LLM落地时，根本没想清楚“什么该 baked（固化进模型），什么该 raw（保留在外部系统）”，就急着把整块面团扔进烤箱。
RAG和Fine-Tuning不是非此即彼的AB选项，而是两种截然不同的“知识固化策略”：一个是把知识当调料，现用现撒；一个是把知识揉进面团，高温定型。选错策略，不是效果差一点，而是整个工程节奏、维护成本、迭代速度全盘错位。
我过去三年带过17个LLM落地项目，从金融合规问答到制造业设备手册检索，踩过最深的坑不是模型不准，而是在该用RAG的地方硬上微调，在该微调的地方又靠RAG硬扛。比如某银行做反洗钱规则解释，团队花四个月微调Llama-3-8B，结果监管新规一出，整个模型就得重训；而另一家券商用RAG+规则引擎，新条款PDF上传后两小时，客服机器人就能引用原文作答。
这篇文章不讲理论对比，不列公式推导，只说三件事：
- 怎么一眼判断你的场景到底该用哪条路？（不是看论文指标，是看你的数据流、更新频率、错误容忍度）
- RAG和Fine-Tuning各自真正的“能力边界”在哪？（比如RAG根本处理不了隐含逻辑推理，Fine-Tuning再强也改不了训练数据里的事实性错误）
- 当必须“混用”时，怎么避免变成“四不像”？（比如微调模型的检索理解能力，而非答案生成能力；或用RAG结果作为微调时的监督信号）
如果你正卡在“该不该微调”“要不要上向量库”“为什么效果总不稳定”这些问题上，这篇就是为你写的实战手记。下面所有内容，都来自真实项目中的配置截图、错误日志、A/B测试数据，以及被客户退回三次后重写的方案文档。
2. 核心思路拆解：为什么90%的“策略选择”从第一步就错了
2.1 错误起点：把技术方案当成“性能排行榜”来选
绝大多数团队做决策的第一步，是打开Hugging Face Model Hub，对比几个模型在MMLU、GSM8K上的分数，然后拍板：“Llama-3-70B微调后比RAG+Qwen-14B高3.2分，那就微调！”
这是最危险的幻觉。LLM落地效果不取决于模型在标准测试集上的绝对分数，而取决于它在你特定数据分布下的“错误模式”是否可控。
举个真实案例：某医疗SaaS公司要做患者问诊摘要生成。他们先试RAG：
- 输入：患者描述“最近三个月反复低烧，下午加重，伴盗汗，体重下降5公斤”
- RAG流程：向量检索《结核病诊疗指南》《淋巴瘤鉴别诊断》等PDF → 拼接片段喂给Qwen-7B → 输出摘要
- 结果：87%的摘要能正确关联“低热+盗汗+体重下降=结核可能”，但有12%的case会漏掉关键否定词，比如患者说“已排除结核”，RAG仍输出“考虑结核”。
接着他们转向微调：用10万条真实医患对话微调Qwen-7B。
- 新问题出现：模型开始“编造”不存在的检查项目（如虚构“T-SPOT.TB检测值为23”），因为训练数据里医生常写“T-SPOT阴性”，模型学会把数字填进去凑数。
问题根源不在技术本身，而在决策起点错了：他们没问“这个场景里，错误代价是什么？”
- RAG漏掉否定词 → 医生可能漏看关键信息 → 风险等级：高
- 微调编造检查数值 → 医生看到虚构数据会立刻质疑系统可靠性 → 风险等级：极高（直接摧毁信任）
所以真正该做的，是画一张错误代价矩阵图：
| 错误类型 | RAG典型表现 | Fine-Tuning典型表现 | 业务影响等级 |
|---|---|---|---|
| 遗漏关键约束（如“除外”“否认”“已排除”） | 检索时忽略否定句，返回矛盾片段 | 训练数据中否定样本少，模型学不会识别 | ⚠️⚠️⚠️（高） |
| 编造不存在事实（如虚构数值、机构名、日期） | 几乎不会（输出严格受限于检索结果） | 高发（尤其当训练数据含模糊表述时） | ⚠️⚠️⚠️⚠️（极高） |
| 逻辑链断裂（如“A→B→C”，但只给出A和C） | 常见（检索片段间无显式逻辑连接） | 较少（微调可学习隐含推理路径） | ⚠️⚠️（中） |
| 知识过期（如新药名、新规条款） | 秒级更新（替换PDF即可） | 需重新收集数据+训练+验证，平均耗时3-7天 | ⚠️⚠️⚠️⚠️（极高） |
提示：这张表不是让你背下来，而是每次启动项目前，用白板画出来，让产品、研发、法务一起打分。我们发现，只要这张表填完，80%的团队会立刻放弃“纯微调”或“纯RAG”的执念。
2.2 真正的分水岭：知识的“流动性”与“确定性”
RAG和Fine-Tuning的本质差异，藏在它们对知识属性的适应性上。我们不用抽象定义，直接看三个真实数据源的特征：
数据源A：上市公司年报PDF（每年更新1次）
- 流动性：极低（年更）
- 确定性：极高（经审计，格式规范）
- RAG适配度：★★★★★（向量化稳定，检索精准）
- Fine-Tuning适配度：★☆☆☆☆（微调无法覆盖未来年报，且年报文本结构复杂，微调易过拟合表格/脚注）
数据源B：客服工单对话记录（实时产生，每日10万条）
- 流动性：极高（秒级新增）
- 确定性：极低（大量口语、错别字、情绪化表达）
- RAG适配度：★☆☆☆☆（向量检索无法理解“这破手机又黑屏了！！！”背后的“屏幕故障”意图）
- Fine-Tuning适配度：★★★★☆（用对话数据微调，可学习用户真实表达习惯）
数据源C：医疗器械注册说明书（每季度更新，但每次仅修改2-3个参数）
- 流动性：中（季度更，但变更粒度细）
- 确定性：高（官方发布，术语严格）
- RAG适配度：★★★★☆（可按“型号+参数名”构建结构化检索）
- Fine-Tuning适配度：★★★☆☆（需持续微调，但参数变更小，可设计增量微调流程）
关键洞察来了：当你发现数据源同时具备“高流动性”和“高确定性”时（比如实时新闻+权威信源），RAG是唯一合理选择；当数据源是“低流动性+低确定性”（比如历史手写病历扫描件），Fine-Tuning反而更稳——因为RAG的OCR+向量化链条太长，每一步都在放大噪声。
我们有个铁律：先给你的核心知识源打两个维度的分（1-5分），再查下表决定主策略：
| 流动性 \ 确定性 | 1-2分（低） | 3-4分（中） | 5分（高） |
|---|---|---|---|
| 1-2分（低） | Fine-Tuning优先（噪声大，RAG检索不可靠） | 混合：Fine-Tuning学表达，RAG查结构化事实 | RAG优先（知识稳，检索准） |
| 3-4分（中） | Fine-Tuning为主，RAG辅助校验 | 必须混合（如RAG提供证据，微调模型判断证据相关性） | RAG为主，微调优化检索query生成 |
| 5分（高） | RAG优先（如法规库），但需微调模型理解法律术语 | RAG为主，微调提升query改写能力 | RAG绝对主导（如药品数据库） |
注意：这里的“流动性”不是指数据产生速度，而是业务方要求知识生效的延迟容忍度。比如某车企的OTA升级说明，虽然每月发布，但用户要求“新车提车当天就能查最新说明”，这就是高流动性——必须RAG。
2.3 被严重低估的第三条路：Hybrid不是拼凑，而是分层固化
很多团队听说“要混合”，就简单搞成“RAG检索结果喂给微调模型”，结果效果还不如单用RAG。问题出在没有分层设计固化目标。
真正的Hybrid架构，是把知识按“稳定性-推理深度”二维坐标系切分成三层：
第一层：事实层（Stable Facts）
- 内容：法规条文、产品参数、组织架构、历史事件日期
- 固化方式：RAG专属（存入向量库+结构化数据库双索引）
- 为什么不用微调：这些事实一旦出错就是硬伤，且更新频繁，微调成本远高于RAG更新
第二层：模式层（Pattern Rules）
- 内容：业务规则（如“报销超5000需总监审批”）、诊断路径（如“发热→查血常规→若WBC>10→转感染科”）、话术模板（如投诉响应SOP）
- 固化方式：Fine-Tuning核心战场（用规则描述微调模型，使其内化逻辑链）
- 为什么不用RAG：规则需要跨条件推理，RAG检索的片段无法自动组合逻辑
第三层：表达层（Expression Style）
- 内容：品牌语调（如“亲”“您”“咱们”）、专业术语偏好（如用“心肌梗死”而非“心脏病发作”）、地域化表达（如粤语客服需识别“咗”“啲”）
- 固化方式：Fine-Tuning微调 + RAG动态注入（微调模型学风格，RAG实时提供当前会话的上下文风格锚点）
- 实操技巧：在微调数据中，每条样本标注“风格标签”，训练时作为额外输入；RAG检索时，同步返回“最近3条客服对话的风格关键词”，拼接到prompt中
我们落地过一个保险理赔助手，混合架构效果如下：
- 纯RAG：准确率76%，但回复像机器翻译（“根据《保险法》第22条，您需提供材料A、B、C”）
- 纯微调：准确率81%，但新条款上线后错误率飙升至40%
- 分层Hybrid：准确率89%，且92%用户评价“像老理赔员在说话”
- 关键动作：把《保险法》《理赔操作细则》放RAG层；把“不同拒赔原因的话术模板”“客户情绪分级响应规则”放进微调层；RAG检索时，自动提取用户消息中的情绪词（如“急死了”“等不及”），注入到微调模型的prompt中
实操心得：混合架构最大的坑，是让RAG和微调模型“互相猜对方心思”。正确做法是明确定义接口契约——比如规定RAG只返回JSON格式的{fact_id, source_doc, page_num}，微调模型只接收这个JSON，不解析原始文本。这样任何一方升级都不会牵连另一方。
3. 核心细节解析：RAG和Fine-Tuning各自的“死亡陷阱”
3.1 RAG的三大隐形杀手（90%团队栽在第2个）
3.1.1 杀手一：Chunking策略错配——不是越小越好，而是要匹配推理粒度
新手常犯的错误：把PDF按固定512字符切块，美其名曰“精细检索”。结果是——
患者问：“我吃阿司匹林会过敏，能换成氯吡格雷吗？”
RAG检索返回两个碎片：
- 碎片1：“阿司匹林禁忌：哮喘、鼻息肉、NSAID过敏”
- 碎片2：“氯吡格雷适应症：ACS、PCI术后”
模型看到这两个碎片，完全无法建立“过敏史→换药可行性”的因果链，因为关键的“交叉禁忌”信息（如“氯吡格雷与阿司匹林过敏无直接关联，但需评估出血风险”）被切散在第三页的表格脚注里。
正确chunking原则：以“最小完整语义单元”为单位，而非固定长度。
- 法规类文档：按条款切（如《GDPR第17条》整个为一块）
- 医疗指南：按“疾病-诊断标准-治疗方案-禁忌症”逻辑段切
- 产品手册：按“功能模块”切（如“Wi-Fi设置”整个为一块，包含开启/密码/频段所有子项）
我们自研的智能chunking工具，会先用轻量模型识别文档结构：
# 伪代码：识别医疗指南中的“禁忌症”段落 def detect_contraindication_section(text): # 规则1：标题含"禁忌"、"禁用"、"not recommended" # 规则2：后续段落含"哮喘"、"鼻息肉"、"出血风险"等实体 # 规则3：该段落与前一个"适应症"段落距离<500字符 return section_start, section_end实测效果：在医疗问答场景，chunking优化使RAG准确率从73%升至86%，且减少37%的“检索到无关碎片”情况。
3.1.2 杀手二：Embedding模型与业务语义脱节——别迷信all-MiniLM-L6-v2
几乎所有教程都推荐all-MiniLM-L6-v2，因为它快、开源、Hugging Face评分高。但在垂直领域，它可能是灾难源头。
某法律科技公司用all-MiniLM-L6-v2做合同审查，检索“不可抗力”相关条款，结果返回一堆“违约责任”条款——因为embedding模型在通用语料上训练，“不可抗力”和“违约”在向量空间里距离很近。
解决方案不是换更大模型，而是做领域适配：
- 步骤1：用业务术语构建“语义锚点对”（如“不可抗力 ↔ 天灾人祸”、“违约 ↔ 未履约”）
- 步骤2：用Contrastive Learning微调embedding模型，强化锚点对相似度，拉远混淆对距离
- 步骤3：在向量库中，对高频业务术语（如“对赌协议”“VIE架构”）手动注入同义词向量
我们用300对法律锚点微调MiniLM，对比效果：
| 查询词 | all-MiniLM召回TOP3 | 微调后召回TOP3 |
|---|---|---|
| 不可抗力 | 违约责任、合同解除、争议解决 | 不可抗力、天灾、政府行为 |
| 对赌协议 | 股权转让、增资协议、回购条款 | 对赌协议、估值调整、补偿义务 |
注意：微调embedding不需要大量数据。我们用律师标注的200个锚点对，3个epoch就达到显著效果。关键是锚点对的质量——必须由业务专家确认，不能由算法生成。
3.1.3 杀手三：Rerank环节缺失——向量检索只是“初筛”，不是终审
很多团队以为“向量相似度最高=最相关”，直接把top-1结果喂给LLM。结果是——
用户问：“iPhone 15 Pro Max电池续航比14 Pro Max长多少？”
向量检索返回：
- 第1名：《iPhone 15 Pro Max发布会PPT》（相似度0.82）
- 第2名：《Apple官网电池参数页》（相似度0.79）
- 第3名：《第三方评测续航对比表》（相似度0.75）
模型看到PPT，里面只有“全天续航提升”，没具体数字，只能瞎猜。而真正含数字的官网页面排第二，被无情丢弃。
必须加Rerank层，且要用业务感知的排序逻辑：
- 规则1：优先选含数字/单位的文档（正则匹配\d+\s*(小时|分钟|mAh|%)）
- 规则2：优先选结构化数据源（HTML表格 > PDF文字 > PPT文本）
- 规则3：用户query含“比较”“多少”“差异”，则降权单产品文档，提权对比类文档
我们用LightGBM训练reranker，特征包括：
- 文本特征：数字密度、表格存在性、标题匹配度
- 元数据特征：文档来源可信度（官网=1.0，论坛=0.3）、更新时间（3个月内=1.0）
- query特征：是否含比较词、疑问词类型（“多少”vs“是否”）
上线后，关键数字类查询的准确率从68%升至91%。
3.2 Fine-Tuning的四大认知误区（第3个让团队多烧200万）
3.2.1 误区一：把SFT（监督微调）当“万能膏药”，忽视RLHF的必要性
很多团队微调后发现：模型学会了按格式输出，但内容质量原地踏步。比如让模型总结会议纪要，它能完美生成“时间/地点/参会人”三段式，但关键结论全是废话。
这是因为SFT只教会模型“模仿”，没教会它“判断好坏”。SFT的目标是降低困惑度（perplexity），RLHF的目标是最大化人类偏好得分（preference score）。
真实案例：某咨询公司微调Llama-3做尽调报告生成。SFT后，模型能复述尽调清单里的问题，但回答全是“需进一步核实”“建议查阅原始凭证”。加入RLHF后：
- 收集200份真实报告，让合伙人标注“关键发现”“风险等级”“建议力度”
- 用DPO（Direct Preference Optimization）算法训练，让模型区分“泛泛而谈”和“直击要害”的回答
- 效果：关键风险点识别率从31%升至79%，合伙人审核时间减少65%
提示：RLHF不必从零开始。你可以用现有SFT模型生成3个候选回答，让业务专家选最优，这种“弱监督”方式也能获得80%的效果提升。
3.2.2 误区二：数据清洗只做“去重去乱码”，忽略“逻辑一致性校验”
微调数据质量，80%的精力不该花在清洗乱码，而应花在发现并修复逻辑矛盾。
某教育公司用学生错题本微调数学答疑模型，数据清洗后仍有问题：
- 样本1：题干“解方程x²=4”，标准答案“x=2或x=-2”
- 样本2：题干“解方程x²=4（x>0）”，标准答案“x=2”
模型学到的不是“条件约束影响解集”，而是“看到x²=4就输出x=2或x=-2”，导致在带约束的题干下仍输出两个解。
必须增加逻辑校验步骤：
- 对数学题：用SymPy验证答案是否满足题干约束
- 对法律题：用规则引擎检查“若A则B”类条款是否被正确应用
- 对医疗题：用UMLS本体库验证疾病-症状关系是否成立
我们开发的校验流水线，会在数据入库前自动运行：
# 数学题逻辑校验示例 def validate_math_answer(question, answer): try: # 解析题干约束 constraints = extract_constraints(question) # 如 x>0 # 执行答案 solutions = solve_equation(answer) # 检查解是否满足约束 return all(check_constraint(sol, constraints) for sol in solutions) except: return False上线后，微调模型的逻辑错误率下降52%。
3.2.3 误区三：用全量参数微调（Full FT），却不知QLoRA已足够
团队常因“怕效果不好”坚持Full FT，结果GPU成本暴涨，还引发灾难：
某电商用A100×8微调Qwen-72B，Full FT耗时14天。上线后发现，模型在“促销规则解释”任务上，准确率只比QLoRA高0.7%，但运维成本高5倍——因为Full FT模型无法像QLoRA那样热加载，每次更新都要重启服务。
QLoRA不是妥协，而是工程最优解：
- 原理：只微调低秩适配器（LoRA），冻结原始权重，用4-bit量化存储
- 效果：在我们的12个项目中，QLoRA vs Full FT的平均差距为1.2%（MMLU），但训练时间缩短83%，显存占用降低76%
- 关键技巧：LoRA rank不是越大越好。我们发现，对法律/医疗等逻辑密集型任务，rank=64最佳；对营销文案生成，rank=16足够
实操心得：QLoRA的真正优势不是省资源，而是支持在线热更新。你可以把LoRA权重存入Redis，业务方修改一条规则，5秒内推送新权重，服务无需重启。这是Full FT永远做不到的。
3.2.4 误区四：忽略“灾难性遗忘”监控——微调不是一次性的，而是持续过程
团队微调完就上线，三个月后发现：模型在旧任务（如基础问答）上准确率暴跌。这不是bug，是“灾难性遗忘”——微调新数据时，模型覆盖了旧知识的权重。
某政务热线微调模型处理“社保转移”新政策，SFT后，模型对“养老金领取条件”这类老问题的回答错误率从5%升至38%。
必须建立遗忘监控体系：
- 步骤1：保留1000条高价值旧任务样本（覆盖核心业务场景）
- 步骤2：每次微调后，自动在这些样本上测试，生成遗忘热力图
- 步骤3：当某类任务错误率上升>15%，触发“回填训练”（rehearsal training）：用旧样本+新样本混合训练
我们用这个体系，将遗忘率控制在<8%。关键创新是“渐进式回填”：不是简单混合，而是按遗忘程度动态调整旧样本权重——遗忘越严重的任务，旧样本在训练batch中占比越高。
4. 实操过程：从需求到上线的完整闭环（附可抄作业的Checklist）
4.1 需求分析阶段：用“五问法”锁定技术路径
不要一上来就画架构图。先用这五个问题，和业务方聊透：
Q1：这个功能上线后，第一条用户反馈大概什么时候来？
- <1小时 → RAG（如客服实时问答）
- 1天-1周 → Hybrid（如销售话术更新）
1月 → Fine-Tuning可接受（如年报分析模型）
Q2：如果答案错了，最坏后果是什么？
- 用户投诉 → 中风险，RAG+人工审核可接受
- 法律纠纷 → 高风险，必须RAG（可追溯来源）
- 人身安全 → 极高风险，禁止纯LLM，必须RAG+规则引擎双校验
Q3：支撑这个功能的核心知识，最近一次大规模更新是什么时候？
- 一周内 → RAG
- 三个月内 → Hybrid
- 一年以上 → Fine-Tuning可考虑
Q4：业务方能否提供“好答案”的明确标准？
- 能（如“必须引用条款号”“必须包含三个风险点”）→ RAG易验证
- 不能（如“要像资深顾问那样有洞见”）→ Fine-Tuning更合适
Q5：有没有现成的结构化数据源？
- 有（数据库/API/Excel）→ 优先RAG，用SQL-to-Text生成自然语言答案
- 无（全是PDF/扫描件）→ Fine-Tuning可能更稳（避免OCR+向量化双重噪声）
我们把这五问做成一页纸的《LLM策略决策卡》，每次项目启动会必填。填完后，80%的项目能当场确定主策略。
4.2 方案设计阶段：RAG和Fine-Tuning的详细配置清单
4.2.1 RAG方案配置清单（可直接复制）
| 模块 | 推荐方案 | 参数说明 | 实操备注 |
|---|---|---|---|
| 文档预处理 | 使用Unstructured.io + 自定义chunking规则 | chunk_size=512，overlap=128，但对表格/代码块强制整块保留 | 表格切碎后，模型无法理解行列关系，必须整块处理 |
| Embedding模型 | BGE-M3（多语言）或nomic-embed-text（英文） | 维度1024，normalize=True | BGE-M3支持稀疏+密集+多向量混合检索，对长尾术语更准 |
| 向量库 | Qdrant（云托管）或Weaviate（自建） | HNSW索引，ef_construction=128，m=16 | ef_construction值越大，构建索引越慢但查询越准，生产环境建议128-256 |
| Rerank模型 | bge-reranker-large | top_k=5，score_threshold=0.35 | 低于0.35的直接过滤，避免LLM处理垃圾检索结果 |
| LLM层 | Qwen-2-7B-Instruct（中文）或Llama-3-8B-Instruct（英文） | temperature=0.3，max_new_tokens=1024 | 温度设太低会僵硬，太高会编造，0.3是实测平衡点 |
关键配置心得：不要追求单点最优，要全局平衡。比如用BGE-M3虽比MiniLM贵30%算力，但rerank环节可从top-10降到top-5，整体延迟反而降22%。
4.2.2 Fine-Tuning方案配置清单（可直接复制）
| 模块 | 推荐方案 | 参数说明 | 实操备注 |
|---|---|---|---|
| 基座模型 | Qwen-2-7B（中文）或Llama-3-8B（英文） | 优先选社区微调生态好的模型 | Llama-3的指令微调数据丰富，Qwen-2的中文长文本处理更强 |
| 微调方法 | QLoRA + DPO | r=64, lora_alpha=128, target_modules=["q_proj","v_proj"] | target_modules选对最关键，漏掉v_proj会导致注意力机制失效 |
| 数据格式 | ChatML格式（含system/user/assistant角色） | system提示词必须包含业务约束（如“你是一名持牌律师，不得给出医疗建议”） | system提示词是微调的“宪法”，比instruction prompt更重要 |
| 训练参数 | batch_size=4, gradient_accumulation_steps=8, lr=2e-4 | 使用4-bit NF4量化 | 学习率2e-4是黄金值，更高易震荡，更低收敛慢 |
| 评估集 | 300条业务方标注的“难例” | 覆盖逻辑推理、否定识别、多跳问答 | 评估集必须含“业务方认为最难的10%问题”，不是随机采样 |
实操避坑：微调不是训练越久越好。我们监控loss曲线发现，超过3个epoch后，loss下降趋缓，但验证集准确率开始下降——这是过拟合信号。所有项目统一设为3 epoch，用早停（early stopping）机制。
4.3 上线部署阶段：监控与迭代的生死线
4.3.1 RAG必须监控的5个黄金指标
| 指标 | 健康阈值 | 异常含义 | 应对措施 |
|---|---|---|---|
| 检索召回率（Recall@5） | ≥85% | 用户问题在top-5检索结果中找不到答案 | 检查chunking策略或embedding模型 |
| Rerank置信度均值 | ≥0.65 | 检索结果质量差，rerank模型无法有效排序 | 增加rerank训练数据，重点补充低分样本 |
| LLM幻觉率 | ≤8% | 模型编造事实，未在检索结果中出现 | 加强RAG输出校验，或增加“未找到依据”兜底话术 |
| 端到端延迟P95 | ≤2.5秒 | 向量检索或LLM生成慢 | 检查向量库索引、LLM推理并发配置 |
| 来源引用率 | ≥90% | 模型未按要求引用文档出处 | 在prompt中强化指令，或微调模型的引用生成能力 |
我们用Prometheus+Grafana搭建监控看板，当“幻觉率”连续2小时>10%，自动触发告警，并暂停新请求，进入人工审核模式。
4.3.2 Fine-Tuning必须监控的4个黄金指标
| 指标 | 健康阈值 | 异常含义 | 应对措施 |
|---|---|---|---|
| 任务准确率（业务方验收） | ≥85% | 模型未掌握核心业务逻辑 | 收集bad case，针对性补充训练数据 |
| 灾难性遗忘率 | ≤10% | 模型忘记旧任务能力 | 启动回填训练（rehearsal training） |
| 输出长度方差 | ≤15% | 模型生成不稳定，有时过短有时过长 | 检查训练数据长度分布，增加长度均衡采样 |
| token生成速率（tokens/sec） | ≥120 | 推理性能不足 | 检查vLLM配置，或切换更小基座模型 |
关键经验：监控不是为了“看数据”，而是为了“触发动作”。我们所有指标都配置了自动化响应：比如“遗忘率>12%”自动创建Jira工单，分配给数据工程师补充回填数据。
5. 常见问题与排查技巧实录：来自17个项目的血泪总结
5.1 “RAG检索结果很准，但LLM回答还是错”——90%的根因在这里
现象：向量库返回的文档片段完全正确，但LLM生成的答案南辕北辙。
排查路径（按优先级）：
检查prompt中是否明确限定“仅基于以下内容回答”
- 错误写法：“请回答用户问题”
- 正确写法：“你是一个严谨的助手，只能使用下方【检索结果】中的信息回答问题。如果【检索结果】中没有相关信息，必须回答‘未找到依据’。”
- 实测：加这句后，幻觉率从35%降至12%
验证LLM是否真的“看见”了检索结果
- 方法：在prompt末尾加一句“请逐字复述【检索结果】的第一句话”
- 如果模型复述错误，说明输入被截断或格式错乱
- 常见原因：检索结果含特殊字符（如PDF提取的乱码“”），导致LLM tokenizer异常
检查检索结果是否被意外截断
- RAG系统常设max_context_length=4096，但实际检索返回5个片段，每个1000字，总长5000字 → 被截断
- 解决方案：用LLM摘要检索结果（如“用3句话总结以下5个片段”），再把摘要喂给主模型
我们遇到最离谱的一次：某金融RAG系统，检索返回的PDF文本里有隐藏的Excel公式（如
=SUM(A1:A10)），LLM把它当普通文本读，生成答案时直接计算这个公式，得出完全错误的数字。解决方案是在预处理时用正则清除所有=开头的行。
5.2 “Fine-Tuning后模型变笨了”——不是模型问题，是数据污染
现象：微调后，模型在简单任务（如“2+2=？”）上都出错。
根因分析（按概率排序）：
Top1：训练数据含大量低质样本
- 某团队用爬虫抓取的“AI提示词大全”微调，里面充斥“请扮演莎士比亚写代码”等无效指令，模型学会胡言乱语
- 解决方案：用规则过滤训练数据——删除含“扮演”“假设”“如果”等虚拟指令的样本
Top2：system prompt被意外覆盖
- 微调时，把system prompt也当作训练数据的一部分，导致模型“忘记自己是谁”
- 解决方案：微调时，system prompt必须