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数切割还是考虑了段落、标题等语义边界是否针对不同类型的文档如技术手册、QA列表、长篇文章采用了不同的分块策略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我们彻底改变了“一检即用”的模式引入了轻量级但效果显著的重排序层。第一阶段粗检索。沿用原来的向量检索器比如用的是OpenAI的text-embedding-3-small从知识库中召回Top 20个相关的文本块。这一步的目标是保证召回率宁可多不可漏。第二阶段精排序。我们引入了一个专门的交叉编码器Cross-Encoder模型例如BAAI/bge-reranker-large。这个模型不负责从海量数据中找东西它的任务更专一对“用户问题”和“每一个候选文本块”进行深度相关性打分。它比向量检索的相似度计算更准确因为它能同时看到问题和文本进行深度的语义匹配。过滤与截断。根据交叉编码器的打分我们只保留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量身定制了新的系统指令和用户消息格式。系统指令示例你是一个严谨的问答助手。你的任务是根据用户问题严格依据且仅依据下面提供的“参考上下文”来生成答案。 参考上下文由一段或多段文本组成它们是与问题最相关的信息。 你的回答必须直接、准确地回答用户问题。答案中的每一个关键事实或主张都必须能在提供的参考上下文中找到明确支持。如果参考上下文中的信息足以回答问题的全部请给出完整答案。如果参考上下文中的信息只能回答问题的部分请只回答那部分并明确指出“根据上下文关于XX部分的信息未能找到。”如果参考上下文与问题完全不相关或信息不足请直接回答“根据提供的资料我无法回答这个问题。” 禁止在答案中引入参考上下文以外的知识或进行推测。用户消息格式优化我们采用了更结构化的格式来呈现检索结果而不是简单的文本拼接。用户问题{用户的问题} 参考上下文开始 [片段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这类“更聪明、更严谨”模型时你应该做的事情不要假设平滑升级心理上做好准备新模型可能需要你调整系统才能发挥全力。建立精细化评估体系不要只看整体F1。拆解你的测试集看看召回率下降具体发生在哪类问题上是事实型问题、推理型问题还是总结型问题这能给你最直接的线索。优先检查检索质量这是最可能出问题的地方。用新模型测试时可以人工抽查一批召回失败的案例看看当时检索模块返回的是什么“垃圾”。十有八九问题根源在此。迭代你的Prompt根据新模型的“性格”更严谨/更保守/更遵循指令重写你的System Prompt和上下文格式。把它当成一个新员工你需要重新进行“上岗培训”。考虑引入重排序如果你的应用对准确性要求高强烈建议加入一个轻量级重排序步骤。这是提升RAG系统天花板性价比最高的方法之一。监控与A/B测试全量切换前一定要做充分的A/B测试。监控核心指标的同时也要关注延迟和成本的变化。我们这次迁移踩的坑根本原因在于用旧架构的“马车”去拉新模型的“引擎”。大模型在快速进化从“大力出奇迹”走向“精细化和专业化”我们的系统架构也必须随之进化从“粗放管道”走向“精炼流水线”。下一次当Claude 4.0或者其他什么更强大的模型发布时我会首先问自己的不是“它有多强”而是“我的系统配得上它吗”
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数切割还是考虑了段落、标题等语义边界是否针对不同类型的文档如技术手册、QA列表、长篇文章采用了不同的分块策略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我们彻底改变了“一检即用”的模式引入了轻量级但效果显著的重排序层。第一阶段粗检索。沿用原来的向量检索器比如用的是OpenAI的text-embedding-3-small从知识库中召回Top 20个相关的文本块。这一步的目标是保证召回率宁可多不可漏。第二阶段精排序。我们引入了一个专门的交叉编码器Cross-Encoder模型例如BAAI/bge-reranker-large。这个模型不负责从海量数据中找东西它的任务更专一对“用户问题”和“每一个候选文本块”进行深度相关性打分。它比向量检索的相似度计算更准确因为它能同时看到问题和文本进行深度的语义匹配。过滤与截断。根据交叉编码器的打分我们只保留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量身定制了新的系统指令和用户消息格式。系统指令示例你是一个严谨的问答助手。你的任务是根据用户问题严格依据且仅依据下面提供的“参考上下文”来生成答案。 参考上下文由一段或多段文本组成它们是与问题最相关的信息。 你的回答必须直接、准确地回答用户问题。答案中的每一个关键事实或主张都必须能在提供的参考上下文中找到明确支持。如果参考上下文中的信息足以回答问题的全部请给出完整答案。如果参考上下文中的信息只能回答问题的部分请只回答那部分并明确指出“根据上下文关于XX部分的信息未能找到。”如果参考上下文与问题完全不相关或信息不足请直接回答“根据提供的资料我无法回答这个问题。” 禁止在答案中引入参考上下文以外的知识或进行推测。用户消息格式优化我们采用了更结构化的格式来呈现检索结果而不是简单的文本拼接。用户问题{用户的问题} 参考上下文开始 [片段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这类“更聪明、更严谨”模型时你应该做的事情不要假设平滑升级心理上做好准备新模型可能需要你调整系统才能发挥全力。建立精细化评估体系不要只看整体F1。拆解你的测试集看看召回率下降具体发生在哪类问题上是事实型问题、推理型问题还是总结型问题这能给你最直接的线索。优先检查检索质量这是最可能出问题的地方。用新模型测试时可以人工抽查一批召回失败的案例看看当时检索模块返回的是什么“垃圾”。十有八九问题根源在此。迭代你的Prompt根据新模型的“性格”更严谨/更保守/更遵循指令重写你的System Prompt和上下文格式。把它当成一个新员工你需要重新进行“上岗培训”。考虑引入重排序如果你的应用对准确性要求高强烈建议加入一个轻量级重排序步骤。这是提升RAG系统天花板性价比最高的方法之一。监控与A/B测试全量切换前一定要做充分的A/B测试。监控核心指标的同时也要关注延迟和成本的变化。我们这次迁移踩的坑根本原因在于用旧架构的“马车”去拉新模型的“引擎”。大模型在快速进化从“大力出奇迹”走向“精细化和专业化”我们的系统架构也必须随之进化从“粗放管道”走向“精炼流水线”。下一次当Claude 4.0或者其他什么更强大的模型发布时我会首先问自己的不是“它有多强”而是“我的系统配得上它吗”
)
