RAG 检索增强生成七步链路实战：从文档切分到答案生成

RAG 检索增强生成七步链路实战从文档切分到答案生成一、为什么需要 RAG三个绕不过去的限制本地模型跑起来之后你会撞上三个限制它们恰好对应 RAG 的三个存在理由。第一是幻觉。问模型我们公司产品的保修期是多久它不会说不知道而是基于训练时的通用知识编一个听起来合理的数字。对企业场景这是致命的。RAG 的思路是先把文档里真正相关的段落搜出来强制模型照着资料答题编造空间被大幅压缩。第二是私有知识不在模型脑子里。公司合同、内部手册、上周的周报训练语料里不可能有。RAG 不要求模型记住这些材料只要求它现场读——每次提问时把相关资料临时塞进上下文。知识更新不需要重新训练文档改了、重新入库下一次提问就生效这是 RAG 相对微调最大的运营优势。第三是上下文窗口有限。就算不嫌贵几十万字的文档也塞不进一次请求。RAG 只检索最相关的 3-8 个块上下文占用稳定可控。一句话概括RAG 就是给模型配一套开卷考试的资料检索系统。二、标准链路七步从文档到答案RAG 的完整链路分两条泳道离线建库文档只处理一次和在线问答每次提问都走一遍。第①步文档准备输入是原始文档PDF、Markdown、TXT、HTML。这一步最坑的在源头扫描版 PDF 没有文字层解析出来是空的后面全白干要先确认能复制出文字不行就先 OCR。表格混排的文档抽取顺序常常是乱的建议人工整理成 Markdown 再入库。还有一个经验一百份产品手册和一百份合同混在一个库里检索精度会被明显拖累按主题分库更稳。第②步解析Loader解析器把不同格式还原成纯文本。手写时一般用 LangChain 的各类 Loader 或各格式自己的解析库。可调点是元数据解析时给每段文本附带来源信息文件名、页码、章节名后面调试答案出处对不对全靠它也是给最终答案附引用的基础。第③步切块Splitter——最影响检索质量的参数切块是 RAG 里最考验经验的地方。经验区间单块 800-1200 字相邻块 10-15% 重叠。两个方向各有一个坑块太大一个块塞太多主题语义被稀释模型要在一大段里自己找答案块太小一句话一个块语义不完整。重叠区让跨边界的语义在相邻块各留一份缓解关键信息正好卡在切缝上的问题。实操建议优先按结构切按章节、按段落边界而不是按字数硬切。按结构切为主、超长段落再按字数切是更稳的组合。第④步嵌入Embedding嵌入模型把文本映射成高维向量。两条硬约束入库和检索必须用同一个嵌入模型换模型后老库向量全部作废必须重建——这是 RAG 最常见的坑中文文档优先选中文能力强的模型本地可用 bge-m3轻量通用可选 nomic-embed-text。第⑤步入库向量库所有块的向量连同原文、元数据写进向量数据库。选型参考Chroma 嵌入式适合个人和小数据量FAISS 内存库适合追求检索速度Milvus 或 Qdrant 适合生产和海量数据。第⑥步检索top-k把用户问题用同一个嵌入模型转成向量去库里找距离最近的 k 个块。经验区间 top-k 3-8k 太小相关块没排进前几答案直接缺料k 太大噪声块引入不仅浪费上下文还会把模型注意力带偏。判断 top-k 是否合适有个土办法把检索出来的块打印出来自己看一遍前 3 个块里必须包含答案原文否则不是模型的问题是检索没命中。第⑦步拼 Prompt 与生成把系统指令 检索到的块 用户问题拼成一次请求发给 LLM。Prompt 模板里两句指令很关键“只根据下面提供的资料回答资料里没有就回答’资料中没有相关信息’”——给模型留说不知道的出口是压制幻觉的直接办法资料和问题分开标清楚别让模型分不清背景和问题。三、最小可用代码Ollama 嵌入 Chromaimportrequestsimportchromadb OLLAMAhttp://localhost:11434LLM_MODELqwen2.5:7bEMB_MODELbge-m3defembed(texts):resprequests.post(f{OLLAMA}/api/embed,json{model:EMB_MODEL,input:texts})resp.raise_for_status()returnresp.json()[embeddings]# 离线建库一次性clientchromadb.PersistentClient(path./rag_store)colclient.get_or_create_collection(manual)col.upsert(ids[str(i)foriinrange(len(chunks))],embeddingsembed(chunks),documentschunks)# 在线问答每次提问defrag_answer(question:str,top_k:int5)-str:hitscol.query(query_texts[question],n_resultstop_k)context\n.join(hits[documents][0])prompt(只根据下面的资料回答用户问题资料中没有相关信息就回答资料中没有相关信息。\n\n【资料】\ncontext\n\n【问题】question)resprequests.post(f{OLLAMA}/api/chat,json{model:LLM_MODEL,messages:[{role:user,content:prompt}]})resp.raise_for_status()returnresp.json()[message][content] 验证分三层Ollama 层确认嵌入模型在列表里检索层把命中块打印出来确认包含答案原文——这是金标准检索没命中时别急着调 Prompt先回切块和嵌入模型查生成层确认回答与文档一致且对资料里没有的问题回答没有相关信息而不是编造。## 四、回答质量排查症状对应链路RAG 答错时按症状反推是哪一步出了问题不要一上来就换更大的模型-检索不到命中块全不相关→ 切块/嵌入/文档质量有问题。检查是否扫描版 PDF 没抽到字确认入库和检索用同一嵌入模型。--答非所问命中对了但答偏→ top-k 过大引入噪声或 Prompt 没写死只根据资料回答。降 top-k 到3再看。--幻觉资料里没有的也编→ Prompt 没留说不知道的出口或模型能力不足。加没有就回答不知道仍不行换更大的对话模型。--答案对但缺细节→ 块切得太碎关键句被切散。加大 chunk 或加大 overlap 重切重建。 调试习惯每次只改一个变量并把检索命中块打印出来对比。改完立刻知道是哪次改动起的作用。## 五、RAG vs 微调 vs 长上下文先选路线再动手三条路线经常被混在一起其实分工不同让它知道新事实用 RAG知识更新快、需要引用来源、冷启动项目都适合让它学会新本事用微调风格、格式、专业推理这类怎么答的问题微调更合适两者可叠加微调把基座调好RAG 负责喂私有知识。 长上下文场景也有讲究文档总量在几万字以内、且每次提问都高度相关比如就一份合同反复问直接整份塞进上下文可行省掉检索失真的风险文档总量超过上下文预算、或每次提问只跟一小部分相关必须走 RAG。折中做法是直接塞 检索各留一部分。 生产环境里 RAG 答案最好带出处解析时把文件名、页码存进 metadata检索后把来源编号附在答案末尾。引用对不上时问题多半出在切块边界——这既是用户体验也是快速核对通道。把这条链路吃透任何工具里的切块大小、top-k、嵌入模型这些参数你调起来都有依据而不是盲猜。