1. 我在 Agent 实战中最离不开的一个设计模式
做智能体（Agent）开发这两年多，我迭代过好几版带记忆能力的系统。最初，我图省事，直接把对话历史整个塞进上下文窗口，用长文本硬扛；后来，上下文一长，响应延迟和成本都变得很难看，模型也经常“捡了芝麻丢西瓜”，对早先出现的关键事实视而不见。直到我把知识检索（RAG，Retrieval-Augmented Generation）纳入了 Agent 的记忆增强体系，才算是找到了一个兼顾准确率、实时性和可控性的解法。
简单来说，RAG 就是让模型在开口之前，先从一个外部知识库中捞取和当前问题最相关的片段，然后把这些片段连同原始问题一起交给生成模型。它不改变模型本身的参数，而是通过“外挂知识”的方式，让模型回答问题时能查资料、能引出处，极大缓解了幻觉问题。对于要做客服问答、私有知识库、实时资讯分析的 Agent 来说，这条路线基本是必选项。
这篇文章会把我实际搭建 RAG 链路时拆过的零件、踩过的坑、调过的参都整理出来，从基础概念一路讲到检索优化和前沿方向。不管你是刚接触 Agent 的新手，还是已经跑通了一套流程但想进一步提升效果的老手，都可以在对应部分找到能直接落地的经验。
2. 为什么 Agent 必须补上“记忆增强”这一课
2.1 模型再强，也逃不过三个死穴
大语言模型虽然能写出流利的回答，但它的知识本质上是训练时凝固下来的快照。我把它总结成三个绕不开的问题：
一是知识陈旧。训练数据有截止日期，模型不知道之后发生的事。你问它某款产品的最新价格、某项政策的最新调整，它大概率会给出过时信息，或者干脆用训练样本里的常见答案“编”一个出来。
二是专有知识缺失。企业内部的操作手册、个人笔记、小众领域的研究报告，这些内容根本不在模型训练语料里。让模型直接回答，它只能靠泛化能力“猜”，猜得准是运气，猜不准才是常态。
三是信息混淆。当知识库很大、并且很多文档内容相似时，让模型凭参数记忆去回答，非常容易把不同来源的信息交织在一起，产生事实性错误。这一点在同一个问题涉及多个产品线、多个版本时尤为致命。
2.2 长期记忆、短期记忆与知识检索的分工
在 Agent 系统里，我们经常把记忆分成几层：会话内的短期记忆，跨会话的长期记忆，以及静态或半静态的知识库。RAG 解决的是“世界知识与专有知识”的读取问题，它和记忆之间的关系，我习惯用一个比喻来理解。
短期记忆像便利贴，随手记下当前任务的要点，用完就撕；长期记忆像笔记本，记录用户偏好、历史决策，跨会话复用；而 RAG 更像一个随取随用的图书馆。图书馆里的书不是靠背诵记住的，而是通过索引找到的。模型不需要把整本书装进脑子里，只需要知道“这本书放在哪个书架、翻到哪一页”。这样既不占用宝贵的上下文窗口，又能保证知识的完整性和新版本的可替换性。
在实际架构中，我会把 RAG 检索到的内容当作“临时记忆块”动态注入到 Prompt 中，和用户输入一起交给模型。这样一来，每次回答都像是在开卷考试，模型能看到资料再答题，准确率自然要比闭卷硬答高出一截。
2.3 什么时候该用 RAG，什么时候不该用
RAG 不是银弹。如果问题本身需要模型发挥创造力，比如头脑风暴、生成故事，引入检索反而可能限制想象的广度。如果知识库很小，小到只有几十条规则，直接写死在 Prompt 里更简单高效。如果知识更新极快、每秒都有新内容，传统的离线索引流程可能跟不上，还需要叠加实时写入通道。
我的决策标准很简单：凡是回答需要依赖“具体事实”的场景，优先考虑 RAG；凡是回答主要依赖“推理能力”或“通用常识”的场景，直接用模型原生的能力即可。把两者结合，也就是让 RAG 负责喂料、模型负责思考，往往能获得最佳效果。
3. 核心设计拆解：一条完整的 RAG 链路长什么样
3.1 从文档到知识的“切碎”艺术
整个 RAG 链路的第一步，是把原始文档处理成模型能有效利用的形态。这里最容易犯的错误，是直接把一个几万字的 PDF 整篇扔进去。且不说向量化模型对输入长度有限制，就算塞得进去，检索时也会因为“命中范围过大”而找不到精确答案。
我常用的做法是分两步走。第一步，把文档按结构切块，比如按标题、段落、表格单元切分。第二步，再根据语义完整性和块大小限制做二次合并。
切块参数里有三个关键值：块大小（chunk size）、块重叠（overlap）和最大块数。块大小决定了每次检索返回多少内容。我一般从 300 到 800 个 token 起步。这个量级，既能装下一个完整的论点，又不会因为太长而阻塞上下文。
块重叠是为了防止“正好从中间切断一句话”导致语义断裂。比如你设置了 500 token 的块大小和 50 token 的重叠，那么下一块的开始部分会和上一块的结尾部分有 50 token 是重复的。这样一来，关键信息即使恰好在切割边界附近，也能在相邻块里找到。
我在实践中还会用到结构化切分。对于技术文档，先解析 Markdown 标题层级，保证每个块内包含完整的小节内容；对于表格类数据，最好把每一行转成“字段名:值”的文本再切，不然向量检索对表格的理解往往很差。
3.2 向量化：把文字变成可计算的距离
切好的文本块，需要经过嵌入模型转换成一串浮点向量。向量化的核心目标是让“语义相近”的文本在向量空间中的距离也相近。这样，用户查询和知识库片段在语义层面的相似度，就可以用余弦相似度或内积来计算。
选择嵌入模型时，我主要看三个指标：中文/领域语料的表现、向量维度、以及推理速度。目前常见的方案里，有的模型在通用中英文上表现均衡，有的在代码或法律等垂直领域做了额外训练。同一份知识库，用不同的嵌入模型索引出来的检索效果差异可能非常明显，所以不要只看模型榜单上的总分数，最好用你自己的领域数据做一次冒烟测试。
有一条要注意的细节：嵌入模型对文本的长度有容忍度，但过长的输入可能导致信息被平均化，重要细节被稀释。这也是为什么 3.1 节里的分块策略如此重要。好的分块让向量化模型能把注意力集中在单一主题上，表示出来的向量才更有区分度。
3.3 索引与存储：检索速度的基石
向量算出之后，需要一个专门的向量数据库来存储和检索。我比较常用的是支持混合检索的方案，也就是既能做向量相似度搜索，也能做关键词全文检索。
向量数据库的核心数据结构是 ANN（近似最近邻）索引。它牺牲了一点点精度，换来极高的检索速度，使百万级向量的毫秒级搜索成为可能。常见的索引类型有 HNSW、IVF 等。HNSW 是我用得最多的，它对高维向量的召回率和延迟平衡得比较好。
索引参数里，M 值（每个节点的最大连接数）影响召回率和内存占用，efConstruction 影响构建时间，efSearch 影响查询精度。一般来说，M 设为 16 到 32，efConstruction 设为 200 左右，efSearch 在查询时设置为 top_k 的 10 到 20 倍，就能获得不错的基线效果。
提示：在生产环境里，不要只建向量索引，一定要把原文块也存进数据库。检索时除了返回向量、距离分数，还要返回 text 字段，否则生成阶段无米下锅。
我在很多项目里还会加一层倒排索引，用于关键词精确匹配。比如用户搜索一个产品型号“XK-200”，这个型号是专有名词，向量检索可能把它和“XK-300”混在一起，但关键词检索能精确定位。把两种检索结果做融合（RRF 或加权合并），能显著提升实际效果。
3.4 检索、重排与生成的最后冲刺
检索本身不是终点。query 经过向量化，在索引里取回 top_k 个候选片段后，通常还需要一层“精排”。我习惯把召回阶段设置得宽一些，比如取回 20 到 50 个候选，然后用一个更强的模型做重排序，只保留最相关的 5 到 8 个片段进入生成阶段。
重排模型和嵌入模型的区别，也解释了为什么两段式方案效果更好。嵌入模型要兼顾速度和泛化，把整个知识库尽快编码进来，语义分辨率相对有限；重排模型只处理少量候选对，可以用交叉编码器的方式，让查询和文档逐 token 交互，捕捉到更细粒度的相关性。在召回率已经很高的情况下，重排模型能有效把“貌似相关但答非所问”的内容剔除出去。
生成阶段的 Prompt 设计也有讲究。我会在系统提示词里明确告诉模型：只依据提供的资料回答，不要添加资料之外的信息；如果资料不足以回答问题，就如实说“根据现有资料无法回答”。在实践中，加上这一句“拒答指令”，比单纯堆资料更能遏制幻觉。因为模型在训练中习惯尽量迎合用户提问，只有用明确的约束打断这种惯性，它才会“诚实地说不知道”。
另外，每个片段都要带上来源标记。我会在传给模型的文本前加上 [1]、[2] 这样的编号，然后让模型回答时在句子末尾用 [1] 标注依据来源。这样下游展示阶段可以直接渲染成引用角标，用户也能一眼看到答案来自哪份文档。这一设计对建立信任感很有帮助。
4. 实操环节：手把手搭一个可用的 RAG 链路
4.1 环境选型与基础依赖
先说结论，我目前比较顺手的一套组合是：Python 做胶水语言，LangChain 或 LlamaIndex 做流程编排，向量库用 Milvus 或 Qdrant，嵌入模型用开源的中文向量模型，生成模型接 GPT 接口或本地部署的开源模型。
如果你只是想快速验证效果，可以先不用引入太重的基础设施。用内存型的向量存储（如 Chroma）加一个开源嵌入模型，几百行代码就能跑通一个 Demo。
我建议把重要组件列成一个清单，方便后续排查：
- 文档加载器：适配 PDF、Markdown、Word、HTML 等多种格式
- 文本切分器：递归字符切分或语义切分
- 嵌入模型：提供文本转向量的能力
- 向量数据库：负责存储和相似度检索
- 重排模型：对召回的候选片段做精排
- 大模型服务：负责最终答案生成
4.2 数据清洗：决定了你 RAG 效果的天花板
很多人一开始把精力全放在调 Prompt 和选模型上，但我几次实战下来，发现数据清洗的优先级其实是最高的。数据里如果全是噪声，后面所有环节都是在浪费时间。
我处理过的数据源里有不少文档是从 PDF 或网页直接转出来的，夹杂着页眉页脚、导航栏、乱码字符、重复段落。这些噪声被切块后，要么污染向量表示，要么被检索出来后让模型“答非所问”。我处理这类文本时，会先用正则把纯噪声行删掉，再做一次段落去重。去重可以采用简单的方法：按文本哈希值去重，或者用相似度阈值去掉几乎一样的段落。
还有一种隐蔽的噪声是“冗余表述”。有些文档的每一章末尾都会重复一遍免责声明。如果小标题本身能代表章节含义，我会在清洗阶段把这些重复段落从每个文件里删除，只保留一条记录。否则检索某个问题时，会同时召回五六个内容完全一样的片段，浪费上下文窗口。
4.3 入库流程：从原始文档到可检索索引
整个入库流程，我把它设计成四个阶段，每个阶段都有对应的检查和日志输出。
第一阶段是解析与提取。读取原始文件，输出纯文本和结构化元数据。这里我会保留文档标题、页码、章节路径，后续检索返回时可以直接展示给用户。
第二阶段是清洗与切分。按 3.1 节的方法设置块大小和重叠，同时过滤掉空块和过短的碎片。我设置块大小的经验值是：短文档用 300 token，长文档用 600 token。长文档块太大时，可以配合 overlap 防止上下文断裂。切分完之后，我会统计每块的长度分布，如果某块特别长或特别短，意味着切分策略可能需要调整。
第三阶段是向量化与入库。用嵌入模型把每个块编码成向量，连同原文和元数据一起写入向量数据库。这一步要注意批量大小，不要把成千上万个块一次性压给嵌入模型，否则容易触发接口限流或者显卡内存溢出。我一般是每批 64 个块。
第四阶段是索引验证。入库完成后，我会拿几个典型的 query 做一次检索测试，看看排在前面的片段是不是直觉上最相关的那几段。这个冒烟测试不通过，我就不会进入下一步。
4.4 查询流程：检索增强的完整调用链
查询阶段的完整调用链，我在代码里是这样组织的：
def answer(query: str): # 1. 生成查询向量 query_vec = embed_model.encode(query) # 2. 向量检索 + 关键词检索（混合召回） vector_hits = vector_db.search(query_vec, top_k=30) keyword_hits = vector_db.search_keywords(query, top_k=30) # 3. 融合排序（RRF） fused_hits = reciprocal_rank_fusion([vector_hits, keyword_hits]) # 4. 重排精筛 reranked = rerank_model.rerank(query, fused_hits[:20]) final_contexts = reranked[:6] # 5. 组装 Prompt context_text = "\n\n".join( f"[{i+1}] {item.text}" for i, item in enumerate(final_contexts) ) prompt = build_prompt(query, context_text) # 6. 生成回答 return llm.chat(prompt), [c.source for c in final_contexts]如果你用的是 LlamaIndex，它自带的 QueryEngine 已经把前面这几步封装好了。但我建议至少手动实现一次重排整合流程，因为理解每一步的输入输出，后面调优时你才知道该把力气花在哪一环。
在 Prompt 组装时，有一件事非常关键：上下文的先后顺序。我会把和问题最相关的片段放最前面，次相关的放后面。模型在长上下文里对开头和结尾的内容关注度更高，排在中间的容易被忽略。所以按相关度降序排列并不是形式主义，而是实打实影响效果的细节。
提示：不要把检索到的所有内容全塞进 Prompt。宁可只保留 4 到 6 个高相关片段，也不要为了“看起来全面”而堆砌 15 个片段。上下文越长，模型对单个片段的注意力权重就越低，反而会降低答案质量。
5. 效果调优：检索质量上不去，问题多半出在这里
5.1 三个高速排查方向
当我发现一个 RAG 问答系统的回答质量不理想时，我不会急着调模型 Prompt，而是先判断问题出在哪个环节。我把排查路径分成三个方向。
第一个方向，问题是“找不到”还是“找不准”。如果检索返回的片段里压根没有正确答案，那就是召回阶段的失败。我会检查嵌入模型是否适合当前领域，检查分块是否过大或过小，检查 query 是否需要改写。
第二个方向，问题是“找不准”还是“排不对”。如果正确片段在召回列表里，但排名很靠后，那可能是向量检索本身不够敏 感，也可能是重排模型没有发挥应有作用。这时候我会把重排前后的 top_k 列表打出来对比，看正确片段是否在重排后掉出了窗口。
第三个方向，问题和资料的“边界”是否清楚。如果资料里没有完整答案，模型靠常识补齐了信息，这种回答在表面上很流畅，但经不起考证。解决思路是缩小检索范围、增加拒答约束，或者在 Prompt 里强调“只能依据资料”。
5.2 Query 改写：容易被忽视的提效点
用户实际的提问方式，和知识库里的文档表达方式经常对不上。用户问“这个套餐怎么收费”，文档里写的是“资费标准”，两者在语义上相关，但向量相似度不一定很高。
一个有效手段是让模型对用户 query 做一次改写。比如把口语化问题改写成更正式的检索式查询，或者把历史对话中的代词还原成完整名词。我试过一个场景：用户先问“帮我看看 A 产品的参数”，接着追问“它支持无线吗”，如果不改写，“它”就会被向量化成一个没有实际意义的 token。先把“它支持无线吗”改写为“A 产品支持无线连接吗”，检索效果立刻提升了一个档次。
Query 改写可以单独调用一次大模型接口，也可以在生成答案的同一次调用里顺便输出改写结果。前者延迟更高但更可控，后者省时间但实现复杂一些。我一般选择独立改写，并且把改写后的 query 记进日志，方便回溯分析。
5.3 混合检索与 RRF 融合的实操参数
混合检索，是指把向量语义检索和关键词 BM25 检索的结果合并。合并策略我用得最多的是倒数排名融合（RRF），它的公式简单且不用调权重：
score(d) = Σ 1 / (k + rank(d))其中 k 一般取 60。每个文档在每种检索结果里都有一个排名，把排名代入公式求和，得出最终分数。这样做的好处是，一个只在向量检索里排第 5、在关键词里排第 50 的文档，能得到一个相对较高的总分；而一个只在向量检索里排第 1、在关键词里根本没出现的文档，分数也不会过低。它让两种检索方式的结果能公平地“投票”。
如果知识库里有大量专业术语、型号编码，混合检索几乎是必须的。纯向量检索对生僻词的匹配能力偏弱，纯关键词检索又无法处理同义改写。把两者融合后，互补效果非常明显。
5.4 评估指标与回归测试
优化 RAG 系统最怕的就是“凭感觉”。我一开始也是靠眼睛看几个例子就下结论，后来发现同一处修改，往往在这个 query 上变好了，在那个 query 上变差了。因此，搭建一个最小评估集非常必要。
我的做法是准备 30 到 50 条测试 query，每条预先标注好“期望命中的文档片段”。每次改动之后，跑一遍全量测试集，统计三个指标：
- 召回率：期望片段是否出现在检索结果的前 N 位中
- 命中率：最终生成答案是否包含了正确答案
- 拒答率：对于资料中确实没有答案的问题，模型是否正确拒答
这个测试集会随着迭代逐渐扩充。新发现的 bad case 会追加进去，防止同一个问题复发。只要把这套流程跑起来，RAG 的优化就不再是玄学，而是一个可量化的迭代过程。
6. 常见问题与排查技巧实录
6.1 检索结果相关但回答跑偏
这是我最常遇到的一类问题。检索返回的片段确实是知识库里和问题最相似的，但看具体内容，只覆盖了问题的一半，另一半信息在另一个片段里。模型拿到这些片段后，可能只看到了前半段，就用泛化能力补齐了后半段，结果补错了。
排查时，我第一件事是检查“召回完整度”——把检索到的 top 20 片段全部打印出来，看是否包含问题的各个子方面。如果发现正确答案在第 18 位，说明候选窗口太小，或者重排模型把正确片段压到了后面。解决方法是调大召回数量（比如从 20 提到 50）、调大重排候选数，并且检查重排模型是否在领域数据上表现不佳。
6.2 回答不引用来源，或者乱引用
严格来说，引用来源靠的是 Prompt 约束，不是靠模型“自觉”。如果模型输出的内容没带 [1] 标记，先检查 Prompt 里的指令是否足够明确。我试过的最有效写法是：“回答每一句话时，如果它依据了提供的资料，就在句末添加对应编号；如果一句话综合了多个片段的信息，就同时标出多个编号。”
还有一种情况是模型“一本正经地编引用”——它引用了 [2]，但 [2] 里根本没有那句话。这往往是 Prompt 里上下文顺序太乱，或者片段本身太相似。我会把重排后的片段逐一检查，确认标号对应关系，再考虑是否要降低上下文长度。
6.3 响应延迟过高，怎么优化
RAG 链路比普通模型调用多出了好几个环节，延迟很容易翻倍。我按下单顺序排查：
首先是“检索延迟”。向量数据库索引参数没调好时，百万级数据检索也可能耗时几百毫秒。把 efSearch 调低、使用 GPU 加速的索引版本、为高频查询加缓存，都能改善。
其次是“重排延迟”。重排模型如果是一个大号的交叉编码器，在 CPU 上跑得很慢。解决办法是：把重排模型置换成小一号的蒸馏版本，或直接把重排候选数从 20 降到 10。
最后是“生成延迟”。生成阶段对上下文长度最敏感。如果你塞了十几个片段，每个片段 500 token，那光是输入就有七八千 token，生成速度当然慢。解决方法是减少片段数量、对片段做关键句提取，或使用流式输出来掩盖部分延迟。
6.4 常见问题速查表
| 现象 | 可能原因 | 优先排查项 |
|---|---|---|
| 检索不到正确答案 | 分块过大/过小，嵌入模型不匹配 | 打印召回 top 20，检查候选位置 |
| 答案前后矛盾 | 上下文里片段互相冲突 | 检查片段来源，增加冲突消解指令 |
| 该拒答的不拒答 | 模型受训练惯性影响 | 在 Prompt 中加显式拒答指令 |
| 引用乱标 | 片段边界不清 | 统一片段编号，重排后验证对应关系 |
| 检索结果老旧 | 知识库未及时更新 | 检查索引更新流水线、增量入库逻辑 |
| 长文档效果差 | 切分丢失上下文 | 尝试父子分块，子块检索、父块生成 |
7. 从基础到前沿：下一代知识增强思路
7.1 长上下文时代，RAG 会被淘汰吗
随着大模型的上下文窗口越来越长，一度有人提出“把整个知识库塞进上下文”的激进方案。我的看法是，在短期内，RAG 不会被淘汰。
原因有三。第一，成本问题。把百万 token 的文档全部放入一次请求，成本是按 token 计费的，价格高得难以接受。第二，注意力稀释问题。即使模型能“看到”一百万 token，它对每个 token 的关注度也是有限的，重要细节很可能淹没在海量文本中。RAG 的精髓正是“聚焦”——只把最相关的几段挑出来，让模型看到的是精华中的精华。第三，可审计性问题。RAG 的回答有明确资料出处，方便做溯源和合规审查。长上下文方案在这方面的可控性要差得多。
7.2 知识图谱增强：从“找片段”到“找关系”
传统 RAG 把知识当作一个个独立的文本块，但现实中的知识是彼此关联的。比如一个产品的参数变更，可能牵动多个文档里的描述。片段级别的检索很难把这种跨文档的关联信息聚合起来。
GraphRAG 的思路，是先把文档解析成实体和关系，构建成知识图谱，再在查询时先从图谱中找到相关实体及周边关系，再回溯到对应的文本片段。我在一个产品知识库项目里试过这个思路，对于“A 功能会影响哪些模块”这类关系型问题，效果比纯向量检索好一大截。
当然，知识图谱的构建成本也不低，需要命名实体识别、关系抽取等 NLP 组件，对长尾实体和复杂关系的处理也有不少工程细节。如果只是做简单的文档问答，传统 RAG 已经够用；但如果你面对的是结构复杂、强关联性的领域知识库，GraphRAG 值得投入。
7.3 Agent 化 RAG：让检索成为可调用的工具
我最近在尝试的一个方向，是把 RAG 从“单次检索”升级为“Agent 可调用的工具”。在这个设计里，Agent 可以自主决定要不要检索、检索几次、用什么关键词检索，甚至可以根据第一次检索的结果，调整查询词后再次检索。
这种 Agentic RAG 的好处是能应对复杂问题。比如用户问“对比一下我们公司和竞争对手的售后政策”，传统 RAG 一次检索只能捞到一个主题的片段，而 Agent 化的 RAG 可以分别检索“我们公司的售后政策”“竞争对手公司的售后政策”，再把两组结果分别整理，最后汇总对比。
实现这个能力，需要在系统里加入一个决策模块——通常就是一个带工具调用能力的大模型，让它能看到检索工具的说明和调用格式。这一步的复杂度比传统 RAG 高不少，但也是我认为最能发挥智能体优势的方向。
7.4 数据更新与增量索引：知识保鲜的关键
知识库不是建好就不动了。在实际场景里，文档经常会更新：旧的版本要作废，新的版本要入库。如果更新策略不严谨，检索到的还是几天前的旧知识，那 RAG 的全部优势就打了折扣。
我的做法是给每个文档块加上“版本号”和“生效时间”。库里的文档更新时，不是删除后重建，而是把旧版块标记为失效，新块带新的版本号入库。查询时默认只检索当前生效的版本。对于有时效性的内容，比如政策条款，我还会在元数据里加上生效日期范围，检索时用过滤器把已过期的文档排除。
增量索引要注意一个问题：同一文档更新后，旧版块的向量应该从索引中删除，否则检索时会同时召回旧版和新版，模型将无所适从。目前多数向量数据库支持按元数据过滤删除，操作时我会先删掉旧版本关联的全部块，再写入新块。
8. 我踩过的几个坑，希望你少走弯路
写到这里，我想把几个印象最深的踩坑记录整理出来。这些东西，文档里很少会写，只有做到一定深度才会碰到。
第一，向量模型和检索场景不匹配导致的“全面平庸”。我之前在一个中文客服系统里用了某个英文表现很好的嵌入模型，结果中文查询的召回质量很差。后来换成了针对中文语料优化的模型，同样的索引参数，效果立竿见影。后来我形成了一个习惯：不管模型榜单多高，先用自己领域的 20 条典型问题做离线验证。
第二，小切块在长文档场景下的失效。一开始我把切块调得很小，觉得这样检索更精确。但对一些需要完整上下文才能回答的问题，比如“这段代码的作用是什么”，小块里只有代码片段没有上下文说明，模型根本答不对。后来我采用了“父子分块”策略：小切块用于检索，命中小块后，再把它所属的父级大块检索出来作为上下文。效果好了不少。
第三，重排模型不是越大越好。重排环节虽然提升精准度，但也增加了延迟。我试过一个很重的重排模型，确实把 top 5 准确率拉高了很多，但每次查询多了两秒多延迟，产品侧完全无法接受。后来换成了一个小型蒸馏模型，准确率只降了一点点，延迟却降了 70%。做技术选型时，一定要把“端到端延迟”当作一个核心指标来考量。
第四，不要忽略元数据过滤的价值。向量检索是一个“按相似度排序”的过程，它不懂“时间”“类型”“权限”这些约束。如果知识库里有多个部门、多种密级的文档，必须在检索之前用元数据过滤器把权限范围外的内容排除掉，而不是依赖向量相似度去判断。这一点在落地到企业内部知识库时尤其重要。
第五，日志里一定要记录每一条查询的检索片段和分数。我早期没有留这些日志，等到用户反馈“某条回答很奇怪”时，想复盘是哪一步出了问题，却发现完全没有数据。后来我把每个 query 的召回片段、排序分数、最终上下文都结构化地写入日志。排查问题的效率提升了一个量级。
我个人对 RAG 的一句话总结是：它拉近了模型知识与真实世界的距离，但真正决定效果的，还是数据质量和工程细节。文本清洗、分块、召回、融合、重排、生成，每一个环节都值得认真对待。这套链路里没有那么多神秘魔法，只要你愿意一步步排查和调优，最终都能得到一个稳定可信的知识增强系统。
