1. RAG是什么先用一句话把它说清楚RAGRetrieval-Augmented Generation检索增强生成这几年在自然语言处理领域几乎成了标配热词但真要让一个刚接触的人快速抓住本质其实一句话就够了RAG 就是先让模型从外部知识库里查资料再把查到的资料连同原始问题一起交给大语言模型LLM去生成答案。换句话说它把信息检索和文本生成两件事串成了一条流水线让模型不再只靠脑子里那点训练记忆硬答而是学会先查后答。我是从实际项目里真正体会到这个价值的。去年做某个企业内部知识问答系统甲方老板上来就问能不能让模型读一遍我们的几百份文档然后随便怎么问都答得出来。当时摆在面前的无非两条路要么把文档拿去微调模型要么就做 RAG。最后我选的是 RAG原因后面会详细讲但先说结论如果一个任务的核心是让模型回答那些不在通用能力范围内、且需要持续更新的私有知识RAG 往往是投入产出比最高、坑也相对可控的方案。这篇文章不打算写得像教科书定义条款我想站在我要真刀真枪去做一个问答系统的角度把 RAG 的原理、流程、和微调的差异、以及工程落地时的关键细节一次说透。适合正在选型的技术负责人、刚入门的大模型应用开发者、还有那些被老板一句话难住的工程师们参考。读完之后你至少应该能回答三个问题RAG 到底怎么工作它和微调本质区别在哪什么时候选 RAG、什么时候该咬牙上微调2. 为什么会有RAG大语言模型的两个老毛病2.1 模型只会回忆不会查证先聊背景。大语言模型的底层机制本质上是基于海量语料做概率预测它生成出来的每一个词都是在对下一个最可能出现的词做预测。这意味着模型内部其实是一个巨大的压缩记忆体它存储的是训练语料里的统计规律而不是一本可以随时翻阅的实时资料库。这个机制带来两个直接后果。第一模型的知识都被冻结在训练截止日期那一刻训练完之后世界怎么变化它一概不知。第二模型在回答时会一本正经地把记混了、或者压根不存在的内容说得像真的一样。业内管这个叫幻觉。比如你问模型某个最新发布的产品是否支持某功能如果这个产品发布晚于训练数据模型几乎不可能知道真实答案。它更有可能基于旧的、相似产品的经验生成一段流畅但错误的内容。问题不在于模型笨而在于它根本不知道自己在不知道。RAG 的思路很朴素既然模型不知道那就喂它一份参考资料。让它在回答前先去一个可控的文档库中检索相关内容把检索到的原文片段作为上下文放进提示词里再由模型综合这些资料给出答案。这一下就把模型闭卷考试变成了模型开卷考试而且开卷的参考资料是我们自己指定的。2.2 一个经典场景企业知识问答我拿企业知识问答来举例因为这个场景最能说明 RAG 解决的实际问题。假设一家制造企业有三千多份设备操作手册、维修工单、质检标准和历史故障记录散布在各个部门和共享盘里。工人遇到设备报警想快速知道这个报警意味着什么、按什么顺序排查你去问一个通用大模型它大概率只能泛泛地说请参考设备说明书或者编一个看起来合理的流程。如果用 RAG流程就变成先把三千份文档切块、向量化、存入一个索引库当工人提问时系统把这句提问也向量化去索引里找出最相关的几十段内容然后把原始问题和这些片段拼成一段提示词交给大模型模型阅读这些片段后再综合生成一个带依据的回答。整个过程中模型不记忆这些文档它只是在每一轮请求时现查所以文档更新了答案也跟着变不需要重新训练任何东西。这个场景里 RAG 的价值有三个回答有据可依、知识可以实时更新、并且可以追溯到答案来自哪一份文档。这三点恰恰是微调很难同时满足的。2.3 RAG不是银弹它解决知识接入不解决能力不足不过这里我得泼一盆冷水RAG 不是万能的。它擅长解决的是模型不知道这个知识的问题而不是模型本身能力不够的问题。举个例子如果你想让模型学会一种全新的推理方式比如把 COT思维链应用到极其复杂的多步逻辑题上或者从一段代码里解析出某种特定风格的漏洞RAG 能给模型提供一些例子和参考片段但它无法改变模型底层的推理质量。因为生成能力本身来自模型参数参考材料只是辅助不是器官移植。这也是为什么我的选型逻辑永远是先问自己这个任务失败的原因是知识缺失还是能力缺失知识缺失RAG 优先能力缺失可能得上微调或者换个更强的底座模型。很多人把 RAG 和微调当成二选一的对立方案实际上在复杂系统里两者经常搭配使用只是分工不同。3. RAG 怎么工作从文档入库到答案生成的全流程拆解3.1 离线阶段文档切分与向量化RAG 系统的第一个阶段是索引构建这一步在用户提问之前完成属于离线过程。整个链路通常分为文档加载、文本切分、Embedding 向量化、向量存储四个环节。文档加载没什么特别需要解释的就是从 PDF、Word、Markdown、网页、数据库记录等来源把文本读出来。真正决定检索质量的是切分策略。一段文本太长向量化之后会丢失细节检索时关键词被埋没太短又可能截断上下文导致语义不完整。我常用的策略是按照语义边界切分优先选标题层级、段落首行、列表项作为切分边界每个块控制在 300 到 500 个汉字左右同时保留 50 到 100 个字符的重叠窗口。重叠窗口的作用是避免一个完整语义被从中间硬生生截断比如一个段落前半段在块 A 结尾、后半段在块 B 开头如果两块之间没有重叠检索到块 B 时就会缺少上文语境。切分完成后每个块会被送入一个 Embedding 模型转成一个固定维度的向量。比如常见的向量维度是 1024 维这个向量在数学上表示了文本的语义位置。语义相近的文本向量在高维空间里的距离也相近。3.2 在线阶段向量的相似度检索用户提问到了之后系统会把问题转成同样维度的向量然后在向量数据库里做最近邻搜索找出与问题向量距离最近的一批文档块。这里有一个很多新手容易忽略的重点搜索的目标不是字面重合而是语义相关。因为向量表达的是语义所以用户问设备冒烟了怎么办即使文档里根本没有冒烟两个字只要存在设备过热处理流程这样的段落两者向量距离也会很近。这就是向量检索比传统关键词检索强的地方。不过语义检索也有代价它对专有名词缩写这类精确信息不敏感。比如产品编号是XTR-2000B向量模型很可能把XTR和IXT混淆导致检索结果不稳定。所以成熟一点的 RAG 系统通常会做混合检索向量检索负责语义关键词检索比如 BM25负责精确匹配两个结果做加权融合后再进生成环节。检索阶段还需要调一个参数就是召回数量 top-k。k 太小有用的资料可能漏掉k 太大塞进提示词的资料过多反而稀释了模型的注意力还可能突破上下文长度限制或者引入杂质内容干扰判断。我一般从 k 5 开始调观察答案质量后再上下浮动。3.3 增强生成把检索结果拼进提示词检索完成之后系统进入第三个阶段——增强生成这也是 RAG 这个名称里增强两个字的来源。具体操作是把检索到的文档块拼接成一段上下文文本然后按照固定模板组装提示词。模板大概是这样的结构系统指令 检索到的若干资料 用户原始问题 输出格式约束。我项目里常用的一种提示词模板结构是这样你是一个严谨的智能问答助手。请严格依据下方提供的【参考资料】回答用户问题。 如果参考资料中没有相关内容请直接回答“资料库中未找到相关信息”不要尝试编造。 【参考资料】 - 资料1段落内容 - 资料2段落内容 - 资料3段落内容 【用户问题】 这里放用户输入的问题 要求 1. 回答要简洁、完整优先引用资料中的原文表述。 2. 如果资料之间存在矛盾指出矛盾并说明。 3. 回答末尾标注你主要依据的资料编号便于人工复核。这个模板看起来简单但每个部分都有讲究。指令部分要明确禁止编造的边界资料部分要编号引用输出约束要保留可追溯性。所有这些设计本质上都是在对抗大语言模型过度发挥的倾向。3.4 RAG 的字段解释为什么召回的是一个块而不是整篇文档这里顺便把 RAG 系统里常见的数据结构说清楚。RAG 的索引库往往同时存储两种字段文本字段和向量字段。一条记录除了包含切块后的正文文本还包含这个文本的向量表示、来源文档 ID、以及文档路径等元数据。为什么存的是块而不是整篇文档原因很好理解如果用户问这台机器的最大承重是多少你把整本 300 页的说明书全书塞给模型上下文里绝大部分内容都是无关信息模型反而难以定位答案而且大模型对长上下文的注意力稀释问题会非常明显。切成小块后检索阶段想办法找出最相关的那一两段生成阶段只让模型阅读这两段精准度会高得多。在实际系统中一条典型的索引记录长这样字段示例值iddoc2024001_chunk007source某操作手册_第3章_PDFtext当设备温度超过85摄氏度时系统会触发二级报警……embedding[0.023, -0.045, 0.101, ...]metadata设备型号部门上传时间这个表结构也便于后续做权限控制。比如某些文档只允许特定部门的员工检索到就可以在检索时加元数据过滤条件向量数据库和普通数据库在过滤逻辑上没有本质差别。4. RAG 本质解决什么一个信息接入的视角4.1 RAG 是给大模型插了一根外部数据线从架构视角看RAG 的实质是把大模型的知识边界扩展到了外部存储。模型本身没有新增记忆但它每时每刻都能访问最新、最全的私有知识库。用一个生活化的类比微调像是把参考书背进脑子里但人的记忆力有限背的过程中还可能背错、背串RAG 像是做题时旁边放一本可以随时翻的资料书不占脑子翻到哪里算哪里书更新了你就能用到新知识。这个类比不完美但它精准点出了两者在知识更新成本和记忆容量上的本质差异。所以如果你做一个项目知识的来源变化很快比如法律条文更新、产品版本迭代、内部制度调整RAG 的自然优势非常明显。你只需要把新文档扔进索引库答案马上就跟着变了整个过程不需要训练也不需要 GPU 集群跑几小时甚至几天。4.2 RAG 与微调对比差异不仅在成本说到微调我需要先把概念澄清。微调Fine-tuning是指在预训练模型的基础上使用特定领域的数据对模型参数做进一步的训练更新。微调可以使模型在特定任务上表现更专精比如让模型学会某种特定的输出格式、语调和领域术语。它和 RAG 最本质的差异在于知识放在哪里对比维度RAG微调知识存储位置外部向量数据库模型参数内部知识更新方式替换/新增索引即可重新训练或增量训练能否追溯依据能可输出来源编号不能模型不会告诉你依据对算力和数据的需求低主要靠 Embedding 和向量检索高需训练环境与训练样本擅长解决的场景私有知识、实时知识、可追溯问答风格模仿、格式约束、推理质量提升风险点检索不准、上下文拼接过长灾难性遗忘、过拟合、成本高这个表是做选型决定时最核心的参考。我每次跟同事讨论方案都会先把这个表摆出来问一句我们的项目核心痛点到底是不知道知识还是能力风格不对。4.3 什么场景该选 RAG四个典型信号根据我的经验如果同时命中下面几个信号选 RAG 基本不会出错第一你需要回答的问题有明确的知识边界。比如企业内部规章制度、操作手册、产品 FAQ这些内容封闭且权威非常适合建索引。第二答案需要附带依据。法务、医疗、金融、质检这些行业领导或者某个下游环节会追问这句话出自哪份文件RAG 天然支持溯源微调则很难给出令人信服的出处。第三知识库内容会频繁更新。比如产品说明书每个季度变一次用 RAG 只需要重建索引或者增量更新代价极小。第四你预算有限、没有足够的高质量标注数据。RAG 对高质量标注样本的依赖远低于微调你只需要把原始文档整理好不需要人工去写问题-答案对。反过来如果产品需要一个稳定的、固定格式的输出风格比如客服机器人必须用某种俏皮话术回答所有问题或者模型的回复结构必须严格统一到 JSON 模板那微调的价值就比 RAG 大。RAG 能给到模型的风格约束非常有限它主要改变的是回答内容而不是回答方式。5. RAG 工程落地从零搭一个最小系统5.1 技术选型别迷信框架从最小闭环开始聊完概念到实操环节。现在市面上的 RAG 框架和组件已经非常多了但我的建议是第一版别直接上重框架先用 Python 脚本打通最小闭环。为什么因为 RAG 项目的成败80% 取决于你对数据质量的理解而不是框架功能多强大。如果一开始就引入一堆自动化和编排功能调试问题时你会分不清是检索的问题、切块的问题还是框架配置的问题。先写一个三百行左右的脚本把文档切块 → 向量化 → 检索 → 拼装提示词 → 生成这条链路跑通你才能直观体会到每个环节对最终答案质量的贡献。技术选型上我一般按这个组合起步文档解析使用通用 PDF 解析库不同语言的库各有差异但基本都是 PDF 转文本的套路如果是扫描版 PDF 需要先过 OCR。Embedding 模型选本地部署或者云端 API 均可重点关注向量维度和中文语义效果。向量数据库小型项目用一个本地向量库够用数据量大、并发高再上分布式方案。LLM可以是云端大模型 API也可以是本地部署的开源模型。5.2 代码演示最小化的 RAG 管线我来还原一个极简版的核心逻辑省略框架封装让你看清楚本质。这段代码的目的不是生产级别而是帮助你理解数据流# 最小化 RAG 管线示例伪代码级示意 from embed_client import embed_texts, embed_query from vector_store import VectorStore from llm_client import chat_completion # 1. 索引阶段切块并写入向量库 chunks split_documents(manual.pdf, chunk_size400, overlap80) vectors embed_texts(chunks) # 每个块得到一个向量 store VectorStore() store.add_documents(chunks, vectors) # 2. 检索阶段把问题向量化并搜索 question 设备二级报警的排查步骤是什么 q_vec embed_query(question) results store.search(q_vec, top_k5) # 返回最相似的5个块 # 3. 生成阶段拼装提示词并调用LLM context \n.join( f- 资料{i1}{r.text} for i, r in enumerate(results) ) prompt f依据以下资料回答问题{question}\\n\\n{context} answer chat_completion(prompt) # 4. 输出 print(answer)这个流程的核心其实就是三个函数调用embed_texts、search、chat_completion。所有复杂工程都是在这个基础上加缓存、加权限、加重排、加监控。理解了这三步你就理解 RAG 了。5.3 检索质量优化的三个关键旋钮打通最小闭环之后你大概率会遇到答案质量不满意的情况这时候不要急着换模型先调下面三个旋钮。第一个旋钮是切块粒度。如果答案总是不完整、丢细节把块调小一些如果答案总是泛泛而谈、缺上下文把块调大一些或者增加重叠窗口。这个过程说白了就是在检索精度和上下文完整性之间找平衡。第二个旋钮是 top-k 召回数量。答案明明在资料库里有但模型说找不到多半是 k 太小、没召回答案里混入了无关信息、前后矛盾可能是 k 太大、噪音进来了。我一般会做一个简单的人工抽检拿二十个典型问题试 k 3/5/10 三档人眼比较输出质量选出一个最优值。第三个旋钮是重排序Rerank。单纯靠向量相似度取前 k 个片段得到的顺序未必是最优答案顺序。更稳妥的做法是先用向量检索取回 k*3 个候选再让一个专门的重排序模型对问题候选片段打分最后取分数最高的 k 个片段进入生成。重排序模型的引入通常会显著提升答案的命中率尤其是文档库规模超过一千份以后。6. RAG 常见的坑与排查思路实操实录6.1 症状一模型总是回答资料库中无相关信息这个症状我在测试阶段遇到太多次它的第一反应不是模型不行而是检索阶段根本没召回有效内容。排查思路按顺序来。首先检查切块质量。是不是某些块是空文本是不是 PDF 解析出来的文本里全是换行符和乱码这些脏数据向量化后跟用户问句的距离会非常远自然谈不上召回。其次检查 Embedding 模型的领域适配性。通用 Embedding 模型对自然语言问句效果好但对专业术语多的文档向量相似度往往表现一般。条件允许的话用一批领域内的问题-文档块正样例去评测不同 Embedding 模型选效果最好的。最后把检索到的 top-5 片段打印出来人工看一眼。只要这一步能看到相关内容问题就转移到生成环节如果 top-5 全是无关内容问题就锁定在检索环节。这个二分法排查思路几乎能解决 90% 的质量问题。6.2 症状二回答了内容但是部分关键点缺失如果说第一个症状是一点也没有参考到第二个症状就是参考到了但没参考全。我遇到过一个典型的案例用户问设备的维护周期和注意事项维护周期在文档第一节注意事项在文档第五节。这两段语义距离很大向量检索很可能只召回其中一段另外一段被漏掉了。这种多意图问题靠单向量检索很难一次性命中所有方面。解决办法有两个思路。第一拆问题时用多路召回把用户问题做子意图切分比如拆成维护周期和注意事项两个子问题分别检索再合并候选集。第二在数据库端做 metadata 反链如果同一份文档的不同章节在逻辑上有关联就在切块时给块上加一个同源章节标签检索到一块后可以顺着标签拉出相关块。还有更朴素的办法把 top-k 稍微调大让更多候选进入重排序阶段。对多意图问题宁可先多召回再用重排序筛选也不要一开始就扣得太紧。6.3 症状三答案像是对的但完全被检索结果带偏这个症状最隐蔽因为模型生成的内容流畅又有逻辑你很难一眼看出问题在哪。我读过一些失败案例最后定位到根因是检索回来的片段本身是正确的但片段与片段之间彼此冲突模型最后选择了其中一个而它恰恰不是最新的那个。典型的冲突来源是文档版本管理。企业资料库里往往会积压多个版本的旧文档比如 2023 年版设备配置和 2024 年版设备配置并存两版参数完全不同。向量检索只看语义相似它不管文档新旧版本于是两个版本的片段都被召回模型就有概率回答成旧版本的参数。解决方案很直接在索引写入时强制给每个切块打版本号检索之后按版本号过滤或者给不同版本的文档设置优先级权重。再一个思路是在提示词里明确要求当多个资料矛盾时优先采纳资料编号最小/最新上传的片段。这个逻辑看似小但在真实企业场景里救命的次数非常多。6.4 症状四系统响应太慢用户体验差RAG 系统的延迟来源通常有四个文档切分的离线任务不影响在线、向量检索的耗时长、生成模型的首字延迟高、系统请求链路串行过多。如果检索库达到中等规模向量检索本身一般是毫秒级到几十毫秒级通常不是瓶颈。真的瓶颈往往是检索 → 生成的串行链路以及 LLM 本身的推理时间。优化方向无非两个一是给向量检索加缓存针对高频问题直接缓存答案二是把检索和生成做成异步流式用户看到正在检索资料再到正在生成回答的逐步反馈体验会好很多。还有一个小细节经验不足的人很容易忽略检查一下是否有不必要的 Embedding 重复计算。有的系统把用户每次提问都重新跑一遍 Embedding 模型但问句如果和历史记录高度重复完全可以直接命中缓存。别看这只是一次 API 调用在高并发场景下省掉这个冗余调用能带来不小的性能收益。7. RAG 与微调搭配使用的实践心得7.1 两者不是互斥方案现在回看文章开头那个问题RAG 和微调差在哪我觉得更准确的问法应该是它们各自擅长什么、何时配合使用。我在实际项目中越来越多见到 RAG 微调的组合架构。一种典型的搭配是微调负责让模型学会如何从资料里提炼答案RAG 负责提供最新和私有的资料内容。先用一些小规模的指令数据微调模型让它在提示词里看到参考片段时更习惯输出按资料回答的结构化文本而不是自由发挥再挂上 RAG 管线给它一个随时变化的资料源。这种模式下微调提升的是跟 RAG 配合时的表达能力RAG 提升的是知识覆盖面。7.2 评估体系的建立别靠手感靠指标最后我必须强调一套评估思路。RAG 系统的开发是典型的看着还行但说不清哪里不行的项目如果没有一个固定的评估集你会陷入改一版感觉好了再改一版感觉又差了的泥潭。我在项目启动第一天就会建立一套评估集通常包含三类测试数据标准题答案在资料库中明确存在的题目至少 50 道覆盖不同章节和不同问法。无据题答案在资料库中不存在的题目用来测试拒绝回答能力。冲突题资料库中有相互矛盾信息的题目用来测试版本选择能力。然后定义两类衡量指标检索命中率回答的内容是否来自正确的片段和答题正确率人工判断最终答案是否符合事实。每次改动切块策略、top-k、提示词模板或者重排序模型都用这套评估集跑一遍分数涨了就保留跌了就回滚。没有这套评估体系的 RAG 项目后期维护会非常痛苦。7.3 一个多数项目逃不开的未来路口知识图谱增强 RAG写到这里忍不住再提一嘴 RAG 后续的演进方向。纯向量检索的 RAG在多跳推理问题上会碰壁。所谓多跳推理就是要回答一个问题需要先找到线索 A再顺着线索 A 找到线索 B最后由线索 B 推出答案。比如用户问哪个部门负责最近一次设备事故的处理你需要先检索出事故报告从报告里找到责任部门名称再去部门通讯录里找负责人。纯向量检索很难把这两个毫无语义关联的文档串联起来。这时一种思路是引入知识图谱把实体之间的关系显式地存成图结构实体节点 关系边检索时先走一次图谱路径推理再结合向量检索做混合召回。图增强 RAG 的工程复杂度比普通向量 RAG 高一个量级因为它要求你先把非结构化文本抽取出结构化三元组这一步本身就需要一个能跑信息抽取的模型。但一旦搭好它的可解释性和多跳推理能力会明显优于纯向量方案。如果你正在做一个知识密度高、实体关系复杂、用户问题需要跨文档串联的场景这个方向值得提前布局。我在实际项目里对 RAG 的态度概括成一个词就是朴素先别想着上多炫的架构把文档切好、把索引建好、把检索结果人工检查一遍这比任何花哨的框架都管用。检索不到模型再强也是无米之炊检索到了但拼装得乱模型能力再强也会被噪音干扰。把数据链路打磨扎实再把重排序和评估体系补上你的 RAG 系统就已经超过绝大多数同类项目了。至于微调等哪天你真的发现模型读到资料但就是不按资料答的时候再去考虑也不迟。方向上记住这个判断顺序知识缺失用 RAG能力缺失先换底座模型最后才轮到微调收尾。这样按性价比排优先级项目的成功率会高很多过程中省下的时间和预算也都是实打实的。