简介这是一份聚焦大模型RAG问答应用实战的PDF文档面向人工智能领域正在准备大模型八股文面试的求职者以及希望快速上手LangChain开发框架的工程师。资源以百度百科中的藜麦数据模拟个人或企业的私域数据完整演示了从环境搭建到问答系统落地的流程包括CUDA、Python、PyTorch等依赖版本选型本地文档加载、固定长度字符分割、向量化入库以及基于Chroma和m3e-base模型的检索实现并配有可直接参考的代码片段。包内仅含1个PDF文件容量约为390KB内容紧凑但关键步骤齐全。目前已有283人浏览学习对面试复盘和实战入门均有参考价值。通过阅读这份材料读者可以系统理解RAG应用的通用开发链路同时掌握文档切片策略、OCR识别误差处理、数据清洗等实用技巧是一份兼顾面试知识点与上手实操的优质资料。1. 面试官一句“讲讲你的 RAG”为什么多数人当场翻车大模型八股文面试里RAG检索增强生成是被问得最频繁、也最容易露怯的话题。背得出“检索增强生成”六个字的人不少能当场画出链路图、说出切分策略对召回率的影响、解释为什么embedding模型选不好答案就偏的寥寥无几。这份笔记按“基于 LangChain 的 RAG 问答应用实战”这条线把索引构建、检索召回、生成融合三段链路全部拆开落到可复现的代码和参数上。适合两类人准备大模型岗位面试、需要拿真实项目撑住追问的候选人以及已经在用 LangChain 搭知识库问答、但回答质量不稳定、想系统调优的工程师。读完你至少能应对从“原理是什么”到“chunk_size 设多少、为什么”的连环追问。2. RAG 的链路拆开看索引、检索、生成各自在解决什么问题2.1 为什么大模型需要外挂知识库参数记忆与检索记忆的边界大模型的知识全部压缩在权重里训练 cutoff 之后的事情它不知道公司内部的制度文档、产品手册、私有代码它更没见过。所谓“幻觉”本质上是模型在参数记忆里找不到答案时用语言习惯“编”了一个最像样的回答。RAG 的思路很直接不让模型裸答先从一个外部知识库里检索出与问题最相关的片段把这些片段拼进提示词再让模型基于这些片段作答。这样一来模型不需要“记住”私有知识只需要“读懂”检索结果并复述、归纳、推理。这个边界决定了 RAG 的适用范围知识更新频繁、答案需要可追溯、领域词汇特殊容易幻觉的场景都适合用 RAG。反过来如果问题需要跨文档推理、需要多跳逻辑纯 RAG 会力不从心因为切片之后上下文被物理切断了。面试官问你“RAG 和微调怎么选”标准回答就是知识变更频繁选 RAG风格与能力塑造选微调两者不冲突也可以叠加。你还需要说清楚RAG 的召回质量直接决定生成质量的上限——检索回来的片段里没有答案模型再强也答不对这是全链路里最核心的认知。2.2 LangChain 在 RAG 里承担的角色编排层而非模型层LangChain 不提供大模型也不提供向量数据库它做的是编排把文档加载、文本切分、向量化、存储、检索、提示词组装、模型调用、输出解析这一串动作串成标准流水线。面试里常被追问的“LangChain 解决了什么问题”答案就是它把 RAG 的工程套路模板化了你不需要自己写文档解析、不用手工拼提示词、不用为每家向量库写一套调用代码。对比直接调 OpenAI API 手搓 RAGLangChain 省掉的是胶水代码代价是引入了一层抽象排错时要多查一层。常见做法是 LangChain 只做编排embedding 模型和 LLM 都可以替换成任意厂商的实现甚至本地部署的模型。面试官如果追问“LangChain 是不是必须的”诚实回答不是RAG 的核心是检索链路本身LangChain 只是让链路更标准化。真正体现功底的细节在于loader 选什么、splitter 参数怎么设、embedding 维度与检索阈值的匹配、以及提示词里对“无答案”场景的约束。这些才是 RAG 应用质量的胜负手也是本笔记后面要展开的重点。2.3 RAG 的经典三段式流程与数据流向一次完整的 RAG 问答数据是这样流动的原始文档先进 loader变成纯文本纯文本进 splitter按语义或长度切成若干块每一块经过 embedding 模型变成向量写入向量数据库用户提问时问题文本被同一个 embedding 模型向量化在向量库里做相似度检索取 top-k 个最相关的块这些块连同问题一起组装进提示词交给 LLM 生成答案。索引阶段是离线的检索和生成是在线的。面试时把这条线画清楚已经能拿基础分。进阶分来自你能讲出每个环节的取舍切分粒度影响检索单元的大小embedding 模型决定相似度计算的空间top-k 决定上下文宽度提示词决定生成时如何利用这些上下文。下面进入实战部分我用一套最小可复现的代码把这条链路跑通然后逐参数讲怎么调。3. 用 LangChain 跑通最小 RAG从文档加载到问答的完整代码3.1 环境准备与依赖选择避免版本地狱的固定组合先把依赖装齐。这个组合是我反复验证过比较稳的langchain 主库负责编排langchain-community 提供 loader 和向量库封装langchain-openai 提供 LLM 和 embedding 的接口chromadb 做本地向量存储。安装命令如下pip install langchain langchain-community langchain-openai chromadb装完后用pip show langchain确认版本号。LangChain 0.2 之后拆成了多个子包如果你在网上搜到旧教程用的是from langchain.embeddings import OpenAIEmbeddings在新版本里要改成from langchain_openai import OpenAIEmbeddings这是最常见的版本迁移坑。另外要注意langchain-community 里的文档加载器和向量库封装依赖各自独立的第三方库比如加载 PDF 需要 pypdf加载 docx 需要 python-docx用到哪个装哪个不要一次装一大堆。如果你本地没有 OpenAI 的 API key也可以换成完全本地化的方案embedding 用HuggingFaceEmbeddings配BAAI/bge-small-zhLLM 用 ollama 拉一个 qwen 模型LangChain 的接口封装是统一的代码改动量只有几行。面试时可以主动提这件事表明你知道 embedding 和 LLM 都是可替换的这比死记 API 更加分。3.2 文档加载与切分chunk_size 和 overlap 的第一层影响先写一个最小可用的索引构建脚本。这里用最常见的场景加载一份本地文本文件切分成块向量化写入 Chromafrom langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import Chroma # 1. 加载文档 loader TextLoader(knowledge_base.txt, encodingutf-8) documents loader.load() # 2. 切分文本 text_splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap100, separators[\n\n, \n, 。, , , , , ], ) chunks text_splitter.split_documents(documents) # 3. 向量化并写入向量库 embeddings OpenAIEmbeddings(modeltext-embedding-3-small) vectorstore Chroma.from_documents( documentschunks, embeddingembeddings, persist_directory./chroma_db, ) print(f切分成 {len(chunks)} 个块)chunk_size500意味着每个文本块大约 500 个字符chunk_overlap100表示相邻块之间保留 100 个字符的重叠。RecursiveCharacterTextSplitter 的切分逻辑是按优先级依次尝试分隔符先从双换行切不行再按单换行切再不行按句号切直到块长满足 chunk_size 约束。这样做的目的是尽量把语义完整的句子保留在同一块里。separators里的中文标点是我后加的因为默认分隔符对中文支持不好这是中文 RAG 必须改的第一个参数。向量库选 Chroma 是因为它是纯本地、零配置、够测试用。生产环境常见做法是换 Elasticsearch、Milvus 或者 pgvectorLangChain 的接口基本一致改动成本不高。注意persist_directory指定了持久化目录不传这个参数数据只存在内存里进程一结束就丢了。3.3 检索与生成构建问答链路的两种写法索引建好之后写问答代码。以下是新旧两种 API 写法的对比新版 LCEL 语法更推荐面试也常被问到两者的区别from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser from langchain_core.runnables import RunnablePassthrough # 从磁盘加载已存在的向量库 vectorstore Chroma( persist_directory./chroma_db, embedding_functionOpenAIEmbeddings(modeltext-embedding-3-small), ) # 构造检索器默认取 top-4 个块 retriever vectorstore.as_retriever(search_kwargs{k: 4}) # 提示词模板约束模型只基于上下文回答 prompt ChatPromptTemplate.from_messages([ (system, 你是一个问答助手。只能依据提供的上下文回答问题。 如果上下文中没有答案直接说知识库中未找到相关内容不要编造。), (human, 上下文\n{context}\n\n问题{question}), ]) # LCEL 链检索 提示词组装 模型调用 输出解析 def format_docs(docs): return \n\n.join(doc.page_content for doc in docs) chain ( {context: retriever | format_docs, question: RunnablePassthrough()} | prompt | ChatOpenAI(modelgpt-4o-mini, temperature0) | StrOutputParser() ) answer chain.invoke(公司年假制度是什么) print(answer)retriever | format_docs是 LangChain 的管道运算符意思是先把检索结果传给 format_docs 函数拼成字符串再作为 context 变量传给提示词。temperature0是问答场景的标配保证输出稳定、少创造性发挥。k4控制了给模型的上下文宽度k 太大容易塞进无关片段干扰判断k 太小可能漏答案后面会专门讲怎么调。老版本写法是RetrievalQA.from_chain_type(...)现在仍然能跑但官方已不推荐。面试官如果问你 LCEL 和旧 API 的区别答“LCEL 支持流式输出、异步调用、并行执行而且链路本身是可运行的对象”就够了。4. 把问答质量从“能用”调到“好用”四个必调参数4.1 embedding 模型选型中文场景为什么优先考虑 bge 系列RAG 的检索质量首先取决于向量空间是否“懂”你的语言。OpenAI 的 text-embedding-3-small 对英文和常见中文效果都不错但如果你的知识库充满行业术语、专有名词、缩写通用 embedding 会把语义相近但用词不同的句子拉得很远。中文社区实践下来BAAI 的 bge 系列在中文语义相似度上表现稳定尤其 bge-large-zh-v1.5检索效果在 C-MTEB 榜单上长期靠前。换成 HuggingFaceEmbeddings 只需改两行from langchain_community.embeddings import HuggingFaceEmbeddings embeddings HuggingFaceEmbeddings( model_nameBAAI/bge-large-zh-v1.5, encode_kwargs{normalize_embeddings: True}, )注意normalize_embeddingsTrue这个参数表示对向量做归一化。加了归一化之后向量内积等价于余弦相似度计算更快而且方便设置统一的相似度阈值。bge 系列的官方建议是查询侧加上“为这个句子生成表示以用于检索相关文章”这样的指令前缀但 LangChain 的封装默认不处理这个细节追求极致效果需要自己写 query 的预处理。这块属于进阶优化面试能提到就是加分项。embedding 模型的维度也要留意text-embedding-3-small 是 1536 维bge-large-zh-v1.5 是 1024 维。换 embedding 模型时向量库里旧数据的维度和新数据不一致会导致检索报错或效果归零。唯一的后悔药是重建索引没有捷径。所以生产项目第一次选 embedding 时要慎重后期切换代价很高。4.2 切分参数调优chunk_size、overlap 与检索精度的三角关系chunk_size 是 RAG 里最玄学也最影响效果的参数。设太小一个问题需要的完整信息被切到多个块里top-k 检索只能召回其中一部分模型看到的信息残缺设太大一个块里塞满无关内容向量表示被稀释相似度计算失准而且塞进提示词的 token 消耗剧增。500 到 800 是多数通用文档的安全区但代码、表格、合同这类结构化文本需要单独处理。chunk_overlap 的作用是缝合切分造成的语义断裂。一段话恰好被从中间切开时后半块缺少主语检索到它模型也读不懂。overlap 保留前一块末尾的一部分内容作为“记忆”能显著缓解这个问题。建议 chunk_size 的 10% 到 20%。以下是针对不同文档类型的经验配置我一般这样设定文档类型chunk_sizechunk_overlap说明规章制度、百科类800120段落较长语义完整优先技术文档、FAQ500100问答对短切忌切碎代码仓库30050按函数切保留上下文合同、法律条文600150条款引用紧密overlap 加大调整切分参数后必须回头验证检索效果不能只看生成答案顺不顺眼。常见做法是把几个典型问题拿出来打印检索到的块内容人工判断相关块是否被正确召回。这一步是 RAG 调试的地基后面第 5 章的排查技巧都建立在这个习惯上。4.3 top-k 与相似度阈值召回数量与精度的平衡top-k 决定给模型几个候选块。k 太小容易漏k 太大容易让模型被不相关上下文带偏。起步用 4文档内容复杂时可以试 6 到 8。另一个被忽略的参数是相似度阈值。Chroma 的默认检索不做拒绝哪怕相似度只有 0.3 的块也会被返回模型只能硬着头皮用这些垃圾上下文作答。加上阈值过滤是提升准确率最简单有效的手段retriever vectorstore.as_retriever( search_typesimilarity_score_threshold, search_kwargs{score_threshold: 0.5, k: 4}, )score_threshold的取值跟 embedding 模型强相关OpenAI 的 embedding 输出相似度普遍偏高0.5 以下基本是无关内容bge 系列归一化之后0.4 到 0.6 之间需要实测确定。确定方法不复杂拿 20 个真实问题跑一遍检索打印每块的相似度分数看相关答案的分数区间落在哪取一个能覆盖大部分正样本又不放太多负样本的临界值。这是血泪经验别指望有一个万能阈值。注意search_type切换后返回的仍然是 Document 列表但similarity_score_threshold模式下不满足阈值的块会被直接丢弃这是它能滤噪的原因。如果你的 LangChain 版本比较旧这个 search_type 可能不支持升级到 0.2 以上即可。4.4 提示词约束与无答案兜底防止模型自由发挥的最后一道闸最后一道质量闸门是提示词。模型天生倾向给出“像答案”的回答就算检索结果里没有相关信息它也会用预训练知识硬凑。必须显式告诉它只能依据上下文作答上下文没有答案就承认不知道。上一章的 system prompt 已经写了这个约束这里补充两个进阶写法prompt ChatPromptTemplate.from_messages([ (system, 你是知识库问答助手。严格遵循以下规则\n 1. 只能使用提供的上下文作答禁止使用预训练知识补全\n 2. 如果上下文与问题无关或信息不足回复知识库中未找到相关内容\n 3. 回答时标注信息来自哪个文档分块格式来源文档名。), (human, 上下文\n{context}\n\n问题{question}), ])“标注来源”这一条强烈建议加上。它有两个作用对内方便人工核验检索质量对外让使用者能追溯答案出处。面试时被问到“怎么减少幻觉”把这条规则和前面的相似度阈值过滤一起答就是完整的工程化方案。提示词里的约束只能管住模型的行为倾向管不住检索结果本身的质量所以顺序是先调检索再调生成别指望提示词补检索的洞。5. RAG 实战避坑现象、原因、解法五条高频踩坑记录5.1 检索不到相关内容查了切分和向量化才发现是 embedding 没对齐现象问知识库里明明有的内容答案却是“未找到”。排查时先手工调 retriever 打印召回结果发现相关性最高的块完全不匹配甚至向量库里的文本是乱码。原因有两种。第一种是 embedding 模型前后不一致索引时用了 text-embedding-3-small检索时换成了 bge维度不同导致检索结果完全错乱。第二种是切分对象不对TextLoader 读出的是原始文本但某些 PDF 加载后输出的是带换行符的碎片文本RecursiveCharacterTextSplitter 会把每个碎片切成独立块语义全碎。解决统一训练和检索时的 embedding 模型没有充分理由不要中途更换。PDF 加载后用print(documents[0].page_content[:500])检查文本质量换用 PyPDFLoader 或 PDFPlumberLoader 对比效果必要时先做文本清洗再切分。这个检查动作应该写进每次索引构建的标准流程。5.2 切分参数导致答案残缺chunk_size 过小的典型症状现象答案只覆盖了问题的前半部分后半部分内容缺失。比如问“年假天数与加班调休规则”模型只回答了年假没回答调休。看起来像模型理解问题实际是检索阶段就漏了。原因相关知识分散在两个 chunk 里chunk_size300 把一段完整制度说明切成了两块top-k4 召回了前两块却漏了包含调休规则的那块。最典型的场景是表格转文本后一行一个 chunk语义被物理截断。解决先打印检索召回的所有块确认缺失内容是否在库中再决定调参方向。若是切片过碎调大 chunk_size 或增加 top-k若是内容正好被切在关键句上加大 overlap。务必记录修改前后的参数组合RAG 调参翻车太常见检索打印是唯一的定位手段。5.3 相似度计算与中文场景的偏差标点、停用词影响召回现象检索时返回的块看起来“沾边但不准”相似度分数普遍偏低或偏高。中文文档里“的、了、吗”这类词对向量贡献大实际语义词却被稀释。原因中文 embedding 对短文本的区分度有限加上停用词没有被过滤。Chroma 内置的检索不做分词整句向量化时高频词会拉高相似度。这是 RAG 检索的黑匣子很难从分数层面直接定位。解决常见做法是在切分后、向量化前做清洗去掉多余空白和特殊符号对 QA 型知识库把问题和答案分开切分检索时只匹配问题块。如果相似度普遍虚高试试 bge 系列的query_instruction前缀官方文档说明这能显著改善短文本检索。实在解决不了就上重排序rerank效果立竿见影但多一层开销。5.4 多轮对话的上下文污染历史记录被检索器当成知识现象连续对话几轮后答案逐渐偏离知识库开始“引用”前面对话里的内容。排查发现检索器把聊天历史也喂给了向量库。原因常见的错误实现是把整段对话历史作为上下文片段传入 prompt没有区分“对话背景”和“知识库内容”。模型面对混合内容时倾向于相信最近出现的文本历史对话里的错误信息就混进了答案。解决对话历史和知识库检索结果分别传入 prompt用 system 消息明确告知“只有标记为上下文的内容才代表知识库”。历史记录只作为背景不参与向量检索。如果确实需要基于历史追问也要先对历史做过滤、只保留最近一轮避免旧信息干扰。5.5 提示词写得太宽松模型开始自由发挥的边界问题现象prompt 里只写了“请根据上下文回答”模型答得天花乱坠甚至出现知识库里根本不存在的数据。原因约束不足。LLM 优化目标是“生成像样的文本”而不是“严格遵循事实”。没有在上下文中找不到答案时如何处理的指令模型宁可编造也不会说不知道。提示词就是给模型划边界边界的清晰程度直接决定幻觉率。解决第 4 章的兜底规则必须写进 system prompt至少包含三条只依据上下文作答、无答案时明确说不知道、不输出额外解释。在测试集上做对照实验把有约束和无约束的回答并排对比你会直观看到边界的重要性。这个现象跟大模型微调的“灾难性遗忘”不同它纯粹是推理期约束缺失改提示词就能复位。6. 从能回答到能答辩加一个可验证的评估环节做过以上调优之后项目已经具备“能跑”的水平。但如果面试官追问“你怎么证明你的 RAG 效果好”光靠几个样例回答没有说服力。这里分享一个我常用的评估脚本思路准备一组标注好的 QA 测试对跑批量检索用命中率评估检索质量再用对比实验证明调整有效。流程不复杂准备 20 到 30 条测试问题每个问题手工标注出它在知识库里对应的 chunk 编号批量执行检索和问答统计检索命中率和问答正确率改参数后重新跑一遍记录指标变化。评估中最值得做的是“检索命中率”它不受 LLM 生成质量影响直接反映索引和检索链路的好坏。命中率低后续生成再完美都是空中楼阁。脚本本身用 LangChain 的批量调用就能实现核心是保存每个问题对应的正确答案跑完后用脚本比对。这个习惯是我做 RAG 项目以来最受用的一条所有质量讨论都建立在数字上而不是感觉上。希望这些参数和避坑记录能帮你在面试中把项目讲扎实也能让实际知识库问答少走几段弯路。本文还有配套的精品资源点击获取