说实话做《RAG进阶实战》这个专栏的策划案我很早就想动笔了。RAGRetrieval-Augmented Generation检索增强生成这两年从一个学术名词变成了工程标配市面上教程也很多但九成都在教“怎么用LangChain读一个PDF然后问问题”把切块、召回、重排、评测这些真正决定系统质量的东西当成了默认值。这个专栏就是想填这个空档——给那些已经跑通过基础demo、但在真实业务里遇到“召回率低”“回答不准”“不知道该怎么优化”的工程师一套从原理到落地的完整思路。我在策划时把目标定得很明确不写教科书写工程实践。所有章节都围绕“一个能上线的RAG系统需要解决什么问题”来设计每个专题都配实验、评测指标和可复现代码读者跟着走一遍就能从“会跑demo”进阶到“能设计系统”。1. 专栏定位从一个demo到一个能上线的RAG系统1.1 这个专栏到底想解决什么问题RAG入门只需要三样东西一个Embedding模型、一个向量库、一个LLM。文档切一切向量存一存检索返一返拼接提示词看起来就能回答问题了。但凡是把RAG放到真实环境里跑过的人都会发现demo和可用之间隔着一条很宽的河。我观察到一个普遍现象网上教程越简单读者越容易产生“RAG很简单”的错觉。直到线上系统上线用户问了一个包含专有名词缩写的问题检索结果完全跑偏生成的回答看着自信满满实则内容全错才意识到RAG系统的效果不是由LLM决定的而是由知识库处理、检索链路、上下文组装这几个环节共同决定的。所以这个专栏的核心目标读者是那些已经接触过RAG、跑通过基础demo但在工作里遇到实际问题的人。具体来说有三类在业务里做智能问答但效果不好的后端工程师、需要做技术选型的数据团队负责人、以及想把RAG能力沉淀到公司内部知识库产品的架构师。专栏所有内容围绕三个问题展开怎么让回答更准怎么让响应更快怎么让系统可控。准包括检索准和生成准快包括延迟和成本可控包括权限、审计、评测和版本管理。我策划的每一章都是冲着这三个问题去的。1.2 什么是“进阶”的真正含义叫《RAG进阶实战》我得先讲讲“进阶”的边界。入门阶段关心的操作是用什么工具加载文档、用什么Embedding模型、用哪个向量库、怎么调用LLM。这些操作背后可以完全不了解原理照着步骤抄就行。但进阶阶段就不一样了。你要能回答这些“为什么”为什么chunk_size设成512效果比1024好为什么同样的文档换个Embedding模型召回率提升了十几个点为什么向量检索命中的结果和问题在语义上相关、但就是答非所问为什么三个检索结果都能用但拼在一起反而让LLM产生幻觉进阶不意味着学一个更高端的模型而是对整个RAG管线建立“可控感”。你知道每个环节默认参数背后是什么逻辑知道出问题时该从哪个环节切入排查也知道如何用数据而不是感觉来指导优化。这个专栏的每一章都是按这个标准来设计内容的。2. 知识库处理RAG的第一道生死线2.1 文本拆解从“能存”到“存得对”知识库处理是整个RAG管线里最不性感、但影响最大的环节。很多人把大量时间花在调模型、换框架上结果问题源头竟然是文档切得太烂。先说切块Chunking。固定长度切块是最常见的做法比如每512个字符切一段中间加128字重叠。这种办法的问题在于画面感太粗糙。它会在段落中间切开句子把“苹果公司的创始人之一”切成“苹果公司的创始”和“人之一”Embedding之后语义严重受损检索阶段自然找不到正确内容。文本拆解的关键是“按语义边界切”。实操中我建议按文档结构走先识别标题层级再按段落、句子、短语的顺序逐级切分这其实就是LangChain里RecursiveCharacterTextSplitter的思路。但更严谨的做法是用文档本身的语义结构比如Markdown的标题、HTML的段落、法律条款的条与款能按结构切就不要按字符切。这里要回应一个很多人问过的热词有没有本地的RAG文本拆解工具。有而且推荐在本地跑。unstructured库就很适合做脏PDF和Word的解析它能把表格、标题、段落识别出来textract能处理几十种格式pandoc是格式转换利器尤其适合处理带复杂结构的文档如果做OCR本地用PaddleOCR或Tesseract就够了。这些工具全部开源不依赖云服务隐私也好控制在Mac上装好环境就能跑。另一个提升检索质量的重要技巧是“父子检索”。简单说就是小块比如一个句子用来做召回匹配大块比如整个段落或整个小节用来喂给LLM生成回答。召回粒度细匹配准确生成上下文完整答案有来龙去脉。这个模式几乎成了我处理长文档的默认选项强烈建议在专栏第2章中实践。2.2 RAG知识库到底能不能存图片“RAG知识库能存储图片嘛”这个问题我经常看到。回答得严谨一点传统RAG存不了图片的语义但可以存图片里的文字。要看你的“存图片”具体指什么。如果图片里是文字信息比如截图、扫描件、含文字的PPT页标准做法是OCR。把图片里的文字提取出来作为文本块进入知识库。这种方式成熟、可靠、成本低也是目前绝大多数知识库产品实际使用的方案。PaddleOCR对中文支持很好Tesseract则更通用都可以本地部署。如果想存的是图片本身的视觉语义比如让用户问“这张流程图表达了什么流程”还能返回图片那就要上多模态RAG了。思路分两种第一种是用视觉语言模型VLM给图片生成详细描述再把描述文本放进常规向量库生成回答时LLM通过文本描述理解图片内容第二种是直接用多模态Embedding模型如CLIP类把图片和文本映射到同一个向量空间用户输入文字查询时直接召回图片。第二种更直接但对Embedding模型和后端存储的要求高。实战建议是按内容类型混用。公司知识库里既有产品文档图片又有流程截图。我会这样设计所有图片先走OCR提取文字再把文字入向量库同时用VLM生成图片的一句话描述作为补充字段如果检索结果显示某一段内容原文来自图片就把图片路径返回给前端展示。这样既保留了图片的展示价值又解决了语义检索问题。多模态RAG值得在专栏里单独开一节我会把两种路线的代码都放出来对比效果。2.3 向量库、知识图谱、结构化库到底该怎么选和“rag知识库能存储图片嘛”同样高频的问题是“kg知识库、rag知识库和结构知识库怎么区分各自用在什么场景”。这个词条拆开看本质是问三种知识组织方式的适用边界。先给一张直观的对比表类型数据形态典型场景查询方式代表技术向量知识库非结构化文本、图片、音视频Embedding语义相似检索、开放问答、相似案例推荐ANN向量检索Chroma、Qdrant、Milvus、PGVector知识图谱实体、关系、属性多跳关系推理、复杂关联问答、可解释性要求高的场景Cypher、SPARQLNeo4j、gStore结构化库表格、JSON、关系数据精确查询、聚合统计、指标计算SQLPostgreSQL、DuckDB三种库不是互斥的而是解决问题的不同层面。向量库擅长“模糊找相似”它不理解精确逻辑关系知识图谱擅长“追关系”比如“某公司旗下子品牌在今年发布的产品的供应商是谁”这种多跳问题结构化数据库擅长“算结果”比如“上季度各区域销售额的同比增长率是多少”这种调用聚合函数就出结果的活儿不该为难RAG。在很多实际项目里最佳方案是混合架构。一个查询进来如果包含明确的结构化查询意图比如带时间、数值的先走SQL或Cypher拿到精确结果如果是开放式文字问答走向量检索。还有一种越来越流行的做法是GraphRAG先用LLM从文档里抽取实体和关系构建知识图谱再结合社区检测做全局摘要最后配合向量检索回答局部和全局两类问题。这个模式我在下面的第4章还会详细展开。3. 检索链路决定回答质量的核心环节3.1 召回率低往往不是模型问题做RAG最让人沮丧的时刻是反复换了更大的模型、更贵的Embedding检索结果依然不对。这时候我一般会提醒一句问题很可能不在模型而在检索策略。向量检索擅长语义匹配但它有几个天然的盲点专有名词、缩写、型号、编号、数字。比如用户问“F-35的维护成本”如果文档里写的是“F35”或“联合攻击战斗机”向量检索很可能召回一坨不相关内容因为词面差异太大、语义上又缺乏足够的上下文化。这时纯关键词检索反而更有效——BM25这种算法就是为精确词匹配设计的。所以工程上首选的方案是混合检索Hybrid Search向量检索负责召回语义相近的内容BM25/全文检索负责召回词面命中的内容两者结果用RRFReciprocal Rank Fusion或者其他加权方式融合。这个改动很简单但效果立竿见影。我在多个项目里实测混合检索的Recall10比纯向量检索能提高10到20个点代价只是多维护一个倒排索引。更关键的优化是加一层Rerank重排。向量检索的目标是从几十万文档里快速筛出Top 50候选重排模型的目标是从这50条里精挑出最相关的Top 5。重排模型通常用Cross-Encoder会把查询和候选文档一起过一遍Transformer比双塔的向量模型精度高一大截。这相当于先海选再终审计算量有限但对最终答案质量的影响是决定性的。每次有人问我“RAG性价比最高的优化是什么”我的答案都是先加重排。3.2 Query改写别让用户的问题和知识库“对不上暗号”检索失败还有一个常见原因用户的表达方式和文档的表达方式不一致。用户问“这个产品保修几年”文档里写的是“质保周期为36个月”用户问“怎么退钱”文档里写的是“退款流程”。语义明明相关但Embedding在短文本上很难跨越这么大的表达差异。解决办法是Query改写Query Rewriting。在检索之前先用LLM把用户的原始问题改写成一个或多个更适合检索的形式。可以展开为完整句、提取关键词、补充同义词、甚至从不同角度改写多个查询分别检索后合并结果。还有一种叫HyDE的技术思路更激进先让LLM基于问题生成一个假想的答案再用这个答案去做向量检索因为假想答案和知识库文档的表达方式通常更接近。我把这一整套称为“检索增强”的完整含义。检索增强不只是字面意义的“检索以后增强生成”它应该覆盖检索前、检索中、检索后三个环节。检索前是Query改写和意图识别检索中是混合检索和重排检索后是上下文组装和重复内容过滤。把这三个环节都做扎实了RAG才算真正具备了工程意义上的“增强”。3.3 元数据过滤让检索范围从“全部文档”缩小到“对的文档”现实里的知识库从来不是“一堆文档”而是有部门的、有分类的、有更新时间、有权限等级的。这些信息就是元数据Metadata。很多人的RAG系统把元数据丢掉只保留纯文本等于把最便宜有效的结构化信息浪费了。正确的做法是在切块时把元数据完整保留下来并作为过滤条件参与检索。举个例子一个企业内部知识库接入了产品手册、销售合同、人力制度三类文档。用户问“年假怎么计算”如果不加过滤向量检索可能在销售合同里找到“年”和“假”两个词相关的内容造成干扰。但如果先用元数据把人力和制度类过滤出来再在这个子集里做向量检索效率和精度都会显著提升。这种“先过滤、后检索”的模式实现成本极低大多数向量数据库都原生支持Metadata Filter但效果奇好。我在教程里也会专门加一节如何设计元数据标签体系、何时在Filter前面加一级搜索、以及如何处理嵌套权限。这些都是生产环境里一定会遇到的问题但网上教程基本不教。4. RAG的瓶颈与破局从普通RAG到Agent和GraphRAG4.1 你迟早会撞上的RAG瓶颈讨论“rag瓶颈”很容易走向两个极端要么说RAG注定不行要么说RAG没有瓶颈。我见过的真实瓶颈基本集中在五个方面这五个问题其实也是我策划整个专栏后半部分的线索。第一是长文档的“中间遗忘”问题。文档太长切块太多检索返回的TopK很难覆盖真正的答案这是召回率问题。第二是多跳推理困难。用户问“A公司投资的那家做芯片的公司的CEO是谁”一次检索根本完成不了需要先找到A公司的投资标的再找到这家公司的CEO这是推理链问题。第三是上下文污染。检索返回了5个chunk其中2个相关、3个不相关不相关的内容混进Prompt里LLM很容易被带偏产生幻觉这是上下文质量问题。第四是评估困难。RAG系统是检索和生成两个Pipeline叠起来出错时很难分清是检索错了还是生成错了这是可观测性问题。第五是成本问题。长上下文、多轮检索、Rerank、大模型调用每一个环节都在烧钱这是工程成本问题。找到瓶颈之后我并没有像很多教程提纲那样直接给出一个“终极解决方案”。因为瓶颈不同解法也不同。多跳问题可以用智能体解决全局性问题可以用GraphRAG解决精确查询问题可以引入结构化查询上下文污染可以用更精细的重排和过滤。专栏后半部分就是按“识别问题类型、选择合适的架构”的思路来设计的。4.2 RAG智能体让回答从“找一次”变成“找对为止”Agent智能体和RAG的结合是我认为RAG进阶最重要的一个方向。传统RAG是单次检索用户问一次系统检一次拿结果生成答案。这个流程对简单问题足够但对需要多步推理的问题就无能为力了。ReAct范式是目前最实用的AgentRAG方案。核心逻辑是让LLM在接受任务后循环执行三个动作Thought思考需要什么信息、Action执行检索或调用工具、Observation观察返回结果直到有足够信息生成答案。这样系统可以从“A公司投资了哪些公司”开始检索出结果后再检索“这些公司的CEO是谁”最终组合出完整答案。多跳检索通过Agent体系变成了天然的能力。我在专栏里设计这个模块时重点不是讲概念而是让读者亲手实现一个能自主决定“要不要再检索一次”的小型Agent。用LangGraph或者直接手写一个ReAct循环都可以关键在于理解控制流和Token成本管理。不加限制的Agent循环非常烧钱一个简单问题绕了五圈、调了十几次模型这种案例我见过太多。所以要让Agent先约束步骤上限再引入“如果信息足够就停止”的判断机制这些都是实战中极其重要的细节。4.3 知识图谱与Ontology RAG让模型“有知识、懂规矩”知识图谱和RAG的结合对应的热词是“ontology rag”。这个方向的技术价值很实在纯向量RAG让LLM自由发挥缺点是模型可能在语义空泛时编造关系知识图谱则给模型一个“有边界的知识结构”实体是什么、关系是什么、属性有哪些都在图里定义好模型不能随便乱编。我先说说什么时候该上图谱。如果你手里的数据实体关系密集比如医疗里的疾病、症状、药物、禁忌金融里的公司、高管、股权、事件自然语言问答中经常需要“跳几步”才能得到答案那文本RAG会非常吃力图谱就派上用场了。典型做法是Text2Cypher让LLM把用户问题翻译成Cypher查询语句在图数据库里执行拿结果再去组织回答。这里的ontology本体起到约束作用——模型只能查你定义好的实体类型和关系类型从机制上杜绝了编造不存在的联系。GraphRAG是另一条路线。它先用LLM从全部文档中抽取实体、关系和社区结构再生成社区摘要检索时可以同时使用局部检索针对单个实体和全局检索针对整个社区回答“总结这份文档”这类全局问题效果显著。这个技术很火但我要提醒一句成本不低。抽取和摘要都需要大量LLM调用如果知识库文档量特别大先做评估再上别盲目跟风。5. 框架选型和本地实操环境5.1 RAG框架怎么选框架是起点不是终点“rag框架”选型是新手最容易纠结的问题。LangChain、LlamaIndex、Haystack各有各的生态网上争论也很多。我自己的态度很明确学习期可以用框架熟悉套路生产期尽量让核心链路在自己控制之下。LangChain生态最大、组件最全但抽象层次高Debug时要穿过好几层封装排查问题的成本很高这是它被吐槽最多的地方。LlamaIndex的定位更贴近RAG本身文档加载、索引构建、检索器的设计都很顺手。Haystack更工程化模块清晰适合直接搭服务。我没法说哪个框架最好因为它们解决的问题不一样。我的建议是专栏第1章到第4章会用LlamaIndex和LangChain带读者快速跑通各模块但在第5章我会带着读者手写一个极简RAG管线。你不需要依赖任何框架只用向量数据库的SDK加几十行代码就能实现文档切分、Embedding、向量检索、重排、Prompt拼装。这个过程非常“提神”——你会发现原来框架替你做了很多你不知道的决策也会发现自己真正需要控制的其实就那几个点。用自己的管线做生产系统出问题时至少知道从哪行代码开始找。5.2 在Mac上搭建一套本地RAG知识库“怎么在mac上搭建rag知识库”是个很具体、需求很旺盛的问题。尤其苹果芯片M系列跑本地模型非常顺很多开发者都在Mac上做实验。我就在这里给一套可操作的方案。先要把数据准备好然后装Ollama跑本地模型。Ollama是一个很轻量的本地模型运行工具能同时跑文本生成模型比如qwen系列、llama系列和Embedding模型比如bge-m3。装好之后在终端执行ollama pull qwen2.5:7b拉一个中文生成模型再ollama pull bge-m3拉一个Embedding模型接下来的代码里直接用它的API就行不需要自己管理模型推理环境。向量库可以用Chroma它是本地友好的纯Python依赖适合实验。核心代码如下from chromadb import PersistentClient from sentence_transformers import SentenceTransformer client PersistentClient(path./kb_store) collection client.get_or_create_collection(knowledge_base) # 使用Ollama提供的embedding模型也可以用sentence-transformers本地加载 from chromadb.utils import embedding_functions ef embedding_functions.OllamaEmbeddingFunction( urlhttp://localhost:11434/api/embeddings, model_namebge-m3 ) # 添加文档 collection.add( ids[doc1, doc2], documents[RAG系统通过检索增强生成能力减少幻觉。, 知识库切块策略影响检索精度。], metadatas[{source: guide}, {source: guide}], embeddings[ef([RAG系统通过检索增强生成能力减少幻觉。])[0], ef([知识库切块策略影响检索精度。])[0]] )查询时用collection.query(query_texts[...], n_results3)就能得到Top3结果。Mac上有MPS加速本地跑7B的量化模型速度完全够用配合Chroma和Ollama整套知识库搭建能在半小时内完成。专栏里我会把这套流程录制成一步一步的实操包括如何解决中文乱码、PDF解析失败、模型显存不足这些细节。5.3 Wiki和RAG“要不要用Wiki代替知识库”“wiki和rag”也是一个高频搜索词。很多人混淆了这两个概念其实它们不在同一个层面。Wiki是一种协作式知识管理工具RAG是生成式AI的上下文增强技术。你完全可以在Wiki上维护团队知识文档再把Wiki内容同步到向量库里做RAG问答也可以开发一个RAG工具直接对接Wiki API实现“问Wiki”而不是“翻Wiki”。实操上还有第三种做法把Wiki页面定时导出为结构化文本按页面标题和章节切分同步到向量库。这样Wiki继续承担人工编辑和维护的职责AI问答从同步过来的索引里做检索。这里要注意权限同步问题——Wiki里有些页面只对特定角色开放如果你不做权限过滤就同步到RAG会有越权风险。专栏里我是把Wiki和RAG的关系当作“一个知识维护与消费的经典组cp”来讲的核心是让读者理解知识从哪里来、如何更新、如何消费而不只是纠结某个工具。6. 专栏章节安排与配套实验设计思路6.1 每一章大概长什么样我设计的专栏共七大章每章都围绕一个明确问题展开并且必须有可运行的代码和可量化的实验结果。下面是完整结构章节核心主题要解决的问题实操产出第1章知识库处理与文本拆解不同文档类型怎么切才能少丢失语义本地拆解工具链输出切块评测小报告第2章Embedding模型选型与调优怎么挑选适合自己的Embedding模型三个模型在同数据集上的召回对比第3章混合检索与重排召回率低怎么治向量BM25Rerank完整管线Recall对比第4章Query改写与高级检索用户问法和文档写法差异怎么处理改写模块代码 效果对比第5章Agent与多跳检索复杂问题一次检索不够怎么办一个能自主二次检索的Agent第6章知识图谱与Ontology RAG关系密集型问答怎么做小规模知识图谱 Text2Cypher第7章评测、监控与生产化怎么持续迭代不靠感觉RAGAS评测 线上日志追踪方案这个设计逻辑很清晰前面1到4章是打好检索基础5到6章是突破瓶颈的高级架构第7章把所有内容收拢到“如何确保系统持续稳定运行”这个生产视角上。每一章都不是孤立的知识点而是递进关系——第3章会用第1章的切块结果第5章会复用第3章的检索器这种连线设计能让读者感受到RAG系统的整体性。6.2 配套数据集和评测方法没有评测就没有优化方向这是我反复强调的一句话。RAG系统是检索和生成两个Pipeline叠加如果每次调整都靠“看几个例子感觉变好了”那这个系统永远不会稳定。所以专栏每一章都配了具体的评测任务。检索侧我用的是公开的问答数据集英文的Natural Questions、TriviaQA中文的CMRC2018或者自建的小规模领域问答集。指标主要看RecallK、MRR和命中率。比如第3章里读者要分别跑纯向量、BM25、混合检索三组实验对比Recall10才能直观感受到混合检索的价值。生成侧我用RAGAS框架关注三个核心指标Faithfulness忠实度回答是否忠于上下文、Answer Relevancy答案相关性回答是否切题、Context Relevancy上下文相关性检索出的内容有多少被实际用到。这三个指标基本覆盖了RAG系统“检索准不准、生成信不信、答案对不对”三个维度。专栏里会教读者如何搭一套最小的评测脚本把每次调优的得分记录成历史曲线这才叫真正的iterate。6.3 从专栏到项目如何把Demo变成生产系统RAG项目做到最后你会发现技术细节只是海面之下的冰山一角。生产系统要解决的额外问题包括文档更新后索引怎么增量同步权限体系怎么在检索前生效用户对话日志怎么追踪敏感内容怎么过滤响应延迟怎么优化成本怎么控制。这些问题不解决再好的检索管线也上不了线。所以第7章里我会直接给一个“内部知识库问答机器人”的收尾项目。要求读者把前面所有章节的能力组装起来并额外实现三个功能基于元数据的权限过滤、增量更新的定时任务、以及基于日志的BadCase回溯机制。这个项目一旦跑通读者就可以把它迁移到自己的工作中直接用于生产。这也是我把这个专栏定位为“实战”的最大底气——内容不是看着玩的是要能搬回去用的。7. 搭建过程中最常见的坑和排查思路7.1 检索结果不相关按这个顺序排查检索效果差是最普遍的问题但很多人一上来就换模型、调参缺乏排查思路。我建议按固定顺序走先看切块再看Embedding然后看查询改写最后看重排和元数据过滤。切块问题有很明显的特征如果回答内容总是“缺头缺尾”或者同一个信息分布在多个chunk里导致每次都只召回一半那基本上就是切块粒度不对。遇到这种情况先改用段落级切分或父子检索。Embedding问题通常会表现为“语义相关但就是命不中”——尤其涉及领域术语时通用Embedding模型理解不了这时候要么换一个领域适配的模型要么在切块文本里补充术语上下文。查询改写问题则表现为“换个说法能检索到、原样问就检索不到”。一路排查下来80%的检索问题都能定位。7.2 回答内容看着完整、但答案全错了这种问题往往不是检索漏了而是检索“吵”了——返回的内容里混入了很多不相关的chunkLLM被噪音带着走。我之前就遇到过用户问“离职流程”系统返回的是公司制度文档里某段关于“离职面谈中需讨论的知识产权归属”的文字模型居然据此一本正经地编出了一套包含知识产权条款的离职流程。解决方案有三个层面一是减少喂给LLM的chunk数量从Top5砍到Top3并且提高相关性阈值过滤掉低分chunk二是引入Rerank时对最终入选的结果做一次相关性打分设定一个硬阈值低于阈值的宁可不要三是在Prompt里强制要求模型“若上下文中无明确答案则明确回答‘知识库中未找到相关信息’”从生成端抑制幻觉。这三点配合能明显减少“答非所问但自信满满”的情况。7.3 本地环境太慢Mac上跑RAG的提速心得本地跑RAG最烦的就是慢但“慢”也需要分清是哪里慢。如果是Embedding阶段慢多半是模型加载占用了太多资源解决方案是批量Embedding而非逐条调用如果是生成阶段慢可以试试更小的量化版本比如从7B降到4B也可以用更短的输出长度如果是检索阶段慢看看是不是没有给向量库建索引或者collection里累积了太多历史版本的数据。我自己在Mac上实测用Ollama跑qwen2.5:7bMaxTok输出控制在256以内单轮问答延迟能压到2到3秒如果任务简单比如关键词抽取换成qwen2.5:3b或者更小的模型延迟能到一秒内。一个常用优化技巧是给不同的任务配不同的模型——简单分类用小型模型复杂回答用大模型不要一个模型打天下。7.4 知识更新后系统还回答旧内容知识库不是一次性建完就完事的。很多人的文档每天都在更新但向量库里的内容还是旧版本导致系统回答内容和实际现状不符。这里要区分两个问题入库更新和索引生效。入库更新的最低成本方案是“按源文档版本号管理”每次文档更新生成新的doc_id版本旧的向量标记为过期但先不删除查询时通过元数据过滤只取最新版本。更简单的方案是直接删除旧的目标文档chunk重新切分并入库。对更新频率不高的知识库用定时重建的方式反而最省心。此外线上一定要有一个“数据更新时间”的字段可以在回答页面上展示既能帮用户判断时效性也是排查问题的重要线索。7.5 成本超预算RAG省钱的关键策略最后聊聊成本。RAG花销大头是LLM调用而LLM调用花销与上下文长度强相关。很多系统的Prompt动辄几千字其中一半是几个月都检索不到一次的冷门文档。省钱策略有三个方向。第一是减小送入LLM的内容量严格限制TopK和最大上下文长度重排后再决定哪些内容值得进Prompt。第二是做Cache对高频、重复的问题比如“怎么请假”“报销流程”可以直接缓存完整回答命中率做到30%以上就能显著降低成本。第三是分级模型策略简单问题走小模型复杂问题才上大模型通过意图分类器在前面做路由。做完这三件事成本通常能下降一半以上而且响应速度还会快很多。策划这个专栏的过程中我最大的体会是RAG系统没有银弹只有链路。每个环节都普通连起来却能解决很多看似“智能”的问题。最后再分享一个我反复踩坑后总结出的小技巧——一定要在项目一开始就建评测集哪怕只有几十条真实问题。没有评测集你做的所有“优化”都只是自我感觉良好有了评测集你才能对每一次改动有信心。RAG这条路很长希望这份策划案能帮你少走几步弯路。