经常有人在群里问：DeepSeek 明明那么强，为什么问它“我们公司上季度那份合同模板在哪”，它只会说“我没有权限访问你的本地文件”？这个问题背后，其实就是 AI Agent 和 RAG 的关系。DeepSeek 这类模型属于 LLM，它懂知识、会推理，但它的“记忆”停留在训练数据截止那一刻，无法感知你本地 ERP 里的产品清单、你团队 Wiki 里的流程规范、你数据库里刚更新的工单状态。要让 LLM 变成能干活、会查资料的 AI Agent，就必须给它接上一条“知识获取管道”——这就是 RAG。
RAG，Retrieval-Augmented Generation，检索增强生成。字面意思很直白：先检索，再生成。先把你私有的、动态的知识切片、向量化、存进一个可查询的索引，等用户提问时，先把问题拿去检索最相关的片段，再把“问题+检索结果”一起塞给 LLM，让模型基于这些材料回答。作为这个系列的第四篇，这一篇专门拆 RAG：它是什么、为什么 Agent 离不开它、怎么从 0 到 1 搭一套本地可用的版本、以及那些文档里不会写的高频坑。
这篇内容适合正在学 AI Agent 的开发者，也适合团队里负责给 Agent 接知识库的产品、后端同学。我不会只讲概念，会把索引构建、切片策略、Embedding 选型、检索阈值、多轮对话这些直接决定效果的技术点全部落到可操作层面，保证你看完能自己动手跑通一个最小闭环。
1. 为什么 Agent 的知识底座绕不开 RAG
1.1 AI Agent、LLM 和 RAG 到底是什么关系
先把三个概念对齐，因为热词里排前面的永远是“agent 和 llm 和 ai模型 有什么区别”。一句话版本：AI 模型是大脑，LLM 是大脑里最有文化的那部分，Agent 是给大脑装上了眼睛、手和行动力，而 RAG 是大脑外接的“图书馆检索员”。
更准确一点说，AI 模型是个大类，包括传统机器学习模型、深度学习模型、生成式模型；LLM 是其中以 Transformer 架构为基础、在海量文本上预训练出来的大语言模型，比如 GPT 系列、DeepSeek、Qwen、Llama，它们的特点是能理解并生成自然语言。AI Agent 则是一个“感知-决策-执行”闭环系统，它用 LLM 做推理中枢，同时通过工具（Tool）调用外部 API、通过 RAG 读取私有知识、通过记忆模块维护对话上下文，最终自主完成任务。也就是说，LLM 只是 Agent 里的一个组件，而 RAG 又是 Agent 知识管道里的核心组件。
很多人把 RAG 当成一个可选的“锦上添花”，这是个误解。实际在 Agent 落地时，RAG 往往是第一个要解决的工程问题。原因很朴素：Agent 最强的能力是“知道何时该用什么工具”，但它如果没有知识底座，连“该用什么”都判断不准。比如一个客服 Agent，它要知道退货政策才能决定是直接回答还是调售后接口；一个数据分析 Agent，它要知道表结构才能生成正确的 SQL。没有 RAG，这些私有知识一概进不了模型的视野。
1.2 模型再强也有三个硬伤，RAG 是当前最务实的解法
LLM 本身有三大硬伤，决定了你不能光靠“调一个更强的模型”来解决 Agent 的落地问题。
第一是知识时效性。所有预训练模型的知识都有截止日期，不可能知道昨天刚发布的公告、今天刚改的流程。第二是私有不可见。企业内部知识不在公开语料里，你没训练过就是没训练过，强行回答只会胡说。第三是幻觉问题。能力越强的模型越容易一本正经地编造答案，在缺少事实依据时，它宁可“脑补”也不说不知道。
针对这三个硬伤，有两条主流路线：微调（Fine-tuning）和 RAG。微调相当于给模型“补课”，把新知识固化进权重，代价是每次数据一变都要重新训练，成本高、周期长、还有灾难性遗忘风险。RAG 相当于给模型配一个“可以随时翻的笔记本”，知识存在外部数据库里，想去哪查就去哪查，更新知识只需要更新数据库，不碰模型本身。
对比下来，两者其实不是竞争关系，但在大多数业务场景下，RAG 是性价比更高、迭代更快的那条路。微调更适合“让模型学会某种表达风格、稳定输出特定格式”这类知识之外的能力塑造，而知识的获取和更新，RAG 天然更合适。这也是为什么现在凡是做 AI Agent 的产品，几乎清一色都带了 RAG 能力。
| 维度 | RAG | 微调 |
|---|---|---|
| 更新成本 | 低，改索引即可 | 高，需重新训练 |
| 知识时效 | 实时同步 | 依赖训练周期 |
| 幻觉控制 | 可引用来源，较好 | 无法溯源 |
| 技术门槛 | 中等，偏工程 | 高，偏算法 |
| 适用场景 | 私有知识、动态信息 | 风格迁移、输出约束 |
1.3 一套 Agent 的组成结构里，RAG 属于哪一块
我把这个系列前面几篇多次提过的 Agent 组成结构再拿过来对照一下，方便你定位 RAG 的位置。一套完整的 AI Agent 通常包含：
- 模型层：主 LLM 和辅助小模型（如埋点模型、摘要模型）
- 记忆层：短期对话记忆和长期知识记忆，长期记忆就是 RAG 的用武之地
- 工具层：Function Calling、API、代码解释器、浏览器等
- 编排层：Agent 的主循环，负责规划、决策、反思
- 知识管道：承载外部知识输入，即 RAG 系统
RAG 在 Agent 里最典型的用法有两种。一种是“查资料再作答”，Agent 在推理过程中判断用户问题需要特定知识，于是触发检索，把检索结果和问题统一交给 LLM 生成最终答案。另一种是“人设背景注入”，系统在构建提示词时就把 RAG 检索到的结构化知识放进 Context，让 Agent 始终保持一致的领域口径。
这两种用法的共同点是：RAG 的输出不是一个最终答案，而是一组“参考资料”。它像给 Agent 配备的一个实时情报员，Agent 拿到情报后再自己决定怎么说、怎么做。这也是 RAG 和单纯的“知识库问答系统”之间的本质区别——前者是组件，后者是产品。
2. RAG 核心链路拆解：索引和检索
2.1 RAG 的经典四步：切片、向量化、存储、检索生成
把 RAG 拆开看，其实就四步：加载与切块、Embedding 向量化、向量索引存储、检索并生成回答。每一步都有讲究，任何一个环节做得粗糙，最终效果都会肉眼可见地打折。
加载与切块（Load & Split）是把 PDF、Word、Markdown、HTML 等格式的文档解析成纯文本，再按一定策略切成小块。这一步的产出叫作 Chunk，是后续向量化的基本单位。切块看似简单，实则是 RAG 工程里最影响效果的环节，后面我会单独展开。
Embedding 向量化是把每个 Chunk 喂给一个嵌入模型，得到一串固定长度的浮点数向量。这个向量的意义是：语义相近的文本，在向量空间里的距离也相近。你问“退款多久到账”和文档里写“退回款项将在3-5个工作日原路返回”，字面上不相似，但语义相近，向量化之后它们就会靠在一起。
向量索引存储是把所有 Chunk 的向量建索引，存进向量数据库。查询时用同样的嵌入模型把用户问题也转成向量，然后在库里做相似度搜索，找出最相关的 TopK 个 Chunk。
检索生成就是把检索到的 Chunk 拼进 Prompt，让 LLM 基于这些材料生成带依据的回答。这一步还能叠加重排（Rerank）、引用标注、多路召回等优化手段。
从工程实现的角度看，整个链路最核心的是“索引质量”和“检索精度”两头。索引质量决定了上游有没有好料，检索精度决定了上游的好料能不能被捞出来。很多团队一上来就调 Prompt，结果发现回答还是一塌糊涂，根子往往在索引阶段。
2.2 Embedding 模型怎么选：中文场景、效果与成本
Embedding 模型是 RAG 的第一道乘法系数，它如果错了，后面所有环节都在放大错误。选型时主要看四个维度：语言能力（尤其中文效果）、向量维度、推理速度、部署成本。
当前中文场景下，我实测过的几类主流方案可以给你一个直接参考：BAAI 的 bge 系列（bge-large-zh、bge-m3）是性价比首选，不仅能处理中文，还支持中英混合检索，且对长文本友好。m3e 系列是早期常用方案，中文效果不错，但如今大模型时代已逐渐被 bge 和更新的模型取代。OpenAI 的 text-embedding-3-large 效果均衡，但需要 API 调用，每次请求有网络延迟，对本地部署的用户不友好。还有 META 的 E5 系列、智源的 e5-mistral 等，都能作为备选。
我个人的建议是：优先考虑本地化部署的 bge-m3 或 bge-large-zh 系列，理由很简单——本地使用零成本、零网络延迟、私有数据不用出内网，这在企业场景是铁一样的要求。如果你做的是全球化多语言知识库，然后再考虑商业 API 方案。
部署上，你可以用 Ollama 直接拉相应的 embedding 模型，或者用 Hugging Face 的 SentenceTransformers 库加载本地模型文件，两种方式都成熟。实际部署时注意确认模型同时支持 query 和 passage 的编码方式，部分模型需要区分“查询输入”和“文档输入”的加前缀策略（如 bge 系列给 query 加为这个句子生成表示以用于检索相关文章这类前缀），不处理这个细节，检索效果会有明显下降。
2.3 向量数据库怎么选：从本地原型到生产环境
向量数据库负责存储和检索向量，常见选择包括 ChromaDB、FAISS、Milvus、Weaviate、pgvector、Elasticsearch 等。作为一开始的选型，我的建议是分阶段看。
本地原型阶段，最省事的是 ChromaDB。它是一个嵌入式向量数据库，能直接跑在 Python 进程中，不需要独立服务，API 也很友好。个人博客知识库、练手项目，用它最合适。也可以先只用 FAISS（Meta 出的向量检索库），它的定位其实更底层，能用内存/磁盘文件存向量并做高效的相似度搜索，配合 Pandas 处理源数据，能很快验证效果。
生产环境阶段，并发高、数据量大、需要权限管理时，就要上 Milvus、Weaviate 这类独立服务。Milvus 是云原生分布式向量数据库，支持海量数据、索引类型丰富（HNSW、IVF等），但需要一套运维。如果团队已经有 PostgreSQL，也可以直接装 pgvector 扩展，好处是能与业务数据统一在一个库管理，减少组件数量。
选型时不必追求“最强”，要根据团队阶段走。我在最初做本地知识库时就用过 ChromaDB 加 bge-m3 的组合，效果已经足够撑起一个完整的问答 Agent，后续数据量上去了再平滑迁移到 Milvus。避免一开始就上复杂的分布式组件，徒增运维负担。
2.4 切块策略：决定检索质量的第一道关卡
切块是 RAG 里最容易被低估的环节。切块粒度太大，一个块可能包含多个主题，向量化之后语义被稀释，检索时难以精准命中；切块粒度太小，语义不完整，检索出来的片段经常“有头无尾”，模型看完也不知道上下文是什么。
我实践下来的经验是：默认优先用 RecursiveCharacterTextSplitter（递归字符切分），按分隔符优先级从高到低切分（段落、句号、逗号），再配合一组 Chunk Size 和 Chunk Overlap 参数学对每篇文档设定。比较典型的基础参数是 Chunk Size 300-600 字符、Overlap 50-80 字符。数据以问答对为主时，可以切得小一些；数据是长篇幅连续文本时，建议适当调大 Size 并增加 Overlap，尽量保证一个 Chunk 能完整描述一个语义单元。
项目里 Markdown 文档很多时，更好用的是按标题结构切分：用 header 标题作为切割锚点，每个 H1/H2 小节单独成为一个块。这样切出来的 Chunk 天然有语义边界，而且能在块元数据里记录“来源章节”，方便回答时附引用。这一点在技术文档、产品手册场景下效果远好于固定字符切分。
另一个很实用的技巧是“父子切片”策略：父块（section）用于语义理解，子块（sentence/paragraph）用于精确检索。先把文档块按大章节切好，再在每个大块内切成更小的片段；Embedding 时统一用大块向量，检索命中返回小块内容。这样既保住了上下文，又提高了命中精度。我做了本地知识库版本迭代后，发现切块策略正确与否比换更好的模型对效果提升都明显。
3. 从 0 到 1 搭一个本地 RAG 知识库
3.1 最小镜像：不用复杂框架也能跑通全流程
现在网上讲 RAG 的文章一大半都在讲 LangChain、LlamaIndex 这种框架。框架不是不好，但在起步阶段很容易让人迷失：你不知道每一步内部发生了什么，出问题都不知道从哪里排查。我建议第一步先不引入框架，用几十行 Python 把“切片-向量化-检索-生成”全链路手写一遍，心里有底之后再上框架。
这个最小镜像的思路很简单：用sentence-transformers加载本地 Embedding 模型做向量化，用numpy做向量点积计算相似度，用一个列表存储向量和文本块，检索时暴力比对 TopK，最后把结果拼进 Prompt 转发给 LLM。数据集规模在一两千个 Chunk 以内时，这套无索引方案完全够用，速度也在毫秒级。
为什么先这么做？因为 RAG 的流程本质上就是一个“召回-重排-生成”流水线，框架只是把这套流水线封装成了组件。自己手写一遍，你就知道了向量数据库起到的作用只是“加速检索”，而不是“产生检索结果”。这个认知能让你后面用任何框架都不慌。
下面给出一段可直接运行的代码骨架，基于 Python 实现的是“检索”部分的完整逻辑，不管大模型接什么都通用：
import numpy as np from sentence_transformers import SentenceTransformer model = SentenceTransformer("BAAI/bge-m3", device="cpu") # 本地嵌入模型 # 假设 docs 是已经切好块的文本列表 docs = [...] # 你的知识库切片 vectors = np.array(model.encode(docs, normalize_embeddings=True)) def retrieve(query, top_k=3): q_vec = model.encode([query], normalize_embeddings=True)[0] scores = vectors @ q_vec # 向量点积 = 余弦相似度(归一化后) top_idx = np.argsort(scores)[::-1][:top_k] return [(docs[i], round(float(scores[i]), 4)) for i in top_idx] query = "退款多久能到账" for text, score in retrieve(query): print(f"{score:.4f}\t{text}")如果你的文档量小，这段代码就直接够用了。后面要接 LLM 作答，无非是把检索结果拼进一个 prompt 模板：“请基于以下资料回答问题，如果资料不足以回答则直接说明不知道。资料：{context} 问题：{query}”。
3.2 建索引时的文档清洗和元数据设计
真实世界的文档远没有测试数据那么干净。PDF 扫描件里有乱码、Word 档里有多余换行、Excel 导出的文本里全是制表符，这些都直接影响切块和向量化的质量。我处理过一批运维工单文档，光清洗文本就花了两天，但后面检索效果比没洗之前提升了不止一个档次。
文本清洗的优先级从高到低是：去无效字符（控制符、非 Unicode 字符）、规范空白（连续换行变段落分隔）、去掉页眉页脚和水印、统一全角半角、处理列表序号。这些操作非常机械，但千万不能省，尤其是 PDF 页眉页脚，会反复污染大量 Chunk。
另一个容易被忽略但价值极高的是元数据设计。每个 Chunk 在入库时都可以带上一组 metadata，比如来源文件名、章节标题、文档类型、更新时间、所属部门。元数据的作用有两个：一是检索过滤，比如“只看财务制度类的文档”，就可以在 query 时按 metadata 过滤后再做向量搜索；二是回答引用，把来源：xxx.pdf 第3节拼进回答里，能让 RAG 结果的可用性大幅提高。
3.3 检索生成：阈值、TopK 与 Prompt 的三个关键参数
检索环节有两个数字直接决定回答质量：相似度阈值、TopK 数量。初学 RAG 的人通常只关注 TopK，忽视阈值，结果就是无论问题库不问库，系统都硬塞三段最相似的 Chunk 给模型，最终模型被无关上下文带偏，强行“融合”出不存在的答案。这一点非常常见。
合理的做法是设置一个双阈值策略：如果最高相似度低于阈值下限（比如 0.35），则直接不检索，让模型回答“知识库中没有找到相关信息”；如果最高相似度在阈值区间内，则只保留高于阈值的 Chunk 并降低 TopK。阈值需要根据实际数据的向量分布来调，bge-m3 在常见知识库上的有效区间大概在 0.4-0.7 之间，但这只是个起步参考值，必须自己多采样几次查询测试来标定。
Prompt 这边同样有讲究。三段式模板是我长期实践后的标准做法：第一段是系统指令，明确“你是知识库助手，仅基于以下资料回答，不要编造”；第二段是检索到的资料，带序号和来源；第三段是用户提问。要想进一步降低幻觉，还可以加一句“如果资料与问题无关，请直接回答‘知识库没有相关内容’”。注意，千万别把检索出的所有 Chunk 一股脑全塞进 Prompt，Token 有限且模型注意力会被稀释，你塞 8 段模糊文本远不如塞 3 段高相关文本管用。
3.4 一个低成本本地问答 Agent 的完整实践记录
下面share一个我在一个运维知识库项目里的完整实践数据，可直接参考。
数据情况：公司运维 Wiki 和工单文档总共约 120 篇 Markdown/PDF 文档，约 15 万字符。本地机器是 8G 内存的笔记本。方案选了 bge-m3 嵌入模型 + 手工清洗 + 按 Markdown 标题切块 + NumPy 暴力检索 + DeepSeek 在线 API 做生成（如果完全离线，也可以换成 Ollama 内部署的 7B 模型）。
切块策略按 H2 标题为主，辅助句子切分，最终产出 480 个 Chunk，平均每个 Chunk 约 300 字符。向量化耗时约 30 秒，单次检索耗时小于 20 毫秒。检索质量上，我做了 20 个问题的抽样测试，其中 16 个问题能准确命中相关 Chunk，3 个问题因文档覆盖不够导致低相关，1 个因切块策略导致语义被截断。整体可用度已经能支撑日常问答。
整个链路换成代码描述就是：加载文档 -> 清洗文本 -> 按标题切块 -> bge-m3 批量向量化 -> 存入 numpy 矩阵 -> 查询时计算余弦相似度取 TopK -> 拼 Prompt -> 调用 LLM。从这个项目里我得到的最深体会是：RAG 的效果下限由文档质量决定，上限由检索质量决定，Prompt 只是最后一道放大器。
4. RAG 不值得只会“查一段”，进阶形态你要知道
4.1 Agentic RAG：让 Agent 自己决定何时查、查什么、查几轮
经典的 RAG 是一次性检索，提问后直接把 TopK 结果丢给模型。这在一些简单问题上是够用的，但在 Agent 场景远远不够。真实的任务往往是多步的：用户问“我上个月云服务器费用为什么超高”，你得先查到账单数据，再关联到服务器规格变更记录，还可能需要知道某个实例的启停时间。这种多跳问题，一轮检索根本解决不了。
Agentic RAG 的思路是：把检索本身作为 Agent 的一个工具（Tool），让模型通过推理决定要不要检索、搜什么关键词、先用哪个知识库接口、如果第一轮结果不够再换关键词搜第二轮。这相当于从“人手动查资料给模型看”变成了“模型自己指挥检索过程”。
实现上无非两步。第一步，把检索函数包装成 Function Calling 格式，供 Agent 调用；第二步，在 Prompt 里告诉 Agent 检索工具的用途、入参格式和使用时机。比如你可以给 Agent 配两个检索工具：search_knowledge_base(query)和search_recent_orders(keyword)，模型自主判断用哪个。工程上，这一步不复杂，描述清楚工具语义比工具本身更关键。
4.2 GraphRAG、多路召回和 Rerank 为什么更稳
信息密度高、跨章节关联多的知识库，光靠向量检索很容易“只见树木，不见森林”。GraphRAG 专门解决这类问题：先用 LLM 在文档中抽取实体和关系，构建知识图谱，查询时既走向量相似度，也走图上的关联路径，把相关实体链上的信息一并取回。典型应用是金融研报问答、医疗临床指南引证这类强逻辑关系场景。
再一个是多路召回加 Rerank。多路召回是指同时用向量检索（语义）、BM25（关键词）、元数据过滤（分类）等多种方式各召回一批候选结果，然后把它们合并去重。Rerank 是拿一个更精细的模型对合并后的候选列表打分排序。这一步是当前 RAG 调优中性价比最高的操作，尤其是关键词精确匹配能力弱是向量检索的天然短板（比如型号“A100-PCIE-40G”这种专有名词，语义向量通常处理不好，BM25 的精确命中就特别有效）。
Rerank 模型我实测下来，bge-reranker 系列在中文场景表现不错，它输入的是 query 和候选文本，输出分数，比单纯用向量相似度再排序准得多。接上 Rerank 之后，Top5 命中的准确率提升幅度经常能达到 15%-30%。
4.3 RAG 和 MCP 到底什么关系，别再混淆了
这个热词出现的频率极高——“RAG 和 MCP 区别”。直接给结论：RAG 负责“获取知识”，MCP 负责“统一调用外部工具和资源的接口标准”。两者解决的是不同层面的问题，可以完全共存，不是一个选择题。
RAG 的薄弱点在“实时获取和操作”：它能查询文档库，但拿不到数据库里最新的库存数字，更没法调用业务系统修改数据。MCP（Model Context Protocol）就是为这个而生的：它定义了一套标准的协议，让模型统一通过“Tool/Resource”去访问外部系统。一个服务如果实现了 MCP Server，Agent 通过一个通用客户端就能对接它，不必每个服务写一套适配代码。
所以典型的企业级架构是：RAG 负责长期记忆和文档知识，MCP Server 负责实时数据和业务操作，Agent 在决策时视情况调用两者。很多团队把这两者混在一起设计，结果搞出了“用 RAG 硬查数据库”的差方案，方向搞反了。
4.4 多轮对话里的 RAG 检索策略怎么调
RAG 在一问一答场景下很容易跑通，一进多轮对话就露馅，最常见的现象是：用户第一句说“帮我查一下退款政策”，第二句说“还有退货的呢”，此时如果把用户第二句原封不动拿去检索，检索出来什么都对不上。核心原因在于多轮对话里用户的问题大量依赖历史上下文。
解决方式主要有三种。第一种是 Context 压缩，把对话历史交给小模型总结成一句独立查询，比如把上面两句压缩为“退款政策和退货政策分别是什么”，再去检索。第二种是检索历史注入，把检索结果和最近几轮对话都放进 Prompt，让模型自己判断；这个办法简单但 token 消耗大。第三种是混合策略，第一轮用用户原话检索，后续轮次先做“用户问题重写（Rewrite）”，重写后的独立问题进行检索。
我实测下来，第三种效果最稳，尤其是 Agent 需要连续追问的场景。你的工具链里加一个 query rewrite 步骤，成本不高，但多轮体验能上一个档次。
5. 高频故障排查与避坑经验
5.1 检索不到、答非所问、幻觉，这三类问题的排查顺序
我在多个 RAG 项目里发现，用户反馈的“回答不准”翻来覆去都是三类问题。捋清排查顺序，能省下大量无效调试。
第一类是检索不到，即相关 Chunk 本身存在却无法被召回。先查全局相似度分布，看检索分数整体是否偏低；再查切块策略和 Embedding 模型，如果文档是 PDF 图片那先查是否做了 OCR，如果模型库是英文模型那先查中文支持问题。
第二类是答非所问，即检索到的 Chunk 虽相似但并非真正对应问题要害。这类问题从重排入手，加一个 Rerank 模型；同时调整 TopK 和阈值，TopK 过大加了噪音，阈值过低放了低相关段落。再不行就检查 metadata 过滤条件，看是否错误限制了文档范围。
第三类是幻觉，即检索结果明明是有的，模型却给出了检索内容之外的信息。先看 Prompt 约束是否明确，再核查检索内容是否被截断（常见于 Chunk 过长超出 context），最后确认系统指令里是否强制要求“只依据资料回答，不得补充外部知识”。幻觉问题优先级最低，因为它往往是上游查出来的内容本身就不对齐，属“因果错位”。
下面把高频坏症状和方案整理成速查表，方便项目里对照处理：
| 症状 | 最大嫌疑环节 | 解决动作 |
|---|---|---|
| 相关知识召回不到 | 切块/嵌入模型 | 改切块粒度，换 bge-m3 并加查询前缀 |
| 召回内容不相关 | 检索策略 | 加入 BM25 多路召回 + Rerank |
| 答案没引用、像脑补 | Prompt | 强约束“只依据资料回答”，要求引用序号 |
| 文档越多效果越差 | 索引噪声 | 定期重建索引，加 metadata 过滤 |
| 多轮对话答非所问 | 查询理解 | 加 query rewrite 或历史压缩 |
| 响应速度慢 | 向量检索库 | 本地小规模用 FAISS，数据量大上 Milvus |
5.2 我踩过的三个坑：前缀、相似度阈值、不重建索引
第一个坑是 bge 前缀问题。我第一次用 bge-large-zh 时，直接把文档和 query 都原样喂给模型，结果检索分数普遍偏低，好多相关知识排到 20 名开外。后来查了模型说明才发现，bge 系列要求对 query 端加指令前缀“为这个句子生成表示以用于检索相关文章”，加了之后命中率立刻回升。这个细节属于“用了才知道，不看不注意”的典型，文档里写了但很容易略过。
第二个坑是把相似度阈值只调一次就以为万事大吉。RAG 上线后随着知识库增量更新，向量的整体分布会漂移，同一阈值在旧库上合理，在新库上可能把高于阈值的低相关内容全放进来或者反过来。一个实用的做法是每次批量更新索引后，抽样 20-30 个标准问题跑一轮评估，看阈值对应的召回分数变化，动态调整后再上线。给“阈值”做版本管理，和给代码做版本管理一样重要。
第三个坑更隐蔽：索引只增不更、不删不重建。有一次我在某个 Agent 产品里改了上游文档标题，但因为旧 Chunk 没有被标记失效，检索时新旧两版同时命中，导致回答混乱。后来形成惯例：上游文档变更时必须触发对应 Chunk 的失效和重建，而不是无脑 append。可以维护一个“文档版本号”做增量更新判断，避免全量重建的算力浪费。
5.3 便宜且有效的优化顺序：先切块、再重排、最后才换模型
很多团队一遇到效果不佳就想着“换更强的 LLM 来兜底”，这是成本最高、收益最低的路径。从我的经验出发，RAG 效果的优化顺序应该是：先做文本清洗和切块策略，这往往直接改变检索质量的基线；再做重排和多路召回，把候选质量提上去；最后才考虑换大参数模型，而且换模型主要影响“表达”，不影响“检索命中”。
用数据说话：我迭代某个知识库的 v1 到 v3，效果提升比例大约是：清洗+合理切块提升了 20%，Rerank 提升了 15%，查询重写优化多轮场景提升了 10%，换成更新的 LLM 只提升了不到 5%。所以每次项目排查问题时，性价比最高的工具永远是最基础的那几个。
补充一个独立的经验：生产环境里要有“检索结果自评”机制。即每次 RAG 问答时记录检索到的 TopK 分数、最终采用哪几个 Chunk、用户对回答的反馈，定期抽检。否则出问题时你连“是检索坏了还是模型坏了”都不知道，根本无从优化。
我在实际项目里体会最深的一句话是：RAG 不是一个库或一个模型，而是一条管道，这条管道的效果由最粗的那节管子决定。把基础细节做扎实，比跟风换一个组件更有用。
