简介面向大模型与人工智能开发者的实战型PDF文档系统演示如何基于LangChain从零实现一个RAG问答应用。文档选取百度百科中的藜麦数据模拟个人或企业私域数据完整覆盖项目策划、环境搭建CUDA 11.7、Python 3.10、PyTorch 1.13.1cu117、LangChain、数据保存与本地加载、文档分割、向量化、向量数据库入库等全流程。实战环节给出了可直接运行的代码用TextLoader读取本地txt文件用CharacterTextSplitter按128字符长度切分再以m3e-base模型生成Embedding并写入Chroma数据库同时对OCR识别可能导致的文字错漏、依赖安装顺序等实操问题提供提醒并为理解数据上下文补充了藜麦的背景知识。资源包仅含1个PDF文件整包大小390KB内容紧凑、步骤清晰便于按章节对照练习。目前已有285人学习/浏览既适合正在入门RAG应用开发、希望快速跑通LangChain检索问答链路的读者也适合准备大模型岗位面试时梳理相关技术要点。1. 大模型八股文面试里的 RAG 实战这道题到底在考什么这两年大模型面试几乎绕不开 RAG尤其当你报的是应用方向岗位面试官很少再问“什么是检索增强生成”这种概念题而是直接甩过来一句“你用 LangChain 搭过 RAG 问答吗” 这个标题看起来像一份面试资料其实背后是一条完整的技能链路你要能在半小时内讲清楚 RAG 的检索、重排、生成三截流水线还要能说出为什么用向量库而不是拿数据库硬撸更要能现场给出一个能跑的代码骨架。单纯背八股文没用因为追问全在细节里分块尺寸设多少、Top-K 取几、召回率低是调 embedding 还是调重排、上下文爆掉怎么办。这篇文章就把我平时带人准备这套面试题时讲的完整方案写出来从原理到最小可运行代码再到参数边界和排错经验读完你不仅答得上题还能当场写出来。2. 从八股到落地RAG 的完整链路和选型理由2.1 RAG 为什么不是“向量检索 塞进 Prompt”那么简单很多面试者第一句话就说“RAG 就是先检索再生成”这话没错但等于没说。真正的 RAG 是一条有明确失败点的流水线文档加载、文本分块、嵌入向量化、向量存储、相似度检索、候选重排、上下文组装、LLM 生成。任何一个环节偷懒最终答案质量都会崩而且崩法各不相同——分块太大导致检索命中噪声多分块太小导致语义不完整embedding 选错导致召回率低重排缺失导致正确答案被埋在第 5 位之后。面试官追问的往往不是你对 RAG 有多乐观而是你有没有被这些问题毒打过。从工程选型角度看我一般会把 RAG 拆成两个决策点检索质量决策和生成质量决策。检索质量由 embedding 模型、分块策略、向量库、检索参数、重排模型共同决定生成质量则由 Prompt 模板、上下文长度控制、引用来源标注、模型温度参数决定。LangChain 的价值不在于它多智能而在于它把这几个环节抽象成了标准组件让你能快速替换和对比。你在面试里如果能说出“我先用哪一层做实验、用什么指标判断好坏”就已经超过大多数只会背流程的候选人。2.2 LangChain 的组件抽象从 Loader 到 RetrievalQA 的调用链LangChain 的 RAG 链路在代码里是一条清晰的链式调用。最精简的骨架是这样加载文档用DirectoryLoader或PyPDFLoader分块用RecursiveCharacterTextSplitter向量化用某个 embedding 模型存储用Chroma或FAISS检索后用RetrievalQA把检索结果和问题一起交给 LLM。这个骨架代码短但每个环节都有默认参数埋着坑。下面是本地跑通 RAG 问答的最小命令集。假设你有一个 PDF 文档目录要把它变成能问能答的本地问答服务from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.vectorstores import FAISS from langchain_openai import OpenAIEmbeddings from langchain_openai import ChatOpenAI from langchain.chains import RetrievalQA # 1. 加载 PDF 文档 loader PyPDFLoader(docs/employee_handbook.pdf) documents loader.load() # 2. 分块每块 500 字符重叠 80 字符 text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , ., !, ?, , ] ) chunks text_splitter.split_documents(documents) # 3. 向量化并存入 FAISS 本地索引 embeddings OpenAIEmbeddings(modeltext-embedding-ada-002) vectorstore FAISS.from_documents(chunks, embeddings) vectorstore.save_local(faiss_index) # 4. 构建检索问答链 llm ChatOpenAI(modelgpt-4o-mini, temperature0) qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, retrievervectorstore.as_retriever(search_kwargs{k: 4}), return_source_documentsTrue ) # 5. 提问 response qa_chain.invoke({query: 年假可以累计到下一年吗}) print(response[result])这段代码的逻辑并不复杂先是把 PDF 解析成 LangChain 的 Document 对象再按递归分隔符切块接着把每个块转成向量写入本地索引最后把“检索器 大模型”组装成问答链。这里有两个参数值得你单独解释给面试官听chunk_size500决定了每个检索单元的信息密度chunk_overlap80是为了避免句子在切分处被拦腰截断导致语义残缺k4则控制送入 Prompt 的候选片段数量。面试官如果接着问“为什么用 FAISS 不用别的”你要答得出来FAISS 是 Meta 开源的向量检索库支持余弦相似度和 L2 距离索引在本地文件里落地对快速 Demo 最友好生产环境换 Milvus 或 Elasticsearch 的向量索引也只是替换一个类的问题。2.3 Embedding 选型决定召回上限的第一步很多人把 RAG 的成败押在 Prompt 上但真正决定检索上限的是 embedding 模型。同一个问题不同的 embedding 模型召回的 Top-5 可能完全不一样。中文场景尤其明显通用英文 embedding 对中文长句的语义区分度差检索出来的片段经常是字面重合但语义无关。我的选择标准是优先在 MTEB 中文榜单上有稳定表现的开源模型然后用自己的测试集实际跑一遍 RecallK不要只看榜单数字。实际代码里需要改的只是 embeddings 对象from langchain_community.embeddings import HuggingFaceEmbeddings embeddings HuggingFaceEmbeddings( model_nameBAAI/bge-large-zh-v1.5, encode_kwargs{normalize_embeddings: True} )这里normalize_embeddingsTrue容易被忽略但它很关键归一化之后用内积计算相似度等价于余弦相似度在 FAISS 里可以直接用METRIC_INNER_PRODUCT加速检索。面试末了聊性能时这个细节能说明你不是只会调包。另外本地加载 embedding 模型需要 GPU 或较好的 CPU首次运行会下载权重这些环境问题要提前说清楚别在面试现场卡住。3. 从 PDF 到可问答知识库完整落地步骤3.1 文档加载的五个隐蔽问题PyPDFLoader看起来简单但真实 PDF 里全是坑。我遇到过扫描版 PDF 需要 OCR、表格被解析成乱序文本、多栏排版导致文字跨栏拼接、加密 PDF 直接抛异常、PDF 内嵌字体缺失导致中文变成空白。面试里你可以不说这些但动手做项目时你一定会碰到。我一般建议按文档类型分流文本型 PDF 直接用PyPDFLoader扫描版走RapidOCR或PaddleOCRWord 文档用Docx2txtLoaderMarkdown 和 HTML 用各自的 Loader。更稳妥的做法是先把所有文档统一转成 Markdown 或纯文本再做清洗、去页眉页脚、合并断行最后进入 LangChain。这个预处理步骤在项目里大概占 30% 的工作量但很少有人写进简历。一个容易忽略的点是 PDF 里的页眉页脚会被当成正文读进来。比如每页都有的“第 3 页/共 20 页”和公司名会让检索结果频繁命中这些噪声。处理方式是在分块之前清洗import re cleaned_docs [] for doc in documents: text re.sub(r\n\s*第\s*\d\s*页[^\n]*, , doc.page_content) text re.sub(r[\u00a0\u200b], , text) doc.page_content text.strip() cleaned_docs.append(doc)这段正则把常见的中文页脚“第 3 页”字样删掉同时去掉零宽空格和非法空白字符。注意这里不要用一行正则解决一切PDF 解析出来的换行很乱建议先把文本打印出来看两页再写针对性规则。面试官很喜欢问“你清洗过哪些脏数据”你能说出页眉页脚、全角半角混杂、OCR 的错别字这三类就已经有真实项目味道了。3.2 分块策略chunk_size 与 chunk_overlap 的调参逻辑分块是整个 RAG 里最像“玄学”的环节。没有哪个参数对所有文档最优但有一套经验法则参数建议范围设置依据chunk_size300–800 字符中文500 左右能保持语义完整又不至于引入过多噪声chunk_overlap50–150 字符至少覆盖一个句子的长度避免断句丢主语separators 顺序先按段落再按句子最后按词优先保持自然语义边界为什么中文按字符算而不是按 token 算因为 LangChain 的RecursiveCharacterTextSplitter默认按字符长度切分而中文字符和英文字符的信息密度差异很大。如果你直接用英文教程里的 1000 字符中文文档会被切得过碎。另一个细节separators列表里的顺序就是切分优先级如果你把空格放在句号前面英文文档会在单词边界被切得乱七八糟。我把中文句号、感叹号、问号放在英文标点前面就是为了让中文文档优先在完整句子处断开。如果你的文档是结构化问答或者 FAQ 格式分块策略可以更激进——直接按条目切。下面这段代码展示了一个简单但有效的处理方式from langchain.schema import Document def split_faq(documents): result [] for doc in documents: # 假设每个 FAQ 条目以数字序号开头 blocks re.split(r\n(?\d\.\s), doc.page_content) for block in blocks: if len(block.strip()) 30: result.append(Document(page_contentblock.strip(), metadata{source: doc.metadata.get(source, )})) return result这种按结构切分的方式比统一chunk_size效果更好因为每个块本身就是一个完整问答对检索命中后直接作为上下文几乎不需要 LLM 做二次理解。面试里能讲出“我按文档结构切分而非统一长度切分”是一个明显的加分项。3.3 向量库与检索参数k 值、相似度阈值、返回字段向量库选型在面试里是个高频追问。我把常用方案列了个对照表方案适合场景主要限制FAISS单机原型、百万元素内不支持增量删改需重建索引Chroma本地快速迭代、元数据过滤大规模并发性能一般Milvus生产环境、千万级向量、高并发需要独立部署和维护Elasticsearch knn已有 ES 体系的团队向量性能依赖插件和配置我平时做面试 Demo 用 FAISS 最多因为save_local一个文件夹就能带走部署到服务器也方便。但你要知道 FAISS 不支持真正意义上的单条删除如果文档更新频繁常见做法是重建索引或者用分段索引。这个问题在面试里常被用来考察你的生产意识。检索参数里最值得调的是k和相似度阈值。k4是我习惯的初始值面试时可以这样说k 太小容易漏掉正确答案k 太大容易把无关片段塞进上下文导致 LLM 被噪声干扰。更好的做法是加一个相似度分数过滤低于阈值的片段直接丢弃retriever vectorstore.as_retriever( search_kwargs{k: 8, score_threshold: 0.5} )注意 FAISS 的score_threshold在不同检索类型下含义不同默认的similarity_search里分数是距离或相似度取决于索引类型similarity_search_with_score返回的分数范围也和 embedding 模型有关系。很多初学者在这里翻车bge 模型默认输出相似度分数较高而 ada-002 的分数整体偏低用一个固定阈值套所有模型就会出问题。所以我后面用重排替代阈值过滤这是更稳的方案。4. 检索质量不高怎么办重排与混合检索的实战补救4.1 重排Rerank为什么比单纯调 k 值有效向量检索的 Top-K 结果往往只有前两三条是准的后面几条开始跑偏。单纯把 k 从 4 调到 8只会让更多噪声进入 Prompt。重排模型的作用是拿一个更强的交叉编码器对候选片段和 query 做逐对匹配重新打分数。这一步很便宜因为只需要对已经召回的 10–20 条做过一次精排。LangChain 里接入重排的常见做法是ContextualCompressionRetrieverfrom langchain.retrievers.document_compressors import CrossEncoderReranker from langchain_community.cross_encoders import HuggingFaceCrossEncoder reranker HuggingFaceCrossEncoder(model_nameBAAI/bge-reranker-v2-m3) compressor CrossEncoderReranker(modelreranker, top_n4) compression_retriever ContextualCompressionRetriever( base_compressorcompressor, base_retrievervectorstore.as_retriever(search_kwargs{k: 20}) )这段代码的逻辑是底层先用向量检索召回 20 条再用重排模型精排只保留前 4 条。top_n4决定了最终进 Prompt 的片段数和直接调 k 的效果完全不同——召回范围变大了但真正送入模型的还是最相关的几条。用重排之后k20不再是噪声来源而是候选池。面试里如果你说出“我宁可召回 20 条但重排取 4 条也不直接取 4 条”面试官会认为你有真实调优经验。重排模型也要选型。bge-reranker 系列在中文上表现比较稳但模型体积从几百 MB 到 1 GB 以上不等本地部署要能接受首次加载时间。如果你在 API 环境里也可以调用付费的 rerank 接口但面试 Demo 一般本地跑开源模型就够了。4.2 混合检索BM25 向量的融合是保底方案向量检索对同义改写很友好但精确匹配却经常输给关键词检索。比如用户问“试用期是几个月”文档里写的是“试用期为三个自然月”向量检索能找到因为语义相近但如果用户问的是“试用期 3 个月”而文档里只有“3-month probation”向量检索表现看 embedding而 BM25 几乎必定命中。混合检索就是把两者结果合并去重再做重排。LangChain 的EnsembleRetriever就是干这个的from langchain.retrievers import BM25Retriever, EnsembleRetriever bm25_retriever BM25Retriever.from_documents(chunks) bm25_retriever.k 10 vector_retriever vectorstore.as_retriever(search_kwargs{k: 10}) ensemble_retriever EnsembleRetriever( retrievers[bm25_retriever, vector_retriever], weights[0.4, 0.6] # 关键词和语义的权重分配 )注意BM25Retriever需要把分块后的chunks传进去它会在内存里建立倒排索引。weights是融合权重我一般从 0.4/0.6 起步然后根据测试集调整如果文档里专业名词多适当调高 BM25 权重。这一步会让检索召回更全面但也会把 Retriever 的内存占用抬上去——文档量超过十万块时建议把 BM25 换成 Elasticsearch 的查询而不是继续在 Python 内存里硬扛。4.3 评估检索质量写个脚本看 RecallK不量化就无法调参。我习惯在项目里写一个小脚本准备二十个真实问题每个问题标出参考答案所在的文档块然后跑检索看答案是否出现在 Top-K 里。计算 RecallK 的脚本很简单def recall_at_k(retrieved_docs, golden_chunk_ids, k): hit 0 for doc in retrieved_docs[:k]: if doc.metadata.get(chunk_id) in golden_chunk_ids: hit 1 break return 1 if hit 0 else 0 # 使用示例 retrieved retriever.invoke(年假未休完会作废吗) score recall_at_k(retrieved, [chunk_023, chunk_024], k5) print(fRecall{5}: {score})这里的关键在于给每个分块打上chunk_id元数据才能把召回结果和人工标注对上。如果没有标注你可以做粗粒度评估看召回的文本里是否包含答案中的关键名词。这个脚本的作用是让你在换 embedding、调分块、加重排之后有数字告诉你到底变好还是变坏而不是靠感觉“好像更准了”。5. 上下文组装与生成Prompt 模板、引用溯源、超长截断避坑5.1 用 stuff 还是 map_reduce上下文组装三种方式的取舍RetrievalQA的chain_type决定上下文如何进 Prompt。stuff是把所有检索片段全部塞进一个 Prompt适合片段少、总 token 不超限的场景map_reduce是每个片段单独跑一遍 LLM 再汇总适合片段多但总长度爆掉的情况refine则是逐片段迭代式修改答案。面试题里最常见的追问是“如果检索出来的内容超过模型上下文窗口怎么办”。我的建议很直接先算 token。如果总上下文在模型窗口的 60% 以内用stuff质量最高因为 LLM 能看到所有原文如果超过要么降低top_n要么上map_reduce。大部分 RAG 问答场景答案依赖的片段通常不超过 4 个每个片段 500 字符总 token 也就 1500 左右根本不需要map_reduce。面试里如果一上来就选map_reduce说明你还没意识到 stuff 的语义连贯性优势。5.2 Prompt 模板让模型“只根据资料回答不编造”的写法不写 Prompt 模板的 RAG 等于裸奔。默认的 LangChain 模板能用但回答里没有引用来源遇到文档中没有答案的问题还会胡编。我的模板里至少包含三件事角色限定、检索资料区、回答规则。from langchain.prompts import PromptTemplate prompt_template PromptTemplate.from_template( 你是一个企业内部知识库问答助手。请只根据以下检索资料回答用户问题。 检索资料 {context} 用户问题{question} 回答规则 1. 如果资料中有明确答案直接回答并在末尾标注 [来源1][来源2]。 2. 如果资料中没有答案明确回答“资料中未找到相关信息”禁止编造。 3. 回答不超过 3 个要点使用简洁的书面语。 ) qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, retrieverretriever, chain_type_kwargs{prompt: prompt_template}, return_source_documentsTrue )这里的{context}是 LangChain 自动填充的检索片段拼接结果{question}就是用户问题。关键在于第 2 条规则它能在很大程度上防止模型瞎编。但注意这只是一个软约束模型仍可能无视它所以更可靠的兜底是在代码里做检查如果检索片段和问题的相关性分数普遍低于阈值直接返回“未找到资料”不调用 LLM。5.3 引用溯源与源码标注让回答可验证纯文本回答在面试 Demo 里够用但一旦做企业应用没有来源标注的回答没人敢信。我在代码里通常这样处理result qa_chain.invoke({query: 年假可以累计吗}) print(回答:, result[result]) print(引用来源:) for doc in result[source_documents]: print(-, doc.metadata.get(source), | 片段:, doc.page_content[:60])return_source_documentsTrue是 RetrievalQA 的参数当你设为 True 之后返回结果里会带上source_documents字段。每个Document里的metadata保存着来源路径这在加载时是自动写入的。如果源是 PDFmetadata 里还有page页码字段输出时可以直接拼成“来源xxx.pdf 第 3 页”。面试官看到你输出引用来源会认为你考虑到了 RAG 在生产环境中的可信度问题。5.4 上下文超长截断文本压缩检索器的另一种玩法如果重排后仍然有片段长度不一、总长容易超限的问题可以用 LangChain 的LLMChainExtractor做上下文压缩让一个轻量模型把每个检索片段压缩成和 query 相关的摘要只保留关键信息。这个思路在长文档问答里很实用from langchain.retrievers.document_compressors import LLMChainExtractor compressor LLMChainExtractor.from_llm(llm) compression_retriever ContextualCompressionRetriever( base_compressorcompressor, base_retrievervectorstore.as_retriever(search_kwargs{k: 8}) )不过要注意压缩过程本身也会调用 LLM意味着每个问题多了一轮模型调用延迟和成本都会上涨。我在项目里只在 Token 预算极紧时才用这个方案常规情况下优先缩减top_n。面试里把这个取舍讲出来比单纯背组件名更有说服力。6. 必踩的 6 个坑现象、原因与解决办法6.1 坑一检索出的片段牛头不对马嘴但换 embedding 也没用现象用户问“报销流程”召回的片段全是“报销制度概述”没有具体步骤。换更贵的 embedding 模型问题依旧。原因分块把步骤拆散到了不同的 chunk 里query 与任何一个单块的语义重合都不高而制度概述这种块反而因为词汇重合度高出险。解决改用按结构切分把每个流程步骤作为一个独立 chunk或者加大chunk_overlap使得步骤边界不会被一刀切开。另一个补救是引入混合检索让 BM25 的“报销流程”关键词命中更准。最常见的原因是分块问题其次是检索方式最后才是 embedding排查顺序别反了。6.2 坑二模型回答引用了不存在的内容即幻觉现象文档里根本没有“年假可折算工资”这句话模型却言之凿凿回答了还编了个 [来源1]。原因Prompt 里的“禁止编造”是软约束在 context 中有一段和问题沾边、但实际不含答案的内容时模型倾向于强行总结。解决第一把来源标注改成代码强制输出——只允许模型在给定片段内找答案如果找不到必须在回答里写“未找到”第二增加一个相关性校验对召回的 Top-N 片段计算与 query 的相似度分数最高分仍低于阈值时直接拒绝回答。这个校验逻辑放在调用 LLM 之前最可靠。6.3 坑三Chroma/FAISS 索引更新后旧数据还在现象替换了文档内容重新运行脚本问新闻题时模型还是回答旧信息。原因FAISS 的save_local是覆盖整个目录但如果你在原来索引基础上调用add_documents旧 doc 并没有被删除只是新向量追加进去了。解决更新文档时直接删除本地索引目录再重建或者使用带版本号的索引目录路径。我习惯用一个新目录名如faiss_index_v2同时维护一个映射文件记录版本与文档时间越简单越不容易出错生产环境再考虑向量库的增量更新能力。6.4 坑四中文问句检索不如英文准找不到同义表达现象文档写“员工离职需提前一个月申请”用户问“辞职要多久才批”召回结果完全不相关。原因embedding 模型对口语化、同义改写表达的中文泛化能力不够公共模型在这种场景下容易只匹配字面词。解决两步走第一步在检索前加一个查询改写环节——用一个便宜模型把口语化问题改写成关键词更明确的书面表达第二步用混合检索兜底。改写 Prompt 很简单“把用户问题改写成一个更适合检索的关键词组合”。这一招对 RAG 的中文效果提升非常明显但很少有人提。6.5 坑五文档量一大检索变慢甚至内存溢出现象几千页 PDF 全部加载分块后跑一次检索要好几秒加载 embedding 模型时内存直接飙到 8GB。原因HuggingFace embedding 模型加载到 CPU 内存加上向量索引和 BM25 倒排索引全部驻留内存小机器扛不住。解决把 embedding 模型换成一个更小的蒸馏版本或者用 API 调用在线 embedding向量库从 FAISS 切到支持磁盘映射的方案把 BM25 部分移到 SQLite FTS5 或 Elasticsearch 上。调试时先跑一个小批次比如前 50 页确认链路没问题再全量加载。这个坑在面试里往往会以“你的方案能支撑多少文档量”这种方式问出来答出内存瓶颈和替代方案就过关。6.6 坑六接口返回超时以为是 LangChain 问题其实是重排器太慢现象本地问答响应要 5 秒其中 LLM 只花了 1 秒。现象本地问答响应要 5 秒其中 LLM 只花了 1 秒。排查后是重排器在 CPU 上跑bge-reranker 模型体积大每次要对 20 个片段逐对推理。解决把重排候选数从 20 降到 10减少无效计算或者把重排模型换成更小的 distilled 版本再或者把重排放到 GPU 上加载。实际项目里我宁愿多召回少重排因为再好的重排也救不回糟糕的召回如果延迟指标紧张可以先用 BM25 粗筛 50 条再用向量精排 20 条最后重排 5 条每层各司其职。7. 进阶验证用自定义评测集给 RAG 一个量化分数聊完避坑最后说一个我每次做 RAG 必做、但很多教程不教的事给整个问答系统建一个微型评测集。这个评测集的形态很简单——20 到 30 条问答对每一条包含输入问题、期望答案里的必须包含的关键词、期望检索命中的文档块。评测时跑一遍全流程对每一条输出三份记录检索命中了没、答案关键词覆盖了几个、答案有没有胡编。用一个小脚本汇总成百分比就是你这个 RAG 系统的基线分。这个脚本我不建议做得太复杂够用就行eval_questions [ {question: 离职需要提前多久申请, must_keywords: [30天, 一个月], gold_chunks: [chunk_012]}, {question: 报销上限是多少, must_keywords: [5000, 5000元], gold_chunks: [chunk_045]}, ] all_scores [] for item in eval_questions: q item[question] result qa_chain.invoke({query: q}) answer result[result] retrieved_chunks [d.metadata.get(chunk_id) for d in result[source_documents]] recall_hit item[gold_chunks][0] in retrieved_chunks keyword_hit sum(1 for kw in item[must_keywords] if kw in answer) all_scores.append({ question: q, recall: recall_hit, keyword_ratio: keyword_hit / len(item[must_keywords]) }) recall_rate sum(s[recall] for s in all_scores) / len(all_scores) keyword_avg sum(s[keyword_ratio] for s in all_scores) / len(all_scores) print(fRecall Rate: {recall_rate:.2%}) print(fKeyword Coverage: {keyword_avg:.2%})这套小评测有三个好处第一改任何参数后跑一遍就能知道是变好还是变坏不用靠主观感受第二面试官问“你怎么证明你的 RAG 好用”你直接甩出 Recall Rate 和 Keyword Coverage 两个数字比一万句描述都顶用第三它能倒推你该优化哪一环如果 recall 低回去调分块、换 embedding如果 recall 高但 keyword 低问题在 Prompt 或生成参数上。我还习惯把每次评测的分数和当时的参数配置写进一个固定格式的笔记里比如chunk_500_overlap_80_k4_rerank_bge_v2下次再调参数一眼就能看出哪个组合的分数最高。这个过程听起来麻烦但一次调参可能要跑十几遍没有记录很容易今天觉得这个好、明天觉得那个好最后项目烂尾在参数选择上。最后一个个人习惯每次跑新文档集先不追求高分数。我会先拿一条文档里明显存在答案的问题做冒烟测试链路通了再上评测集。因为这个领域里八股文背得再熟也抵不过一次次参数对比练出来的手感。多跑几遍你会慢慢发现哪些指标受chunk_size影响大哪些受重排模型影响大哪种文档又需要用混合检索兜底。这才是别人说的“玄学”背后的真实规律。希望这篇笔记能帮你把 RAG 从背诵题变成实操题也祝你在下一次面试或项目里少踩几个坑。本文还有配套的精品资源点击获取
简介面向大模型与人工智能开发者的实战型PDF文档系统演示如何基于LangChain从零实现一个RAG问答应用。文档选取百度百科中的藜麦数据模拟个人或企业私域数据完整覆盖项目策划、环境搭建CUDA 11.7、Python 3.10、PyTorch 1.13.1cu117、LangChain、数据保存与本地加载、文档分割、向量化、向量数据库入库等全流程。实战环节给出了可直接运行的代码用TextLoader读取本地txt文件用CharacterTextSplitter按128字符长度切分再以m3e-base模型生成Embedding并写入Chroma数据库同时对OCR识别可能导致的文字错漏、依赖安装顺序等实操问题提供提醒并为理解数据上下文补充了藜麦的背景知识。资源包仅含1个PDF文件整包大小390KB内容紧凑、步骤清晰便于按章节对照练习。目前已有285人学习/浏览既适合正在入门RAG应用开发、希望快速跑通LangChain检索问答链路的读者也适合准备大模型岗位面试时梳理相关技术要点。1. 大模型八股文面试里的 RAG 实战这道题到底在考什么这两年大模型面试几乎绕不开 RAG尤其当你报的是应用方向岗位面试官很少再问“什么是检索增强生成”这种概念题而是直接甩过来一句“你用 LangChain 搭过 RAG 问答吗” 这个标题看起来像一份面试资料其实背后是一条完整的技能链路你要能在半小时内讲清楚 RAG 的检索、重排、生成三截流水线还要能说出为什么用向量库而不是拿数据库硬撸更要能现场给出一个能跑的代码骨架。单纯背八股文没用因为追问全在细节里分块尺寸设多少、Top-K 取几、召回率低是调 embedding 还是调重排、上下文爆掉怎么办。这篇文章就把我平时带人准备这套面试题时讲的完整方案写出来从原理到最小可运行代码再到参数边界和排错经验读完你不仅答得上题还能当场写出来。2. 从八股到落地RAG 的完整链路和选型理由2.1 RAG 为什么不是“向量检索 塞进 Prompt”那么简单很多面试者第一句话就说“RAG 就是先检索再生成”这话没错但等于没说。真正的 RAG 是一条有明确失败点的流水线文档加载、文本分块、嵌入向量化、向量存储、相似度检索、候选重排、上下文组装、LLM 生成。任何一个环节偷懒最终答案质量都会崩而且崩法各不相同——分块太大导致检索命中噪声多分块太小导致语义不完整embedding 选错导致召回率低重排缺失导致正确答案被埋在第 5 位之后。面试官追问的往往不是你对 RAG 有多乐观而是你有没有被这些问题毒打过。从工程选型角度看我一般会把 RAG 拆成两个决策点检索质量决策和生成质量决策。检索质量由 embedding 模型、分块策略、向量库、检索参数、重排模型共同决定生成质量则由 Prompt 模板、上下文长度控制、引用来源标注、模型温度参数决定。LangChain 的价值不在于它多智能而在于它把这几个环节抽象成了标准组件让你能快速替换和对比。你在面试里如果能说出“我先用哪一层做实验、用什么指标判断好坏”就已经超过大多数只会背流程的候选人。2.2 LangChain 的组件抽象从 Loader 到 RetrievalQA 的调用链LangChain 的 RAG 链路在代码里是一条清晰的链式调用。最精简的骨架是这样加载文档用DirectoryLoader或PyPDFLoader分块用RecursiveCharacterTextSplitter向量化用某个 embedding 模型存储用Chroma或FAISS检索后用RetrievalQA把检索结果和问题一起交给 LLM。这个骨架代码短但每个环节都有默认参数埋着坑。下面是本地跑通 RAG 问答的最小命令集。假设你有一个 PDF 文档目录要把它变成能问能答的本地问答服务from langchain_community.document_loaders import PyPDFLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.vectorstores import FAISS from langchain_openai import OpenAIEmbeddings from langchain_openai import ChatOpenAI from langchain.chains import RetrievalQA # 1. 加载 PDF 文档 loader PyPDFLoader(docs/employee_handbook.pdf) documents loader.load() # 2. 分块每块 500 字符重叠 80 字符 text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap80, separators[\n\n, \n, 。, , , ., !, ?, , ] ) chunks text_splitter.split_documents(documents) # 3. 向量化并存入 FAISS 本地索引 embeddings OpenAIEmbeddings(modeltext-embedding-ada-002) vectorstore FAISS.from_documents(chunks, embeddings) vectorstore.save_local(faiss_index) # 4. 构建检索问答链 llm ChatOpenAI(modelgpt-4o-mini, temperature0) qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, retrievervectorstore.as_retriever(search_kwargs{k: 4}), return_source_documentsTrue ) # 5. 提问 response qa_chain.invoke({query: 年假可以累计到下一年吗}) print(response[result])这段代码的逻辑并不复杂先是把 PDF 解析成 LangChain 的 Document 对象再按递归分隔符切块接着把每个块转成向量写入本地索引最后把“检索器 大模型”组装成问答链。这里有两个参数值得你单独解释给面试官听chunk_size500决定了每个检索单元的信息密度chunk_overlap80是为了避免句子在切分处被拦腰截断导致语义残缺k4则控制送入 Prompt 的候选片段数量。面试官如果接着问“为什么用 FAISS 不用别的”你要答得出来FAISS 是 Meta 开源的向量检索库支持余弦相似度和 L2 距离索引在本地文件里落地对快速 Demo 最友好生产环境换 Milvus 或 Elasticsearch 的向量索引也只是替换一个类的问题。2.3 Embedding 选型决定召回上限的第一步很多人把 RAG 的成败押在 Prompt 上但真正决定检索上限的是 embedding 模型。同一个问题不同的 embedding 模型召回的 Top-5 可能完全不一样。中文场景尤其明显通用英文 embedding 对中文长句的语义区分度差检索出来的片段经常是字面重合但语义无关。我的选择标准是优先在 MTEB 中文榜单上有稳定表现的开源模型然后用自己的测试集实际跑一遍 RecallK不要只看榜单数字。实际代码里需要改的只是 embeddings 对象from langchain_community.embeddings import HuggingFaceEmbeddings embeddings HuggingFaceEmbeddings( model_nameBAAI/bge-large-zh-v1.5, encode_kwargs{normalize_embeddings: True} )这里normalize_embeddingsTrue容易被忽略但它很关键归一化之后用内积计算相似度等价于余弦相似度在 FAISS 里可以直接用METRIC_INNER_PRODUCT加速检索。面试末了聊性能时这个细节能说明你不是只会调包。另外本地加载 embedding 模型需要 GPU 或较好的 CPU首次运行会下载权重这些环境问题要提前说清楚别在面试现场卡住。3. 从 PDF 到可问答知识库完整落地步骤3.1 文档加载的五个隐蔽问题PyPDFLoader看起来简单但真实 PDF 里全是坑。我遇到过扫描版 PDF 需要 OCR、表格被解析成乱序文本、多栏排版导致文字跨栏拼接、加密 PDF 直接抛异常、PDF 内嵌字体缺失导致中文变成空白。面试里你可以不说这些但动手做项目时你一定会碰到。我一般建议按文档类型分流文本型 PDF 直接用PyPDFLoader扫描版走RapidOCR或PaddleOCRWord 文档用Docx2txtLoaderMarkdown 和 HTML 用各自的 Loader。更稳妥的做法是先把所有文档统一转成 Markdown 或纯文本再做清洗、去页眉页脚、合并断行最后进入 LangChain。这个预处理步骤在项目里大概占 30% 的工作量但很少有人写进简历。一个容易忽略的点是 PDF 里的页眉页脚会被当成正文读进来。比如每页都有的“第 3 页/共 20 页”和公司名会让检索结果频繁命中这些噪声。处理方式是在分块之前清洗import re cleaned_docs [] for doc in documents: text re.sub(r\n\s*第\s*\d\s*页[^\n]*, , doc.page_content) text re.sub(r[\u00a0\u200b], , text) doc.page_content text.strip() cleaned_docs.append(doc)这段正则把常见的中文页脚“第 3 页”字样删掉同时去掉零宽空格和非法空白字符。注意这里不要用一行正则解决一切PDF 解析出来的换行很乱建议先把文本打印出来看两页再写针对性规则。面试官很喜欢问“你清洗过哪些脏数据”你能说出页眉页脚、全角半角混杂、OCR 的错别字这三类就已经有真实项目味道了。3.2 分块策略chunk_size 与 chunk_overlap 的调参逻辑分块是整个 RAG 里最像“玄学”的环节。没有哪个参数对所有文档最优但有一套经验法则参数建议范围设置依据chunk_size300–800 字符中文500 左右能保持语义完整又不至于引入过多噪声chunk_overlap50–150 字符至少覆盖一个句子的长度避免断句丢主语separators 顺序先按段落再按句子最后按词优先保持自然语义边界为什么中文按字符算而不是按 token 算因为 LangChain 的RecursiveCharacterTextSplitter默认按字符长度切分而中文字符和英文字符的信息密度差异很大。如果你直接用英文教程里的 1000 字符中文文档会被切得过碎。另一个细节separators列表里的顺序就是切分优先级如果你把空格放在句号前面英文文档会在单词边界被切得乱七八糟。我把中文句号、感叹号、问号放在英文标点前面就是为了让中文文档优先在完整句子处断开。如果你的文档是结构化问答或者 FAQ 格式分块策略可以更激进——直接按条目切。下面这段代码展示了一个简单但有效的处理方式from langchain.schema import Document def split_faq(documents): result [] for doc in documents: # 假设每个 FAQ 条目以数字序号开头 blocks re.split(r\n(?\d\.\s), doc.page_content) for block in blocks: if len(block.strip()) 30: result.append(Document(page_contentblock.strip(), metadata{source: doc.metadata.get(source, )})) return result这种按结构切分的方式比统一chunk_size效果更好因为每个块本身就是一个完整问答对检索命中后直接作为上下文几乎不需要 LLM 做二次理解。面试里能讲出“我按文档结构切分而非统一长度切分”是一个明显的加分项。3.3 向量库与检索参数k 值、相似度阈值、返回字段向量库选型在面试里是个高频追问。我把常用方案列了个对照表方案适合场景主要限制FAISS单机原型、百万元素内不支持增量删改需重建索引Chroma本地快速迭代、元数据过滤大规模并发性能一般Milvus生产环境、千万级向量、高并发需要独立部署和维护Elasticsearch knn已有 ES 体系的团队向量性能依赖插件和配置我平时做面试 Demo 用 FAISS 最多因为save_local一个文件夹就能带走部署到服务器也方便。但你要知道 FAISS 不支持真正意义上的单条删除如果文档更新频繁常见做法是重建索引或者用分段索引。这个问题在面试里常被用来考察你的生产意识。检索参数里最值得调的是k和相似度阈值。k4是我习惯的初始值面试时可以这样说k 太小容易漏掉正确答案k 太大容易把无关片段塞进上下文导致 LLM 被噪声干扰。更好的做法是加一个相似度分数过滤低于阈值的片段直接丢弃retriever vectorstore.as_retriever( search_kwargs{k: 8, score_threshold: 0.5} )注意 FAISS 的score_threshold在不同检索类型下含义不同默认的similarity_search里分数是距离或相似度取决于索引类型similarity_search_with_score返回的分数范围也和 embedding 模型有关系。很多初学者在这里翻车bge 模型默认输出相似度分数较高而 ada-002 的分数整体偏低用一个固定阈值套所有模型就会出问题。所以我后面用重排替代阈值过滤这是更稳的方案。4. 检索质量不高怎么办重排与混合检索的实战补救4.1 重排Rerank为什么比单纯调 k 值有效向量检索的 Top-K 结果往往只有前两三条是准的后面几条开始跑偏。单纯把 k 从 4 调到 8只会让更多噪声进入 Prompt。重排模型的作用是拿一个更强的交叉编码器对候选片段和 query 做逐对匹配重新打分数。这一步很便宜因为只需要对已经召回的 10–20 条做过一次精排。LangChain 里接入重排的常见做法是ContextualCompressionRetrieverfrom langchain.retrievers.document_compressors import CrossEncoderReranker from langchain_community.cross_encoders import HuggingFaceCrossEncoder reranker HuggingFaceCrossEncoder(model_nameBAAI/bge-reranker-v2-m3) compressor CrossEncoderReranker(modelreranker, top_n4) compression_retriever ContextualCompressionRetriever( base_compressorcompressor, base_retrievervectorstore.as_retriever(search_kwargs{k: 20}) )这段代码的逻辑是底层先用向量检索召回 20 条再用重排模型精排只保留前 4 条。top_n4决定了最终进 Prompt 的片段数和直接调 k 的效果完全不同——召回范围变大了但真正送入模型的还是最相关的几条。用重排之后k20不再是噪声来源而是候选池。面试里如果你说出“我宁可召回 20 条但重排取 4 条也不直接取 4 条”面试官会认为你有真实调优经验。重排模型也要选型。bge-reranker 系列在中文上表现比较稳但模型体积从几百 MB 到 1 GB 以上不等本地部署要能接受首次加载时间。如果你在 API 环境里也可以调用付费的 rerank 接口但面试 Demo 一般本地跑开源模型就够了。4.2 混合检索BM25 向量的融合是保底方案向量检索对同义改写很友好但精确匹配却经常输给关键词检索。比如用户问“试用期是几个月”文档里写的是“试用期为三个自然月”向量检索能找到因为语义相近但如果用户问的是“试用期 3 个月”而文档里只有“3-month probation”向量检索表现看 embedding而 BM25 几乎必定命中。混合检索就是把两者结果合并去重再做重排。LangChain 的EnsembleRetriever就是干这个的from langchain.retrievers import BM25Retriever, EnsembleRetriever bm25_retriever BM25Retriever.from_documents(chunks) bm25_retriever.k 10 vector_retriever vectorstore.as_retriever(search_kwargs{k: 10}) ensemble_retriever EnsembleRetriever( retrievers[bm25_retriever, vector_retriever], weights[0.4, 0.6] # 关键词和语义的权重分配 )注意BM25Retriever需要把分块后的chunks传进去它会在内存里建立倒排索引。weights是融合权重我一般从 0.4/0.6 起步然后根据测试集调整如果文档里专业名词多适当调高 BM25 权重。这一步会让检索召回更全面但也会把 Retriever 的内存占用抬上去——文档量超过十万块时建议把 BM25 换成 Elasticsearch 的查询而不是继续在 Python 内存里硬扛。4.3 评估检索质量写个脚本看 RecallK不量化就无法调参。我习惯在项目里写一个小脚本准备二十个真实问题每个问题标出参考答案所在的文档块然后跑检索看答案是否出现在 Top-K 里。计算 RecallK 的脚本很简单def recall_at_k(retrieved_docs, golden_chunk_ids, k): hit 0 for doc in retrieved_docs[:k]: if doc.metadata.get(chunk_id) in golden_chunk_ids: hit 1 break return 1 if hit 0 else 0 # 使用示例 retrieved retriever.invoke(年假未休完会作废吗) score recall_at_k(retrieved, [chunk_023, chunk_024], k5) print(fRecall{5}: {score})这里的关键在于给每个分块打上chunk_id元数据才能把召回结果和人工标注对上。如果没有标注你可以做粗粒度评估看召回的文本里是否包含答案中的关键名词。这个脚本的作用是让你在换 embedding、调分块、加重排之后有数字告诉你到底变好还是变坏而不是靠感觉“好像更准了”。5. 上下文组装与生成Prompt 模板、引用溯源、超长截断避坑5.1 用 stuff 还是 map_reduce上下文组装三种方式的取舍RetrievalQA的chain_type决定上下文如何进 Prompt。stuff是把所有检索片段全部塞进一个 Prompt适合片段少、总 token 不超限的场景map_reduce是每个片段单独跑一遍 LLM 再汇总适合片段多但总长度爆掉的情况refine则是逐片段迭代式修改答案。面试题里最常见的追问是“如果检索出来的内容超过模型上下文窗口怎么办”。我的建议很直接先算 token。如果总上下文在模型窗口的 60% 以内用stuff质量最高因为 LLM 能看到所有原文如果超过要么降低top_n要么上map_reduce。大部分 RAG 问答场景答案依赖的片段通常不超过 4 个每个片段 500 字符总 token 也就 1500 左右根本不需要map_reduce。面试里如果一上来就选map_reduce说明你还没意识到 stuff 的语义连贯性优势。5.2 Prompt 模板让模型“只根据资料回答不编造”的写法不写 Prompt 模板的 RAG 等于裸奔。默认的 LangChain 模板能用但回答里没有引用来源遇到文档中没有答案的问题还会胡编。我的模板里至少包含三件事角色限定、检索资料区、回答规则。from langchain.prompts import PromptTemplate prompt_template PromptTemplate.from_template( 你是一个企业内部知识库问答助手。请只根据以下检索资料回答用户问题。 检索资料 {context} 用户问题{question} 回答规则 1. 如果资料中有明确答案直接回答并在末尾标注 [来源1][来源2]。 2. 如果资料中没有答案明确回答“资料中未找到相关信息”禁止编造。 3. 回答不超过 3 个要点使用简洁的书面语。 ) qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, retrieverretriever, chain_type_kwargs{prompt: prompt_template}, return_source_documentsTrue )这里的{context}是 LangChain 自动填充的检索片段拼接结果{question}就是用户问题。关键在于第 2 条规则它能在很大程度上防止模型瞎编。但注意这只是一个软约束模型仍可能无视它所以更可靠的兜底是在代码里做检查如果检索片段和问题的相关性分数普遍低于阈值直接返回“未找到资料”不调用 LLM。5.3 引用溯源与源码标注让回答可验证纯文本回答在面试 Demo 里够用但一旦做企业应用没有来源标注的回答没人敢信。我在代码里通常这样处理result qa_chain.invoke({query: 年假可以累计吗}) print(回答:, result[result]) print(引用来源:) for doc in result[source_documents]: print(-, doc.metadata.get(source), | 片段:, doc.page_content[:60])return_source_documentsTrue是 RetrievalQA 的参数当你设为 True 之后返回结果里会带上source_documents字段。每个Document里的metadata保存着来源路径这在加载时是自动写入的。如果源是 PDFmetadata 里还有page页码字段输出时可以直接拼成“来源xxx.pdf 第 3 页”。面试官看到你输出引用来源会认为你考虑到了 RAG 在生产环境中的可信度问题。5.4 上下文超长截断文本压缩检索器的另一种玩法如果重排后仍然有片段长度不一、总长容易超限的问题可以用 LangChain 的LLMChainExtractor做上下文压缩让一个轻量模型把每个检索片段压缩成和 query 相关的摘要只保留关键信息。这个思路在长文档问答里很实用from langchain.retrievers.document_compressors import LLMChainExtractor compressor LLMChainExtractor.from_llm(llm) compression_retriever ContextualCompressionRetriever( base_compressorcompressor, base_retrievervectorstore.as_retriever(search_kwargs{k: 8}) )不过要注意压缩过程本身也会调用 LLM意味着每个问题多了一轮模型调用延迟和成本都会上涨。我在项目里只在 Token 预算极紧时才用这个方案常规情况下优先缩减top_n。面试里把这个取舍讲出来比单纯背组件名更有说服力。6. 必踩的 6 个坑现象、原因与解决办法6.1 坑一检索出的片段牛头不对马嘴但换 embedding 也没用现象用户问“报销流程”召回的片段全是“报销制度概述”没有具体步骤。换更贵的 embedding 模型问题依旧。原因分块把步骤拆散到了不同的 chunk 里query 与任何一个单块的语义重合都不高而制度概述这种块反而因为词汇重合度高出险。解决改用按结构切分把每个流程步骤作为一个独立 chunk或者加大chunk_overlap使得步骤边界不会被一刀切开。另一个补救是引入混合检索让 BM25 的“报销流程”关键词命中更准。最常见的原因是分块问题其次是检索方式最后才是 embedding排查顺序别反了。6.2 坑二模型回答引用了不存在的内容即幻觉现象文档里根本没有“年假可折算工资”这句话模型却言之凿凿回答了还编了个 [来源1]。原因Prompt 里的“禁止编造”是软约束在 context 中有一段和问题沾边、但实际不含答案的内容时模型倾向于强行总结。解决第一把来源标注改成代码强制输出——只允许模型在给定片段内找答案如果找不到必须在回答里写“未找到”第二增加一个相关性校验对召回的 Top-N 片段计算与 query 的相似度分数最高分仍低于阈值时直接拒绝回答。这个校验逻辑放在调用 LLM 之前最可靠。6.3 坑三Chroma/FAISS 索引更新后旧数据还在现象替换了文档内容重新运行脚本问新闻题时模型还是回答旧信息。原因FAISS 的save_local是覆盖整个目录但如果你在原来索引基础上调用add_documents旧 doc 并没有被删除只是新向量追加进去了。解决更新文档时直接删除本地索引目录再重建或者使用带版本号的索引目录路径。我习惯用一个新目录名如faiss_index_v2同时维护一个映射文件记录版本与文档时间越简单越不容易出错生产环境再考虑向量库的增量更新能力。6.4 坑四中文问句检索不如英文准找不到同义表达现象文档写“员工离职需提前一个月申请”用户问“辞职要多久才批”召回结果完全不相关。原因embedding 模型对口语化、同义改写表达的中文泛化能力不够公共模型在这种场景下容易只匹配字面词。解决两步走第一步在检索前加一个查询改写环节——用一个便宜模型把口语化问题改写成关键词更明确的书面表达第二步用混合检索兜底。改写 Prompt 很简单“把用户问题改写成一个更适合检索的关键词组合”。这一招对 RAG 的中文效果提升非常明显但很少有人提。6.5 坑五文档量一大检索变慢甚至内存溢出现象几千页 PDF 全部加载分块后跑一次检索要好几秒加载 embedding 模型时内存直接飙到 8GB。原因HuggingFace embedding 模型加载到 CPU 内存加上向量索引和 BM25 倒排索引全部驻留内存小机器扛不住。解决把 embedding 模型换成一个更小的蒸馏版本或者用 API 调用在线 embedding向量库从 FAISS 切到支持磁盘映射的方案把 BM25 部分移到 SQLite FTS5 或 Elasticsearch 上。调试时先跑一个小批次比如前 50 页确认链路没问题再全量加载。这个坑在面试里往往会以“你的方案能支撑多少文档量”这种方式问出来答出内存瓶颈和替代方案就过关。6.6 坑六接口返回超时以为是 LangChain 问题其实是重排器太慢现象本地问答响应要 5 秒其中 LLM 只花了 1 秒。现象本地问答响应要 5 秒其中 LLM 只花了 1 秒。排查后是重排器在 CPU 上跑bge-reranker 模型体积大每次要对 20 个片段逐对推理。解决把重排候选数从 20 降到 10减少无效计算或者把重排模型换成更小的 distilled 版本再或者把重排放到 GPU 上加载。实际项目里我宁愿多召回少重排因为再好的重排也救不回糟糕的召回如果延迟指标紧张可以先用 BM25 粗筛 50 条再用向量精排 20 条最后重排 5 条每层各司其职。7. 进阶验证用自定义评测集给 RAG 一个量化分数聊完避坑最后说一个我每次做 RAG 必做、但很多教程不教的事给整个问答系统建一个微型评测集。这个评测集的形态很简单——20 到 30 条问答对每一条包含输入问题、期望答案里的必须包含的关键词、期望检索命中的文档块。评测时跑一遍全流程对每一条输出三份记录检索命中了没、答案关键词覆盖了几个、答案有没有胡编。用一个小脚本汇总成百分比就是你这个 RAG 系统的基线分。这个脚本我不建议做得太复杂够用就行eval_questions [ {question: 离职需要提前多久申请, must_keywords: [30天, 一个月], gold_chunks: [chunk_012]}, {question: 报销上限是多少, must_keywords: [5000, 5000元], gold_chunks: [chunk_045]}, ] all_scores [] for item in eval_questions: q item[question] result qa_chain.invoke({query: q}) answer result[result] retrieved_chunks [d.metadata.get(chunk_id) for d in result[source_documents]] recall_hit item[gold_chunks][0] in retrieved_chunks keyword_hit sum(1 for kw in item[must_keywords] if kw in answer) all_scores.append({ question: q, recall: recall_hit, keyword_ratio: keyword_hit / len(item[must_keywords]) }) recall_rate sum(s[recall] for s in all_scores) / len(all_scores) keyword_avg sum(s[keyword_ratio] for s in all_scores) / len(all_scores) print(fRecall Rate: {recall_rate:.2%}) print(fKeyword Coverage: {keyword_avg:.2%})这套小评测有三个好处第一改任何参数后跑一遍就能知道是变好还是变坏不用靠主观感受第二面试官问“你怎么证明你的 RAG 好用”你直接甩出 Recall Rate 和 Keyword Coverage 两个数字比一万句描述都顶用第三它能倒推你该优化哪一环如果 recall 低回去调分块、换 embedding如果 recall 高但 keyword 低问题在 Prompt 或生成参数上。我还习惯把每次评测的分数和当时的参数配置写进一个固定格式的笔记里比如chunk_500_overlap_80_k4_rerank_bge_v2下次再调参数一眼就能看出哪个组合的分数最高。这个过程听起来麻烦但一次调参可能要跑十几遍没有记录很容易今天觉得这个好、明天觉得那个好最后项目烂尾在参数选择上。最后一个个人习惯每次跑新文档集先不追求高分数。我会先拿一条文档里明显存在答案的问题做冒烟测试链路通了再上评测集。因为这个领域里八股文背得再熟也抵不过一次次参数对比练出来的手感。多跑几遍你会慢慢发现哪些指标受chunk_size影响大哪些受重排模型影响大哪种文档又需要用混合检索兜底。这才是别人说的“玄学”背后的真实规律。希望这篇笔记能帮你把 RAG 从背诵题变成实操题也祝你在下一次面试或项目里少踩几个坑。本文还有配套的精品资源点击获取
