从Claude 3.5升级到3.7：RAG系统召回率下降的架构优化实战

1. 从一次失败的模型升级说起

最近团队里有个事儿挺有意思，我们负责的一个智能问答系统，核心的检索增强生成（RAG）模块，一直用的是Claude 3.5 Sonnet。效果嘛，中规中矩，用户反馈的“答非所问”率大概在15%左右，属于能接受但还有优化空间。上个月，看到Anthropic发布了Claude 3.7 Sonnet，官方宣传在代码、数学和推理能力上都有显著提升，尤其是长上下文处理更好了。我们一想，这RAG场景不就是大量文档检索然后生成答案吗？长上下文能力强，意味着模型能更好地“消化”我们塞给它的检索结果，生成更精准的回复，召回率（Recall）理论上应该会提升啊。

于是，我们兴冲冲地做了升级。流程很标准：更新API调用端点，把模型版本号从claude-3-5-sonnet-20241022换成claude-3-7-sonnet-20250219，调整了一下预算，跑了一遍完整的测试集。结果出来，大家都傻眼了。关键的业务指标——答案的召回率，不仅没升，反而从之前的78.5%跌到了72.1%。精确率（Precision）倒是微微涨了一点，但整体F1分数是下降的。这就像你给汽车换了个马力更大的新引擎，结果百公里加速反而变慢了，这完全不符合直觉。

问题出在哪儿？一开始我们怀疑是测试集有问题，或者是新模型对prompt更敏感了。我们反复调整了系统指令（System Prompt），优化了检索结果的格式，甚至尝试了不同的温度（Temperature）参数，但召回率始终在72%附近徘徊，无法回到之前的水平。这让我意识到，问题可能不在模型本身，也不在表面的调用参数上。我们很可能在系统架构设计上，埋下了一颗与新一代大模型特性不匹配的“雷”。这次迁移，只是踩响了它。

2. 召回率下降的“元凶”：新旧模型的能力边界差异

要定位问题，我们得先抛开“新模型一定更好”的思维定势，深入理解Claude 3.5和3.7在能力边界上的具体差异。官方文档和社区评测都指出，Claude 3.7在复杂推理、遵循指令的严谨性以及“拒绝回答不确定问题”的倾向上有增强。这对RAG系统来说，是一把双刃剑。

2.1 更严格的指令遵循与“保守化”倾向

Claude 3.7被训练得更倾向于严格遵循用户的指令和系统设定的角色。在我们旧的系统指令中，有这样一句话：“请基于提供的检索文档片段，生成一个全面且准确的答案。如果文档中的信息不足以完全回答问题，你可以进行合理的推断或补充常识。”

在Claude 3.5时代，这个指令工作得不错。模型会努力从提供的片段中拼凑答案，对于模糊或间接相关的信息，它敢于做出一些概率上的连接和推断，这在一定程度上提升了召回率——即使文档没有直接命中问题，模型也可能“蒙对”一部分。

但Claude 3.7对此的处理截然不同。它对“信息不足以完全回答”这个条件判断变得极其严格。当它认为检索到的文档没有百分之百、清晰无误地包含答案所需的所有要素时，它更倾向于采取一种“保守策略”：要么在答案中明确指出来源不足的部分，要么直接生成一个非常简短、只包含绝对确定信息的答案，甚至有时会建议用户重新查询。在我们的测试中，许多原本3.5能通过“连蒙带猜”给出部分正确答案的案例，3.7直接给出了“根据提供文档，无法确定...”或一个极其简略的答案，导致该问题被判为“未召回”。

2.2 长上下文优化带来的“注意力稀释”

第二个关键差异在于长上下文处理。Claude 3.7确实能处理更长的上下文，但它的工作机制可能优化了对长文本中关键信息的聚焦和去重。我们的旧架构为了提升召回率，普遍采用了一种“广撒网”策略：对于用户的一个问题，检索模块会返回5-8个可能相关的文档片段（chunk），有时总长度超过8000个token，然后一股脑塞给模型。

我们的假设是：给模型更多材料，它总能找到有用的。这在Claude 3.5上部分有效。但Claude 3.7的长上下文优化，可能包含了对冗余、低质量信息的更强过滤机制。当它面对多个相关性参差不齐的片段时，反而可能因为需要评估和协调过多信息，导致对核心相关片段的注意力被稀释，或者因为片段间存在细微矛盾而更加谨慎，最终影响了从海量信息中准确提取答案的能力。

2.3 对检索结果质量的要求阈值提高

本质上，Claude 3.7像一个更聪明但也更“挑剔”的专家。Claude 3.5像一个有经验的中级工程师，你给他一堆杂乱的需求文档和部分代码，他能大概猜出你要做什么，并给你一个可用的方案。而Claude 3.7像一个资深架构师，你给他同样杂乱的材料，他会先花时间厘清需求的矛盾点，指出文档的缺失项，然后要求你提供更清晰、更权威的输入，否则他宁愿不给出完整方案，只评审现有材料。

这意味着，我们之前那套“检索模块只管召回尽可能多的相关文本，生成模块自己去芜存菁”的粗放架构，已经跟不上模型进化了。新模型对输入质量（即检索结果的质量）的要求阈值大幅提高。低质量、多噪声的检索结果，在3.5时代可能被容忍并部分利用，在3.7时代则会直接导致模型“罢工”或输出质量下降。

3. 架构层面的“雷区”自查清单

基于上面的分析，我梳理了几个在从Claude 3.5迁移到3.7（或类似的能力增强型模型）时，最容易导致召回率不升反降的架构设计“雷区”。你可以对照检查自己的系统。

3.1 检索模块与生成模块的“脱节”设计

这是最经典的“雷”。很多RAG系统在设计时，检索和生成是两个独立的、通过接口连接的子系统。检索模块的目标是优化自己的指标，比如检索命中率（Hit Rate）或MRR（平均倒数排名），它倾向于返回更多、更全的结果以确保覆盖率。而生成模块则被动接受这些结果。

• 问题表现：检索模块返回了10个片段，其中只有前2个是高度相关的，后面8个是弱相关或噪声。Claude 3.5可能会主要关注前2个，并忽略后面的噪声。但Claude 3.7可能会因为后8个噪声片段的存在，而怀疑整个检索结果集的质量，或者花费额外精力去“证伪”这些噪声，从而影响了对核心片段的信息提取效率。
• 自查方法：检查你的检索模块是否只追求“召回数量”？是否缺乏对返回结果的重排序（Re-ranking）或相关性评分过滤机制？检索和生成模块之间是否只是一个简单的“文本块列表”传递？

3.2 文档分块（Chunking）策略过于僵化

很多系统为了处理方便，采用固定的分块大小（如512或1024个token）和重叠窗口。这种策略没有考虑文档的实际语义结构。

• 问题表现：一个完整的答案可能被生硬地切割在两个不同的chunk中。Claude 3.5凭借较强的上下文理解能力，有时能跨chunk“脑补”出完整信息。但更严谨的Claude 3.7，如果主要依据的那个chunk信息不完整，它就可能判断为“信息不足”，而不会主动去另一个chunk寻找缺失部分，因为它被训练得更依赖当前提供的、明确的上下文。
• 自查方法：你的分块策略是简单的按字符/Token数切割，还是考虑了段落、标题等语义边界？是否针对不同类型的文档（如技术手册、Q&A列表、长篇文章）采用了不同的分块策略？

3.3 系统指令（System Prompt）未能与时俱进

系统指令是塑造模型行为的关键。为Claude 3.5设计的指令，可能不适用于3.7。

• 问题表现：指令中包含了模糊的、鼓励“创造性”或“推断”的词语，如“尽可能发挥”、“合理推测”。这在3.5上可能促进了召回，但在3.7上可能导致模型因不愿进行“不合理”的推测而变得保守。或者，指令没有明确要求模型“严格依据检索结果”，导致3.7过度依赖自身知识而忽略了提供的文档。
• 自查方法：仔细审查你的System Prompt。是否需要为3.7设计更精确、更结构化、更强调“基于给定来源”的指令？例如，明确指令：“你的回答必须严格且仅基于以下提供的检索上下文。如果上下文中的信息不足以直接回答问题的所有部分，请明确指出哪些部分无法从上下文中找到答案。”

3.4 缺乏对检索结果的“预处理”与“增强”

直接扔给模型一堆原始文本片段，是最简单的做法，但可能不是最优的。新模型的能力，需要更高质量的输入来匹配。

• 问题表现：检索到的文本片段包含无关的页眉页脚、广告代码、重复内容或格式混乱的标记。这些噪声会干扰模型对核心内容的判断。
• 自查方法：在检索结果送入生成模型前，是否有清洗、去重、格式化的流水线？是否考虑过对多个相关片段进行摘要或信息融合，生成一个更精炼、信息密度更高的上下文，再交给模型？这可以显著降低模型的认知负荷。

4. 针对性的架构优化与实战调整

找到“雷区”后，我们进行了一系列架构和策略调整，最终不仅让Claude 3.7的召回率恢复并超过了原有水平，整个系统的答案质量也上了一个台阶。以下是我们的实战调整方案。

4.1 引入两阶段检索与重排序（Re-ranking）

我们彻底改变了“一检即用”的模式，引入了轻量级但效果显著的重排序层。

1. 第一阶段：粗检索。沿用原来的向量检索器（比如用的是OpenAI的text-embedding-3-small），从知识库中召回Top 20个相关的文本块。这一步的目标是保证召回率，宁可多，不可漏。
2. 第二阶段：精排序。我们引入了一个专门的交叉编码器（Cross-Encoder）模型，例如BAAI/bge-reranker-large。这个模型不负责从海量数据中找东西，它的任务更专一：对“用户问题”和“每一个候选文本块”进行深度相关性打分。它比向量检索的相似度计算更准确，因为它能同时看到问题和文本，进行深度的语义匹配。
3. 过滤与截断。根据交叉编码器的打分，我们只保留Top 3（具体数量可根据场景调整）得分最高的片段。同时，设定一个相关性分数阈值（比如0.7），低于这个阈值的片段即使排名靠前也直接丢弃，因为它们很可能是噪声。

这样，最终传递给Claude 3.7的，是经过深度评估的、最相关、最精炼的少量信息。这完美匹配了3.7对输入质量的高要求。调整后，虽然检索阶段返回的片段数量变少了，但质量极高，Claude 3.7的“信心”明显增强，召回率大幅回升。

4.2 实现动态化、语义化的文档分块

我们放弃了固定的分块大小，转向了基于语义的分块策略。

• 工具选择：我们使用了LangChain的RecursiveCharacterTextSplitter，但它不是简单按字符切。我们优先按文档的天然分隔符来切分，比如Markdown的标题（#，##）、LaTeX的章节（\section）、甚至是代码文件中的函数定义。对于普通文本，则按段落、句子进行递归分割，确保每个chunk在语义上尽可能完整。
• 重叠策略优化：我们不再使用固定的重叠token数，而是改为“按句子重叠”。例如，设置重叠2个句子，这能更好地保证被切开的语义上下文，在相邻chunk中有延续性。
• 分块后处理：对每个chunk，我们不仅存储其文本和向量，还额外存储了它的“元信息”，比如它来自哪个文档的哪个章节/标题下。这个信息有时可以在构造prompt时提供给模型，帮助它理解上下文。

4.3 重构系统指令与提示工程

我们为Claude 3.7量身定制了新的系统指令和用户消息格式。

• 系统指令示例：

  你是一个严谨的问答助手。你的任务是根据用户问题，严格依据且仅依据下面提供的“参考上下文”来生成答案。 参考上下文由一段或多段文本组成，它们是与问题最相关的信息。 你的回答必须：

  1. 直接、准确地回答用户问题。
  2. 答案中的每一个关键事实或主张，都必须能在提供的参考上下文中找到明确支持。
  3. 如果参考上下文中的信息足以回答问题的全部，请给出完整答案。
  4. 如果参考上下文中的信息只能回答问题的部分，请只回答那部分，并明确指出：“根据上下文，关于XX部分的信息未能找到。”
  5. 如果参考上下文与问题完全不相关或信息不足，请直接回答：“根据提供的资料，我无法回答这个问题。” 禁止在答案中引入参考上下文以外的知识或进行推测。

• 用户消息格式优化：我们采用了更结构化的格式来呈现检索结果，而不是简单的文本拼接。

  用户问题：{用户的问题} 参考上下文开始： [片段1来源]：{片段1文本} --- [片段2来源]：{片段2文本} --- [片段3来源]：{片段3文本} 参考上下文结束。 请根据以上参考上下文回答问题。

  这种清晰的边界和来源标注，有助于模型区分指令、问题和参考材料，减少混淆。

4.4 实施检索结果的后处理与增强

在重排序之后、发送给大模型之前，我们增加了一个“上下文构建”环节。

• 去重与清洗：使用简单的文本相似度算法（如MinHash LSH）去除高度重复的片段。同时，用正则表达式清洗掉HTML标签、无意义的乱码等。
• 信息融合（可选进阶）：对于特别复杂的问题，当多个相关片段从不同角度阐述了同一件事时，我们会先用一个小型、快速的LLM（比如GPT-3.5-Turbo或Claude Haiku）对这些片段进行摘要和整合，生成一个连贯、简洁的背景摘要，然后将这个摘要和最关键的一两个原始片段一起送给Claude 3.7。这相当于为3.7配备了一个“信息预处理助理”，进一步提升了输入的信息密度和质量。

5. 效果验证与性能权衡

经过上述架构调整后，我们重新在测试集上进行了评估。

• 召回率（Recall）：从迁移后的72.1%提升到了85.3%，显著超过了原来Claude 3.5的78.5%。
• 精确率（Precision）：从原来的小幅提升，到现在的显著提升，因为低质量答案和“幻觉”回答大幅减少。
• 整体F1分数：达到了历史最佳水平。
• 用户反馈：最直观的感受是，答案变得更加“笃定”和“有据可查”了。模糊两可、包含“可能”、“也许”的答案减少了。

当然，这些优化不是没有代价的：

• 延迟增加：两阶段检索（尤其是交叉编码器重排序）增加了约100-200ms的延迟。信息融合步骤如果启用，会增加更多。
• 成本变化：虽然重排序模型通常是本地部署的小模型，成本可忽略，但因为我们传递给Claude 3.7的上下文更短更精炼，实际的大模型Token使用量是下降的。综合算下来，单次查询的总体成本变化不大，甚至略有下降，因为大模型处理的低效噪声Token减少了。
• 系统复杂性：架构从简单的“检索-生成”变成了“检索-重排序-后处理-生成”，运维和调试的复杂度提高了。

这是一个典型的权衡：用一定的架构复杂性和少量延迟，换取最终答案质量的显著提升。对于大多数对准确性要求高的生产级RAG系统来说，这个交换是非常值得的。

6. 迁移前后的 checklist 与持续迭代

最后，总结一下从类似Claude 3.5升级到3.7这类“更聪明、更严谨”模型时，你应该做的事情：

1. 不要假设平滑升级：心理上做好准备，新模型可能需要你调整系统才能发挥全力。
2. 建立精细化评估体系：不要只看整体F1。拆解你的测试集，看看召回率下降具体发生在哪类问题上？是事实型问题、推理型问题还是总结型问题？这能给你最直接的线索。
3. 优先检查检索质量：这是最可能出问题的地方。用新模型测试时，可以人工抽查一批召回失败的案例，看看当时检索模块返回的是什么“垃圾”。十有八九，问题根源在此。
4. 迭代你的Prompt：根据新模型的“性格”（更严谨/更保守/更遵循指令），重写你的System Prompt和上下文格式。把它当成一个新员工，你需要重新进行“上岗培训”。
5. 考虑引入重排序：如果你的应用对准确性要求高，强烈建议加入一个轻量级重排序步骤。这是提升RAG系统天花板性价比最高的方法之一。
6. 监控与A/B测试：全量切换前，一定要做充分的A/B测试。监控核心指标的同时，也要关注延迟和成本的变化。

我们这次迁移踩的坑，根本原因在于用旧架构的“马车”去拉新模型的“引擎”。大模型在快速进化，从“大力出奇迹”走向“精细化和专业化”，我们的系统架构也必须随之进化，从“粗放管道”走向“精炼流水线”。下一次，当Claude 4.0或者其他什么更强大的模型发布时，我会首先问自己的不是“它有多强”，而是“我的系统，配得上它吗？”