1. 先想清楚：RAG到底哪里容易出问题
做了几轮RAG项目之后，我最大的感受是：RAG的门槛不在“搭起来”，而在“调好”。用LangChain或LlamaIndex把索引、检索、生成三条流程串起来，一个下午就能跑通demo。但一放到真实业务场景里，用户问出来的问题千奇百怪，知识库文档格式五花八门，模型回答时而精准时而离谱——这时候你才会真正意识到，RAG是一座冰山，水面上是“输入问题→检索→拼接提示词→生成回答”的简单流程，水面下是切片策略、嵌入模型选型、召回质量、上下文窗口管理、提示词约束、数据清洗、评测体系这一整串工程问题。
结合我这几年做的RAG项目，以及最近社区里讨论热度很高的几个方向（RAG知识库、Agentic RAG、基于ollama的本地知识库、LangChain4j Easy RAG等），我整理出了RAG项目里最常踩的5个问题，每一个都附上可复现的解决办法。这些问题基本覆盖了从数据接入、检索、生成到本地部署的全部链路，适合正在做RAG实战、或者想把手头文档库变成可问答知识库的团队参考。
在展开之前，先给一个统一语境。下面所有讨论，都默认你用的是最经典的RAG流程：文档加载（Loader）→文本切片（Splitter）→向量化（Embedding）→向量库存储（Vector Store）→检索召回（Retriever）→增强生成（LLM）。这5个问题分别出在流程的不同环节，即使你已经用了Agentic RAG或者GraphRAG这类变体，底层逻辑依然成立。
2. 问题一：检索结果不相关——根源多半在“切”和“嵌”
2.1 第一个误区：不分青红皂白按固定字数切片
我见过太多RAG项目，第一步就栽在切片上。很多教程默认“chunk_size=500, overlap=50”，然后就完事了。这么做的结果是：用户问“服务器部署需要什么配置”，检索回来的片段可能是一大段接口文档，真正讲硬件配置的句子被切碎散落在三个chunk里，每个chunk都不完整，大模型怎么拼都拼不出正确答案。
切片的核心矛盾是“语义完整性”和“上下文连贯性”的平衡。固定字数切片最大的问题，是它完全不理解文档结构。一个PDF里的一行表格数据、一个标题下的导语、一段代码块的注释，都可能因为字数限制被拦腰截断。
我现在的做法是优先考虑基于结构的切片：
- 按标题层级（Markdown的#、##、###，或PDF的目录结构）切分，每个一级标题下的内容作为一个候选块，再根据最大长度限制二次切分。
- 按语义段落切分，尽量不破坏一个完整观点。
- 对于超长段落，用overlap做上下文衔接，overlap建议在10%~15%之间，太小会丢上下文，太大则重复内容挤占向量表达空间。
以LangChain为例，优先用MarkdownHeaderTextSplitter，它能把Markdown文档按标题结构切成块，而不是无脑按字符数切。
from langchain.text_splitter import MarkdownHeaderTextSplitter headers_to_split_on = [ ("#", "一级标题"), ("##", "二级标题"), ("###", "三级标题"), ] splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers_to_split_on) chunks = splitter.split_text(markdown_document)对于PDF里的表格和扫描件，我通常先把非文本内容用OCR识别、然后转成结构化文本再进入切片，直接对扫描件做固定字数切分，基本等于让RAG瞎猜。
2.2 第二个误区：embedding模型没选对
切完片，下一步是向量化。这里有个高频问题：中文场景还在用面向英文优化的通用Embedding模型，检索效果自然惨淡。英文效果好不代表中文效果好，中文的字词粒度、简繁、多义性，都需要模型在中文语料上专门训练过。
我一般按这个逻辑选择Embedding模型：
| 场景 | 推荐方向 | 说明 |
|---|---|---|
| 中文通用知识库 | bge系列、m3e系列 | 对中文支持好，社区生态成熟 |
| 英文为主 | OpenAI text-embedding或开源英文模型 | 英文语义理解更稳 |
| 代码/技术文档 | 带代码语义的模型或文本+代码联合模型 | 普通模型对代码理解偏弱 |
| 本地离线部署 | 基于ollama运行的嵌入模型 | 省资源，数据不出内网 |
选模型不是越大越好，还要看向量维度与检索速度的平衡。我用过不少本地部署方案，ollama拉起一个嵌入模型非常方便，像bge-m3就可以直接在ollama里跑，零基础也能完成本地RAG的第一步。
2.3 救命的“混合检索”和“重排”
如果切片和嵌入都调优了，检索结果还是不准，那就是纯向量检索的天花板问题。向量检索擅长“语义相似”，但有时用户输入的是精确关键词（比如一个型号、一个工单号），向量召回反而会被无关语义干扰。
这时候要上混合检索：向量召回 + 关键词召回（BM25）并行，再用一个重排序模型（Reranker）把两路结果融合排序。你可以自己实现一个简单加权合并，也可以直接用FlagEmbedding里的Reranker模型，或者LangChain里的EnsembleRetriever。
from langchain.retrievers import EnsembleRetriever from langchain_community.retrievers import BM25Retriever from langchain_community.vectorstores import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings bm25_retriever = BM25Retriever.from_texts(chunks) bm25_retriever.k = 4 vectorstore = Chroma.from_texts(chunks, HuggingFaceEmbeddings(model_name="BAAI/bge-m3")) vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 4}) ensemble_retriever = EnsembleRetriever( retrievers=[bm25_retriever, vector_retriever], weights=[0.3, 0.7] )实测下来，混合检索+重排这个组合，能把“精确词命中但语义偏离”的场景拉回正轨。比如用户查“RAG-1234工单处理状态”，关键词命中工单号，语义向量命中“工单处理流程”，混合后重排，正确的那个片段大概率会排在前面。
3. 问题二：检索到了，答案却还是错——生成环节的“幻觉”治理
3.1 RAG不是“把检索结果丢给大模型”就完了
很多人以为RAG防幻觉是自动的——检索到了正确文档，模型就会基于文档回答。大错特错。只要提示词里没有明确约束，大模型就会“自由发挥”。检索到的内容只占了提示词的一部分，模型完全可能忽略它们，或者只看了第一段就开始编。
我在一个医疗问答项目里踩过这个大坑：检索结果明明包含了“该药不适用于肝功能不全患者”，模型却回答“肝功能不全患者可正常服用”，因为用户问的是“肝功能不好的病人能吃吗”，模型在对话习惯的驱动下直接给了一个模糊的“可以”。
3.2 提示词工程：把模型的嘴焊在上下文上
治理这类问题，第一道防线是提示词。实践中最有效的约束包括：
- 明确要求“只能根据提供的上下文回答，不要使用先验知识”。
- 要求“如果上下文中没有相关信息，请直接回答不知道，不要编造”。
- 要求引用来源片段，或输出对应的文档编号。
我把一套可复用的RAG提示词模板写成了英文，因为实测英文提示词对主流模型的约束效果更稳定：
You are a strict Q&A assistant. You must answer ONLY based on the following context. If the context does not contain the answer, respond with "I don't have enough information to answer." Do not use your prior knowledge. Do not make up facts. Cite the source passage number for each key statement. Context: {context} Question: {question}注意“Do not use your prior knowledge”这句话。加了和没加，幻觉率差别很大。原因在于，大模型的生成本质是概率采样，如果先验知识和上下文冲突，模型倾向于相信“自己记得的答案”。你必须把这个倾向强制压下去。
3.3 上下文窗口管理：塞太多反而更笨
第二个生成环节的常见坑是上下文超长导致的注意力稀释。很多RAG框架默认取top_k=4或5，每段500字，再加系统提示词和历史对话，一次可能塞进5000~8000字。如果知识库文档本身又长，一个chunk里混着多个主题，模型会分不清主次。
我的经验是：不是上下文里检索内容越多越好，而是越精准越好。对生成质量来说，两段高度相关的内容远好过五段勉强相关的内容。控制top_k在3~5之间，同时让每个chunk尽量保持主题单一，是性价比最高的处理方式。
还要注意历史对话对上下文窗口的挤压。多轮对话场景中，如果不做历史消息裁剪，对话占用的token会越来越长，检索内容反而被挤出去。简单做法是只保留最近两轮对话，或者把历史对话做一次总结压缩再拼接。
3.4 给答案装上“引文”，追责才追得到
最后，一定要给模型生成的回答配上来源引用。这个看似是“附加功能”，其实对定位问题至关重要。如果模型回答错了，你还能快速翻出它引用的原文，判断到底是检索错了还是模型编了。用LangChain的话，可以在RetrievalQA里注入return_source_documents=True，然后在输出里把对应的chunk编号一并打印出来。
4. 问题三：知识库更新难、入库质量差——数据工程才是重头戏
4.1 入库管道的三个常见翻车点
RAG项目里，很多时候问题不是出在检索和生成，而是知识库本身就没建好。我总结了入库环节的三个高频翻车点：
- 格式解析失败：PDF表格变成乱码，图片型PDF全部丢失内容，Word里嵌套的文本框读不出来。
- 冗余和冲突：同一个知识点在多个文档里以不同版本存在，RAG可能检索到过时版本，导致答案前后矛盾。
- 切片时把关联内容拆散：比如“系统参数表”和“参数说明”分别在不同章节，按结构切分后，检索参数名能召回参数表，却召不回说明文字。
4.2 表格和扫描件：谁处理谁受益
针对格式问题，说实话，没有万能解析器。我的做法是分情况处理：
- 文本型PDF：用
PyMuPDF或pdfplumber提取文本，保留页码和标题结构。 - 扫描型PDF：先OCR（推荐PaddleOCR），再进文本解析管线。
- 表格：优先考虑转成Markdown表格或JSON，而不是纯文本拼接。这样可以保留表格的语义结构，后续检索“某个字段的值”会准确很多。
- Word文档：不直接当纯文本读，优先解析标题层级，方便结构化切片。
4.3 一个提升召回准确率的小技巧：QA问答对构建
纯文本切片是给“RAG系统”喂饭，而QA问答对是给“RAG系统”喂考试重点。如果你手里有FAQ、客服手册、操作指南，把这些内容拆成“问题-答案”的结构化问答对入库，效果通常远好于整体切片。
原因是用户提问时，问题本身就是“问句形态”，如果你库里存的也是“问句-答句”对，检索匹配的语义空间几乎一致，匹配率会显著提高。
以ollama本地RAG为例，零基础也能做到：先把FAQ文档拆成一问一答的条目，然后用嵌入模型把问句向量化存入向量库，检索时用户问题去匹配FAQ问句，命中后直接把标准答案返回给大模型做润色。这个方案在许多实际知识库项目中，比RAG原始流程（语义检索长文本）的准确率高出一大截。
5. 问题四：复杂业务问题答得稀烂——从RAG升级到Agentic RAG
5.1 单次检索解决不了“多跳问题”
当用户问“上个月A类工单的平均处理时长是多少？和B类工单比谁更快？”这种问题，经典RAG流程会直接卡壳。因为它需要先检索出“A类工单的处理时长数据表”，再检索“B类工单处理时长”，还要做比较。单次向量检索，在第一步就可能因为关键词分散而召回不全，更别提后续的计算与对比了。
这类多跳（Multi-hop）问题，恰恰是最近社区里很火的Agentic RAG要解决的。
5.2 Agentic RAG的核心思路：从“一次检索”到“自主规划检索”
Agentic RAG不是新的算法，它是在RAG外面包了一层Agent控制器。大致流程是：
- 用户问题进来，先由Agent判断：这个问题是一次能回答，还是需要拆分？
- 如果需要拆分，就规划子问题，比如上面的工单对比问题，拆成“A类工单平均处理时长”“B类工单平均处理时长”“对比结论”。
- 每个子问题分别走“检索→生成”流程，得到子答案。
- 再汇总所有子答案，生成最终回答。
这种方式，能让RAG处理“复杂查询”“跨文档关联查询”“需要计算推理的查询”。不过它也会牺牲一些响应速度和多一次模型调用的成本，所以要结合场景取舍——不是所有RAG都要Agentic化。
5.3 落地时怎么选：经典RAG还是Agentic RAG
我自己在项目里的选择标准是：
- 单纯的知识库问答（“XX产品的安装步骤是什么”）：经典RAG足够，别上Agent，慢且不稳定。
- 跨文档对比、多条件筛选、需要推理的QA：上Agentic RAG，收益远大于成本。
- 对话式知识库（结合历史上下文、连续追问）：至少要做Query改写，这是Agentic RAG的雏形。
5.4 轻量级Query改写：Agentic RAG的入门替代
其实不需要一步到位Agentic RAG。一个轻量级的Query改写模块就能解决不少痛处。经典RAG里，如果用户连续追问模糊问题，比如先问“服务器宕机怎么排查”，再问“那内存泄露呢？”，第二次检索如果还用原句，向量检索很难命中“内存泄露排查”相关文档；但如果把两轮对话拼接成完整Query，检索效果就完全不一样。
from langchain.prompts import PromptTemplate from langchain.llms import Ollama from langchain.chains import LLMChain rewrite_prompt = PromptTemplate.from_template( "请把用户的问句改写成包含历史上下文的自包含问题。\n" "历史对话：{chat_history}\n" "当前问题：{question}\n" "改写后的独立问题：" ) llm = Ollama(model="qwen2.5") chain = LLMChain(llm=llm, prompt=rewrite_prompt) query = chain.invoke({ "chat_history": "用户问：服务器宕机怎么排查？", "question": "那内存泄露呢？" })实测下来，这个30行不到的改造，能让模糊追问的召回准确率提升一大截。
6. 问题五：本地部署翻车——工具链与环境的坑
6.1 零基础本地RAG最容易踩的技术栈坑
最近很多同学都在搭“ollama + 本地知识库”，榜单上也频繁出现“零基础可复制教程”这类关键词。本地部署RAG确实很香：数据不出内网、无API调用费用、可私有化定制。但翻车点也非常集中，尤其是新手。
坑1：Embedding模型和LLM模型混为一谈。有人用一个模型既做向量化又做生成，结果检索效果和生成效果都很差。这两个任务的技术要求不一样，至少在当前的开源生态里，还是要分开用两个模型。
坑2：向量库使用不当。有人把向量库只当成“存向量的地方”，忽略了它也有索引参数。比如Chroma的默认距离函数是L2，但很多教程推荐的模型是余弦相似度训练的，不匹配就会导致检索质量下降。用模型之前，先确认它的训练目标，是cosine还是L2，尽量保证向量库的距离函数和模型一致。
坑3：重复执行管道导致脏数据。知识库更新后，旧的向量没删除，再跑一遍入库，同一个文档在库里出现两个版本。查询时两个版本的分数接近，模型一会答新的、一会答旧的，体验极差。建议入库时带上文档ID，更新时先按ID删除旧向量，再写入新向量。
6.2 一套亲测稳定的ollama + 本地RAG参考配置
如果你是零基础，想快速跑通一个本地RAG知识库，我建议按下面这套来：
- 模型：
ollama pull qwen2.5（生成）+ollama pull bge-m3（Embedding）。 - 向量库：Chroma，轻量且对新手友好，一个
pip install就能用。 - 框架：LangChain，文档多，社区案例丰富。
- 数据接入：先用文本文件和Markdown文件跑通，再上PDF和Word。
跑通之后，你会有几个直观的感觉：响应速度取决于本机显卡（纯CPU跑7B模型会比较慢）、检索准确率取决于切片和嵌入模型的配合、整个链路最脆弱的环节是文档解析。
6.3 评测体系：别再用“感觉”验收RAG
本地部署的另一个“隐性坑”是没有评测标准。很多团队做完RAG，测试方式是拿三五个问题问问，感觉还行就上线了。这在demo阶段可以，但进入生产环境，一定要建立一套基础评测集。
我建议至少准备：
- 20~50个真实用户问题，覆盖高频问题、长尾问题、边界问题。
- 每个问题标注标准答案来源（来自哪一份文档）。
- 每次调整切片参数、换Embedding模型、改提示词时，跑一遍评测集，对比正确率。
不要小看这一步。RAG系统的每次改动都可能带来局部提升、全局下降，没有评测集，你根本不知道改了什么就退化了。这也是我见过最多团队在“优化RAG”过程中越改越乱的根本原因。
7. 踩坑之后，我自己留下的几条判断准则
这些是我在RAG项目里反复踩坑后沉淀下来的几条体会，分享在这里，权当给后来者一个参考。
第一，先诊断出问题在哪个环节，再动手改。RAG链路长，一个badcase可能是切片问题、嵌入问题、检索问题、提示词问题、甚至文档本身质量问题。不要一上来就换模型或改提示词，先定位，再动手，否则90%的调整都是在碰运气。
第二，数据质量永远值得花最多时间。我见过太多团队花两周调模型参数，最后发现是原始文档里有一半内容都是过时的。先把数据清洗、去重、版本管理做扎实，RAG的效果能提升一大截。
第三，从Q&A问答对做起，是最稳妥的冷启动方案。不管你是做本地知识库、客服机器人还是内部文档问答，先用FAQ构建一个最小可用RAG，效果稳定后再往长文档扩展。这条路成功率最高，也最适合“零基础可复制”。
RAG不是什么魔法，它只是一个朴素的系统。系统出问题的概率永远和环节数成正比。正因如此，把每个环节可能出的错提前想到，比追求花哨的架构更有价值。
