从RAG 1.0到2.0：检索增强生成的进化路径与工程实践

1. 先搞清楚：RAG 1.0 到底是怎么跑起来的

聊 RAG 2.0 之前，必须先回到 RAG 1.0。这几年大模型落地项目里，RAG（Retrieval-Augmented Generation，检索增强生成）几乎是标配：大模型本身训练完就"封存"了，新知识没法实时更新，你也不可能把整个企业知识库都塞进它的上下文里，所以主流方案就是"先检索，再生成"——先从你的文档库里把相关片段捞出来，再让模型照着这些片段写答案。

RAG 1.0 这个概念刚出来的时候，大家都觉得挺妙，相当于给大模型配了个"开卷考试"的能力：模型不用背下所有内容，只管翻书、找答案、组织语言。早期很多知识库问答、智能客服、文档助手都是这么搭的，流程简单，见效也快。

但它的问题同样明显。我是从实际项目里跑过来的人，第一版 RAG 搭完，demo 阶段看着还行，一上真实业务就露馅：用户问法一变，检索结果就跑偏；答案引用得不对，模型却能一本正经地编；知识库更新后，旧文档还在被反复召回。这些问题后来催生了 RAG 2.0 这个方向。先别急，咱们从 1.0 的完整流程说起，你才能明白 2.0 到底补了哪些窟窿。

1.1 为什么大模型需要"外挂知识"

大模型本质上是一个"根据概率接龙"的系统。它训练完那一刻，知识就固定在参数里了，不会因为公司某天发了新的报销制度就自动更新。这带来三个现实问题：

第一，知识有时效性。训练数据截止在那个时间点，之后发生的事情它一概不知。第二，专业领域覆盖不够。通用模型对某个公司的内部制度、某个产品的操作手册一知半解，强行提问只能得到"正确但无用"的空话。第三，隐私和权限。企业的内部资料不能拿去公开训练，只能在本地私有化部署后用检索的方式喂给模型。

RAG 的思路就是绕开"让模型记住一切"这条路，改成"每次回答前，动态检索相关材料，把它们作为临时参考资料放进提示词"。这样知识库可以随时更新、按权限隔离、还能追溯答案来源。你想想，这比不断重训模型划算太多了。这也是 RAG 在 2023 年之后迅速成为企业落地大模型首选方案的根本原因。

1.2 RAG 1.0 的三步走

RAG 1.0 的标准流程，业界通常概括为三个阶段：索引（Indexing）、检索（Retrieval）、生成（Generation）。

索引阶段，就是把原始文档切分成小块（chunk），然后做两件事：一是把每一块文本用嵌入模型（Embedding Model）转成向量，存进向量数据库；二是把原文也留着，方便后面引用和展示。这一步的关键是"切分策略"，切多大、重不重叠、按什么结构切，直接决定后面能不能查到。

检索阶段，用户问题来了之后，先把问题也转成向量，然后去向量数据库里做相似度搜索，找出最接近的 top-k 个文档块。很多初级方案到这里就结束了，直接把检索结果拼进提示词。

生成阶段，把用户问题和检索到的文档块一起交给大模型，在提示词里明确说"请基于以下资料回答"，模型再输出最终答案。

这套流程思路清晰，我也见过不少团队一晚上就能跑通。但跑通和跑好，中间隔着一整条 RAG 2.0 的进化路径。

1.3 一个开卷考试的类比

我给你打个比方，你马上就懂 RAG 1.0 的尴尬了。假设你参加开卷考试，参考资料是一本 500 页的手册。RAG 1.0 的做法是：你拿到题目后，随手大概翻到某一页，把那一页内容抄到草稿纸上，然后直接照着草稿纸写答案。

问题来了：你翻的那一页，未必是真正有用的那一页。甚至你抄下来的内容里，可能只有半句话跟题目有关，其他全是干扰信息。模型跟考生一样，不会因为资料是"检索来的"就特别正确地使用它——它依然可能被干扰、可能过度解读、可能一本正经地胡说八道。

RAG 2.0 想解决的就是这件事。它不再满足于"翻一页就答题"，而是让系统学会：先理解题目，再决定去查什么，多翻几个地方交叉验证，发现不对就重新查，最后答完还要核一遍。听起来不就是个聪明的考生吗？对，RAG 2.0 的核心进化方向，就是让检索增强生成从"机械流程"变成"会思考的流程"。

2. RAG 1.0 用起来之后，问题全冒出来了

RAG 1.0 的坑，不是在论文里看出来的，是真实业务里踩出来的。我做过的几个知识库项目，几乎把这些问题挨个遇了一遍。

2.1 召回不准：用户不是按你的文档结构提问的

第一个大问题是召回不准。向量检索依赖的是语义相似度，但用户提问的表达方式和文档原文往往差异巨大。比如知识库里写的是"员工连续工作满一年，可享受 5 天年假"，用户问的是"我入职一年多了，能休几天假？"——这两个句子表面用词几乎不同，语义上有相关性，但向量相似度可能并不高，很容易被漏掉。

更麻烦的是，很多问题带有隐含前提。用户问"晚上加班回去打车能报销吗"，文档里写的是"工作日加班至 21 点后，可通过企业打车平台叫车，费用由公司承担"。这里面"21 点""企业打车平台"都是关键约束，但用户没说出来，单纯靠向量检索很难自动匹配上。

2.2 切分太粗：文档被拦腰砍断

第二个大问题是切分策略。RAG 1.0 最常见的是按固定字符数切块，比如 512 字符一段。这种切法完全不尊重文档结构：一个表格被劈成两半，一个条款从中间断开，一段话的上下文被切没了一半。结果就是检索到了这块内容，但内容本身不完整，模型拿着残缺信息，当然答不对。

有人会想，那我把块切大一点不就完整了？块切太大，检索精度下降，无关内容混进来；块切太小，语义不完整。单纯调整 chunk size 并不能根治，因为问题的本质是"检索单元"和"语义单元"不一致。这个矛盾，直到 RAG 2.0 引入多路召回、重排、结构化索引，才真正得到缓解。

2.3 知识更新：旧文档反复捣乱

第三个问题是知识更新。企业知识库是动态的：制度在改、产品在升级、条款在作废。RAG 1.0 的流程里，检索器并不知道什么是"新"什么是"旧"，它只按相似度排序。结果就是新制度已经发布，旧制度的文档还躺在库里，用户一提问，新旧内容同时被召回，模型要么给出过时答案，要么自己纠结地"和稀泥"。

这个问题在金融、医疗、法律这类对时效性极其敏感的行业尤其致命。后来 RAG 2.0 的不少方案里都加入了时效性过滤、规则优先级、甚至元数据路由，本质上都是在解决"检索器太笨、不知道筛选"的问题。

2.4 没有反馈：查错了也绝不回头

第四个问题是最要命的：RAG 1.0 是单次前向流程。用户问题进来，检索一次，生成一次，结束。如果第一次检索就查错了，没有任何机制能发现并纠正。你想想，人做题的时候，发现自己引用的资料不对，至少会换个方向再查一次，但 RAG 1.0 不会。

这三个问题叠加在一起，导致 RAG 1.0 的落地体验很看运气：文档规范、问题简单、检索碰巧命中的时候，效果惊艳；一旦问题复杂、文档凌乱，效果就断崖式下跌。RAG 2.0 的所有改进，本质上都是围绕这几个痛点展开的。

3. RAG 2.0：到底升级了哪几件事

RAG 2.0 这个叫法，在业界其实有两种理解，一种是"先进 RAG"或者说"模块化 RAG"的技术升级路线，另一种来自那篇著名的《RAG 2.0：工业化检索增强生成》论文，强调检索器和生成器联合训练。两条线不冲突，很多工程实践是两条一起用。我给你分开讲清楚。

3.1 从"一次检索"到"边答边查"

RAG 2.0 的第一个变化，是打破"只查一次"的僵化流程。系统会先判断：这个问题我需不需要检索外部资料？如果需要，我要查几轮？查完之后生成答案时，如果发现资料不足或矛盾，还要不要补查？

这就是所谓的"自适应检索"。实现方式通常是在流程里加入一个判断节点：让大模型先评估当前检索结果是否足够回答问题，不够就改写查询词再查一轮，重复直到满足条件或达到次数上限。这个过程很像人查资料：先粗略翻一遍，发现不行，换关键词、换来源，再查。

有一个很直观的类比：RAG 1.0 是"搜索引擎只让你搜一次就交卷"，RAG 2.0 是"允许你先搜、再调整关键词、再搜，迭代到满意为止"。

3.2 从"单路召回"到"多路召回加融合"

第二个变化，是不再只靠向量检索一条路。向量检索擅长语义匹配，但关键词匹配能力弱；BM25（经典关键词检索算法）擅长精确词匹配，但不懂同义词和语义变体。RAG 2.0 的做法是"两条腿走路"：同时用向量检索和关键词检索，把两路结果合并去重，再用一个重排序模型做精细化筛选。

这就是业界常说的"混合检索 + 重排"。实测下来，这套组合对长尾问题、专有名词、精确条款类问题的提升非常明显，往往能把命中率从低得可怜拉到能用的水平。

3.3 从"机械拼装"到"自我反思"

第三个变化，是引入了"自我反思"和"自我修正"机制。大模型生成答案后，不再直接返回给用户，而是先让自己（或专门的评判模型）检查一遍：我的回答是不是严格基于检索到的资料？有没有编造？资料和资料之间有没有矛盾？如果发现回答不忠实，就带着这个反馈重新生成；如果发现资料不够，就再检索。

这类方法在学术上有一套体系，比如 Self-RAG（让模型在生成过程中给自己打分）和 CRAG（Corrective RAG，检索出错时自动纠偏）。落地时不用搞那么复杂，但"生成后再校验"这个动作，确实能显著减少幻觉，代价是多一次模型调用，钱和时间要多花一点。

3.4 另一层含义：检索器和生成器一起训练

论文里定义的 RAG 2.0，核心思想更激进：不再把检索器和生成器当作两个独立部件，而是在同一个目标函数下联合训练。传统方案里，检索器和生成器是各自训练、各自部署的，中间用向量库和提示词硬凑在一起，必然存在"接口损耗"——检索到的内容和模型偏好不一定对齐。

联合训练的做法，是让整个系统在特定领域数据上端到端微调，检索器学习"这个领域的哪些信息对生成最有用"，生成器学习"如何更忠实地利用检索结果"。中间还增加了 refine（精修）阶段，在正式生成前对检索结果再做一轮细加工，比如过滤噪声、合并重复、补充缺失信息。

这个思路在单点技术上并不新奇，但它的意义在于把 RAG 当成一个"整体系统"来优化，而不是一堆零件的临时拼接。很多企业在落地高精度场景时，最后都会走到这一步：要么自己优化检索，要么联合微调整个管道。

4. RAG 2.0 的核心模块，逐个拆开看

说完了方向，咱们把 RAG 2.0 里最常见的几个模块逐个拆开。这些模块不是每套系统都要全上，但知道它们是干什么的、解决什么问题，你设计自己的方案时才有谱。

4.1 查询改写（Query Rewriting）

用户原始问题往往不适合直接拿去检索。太口语、太啰嗦、缺少关键词，或者有歧义。查询改写的任务，就是让大模型把用户问题改写成更适合检索的形式。

举个例子。用户问："公司对迟到怎么说的来着？我有点记不清。"这句话直接拿去检索，大概率查不到什么。改写之后变成："公司关于迟到的规定是什么？"再进一步抽取关键概念："迟到 处罚 规定"，检索质量立刻不一样。

更高级一点的改写是"拆解复杂问题"。用户问"入职三个月还在试用期，想请假，工资怎么算？"这个问题至少涉及"试用期请假"和"工资计算"两个子问题，如果只检索一次，很难同时命中两块资料。查询改写阶段可以把问题拆成多个窄问题，分别去检索，再拼合答案。简单说，改写就是用模型的"理解能力"帮检索器扫清障碍。

4.2 多查询扩展与 HyDE

多查询扩展（Multi-Query）的思路是：一个问题不要只查一次，而是让模型生成问题的好几种问法，分别去检索，再把结果合并。比如"年终奖怎么计税？"可以扩展成"年终奖个人所得税计算方法""全年一次性奖金计税方式""年终奖 税率 公式"等多个变体。这样就算原始问法和文档写法对不上，总有一个变体能命中。

HyDE（假设性文档嵌入）是另一个有意思的技巧：先让大模型根据问题凭空写一段"假设性答案"，然后把这段假答案去和文档做相似度匹配。原理是：假答案虽然内容不一定对，但它包含了很多跟问题同领域的词汇和写作风格，向量上更容易和真实文档碰在一起。这个方法特别适合"问题很短、文档很长"的场景，能明显提升召回率。

不过要提醒一句：多查询和 HyDE 都会成倍增加检索调用量和 token 消耗，属于"花钱买效果"的手段，适合检索瓶颈明显时使用，不是无脑都能上的。

4.3 重排（Reranking）

向量检索返回的 top-k 结果，只是"初步入围"，里面肯定混着噪声。重排阶段用更强的模型（通常是交叉编码器）把检索结果逐条和问题做深度匹配，重新排序，砍掉低质量结果。

交叉编码器的原理，是把问题和文档拼在一起输入同一个模型，让模型直接判断"这篇文档对回答这个问题有多大帮助"。这个匹配方式比向量相似度精细得多，代价是计算量更大，所以它不能替代第一步召回，而是作为精排。

我在实际项目里发现，重排这一步对效果的影响经常被人低估。有时候向量检索出来的 top-5 里有两条根本不相关的内容，如果不加过滤，模型就会被带偏；加上重排后，把不相关的内容踢出去，准确率能提升一个档次。

4.4 自我评判与纠偏（Self-RAG 思路）

这个模块负责回答"检索结果够不够好""生成的答案能不能信"两个问题。工程上最简化的做法是：加一个"质量评分"步骤，让模型对检索到的资料打分，比如是否相关、是否包含答案、是否存在矛盾，再决定继续生成的路线。

如果评分显示"资料相关但不足"，系统就进入下一轮检索；如果显示"资料之间有矛盾"，系统把矛盾信息单独提出来，让模型优先采用更新或更权威的来源；如果显示"资料足够但生成内容不忠实"，系统带着修正提示重新生成。

这套机制最直接的效果是减少幻觉。很多评测里，RAG 的"答案相关度"容易提升，但"答案忠实度"（回答是否严格基于检索内容）才是真正的分水岭。自我评判正是冲着忠实度去的。

4.5 路由（Routing）：先判断再选择

路由模块是整个系统的"调度员"。它负责判断当前用户问题应该走哪种处理流程。比如：简单常识性问题，不需要检索，直接让模型回答就行；需要查内部资料的问题，走 RAG 管道；涉及多轮对话澄清的，先反问用户再检索；涉及代码或结构化数据的，直接走专用查询接口。

路由的价值在于"不浪费资源"。很多实际系统里，大量问题是简单问题，没必要每次都跑完整 RAG 2.0 流程。路由模块用规则或轻量大模型分类就能实现，省下来的时间和成本相当可观。它也让系统面对复杂问题时有了弹性处理的余地。

5. 实操：一个人怎么搭一套 RAG 2.0

理论讲完，上实操。这里我按"一个人、一台开发机、一个开源技术栈"的假设，给你一套能跑通的最小实现方案。不用纠结具体产品选型，重点是理解每个环节为什么要这么放。

5.1 工具选型

先说现成的开源框架。LangChain 和 LlamaIndex 都提供了 RAG 管道的抽象，早期我用 LlamaIndex 比较多，它对索引、检索、重排的模块划分很清晰，适合理解概念。LangChain 胜在生态全，各种工具、模型、向量库都能接。现在也有很多新的编排框架在做"Agentic RAG"，本质上是把流程控制权交给大模型，这是另一个路子。

向量数据库我建议从 PostgreSQL 的向量插件或者轻量的开源向量库起步（比如 Chroma、Qdrant 这类），不要一开始就上重型的分布式方案。原因很简单：你的瓶颈大概率不在检索性能，而在检索质量，先把流程调通再说。

嵌入模型和重排模型是质量关键。嵌入模型负责召回，重排模型负责精排，两者是不同层面的能力。建议至少在重排环节用专门的重排模型，而不是简单复用嵌入模型。

提示：不要把嵌入模型和重排模型混为一谈。嵌入模型解决"哪些文档大概相关"，重排模型解决"哪些文档确实能回答当前问题"。两者合在一起，才是完整的召回链路。

5.2 流程设计

下面是一套标准 RAG 2.0 流程的伪代码。你可以把它当成设计蓝图，每个函数对应一个模块，实际开发时用你喜欢的框架去实现。

def rag2_answer(question, knowledge_base): # 1. 路由：判断是否需要检索 if not needs_retrieval(question): return llm.generate(question) # 2. 查询改写：把口语问题改成适合检索的形式 rewritten = rewrite_query(question) # 3. 多查询扩展：生成多个检索变体 queries = expand_queries(rewritten) # [q1, q2, q3] # 4. 混合召回：向量检索 + 关键词检索，合并去重 candidates = [] for q in queries: vec_hits = vector_search(q, knowledge_base) key_hits = keyword_search(q, knowledge_base) candidates = merge_candidates(candidates, vec_hits, key_hits) # 5. 重排：用强模型精排，去除噪声 ranked = rerank(candidates, question) useful_docs = filter_by_threshold(ranked, threshold=0.5) # 6. 自省：若资料不足，改写查询再来一轮 for _ in range(max_retries): score = evaluate_sufficiency(useful_docs, question) if score.adequate: break new_query = rewrite_based_on_missing(question, score.reason) new_docs = hybrid_search(new_query) useful_docs = merge_and_rerank(useful_docs, new_docs, question) # 7. 生成 + 忠实度校验 answer = llm.generate(question, context=useful_docs) check = verify_faithfulness(answer, useful_docs) if not check.is_faithful: answer = llm.regenerate(question, context=useful_docs, hint=check.reason) return answer, useful_docs # 附上引用来源

这套流程最核心的，是第 6 步的"自省循环"。你仔细观察就会发现，它把这轮检索能不能解答问题，作为一个显式的判断条件。这正是 RAG 1.0 和 2.0 的分水岭。

5.3 端到端小例子

我给你举个具体例子，就按伪代码的逻辑走一遍。假设知识库里有一份虚构的《员工手册》，里面有一条："工作满一年的员工，自次年起享有每年 5 天带薪年假；工作满五年，增加到每年 10 天。"

用户提问："我在这家单位已经干了六年了，今年能休几天年假？"

第一步，查询改写。模型把问题改成"工作满五年 年假天数 规定"，并补上一个关键识别："六年 > 五年，应适用满五年档位"。

第二步，多查询扩展。生成两个变体："工作满五年年假多少天""年假标准 5年工龄 10天"。

第三步，混合召回。向量检索命中"工作满一年 5 天"和"工作满五年 10 天"两块，关键词检索也可能命中包含"年假""满五年"的条款。

第四步，重排。重排模型判断"工作满五年，增加到每年 10 天"与问题最相关，排在前面；"工作满一年 5 天"也有参考价值，保留；其他无关片段被过滤掉。

第五步，生成。模型的输出是"根据手册规定，工作满五年后年假为每年 10 天。您在单位已满六年，满足这一档条件，因此今年可休 10 天年假。"

第六步，忠实度校验。模型检查发现"已满六年应适用满五年档"是一个推理结果，手册原文没有直接写"六年对应多少天"，但规则默认按档位累进，这种推理合逻辑且可追溯，校验通过。

对比 RAG 1.0，朴素流程很可能只检索到"工作满一年 5 天"这一条，然后给出"5 天"的错误答案——因为用户问题里的"六年"在文档里根本没有出现，向量检索可能把最相关的"满五年"漏掉。多一步改写、多一路召回、多一道重排，结果天差地别。

5.4 效果评估：别只盯着"答得对不对"

搭好系统后，评估是另一个坑。很多人用两三个测试问题试一下，感觉"还行"就上线了，结果在真实流量里翻车。规范化做法是建一个评估集，至少包含几十到上百条有标准答案的问题，然后从三个维度打分：

第一，检索质量：回答所需的关键文档是否被成功召回？可以计算召回率（Retrieval Recall）和 MRR（平均倒数排名）。第二，生成质量：答案是否相关、是否完整、是否正确。第三，忠实度：答案里的每个关键结论，是否都能在检索到的文档里找到依据。忠实度这个指标最容易被忽略，又恰恰是 RAG 区别于普通对话的最大价值——因为"正确但编造"比"错误但明说"更危险。

现在的做法是把大模型本身当裁判，让另一个模型按维度给答案打分，或者用专门的开源评测数据集跑一遍。成本不高，但能帮你发现很多自己试不出来的边界情况。我见过太多项目，召回率其实只有 40%，但因为测试问题刚好命中，团队以为效果很好，实际上线后被用户差评淹没。评估这步省不得。

6. 常见问题与排查技巧实录

下面这些问题，是我和身边同行在 RAG 2.0 落地过程中真实踩过的，分享出来，你可以对照自查。

6.1 检索结果相关，答案还是错

这是最让人崩溃的情况：你手工检查检索结果，发现关键文档都在，但模型答出来还是错的。排查时先看提示词，是不是没有明确要求"只基于资料回答"并且"不要使用资料外的知识"。

第二个常见原因是检索结果里有互相矛盾的文档。比如新旧制度都在库里，模型不知道该信哪个。解决办法是给文档加元数据（版本号、生效日期、来源），在检索阶段按优先级过滤，或者把"采用最新生效版本"写进提示词。

第三个原因是上下文太长、关键信息被淹没。检索了 top-5，每块 512 字，塞进去 2500 多字，真正的答案只有一句话，模型容易被大量无关内容带偏。这时要么降低 top-k，要么在重排后只保留真正有用的两三条，要么让模型先"逐条判断是否有用"再回答。

6.2 加了重排反而更差

重排模型并非万能。如果你的重排模型和嵌入模型来自不同体系，且重排模型比较弱，排序结果可能还不如向量检索原始顺序。我遇到过重排模型对长文本处理不稳定，把正确答案排到后面的情况。

解决办法：第一，重排模型尽量选更强的交叉编码器类型；第二，不要只取重排后的 top-1，至少保留 top-2 到 top-3，给生成阶段留余地；第三，做 A/B 测试，分别跑"带重排"和"不带重排"，用召回率和端到端答案质量对比，别凭感觉拍板。

6.3 自省循环死循环，一直检索不完

自省循环给了系统"再来一次"的能力，但也可能让它"永远再来一次"。最常见的原因是评判标准太松，模型总觉得自己不够满意，于是一轮一轮没完。

解决办法是给循环加硬性限制：最多 2 到 3 轮，到上限后就算质量一般也直接生成。另外，把"够用"的标准写具体：比如"如果检索结果中已经包含了回答该问题的关键信息，就认为足够"，比笼统的"资料够不够"更能防止模型钻牛角尖。

6.4 Token 成本爆炸

RAG 2.0 每一步都在花钱：查询改写一次调用、多查询扩展三到五次调用、重排模型推理、自省循环又要调用、生成后校验还要调用。一条复杂问题跑下来，token 消耗可能是 RAG 1.0 的十到十五倍，账单会给你一个惊喜。

省钱思路：一是给不同问题分流，简单问题走轻量流程；二是把多查询扩展和自省循环设置为"仅在检索质量低时触发"，用阈值控制；三是善用缓存，高频问题的检索结果和改写结果可以缓存，没必要每次重新算；四是控制循环上限，并给重排设置数量上限。RAG 2.0 的优势是质量，但成本控制做不好，系统再聪明也上不了生产。

6.5 常见问题速查表

7. 我实际跑完之后的几条体会

最后说点实在话。RAG 2.0 不是某个单一技巧，而是一整套"把检索增强生成当作系统来设计"的思维方式。我搭过几套不同复杂度的方案，总体上感受是：效果提升最明显的，往往不是最先进的技术，而是最基础的三个动作——查询改写、混合检索、重排。这三样做好，大部分知识库问答项目的体验就能从"不能用"变成"能用"。

自省和校验这类高级能力，则更适合对准确率要求极高的场景。它们能帮你从 90 分往 95 分靠，但每往上走一分，成本和复杂度都是指数级上升。所以我的建议是：先搭一个带改写、混合检索、重排的最小系统，跑一段时间，把评估集建起来，看看真正的短板在哪，再决定要不要引入循环检索和自我评判。一步到位把所有模块都上全，大概率是在为想象中可能存在的问题付费。

还有一条经验，算是踩过几次坑后的总结：RAG 2.0 再怎么进化，提示词和文档质量依然是地基。文档本身结构混乱、内容表述不清、动不动就是大段表格和扫描件，检索器再聪明也救不回来。我每次做新项目，都会先去跟业务方争取一块时间做文档治理，把高频问题对应的内容整理成结构化、干净的文本，这个投入的产出比，往往比调任何参数都高。

最后再分享一个小技巧：日志一定要把"检索到了什么""重排保留了什么""模型基于什么生成的"完整记录下来。问题复现和排查的时候，这套日志的价值无可替代。它让我几乎每次都能在十分钟内定位到是召回的问题、重排的问题，还是生成的问题。没有这套记录，你面对一个错误答案，就只能靠猜。而做 RAG 这件事，靠猜是走不远的。