1. 先泼一盆冷水你能跑通的 RAG 流水线距离能用的项目还差得远这两年聊 RAG 的人非常多随便打开技术社区挂着 RAG 标签的项目一抓一大把。我粗略统计过自己接触过的落地场景从知识库问答、客服辅助、报告生成到企业内网检索真正从 Demo 走到生产环境并稳定跑上几个月的其实不到两成。这不是 RAG 本身不行而是跑通流水线和做成产品之间隔着一条巨大的认知鸿沟。很多朋友第一次接触 RAG学到的都是同一套标准动作加载文档、按固定大小切分、丢进 Embedding 模型转成向量、存入向量库、检索 TopK、把命中片段拼进 Prompt、丢给大模型生成答案。这套流程本身没错它是 RAG 的基础骨架任何项目都绕不开。问题在于这套流水线太容易跑通了。你只要会写几十行 Python用 LangChain 或者 Spring AI 封装的现成组件半小时就能搭出一个能回答问题的 Demo。但 Demo 能回答和回答得对、回答得稳、回答得快是三件完全不同的事。我见过太多项目死在同一个地方向量库里存了两万段文本检索召回率看着很漂亮用户随便问一个需要跨段落推理的问题答案立刻开始胡编。也见过有的团队把文档解析做得极其粗糙PDF 里的表格变成了乱序字符串导致模型每次回答都引用错数据。这些问题的根源都不在生成阶段而在流水线上游那些被认为差不多就行的环节。所以RAG 烂大街这个说法我认为只说对了一半。烂大街的是那条谁都能搭出来的基础流水线真正拉开差距的是六个很少被放在一起讨论的分水岭。这篇文章我不想再重复一遍什么是 RAG 检索增强生成这种科普也不会只给一堆概念名词。我就按自己做项目时实际踩过的坑、反复调整过的方案把这六处关键节点一个个拆开讲。适合谁看正在做知识库问答、准备把 RAG 落地到业务系统、或者做完 Demo 之后不知道下一步该优化什么的开发者和产品同学这篇应该能帮你在动手之前先建立一张完整的作战地图。1.1 为什么说流水线烂大街——不是比喻是实情随便搜一下 RAG 教程你看到的套路几乎完全相同LangChain 官方教程加载一个 PDF用split_text按固定长度切块OpenAI Embedding 入库然后RetrievalQA一问一答。Node 生态里有 LangChain.jsJava 生态里有 LangChain4j Easy RAG 和 Spring AI 的抽象甚至有人把整套流程封装成了 RAG as a Service调用方只需要传文档和问题。这意味着什么意味着组装这条流水线的成本已经趋近于零它不再构成任何竞争优势。但同样的流水线在不懂行的人手里和懂行的人手里产出的系统完全不是一个物种。举一个最简单的例子同一个 PDFA 团队用 PyPDF 提取文本后直接按 500 字符切块B 团队先做版面分析识别标题层级、表格区域再按语义段落切分最后连文档结构一起存进向量库。两套系统面对二月份华东区的销售数据环比涨了多少这种问题A 可能连销售数据对应的表格都定位不到而 B 能把表格行、列标题和上下文描述一并召回让模型拿到结构化信息进行推理。流水线相同分水岭在流水线上游的每一个决策点。所以我一直跟团队里的人说别把精力浪费在反复调整 Prompt 上祈求模型变聪明要先检查喂给模型的材料是否干净、结构是否完整、检索是否真的命中。大部分 RAG 项目效果差不是模型不够强而是输入侧的工作没做到位。1.2 站在 2025 年的时间点重新给 RAG 画一张全景图为了不让下面的讨论变成零散技巧我先给一张我在项目复盘时常用的全景图。这张图把 RAG 系统拆成六个环节每个环节对应一类能力也是我认为当前阶段真正值得投入的分水岭分水岭核心问题大多数项目翻车的地方文档解析与切分模型能否读到干净的、保留结构的上下文直接文本抽取表格和版式信息全部丢失检索策略召回的片段是否真的包含答案所需信息只看 Hit Rate不看上下文完整性和准确性索引组织知识之间是否互相连接能否支撑跨段推理永远扁平向量知识割裂严重Agentic 编排复杂问题能否被拆解成多步检索与推理一次检索就出答案遇到复合问题直接崩评测闭环系统改动后是变好还是变坏有无量化依据靠肉眼和几个手写的测试题糊弄工程落地从几百个文档到生产级服务的扩展性、成本与运维只在笔记本上跑通没考虑部署和更新下面我从第一处开始逐个展开。2. 分水岭第一处文档解析与切分决定答案上限的不是模型而是这一步如果只能选一个环节来优化我会毫不犹豫选文档解析。原因很简单RAG 的上限不是由大模型决定的而是由喂给模型什么决定的。你用一个很强的通用模型但喂给它的上下文是把 PDF 表格抽成一行行乱序文本它再聪明也没法还原出正确的行列关系。这个道理跟人一样——让一个分析师看一份扫描件复印件他能看明白让同一个分析师看一张被裁掉一半、表格线错位的传真他肯定会抓狂。模型不会表达我看不清它只会硬着头皮回答然后用幻觉来掩盖理解上的缺失。2.1 版面解析PDF 表格、双栏、页眉页脚的第一波翻车PDF 是最常见的知识库载体也是解析重灾区。用pypdf或 PyMuPDF 直接抽取文本处理纯文字型、单栏排版的文档没有大问题但只要遇到以下三种情况效果就会急转直下表格抽取顺序通常是先读表头行再一行行读单元格文本。如果 PDF 的表格是由坐标定位的抽取出来的文本顺序完全可能变成左列全部读完再读右列导致一行数据被拆到两个地方。双栏排版很多论文和杂志是双栏印刷直接抽取文本会把左栏下半段和右栏上半段拼接在一起语义完全错乱。页眉页脚与页码如果不去除页眉页脚每页都重复的公司名称、章节名会反复进入向量库检索时这些噪声片段很容易被当成有效信息召回白白挤占上下文窗口。我在实际项目里处理这些问题时常用的组合方案是先做OCR 或版面分析再做结构化提取。工具链上轻量场景可以直接用 Unstructured 库它能自动识别标题、正文、表格区域复杂一些的 PDF我推荐用 MinerU 或者把 PDF 转成图片后走多模态模型做版面识别。这一步的产出不是纯文本而是一份带结构信息的文档对象至少要标记出标题层级、段落边界和表格的行列结构。提示判断一个 PDF 解析方案是否合格不要只看文字抽取率要直接检查表格转出来后行列是否真实对应。很多开源工具文字抽取率能做到 95% 以上但表格结构还原率惨不忍睹。2.2 切分策略固定窗口是权宜之计结构感知才是正解切分是另一个容易被低估的环节。很多教程教你用一个RecursiveCharacterTextSplitter按 500 字符切块、50 字符重叠这在玩具项目里没问题但放到真实文档里会产生大量语义断裂。比如一个包含三层结构的产品文档标题是接口鉴权下面依次是签名算法参数说明错误码固定长度切分可能把签名算法的正文切成两半让第一半落到上一块的末尾第二半落到下一块的开头。检索时如果只命中了第一半模型拿到的就是一截不完整的思路。我现在的做法是结构感知切分优先。具体来说先按文档自带的大纲结构Markdown 标题、PDF 目录项、HTML 的 Heading 标签把文档切成若干语义块每个块对应一个完整的主题。对过长的块再用段落边界和句子边界做二次切分而不是硬按字符数切。切出来之后给每个块打上元数据包括文档标题、一级目录、二级目录、页码、块 ID。这些元数据在后面的检索排序和引用溯源阶段会救命。如果你用的 Python 栈LangChain 里新版的MarkdownHeaderTextSplitter和HTMLSectionSplitter都可以直接用如果文档格式比较复杂可以自己写一个简单的解析器先记录标题出现的位置再取两个标题之间的正文作为候选块最后对超长块做递归切分。我用这个思路处理过几百份技术文档召回质量比固定窗口切分高出一截而且后续定位引用来源也方便得多。关于 chunk 的参数我一般不会把固定值当成金科玉律。chunk_size 设在 400 到 800 token 之间、重叠设 10% 到 20%是一个兼顾上下文完整性和检索精度的经验区间。但真正的原则只有一条切分边界必须落在语义完整的位置不要腰斩一个话题。你用固定长度切完之后随手抽几个切片读一读如果读起来前言不搭后语那这个参数不管数值多好看都得改。2.3 本地可用的解析与切分工具链零基础也能复制聊到工具很多朋友想找一个本地就能跑的RAG 文本拆解工具。按我的经验本地方案完全够用关键是要分层处理PDF 解析文本型 PDF 用 PyMuPDF Unstructured扫描型 PDF 用 OCRPaddleOCR 或 Tesseract。想省事就用现成的 MinerU 或者 OpenParse。HTML/MarkdownBeautifulSoup 提取正文Markdown 直接按标题结构切。切分框架LangChain 提供的各种 Splitter 用起来最快想更可控可以写一个 Python 函数按标题级别做递归切分核心逻辑不到 50 行。真有决心做到位的话我第一次建议你手写一次切分逻辑而不是直接用现成组件。因为只有自己处理过标题识别、正文归属、表格保留、超长块递归这些问题你才会真正理解为什么切分不是简单按字数割也才能在出问题时快速定位到是解析环节、切分环节还是检索环节掉了链子。3. 分水岭第二处检索策略别拿 Hit Rate 自嗨答非所问的根源在这里做完解析和切分向量库里已经有了一批看起来很干净的文本块。接下来是检索引擎这一环决定了知识有没有被找到。很多人对这个环节的认知停留在把问题转成向量算个余弦相似度取 TopK。这套逻辑在文档数量少、问题简单、关键词明确的情况下勉强能跑一旦文档量上去、问题变得口语化你会发现结果非常不稳定。3.1 Hit Rate 只是入口上下文命中不等于答案正确社区里经常讨论 Hit Rate也就是检索结果中是否包含正确答案的来源。拿它做评估指标本身没有问题但如果你只盯着 Hit Rate等于只验证了相关内容有没有被召回而没有验证召回的上下文是否足够回答问题。我遇到过很多案例Hit Rate 高达 95%但模型的回答仍然是错的。原因通常是正确答案被切到了一个不完整的块里比如表格被拆成了两半或者关键数字所在的句子缺少主语。所以我在项目里会同时看两个指标Context Relevance召回内容与问题的相关程度和Faithfulness生成答案是否忠实于召回上下文。前者衡量检索质量后者衡量生成质量。Hit Rate 可以看作有没有候选Context Relevance 决定候选是不是真的有用Faithfulness 决定模型有没有照着候选答。三者缺一不可。怎么提升 Context Relevance第一步先自查召回样本。真实用户问题进来后打印出召回的前 10 个片段人眼看一遍。你很快就会发现问题有些检索结果与问题只在字面上有重叠语义上完全不相关有些问题涉及多个主题单个向量检索只能命中其中一个最核心的信息散落在多个块里TopK 拉不到一起。这几种情况对应不同的解法但有一种解法对大多数场景都有效那就是上混合检索。3.2 混合检索BM25 与向量不是二选一而是搭档纯向量检索的弱点是语义接近但字面很远的 query 检索不到、精确关键词反而索引不到。比如你问加多宝是哪个公司的向量检索可能会把王老吉相关法务问题的文档拉升上来但 BM25 能准确命中包含加多宝全部关键字的句子。反过来怎么写一封辞职信这种语义型问题BM25 表现不如向量。所以很多团队选择了 Elasticsearch / OpenSearch 的混合检索BM25 计算稀疏关键词得分向量模型计算稠密语义得分最后用 RRFReciprocal Rank Fusion合并排名。我之前在一个企业内部知识库项目里做过对比。单向量检索的 Context Recall 大概在 78%加上 BM25 并行召回并用 RRF 合并后提升到了 89%。这个提升主要来自两类受益场景一类是包含产品编号、法律条款号、工单 ID 这类精确标识符的问题另一类是实体名称较冷门、但文档中恰好有完整关键词匹配的短问题。如果你的业务文档里有大量型号、编号、名词缩写混合检索几乎是必选项而不是可选项。混合检索的实现并不复杂。Python 侧可以直接在 Elasticsearch 上建knnmatch的查询模板Java 侧可以直接用 Spring AI 或 LangChain4j 的向量存储抽象底层换成带稀疏检索能力的库比如 Elasticsearch、Qdrant 的 sparse vector或 Weaviate。我自己的习惯是先用 Qdrant BM25 实验性跑通确认指标提升后再决定要不要下沉到 Elasticsearch。3.3 Rerank 这一层今天已经不能省了混合检索能把候选集从够用变成更多但 TopK 里通常还是会混入一些次相关的片段。再往后一道关键工序是Rerank重排。Rerank 模型通常是一个交叉编码器Cross-Encoder它把问题和候选片段拼接成一个序列送进模型输出一个相关性得分比双塔式的向量相似度精细得多。代价就是速度慢所以它只负责对召回的前 20 到 50 条做精细打分而不是对全库打分。有一个很形象的类比向量检索是海选简历只看学历关键词快速筛掉 90% 的人Rerank 是面试官和候选人坐下来细聊判断这个人到底适不适合岗位。海选可以糙但面试这一关不能省。具体模型选型上中文场景常用 bge-reranker-v2-m3英文场景常用 Cohere Rerank 或 BGE 系列本地方案也可以跑 Qwen3 系列专门定制的 rerank 版本。在 LangChain 里加一层 Rerank 非常简单拿到检索结果之后调一下 reranker 的rerank(query, documents)取前 4 到 6 条作为真正的上下文。自从所有项目都加了 Rerank 之后我几乎没有再为TopK 里混进垃圾内容这件事单独调过参。4. 分水岭第三处索引结构从扁平向量到本体与知识图谱有了干净的块、能精准检索的策略很多项目在问答效果上已经超过平均水平了。但再往前推一步就会撞上一个更硬的墙知识割裂。扁平向量库里每一段文本都是孤立的模型可以回答某个细节是什么但要回答A 和 B 之间是什么关系、把三条数据汇总起来看结论单纯靠向量检索很难组织出跨片段的推理线索。这也是大家讨论 GraphRAG、本体 RAG、LLM Wiki 这些方向时最关注的问题。4.1 知识割裂问题的本质你存了一堆句子却没有存关系举一个项目里遇到的真实场景企业知识库里有一份员工手册里面写年假 15 天需工作满一年另一份请假制度里写入职不满一年的员工只能享受 5 天年假。两份文档被切成不同的块向量库分别存储。用户问我刚入职半年能休几天年假检索系统可能同时召回两块文本模型在拼接时看到两个互相矛盾的结论就有概率给出错误答案。这个问题的本质是RAG 检索的是文本片段但人类理解知识依赖的是实体之间的关联。如果索引层没有建立员工手册-年假规则-入职年限这组关系模型就只能通过文本里的字面措辞去碰运气。扁平向量的语义检索对相关有一定容忍度但对关联推理天生无力。4.2 GraphRAG 不是银弹本体才是真正的骨架GraphRAG 这两年热度很高核心思路是用 LLM 从文档中抽取实体和关系构建知识图谱然后在回答时利用图结构做社区检测、聚合摘要。这个思路是对的但我见过不少团队照着官方实现搬了一遍效果并不理想。原因在于直接让 LLM 抽取的实体-关系三元组往往是危险且不稳定的。同一个实体在不同文档里叫法不同关系谓词五花八门图构建完了之后噪声极大检索时很难保证准确。我更推荐的做法是在 GraphRAG 之前先引入一套稳定的本体约束。所谓本体就是预先定义好的实体类型和关系类型比如员工制度条款部门是实体适用于冲突于规定是关系。让 LLM 在这个受限的 Schema 里去抽取而不是自由发挥。这就像让一个编辑写新闻时先限定好标题-导语-正文的结构而不是给他一张白纸随便写。有人把这套做法叫做本体 RAG或 Ontology RAG我认为它才是解决知识割裂的骨架图结构只是骨架之上的皮肉。本体的 Schema 怎么设计我的经验是不要一上来就追求全知全能的模型化规则。先根据业务里最高频的 20 个问题类型反推它们分别需要哪些实体、哪些关系如果一个关系的覆盖场景不足三个问题就先不建。Schema 尽量保持在 10 到 30 个类型之间宁简勿繁。建好 Schema 之后用 LLM 从文档里抽实体和关系存进图数据库Neo4j 或 NebulaGraph再把每个实体对应的文本块链接回向量库。检索时先通过图找关联实体再把这些实体的描述文本作为上下文补充给模型。这个图引导向量的方案比纯 GraphRAG 更容易落地、也更可控。4.3 一种可落地的本体式索引方案如果要给一个能抄作业的路径我建议按这个顺序来建 Schema把业务里最重要的实体类型、关系类型罗列出来开一个半天的小型工作坊和业务方一起敲定。抽取与清洗用 LLM 按 Schema 从已有文档中抽取三元组抽完一定要做实体对齐把王总王小明王某归并为同一个实体节点。这一步最耗时也最值得花时间。图 向量双存储实体和关系进图库原始文本块进向量库。图库负责找关系向量库负责找文本。检索时做两层路由先判断问题是否需要跨实体推理。如果需要先走图查出关联实体集合再将这些实体的文本块以及它们的邻居块一起喂给模型。这个方案的好处是即使图抽得不完整向量检索仍然能做兜底而一旦图结构命中正确回答的推理质量会明显提升。我做过最典型的一个案子是把公司两千多份制度文档按这套方式重构成了制度本体用户问出差住宿标准超了怎么办时系统能自动关联差旅制度-费用报销-审批流程三份文档给出有层级结构的完整答案而不是从某一份文档里抄一段。5. 分水岭第四处Agentic 编排让 RAG 从查询接口变成思考过程如果你走到前三个分水岭你的 RAG 已经能回答大多数单点问题。但是真实的用户问题往往是模糊的、复合的、需要多轮对齐的。比如帮我把上季度各区域的销售情况做个对比顺便指出哪个区域增长最慢——这背后至少包含两个子任务查销售数据、做区域对比分析还可能涉及一个时间维度的筛选。传统 RAG 只适合问一句、检一次、答一次的模式遇到这种问题就会暴露结构性的短板。5.1 Agentic RAG 到底解决什么问题很多人把 Agentic RAG 理解成在回答之前多调用几次检索这个理解不够准确。Agentic 的核心是把回答问题的过程变成一个决策循环模型根据用户问题决定下一步做什么——拆解问题、选择工具、调用检索、阅读结果、判断是否足够、不够就继续——直到有足够信息时才生成最终答案。这种模式天然适合问题里包含多个子问题需要分别检索再合并第一次检索结果不充分需要换关键词或换检索方式重试用户说法模糊需要追问澄清答案依赖多份文档需要让模型自己决定再找找还是开始回答。举个例子。用户问我在北京入职一家新公司社保和公积金应该按什么比例交一个 Agent 可以先把这个复合问题拆成北京社保比例和北京公积金比例两个子查询分别检索两份不同但都相关的文档最后合并输出。传统 RAG 用一条 query 去做向量检索几乎不可能同时从两份文档里拿全答案。这就是 Agentic 的价值把 RAG 从一个死板的查询接口升级成一个思考过程。5.2 子查询分解与工具调用的最小实现如果你想自己实现一个最简 Agentic RAG不需要上重型框架核心就两个能力让 LLM 输出结构化行动计划和让程序按照行动计划调用工具并回填结果。以 Python 为例用 LangChain 的create_openai_functions_agent或新版 LangGraph把检索工具注册成可调用函数agent 会自动决定调用时机。伪代码思路大致是这样from langchain_core.tools import tool from langchain_community.vectorstores import Qdrant from langchain.agents import create_tool_calling_agent, AgentExecutor retriever qdrant_store.as_retriever(search_kwargs{k: 5}) tool def search_knowledge_base(query: str) - list[str]: 从企业内部知识库检索与 query 相关的文档片段 docs retriever.invoke(query) return [d.page_content for d in docs] tools [search_knowledge_base] agent create_tool_calling_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools) answer agent_executor.invoke({input: 北京社保和公积金比例分别是多少})关键点是这个tool的 docstring。不要以为工具描述只是给开发者看的注释Agent的 LLM 会认真读这个描述来决定何时调用、怎么调用。描述写得含糊模型就可能不知道该不该用这个工具或者在需要的时候跳过它。我见过不少 Agent 调用混乱的问题最后定位到根因就是工具描述太敷衍。还有一种轻量方案不用 agent 框架直接在 Prompt 里要求模型 JSON 输出下一步计划程序解析 JSON 后依次执行检索并回填。这种方案可控性更强、调试更简单适合步数固定、规则清晰的业务比如先查产品信息再查库存最后查价格。5.3 从 LangChain 到 LangChain4j / Spring AI不同技术栈怎么选说到技术栈我顺便提一下生态选择带来的坑。Python 生态里 LangChain/LlamaIndex 功能最全社区例子最多适合做原型验证和重逻辑项目。但如果你所在团队是 Java 为主我更推荐在 Python 上只做离线实验线上服务用 LangChain4j 或 Spring AI 来承接。LangChain4j 的 Easy RAG 模块做基础检索很快Spring AI 的 Advisor API 能比较方便地做提示词模板和上下文组装。两者的共同问题是生态不如 Python 丰富但只要你的流程不复杂封装好的组件完全够用。我的实际感受是Agentic 环节最容易被忽视的反而是退出条件。循环检索不能无限进行一定要设置最大轮数比如 3 轮并明确要求模型在达到轮数后必须基于现有信息作答。否则遇到检索结果总是差一点的情况Agent 会陷入调用工具的循环既浪费 token又让用户在页面上干等。6. 分水岭第五处评测闭环没有评价指标的 RAG 项目都在裸奔现在很多团队做 RAG 项目评估方式还停留在我拿几个测试问题问它回答看着还行就上线。这种评估方式最大的问题在于系统上线后一旦调整了解析策略、检索参数或 Prompt你根本无法量化地知道这次改动是变好了还是变差了。RAG 项目做到后期日常工作的主体就是参数调优和策略调整如果没有一套信得过的评测机制优化就成了一场靠运气的赌博。6.1 评测维度怎么选不只是答得对不对我推荐至少在项目里建立三个维度的评测每个维度可以再拆细维度指标说明检索质量Context Precision / Context Recall召回的片段中是否包含答案信息、噪声比例高不高生成质量Faithfulness / Answer Relevance答案是否忠实于召回内容、是否真正回答了问题用户感知响应时间 / 引用准确率速度是否可接受、引用的文档编号和出处是否真实其中Faithfulness忠实度是我最看重的。RAG 最大的卖点是可溯源、可减少幻觉而 Faithfulness 衡量的恰恰是这一点。有些项目模型回答流利、逻辑通顺看起来很厉害但仔细核对内容后发现有一半是模型自己编的这种系统上线等于把幻觉风险放大给用户。生成式 AI 应用里看起来对是最危险的信号之一。在具体工具上RAGAS 是常用框架它提供faithfulness、answer_relevancy、context_precision等现成指标并且可以接入 LangChain/LlamaIndex 的 Run 日志做自动化评估。如果团队有能力也可以自建一个轻量评测脚本把测试集里的每个问题、标准答案、检索片段输给一个强大的评估 LLM让它按 1 到 5 分打三个维度再把结果存表。没有预算用 GPT-4 系列的话用开源模型也可以关键是评测口径要固定不能今天用这个模型打分明天换另一个否则指标就失去可比性。6.2 构建一个像样的评测集三个来源缺一不可评测集的质量直接决定指标有没有参考价值。我通常从三个来源构建测试集历史真实用户问题从日志里随机抽样。这是最接近真实分布的来源但要注意隐私脱敏。业务专家提供的挑战集让业务方整理 20 到 50 个他们认为最容易答错的刁钻问题专门测试系统的弱点。合成生成的边界问题用 LLM 在文档内容基础上变体生成问题覆盖否定提问、复合提问、术语别名等情况。每一条测试数据至少要有三列问题、标准答案、答案所在的源文档 ID。标好源文档 ID 很重要因为它能同时支撑上下文命中的检查和引用溯源验证。没有标准答案的评测集也能用但会损失精度。测试集规模不需要特别庞大一百条高质量问题足够支撑一周的迭代节奏关键是不能只加容易的问题那样评测结果会虚高。6.3 评测驱动的迭代节奏比你想的更简单有了评测集迭代就变成一件很有章法的事。我的习惯是每做一次改动解析规则、切分参数、检索 TopK、Rerank 开关、Prompt 模板先跑一遍评测看三个核心指标和响应时间的变化。改动之后指标如果没降就说明这步操作是安全的指标上升就保留指标下降就回滚。听起来很机械但这就是工程化的本质——把每次优化转成可验证、可回溯的决策。我踩过的一个比较深的坑是只评测答案文本而忽略了引用来源。有一次我们把检索从纯向量改成混合检索之后用户主观反馈答案更全面了但评测时发现 Faithfulness 反而下降。排查之后才知道混合检索把很多外部相似文档也召回了模型在拼接上下文时被部分无关信息带偏。如果没有评测及时发现这个副作用这个改动很可能就在感觉不错中被留在线上成为后续隐性问题的来源。评测闭环还有一个不可忽略的组成部分上线后的回访评测。建议每周从线上日志随机抽 50 条问答让评测模型重新打分用来监控崩溃、异常和指标漂移。RAG 系统的文档库会持续更新向量分布会随之变化静态测试集只能保证过往能力不退化线上巡检才能保证近期改动没有引入新的问题。7. 分水岭第六处工程落地从本地 Ollama 到生产级服务的最后一公里聊完算法和策略最后落到工程层。很多项目死在最后一公里代码在笔记本上跑得很好放进容器、接上生产数据之后问题一个接一个。RAG 系统不是模型文件 向量库 应用代码三样东西的简单叠加它的工程化难度主要集中在部署成本、更新机制和稳定性三个方面。7.1 部署形态从 Ollama 本地方案到服务化架构本地部署是很多团队的起点尤其是需要数据不出内网或者预算有限的场景。Ollama 配合一个轻量向量库Chroma/Qdrant搭一套简易本地 RAG 知识库确实是零基础就能复制的路线。具体怎么做装 Ollama拉一个 embedding 模型中文场景推荐 bge-m3兼容中英文、一个生成模型按显存规模选 qwen2.5 7b/14b 或 llama3.1再用 Python 脚本加载 PDF、切块、入库最后用同一个 embedding 做查询。这套东西我在一台只有 24G 显存的机器上跑过几十个文档的效果完全够用适合团队内部做知识库的 MVP。但请注意MVP 和产品之间至少还差着这几个问题并发与排队本地跑大模型的推理吞吐量有限高峰期需要给推理服务加队列、限流否则检索再快用户也等不到结果。向量库选型Chroma 适合原型但到了百万级向量、需要持久化和权限控制的阶段我更推荐 Qdrant 或 Milvus。Qdrant 部署简单、支持过滤Milvus 适合大规模和复杂的索引需求。API 抽象生产环境不要让你应用代码里的检索逻辑跟具体向量库绑死。用 Spring AI 的VectorStore接口或者 LangChain 的VectorStore抽象做一层隔离将来换存储引擎时不需要改业务代码。模型服务化生成模型可以继续用 Ollama 暴露 OpenAI 兼容接口也可以切到 vLLM 或 SGLang 提升吞吐还能配合 RAG as a Service 的思路把整套能力封装成独立微服务供多个业务线复用。我自己实践中比较顺手的部署组合是检索侧用 Qdrant 存向量生成侧由 vLLM 部署开源模型中间用 FastAPI 包一层文档上传、切分、检索、问答的服务接口缓存层放 Redis。这套组合在内部知识库项目里稳定跑了大半年单机就能承载日常几百个请求。7.2 增量更新与缓存设计决定系统会不会越用越笨RAG 系统的知识库是活的。文档会有新版本、旧文档会下架、员工手册可能每个月修订一次。如果更新机制做不好系统就会越用越笨——旧内容占据着向量库存量新内容迟迟进不来。做增量更新时我建议注意几点文件级版本管理每个文档存一个内容哈希重新上传时先比哈希内容没变就直接跳过变了再重新解析切分。向量级覆盖删除删除旧文档时不仅要删文件记录还要删对应块向量。如果向量库支持按 metadata 过滤删除Qdrant 的delete by filter就可以通过文档 ID 一次性清理干净。嵌入模型换版本的连锁反应如果你换了 embedding 模型全库向量都要重新入库这个操作通常只能离线做。为了避免频繁全量重建我在生产环境会尽量避免升级 embedding 模型把版本固定下来。缓存也是容易被忽略的点。高频问题比如产假几天怎么报销如果每次都走完整 RAG 流程既慢又费钱。我习惯加一层语义缓存把用户问题先做 embedding和缓存库里的向量做相似度比对命中就直接返回结果未命中再走完整链路。这个方案可以显著降低重复问题的响应时间和推理成本。需要注意给缓存的答案配一个过期时间因为知识库更新后旧缓存可能已经不能反映最新政策。7.3 最后一道避坑清单也是我给所有 RAG 项目的通用建议把六个分水岭走完之后我发现不同项目碰到的坑虽然千奇百怪但底层规律大致相同。最后整理几条通用建议希望能帮你少走弯路不要跳过问卷分析直接调参。用户的问题是流式分布先统计高频问题类型再决定检索策略和知识组织方式而不是一上来就上混合检索和图谱。检索失败不等于问题无法回答。至少要在 Prompt 里给模型一个如果检索内容与问题无关必须明说不知道的指令。大部分幻觉来自模型硬着头皮从无关上下文里编答案。本地先跑通再谈分布式。Ollama 本地方案甚至不需要 GPU 也能跑起来做功能验证验证完再逐步引入 vLLM、服务化组件也不迟。一上来就搭全套微服务架构很可能连问题都还没出现就先把团队精力耗光了。关注可观测性。RAG 系统上线之后要能看到每次问答检索了哪些片段、模型引用了哪段、响应用了多少 token。没有这些日志出问题时你连排查入口都找不到。我从第一个 RAG 项目到现在最大的体会是这套流水线看起来入门极快但每一项能力的背后都有大量的隐性工程。真正拉开团队之间差距的往往不是谁选的模型更强而是谁更早意识到了文档解析要做得像数据工程一样认真检索策略要配评测指标才敢上线知识组织要提前建立 Schema。如果你正打算做一个新的 RAG 项目不妨在动手写第一行代码之前先把这六个分水岭的位置画出来。资源有限时按解析质量、检索策略、评测闭环这个优先级去分配大概率不会走偏。