1. RAG不是“向量库Prompt”那么简单这两年RAG检索增强生成几乎成了大模型落地的标配名词只要涉及企业知识库、私有文档问答、AI客服十有八九都会提到RAG。但如果你真的动手做过一个RAG项目大概率会发现跑通demo只需要半天把效果做到能上线却要磨上几周。原因在于RAG理论上的链路是“检索-增强-生成”三个词实际落地时每一步都藏着大量细节任何一个环节偷懒最后都会被一句话的幻觉或一次检索的遗漏打回原形。RAG的全称是Retrieval-Augmented Generation核心思路并不复杂大模型没有你的业务知识那就先把相关资料查出来、拼进上下文再让模型基于这些资料作答。它的价值在于不用重新训练模型就能把外部知识注入到生成过程中并且理论上答案的来源可以被追溯。适合的场景包括企业内部制度问答、政务政策咨询、产品说明书问答、科研文献辅助阅读等等。凡是“知识是相对固定的、答案要从文档里找依据”的需求RAG都能给出一个性价比很高的解法。但这里有一个经常被忽略的真相RAG的上限取决于检索的质量而不是生成模型的能力。模型再聪明喂进去的上下文里没有正确答案它也只能一本正经地胡编。所以真正决定一个RAG系统好不好的是索引构建、查询理解、召回排序这一整条前期链路。理解了这一点再看网上各种“用LangChain三步搭好RAG”的教程你就会明白那些只是演示骨架离生产级应用还很远。这篇文章我会从理论到实践把RAG的关键环节拆开讲清楚包括文档切块、Embedding选型、多路召回、重排、查询改写、权限卡控以及Graph RAG、Agentic RAG这些进阶方向。内容主要面向两类人一类是准备用RAG做项目但还没完全理清技术选型的开发者另一类是在准备RAG相关面试题、想系统补全知识体系的同学。文章不会停留在概念层面我会把每个环节“为什么这么做”和“实际中会踩什么坑”都讲到位。提示文中涉及的配置和代码片段是通用的工程实践示例你可以直接参考但具体参数一定要结合自己的数据和场景调整不存在一套配置通吃所有RAG项目的银弹。2. 索引构建阶段切块、向量化和元数据决定了RAG的天花板很多人把一个RAG项目一上来就重点调Prompt实际上索引阶段犯的错后面再怎么调Prompt都救不回来。索引构建本身就是一门学问本阶段的核心任务是把原始文档转换成可供检索的格式并存储起来整个过程包括文档解析、清洗、切块、向量化以及元数据设计。下面我们逐个环节说清楚。2.1 文档切块固定长度、递归切分还是语义切分文档切块Chunking是RAG链路里第一个重要关卡也是面试题中经常出现的知识点。切块的核心矛盾在于块太小单个块包含的语义信息不完整检索时容易漏掉关键内容块太大向量化后的语义容易被稀释而且塞进大模型上下文后容易超出窗口限制同时回答的精确度也会下降。我见过不少RAG效果差的案例最后追根溯源都是切块策略没选对。比如直接把一份合同按固定4096字符切结果把“甲方应在收到货物后30日内付清全部款项”这样的关键条款从中间拦腰截断检索时自然匹配不上完整的付款约定。固定大小切块不是不能用但它完全不考虑文本的语义边界只适合段落结构极其规整的文档实际项目中很少能直接用。目前工程上比较稳妥的默认方案是递归字符切分Recursive Character Splitter它的思路是用一组分隔符列表比如先按段落分隔符切再按句子分隔符切再按标点切逐层递归地切割文本尽量保证每个块内部是相对完整的一句话或一个段落。LangChain和LlamaIndex里的默认文本分割器都实现了这套逻辑。相比固定长度切分它能让每个块在语义上的独立性明显更好。如果文档结构复杂且对切分质量要求高可以进一步用语义切分即利用Embedding模型对相邻句子做相似度计算相似度出现明显下降的地方就视为段落边界。这种方法在小样本测试集上表现不错但计算成本较高且需要调节相似度阈值的经验。实践中两条原则值得参考目标块大小建议在300到800字之间常见的经验值是500字左右是否需要块重叠重叠多少取决于文档内容和提问方式如果问题经常跨越段落边界推荐设置50到100字的块重叠。注意切块策略没有标准答案必须拿自己的文档做实验对比。强烈建议搭建一个小的评测集用同样的Question和标准答案去测试不同切块策略下的检索效果用数据说话而不是靠体感。2.2 Embedding模型选型通用与领域模型的差异向量化的质量取决于Embedding模型。同样是“定期存款提前支取怎么算利息”用一个在财经语料上训练过的Embedding模型去编码和用一个纯通用模型去编码检索结果往往差出一大截。Embedding模型的核心能力是“语义压缩”它把文本映射到几百维甚至上千维的向量空间语义相近的文本在空间中距离更近。选Embedding模型时主要看几个维度模型效果看它在MTEB等评测基准上的表现但更重要的是你的垂直语料效果。很多开源模型在公开榜单上分数很高放到特定行业语料上一测就明显退化。向量维度维度越高通常表达能力越强但存储和检索的计算成本也随之上来。窗口长度老一点的中文Embedding模型窗口长度只有512长文档切块后如果块超过这个长度后面部分会被截断语义丢失严重。新一代模型普遍支持到8192以上能处理的块长就灵活很多。是否支持中文优化中文语义跟英文差异很大优先选针对中文语料优化的模型。在实际项目中我会建议先用主流的国产开源Embedding模型快速跑通流程然后拿一批与你业务相关的query和文档片段做一次小规模的候选集评测根据命中率来做最终选型。模型的“好坏”不该只看榜单你的数据说了算。2.3 元数据设计来源、时间、权限与结构信息元数据在RAG中的重要性经常被低估很多入门教程压根不提。但生产级RAG系统元数据往往是解决权限问题、提高检索精度、实现答案溯源的关键。存储在向量库里的每一条文档块除了向量和原始文本还应该挂载一套元数据。常见的元数据包括来源信息文档名称、页码、章节路径、文档链接。生成答案时引用这些字段就可以实现“答案可溯源”。业务属性文件类型、所属部门、文档版本号、标签体系。便于在检索时做过滤比如只检索“质量手册”和“财务制度”。时间信息文档发布日期、生效日期、更新时间。涉及政策法规类文档时时间信息至关重要过期的制度文书不能匹配给用户当依据。权限级别密级/部门/角色等。配合检索阶段的权限过滤避免低权限用户通过RAG问答拿到不该看的内容。结构信息汇报关系、条款编号、父子节点关联Graph RAG很多能力就是基于这类信息构建的。好的元数据设计能让很多上层功能变得极其简单。例如一份政务知识库中有各级政策文件如果没对元数据中的“所属地区”做处理用户问“本市有什么人才补贴政策”系统搜出来的结果是外省政策回答自然不可用。而有了标准化的地区元数据后只需要在检索前做一次过滤问题就解决了。2.4 向量库的选型思路向量库的选型也是索引阶段的重要决定。目前市面上的选项大致分三类专门的向量数据库Milvus、Qdrant、Weaviate、Chroma、Pinecone、带向量功能的传统数据库PostgreSQL加pgvector、Elasticsearch的向量检索能力、以及云厂商托管的向量检索服务阿里云、腾讯云、AWS等都有。选型时重点看这几项指标支持的数据量级和查询QPS、过滤条件的表达能力特别是元数据过滤和权限过滤、是否支持HNSW、IVF等主流索引算法、高可用和运维复杂度、成本。我个人的习惯是非生产原型或内部工具Chroma/PGVector足以部署轻改起来快。生产级中大规模应用优先考虑Qdrant或Milvus性能和功能更接近生产要求如果团队已经重度使用ES那直接启用ES的向量检索能力也是一个务实的选项。只要数据体量不是特别大尽量少在基础设施选型上花费过多纠结把精力留到检索质量优化上这往往是项目能否按期交付的关键。3. 检索阶段多路召回与重排才是检索质量的分水岭索引构建好了下一步就是从库里把最相关的内容找出来喂给大模型。检索策略是RAG项目中调控空间最大、效果差异最明显的一环也是“多路召回”“Rerank”这些概念集中出现的环节。一个朴素的RAG系统可能只是做一次top-k向量检索然后拼Prompt但实际业务中这样的结果通常是不够用的。3.1 为什么单路向量检索永远不够纯向量检索的本质是“语义搜索”它把query编码成一个向量然后在向量空间里找最近的k个邻居。这里有一个隐形的问题Embedding模型对短文本的语义表达是偏全局的query中的关键词细粒度信息很容易被抹平。举个例子用户问“2024年上海社保公积金缴费基数上限是多少”Embedding模型会把整句话编码成一个高维向量它可能能匹配到语义相近的内容但“2024”“上海”“社保”“公积金”“上限”这些关键词在向量检索中的约束力是分散的。如果知识库里恰好有2021年和2024年多份不同城市的缴费比例文档纯向量检索很容易把2021年的文档也召回来因为它们的整体语义相似度太高了。这就是Hybrid Search在实际项目里几乎成为标配的原因。所谓混合检索通常是向量检索关键词检索BM25两条路并行召回然后再合并结果。BM25吃的是字面信息对精确匹配和术语识别非常可靠向量检索吃的是语义信息能处理“同义改写”“口语化表达”等字面不匹配的问题。两者互补召回的效果才会扎实。3.2 多路召回的具体组合方案多路召回是RAG实战中绕不开的关键词它指的不只是向量检索和BM25两条路还可以根据业务场景叠加更多召回通道。常见的组合包括普通向量召回语义主通道负责理解用户意图。稀疏向量召回BM25/全文检索关键词精确匹配专治专有名词和编号类信息。父文档召回先用小块匹配命中后把所在的父级大块返回适合处理“答案在一个大章节中但被切碎了”的情况。结构化字段过滤预先按元数据过滤一遍部门、地区、时间、文档类型而不是纯靠向量排序。例如政务场景中的地区过滤、合同场景中的合同编号过滤。同义词/别名扩展召回把query中的词做同义词扩展后一并检索对专业黑话和缩写特别有用。Graph路径召回基于知识图谱的关联路径做召回适合多跳类问题和关系密集型问题。多路召回的结果合并是关键。简单做法是把多路结果按得分归一化后混合排序更精细的做法是结合重排模型做二次排序让重排模型确定最终进上下文的顺序。路线上现在很多框架如LangChain、LlamaIndex、Haystack都有现成的多路检索模块可以直接组合。3.3 Rerank为什么是投入产出比最高的一步在做RAG的过程中我最大的感受是Rerank是在效果上投入产出比最高的一个优化步骤。前面召回的top-k结果里经常混着不少噪声单纯靠向量相似度做排序排名靠前的未必是真正能回答用户问题的片段。而Rerank模型做的事情是把query和每一个候选文档拼接起来做一次深层的交互式语义匹配输出一个相关性得分然后依据这个得分重新排序。它不再像双塔式的向量检索那样把query和文档分开编码、只比向量夹角而是让两者在模型内部“见面”能够捕捉到细粒度语义关系。Rerank的实践建议top-k召回可以放宽比如先召回50到100条候选再通过Rerank取前5到10条进上下文效果往往比直接top-k5要好。Rerank模型选型上中文场景优先选bge-reranker系列等对中文效果好的模型如果有条件用API服务也可以接入商业的Rerank接口。Rerank会带来额外的算力开销但通常可接受因为只对候选集做重排量不算大。模型推理速度如果不够可以用GPU部署或按batch推理来缓解。3.4 查询优化把用户的问题改写得更适合检索RAG系统的输入往往是一句口语化的提问“我要查一下之前那个红头文件到底怎么说的”。这句话如果直接拿去检索效果大概率很差。查询优化的目标就是把这句口语转化成一个对检索系统友好的查询。常见的查询优化技巧有查询改写让LLM把用户问句改写为更规范、更明确的关键词组合。例如“那个红头文件”改写成“《XX市关于...的通知》红头文件”。HyDEHypothetical Document Embeddings让LLM先根据用户问题假设一个答案用这个假设答案的向量去检索理论上能更贴近目标文档的语义空间。做RAG面试题时这是个高频考点实践中对其效果评价褒贬不一建议在小数据上快速试一下。多查询分解把复杂问题拆解成多个子查询分别检索完事后再合并结果。例如“2024年公积金存缴和提取有哪些新变化”可以拆成“2024年公积金存缴变化”和“2024年公积金提取变化”两个子问题。查询纠错与术语归一利用领域词典对用户输入做拼写纠错和术语标准归一加速命中精度。这些技巧的取舍取决于业务复杂度。如果知识库的问题类型比较单一把“查询改写”做好就已经能带来明显提升如果问题五花八门那多查询和HyDE这类方案才值得付出额外的token成本。4. 生成阶段Prompt组织、上下文管理与答案溯源检索完成后最后一步是把候选文档交给大模型生成答案。这一步门槛看起来最低但也有很多容易忽略的细节。真正好的RAG生成环节不是简单地把文档拼接进Prompt就完事而是需要精心设计提示模板、控制上下文长度、建立引用机制、处理“找不到答案”的情形。4.1 Prompt模板的常见写法一个合格的RAG生成Prompt至少要表达清楚三件事角色的身份和任务是什么、有哪些参考资料、回答时应遵循的约束条件。基础的模板可以这样设计你是一个专业的知识库问答助手。请基于以下参考资料回答用户的问题。 参考资料 {documents} 用户问题{query} 回答要求 1. 如果参考资料中有明确答案请直接回答并标注引用来源。 2. 如果参考资料中没有相关内容请直接回复“根据现有资料无法回答该问题”不要编造。 3. 回答时避免重复参考资料中的无关细节精炼输出。这里的“没有相关内容就直接说不知道”约束尤其重要。没有这样一条要求模型就会强行用上下文中的边角料信息编造答案输出看似合理实则错误的结论。政务类、金融类知识库对答错特别敏感这种“拒绝回答”的能力比“回答的覆盖范围”更重要。4.2 上下文管理与上下文压缩实际场景中检索回来的文档片段往往有冗余甚至彼此冲突。如果把一堆文档原封不动地塞进上下文大模型容易顾此失彼还会浪费token。这个环节称为“上下文压缩Contextual Compression”可以直接压缩或过滤掉与query无关的检索片段。LangChain里提供了ContextualCompressionRetriever组件配合LLMChainExtractor可以提取出document中与query相关的部分。上下文管理另一个关键是排序。相关度最高的内容应该尽量放在参考资料的前部因为大模型对长上下文中开头和结尾的信息记忆最牢、对中间段落容易“失焦”。这也是为什么Rerank的输出结果需要严格排序后再拼Prompt。上下文的可容纳量与模型窗口大小直接相关如果知识库文档较大往往需要将多个片段的结果按总长度裁剪。以4096窗口的模型为例参考资料部分建议控制在2000-2500字留出给模型发挥和输出的空间。4.3 答案溯源与引用设计在生产级RAG系统里答案必须能溯源否则没人敢真正相信这个系统。实现溯源的方法大致有两种一是让模型在回答时按序引用参考资料的编号二是在检索结果中记录每个文本块的来源元数据生成后做一次“引用映射”。第一种方法的Prompt写法可以是回答时在涉及事实性内容的句末标注编号例如[1][2]编号对应参考资料的顺序。生成结束后系统再根据模型输出的编号反向查找对应的元数据文档名、页号、链接渲染成可点击的引用标签。常见的RAG框架里LlamaIndex的CitationQueryEngine把这件事做得很完善如果是自研管线这部分需要自己实现但逻辑并不复杂。**政务、法律、金融等场景必须把“不输出没有出处的内容”作为系统默认行为。**宁可答不上来也不能给一个没有依据的答案。这个理念要从Prompt、Rerank策略和系统校验三个层面同时贯彻。5. 查询权限卡控与知识安全企业落地的硬门槛RAG系统在企业内部落地时最麻烦的往往不是效果问题而是权限和安全问题。如果一个普通员工通过统一的知识库问答入口能问出另一部门未公开的薪酬政策系统做得再智能化也没有价值。这里涉及的就是RAG权限卡控它是RAG工程化中最容易被遗忘、却最影响上线的环节之一。5.1 权限卡控的常见实现方案权限卡控按实现层级可以分为三种应用层过滤在检索之前先根据当前用户的身份信息部门、角色、职级生成一个过滤条件插入到向量检索的元数据过滤中。这一层是主流方案实现成本低、可控性强。例如使用pgvector查询时可以这么写SELECT * FROM documents WHERE vector_meta-department IN (行政部,人力资源部) AND vector_meta-permission_level 2 ORDER BY embedding - $1 LIMIT 10;文档级隔离如果知识库中不同人员只能查不同文档集可以在索引时就按用户维度建立独立的向量集合检索时直接查询授权范围内的集合。这个方案权限控制最彻底但存储冗余比较大。生成后校验在答案生成后做一次校验检查输出的文本中是否包含超出当前用户权限的敏感信息。这个方案需要额外的敏感信息识别能力通常作为前面方案的补充。实际项目中应用层元数据过滤是最常用的配合好的元数据体系能覆盖95%以上的权限诉求。唯一的坑是很多向量库的元数据过滤性能并不好如果权限条件复杂、标签多检索延迟会直线上升。选向量数据库时一定要拿真实的权限条件多做几轮压测。5.2 敏感信息识别与脱敏政务和企业知识库中经常含有身份证号、手机号、银行卡号、联系方式、内部通知编号等敏感信息。RAG系统如果把这些内容直接检索出来原样输出就是严重的数据泄露。做法上可以考虑在文档解析阶段预先做敏感信息识别把命中敏感规则的内容做打标并设置“该内容只有在特定权限下才能返回”也可以为涉密文档单独标记密级对超低权限用户直接不参与召回。RAG面试题中“权限卡控怎么做”是最近的高频问法面试官真正想听到的其实就是不能只靠检索返回结果而应该在元数据和检索链路层面提前做访问控制同时在生成层有脱敏兜底。5.3 政务场景与Dify平台实践的启发标题相关热词中提到了“dify 完成政务 rag 知识库的实践项目”这确实是一个典型的落地场景。政务RAG的难点除了文档格式复杂红头文件、PDF扫描件、表格、附件更核心的是权威性和合规性。普通企业内部知识库允许一定程度的模糊回答但政务问答中的答案是面向公众或体制内的正式答复半点出错都容易引发严重问题。用Dify这类低代码平台来做政务RAG优势在于开发速度快、知识库管理界面友好、可以和账号体系、审批流做集成。实践经验上政务RAG项目有几个必须守住的底线数据来源只允许指定的权威文件任何检索结果都必须能追溯到具体文件名和条款。涉及政策时效性的问题必须设置时间过滤失效政策不允许进入检索候选。涉及个人隐私的问题严格按权限体系过滤宁可不答也不越权。上线前需要准备一批标准问题集逐条做人工审核并持续迭代测试集。Dify平台本身的RAG管线是“召回-重排-生成”的标准三段式如何使用它的知识库API、如何调重排模型、如何在应用内做变量过滤官方文档都很清楚。需要特别注意的是低代码平台掩盖了细节但并不意味着细节不重要——如果你不清楚底层检索和引用的逻辑出问题时就会无从下手。别人的实践项目之所以能做成恰恰是对底层机制有足够的理解。6. 进阶方向Graph RAG、Agentic RAG与多模态RAG聊完基础RAG的工程细节再说说现在越来越常被讨论的进阶变体。这些方向的背后本质是同一个问题传统向量RAG在某些场景下不够用于是业界在探索新的范式来补足短板。6.1 传统RAG的边界在哪里传统RAG的短板集中在几处一是对全局性、总结性问题无能为力比如“这份年报中提到的所有风险因素给我汇总一下”单靠检索几个top-k片段效果很差二是多跳推理能力弱问题需要跨越多个文档或多个知识片段进行推理时传统RAG容易断链三是对实体关系理解不深比如“A公司和B公司是什么关系它们的合作对C公司有什么影响”涉及关系的回答很难通过向量检索解决。6.2 Graph RAG从向量空间走向知识图谱Graph RAG的核心思路是在文档基础上构建知识图谱把实体和关系显式地组织起来再在问答时使用图结构进行检索和推理。微软开源的GraphRAG方案影响力最大它利用LLM从文本中自动抽取实体、关系和事件构建实体关系图然后通过社区检测等方法组织索引结构。查询时既可以对局部实体做图遍历检索也可对全局性问题做社区摘要式回答。Graph RAG能很好地补足传统RAG在全局性和多跳推理上的不足。比如问“请根据上半年数据分析公司各个产品线的发展趋势”传统RAG可能抓取出一堆碎片信息而Graph RAG可以从图的全局视角出发生成有结构的回答。代价是构建成本高抽取实体和关系很费token同时图数据库的运维也有门槛。6.3 Agentic RAG把“检索”变成“决策过程”Agentic RAG是“RAGAgent”的融合形态。常规RAG是线性的query进、文档出、答案出中间没有分支。而Agentic RAG中检索的行为由智能体动态决定先检索、如果不够就改写查询再检索或者决定去调用表格查询工具、或者自己去查知识图谱可以多轮迭代。每一步用什么工具、是否终止都由LLM在推理过程中做出决策。现阶段比较常见的Agentic RAG实现有将工具调用Function Calling与RAG管线结合让模型自主决定是否检索、检索什么、检索几轮以及“路由式”的RAG系统先判断用户问题属于哪一类再路由到不同的检索管线。黑马大模型“RAG与Agent智能体实战”这类教程体系里Agentic RAG通常占据最后一章的篇幅因为它确实是在理解了基础RAG之后才能驾驭的进阶能力。Agentic RAG的优势是灵活、可以处理复杂任务缺点是延迟和token成本成倍上升同时Agent的决策不完全可控生产环境需要加更多护栏。我的建议是能用简单RAG解决的不要上Agentic只有那些确实需要多轮反思、多次调工具的场景才值得引入。6.4 多模态RAG与Ontology RAG多模态RAG解决的是“文档里不只有文字”的问题。比如一份设备维修手册里含大量图片、表格、流程图传统RAG会对图片视而不见。多模态RAG的方案大致有两条路线一是用多模态Embedding模型把图文统一编码进向量空间二是把非结构化内容图片说明、OCR结果、表格转文本先“翻译”成文本再进入常规RAG管线。第二条路线更偏工程实用主义做文本预处理的成本更低。Ontology RAG是在RAG中引入本体Ontology约束即事先定义好领域的概念体系、属性和关系再用这些约束来指导文档的解析、实体抽取和检索过程。它和Graph RAG有交叉但更强调“语义模式的显式定义”。在专业壁垒高的场景如医疗分诊、法律条款推理、装备维修预先定义一套领域本体能让RAG的实体识别和关系推理准确性显著提升。7. RAG效果评测、常见大坑与工程落地建议最后这部分聊聊怎么判断一个RAG系统究竟好不好。很多人做RAG项目靠肉眼抽查几个问题就下结论“效果不错”这样做的风险极高——抽查时看到的几个好结果掩盖了大量未覆盖的问题类型等系统一上生产用户真正的问题涌进来效果很可能立刻崩掉。7.1 RAG评测的三大指标与评估集构建RAG系统评测通常分为两大维度检索质量和生成质量。检索质量用下面几个指标衡量指标全称含义建议值Recallk前k条命中率正确文档是否出现在前k个结果中越高越好0.8算初步可用MRR平均倒数排名第一条正确结果排得多靠前0.7为宜NDCGk归一化折损累计增益综合排序质量关注趋势用于对比调优生成质量则包括忠实度Faithfulness答案是否基于给定上下文、相关性Answer Relevance回答是否切中问题、正确性和引用准确率等。现在有RAGAS这类评测框架可以调用LLM自动完成部分指标的评估。评测集的建设思路是从真实用户问题里采样50到200条覆盖高频问题、难点问题、边界问题如无答案问题、需要多文档推理的问题逐条标注期望检索到的文档和标准答案。每次修改切块策略、Embedding或Rerank配置后都跑一遍评测集对比分数这是系统化优化RAG效果的正确工作方式。7.2 我踩过的坑和最终的配置建议最后分享几个我实际做RAG项目时踩过的坑这些经验比任何理论都有参考价值。坑一过度信任默认切块参数。有次直接用了LangChain的默认递归切分chunk_size设为500结果一份技术规范文档里大量表格被拦腰切断表格内容检索不到。后来针对表格内容做了“先按表格拆分再切块”的预处理召回率直接涨了十几个点。坑二检索出来了但答错。有一个项目检索结果的相关性已经做得不错但用户反馈答案依然有错。查了半天发现是Prompt中缺少“如果资料中有相互矛盾的信息要明确指出矛盾并优先采用最新文件”的指令。加上这句话以后冲突性问题的答错率大幅下降。坑三只调Rerank不更新测试集。Rerank确实能提升排序质量但如果不持续更新评测集优化很快走到过拟合评测集的死胡同里。坑四爬得太快。在基础RAG还没做扎实的时候就想着上GraphRAG和Agent结果整个系统复杂到没法调试。后来回到基础RAG老老实实做切块、检索、重排效果反而迅速改善。配置上一个比较稳的生产参考组合是递归切分chunk_size大约500字overlap 50-100中文Embedding模型 多路召回向量BM25召回top-k设50Rerank后取前5-8Prompt明确“无法回答时直接承认、答案要带引用来源”元数据设计包含来源、时间、部门、权限级别所有模型接口做超时和失败降级处理。RAG本身的技术含量不在创意层面而在于工程细节。真正把每个环节做扎实效果自然会上来。如果你准备面试上面的这些点基本覆盖了高频考点如果你正准备做项目我建议按这个路径走一遍——从最小可用版本出发先做评测集再逐环节调优最后根据需求再上Graph或者Agent这些进阶方案这是目前最稳妥的落地姿势。