好好住先说个现象。这几年做 AI 应用，我身边不少人从“大模型真厉害”到“这玩意儿怎么老胡说八道”，中间只隔了一个生产环境。问它公司制度，它给你编一条；问它项目历史，它把别人的事安到你头上。有些团队第一反应是换更大的模型，结果成本翻了几倍，该编还是编。其实大部分业务场景压根用不着微调，也不需要换模型，你应该先把 RAG 搞清楚。
RAG 全称 Retrieval-Augmented Generation，检索增强生成。我习惯把它理解成“给大模型开卷考试”：模型不需要靠记忆硬答，而是先从你的知识库里查资料，再基于查到的内容作答。这篇我不打算写成学术论文，就按我从零开始做 RAG 项目的顺序，把原理、选型、实操、进阶、踩坑全捋一遍。适合准备做知识库问答的开发者、想用企业内部文档搭问答服务的工程师，以及被幻觉问题折磨到怀疑人生的产品经理。
1. 先理解问题：大模型的“胡说八道”到底从哪来
1.1 大模型的记忆不是数据库
先说一个很多人忽略的事实：大模型本质上只是一个“接龙游戏高手”，它的训练目标就是预测下一个 token，而不是建立一个事实数据库。你问它问题，它不是在“查档案”，而是在根据概率“续写一段看起来合理的文本”。
这就带来三个天生的问题。第一，知识有截止日期，2023 年之后发生的事情它一概不知道，除非有人帮它补上；第二，参数容量有限，训练语料里低频的知识它根本记不住，或者记成了模棱两可的样子；第三，训练数据本身就有噪声，网上的错误信息它一样会学进去。
所以你让大模型直接回答你的私有业务问题，它最好的情况是“记混了”，最坏的情况是“自己编一个”。这不是模型笨，是它压根没有你那些资料的入口。
1.2 RAG 的本质：让模型学会查资料
RAG 的思路很简单：既然模型不知道，那就先查，查完再答。整个流程可以拆成三个动作——先把你手里的文档切成小块、做成索引；用户提问时，从索引里找出最相关的几块内容；把这些内容塞进提示词，让模型“看着资料回答”。
这不是什么高深理论，跟你上班查 wiki 写方案一模一样。但正是这个朴素的思路，解决了大模型落地的两个关键痛点：一是知识可以实时更新，你不用重新训练模型；二是回答有出处，模型不能凭空编造，因为提示词里明确写了“仅基于以下内容回答”。
我在实际项目中经常跟团队说一句话：RAG 不是模型能力的替代品，而是模型能力和业务数据之间的桥梁。它让大模型从“凭记忆瞎猜”变成了“查资料作答”，这种转变在知识库问答、客服辅助、文档分析这类场景里，效果立竿见影。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 搞懂 RAG 的三个阶段：索引、检索、生成
2.1 一条完整链路在做什么
RAG 的标准流程分三段，听起来简单，但每一段都有大量细节。
第一阶段是索引构建（Indexing）。你要把 PDF、Word、Markdown、网页这些乱七八糟的原始文档，清洗成纯文本，切成适当大小的片段（chunk），用嵌入模型（Embedding Model）把每个片段转成向量，最后存进向量数据库。这个阶段有点像给一本书编目录——但比编目录难，因为切多细、怎么切，直接决定了后面能不能查到。
第二阶段是检索（Retrieval）。用户输入问题后，先把问题也转成向量，然后去向量库里找最相似的几个片段。这个阶段的目标不是“找到正确答案”，而是“找到可能包含正确答案的资料”，所以通常要放宽一点，多召回一些候选。
第三阶段是生成（Generation）。把检索到的片段和用户问题一起拼成一个结构化提示词，交给大模型。模型不能自由发挥，只能基于你给的片段回答。如果片段里没有答案，它必须承认不知道，而不是硬编。
你可以把这个过程理解成做菜：索引阶段是备菜，检索阶段是配菜，生成阶段是炒菜。前面任何一步做得不好，最后端上桌的菜都好不了。
2.2 文档切分：最容易被低估的环节
我在很多项目里都遇到过这种情况：Embedding 模型选得挺好，向量库也搭得没什么毛病，但检索结果就是一团糟。查到最后，问题往往出在文档切分上。
切分的核心矛盾是“尺度”问题。切得太细，比如一句话一切，检索时容易匹配到碎片，抓不住完整的上下文；切得太粗，比如整章一切，向量会被大量无关信息稀释，相似度计算出来的结果很不稳定。这两种情况都会让检索召回质量直线下降。
我常用的切分策略有这么几种：
- 固定字符切分：按固定长度硬切，代码简单，但会拦腰切断语义。
- 递归字符切分：按“段落 → 句子 → 标点”的优先级逐层往下切，是大多数场景的默认选择。
- 结构化切分：针对 Markdown、HTML、代码文件按标题、章节、代码块切分，能最大程度保留文档本身的层级结构。
- 语义切分：算相邻句子的向量相似度，相似度掉到某个阈值就切一刀，效果不错但计算成本高。
具体参数上，我习惯的中文场景起点是：块大小 500 到 800 字符，重叠长度 50 到 100 字符。为什么要有重叠？因为切分点在语义中间时，关键信息正好落在边界上的概率不小，重叠部分能起到“保险带”的作用。
这里有个容易被忽略的细节：你切出来的 chunk 最终是要被当成一段独立文本去做语义匹配的，所以每个 chunk 内部必须有完整的信息单元。表格数据要整行整行地保留，合同条款要按条款切，菜谱要把用料和步骤放在一起。拿合同举例，如果把甲方名称和违约条款切成两个 chunk，用户问“甲方违约了怎么办”，检索根本联系不到一块儿。
2.3 Embedding 和向量检索：匹配的核心引擎
切好文档之后，下一步就是把文本变成向量。Embedding 模型的作用是把一段文字映射成一个高维向量，让语义相近的文本在向量空间里距离更近。你问“怎么请假”，它知道跟“休假制度”离得近，这就是向量匹配能工作的基础。
选 Embedding 模型的时候，我有一个很朴素的建议：别死盯着英文榜单，中文场景一定用中文优化过的模型。OpenAI 的 text-embedding-3 确实强，但你在国内做业务的私有数据，往往是中英混杂的，选型时优先看对中文支持好的开源模型，比如 BGE 系列、M3E，都能在本地部署，成本可控且不会存在数据外传的风险。
向量存进向量数据库之后，检索时就是算距离。最常用的是余弦相似度，公式很简单：
code复制similarity = cos(A, B) = (A·B) / (|A| × |B|)
值越接近 1，表示两段文本语义越接近。我见过一些团队直接用内积相似度，结果召回结果乱七八糟——因为他们没注意到部分模型做完向量后没有归一化，内积算出来的分数会被向量长度干扰。建议先确认 Embedding 模型的官方建议，BGE 系列明确推荐用余弦相似度，别偷懒。
向量数据库的选择上，拿数据规模说话就行。学习和小型 Demo 直接用 Chroma，零配置、好上手；正式项目数据量在百万级以内，Qdrant 是个不错的中间档，内存占用控制得很好；到了千万级、需要分布式和高可用，再上 Milvus。如果你团队本来就重度使用 Elasticsearch，新版 ES 自带的向量检索也能凑合，但别指望它在大规模高并发下能跟专业向量库比性能。
2.4 Rerank 不是加分项，是必选项
先问一个问题：向量检索帮你从 10 万个 chunk 里召回 20 个候选，你敢把这 20 个全部塞给大模型吗？大概率不敢，因为上下文窗口有限，噪音也会干扰输出。但如果你不塞，只取 top 5，又可能把真正相关的那个挤出去。
Rerank（重排序）就是来解决这个矛盾的。流程分两步：先用轻量级的双塔模型（bi-encoder）快速召回 50 到 100 个候选，再用一个重量级的交叉编码器（cross-encoder）对每个候选重新打分排序。交叉编码器会把问题和候选文本拼成一对，让模型同时看两个句子来打分，精度比向量相似度高一截，代价是速度慢，所以它只负责精排，不负责全量扫描。
我在项目的 RAG 链路里有一条铁律：召回可以宽，排序必须严。实测下来，加一层 Rerank 之后，生成答案的准确率能提升 10 到 20 个点，尤其当知识库里的文档风格接近、表述相似时效果更明显。BGE-reranker-base 是社区常用的选择，中文效果不错，显存占用也不大。
3. 从零搭建 RAG：一套可复制的最短实践
3.1 技术选型：先看你的场景，再看你的团队
搭建 RAG 之前，我先问自己三个问题：知识库体量多大？更新频率多高？团队有没有算法背景？这三个问题决定了技术路线。
如果你要做的只是一个内部知识库问答 Demo，我建议直接用 Dify 这类开源 RAG 框架。它的界面化配置能让你在半小时内跑通“上传文档 → 切片 → 嵌入 → 检索 → 对话”整个链路，而且内置了向量库、Embedding、Rerank 的多种接入方式。对你理解流程、验证效果非常友好。
如果你要做的是一套面向生产的系统，或者你的数据有很强的私域性，那我还是推荐自己手写链路。组件就那几个：文档解析用 PyMuPDF 或者 unstructured，切分用 LangChain 的 RecursiveCharacterTextSplitter 或者自己写，Embedding 可以部署 BGE 系列，向量库用 Qdrant 或 Milvus，生成模型用 OpenAI 兼容接口的本地部署模型，或者直接接国内大模型 API。
3.2 手写最小实现：核心代码与参数说明
我贴一段我常用的最小 Python 实现，不依赖任何重型编排框架，方便你理解 RAG 到底做了什么。这里假设你已经把文档切好并存入 Qdrant。
python复制from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct
# 1. 连接向量库（本地模式）
client = QdrantClient(path="./local_qdrant")
# 2. 创建集合，维度要和Embedding模型输出对齐
collection_name = "knowledge_base"
vector_dim = 1024 # 以BGE-large-zh为例
if not client.collection_exists(collection_name):
client.create_collection(
collection_name=collection_name,
vectors_config=VectorParams(size=vector_dim, distance=Distance.COSINE),
)
# 3. 写入向量（chunks已经通过Embedding模型转换为vectors）
points = [
PointStruct(id=i, vector=vector, payload={"text": chunk_text})
for i, (vector, chunk_text) in enumerate(zip(vectors, chunk_texts))
]
client.upsert(collection_name=collection_name, points=points)
# 4. 检索
query_vector = embed_query(user_question)
hits = client.search(
collection_name=collection_name,
query_vector=query_vector,
limit=20,
)
这段代码的核心点有两个。第一，创建集合时要显式指定距离算法为余弦相似度，不是所有向量库都默认用这个；第二，检索时 limit 先放 20，后面配合 Rerank 再砍到 5 到 8 个进上下文。
接着是 Rerank 和生成。Rerank 我用的是 BGE-reranker-base，代码相当简洁：
python复制from FlagEmbedding import FlagReranker
reranker = FlagReranker("BAAI/bge-reranker-base")
pairs = [(user_question, hit.payload["text"]) for hit in hits]
scores = reranker.compute_score(pairs)
# 排序后取top5，拼上下文
top_hits = [h for _, h in sorted(zip(scores, hits), reverse=True)[:5]]
context = "\n\n---\n\n".join(h.payload["text"] for h in top_hits)
最后一步是把检索结果拼进提示词。我的提示词模板很固定，就三条指令：第一，只根据提供的资料回答；第二，资料里没有就明确说不知道；第三，回答时引用来源编号。这里有一个容易忽略的细节：如果你不做任何约束，很多模型还是会忍不住“补充”自己的常识，所以“仅基于以下内容回答”这句指令必须放在提示词最前面。
3.3 本地部署大模型：Ollama 的实用玩法
生成模型怎么选？我的建议很简单：先跑通流程用 API，上生产再考虑本地部署。如果数据必须留在内网，那本地部署就是必选项。Ollama 是目前最省心的本地大模型运行工具，一条命令就能拉起一个 OpenAI 兼容的服务。
bash复制# 拉取模型并启动服务（以qwen2.5为例）
ollama pull qwen2.5:14b
ollama run qwen2.5:14b
# 查看服务是否正常
curl http://localhost:11434/v1/models
实例运行后，http://localhost:11434/v1 就是一个标准的 OpenAI 兼容接口，你在代码里只需要改一下 base_url 和 api_key（随便填就行）。所以我一直觉得 Ollama 是本地部署的“及格线工具”：安装简单、模型管理方便、资源占用可控。
但我必须强调一个量化级别的坑。Ollama 下载的模型默认可能是 Q4_K_M 量化版本，意思是把原始模型从 16 位权重压到 4 位左右。这个版本在“能跑”和“跑得好”之间算是个平衡点，但如果你对生成质量要求高，比如做专业领域的问答，建议拉 Q8 或者直接用 fp16 权重。多占的那点硬盘空间，换来的是明显更稳的输出，值。
3.4 评估：怎么知道你的 RAG 系统真的变好了
很多人搭完 RAG 之后，凭感觉试几个问题就说“效果不错”。这在 Demo 阶段没问题，但上生产之前必须建立一套可持续的评估机制，否则你根本没法判断一次改动是在变好还是变坏。
我推荐从两个维度建评估集。第一个是“检索质量”，核心指标是命中率：针对每个测试问题，人工标好标准答案出现在哪个 chunk 里，跑检索后看返回的 top-20 有没有覆盖到这个 chunk。第二个是“生成质量”，核心指标是忠实度：模型回答里的每个关键信息点，能否在检索上下文中找到依据，找不到的就是幻觉。
实操上，我通常会准备 100 到 200 条真实业务问题作为测试集，每轮优化后跑一遍，人工抽样看结果。嫌麻烦的可以直接用 RAGAS 这类开源评估框架，让大模型当裁判打分，但打分只是辅助，最终还是要回到人工抽样上。我的经验是：当你的系统在测试集上稳定达到 80% 以上的命中率、人工抽查忠实度在 90% 以上时，才敢说这个 RAG 系统“基本能用”。
4. 进阶玩法：多路召回、GraphRAG 和 Agentic RAG
4.1 Hybrid RAG：向量加关键词，两碗水端平
向量检索擅长语义匹配，但也有它天生的短板。比如你搜“Q3 季度 OKR 达成情况”，而文档里只有“第三季度目标完成率”这种完全不同的表述，向量检索靠语义关联勉强能搭上；但如果用户搜索一个独特的产品编号“PRJ-2024-0715”，向量检索可能反而因为语义信息太少而表现不佳，这时传统的关键词匹配就能精确定位。
所以我建议在生产环境做混合检索（Hybrid RAG）：一路走向量，抓语义；一路走 BM25 或者倒排索引，抓精确匹配。两条路召回的结果合并时，不能简单地“并集”，要有排序融合策略。最常用的是 RRF（Reciprocal Rank Fusion）方法，公式如下：
code复制score(doc) = Σ 1 / (k + rank_i(doc))
其中 k 通常取 60，rank_i 是文档在第 i 路检索中的排名。这个方法的精髓在于不看原始分数只看排名，因为不同的检索方式返回的分数范围差异很大，直接加会把其中一路的权重带偏。用 RRF 之后，向量召回和关键词召回能被公平地融合到一起，多路召回的稳定性明显提升。
4.2 查询改写与 HyDE：让问题先被“校正”再检索
用户提问的方式五花八门，很多人不会把一个技术问题问得规规矩矩。最常见的问题是“口语化”——用户问“那个新签的跟老李合作的合同里，付款时间是啥时候”，这种 query 直接拿去向量检索，效果往往很差。所以我一般在检索前加一个“查询改写”步骤：让大模型把用户问题改写成适合检索的表述。
改写逻辑很简单，我用的提示词大概是：“把下面的问题改写成适合检索的关键词组合，保留全部实体和限定条件。”上面的口语问题就会被改写成“新签合作合同 老李 付款时间”，向量检索的匹配质量立刻不一样。
还有一个更进阶的技巧叫 HyDE（Hypothetical Document Embeddings），思路很反直觉：先让大模型针对问题假设性地生成一段答案，再用这段假设答案的向量去检索，而不是用问题本身去检索。原理是假设答案里包含的术语和上下文比原始问题更接近真实文档的表达习惯。这个方法不是所有场景都有效——它适合思考型、需要综合多条信息的 query，不适合事实型、有标准答案的 query。我在做项目时会用一个简单规则判断：如果用户问题本身就包含精确实体，就用原始问题检索；如果问题很开放，就用 HyDE 检索，两路都召回再用 RRF 融合。
4.3 多路召回到底在“多”什么
说到“多路召回”，很多初学者以为是多个向量库各查一遍，其实含义更丰富。常见的方式包括：
- 不同的检索策略：向量检索 + BM25 + HyDE 向量检索。
- 不同的切分粒度：同一份文档按段落切一份、按章节切一份，同时建索引，查询时分别召回。
- 不同的 Embedding 模型：有的模型擅长短文本匹配，有的擅长长文本语义，用两套模型各建一套向量，合并结果。
多路召回的价值在于“不把鸡蛋放在一个篮子里”。单独任何一路召回都有漏网的时候，但多路结果合并后，漏掉真实答案的概率会大幅降低。代价是召回多了之后噪音也多，所以 Rerank 在多路召回体系里几乎是强制件，没有 Rerank 的多路召回就是给大模型灌垃圾。
4.4 GraphRAG：搞定单靠向量搞不定的关系型问题
传统 RAG 处理“XX 文档里怎么说”这类局部问题很在行，但面对“我们的系统涉及哪些模块，模块之间依赖关系是什么”这种全局关系型问题，就力不从心了。因为你的知识库被切片成一个个孤立的 chunk，模型看不到文档和文档之间的关系网络。
GraphRAG 的思路是：在索引阶段就抽取文档中的实体和关系，构建一张知识图谱，再通过图谱的社区检测算法把相关实体聚成“社区”并生成摘要。查询时，先通过图谱找到相关实体和社区，再结合原始文本回答。这相当于给 RAG 加了一张“思维导图”，让它不仅能看到树叶，还能看到树的结构。
我当时第一次在项目里用 GraphRAG 的体验是：用户问“看到这些微服务之间的依赖关系链路图”，传统 RAG 给出的是断断续续的文本碎片，GraphRAG 能直接梳理出完整的依赖链路。不过 GraphRAG 不是银弹，它的构建成本高、同步延迟大，适合知识库以多实体关系为主的场景，不适合做高频更新的实时问答。更务实的做法是 GraphRAG 和传统 RAG 共存：全局关系问题走图谱，具体细节问题走向量检索。
4.5 Agentic RAG：让模型自己决定怎么查
再往上走就是 Agentic RAG。传统 RAG 是一次性检索然后生成，Agentic RAG 则让大模型扮演一个“检索 Agent”：它可以自己判断要不要查、查什么、一次不够再查一次、一个工具不够就换另一个工具。
举个实际场景。用户问“帮我对比一下 A 方案和 B 方案的优缺点”。传统 RAG 直接把问题丢给检索，很容易只命中其中某个方案的内容。Agentic RAG 会先判断这个问题需要两步检索，先查 A 方案，再查 B 方案，然后汇总对比。再复杂一点，用户问“这个项目最近有没有进展”，Agent 需要先查项目状态，再根据状态决定是否进一步查具体文档。
Agentic RAG 的实现基础是 ReAct 模式：模型思考（Reason）→ 调用工具（Act）→ 观察结果 → 再思考，循环直到得出答案。框架上用 LangGraph 这类工具可以做非常精细的编排控制。这个方向是当前 RAG 的热点，但我要泼一盆冷水：链路越长，错误传播的概率越大。如果基础检索质量都还没过关，先别急着上 Agentic RAG，否则你会面对一个“花式犯错”的智能体。
5. 生产环境的坑与排查实录
5.1 检索质量差：先分清是“查不到”还是“查不准”
我在排查 RAG 问题时，第一件事永远是看检索结果本身，而不是看模型回答。把检索返回的 top-10 片段打印出来，一眼就知道问题出在哪。
如果检索结果里完全没有相关内容，那是“查不到”的问题。可能原因有三：一是切分太粗或太细，关键信息被切碎了；二是 Embedding 模型不匹配，换一个大一点的模型或者中文优化模型；三是用户 query 表述和文档差异太大，需要加上查询改写环节。
如果检索结果里有相关内容，但排得很靠后，Rerank 之后也没进 top-5，那是“查不准”的问题。原因可能是召回阶段 top-k 设置太小，比如只召回 5 个，真正相关的排在第 8；或者 Rerank 模型本身对领域术语不敏感，需要收集一些领域数据微调。我的习惯是召回阶段放宽到 50 到 100，Rerank 之后再砍，宁可多花一点 Rerank 的算力，也不能让真实答案在召回阶段就丢。
5.2 检索对了，生成还是胡编
这个坑最气人——明明相关片段都在上下文里，模型还是给出了片段里没有的信息。我排查这个问题时，优先检查三件事。
第一，提示词有没有写死“只基于给定资料回答”。我见过不少系统提示词写得像公关稿，一堆“你是AI助手”的客套话，核心约束反而没写。如果提示词没有硬性约束，模型默认会调动它对世界的全部认知去“辅助”回答。
第二，检索片段太多导致注意力被稀释。当上下文里塞了 10 个 chunk 时，其中 3 个相关、7 个无关，模型很难精准找到答案。这时我会把 Rerank 后进入上下文的 chunk 数压缩到 3 到 5 个，并主动在提示词里标注“答案主要来自第 2 段和第 4 段”。
第三，chunk 本身不完整。比如合同条款切分时把“违约责任”和“赔偿金额”切开了，模型只看到一半，就按照自己的理解补全了另一半。这种情况改切分策略，别纠结提示词。
5.3 性能与成本控制
RAG 系统的性能瓶颈通常在 Rerank 和高并发下的向量检索。Rerank 是交叉编码器，计算量大，我试过用 GPU 部署 bge-reranker-base 之后的吞吐提升非常明显。如果预算有限，可以把 Rerank 做成异步任务，或者只让部分复杂查询走 Rerank，简单查询直接用向量检索结果。
向量检索的延迟大头在索引结构和数据量。HNSW 索引是生产环境的标配，它有两大关键参数：M 控制每个节点的最大连接数，ef_construction 控制构建时候选集大小。M 一般在 16 到 64 之间，ef_construction 在 100 到 500 之间，参数越大精度越高、构建越慢。查询时还有一个 ef_search 参数，越大召回质量越好、延迟越高。我的调参思路是：先固定 M=32，构建时 ef_construction=200，查询时从 ef_search=64 开始调，看准确率和延迟的平衡点。
成本方面，最大的省钱点是缓存。同一个用户问题在一段时间内可能被多次问到，我会把“问题 → 检索结果”做一层 Redis 缓存，命中缓存就跳过检索和 Rerank。另一个省钱思路是把小模型和大模型分级使用：简单问题直接小模型答，复杂问题才走完整 RAG 链路。
5.4 排查工具与日常维护
我强烈建议每个 RAG 系统上线前都加一个“调试模式”：在管理后台里能看到每次问答的完整日志——用户问题是什么、改写后的问题是什么、召回了哪几个 chunk、每个 chunk 的相似度分数、Rerank 之后的排名、最终进上下文的片段是哪些、大模型基于这些片段生成了什么回答。
没有这份日志，调优就是盲人摸象。我在生产项目里几乎每天都要翻这种日志：用户反馈“回答不对”，我一看就知道是哪里断了——是查询改写把实体搞丢了，还是 Rerank 把正确答案排到后面，还是生成阶段模型没按提示词约束来。定位到具体环节，修改就有针对性了。
知识库的更新也是一种日常维护。文档更新后要重新切分、重新 Embedding、重新写入向量库，同时把旧的向量删掉。我在实践里会记录每个 chunk 的来源文档 ID 和版本号，更新时按版本号整体替换，避免新旧版本存成两份互相打架。
5.5 几条给了钱都不一定换的实操心得
最后分享几个我在实操中形成的个人习惯，算不上什么高深理论，但确实帮我避了不少坑。
第一，不要迷信开源框架的一键部署。Dify、FastGPT 这类框架让你上手很快，但一旦要深度定制，你得能看懂它的内部实现。我的建议是先手写一个最小 RAG，理解每个环节，再用框架加速；反过来先会用框架、再学原理，很容易被框架限制思路。
第二，日志记录要从第一天就做。我见过太多项目跑了两三个月，想回看某次线上问题的上下文，结果什么记录都没有。RAG 系统的可观察性决定它能走多远，这不是一句空话。
第三，对用户 query 做分类，远比你优化检索重要。我现在都会在检索之前加一个意图识别步骤，把问题分为“闲聊类”“知识库类”“计算类”等。闲聊直接进大模型不检索，知识库类才进 RAG，这样既节省成本，又避免检索噪音干扰闲聊质量。
第四，评估集要持续扩充。每次线上发现一个新的失败案例，就把它加进测试集。这样你的系统会被真实问题“喂养”得越来越稳，而不是只在你手工挑的几个例子上表现良好。
我自己搭 RAG 踩过最大的坑，是花了大量精力优化检索，结果发现生成阶段的提示词约束不严，模型一直在拿自己的知识“脑补”。那之后我把所有项目的 RAG 调试流程固定成一套排查顺序：先看检索日志确认资料有没有找到，再看提示词约束确认模型有没有按要求作答，最后才去调参。这个顺序看着简单，但能解决八成以上的“答非所问”。拿着这套思路去搭，你至少能比我少走两个月的弯路。