如果你最近在调试大模型驱动的问答系统，肯定遇到过这类情况：模型答得自信满满，但引用的数据和资料全是你没见过的；或者你问它上周刚更新的业务规则，它只能一脸无辜地复述训练时的旧知识。问题核心不在模型智商，而在于它“记忆”里根本装不下你的私有资料。RAG（检索增强生成）就是为这件事而生的一套优化方案：先把外部知识按块切好、向量化、存进知识库，用户提问时先检索出最相关的片段，再把这些片段连同问题一起交给模型生成答案。这套思路不要求你重新训练模型，却能明显降低幻觉、补上时效性短板，是目前落地大模型应用最务实的技术路线之一。
这篇文章不打算写得太学术，我尽量按“为什么要用、原理是什么、怎么一步步搭、踩过哪些坑、还能怎么优化”的顺序，把RAG从原理到流程完整拆开。适合刚接触大模型应用开发的同学，也适合已经跑过一个简单Demo、但觉得效果不稳定、想系统排查调优的工程师。看完全文，你应该能自己说清楚RAG每个环节在干什么，以及该用什么标准判断系统好坏。
1. RAG到底在解决什么问题：先把需求捋清楚
1.1 大模型的三块短板
先回到本质：大模型再强，本质上也是一个在固定时间点完成训练的“静态知识容器”。它有三个绕不开的短板。
第一是知识有截止日期。模型训练完，世界还在继续运转，新产品发布、新政策出台、公司内部制度更新，它一概不知道。你问它某个三天前刚发生的事，它只能靠训练数据里的旧信息“猜”一个答案，猜对了是运气，猜错了就是幻觉。
第二是私有数据进不去。企业内部的合同、技术文档、客服记录、代码仓库，这些数据永远不会出现在公开训练集里。哪怕你愿意把自己的资料喂给模型，也没法保证它能在下次训练前记住，更别说数据安全和合规这些现实阻力。
第三是“幻觉”难以根除。模型本质上是在做“下一个词的概率预测”，它没有数据库那样精确回溯的能力。当某个问题超出它的知识边界，它会倾向于生成一个语法通顺、结构合理但内容错误的回答。这在大众闲聊场景还能接受，放在医疗、金融、法律、售后等场景里就是事故。
这三块短板叠加在一起，决定了“开箱即用的大模型”很难直接承担知识密度高的业务任务。RAG的出发点，就是不试图改造模型本身，而是给它外挂一个“可以随时查阅的资料库”，把答案的生成从“凭记忆”变成“查资料”。
1.2 三条优化路线怎么选
面对大模型的这些问题，业界的优化思路大体分三条路线：微调（Fine-tuning）、提示词工程（Prompt Engineering）、RAG。
微调是改造模型自身参数，让模型“学会”某种风格或特定领域的表达逻辑。它适合处理“行为风格变化”的问题，比如把模型调得更严谨、更幽默、更贴合客服话术；但它不适合承载大规模事实性知识更新，因为训练成本高、周期长，知识一变又得重新调。
提示词工程是零成本打法，通过设计更清晰的指令让模型尽量发挥出自己的知识。它对“让模型按指定格式输出”很有效，但没法解决“模型不知道这个事实”的根本问题——就像你再怎么提醒一个没看过合同的人去背诵合同条款，他背不出来还是背不出来。
RAG走的是第三条路：不改变模型参数，也不指望模型自己知道，而是把“答案素材”先检索出来，作为上下文喂给模型。这样模型从“闭卷考试”变成“开卷考试”，知识来源可控、更新即时、还能追溯到具体文档。
需要说明一点，这三条路线不是互斥的。实践中很常见的是“RAG为主 + 提示词规范输出 + 必要时用微调调整表达风格”。但如果你只想解决“答不出私有知识、爱编造事实”这类问题，RAG的投入产出比最高，这也是它成为大模型应用落地标配的原因。
1.3 RAG适合什么场景，不适合什么场景
适合的场景很明确：知识密集、答案需要依据的场景。企业知识库问答、产品使用文档助手、私有代码库检索、客服工单处理、合同条款审阅这类任务，本质都是“从一堆资料里找依据然后作答”，RAG天然匹配。
不适合的场景也需要清醒认识：如果你只是想闲聊、写诗、头脑风暴，不需要外部事实支撑，直接调模型就行，RAG反而会增加延迟和复杂度；如果你的问题高度依赖多文档联合推理、需要深度逻辑推导，比如“对比这十份合同的违约条款差异并给出谈判策略”，朴素RAG会因为上下文碎片化而表现受限，需要更高级的检索策略才可能做好。
我在实际项目里最常说的一句话是：RAG不是万能药，但它是“让模型学会查资料”的必经之路。先把这套基础链路跑通，再针对具体瓶颈做优化，比一开始就追求上复杂框架要好得多。
2. 拆开RAG的肚子：三段式核心原理
2.1 索引阶段：知识入库前的准备
RAG标准流程可以拆成三段：索引（Indexing）、检索（Retrieval）、生成（Generation）。第一阶段是把非结构化的原始文档，加工成可供快速检索的索引结构。
整个索引阶段做的事，和你给书做目录、给文件打标签是同一个逻辑。原始文档先要做格式解析，把PDF、Word、Markdown、网页里的正文内容提取出来，去掉页眉页脚、导航栏、水印这些噪音。然后按一定规则切成小块，每个块就是一个“知识片段”。接着用Embedding模型把每个文本块转成一个向量——你可以把向量理解成“一句话在语义空间里的坐标”，语义接近的句子坐标也接近。
这些向量连同原始文本、来源信息一起写入向量数据库。查询的时候，系统把用户的问题也转成向量，然后在这个向量空间里计算距离，找出“坐标最接近”的几个文本块。这里有个关键点：向量检索本质上是在做“语义近似匹配”，不是“关键字精确匹配”。它能处理“手机没法开机”和“设备无法启动”这种说法不同但意思相同的情况，这是传统全文检索很难做到的。
2.2 检索阶段：召回的思路
检索阶段发生在用户提问之后。系统要做的事可以拆成几步：生成查询向量、在向量库里找最近邻、把命中的结果取出来。
“找最近邻”听起来简单，这里面有个工程难点：数据量大了之后，不能暴力地拿查询向量跟库里每个向量算距离。在实际的向量数据库里，通常会用近似最近邻（ANN）算法，比如基于HNSW图结构的方式，把搜索范围缩小，用少量精度换大量速度。这就像你在一本厚词典里查词，不会从第一页逐页翻，而是先用索引定位到大致区域。
检索结果一般取Top-K个，也就是最相似的前K个文本块。K的选择直接影响后续效果：K太小可能漏掉关键信息，K太大则会把不相关的内容塞进上下文。常见的初值范围在4到10之间。检索打分除了向量相似度，也可以同时考虑关键词匹配，形成混合检索，这部分我放到后面的进阶章节细说。
好一点的RAG实现还会在召回之后加一个“重排”（Rerank）环节。因为向量检索返回的Top-K只是“初步候选”，它第一轮用的双塔模型速度快但精度有限，重排模型会逐一对“问题-候选文本”做精细打分，把真正有用的排到前面。这一步对最终答案质量影响很大，但很多入门Demo会忽略它。
2.3 生成阶段：模型如何组织答案
生成阶段是整个RAG链路的最后一步，也最能看出工程水平。系统把检索到的文本块拼进提示词，形成类似“请根据以下资料回答问题”的指令，连同用户问题一起发给大模型。
这里有个常见的误解：检索到相关文本，答案就一定对吗？不一定。生成阶段有两个隐蔽问题。一是“上下文污染”，如果检索回来的10个块里有三块是干扰项，模型就可能被带偏，答出资料里本来没有的内容。二是“资料矛盾”，如果库里同时存在新旧两个版本的规则，模型可能各取一半，拼出一个四不像答案。
因此，生成阶段的提示词模板设计非常关键。我常用的做法是：明确告诉模型“只能依据提供的资料回答，资料中没有的信息要直接说不知道”；要求模型在回答后列出引用了哪几个文档编号；必要时设置温度参数低一些，比如0到0.3之间，让模型更保守、更贴近资料原文。这部分不是简单的“把上下文塞进Prompt就完事”，而是决定RAG是“可靠工具”还是“高级玩具”的分水岭。
3. 从零手搭一套RAG流程：关键环节与参数
3.1 文档加载与清洗：数据质量决定了结果上限
做过几次RAG项目后，我最大的感悟是：整套系统的效果上限，早在你处理文档的第一天就定死了。团队里常流行一句话叫“垃圾进，垃圾出”，在RAG里体现得格外明显——如果原始文档格式混乱、内容重复、表格被拆得七零八落，后面检索和生成再努力都救不回来。
第一步做文档解析时，针对不同格式要有不同策略。PDF要按页面布局做解析，区分单栏双栏、识别表格和图片的位置；Word和Markdown这类半结构化文档相对友好，但要留意目录、脚注、批注这些容易被当成正文的内容；网页则需要先清洗掉HTML标签、脚本块和广告位。实操中我非常推荐先做一轮“乱码与噪音检测”，可以在入库前把编码异常、重复出现的页眉页脚、无意义的换行符批量清掉。
还要注意敏感信息处理。文档里可能包含手机号、身份证号、内部账号等数据，在索引之前就要建立脱敏流程。这不是可选项，而是工程红线。我见过不止一次因为直接把带敏感信息的原始文档灌进向量库，导致检索时被无意暴露给未授权用户的事故。
清洗完成后，最好顺手做一次“文档去重”。同一份资料可能在多个文件夹里存在不同版本，不清理的话检索系统会频繁返回重复内容，浪费上下文窗口，还会让模型一会儿看到旧规则一会儿看到新规则。基础做法是用文本哈希做完全重复检测，进阶做法是用向量相似度做近似重复检测。
3.2 分块策略：chunk size怎么定
分块是RAG里最容易被低估的环节。块太大，单块里包含太多无关信息，向量化之后的“语义重心”会被稀释，检索精度下降；块太小，语义不完整，经常出现“这块内容讲了一半，另一半在上一块”的尴尬情况，模型拿到的素材不完整，自然答不好。
我常用的经验值是：通用文档分块大小在500到800个字符左右，相邻块之间设置50到100个字符的重叠。重叠的目的很简单——如果一句话刚好被切在分界处，重叠部分能保证这句话的完整语义至少完整出现在某一个块里，不至于一句话被切成两半后两头都检索不到。
但这不是一个固定公式。代码类文档适合按函数、类、代码块来切，而不是按字数硬切；合同和法律文书最好按条款编号切；FAQ类数据本身一问一答就是一个天然完整块，强行按字数切反而破坏结构。更聪明的做法是把“固定大小切片”升级为“结构感知切片”：先用标题层级把文档切出章节树，再在章节内部做小粒度切块，最后在每块上记录所在的章节路径。这样既保证粒度合适，又保留了上下文来源信息。
分块策略的验证方法也很简单：不急着看最终答案，先随机抽几个检索query，人工检查返回的Top-K块是否完整覆盖了问题的关键信息。如果经常出现“答案信息横跨两块才能拼全”的情况，说明块切得太小或重叠不够；如果返回块里总是夹着大量不相关内容，说明块切得太大。
3.3 向量化与入库：Embedding模型和向量库怎么选
分好块之后，下一个关键决策是选Embedding模型。这件事直接决定你对“语义相近”的判断准不准。中文场景下，选择开源中文向量模型时重点看它们在语义相似度、文本分类等中文本任务上的表现，而不要只看英文榜单。另一个容易忽略的点是“查询文本与文档文本需要被同一个模型编码，且输入长度上限要足够容纳你的文本块”，否则长文档会被截断，语义信息直接丢失。
对于向量存储，选型要按你的数据量和延时需求来分：学习和小项目用轻量级嵌入式向量库就可以，文件即数据库，部署简单；数据量到百万级或需要分布式部署时，就要上独立向量数据库服务。不过对大多数企业知识库场景（几万到几十万文档块），嵌入式方案完全够用，不必一上来就引入重型组件。
入库时除了向量，还要把每块文本的原始内容、来源文档路径、更新时间、权限标签、分块编号等元数据一起存进去。这些元数据在后面的过滤检索和溯源展示中非常有用，比如按“只检索技术部文档”或“过滤掉过期版本”来做权限收紧，没有元数据支撑，这些需求都很难落地。
3.4 检索打分与重排：别只信向量相似度
最朴素的检索是纯向量相似度召回，但实际项目里我会强烈建议加上混合检索。原因很简单：向量相似度擅长“意思相近但用词不同”的匹配，但在处理人名、产品型号、订单号这类精确标识时反而不如传统的关键词匹配靠谱。比如用户输入“型号XB-2000”，向量检索可能因为词向量空间里这个型号的分布稀疏而返回一堆语义接近但型号完全不对的文本，传统倒排索引却能精准命中。
混合检索的典型做法是：向量召回和关键词召回各取一批候选，再用重排模型统一打分合并。重排模型通常是cross-encoder结构，它把问题和候选文本同时输入同一个模型，计算两者匹配的精细分数。相比第一轮检索用的双塔Embedding模型，cross-encoder精度更高，但速度慢，所以只适合在候选量不大的情况下使用，一般对Top-50的候选重排出Top-5。
打分层面还有几个细节：向量相似度指标一般用余弦相似度或内积，落地时要注意向量是否做了归一化；关键词检索通常用BM25类算法，它对词频和文档长度做了平衡。混合分数不是简单加和，而是各乘一个权重系数，系数需要拿一批标注好的问题做离线调优，而不是靠感觉拍脑袋。
3.5 生成提示词模板：把“凭感觉答”变成“按材料答”
生成环节的Prompt模板质量，决定了模型能不能克制住“炫耀知识”的冲动。我的比较模板结构大致是这样：
- 角色限定：你是知识库问答助手。
- 任务指令：严格依据下方提供的资料回答用户问题。
- 资料部分：按编号列出检索到的文本块。
- 引用要求：每条答案末尾标注引用了哪个编号的资料。
- 拒绝条件：资料中没有答案时，直接回答“资料中未找到相关内容”，禁止自行编造。
这套模板看起来简单，实操时会发现它非常考验细节。比如“严格依据资料”这句话，在不同模型上的约束力不同，有些模型会“礼貌性地遵守”，但遇到资料内容不完整时还是会脑补。我会再加一句反问：“如果资料之间存在矛盾，请指出矛盾，不要强行融合成一个答案。”这句话在知识库同时存在新旧版本时特别有用。
生成参数上，温度建议设低一些。我常用温度0.1到0.2，这能让模型更倾向复制原文而不是自由发挥。不过也别设成0，太低的温度会让模型在组织语言时显得机械，尤其在需要概括性回答的场景下反而生硬。
下面是一段不依赖具体框架的伪代码，便于你看清链路：
def rag_answer(question): question_vec = embedding_model.encode(question) candidate_chunks = vector_store.search(question_vec, top_k=50) keyword_hits = keyword_index.search(question, top_k=50) merged = merge_and_dedup(candidate_chunks, keyword_hits) top_chunks = rerank_model.rerank(question, merged, top_k=5) context = build_context(top_chunks) # 带编号 prompt = TEMPLATE.format(context=context, question=question) return llm.generate(prompt, temperature=0.1)这个流程跑通之后，你就拥有一个最简但功能完整的RAG系统，可以继续往里加缓存、权限、日志评估等能力。
4. 工具选型与方案对比：不只看热度
4.1 编排框架怎么选
现在市面上有很多RAG编排框架，可以把“加载文档、切块、向量化、检索、调用模型”这些步骤串起来，省掉不少胶水代码。我的建议是：前期调研时可以把框架当成学习参考，但真正要上生产，务必想清楚框架帮你做了什么、又限制了你什么。
一些成熟框架把常用组件做了统一封装，开发速度快，适合快速原型验证。但框架的抽象层级不一定匹配你的业务需求，比如你想在检索前做复杂的权限过滤、想在生成后做流式输出定制，可能会发现框架的内部逻辑难以灵活插入。我在生产系统里更倾向只依赖框架的文档解析和分块工具，检索和生成主链路自己在代码里显式编排，这样每一步都可观测、可干预、可替换。
选型时还要关注一件事：框架的维护活跃度与社区规模。一个正在快速迭代的开源框架，今天和三个月后的API可能完全不同，升级成本会悄悄吃掉你的开发红利。如果你做的是长期项目，尽量选择接口稳定、可扩展性好的方案，并锁定版本。
4.2 向量数据库选型参考
向量数据库的选择需要结合数据量、查询并发、部署环境来做判断，不能只看测评榜单。
第一档是轻量级嵌入式向量库。适合百万向量以下、单机部署、开发调试期的场景。它的优点是无独立服务、部署简单，数据写进本地文件即可；缺点是横向扩展能力有限，高并发和分布式能力不太行。
第二档是服务型向量数据库。适合数据量较大、需要多副本高可用、需要多语言SDK和权限控制的场景。它一般提供基于ANN索引的快速检索能力，同时也支持元数据过滤、混合检索、标量索引等功能。缺点是引入了独立组件，运维复杂度上升，成本也更高。
选型时最好有一个数据量预估。假设你有1万份文档、平均每份切成20块，那就是20万向量。这个级别用嵌入式方案压力不大。但如果你要做千万级向量的“全量知识检索”，就必须考虑服务型方案，并设计好分片策略。实践里还有一个常被忽略的指标：写入吞吐。批量导数据阶段，如果向量库写入太慢，几万份文档能倒一整天，直接影响项目节奏。
4.3 Embedding与重排模型的选择
中文Embedding模型选择，重点不是看参数越多越好，而是看它在你自己的数据分布上是否真的好用。我建议把选型当成一次小型实验：准备几百条真实业务问题，每条配上标准答案依据，然后分别用候选模型做向量化检索，看Top-K命中率。这个评测不需要太复杂，但一定比看模型卡片的理论指标更可信。
Embedding模型还有一个容易踩的坑：领域词汇的覆盖。如果是医疗、法律、工业制造这些专用术语密集的领域，通用向量模型可能压根没学好这些词，检索效果会显著下降。应对方案是优先选择在目标领域语料上继续训练过的模型，或者在采集不到更多数据时，先通过同义词扩展的方式缓解。
重排模型的选择思路不一样：重排是配对打分任务，速度和精度要平衡。生产环境如果要求用户等待时间控制在2秒以内，那么重排模型应控制在几十毫秒到上百毫秒级别，每天处理的调用量也要纳入考量。用大模型做重排（比如直接把候选文本让大模型去判断“是否相关”）精度通常很好，但成本高、时延大，更适合离线评测或对延迟不敏感的异步流程。
5. 实测中踩过的坑：问题排查与避坑指南
5.1 检索不到内容的典型原因
RAG里最常见的问题不是模型不会答，而是“该检索到的内容压根没被捞上来”。我整理过一套排查顺序，每次检索效果不对都按这个来，通常能快速定位。
先看分块是否合理。如果答案是句散落在不同块里的长描述，分块时把它切断了，向量就无法完整捕捉语义。操作上可以先直接把原始文档段落的完整文本拿来做一次“暴力检索”，也就是不经过分块，直接对整段做相似度计算，看看能不能命中。如果能命中而切块后不行，问题基本就出在分块上。
再看Embedding模型是否匹配语言。如果文档是中文，却选了以英文语料为主的模型，向量空间对中文表达的支持会很弱。中文场景一定要用针对中文优化过的模型，并且确认模型输入长度大于你的分块长度。
接着检查是否存在权限过滤或元数据过滤条件误伤。我在项目里踩过一次：给每个文档块打了部门标签，调试时忘了注入用户的部门信息，结果所有检索都被过滤成了空集，看起来像“向量库坏了”，其实是过滤条件写反了。这个问题很隐蔽，建议排查时先把过滤条件全部放开，再逐层加回去。
最后要注意query本身的写法。用户口语化的问题有时很简短，比如用户输入“退款”，但相关资料里写的是“全额退费规则”，纯向量检索可能匹配不上。这种情况需要用查询改写、同义词扩展，或者混合检索来补足。
5.2 答案质量不高的排查思路
当检索结果看起来“有一点关系但不够准”的时候，最终答案往往会出现事实性错误或内容空洞。排查思路要从下游往上游走。
先看生成Prompt里的上下文是否被污染。把实际发给模型的几条文本块打印出来，人工通读一遍，判断这些文本块是不是真的能支撑答案。很多时候问题不在模型，而在于检索回来的10个块里有7个垃圾数据，再强的模型也会被干扰。这时候可以通过重排过滤，或者减小Top-K来收敛上下文质量。
再看检索排序是否合理。有些场景下，正确答案排在候选列表的第6位，而前面5个都是高相似度但低信息量的“泛泛而谈”，Top-K取5就把正确答案拦在门外。解决手段是提高K值之后引入重排，让细节匹配度更高的块位次前提。
还要观察是否出现了“知识时效冲突”。知识库里同时存在两版规则时，模型可能选择更新但错误的版本。我的建议是在文档元数据里加上“生效日期”“版本号”，检索时如果查询涉及具体时间，就按时间过滤版本，而不是把所有版本都交给模型自行取舍。
最后也别忘了评估问题本身是否合理。有些问题需要跨多文档甚至多轮推理，比如“Project A在Q2的总支出比Q1高多少”，这要求检索至少同时召回两个季度的财务数据并且做计算。朴素RAG一次检索很难满足，需要拆解问题子步骤，分步检索。这属于进阶优化，但很多“答案不对”的真实原因，其实是问题超出了基础RAG的能力边界。
5.3 性能与成本的取舍
RAG系统上线后，性能与成本问题会逐渐浮出水面。我在几个真实项目里总结的结论是：延迟瓶颈多半不在向量检索，而在大模型生成和重排环节。
向量检索即使数据量到了几百万条，在好的ANN索引下通常也在几十毫秒级别。大模型生成才是大头：你检索再快，最终都得等模型一个字一个字吐出来。因此，在交互场景中可优先优化的是减少送入模型的内容长度、使用更快的生成参数、以及考虑对重复或相似问题进行缓存。
成本方面，最容易失控的是“为了质量无限拉大上下文”。有些人为了效果好，把Top-K加到20甚至30，结果每轮请求多消耗数千token，一个月下来API账单翻倍，但答案质量很可能并不比Top-5好多少。正确做法是固定一个合理的上下文预算，比如每个回答最多塞3000到4000字符，把质量优化重心放在“怎么筛选出更少的优质片段”而不是“塞更多片段”。
还有一个常被忽视的点：重排环节的算力成本。重排模型每天要处理的调用量如果很大，需要使用专门的推理服务或量化版本，否则延迟和开销都会成为瓶颈。做成本估算时，不要只算离线嵌入的建库成本，要把在线检索与重排的TPM（Tokens Per Minute）需求一起算进去。
6. RAG进阶方向：从能用到好用
6.1 查询改写与意图路由
用户提的问题不总是一个规范的检索语句。比如“那个订单怎么还没到啊”这种自然口语，直接拿去向量检索并不理想。查询改写的思路是：先用一个小模型对大语言模型把用户问题改写成更适合作检索的形式，比如转成“查询订单状态的方法”。改写后的query能明显提升检索命中率。
更进一步是做意图路由：先把用户问题分类，比如“售后咨询”“产品文档查询”“内部流程查询”，每类走不同的检索配置与知识库。这个设计在知识库庞杂时特别实用——如果你把所有内容塞进同一个向量库，检索结果会混杂不同领域的噪声；按意图分库后，每类问题只在自己对应的库里检索，精度和效率都更有保障。
6.2 混合检索与多路召回
前面讲过向量检索和关键词检索的结合，这里扩展一下多路召回的概念。向量召回、关键词召回、结构化元数据过滤、知识图谱查询可以并行执行，每一路都有自己的优势范围，汇总后再统一重排。
比如一个支持“查询A项目的负责人”的RAG系统，向量检索能匹配语义，但如果文档里有“项目负责人张三”的表格信息，结构化查询可以直接精确命中。多路召回的工程复杂度在于各路结果的去重与融合，但收益也很直观：让“只靠一路打通天下”的脆弱性大大降低。
在更复杂的资料体系里，还可以引入“父子分块”策略：小分块用于检索，命中后把所在章节的大分块作为上下文送入模型。这能解决“检索到的片段太碎、上下文不完整”的问题，又不牺牲检索精度。
6.3 缓存、评估与持续迭代
RAG上线之后不能只靠感觉维护，一定要建立评估指标。线上指标至少要覆盖两块：检索质量（Recall@K、MRR）和生成质量（忠实度、答案相关性、有用性）。忠实度用来衡量“生成的回答是否严格基于检索到的资料”，它比“回答是否正确”更容易自动化检测——你可以用模型判断回答中的每一个陈述是否都能在提供的资料中找到依据。
缓存策略在RAG里的价值常被低估。对高频相似问题做语义缓存，可以把大量重复请求直接从向量库和大模型计算中省掉。具体做法是保存用户query的向量与对应回答，新请求进来时先查缓存近邻，相似度超过阈值就直接返回历史答案。要注意缓存命中后的时效管理——知识内容如果更新了，缓存要及时失效。
持续迭代机制上，我强烈建议给每个线上问题记录反馈信号，比如用户是否点了“答案有用”或“重新提问”，再定期把高质量问题加入评测集，回归测试新版本的检索参数是否比旧版本更优。RAG系统的调优不是一次性工程，而是“评测集持续扩充 + 参数不断回归”的长期过程。
我个人在实际项目中的体会是，RAG做得越久，越觉得难点不在技术组件本身，而在于你对业务资料的理解深度。同一套流程，在A公司的合同库上跑得好好的，换到B公司的售后工单上可能完全失效。这说明没有放之四海皆准的参数，只有一套“按数据特征去调整检索和生成策略”的方法论。建议你从一个小型知识库入手，跑通链路，再逐步加入查询改写、混合检索、父子分块这些优化。RAG这条路没有捷径，但它每一步都有迹可循，这也是它最有魅力的地方。
