Google Gemini 做 RAG 的4大阶段10个步骤

最近刷到一个挺有意思的分享，来自B站一位小姐姐讲的《基于 Gemini 和向量搜索的生成式推荐》，里面把RAG的实现流程梳理得特别清晰。我把它提炼了一下，总结成4大阶段、10个步骤——这框架挺实用的，不管是新手入门还是老手复盘，都值得过一遍。

一、知识准备阶段

一切RAG的起点，都是先把“知识”堆起来。这些知识可以是文本文件、PDF、网页、图片——形式不限，关键是要够多、够相关。拿到原始材料之后，得先做一轮“打扫”：清洗掉垃圾数据、去掉重复内容，保证底子干净。这中间还有个容易被忽视的环节：元数据提取。比如文件名、章节标题、图片的alt信息，甚至用OCR把PDF和图片里的文字数字化——这些细节在后面检索时能派上大用场。

文档不能整篇往里扔，得切成合适大小的小块。分块方式有两种主流思路：一种是固定大小切分，另一种是按语义意图切分。用固定大小的话，有个坑必须避开——“块”的边缘信息容易丢失。举个极端例子，“我们今天晚上应该去吃个大餐庆祝一下”要是正好被切成“我们今天晚上应该”和“去吃个大餐庆祝一下”，那检索时就彻底断片了。解决办法很简单：给每个块增加一点“冗余”，也就是前后块之间重叠一部分内容，保住上下文连贯性。

分块完成后，把每个小块转化成向量（也就是embedding），全部塞进向量数据库。这一步决定了后续检索的速度和精度，算是整个RAG的“地基”。

二、问题处理阶段

用户提问往往很随意，可能带着拼写错误、口语化表达。这时候大模型就该上场了——先帮用户把问题做一遍拼写检查和内容改写，但前提是不能改变原意。比如用户问“我的背景调查一直没有结果”，可以改写成更清晰的“为什么我的背景调查要花费这么长时间”。这样一来，后续向量匹配才能找准方向。

改写后的用户问题，同样要做一次向量化，转成和知识库里向量同维度的表示。这一步就是为接下来的相似度检索做准备。

三、问题召回阶段

用用户问题的向量去向量数据库里跑相似度匹配，召回最相关的topN个文档。但现实往往没那么理想——光靠相似度检索可能漏掉关键信息，所以很多系统会混合使用关键词检索、SQL检索等多种手段，保证召回结果的全面性和准确性。

召回来的文档不能直接用，得先过一遍安全审查。比如某些信息是否有权限接触、内容是否敏感、是否涉密——这些规则必须提前定好，系统自动过滤。这一步在B端场景尤其重要，毕竟数据安全是红线。

最后把用户问题、合规的召回文档拼成提示词，喂给大模型，让它生成最终答案。这一步看起来简单，但提示词的组装质量直接影响回答效果。

四、答案优化阶段

一次检索往往不够。因为知识库里的文本块数量庞大，单次检索的维度不一定是最优的。系统可能会进行多轮检索，每轮生成的答案互相比较，判断是否需要补充或修正。这背后通常有一个内部的质量判断器，专门评估返回结果的相关度，并触发重排序操作——把更贴近业务场景的结果往前排。

经过多轮检索、反复校验之后，大模型才会输出一个经过检验的最终答案。这个答案已经是尽可能准确、完整的结果了，直接呈现给用户。

整个流程走下来，从知识准备到答案优化，环环相扣。这10个步骤虽然看着多，但每一步都对应着RAG实际落地中可能遇到的典型问题。下次再看到类似项目，不妨拿这个框架去拆解一下，心里就有谱了。