RAG 效果差先别急着换模型90% 的问题出在检索层获取方式完整的项目课程、配套代码与文档资料我整理在 资源获取上线了一个基于大模型的知识库问答测试时用户问退货政策是几天内可以退模型洋洋洒洒答了一段——里面有三条公司根本不存在的条款。排查了一下午最后发现问题不在模型在检索召回的四段内容里两段来自员工手册的团建章节。如果你也遇到过类似情况——答案看着合理但事实是错的、换更大的模型也没改善——那本文就是为你写的。读完你能拿到一套可运行的 Naive RAG 实现、三个把检索质量拉起来的优化手段以及一份按阶段划分的学习路径。一、先想清楚为什么是 RAG不是微调这是第一个容易走错的路口。很多团队的第一反应是数据不够就让模型学于是去搞微调。但微调解决的是风格和格式问题不是事实知识问题。方案适合场景主要代价提示词工程规则简单、上下文短上下文长度受限RAG 检索增强知识频繁更新、要求可溯源需要维护检索链路微调 Fine-tuning固定风格、固定输出格式知识更新要重新训练我整理的那套课程里有一节专门讲微调 和 RAG 方案选型结论很直白知识库类需求优先 RAG。因为企业文档每天都在变微调一次的成本和周期都扛不住。二、Naive RAG最小可运行版本先别急着上花活把最小闭环跑通。整套流程只有四步加载 → 切分 → 向量化入库 → 检索生成。fromlangchain_community.document_loadersimportPyPDFLoaderfromlangchain_text_splittersimportRecursiveCharacterTextSplitterfromlangchain_openaiimportOpenAIEmbeddings,ChatOpenAIfromlangchain_community.vectorstoresimportChromafromlangchain_core.promptsimportChatPromptTemplatefromlangchain_core.output_parsersimportStrOutputParserfromlangchain_core.runnablesimportRunnablePassthrough# 1. 加载把 PDF 读成一页一页的文本pagesPyPDFLoader(./docs/handbook.pdf).load()# 2. 切分长文档必须切块否则检索精度会崩splitterRecursiveCharacterTextSplitter(chunk_size500,# 每块约 500 字chunk_overlap80,# 相邻块留 80 字重叠避免语义被硬切断separators[\n\n,\n,。,,, ,],)chunkssplitter.split_documents(pages)# 3. 向量化 入库vectorstoreChroma.from_documents(documentschunks,embeddingOpenAIEmbeddings(modeltext-embedding-3-small),persist_directory./chroma_db,)retrievervectorstore.as_retriever(search_kwargs{k:4})# 4. 组装链路promptChatPromptTemplate.from_template(仅根据以下资料回答资料中没有的内容直接回答「不知道」\n\n{context}\n\n问题{question})llmChatOpenAI(modelgpt-4o-mini,temperature0)rag_chain({context:retriever,question:RunnablePassthrough()}|prompt|llm|StrOutputParser())print(rag_chain.invoke(退货政策是怎样的))几个参数直接决定效果别照抄默认值chunk_size中文场景300–600 字比较稳。太大导致噪声污染太小导致语义碎片化。chunk_overlap一般取 chunk_size 的10%–20%。separators一定要把中文标点加进去否则切分器会按英文句号硬切把中文句子拦腰截断。temperature0知识问答要的是稳定复现不是创造力。踩坑提示如果你发现回答经常差一点先打印retriever.invoke(question)看召回内容而不是急着换模型。九成的问题在召回内容里就已经暴露了。三、Advanced RAG把检索层的三个漏点补上Naive RAG 的三大典型失败模式口语化提问检索不到—— 用户问东西坏了能退不而文档里写的是商品质量问题的退换货流程。向量相似 ≠ 真正相关—— 向量检索是粗排容易召回过内容语义相近但答非所问的片段。多跳问题答不上来—— 需要串联两三条信息才能回答的问题单次检索覆盖不到。对应三个优化手段# 优化一查询改写 —— 把一句口语化提问扩写成多个检索友好的表述fromlangchain.retrievers.multi_queryimportMultiQueryRetriever multi_retrieverMultiQueryRetriever.from_llm(retrieverretriever,llmllm)# 优化二重排序 —— 先粗排多召回再用 Cross-Encoder 精排出最相关的几条fromlangchain.retrieversimportContextualCompressionRetrieverfromlangchain.retrievers.document_compressorsimportCrossEncoderRerankerfromlangchain_community.cross_encodersimportHuggingFaceCrossEncoder rerankerCrossEncoderReranker(modelHuggingFaceCrossEncoder(model_nameBAAI/bge-reranker-base),top_n4,)compression_retrieverContextualCompressionRetriever(base_compressorreranker,base_retrievermulti_retriever,# 改写 重排叠加使用)先多召回再精排是性价比最高的一个改动。把k从 4 提到 20再用重排序取回前 4 条实测准确率提升往往比换更大的生成模型明显而成本几乎不变重排序模型很小可以本地跑。踩坑提示重排序模型bge-reranker第一次加载会下载几百 MB 权重如果部署在容器里记得把模型目录挂载出来否则每次重启都要重新下载。四、让 RAG 会用工具Agent 的分工当问题需要多种能力组合时比如帮我查一下退货政策再算算我这单还能退多少钱单纯检索就不够了需要 Agent 来做调度判断该检索、该调接口、还是该直接回答。fromlangchain.agentsimportAgentExecutor,create_react_agentfromlangchain_core.toolsimporttooltooldefsearch_handbook(query:str)-str:在公司制度文档中检索相关条款。docsretriever.invoke(query)return\n\n.join(d.page_contentfordindocs)tooldefcalc_refund(order_id:str)-str:根据订单号查询可退款金额。# 这里换成你自己的业务接口returnf订单{order_id}可退金额128.00 元agentcreate_react_agent(llm,[search_handbook,calc_refund],prompt)executorAgentExecutor(agentagent,tools[search_handbook,calc_refund],verboseTrue)分界线很简单RAG 负责知道Agent 负责决定做什么。两者不是替代关系是配合关系——课程里Agents 之 LangChain 提供的 ReAct Agent 抽象那几节讲的就是这条边界怎么划。五、私有化部署数据不能出内网怎么办企业场景下最常见的一票否决项。用 Ollama 拉一个开源模型几行命令就能把链路改成完全本地# 拉取并启动本地模型以通义千问 7B 为例ollama pull qwen2.5:7b ollama servefromlangchain_community.llmsimportOllama# 只改这一行其余链路完全不用动llm_localOllama(modelqwen2.5:7b,temperature0)因为 LangChain 的链路是通过 Runnable 组合的生成模型是可以随时替换的组件这也是它相比裸写 API 调用最大的工程价值。六、配套资源清单上面这套路径对应的完整课程是《2025西瓜AI大模型RAG项目实战课》共158 节模块划分如下按课程真实章节顺序RAG 原理层RAG 流程详细剖析、大模型应用落地痛点剖析、RAG 关键问题剖析、RAG 架构演进之 Naive RAG / Advanced RAG、微调和 RAG 方案选型、RAG 的应用落地场景LangChain 架构层总体架构剖析、RAG 架构支持、Agent 架构支持、核心 API 设计剖析Model IO模型调用实践、Promptsstr.format/ Few-Shot / ExampleSelector、Output Parser、外部函数调用全流程、Ollama 私有模型部署Chains设计理念、LCEC 构建、SimpleSequentialChain / SequentialChain / RouterChain、全链路函数调用跑通Memory为什么需要 Memory、自定义 Memory、实体识别 Memory、ConversationBuffer / Window / Summary 等内置模块AgentsAgent 架构意义、自定义 Agent、ReAct Agent 抽象、XML Agent 抽象RetrievalLoader、Transformers、Embedding Model、Vector Store、Retrievers 全链路按这个顺序学基本就是一条从原理到工程落地的完整路径比我东一榔头西一棒子地搜博客高效得多。七、三条避坑建议不要跳过 Retrieval 章节直接写业务。我见过太多人卡在回答不准其实问题全在切分和召回策略上。不要一上来就追求 Advanced RAG。先把 Naive RAG 跑通、把召回内容打印出来看明白再逐项加优化否则你不知道是哪个改动起了作用。不要迷信更大的模型。检索层没做好的情况下把 7B 换成 70B效果提升通常远小于你的预期但成本是实打实的。本文为原创内容转载请注明出处。 RAG 效果差？先别急着换模型，90% 的问题出在检索层
RAG 效果差先别急着换模型90% 的问题出在检索层获取方式完整的项目课程、配套代码与文档资料我整理在 资源获取上线了一个基于大模型的知识库问答测试时用户问退货政策是几天内可以退模型洋洋洒洒答了一段——里面有三条公司根本不存在的条款。排查了一下午最后发现问题不在模型在检索召回的四段内容里两段来自员工手册的团建章节。如果你也遇到过类似情况——答案看着合理但事实是错的、换更大的模型也没改善——那本文就是为你写的。读完你能拿到一套可运行的 Naive RAG 实现、三个把检索质量拉起来的优化手段以及一份按阶段划分的学习路径。一、先想清楚为什么是 RAG不是微调这是第一个容易走错的路口。很多团队的第一反应是数据不够就让模型学于是去搞微调。但微调解决的是风格和格式问题不是事实知识问题。方案适合场景主要代价提示词工程规则简单、上下文短上下文长度受限RAG 检索增强知识频繁更新、要求可溯源需要维护检索链路微调 Fine-tuning固定风格、固定输出格式知识更新要重新训练我整理的那套课程里有一节专门讲微调 和 RAG 方案选型结论很直白知识库类需求优先 RAG。因为企业文档每天都在变微调一次的成本和周期都扛不住。二、Naive RAG最小可运行版本先别急着上花活把最小闭环跑通。整套流程只有四步加载 → 切分 → 向量化入库 → 检索生成。fromlangchain_community.document_loadersimportPyPDFLoaderfromlangchain_text_splittersimportRecursiveCharacterTextSplitterfromlangchain_openaiimportOpenAIEmbeddings,ChatOpenAIfromlangchain_community.vectorstoresimportChromafromlangchain_core.promptsimportChatPromptTemplatefromlangchain_core.output_parsersimportStrOutputParserfromlangchain_core.runnablesimportRunnablePassthrough# 1. 加载把 PDF 读成一页一页的文本pagesPyPDFLoader(./docs/handbook.pdf).load()# 2. 切分长文档必须切块否则检索精度会崩splitterRecursiveCharacterTextSplitter(chunk_size500,# 每块约 500 字chunk_overlap80,# 相邻块留 80 字重叠避免语义被硬切断separators[\n\n,\n,。,,, ,],)chunkssplitter.split_documents(pages)# 3. 向量化 入库vectorstoreChroma.from_documents(documentschunks,embeddingOpenAIEmbeddings(modeltext-embedding-3-small),persist_directory./chroma_db,)retrievervectorstore.as_retriever(search_kwargs{k:4})# 4. 组装链路promptChatPromptTemplate.from_template(仅根据以下资料回答资料中没有的内容直接回答「不知道」\n\n{context}\n\n问题{question})llmChatOpenAI(modelgpt-4o-mini,temperature0)rag_chain({context:retriever,question:RunnablePassthrough()}|prompt|llm|StrOutputParser())print(rag_chain.invoke(退货政策是怎样的))几个参数直接决定效果别照抄默认值chunk_size中文场景300–600 字比较稳。太大导致噪声污染太小导致语义碎片化。chunk_overlap一般取 chunk_size 的10%–20%。separators一定要把中文标点加进去否则切分器会按英文句号硬切把中文句子拦腰截断。temperature0知识问答要的是稳定复现不是创造力。踩坑提示如果你发现回答经常差一点先打印retriever.invoke(question)看召回内容而不是急着换模型。九成的问题在召回内容里就已经暴露了。三、Advanced RAG把检索层的三个漏点补上Naive RAG 的三大典型失败模式口语化提问检索不到—— 用户问东西坏了能退不而文档里写的是商品质量问题的退换货流程。向量相似 ≠ 真正相关—— 向量检索是粗排容易召回过内容语义相近但答非所问的片段。多跳问题答不上来—— 需要串联两三条信息才能回答的问题单次检索覆盖不到。对应三个优化手段# 优化一查询改写 —— 把一句口语化提问扩写成多个检索友好的表述fromlangchain.retrievers.multi_queryimportMultiQueryRetriever multi_retrieverMultiQueryRetriever.from_llm(retrieverretriever,llmllm)# 优化二重排序 —— 先粗排多召回再用 Cross-Encoder 精排出最相关的几条fromlangchain.retrieversimportContextualCompressionRetrieverfromlangchain.retrievers.document_compressorsimportCrossEncoderRerankerfromlangchain_community.cross_encodersimportHuggingFaceCrossEncoder rerankerCrossEncoderReranker(modelHuggingFaceCrossEncoder(model_nameBAAI/bge-reranker-base),top_n4,)compression_retrieverContextualCompressionRetriever(base_compressorreranker,base_retrievermulti_retriever,# 改写 重排叠加使用)先多召回再精排是性价比最高的一个改动。把k从 4 提到 20再用重排序取回前 4 条实测准确率提升往往比换更大的生成模型明显而成本几乎不变重排序模型很小可以本地跑。踩坑提示重排序模型bge-reranker第一次加载会下载几百 MB 权重如果部署在容器里记得把模型目录挂载出来否则每次重启都要重新下载。四、让 RAG 会用工具Agent 的分工当问题需要多种能力组合时比如帮我查一下退货政策再算算我这单还能退多少钱单纯检索就不够了需要 Agent 来做调度判断该检索、该调接口、还是该直接回答。fromlangchain.agentsimportAgentExecutor,create_react_agentfromlangchain_core.toolsimporttooltooldefsearch_handbook(query:str)-str:在公司制度文档中检索相关条款。docsretriever.invoke(query)return\n\n.join(d.page_contentfordindocs)tooldefcalc_refund(order_id:str)-str:根据订单号查询可退款金额。# 这里换成你自己的业务接口returnf订单{order_id}可退金额128.00 元agentcreate_react_agent(llm,[search_handbook,calc_refund],prompt)executorAgentExecutor(agentagent,tools[search_handbook,calc_refund],verboseTrue)分界线很简单RAG 负责知道Agent 负责决定做什么。两者不是替代关系是配合关系——课程里Agents 之 LangChain 提供的 ReAct Agent 抽象那几节讲的就是这条边界怎么划。五、私有化部署数据不能出内网怎么办企业场景下最常见的一票否决项。用 Ollama 拉一个开源模型几行命令就能把链路改成完全本地# 拉取并启动本地模型以通义千问 7B 为例ollama pull qwen2.5:7b ollama servefromlangchain_community.llmsimportOllama# 只改这一行其余链路完全不用动llm_localOllama(modelqwen2.5:7b,temperature0)因为 LangChain 的链路是通过 Runnable 组合的生成模型是可以随时替换的组件这也是它相比裸写 API 调用最大的工程价值。六、配套资源清单上面这套路径对应的完整课程是《2025西瓜AI大模型RAG项目实战课》共158 节模块划分如下按课程真实章节顺序RAG 原理层RAG 流程详细剖析、大模型应用落地痛点剖析、RAG 关键问题剖析、RAG 架构演进之 Naive RAG / Advanced RAG、微调和 RAG 方案选型、RAG 的应用落地场景LangChain 架构层总体架构剖析、RAG 架构支持、Agent 架构支持、核心 API 设计剖析Model IO模型调用实践、Promptsstr.format/ Few-Shot / ExampleSelector、Output Parser、外部函数调用全流程、Ollama 私有模型部署Chains设计理念、LCEC 构建、SimpleSequentialChain / SequentialChain / RouterChain、全链路函数调用跑通Memory为什么需要 Memory、自定义 Memory、实体识别 Memory、ConversationBuffer / Window / Summary 等内置模块AgentsAgent 架构意义、自定义 Agent、ReAct Agent 抽象、XML Agent 抽象RetrievalLoader、Transformers、Embedding Model、Vector Store、Retrievers 全链路按这个顺序学基本就是一条从原理到工程落地的完整路径比我东一榔头西一棒子地搜博客高效得多。七、三条避坑建议不要跳过 Retrieval 章节直接写业务。我见过太多人卡在回答不准其实问题全在切分和召回策略上。不要一上来就追求 Advanced RAG。先把 Naive RAG 跑通、把召回内容打印出来看明白再逐项加优化否则你不知道是哪个改动起了作用。不要迷信更大的模型。检索层没做好的情况下把 7B 换成 70B效果提升通常远小于你的预期但成本是实打实的。本文为原创内容转载请注明出处。