RAG完整流程与面试指南：从原理到最小代码实现

面试被问 RAG 说不清楚这事我真经历过而且是在我最自信的时候翻的车。当时对方就问了一句讲讲RAG的完整流程我张口就是检索、增强、生成然后补了句就是给大模型加知识库。面试官紧接着来了三个连环追问分块大小你怎么定检索召回不准你怎么办多跳问题为什么不直接写死我当场就有点懵因为之前光刷概念根本没跑过完整代码。今天这篇文章我不打算从抽象定义讲起而是用一条完整的故事线和一份能直接复现的最小代码把检索增强生成从原理到面试话术整个捋一遍。读完你可以做到给不懂的人讲他能懂给面试官写白板他挑不出毛病回到工位你能用三小时跑出第一个RAG小项目。这篇文章适用于准备面试的后端和算法同学也适合刚接触大模型应用、想从零搭一个知识库问答的工程朋友。1. 面试官死盯 RAG 不放背后的三个核心诉求1.1 一次真实面试翻车过程的复盘那次面试我犯的最大错误不是不懂RAG而是把RAG理解成了一个名词而不是一套系统。面试官真正想听的从来不是你对检索增强生成这六个字的解释而是你有没有能力把一套真实系统从零到一搭建出来并在其中做出一系列工程判断。他追问的链条其实非常清晰先问原理再问流程再问参数再问瓶颈最后问演进方向。这其实是在模拟一个真实的落地场景——如果你今天就要给公司里的文档做一个智能问答系统第一步做什么第二步做什么遇到问题怎么排查。我把那天的回答重新想了一遍发现真正缺的只是三个层次原理层的为什么、实现层的怎么做、优化层的怎么选。这三层正好是后面三个章节要解决的问题。1.2 LLM 距离好用还差一个外挂记忆先说清楚 RAG 到底在解决什么问题。用过 ChatGPT 的人应该都有这种感觉聊常规话题没问题但一问到 2024 年以后的新事件、或者你发给它的内部文档细节它就露馅了。这不是模型笨而是模型本身就存在三个天生缺陷知识截止模型训练的数据是某个时间点之前收集的训练完的那一刻它的世界就凝固了。私有数据不可见公司内部的知识库、个人笔记、最新报表模型训练时根本看不到。幻觉问题模型是预测下一个词的概率模型不知道就直接编而且编得还特别有逻辑。RAG 的思路非常直接既然模型不知道那我就主动去资料库里把相关内容找出来塞进它的上下文里让它看着资料回答。这个过程不改变模型参数却相当于给模型装了一个可以随时更新、完全可控的外挂记忆。这也是面试官愿意深挖它的原因——它不是一个花哨的技术而是一套非常实用的大模型工程范式。1.3 为什么不直接微调这个对比是面试必答项几乎每次聊到 RAG面试官都会紧接着问一句微调也能达到类似效果为什么不用微调。这个地方千万别含糊我把两者的关键差异整理成了一张对照表对比维度RAG 检索增强微调 Fine-tuning知识更新成本换文档、重建索引即可分钟级重新准备数据集并训练小时到天级私有数据支持天然支持文档进库即可生效需要构造高质量训练数据可解释性高能指出引用了哪段原文低知识存在于权重里说不清依据幻觉控制用原文约束生成明显降低幻觉仍可能编造只是风格/格式更接近目标成本与算力只需向量化和检索服务门槛低需要 GPU 训练人力算力成本高适用场景知识问答、私域文档、实时信息固定输出格式、特定语气风格、专业术语习惯标准回答是RAG 管知识微调管表达。追求回答内容准确、依据可查优先考虑 RAG追求回答的风格、腔调、格式才考虑微调。大多数业务系统的正确做法是微调加 RAG 叠加使用而不是二选一。把这个逻辑讲清楚面试官基本就认为你理解到关键点了。2. 故事线把 RAG 想象成一位查菜谱的大厨2.1 用做菜来理解整套系统我带新人时最喜欢用一个比喻大语言模型就像一位厨艺精湛的大厨基本功扎实煎炒烹炸全会。但有一天客人点了一道客家酿豆腐大厨只是听说过没有具体做法。这时候怎么办有经验的厨师绝不会把整个菜谱书从头背一遍而是先翻目录找到豆腐类再翻到酿豆腐那一页看一眼配料和步骤然后回到灶台上动手。整个做菜过程就是一次完整的 RAG大厨的脑子是 LLM菜谱库是外部知识库翻目录加找页码是检索照着菜谱做菜是生成。里面有两个特别关键的细节。第一厨师没有死记硬背整本菜谱这意味着知识库可以随时更新——明天买本新菜谱他就能做最新菜系。第二厨师做菜时手上只放着一两页相关资料而不是把整本书摊在灶台上这对应着 RAG 里只把最相关的片段放进上下文避免信息过载。理解了这两个细节就理解了 RAG 的整个设计哲学。2.2 索引子系统给知识库编一套高效目录厨师翻目录能快速找到页码的前提是菜谱书已经有一份好的目录。RAG 的第一步就是把所有原始文档整理成一份可以快速检索的目录这一步叫索引构建它由三个环节组成第一是文本清洗与分块。原始文档可能是 PDF、网页、Word乱七八糟的格式和排版要先清理掉然后把长文档切成一小段一小段。为什么切块是件关键的事因为向量检索的单位是片段片段太大会稀释语义片段太小会丢失上下文。后面我会专门讲分块参数怎么调。第二是向量化。我们需要用 Embedding 模型把每一段文字转变为一串数字也就是向量。这段文字的意思被压缩到了空间坐标里语义相近的两段文字它们的向量在空间里距离也更近。比如怎么申请年假和年假申请流程这两个不同写法的句子向量距离会非常近。第三是存储。把所有向量连同原始文本一起放进向量数据库比如 Chroma、FAISS、Milvus、pgvector 等。它提供的能力是你给我一个向量我还你距离最近的 K 个向量。到这一步知识库的目录就正式可用了。2.3 检索与生成子系统从查到答的临门一脚做菜过程中查菜谱和做菜是分开的两个动作RAG 的线上流程也分两步。先看检索。用户提问后系统用同一个 Embedding 模型把用户的问题也转成向量然后去向量库里做相似度搜索找出最相近的 K 个文本片段。这里有个易错点问题向量必须和文档向量用同一个模型来算否则不同的向量空间根本没法比较就像用米尺量出的尺寸和用磅秤称出的重量去比大小一样毫无意义。再看生成。系统把检索出来的几个片段按固定格式拼到 Prompt 里附上原问题一起发给 LLM。典型 Prompt 长这样请仅根据以下资料回答问题资料中不存在的内容请明确说不知道资料之间用分隔线隔开。最后 LLM 基于这些片段生成答案输出给用户。到这里一个完整的 RAG 流程就是文档切块、向量入库问题转向量、相似度检索拼接提示词、生成回答。你面试时在白板上把这五步画出来面试官基本能看到你心里有全局图景了。3. 手把手实现一个面试能讲清楚的最小 RAG3.1 为什么我不用 LangChain 带你入门网上大部分 RAG 教程上来就是 LangChain语言链条一拉五十行代码跑通了但很多人跑完还是一头雾水因为框架把细节全藏起来了。面试被追问时你连那步到底干了什么事都说不上来。所以我建议先用原生方式手写一遍核心路径。代码量更少而且每一步对应一个明确的概念讲起来像讲自己写的代码一样流利。我这个示例的选型是用 sentence-transformers 提供的开源 Embedding 模型做向量化用 numpy 手写余弦相似度做检索用 OpenAI 兼容客户端对接本地 Ollama 或其他 OpenAI 兼容服务完成生成。选型思路很朴素每个环节都用最少依赖、最透明的实现方便你逐步替换成生产级组件。3.2 完整可复现代码从三段文档到一个回答整个过程分五步你可以直接复制到本地跑。首先安装依赖pip install sentence-transformers numpy openai然后是核心代码。我故意把每个环节拆成函数面试时你甚至可以照着这个结构画流程图from sentence_transformers import SentenceTransformer import numpy as np # ---------- 1. 加载 embedding 模型 ---------- # 中文场景下 bge-small-zh 是体积小、效果稳的选择 model SentenceTransformer(BAAI/bge-small-zh) # ---------- 2. 准备知识库文档 ---------- # 真实项目中这里换成读取 PDF、Word、数据库内容即可 documents [ 公司年假制度入职满一年可享受 5 天年假每增加一年工龄多一天上限 15 天。, 年假申请流程提前三天在 OA 系统发起申请提交直属 leader 审批通过后自动销假。, 薪资发放日每月最后一个工作日发放当月工资如遇节假日则提前至最近的工作日。, ] # ---------- 3. 文本分块 ---------- # 因为示例文档都很短这里直接整段作为块。 # 长文档需要按固定 chunk_size overlap 切分后面章节详细讲。 chunks [documents[i] for i in range(len(documents))] # ---------- 4. 构建索引把每个 chunk 向量化 ---------- chunk_vectors model.encode(chunks, normalize_embeddingsTrue) def search(query: str, top_k: int 2): 将 query 向量化并返回最相似的 top_k 个片段 query_vector model.encode([query], normalize_embeddingsTrue)[0] # 余弦相似度 向量内积因为已经做了归一化 scores chunk_vectors query_vector top_indices np.argsort(scores)[::-1][:top_k] return [(chunks[i], float(scores[i])) for i in top_indices] # ---------- 5. 检索 生成 ---------- from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, # 指向 Ollama 本地 OpenAI 兼容端点 api_keyollama, # 本地服务一般不会校验 key ) def rag_answer(question: str, top_k: int 2): hits search(question, top_ktop_k) context \n---\n.join([text for text, _ in hits]) prompt f请仅依据下面的资料回答问题。如果资料中没有相关信息请回答资料中未找到相关内容。 资料 {context} 问题{question} 回答 resp client.chat.completions.create( modelqwen2.5:7b, # 换成你 Ollama 里已下载的模型名 messages[{role: user, content: prompt}], temperature0.2, # 低温度让回答更克制减少自由发挥 ) return resp.choices[0].message.content调用一次看看效果print(rag_answer(入职两年能休几天年假))在本地 Ollama 已经运行并且拉取好 qwen2.5 模型的情况下输出大概会是这样根据资料入职满一年可享受 5 天年假每增加一年工龄多一天因此入职两年可休 6 天年假。如果你没有搭本地 Ollama也可以把base_url换成任何一家 OpenAI 兼容服务的地址代码逻辑完全不变。3.3 一次我实际踩过的检索排错过程完整链路还原我还想分享一个真实踩坑的过程因为它特别典型。我第一次跑这个代码时检索出的结果完全不相关——问年假返回的居然是薪资发放日。我当时第一反应是模型不行但后来按步骤排查发现根本不是模型的问题。排查链路是这样的。第一步我先打印query_vector的 shape 和chunk_vectors的 shape发现都是 512 维维度对得上。第二步我把normalize_embeddings去掉重新计算相似度发现分数变得奇怪确认归一化影响很大但依然不是最根本问题。第三步我把 documents 列表里的文本打出来逐条看发现真正的原因是我有一份长文档用简单的split(\n)切块后把一句话从中间截断了语义被劈成两半向量自然就跑到别处去了。最后我调整了切块策略按段落优先超长再切割处理问题当场消失。这个经历想说明一个道理RAG 出坑时八成问题不在模型而在切块和预处理。面试时如果能讲出这样一条排查过程比背十个概念都有说服力。4. 检索质量的三个隐藏开关分块、Embedding 与 Hit Rate4.1 分块大小为什么不是拍脑袋决定的我见过很多人一上来就把 chunk_size 设为 512问为什么答大家都这么设。实际上分块大小直接影响检索的精度和回答的质量。我把背后的权衡讲透块太小比如 64一段话被切得七零八落单块缺乏上下文。比如这个政策不适用于外包员工里的这个政策指代什么光看这一块根本不知道向量化效果也差。块太大比如 2048一段文本里包含多个主题向量被平均成一个四不像检索时什么都沾一点什么都不精准。而且大块还会消耗上下文窗口留给 LLM 发挥的空间变小。常见做法先用 256 至 512 起步再做实验对比。同时对分块做overlap 重叠处理让相邻块之间保留一部分重复内容避免关键信息正好卡在切点上。有一个简单的验证手段把测试问题的答案所在的那段原文找出来分别用不同 chunk_size 重建索引看哪个参数下检索能召回这一段。别怕多做几次实验这比任何理论都可靠。4.2 Embedding 模型选型决定相似度计算的上限如果说分块决定能召回什么那 Embedding 模型决定的是能不能召回的准。我用过几类模型分享一些直观感受通用英文模型如 OpenAI 的 text-embedding-ada-002英文表现好中文只能说够用。中文专用模型如 BGE 系列、M3E中文语义相似度明显更强是目前中文知识库项目的首选。本地 vs API本地模型用 CPU 也能跑适合离线环境API 模型方便但数据要出内网很多公司不接受。选型还有一个容易被忽略的指标向量维度。维度越高单个向量的表达能力越强但存储和计算成本也越高。BGE-small 是 512 维BGE-large 是 1024 维对一般知识库来说small 已经足够用不必盲目追大。评价 Embedding 的效果最直接的方式是抽 100 个真实问题人工标注出标准答案片段再算 Hit Rate。4.3 Hit Rate 到底怎么算为什么它是核心指标Hit Rate召回命中率是 RAG 检索环节最核心的指标定义很简单检查你检索到的前 K 个片段里是否包含真正能回答问题的那个片段。比如 100 个测试问题里检索系统在 85 个问题的 Top-5 结果中命中了正确答案那 Top-5 的 Hit Rate 就是 85%。计算代码也很简单关键是先有标注数据# 先构造测试集每个问题对应一个标准答案片段 # qa_pairs [(问题, 标准片段原文), ...] def calculate_hit_rate(qa_pairs, search_func, top_k5): hit 0 for question, gold_chunk in qa_pairs: results search_func(question, top_ktop_k) retrieved_texts [text for text, _ in results] if gold_chunk in retrieved_texts: hit 1 return hit / len(qa_pairs)这个指标的价值在于它是生成质量的先行指标。检索召回的内容都不对后面 LLM 再怎么厉害也回答不出正确答案。面试聊到如何评估 RAG 系统能说出 Hit Rate、能讲出标注测试集的思路就已经比大多数人专业了。4.4 Rerank加了这道重排序效果立刻上一个台阶单纯靠向量相似度做 Top-K 召回有一个常见问题语义相似不等于能回答问题。向量只能衡量文本长得像不像却不太理解这段文字是否真正能够解答这个问题。解决办法是加一个 Rerank 重排序环节。思路很清晰召回阶段先用轻量向量检索拿到 Top-50然后把问题和这 50 个片段送到一个更强的交叉编码器Cross-Encoder模型里逐对计算问题-片段的相关性得分按得分重新排序最后取 Top-5 喂给 LLM。这个环节能非常显著地改善检索精度实测中我的 Hit Rate 往往能从 70% 左右提到 85% 以上。代价只是多一点计算延迟但对效果要求高的系统这笔交易非常划算。5. RAG 的瓶颈和最新打法面试追问的下一层地图5.1 别再说 RAG 没有缺点了常见的四个瓶颈面试官到了这一步通常会把问题升级RAG 有什么瓶颈这时候如果你只说效果还行那基本没戏。我把实践中遇到的真问题梳理成四点先射箭再画靶的检索盲区传统 RAG 是一次性检索查一次就定音。它不知道哪些问题需要多步推理更不知道应该换一个关键词重新检索。复杂问题拆成多个子问题的时候一次性检索基本抓瞎。知识割裂很多问题的答案散落在不同文档甚至不同章节里比如这个政策对员工的加班费怎么算至少要拼凑岗位规定、加班制度、薪酬说明三处内容。普通 Top-K 检索容易只抓到一个角。上下文窗口与信息碎片冲突RAG 把检索结果整段塞进 Prompt但窗口是有限的。相关片段一多要么截断要么挤占 LLM 的推理空间。幻觉不会被根除只会缓解即使检索到相关内容LLM 在组织语言时依然可能脑补细节尤其在资料本身模糊或者互相矛盾的时候。这四条背熟并不难关键是你得针对每一条都能说出一个实际场景。我自己拿知识割裂举例时会直接回忆起踩过的坑问跨部门报销流程系统只召回了一个部门的规定生成了残缺答案。说实话的踩坑经历比抽象总结可信得多。5.2 进阶路线图Agentic RAG、GraphRAG 与混合检索聊完瓶颈面试官基本都会接着问那你有什么改进思路这正是展示知识面的时候。按进化路线我从四个方向讲第一Agentic RAG。核心变化是让 LLM 不再查一次就答而是当一个会思考的检索代理。它自己决定要搜几次、每次搜什么关键词、要不要换个方向。比如回答跨部门报销问题Agent 会先搜报销总则发现需要子公司细则再发起第二次检索。LangChain 里的 React Agent、OpenAI 的 Function Calling 都是常见实现方式。第二GraphRAG。普通 RAG 用向量表示文本片段GraphRAG 先把文档构建成知识图谱把实体和关系抽取成节点和边。回答这个社区的用户主要聊什么话题这类需要全局性归纳的问题时GraphRAG 能通过图结构捕捉全局语义这是向量检索很难做到的。第三Self-RAG。让模型对检索到的内容进行自我反思这些内容够不够支撑回答要不要再找生成后还要检查回答是否忠于检索结果。相当于在生成环节加了质检员。第四混合检索。把向量检索和关键词检索BM25结合再加 Rerank。关键词负责精确匹配专有名词向量负责语义相似互补效果明显。这是落地最容易、见效最快的一招。面试时建议用一条主线串联先说传统 RAG 的人肉检索再说 Agentic 让模型自己决定拆解和搜索最后说 Graph 解决全局语义。这样讲面试官会觉得你有技术演进视野而不是在堆名词。5.3 一套让面试官满意的回答组织框架最后分享一个我总结的 RAG 面试应答公式按顺序走就不会乱一句话原理 → 画链路图 → 讲关键参数权衡 → 说评估指标 → 谈失败案例 → 给演进方向原理句控制在 30 秒内比如RAG 通过外部检索把相关资料拼进上下文让 LLM 基于证据而非记忆作答。画链路就是索引与检索生成两步走。参数权衡选 chunk 和 top_k 来讲。评估指标用 Hit Rate 加人工抽检。失败案例说知识割裂或分块截断。演进方向按业务需要提 Agentic RAG 或 GraphRAG。回答时记得一个心态面试官想看到的不是标准答案而是你如何在不确定中做决策。你大胆说出我在项目里 chunk_size 从 256 测到 1024最后选了 512因为再大会分散向量语义再小会丢失上下文这比任何完美定义都更打动人。我个人的实际体会是如果面试前只够准备一件事那就亲手跑通一个最小 RAG 项目。不需要生产级不需要多复杂哪怕就是我上面这段代码只要你自己改过参数、看过出错、调过相似度分数面试聊起来的状态就完全不同。知识靠阅读获得底气靠踩坑获得。真到面试现场你会发现最戳人的从来不是术语而是你随口说出的那一句这个地方我实际排查过你们是不是也遇到类似的……