一文搞懂RAG-从索引构建到检索生成的完整技术原理

前言你有没有发现大模型很像一个闭卷考试的学霸——什么都能聊两句但一旦问到它没学过的东西就开始编。问你公司去年的营收数据它编。问你们产品的售后政策它编。问它三天前刚发布的行业新规它还是编。不是它故意骗你而是它的知识在训练结束那一刻就冻结了。它不知道的只能靠猜。那有没有办法让它从闭卷变成开卷——允许它翻资料再作答有这个方案就是 RAG。RAG 是什么一句话说清RAG 先检索再生成。用户提了一个问题系统不急着让大模型回答而是先去知识库里翻一翻把跟问题相关的内容找出来连同问题一起丢给大模型。大模型拿到参考资料再组织语言给出回答。打个不太恰当的比方你让一个律师帮你分析合同他不会光凭记忆就给你结论而是先翻出相关法条和过往判例对着条文跟你讲。RAG 就是给大模型配了这个翻资料的能力。这样做的好处很明显回答有依据不瞎编知识可以随时更新追加新文档就行不用重新训练模型能覆盖私有数据比如你公司的内部知识哪些场景特别需要 RAG不是所有场景都需要 RAG。让大模型写首诗、做个翻译、帮你润色文案它本身就够用了。但当你的场景涉及以下特点时RAG 就非常关键知识是私有的。企业内部的产品文档、运维手册、客户服务记录——这些内容从来没有出现在大模型的训练集里。没有 RAG大模型对这些东西一无所知。知识是会变的。法律法规在修订、金融政策在调整、安全漏洞在不断暴露。大模型的训练数据有截止日期之后发生的事它不知道。错误的代价很高。在医疗、法律、金融领域一个错误的回答可能导致严重后果。单纯依赖大模型的记忆风险太高必须有可靠的知识来源做支撑。RAG 的两条主线理解 RAG最关键的是分清两条时间线离线阶段建库。在用户还没提问之前你把各种文档整理好建成一个可检索的知识库。这个过程叫索引构建。在线阶段问答。用户提了问题之后系统实时去知识库里找相关内容喂给大模型让它生成回答。这个过程叫检索生成。两条线一前一后配合工作。下面挨个拆解。离线阶段索引构建怎么把文档变成可检索的知识库你有一堆 PDF、Word、网页、Markdown 文档直接丢给大模型行不行理论上可以但实际上不行——文档太大、太杂、格式不统一大模型根本吃不消。所以需要一套加工流水线把原始文档变成知识库。这条流水线分四步第一步清洗和标准化原始文档五花八门PDF 里有乱码Word 里有隐藏格式网页里有广告和导航栏。这一步就是把这些脏数据清理干净——去掉无用字符、统一编码格式、把不同来源的文档转成统一的结构。就好比你准备考试前先把乱七八糟的课件、笔记、截图整理成一份干净的复习提纲。提纲整理得好不好直接决定了后面复习的效率。这也是 RAG 系统里最容易被忽视、却最致命的一环——数据质量不过关后面做再多优化都白搭。第二步分片Chunking一个文档动辄几万字不可能整篇丢给大模型。一来大模型的上下文窗口有限装不下二来整篇文档里大部分内容和用户的问题无关塞进去只会干扰回答。所以要把文档切成小块chunk检索的时候只拿出最相关的几块精准投喂。分片听着简单其实很有讲究。切太大一块里塞了好几个主题检索时鱼龙混杂想找的被不想找的淹没了。切太小一句话被拦腰截断上半句在 A 块下半句在 B 块检索出来大模型看了一头雾水。实际操作中常用的策略有按固定长度切、按段落和章节边界切、甚至用语义模型来智能判断在哪里切。没有放之四海皆准的最优解需要根据你的文档特点来调。第三步向量化Embedding这是 RAG 里最核心的魔法环节。分片完成后每一块文本都要通过一个 Embedding 模型转换成一个长长的数字数组向量。你不用深究这个模型的内部结构只需要理解一件事语义相近的文本转换出来的向量在数学上也相近。今天天气真好和外面阳光明媚这两句话字面上没什么重叠但语义接近所以它们对应的向量在高维空间里会挨得很近。而今天天气真好和如何安装 Docker的向量则会离得很远。这就是向量化存在的意义——它把人类的语义理解翻译成了机器可以计算的数学距离。至于怎么衡量两个向量近不近最常用的方法是余弦相似度算两个向量之间的夹角。夹角越小方向越一致语义就越相关。也有用欧几里得距离两点间直线距离或点积方向重叠程度的不同场景各有适用。第四步存入向量数据库向量化完成后每个文本块都有了对应的向量。这些向量需要一个专门的存储引擎——向量数据库。为什么不用 MySQL因为传统数据库擅长的是精确匹配比如查找名字叫张三的记录而向量数据库擅长的是模糊相似搜索比如找和这段话语义最接近的 5 段文本。存储时每个条目通常包含三个部分向量本身用于相似度计算原始文本检索出来后给大模型参考的实际内容元数据比如来源文件名、创建时间、所属章节等方便检索时做过滤和追溯常用的向量数据库有 Milvus、Pinecone、QdrantPostgreSQL 用户也可以直接用 pgvector 插件。到这一步离线阶段的索引构建就完成了。知识库已经就位可以开始回答问题了。在线阶段检索生成用户提问后发生了什么用户输入一个问题系统需要在几百毫秒内完成找资料 写回答的全过程。具体来说分五步1. 问题向量化用户的问题本身也是一段文本先用同一个 Embedding 模型把它转成向量。注意这里必须用和离线阶段同一个模型——不然两个向量在不同的坐标系里没法比较。2. 相似度检索拿着问题的向量去向量数据库里找最邻居的几条记录通常取 Top 3~5 条。这一步叫粗召回目标是先把可能相关的内容捞出来宁多勿漏。但纯向量检索有个弱点它擅长语义匹配却可能在关键词上翻车。比如用户问CVE-2024-1234 的修复方案向量检索可能找出一堆和漏洞修复相关的内容但没有一条精确提到这个 CVE 编号。解决办法是混合检索——把向量语义检索和传统的关键词检索如 BM25结合起来既查得广又查得准。3. 重排序Re-ranking粗召回拿到的结果可能有好有坏。这一步用一个更精确但也更慢的模型对结果重新打分排序把最相关的推到前面不相关的踢掉。你可以把粗召回理解为海选重排序是决赛。两轮筛选下来最终交给大模型的参考资料质量就高很多了。4. 组装 Prompt把筛选后的文本块和用户的原始问题拼在一起组成一个增强版的提示词大概长这样请根据以下参考资料回答问题 参考资料1...... 参考资料2...... 用户问题CVE-2024-1234 的修复方案是什么Prompt 怎么写也直接影响到回答质量。同样的检索结果不同的 Prompt 写法大模型的输出可能天差地别。5. 大模型生成回答最后把组装好的 Prompt 发给大模型。大模型基于参考资料生成回答——大幅降低了凭空编造的概率回答更有据可依。当然如果检索本身就找偏了模型仍可能出错这也是 RAG 系统需要持续调优的原因。如果索引阶段存了元数据来源文件名、链接等这一步还可以让大模型在回答中标注引用来源进一步提升可信度。总结用一张表回顾 RAG 的两条主线阶段时机做了什么索引构建离线用户提问前文档清洗 → 分片 → 向量化 → 存入向量数据库检索生成在线用户提问时问题向量化 → 相似度检索 → 重排序 → 组装 Prompt → 大模型生成核心思想就一句话别让大模型裸考给它开卷。当然RAG 不是万能药。检索召回不准、分片粒度不对、重排序模型拉胯都可能导致最终回答质量不理想。在实际落地中数据质量、分片策略、检索参数的调优才是真正拉开差距的地方。另外RAG 本身也在进化。2025 年以来Agentic RAG让 AI 智能体自主决定检索什么、检索几次、GraphRAG结合知识图谱做结构化推理等新架构不断涌现。但底层逻辑万变不离其宗——理解了索引构建和检索生成这两条核心链路后面任何 RAG 变体你都能看明白。欢迎关注公众号 FishTech Notes一块交流使用心得