面试被问 RAG 说不清楚故事 代码带你吃透检索增强生成先说说我自己的真实经历。去年年中面一家做企业知识库的AI团队聊到一半面试官突然往前一靠带着那种“终于问到正题了”的表情问“你讲讲RAG吧不是背定义那种讲讲你为什么需要它它到底解决了什么问题”我当时嘴上说着“RAG是检索增强生成就是先从外部知识库检索相关内容再让大模型基于这些内容生成回答……”心里却知道这回答八成没让他满意。因为他接着就问了一句“那为什么不直接把文档都塞进上下文为什么要检索检索不到怎么办”说实话那几分钟我确实有点语塞很多细节我是“用过但不一定想明白了”。面完回去复盘了一晚上把RAG从原理到代码到生产调优整个重新捋了一遍才觉得真正吃透了。后来再去面试同样的问题我可以讲成一个完整的故事顺便甩出可运行的代码面试官眼睛都会亮。这篇文章就是要把那晚复盘出来的东西完整写出来先用一个故事把RAG讲明白再给一套能从零跑起来的极简代码最后把面试高频追问和真实项目里的工程坑也一并整理了。不管你是准备面试、刚上手做RAG应用还是已经在生产环境被召回率折磨过的朋友应该都能找到点有用的东西。1. 先把故事讲明白RAG 到底在解决什么问题1.1 用“开卷考试”理解 RAG 的本质我在尝试跟别人解释RAG的时候发现最有效的类比就是“闭卷考试 vs 开卷考试”。传统的大模型相当于一个“闭卷考试”的学生。它的所有知识都来自训练时见过的数据你问它问题它只能凭记忆作答。这不代表它不聪明而是有四个硬伤记忆会过时。训练的时候它没见过2025年的事你问它最新产品规格它只能一本正经地编。记不住细枝末节。你问它某份合同第17页怎么写的它的记忆里根本没有这样的细粒度信息。不知道你的私有信息。你公司内部的流程规范、历史项目总结它压根没见过。记错和混淆。闭卷考试嘛记忆一旦模糊它就会“自信地胡说”也就是幻觉。RAG做的事情特别简单你把考试规则从“闭卷”改成“开卷”。允许模型在回答问题之前先去翻指定的资料库找到和问题相关的几段内容再把这些内容抄到草稿纸上然后照着草稿纸作答。这个过程有一个专门的说法叫“给模型提供外部知识上下文”。它没有改变模型的“智商”只是改变了模型“作答时手里有什么”。所以RAG不是微调那种让模型“记住新知识”的路线而是让模型“遇到问题临时查资料”的路线。它的核心价值就一句话把“模型不知道”变成“模型可以查得到”。这一下子就让大模型的适用场景扩大了好几倍。企业内部知识问答、私有文档检索、客服系统、金融研报分析、法律条文咨询……这些场景的共同特点都是信息是私有的、更新的、需要精确引用的。它们都适合用RAG来做。1.2 一个“带笔记的专家”说清楚三个核心步骤故事讲到这还只是第一层。面试官通常不会停下来他会继续问那RAG到底是怎么“查资料”的这时候我会把类比升级换成“带笔记的专家”。想象一位处理客户投诉的资深客服专家他工位上有一大摞笔记本里面记录着几千条历史案例。他处理一个新投诉的时候绝对不会把几千条笔记从头看一遍而是会做这几件事第一翻看笔记目录快速定位跟当前问题相关的几页第二从那几页里挑出最相关、最可信的内容撕下来夹到新档案里第三根据这些内容组织语言写出一份有依据、可以给客户答复的文档。这个例子里的三个动作对应RAG的三个核心阶段。第一步“翻目录”是索引与检索第二步“挑内容”是重排与筛选第三步“组织语言”是增强与生成。模型本身不找笔记检索系统负责找模型只负责“读着笔记回答问题”。为什么要拆成这三步而不是直接把所有笔记都塞给模型因为上下文窗口再大也有上限更关键的是——信息太多太杂时模型会“迷失”抓不住重点甚至被无关信息带偏。就像你给专家一整箱笔记让他从头翻他反而可能被大量无关案例干扰。所以“先检索最相关的几段”不是省事而是保证生成质量的关键。1.3 RAG 和直接塞全文的区别一句话就能讲清面试官还可能变着法子考你现在模型上下文已经支持几百万token了把文档全塞进去不就行了还要RAG干嘛这个问题我在真实项目里也反复权衡过。直接塞全文最大的问题是大模型对长上下文的注意力会分散。你放进去1000页合同模型就算理论上“看得到”第17页的内容实际生成时它更倾向于关注开头、结尾和高频出现的措辞中间页的关键条款它常常视而不见。这是注意力机制本身的特性不是某个模型不够好是端到端学习都存在的通病。RAG的优势是先把“相关内容”从海量文档里捞出来只喂给模型一小撮高质量的上下文。这就好比帮你先划好重点模型聚焦起来反而答得更准。当然如果系统做了多路召回把检索结果和全文分段都做对比那又是混合策略的问题了。但作为RAG的核心理念“检索-筛选-生成”而不是“全塞-碰运气”这是你必须刻在脑子里的认知。2. 一份能跑的代码从零搭建最小可用的 RAG2.1 用什么工具为什么这么选聊完故事面试如果进入实际操作环节下一步十有八九让你聊一聊技术选型甚至现场写点伪代码或者让你讲项目里的实现链路。我建议自己动手从零搭过一遍不用非得依赖重型框架这样你对每个环节的感受完全不同。我最早用LangChain搭过后来为了真正理解内部逻辑改用纯Python手撸了一个最小版本。其实一个最基本的RAG系统就是这么几个模块文档加载与切分把长文档切成小块chunk。Embedding向量化把每个小块转成向量也就是一串浮点数。向量存储与检索把向量存起来用相似度检索出最相关的块。结合提示词生成把检索到的内容拼进Prompt交给大模型回答。选型上我用了ChromaDB做向量库它能直接内存运行适合演示embedding 用的是sentence-transformers里的中文模型LLM 部分为了省事我直接接 OpenAI 兼容的接口但为了大家本地能跑我后面会顺便演示怎么换成本地 Ollama。整体思路是不求生产级别先把链路跑通。关于为什么不用现成的框架我的想法是“框架帮你隐藏的复杂度一定会在某个环节来找你。” 用LangChain你会觉得一切都好简单可一旦线上检索效果变差你连该调哪一步都不知道。我建议至少手写一遍最小实现理解了每个环节再回去用框架手感完全不同。2.2 文档加载与切分选好切分粒度是关键代码的第一步得先把原始文档读进来并切块。很多人会忽略这一步的重要性实际上切分质量直接影响后续检索效果。我用的示例是一份简单的产品说明文档你可以替换成任何txt或者markdown。加载直接用open读文本就行麻烦的是切分。切分方式有三种常见思路按固定字符数切分比如每500字切一块加150字重叠。优点是简单缺点是可能从半句话中间切开破坏语义。按段落/标题切分比如markdown按#级别切。优点是语义完整缺点是小段落过多时块大小不均匀。递归切分先按段落切段落太长再按句子切句子太长再按字符切。这是LangChain里最常用的策略。我写的代码里为了让你好懂先用了固定长度切块的方式。生产环境我建议直接上RecursiveCharacterTextSplitter按分隔符优先级递归切分效果均衡很多。至于chunk size怎么定我后面会专门讲调参经验。2.3 用 Embedding 把文本变成向量为什么相似文本的向量也相似切好的文本块要能被计算机“算相似度”得先变成向量。所谓向量就是一组数字比如一个文本块被变成一个768维的向量也就是768个浮点数组成的数组。这里的关键机制是embedding模型把“语义”变成了“几何位置”。如果你把“今天天气怎么样”和“明天会下雨吗”两句话送进同一个embedding模型它们得到的向量在空间中距离会很近因为这两个句子语义相关。而“今天天气怎么样”和“红烧肉怎么做”的向量距离就远。这就是向量检索的基础。我在代码里用的是sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2它是多语言模型对中文支持还行模型小、速度快演示完全够用。如果你的场景对中文效果要求高可以换BAAI/bge-large-zh-v1.5或者text2vec-large-chinese效果会更好但推理速度会慢一些。2.4 完整代码从读文档到生成回答的一条龙实现下面我就把最小可用RAG的完整代码贴出来。你可以直接保存成minimal_rag.py跑一下需要提前安装几个库pip install chromadb sentence-transformers requests代码里我特意不用LangChain框架方便你看出每个环节的原貌。# -*- coding: utf-8 -*- Minimal RAG implementation: load docs - chunk - embed - retrieve - generate import os import chromadb from chromadb.config import Settings from sentence_transformers import SentenceTransformer # ---------- 1. Load and chunk ---------- def load_and_chunk(file_path, chunk_size300, overlap50): with open(file_path, r, encodingutf-8) as f: text f.read() # remove extra blank lines text \n.join([line.strip() for line in text.splitlines() if line.strip()]) chunks [] start 0 while start len(text): end start chunk_size chunks.append(text[start:end]) if end len(text): break start end - overlap return chunks # ---------- 2. Embedding function ---------- model SentenceTransformer(sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2) def embed_texts(texts): return model.encode(texts).tolist() # ---------- 3. Store into vector DB ---------- client chromadb.Client(Settings(anonymized_telemetryFalse)) collection client.get_or_create_collection(demo_kb) def index_chunks(chunks, doc_iddoc1): ids [f{doc_id}_{i} for i in range(len(chunks))] embeddings embed_texts(chunks) collection.upsert(idsids, embeddingsembeddings, documentschunks) print(findexed {len(chunks)} chunks) # ---------- 4. Retrieve ---------- def retrieve(query, top_k3): q_emb embed_texts([query])[0] results collection.query(query_embeddings[q_emb], n_resultstop_k) docs results[documents][0] distances results[distances][0] return list(zip(docs, distances)) # ---------- 5. Generate with the help of retrieved context ---------- def generate_with_context(query, context_docs): context \n\n---\n\n.join(context_docs) prompt f请基于以下【参考资料】回答用户问题。如果参考资料不足以回答问题请如实说明不知道。不要编造。 【参考资料】 {context} 【用户问题】 {query} 【回答】 # Here I use a fake LLM call placeholder for portability. # In real usage, you can call OpenAI / Ollama / vLLM / local model. import requests resp requests.post( http://localhost:11434/api/generate, json{model: qwen2.5:7b, prompt: prompt, stream: False}, timeout120 ) return resp.json()[response] # ---------- 6. Demo flow ---------- if __name__ __main__: # prepare sample doc sample sample_doc.txt if not os.path.exists(sample): with open(sample, w, encodingutf-8) as f: f.write(智能音箱X1使用说明 X1支持语音控制家电。 首次使用需要连接家庭Wi-Fi并下载配套App完成配对。 X1内置3000mAh电池满电可使用8小时。 如果设备无法连接网络请尝试长按电源键10秒重置网络模块。 常见问题排查 - 唤醒失败请检查麦克风是否被遮挡。 - 音量异常请在App中检查音量均衡设置。 - 无法充电请使用随附的Type-C充电线。 ) chunks load_and_chunk(sample) index_chunks(chunks) query X1无法连接网络怎么办 top_docs retrieve(query, top_k2) print( retrieved ) for doc, dist in top_docs: print(f[dist{dist:.4f}] {doc}) # For a true endpoint, you need Ollama running locally: # answer generate_with_context(query, [doc for doc, _ in top_docs]) # print(answer)这段代码跑完你会看到检索出来的片段确实包含了“无法连接网络”的关键字。把检索片段拼进prompt再交给本地大模型它就能给出更可靠的回答并且带上参考资料作为依据。这就是RAG的完整闭环。2.5 关键一步为什么必须把“参考资料”放进提示词代码里最容易被忽略但恰恰最重要的地方是generate_with_context里的那个prompt模板。我特意写了“请基于参考资料回答”“如果资料不足请说明不知道”这不只是礼貌用语。大模型没有义务配合你的检索结果。你把检索片段放进去它可能看一眼不相关的部分然后跑题或者开始自由发挥。所以prompt里必须明确三点知识来源只有一个告诉它只能引用参考资料里的内容。允许承认不知道逼着它不能编造降低幻觉风险。结构化输出告诉它先写结论再列依据便于下游解析和引用溯源。我早期做项目时就吃过亏prompt里没加这些约束RAG检索到的内容明明是对的模型却自作聪明补充了一堆错误信息。后来把prompt改成上面这种“硬约束”写法幻觉明显下降。在演示代码里用注释标注了接入方式真实项目里这块值得花精力反复打磨。3. 面试官真正想考察什么RAG高频追问拆解3.1 为什么需要向量检索有没有非向量的替代方案这个问题其实考察你对RAG检索阶段的底层理解。向量的好处是能捕捉语义相似比如用户问“冰箱不制冷”文档里写的是“冷藏室温度过高”字面上完全看不出关联但向量距离很近能召回。这个能力靠的是embedding模型在海量语料中学到的语义空间。但不代表所有场景都要向量检索。有些系统里如果文档量不大、结构化程度极高用BM25这类基于关键词的检索反而又快又准。真实项目里最稳的做法是混合检索重排先用BM25做关键词召回互补向量召回两者结果合并后再用rerank模型精排。我后面会在调优部分详细说。3.2 chunk size 怎么定切小了丢上下文切大了检索不准这几乎是面试必考题。我觉得最好先理解两个方向上的坑再记住经验值。Chunk太小比如50字语义上下文不完整。模型拿到小块可能只看到“返回值是false”但看不到“当网络超时时”根本答不对。Chunk太大比如2000字检索阶段会把整块都捞出来但这一块里可能只有200字是相关的剩下1800字全是噪声把模型注意力带偏了。经验上通用文本300~800字是比较舒服的区间配合50~100字的重叠overlap避免切分切断关键语义。如果文档结构清晰比如按章节、按条款、按FAQ条目聚合优先按结构切分而不是按字数硬切。这个原则你理解之后面试官追问“你项目里怎么定的”就不会慌了。3.3 embedding 模型怎么选开源和闭源怎么权衡中文RAG项目里embedding选型直接影响检索效果。我踩过的坑是早期为了省事用了一些英文强中文弱的模型检索出来的结果驴唇不对马嘴。选型基本逻辑如下预算充足、追求效果直接上OpenAI的text-embedding-3-large或者Cohere的多语言embeddingAPI调用省心。需要私有化部署推荐BAAI/bge-large-zh-v1.5或Qwen3-Embedding中文效果都很能打。资源受限、本地演示上面代码用的MiniLM多语言模型足够用。3.4 检索不到或检索不准时怎么办这个问题考察的不是“你知道标准答案”而是“你有没有真实调优经验”。我从实际项目里总结的排查顺序是先看数据侧。停用词有没有处理文档有没有清洗切分有没有破坏语义再看检索侧。是否已经用混合检索top_k是不是太小有没有做query改写最后看模型侧。是不是embedding模型压根不擅长这个问题域有没有考虑换模型一个非常实用的技巧是query改写用户提问往往口语化、指代不清比如问“它多少钱”你需要先推断“它”指代什么商品再把改写后的query拿去做向量检索。这个步骤在客服类场景几乎能提升10%以上的命中率。3.5 进阶考点Agentic RAG、GraphRAG 和 Self-RAG 的区别是什么面试官要区分你和只会调包的人就会往这个概念上引。这里用一个简单类比基础RAG相当于“一次开卷查资料”Agentic RAG相当于“一个会自己找资料的助手”。Agentic RAG不满足于“只查一次资料”而是让LLM当agent自己决定要不要查、查什么、查完不满意再换一种查法甚至多次调用工具。比如用户问“对比一下X1和X2两个产品”一次性检索可能各自只找到一部分信息Agentic RAG可以拆成多个子查询分别检索最后汇总对比。它把RAG从“单轮检索”升级为“多轮决策”。GraphRAG把实体之间的关系构建成知识图谱再在图上做检索。它的优势是处理多跳关系。比如“A公司收购了B公司B公司的创始人是CC现在在哪任职”这类问题纯向量检索要碰运气图结构可以直接沿边推理。微软那篇GraphRAG论文就是从“全局性问题”入手的适合财报分析、文档集总结这类场景。Self-RAG让模型在生成过程中自我反思判断检索到的内容是否足够支撑回答不够就再检索答完之后再评估一下自己答得好不好。本质是给RAG加了一个“反馈循环”。这三者的关系可以理解为基础RAG是版本1Agentic RAG是让决策循环起来GraphRAG是让知识的关联结构显式化Self-RAG是让模型自己评价并优化生成。面试时你能把这段话讲出来已经能证明你是真的在用RAG做事而不是背概念了。4. 从 Demo 到生产工程化调优的核心经验4.1 一个线上项目的真实链路长什么样我自己负责过的一个企业知识库项目初期照搬demo架构上线后发现一堆问题检索质量差、响应慢、用户问同样的问题答案不稳定。后来重构了几轮才形成一套能扛住真实流量的标准链路。线上链路我推荐这样组织先用一个Query Rewriter改写用户question顺便做意图分类、实体抽取同时跑路。一路BM25关键词召回一路向量召回两路结果合并合并以后用cross-encoder重排取top 3以内再把精排后的文本块按原文结构重新组装拼进prompt最后交给LLM生成同时把引用来源一并输出。这一套流程下来整体效果比单纯向量检索好非常多。4.2 必须监控的四个关键指标讨论RAG不聊评估等于白干。实践中最常用的四组指标Hit Rate / RecallK衡量检索出来的片段里是否包含能回答问题的关键信息。计算公式不复杂对每个测试问题如果正确答案所在的原始文档片段出现在检索返回的前K个结果里就算命中。所有问题命中率求和除以问题总数就是Hit Rate。我们项目里定的及格线是0.8如果低于这个数后面生成再好都白搭。MRRMean Reciprocal Rank更严格考察“正确答案排在第几位”。比如正确答案排在第一位得分1排在第二位得分0.5。表达式是MRR (1/N) * Σ(1/rank_i)。这个指标特别适合对比不同的embedding模型或切分策略。Faithfulness / 忠实度衡量生成答案是否严格基于检索到的上下文有没有添加检索结果里没有的信息。业界常用做法是让一个强模型当裁判把答案拆成若干原子claim逐一检查每个claim能否由检索片段支撑。理想值是0.9以上。Answer Relevancy衡量答案是否真正回答用户的问题而不是答非所问。这个指标偏主观通常用LLM-as-a-judge打分。我建议项目一开始就建立一套评估集至少50条真实用户问题标注好每道题对应的答案片段所在文档。每次改动切分、换embedding、调重排都跑一遍评估集用数字说话而不是靠感觉。只有这样做RAG调优才不是玄学。4.3 表格速查常见问题与调优方向我把自己压箱底的问题排查清单整理成一个表几乎覆盖了线上RAG的大部分典型问题现象可能原因优先排查方向检索结果明显不相关embedding模型中文能力弱 / query意图不清换中文embedding、增加query改写答案看起来流畅但内容是错的检索到了无关片段 / prompt约束不够检查Hit Rate、加强prompt约束、加引用校验长文档的深层信息永远看不到切分太粗 / top_k太小 / 上下文被覆盖按结构切分、增大召回数、加rerank同一问题多次回答结果不稳定LLM温度过高 / 上下文顺序抖动降temperature、固定prompt结构知识库更新后检索不到新内容增量索引没生效 / 缓存问题检查upsert逻辑、清缓存、重建索引用户口语化提问效果差query和文档语言风格差异大做query改写、同义词扩展、混合检索这个表不一定能覆盖所有情况但它是我在一次故障排查中真正用过的排查路径先定位现象再改配置效率远高于乱试。4.4 关于“RAG瓶颈”我必须说的几句实在话网上讨论RAG瓶颈特别热闹我也来说点真实感受。RAG最大瓶颈不是“检索不准”这种具体问题而是整个系统的插拔性。真实世界里一个RAG系统往往要沉淀自己的评估集、调优流程、监控看板每换一个LLM、每加一个知识库类别都可能牵一发动全身。另外就是成本问题。同样一个知识库当文档数量从1万涨到100万向量索引、检索延迟、重排开销都会指数级上升。这时候你就得考虑做metadata过滤先按部门/文档类型/时间范围缩小检索范围再做向量检索效率和精度都能提升。我把RAG定位成“解决大模型落地最实用的一层脚手架”但脚手架本身也需要工程维护。这个认知比任何具体技巧都重要。5. 常见问题与避坑实录5.1 本地模型接入时最容易踩的坑很多新手把RAG代码写完想在本地跑通结果在接入LLM这一步反复卡壳。我推荐本地部署直接上Ollama它把模型下载、加载、API暴露全部封装好了。但有几个我踩过的坑提醒你第一模型下载慢。遇到这类问题解决办法是设置国内镜像源具体配置就一句OLLAMA_MODELS指向你的模型目录或者使用代理下载模型文件。第二默认API端口是11434如果你服务器上已经占用了记得改成--port 11435。第三本地小模型的指令遵循能力远不如云端大模型所以prompt里的约束要写得更死板更直接少绕弯。5.2 向量库选型ChromaDB、FAISS、Milvus 怎么选选型问题面试也爱问。我直接给结论ChromaDB适合原型验证、单机应用部署简单但并发能力和数据量上限一般。FAISS不是完整数据库只是一个向量索引库快但需要自己管理数据持久化、元数据过滤。适合在代码里嵌入使用。Milvus / Qdrant / pgvector面向生产级支持分布式、多租户、元数据过滤、混合检索、高并发。我线上项目用的就是Milvus MinIO MySQL的组合元数据放MySQL向量放Milvus大文档原始文件放对象存储。只要数据量不到百万级ChromaDB完全够用。但如果你要支撑企业级多部门隔离、权限过滤、高并发查询直接上 Milvus。5.3 从“能跑”到“好用”还有三件事必须做代码跑通只是开始真实项目里你还需要做三件事第一加上引用溯源。让模型在生成答案时给出来源片段编号你可以在前端展示“参考了哪份文档的第几段”。这不仅是用户体验问题也是降低用户对AI不信任感的手段更是合规要求。第二埋点监控。每条用户query的检索返回结果、模型生成结果、响应时间、token消耗都记录下来。这样你可以拿真实数据反推问题而不是等用户投诉了才知道系统坏了。第三定期用真实数据更新评估集。我每个月都会从日志里挑20条失败或不满意的case加进评估集重新跑指标。RAG系统不是一次调完就完了的它是一个需要持续维护的有机体。5.4 面试或者做项目时最容易暴露功力的一句话我自己面试别人的时候最常问的是“如果你的RAG答错了你的排查第一步是什么”这个问题最能看出一个人是真做过还是背过概念。背概念的会说“微调模型”“扩大数据集”做过的会先说“先看检索结果对不对再判断是检索问题还是生成问题”。因为RAG的答错链路一定是先检索后生成检索错了生成一定错这一步先定位了后续排查才有方向。这个思维框架适用于任何RAG去排查的场景。你在项目总结里把这个流程讲清楚面试官就知道你是真的在“systematic troubleshooting”而不是“感觉调优”。我在实际项目里把这些链路调完一遍之后最大的体会是RAG的入门门槛其实不高但上限极高。从跑通demo到稳定支撑业务中间隔着数据清洗、切分策略、检索优化、重排、评估、监控一整套工程体系。但反过来讲只要你能把原理吃透把这套体系搭出来它就是你在AI领域最有说服力的实战资产之一。最后再分享一个小技巧如果你准备面试或做技术分享与其背一堆RAG概念不如准备一条你实际调试过的完整链路——从一句话query开始到retrieval返回结果到prompt构造再到最终答案全程截图或贴代码讲下来。这种“用代码和真实输出说话”的交流方式往往比任何华丽的概念宣讲都更有说服力。