微调还是RAG?4组对比实验跑完,混淆矩阵的数据让我重新选了技术路线去年底团队接到一个企业知识库问答项目,要求用内部几千份文档做精准 QA。生成式AI 落地,大家首先想到的是给大模型灌知识,但到底微调还是 RAG,组里吵了一周没结论。老板让我负责技术选型,我拍胸脯说两周内出结果。那两周我搭了 4 组对比实验,每天盯着混淆矩阵算精确率、召回率,最后数据出来的时候我沉默了--直觉全错。现在回想,如果当时我已经系统学过机器学习基础,就不会连混淆矩阵的假阴性都解读错。后来我补了机器学习入门,才把评估指标的坑填平--那门课里有一整个小节用混淆矩阵讲二分类与多分类的业务代价,直接把我之前做实验时「只看准确率」的错误思路纠正过来。项目背景:为什么微调和 RAG 让团队吵翻了需求看似简单:用户输入问题,系统基于内部知识库给出准确回答,不能瞎编。架构组力推微调,说一次性把知识压进模型权重,推理快、可控;应用组坚持 RAG,说知识更新快、不用重训。两边都有道理,但没人能拿出自己方案「不会出幻觉」的证据。我当时对机器学习管道的理解还停留在「跑个脚本就完事」,根本没意识到无论是微调还是 RAG,都需要一套完整的评估体系。后来学AWS 机器学习系列课程时,讲师反复强调:做生成任务先定义业务指标,然后逐层分解到模型指标。这个观点让我重新审视了自己的实验设计。实验设计:4 组配置背后的考量我从公司文档库抽了 2000 条问答对作为测试集,每条包含问题、正确答案、以及 3 条干扰项。为了让对比公平,我把微调组和 RAG 组都限定在同一个基础模型上。唯一不同的是知识注入方式。在准备训练数据时,我犯了一个后来在机器学习入门课程里被多次警告的错误:没有做合理的数据预处理。微调用的指令数据集里,很多问题-答案对其实包含了同一个答案的不同问法,这导致模型在验证时对于相似问法过度自信,后续混淆矩阵里假阳性飙升。这里贴一下我当时构造评估数据的代码片段:# 构造评估标签:0无关,1部分相关,2完全匹配 import json test_cases [] with open(qa_pairs.jsonl) as f: for line in f: item json.loads(line) # 人工标注时犯的错:把近似答案也标成了 2,导致后续召回率虚高 test_cases.append({ question: item[q], answer: item[a], label: 2 if item[a] in item[gold_answers] else 1 })后来我在AWS 基础知识里的数据处理模块里看到,这种标注歧义应该用多级评分并做一致性校验,否则整个评估基准就是歪的。微调方案:训练过程与混淆矩阵分析我用了低秩适配的方式做指令微调,训练了 3 个 epoch。每轮验证时,我都会跑一遍混淆矩阵来观察每个类别的预测分布。训练 loss 降得很快,验证准确率冲到了 0.91,组里一阵欢呼。但当我拆开混淆矩阵看细节,才发现问题:模型对「部分相关」类别的召回率只有 0.58,大量本该标为「部分相关」的答案被直接判成了「无关」。这就是我在开篇说的「假阴性」灾难。from sklearn.metrics import confusion_matrix, classification_report y_true [2,1,0,2,1,1,0,2] # 简化示例 y_pred [2,0,0,2,0,1,0,2] # 微调模型的预测 cm confusion_matrix(y_true, y_pred, labels[0,1,2]) print(cm) # [[3 0 0] # [2 1 0] - 类别 1 的召回率只有 1/3 ≈ 0.33 # [0 0 3]]这种模式如果上线,用户搜一个模糊问题,系统要么甩一个毫不相关的答案,要么直接说「不知道」,体验极差。我这才想起机器学习基础里讲过拟合时提过:验证集准确率虚高,往往是因为模型只记住了训练数据的表层关联,而没有学到语义匹配。RAG 方案:检索链与生成效果评估RAG 这边的坑更多集中在检索阶段。我用向量数据库存文档块,然后把检索到的 top-k 片段塞进提示词里让模型作答。初期效果很差,生成结果经常张冠李戴。我对 RAG 的输出也构造了混淆矩阵,以最终答案是否包含正确信息、是否凭空捏造作为分类标签。结果触目惊心:幻觉类(即生成了文档里没有的内容)的假阳性率高达 31%,而真正匹配答案的召回率才 0.62。排查下来,根因在特征工程。文档块的切分策略太粗暴,把一段完整的技术规范硬生生拆成了两个语义碎片,检索时永远只能命中一半。后来的机器学习课程里专门有一章讲文本嵌入前的 chunk 设计,我照着里面介绍的滑动窗口加语义边界切分方法改了代码,混淆矩阵里幻觉那一栏的假阳性立刻从 31% 降到了 9%。# 改进后的文档切分:按 Markdown 标题层级 固定窗口 overlap def semantic_chunk(text, max_len512, overlap50): sections text.split(\n## ) chunks [] for sec in sections: words sec.split() for i in range(0, len(words), max_len - overlap): chunk .join(words[i:imax_len]) chunks.append(chunk) return chunks这个改动不涉及模型训练,但效果立竿见影。我开始理解为什么机器学习管道不能只盯着模型调参--数据层的优化有时比改损失函数更有用。实验结果对比:一张混淆矩阵表格推翻了我的直觉我把四组实验(微调基线、微调数据增强、朴素 RAG、RAG优化检索)的评估混淆矩阵汇总成了一张表,直接看业务指标:方案精确率召回率F1幻觉率维护成本微调基线0.910.670.775%高(重训需 GPU)微调增强0.890.780.834%更高朴素 RAG0.640.620.6331%中RAG优化0.860.850.859%低(更新文档即可)直觉上我们都以为微调准确率高就应该赢,但混淆矩阵说清楚了另一件事:在知识更新频繁的场景,RAG 只要把检索做好,整体的 F1 可以超过微调,而且幻觉率可控。最终我给老板的建议是走 RAG优化的路线,同时保留微调能力以备后用。这份混淆矩阵驱动的选型报告,后来成了组里的参考模板。我甚至把它写进了个人技术笔记,每次回头看都庆幸自己补了机器学习入门那门课--如果还是当初那个只会看准确率的状态,大概率会坚持一个费力不讨好的方案。补课之旅:从机器学习入门到 AWS 深度学习,我重新理解了评估实验做完后,我意识到自己缺的不是调包技能,而是一套系统的机器学习思维。我开始系统补课,第一门就是机器学习入门。这门课用非常直观的案例讲解了监督学习、模型评估、过拟合与欠拟合,尤其是「混淆矩阵在业务中的应用」那一章,把我从只看准确率的惯性里彻底拉了出来。接着我又深入学了机器学习基础,搞懂了机器学习管道的完整构建流程,从数据预处理到特征工程再到超参调优,每一环都对应着实验里踩过的坑。比如为什么 RAG 的检索精度可以通过 chunk 策略改善,本质上就是一个特征表示的问题。为了理解大模型推理的效率优化,我还翻了一遍AWS 深度学习课程,里面讲模型部署与推理加速的部分,让我后续在 RAG 推理延迟上做了不少优化。而人工智能入门则帮我补上了生成式 AI 的全局视角--从成本模型到安全审核,这些都不再是只懂模型的算法工程师能忽略的事。这里我特别想提一下亚马逊云科技机器学习系列课程的编排:它不是枯燥的理论罗列,而是每个概念都跟着一个可复现的实验。就比如混淆矩阵那一节,直接给了一个客服工单分类的 Jupyter Notebook,你可以在 AWS 的免费算力上跑通整个评估流程。我就是通过那个 notebook 彻底理解了怎么用混淆矩阵反推业务指标。所以如果现在有人问我如何入门,我第一句话就是:去把AWS 基础知识里的机器学习线跑一遍,比你零散搜博客高效十倍。给同行的建议:落地生成式 AI 前务必搞懂的几件事从那段两周选型实验到后来系统补课,我总结了 5 条可执行的经验,送给同样在微调和 RAG 之间摇摆的工程师:先建立评估体系,再动手做实验。没有混淆矩阵和业务指标对齐,你做的所有优化都是盲猜。不要只盯着模型准确率。去学机器学习基础,把精确率、召回率、假阳性代价这些概念吃透,尤其是生成式场景下幻觉率和召回率往往比精确率更重要。RAG 的上限瓶颈在数据管道,不在大模型。投入时间做好数据预处理和块切分,效果远大于盲目换更大的检索模型。这一点机器学习管道的相关课程会给你一套方法论。微调和 RAG 不是非此即彼。可以在 RAG 基础上做轻量微调,兼顾知识新鲜度和生成质量,前提是你已经通过深度学习入门理解了模型参数更新的成本与收益。系统学习比碎片搜索更划算。我花在踩坑上的时间如果折半,省下的精力够完整刷完人工智能入门、机器学习入门和深度学习基础。这几门课之间有明确的路径衔接,跟着走一遍,比零散看博客建立体系的速度快得多。回头再看混淆矩阵,你会觉得它不再是一张表,而是一把直接切进业务逻辑的刀。这 5 条的背后,其实都有一个共同的起点:把机器学习的评估能力内化成自己的本能反应。如果你的下一个项目也要做选型,不妨先把AWS 机器学习中的评估章节跑一遍,再回来设计实验。你会发现,很多争论在混淆矩阵面前自动就停了。