做 LLM 应用的人大概都经历过这样一个阶段给模型配上搜索引擎却发现答案总是差一口气。第一反应往往是换引擎——商业 API 换一家或者干脆自建一个聚合搜索调完接口继续试质量好像提升了一点又好像没有本质变化。直到我认真看了一项关于 LLM 联网搜索的基准测试才意识到问题可能从一开始就找错了方向。这项测试的标题本身就非常直白在 LLM 联网搜索中更多次搜索胜过更好的搜索引擎。换句话说同样一个模型对一个查询多搜几轮、多取几块信息效果往往比把底层引擎从“一般”换成“更好”还要明显。这个判断乍看反直觉因为它挑战了“工具越强结果越强”的直觉。但放到 LLM 的工作方式里它其实一点都不意外。这篇文章想把背后的机制、落地方法和适用边界一次讲清楚也顺便聊聊为什么很多团队在这件事上花了冤枉钱。1. 先理解基准测试里比的不是“搜索质量”而是“组合效果”1.1 测试到底在控制什么变量一项把搜索能力接入 LLM 的基准测试测的往往不是“搜索引擎本身好不好”而是“模型 搜索”这个组合最终能不能答对问题。所以设计上一般会尽量控制住模型、提示词、结果处理方式这些变量只让两件事发生变化底层搜索引擎是谁返回的结果质量如何模型在回答之前允许执行几次搜索以及每轮搜索之间是否有信息补充。当这两组对照同时存在时标题给出的结论才有意义搜索次数对最终答案的影响大于搜索引擎本身的差异。这里有一个容易误读的地方。不是说所有搜索引擎都一样也不是说换引擎完全没用。而是说在“模型 搜索”这个组合里检索只是整个链路的一段。排序精度的差异在经过“取回 - 截断 - 拼接 - 生成”之后会被明显稀释。而搜索次数直接影响的是模型拿到的信息覆盖面。覆盖面才是决定答案能不能“拼出来”的关键而不只是“搜得准不准”。1.2 为什么“更好的引擎”没有带来碾压优势搜索引擎是为人类设计的不是为模型设计的。人的阅读习惯是看排名靠前的链接点进页面自己判断而 LLM 联网搜索通常只拿摘要片段然后把多个片段拼合成答案。这意味着人类眼里“排在最前面很重要”但模型拼答案时更需要的是不同来源、不同角度、不同时间点的片段组合主流搜索引擎在处理常见问题时精度差异很小真正的差距体现在长尾信息上长尾信息往往不在前三名里如果只取 top-k 个摘要再好的长尾内容也进不了上下文。所以把引擎从 A 换成 B改善的往往是检索精度的“上半场”。而 LLM 回答问题更像是在打“下半场”已经拿到一批材料之后能不能找到缺口、补齐证据、完成推理。这个下半场主要由搜索轮次和查询策略决定。从工程经验看这个判断对多数团队都是好消息。因为换引擎往往要改 API、改解析、改计费逻辑成本不低而增加搜索轮次通常只是改一个循环参数和查询生成逻辑。同样是提升效果后者的改动面小得多。2. 单次搜索为什么总是不够信息是拼出来的不是搜出来的2.1 一个查询只有一种措辞一次机会搜索的起点是一个查询字符串。模型用“什么原因导致某问题发生”去搜搜索引擎就会按这个措辞理解意图。但同一个问题换一个角度提问返回的结果可能完全不同。复杂问答很少只依赖一个页面就能完整回答它往往需要不同来源的不同说法相互印证不同时间点的信息做时效对比不同子问题分别检索再合并推理。单次搜索等于只给了模型一扇窗。窗口里有什么答案就局限在什么范围里。这也解释了一个常见困惑为什么模型明明能联网遇到稍微复杂一点的问题还是答得像在猜。不是模型不行是它只被允许看了一页资料。2.2 多轮搜索的本质让模型像人一样去“查资料”人在做一份调研时不会只搜一次就下结论。第一轮搜索往往是建立底图中间发现某个数字来源不可信会再搜一条验证某个专有名词不认识会再补一次定义查询写完初稿还可能要回头确认最新数据。模型的多次搜索做的其实是同样的事。只不过它需要自己判断“我还缺什么”然后生成下一轮查询。这恰恰是“搜索次数”能成为比“引擎质量”更稳定的预测因子的原因只要模型具备基本的查询改写能力多搜几轮就能稳定地扩大信息覆盖而引擎升级带来的边际收益会随着排序精度已经较高而迅速递减。换句话说更多搜索是在提升模型“看到更多世界”的概率换引擎只是让模型“把同一扇窗户擦得更干净”。2.3 多搜不是重复搜查询多样性才是关键这里要划一个重点。如果每一轮搜索都用同一个查询只是把结果页数增加那么多搜的优势会大打折扣。真正有效的“多搜”是让每轮查询之间产生差异把原问题拆成子问题例如“这个方案的适用场景”和“这个方案的局限”分开搜更换表述从“如何做 A”换成“A 的常见坑”加限定条件例如时间范围、站点来源、文件类型针对缺失信息做反问上一轮没提到成本下一轮就专门搜成本。基准测试把“更多搜索”和“更好引擎”放在一起比较本质上是在比较两种投资方向投资在检索精度上还是投资在探索广度上。至少在 LLM 问答这个场景里后者的回报更明显。注意如果发现日志里每一轮查询几乎一样那不是“多搜”是“重复搜”。多轮搜索的收益来自查询多样性而不是提交次数。3. 真正值得优化的是把“搜索次数”变成“搜索策略”3.1 一个可复用的三层检索框架把“多搜几次”工程化不能只是简单地把搜索函数多调用几次。直接把一个查询循环提交 5 遍浪费预算效果还不如单次搜索。我自己在项目里一般会用一个三层框架第一层基线检索。直接用原始问题去搜取回 3 到 5 个权威结果作为整轮回答的事实底座。第二层子问题补检。让模型先拆解问题列出 2 到 4 个必须回答的子问题逐个独立检索。这一层负责把覆盖面打开。第三层求证与补缺。把前两轮的结果合并让模型判断哪些关键信息缺失哪些来源相互冲突。对缺失信息做定向补搜对冲突信息增加一次“求证搜索”。最后收口时把三轮结果按来源权重和时效性合并去重再交给生成环节。这个框架的价值不是让模型每次都搜满 8 轮而是让每一轮搜索都有明确动机。搜索层查询来源主要作用典型轮次基线检索原始问题建立事实底座1子问题补检模型拆解出的子问题扩大信息覆盖面2-4求证与补缺缺失信息 / 冲突信息提升可信度1-33.2 框架、平台和工具链能帮你做哪些事现在很多 RAG 增强方案和 LLM 工具调用机制已经在支持这种多轮搜索。至少有三种落地方式让模型自己调用搜索工具通过 function calling / tool use模型每一轮都能决定搜什么、什么时候停。这种方式最灵活但对模型的自主性要求高。用工作流平台编排像 Dify 这类平台可以在节点里配置多次搜索、条件分支和结果合并适合不想写太多代码的团队。自己在应用层写循环把“查询生成 - 搜索 - 结果合并 - 判断是否继续”做成循环体。这种方式可定制性最高也是下一节最小流程的基础。选择哪种方式取决于你的模型对工具调用的支持程度以及你是否需要在中间环节插入人工判断。如果在某个 provider 上遇到工具调用 schema 被拒报错信息里出现类似 provider rejected the request schema or tool payload 的内容多半是模型版本不支持某个参数或者返回格式不匹配。这属于工具链层的兼容问题不一定要靠改搜索策略解决。3.3 成本和质量不是对立的是分级管理的多搜几次确实会带来 API 成本和延迟上升。但如果因此放弃多轮搜索等于把质量上限锁死在单次检索的覆盖面上。更务实的做法是按问题复杂度分级简单事实问题1 次搜索直接回答常规问答2 到 3 次搜索基线加一次子问题补检调研型问题4 到 6 次搜索完整走三层框架争议性问题或深度报告8 次以上并且在求证环节多加权重。判断一个查询属于哪一级可以在前端用另一个轻量模型做路由也可以用规则做关键词匹配。先分级再分配搜索预算成本就不会失控。4. 落地一个“多搜几次”的最小流程4.1 前置条件与最小实现实现这个流程需要四样东西一个支持工具调用或函数调用的 LLM一个搜索 API 或自建搜索引擎接口一个结果缓存避免不同会话对同一查询重复计费一个能把多轮搜索结果合并去重的处理函数。最小流程的代码结构大致长这样。注意这只是一个常见的实现骨架具体函数名和参数要以你使用的 SDK 为准不要直接照抄。# 示例结构多轮搜索的最小循环 def answer_with_multi_search(question, max_rounds3): merged_results {} query_list [question] # 第一轮原始问题 for round_idx in range(max_rounds): new_results [] for query in query_list: hits search_api(query, top_k5) new_results.extend(hits) merge_dedup(merged_results, new_results) # 按 URL/标题去重 # 判断是否还需要下一轮 evidence format_for_prompt(merged_results) need_more, next_queries llm_decide(evidence, question) if not need_more: break query_list next_queries # 通常是拆解后的子问题或补缺查询 # 收口合并 - 裁剪 - 生成 context truncate(format_for_prompt(merged_results), max_chars8000) return llm_generate(question, context)这个结构有三个关键点。第一每一轮的查询列表都必须来自上一轮的信息缺口而不是把同一个查询重复提交。第二结果合并一定要做去重和截断不然第 5 轮之后上下文里会出现大量重复段落。第三循环必须设置最大轮次防止模型在某个问题上无限搜索下去。4.2 参数理解先别急着把值拉满几个容易踩坑的参数逐个说一下top_k每一轮每个查询取几条结果。我一般取 3 到 5 条。取太多摘要片段互相重复还挤占上下文取太少覆盖面不够。每轮总结果数和 top_k 配合使用。理想状态是“每轮都有新信息”而不是“每轮都堆满”。max_rounds最大搜索轮次。默认给 3 轮足够做基线加子问题加一次补缺。调研型任务再调高但一般不建议超过 8。上下文裁剪合并后给生成模型的上下文长度。长上下文模型能装更多但不要指望模型依赖几万字背景去回答一个 50 字的问题注意力会被稀释。缓存用查询语句做 key加时间戳失效。同一问题被反复问时能省掉大量重复计费。这里有一个通用经验单次跑通只能说明流程没有断真正麻烦的是批量任务、异常重试和长期维护。所以不要一上来就把批量数拉满先用一条样例确认输入、输出和日志都正常再逐步加量。4.3 从单条到批量的推进路径建议按三步走单条样例验证用 5 到 10 条不同难度的问题跑一遍重点看查询是否多样化、结果是否去重、答案是否引用了新增信息。小批量稳定性测试跑 50 到 100 条统计平均搜索轮次、平均耗时、缓存命中率、失败率。这一阶段最容易暴露 provider 的限流和超时问题。批量与生产化加日志、加失败重试、加熔断、加评估集。每次改动搜索策略后都要用同一批评估题跑回归不然你无法判断是策略变好了还是运气变好了。5. 多搜了但没变好按这个顺序排查5.1 先把现象分清楚遇到“多搜了但效果没提升”时先别急着改参数按现象定位现象优先排查方向答案几乎没变化查询是否在重复同一个角度缓存是否命中了同一批结果答案越来越乱、越来越糊上下文塞入太多重复或无关片段合并去重失效搜索结果明明有模型却说找不到截断策略太激进关键片段被切掉调用报错提示 provider rejected tool payload 之类工具调用 schema 与模型版本不匹配整体超时或提示 request timed out搜索轮次串行太多耗时叠加需要并发和超时控制5.2 推荐的排查链路按下面的顺序查不要跳步先看日志把每一轮的查询、返回条数、摘要前 200 字都打出来。这一步能直接判断是不是“重复搜索”。再看输入多轮结果是否正确合并、去重、截断时间戳和来源信息有没有保留URL 是否完整。再看环境模型版本是否支持工具调用provider 对搜索工具的 schema 要求是什么API key 权限是否够用。再看参数top_k、每轮结果数、max_rounds 是否合理缓存 key 是否把同一问题误判成不同问题。最后回到策略如果前四步都正常那就是查询改写策略的问题。试着把问题拆得更细或在补缺环节加入“明确指出缺失信息”的要求。排查过程中数据是唯一的裁判。你不需要靠感觉判断“多搜到底有没有用”把一轮搜索和五轮搜索各跑 20 条评估题对比答案正确率和引用一致性结论会非常明显。6. 这个结论不是万能药边界和反例同样重要6.1 什么时候多搜是浪费并不是所有场景都适合多轮搜索。下面几种情况“多搜”带来的收益很低甚至可能变差简单实体查询例如“某产品发布时间是哪一年”一次搜索精确命中多搜只是增加延迟和成本。强实时低延迟场景客服机器人需要在几百毫秒内回复多轮搜索会让用户等待明显变长。上下文非常有限的场景如果生成阶段的上下文窗口只有 4K塞下三轮搜索结果后模型已经没有足够空间做推理。在这些场景里正确做法不是多搜而是用路由把简单问题引到单次搜索只让复杂问题走多轮流程。6.2 多来源也会带来新风险信息覆盖面扩大之后新问题出现了来源之间可能互相冲突。这时候模型需要判断谁更可信而不是简单地把所有信息平均一下。我在实践里的做法是保留每个结果的来源、时间和类型例如官网、第三方、论坛在提示词里要求模型优先采用官方或一手数据并明确说明冲突点对关键数字做二次求证未验证的数字在答案里标注不确定性。换句话说多轮搜索提升的是“资料收集能力”但“资料判断能力”仍然要靠提示词、评估集和人工抽检来兜底。不要指望多搜几轮之后模型就不会被错误网页带偏。6.3 这个经验真正适合谁适合的人群和场景正在做 RAG 增强问答、Agent 搜索、研究型内容生成的团队已经接入搜索 API 但对效果不满意的个人开发者想在 LLM 应用里把检索、验证、生成串成一条可持续优化链路的架构师。不太适合的场景简单 FAQ、纯知识库内部检索、对成本极端敏感且问题普遍简单的应用以及没有日志和评估体系的实验性项目。因为在后一类项目里你根本看不出多搜到底有没有带来提升所谓优化只是在碰运气。最后的经验先让模型学会“需要时才搜”回到最初那个判断。很多团队纠结于“哪个搜索引擎更好”其实是把问题想小了。对 LLM 应用来说检索不是终点它是推理的输入。同样一个模型拥有 5 次有策略的搜索机会通常比拥有 1 次更完美的搜索结果表现更好。这个结论的意义不只是让你去调大 max_rounds而是提醒你真正值得投入的地方是让模型学会判断“我还缺什么、下一步该搜什么”然后把搜索从一次性功能变成一种可持续优化的能力。如果你现在正在做 LLM 联网搜索我的建议是先别急着换搜索引擎。把你现有的搜索 API 留用先在同一个引擎上跑一组“1 次搜索 vs 3 次搜索 vs 5 次搜索”的对比评估。用 20 到 30 条真实问题记录答案正确率和引用一致性。绝大多数情况下你会亲眼看到搜索次数的差异比引擎选择的差异更明显。等到多轮策略稳定了再回去考虑是否值得为更好的引擎增加预算。 LLM联网搜索：更多次搜索胜过更好的搜索引擎
做 LLM 应用的人大概都经历过这样一个阶段给模型配上搜索引擎却发现答案总是差一口气。第一反应往往是换引擎——商业 API 换一家或者干脆自建一个聚合搜索调完接口继续试质量好像提升了一点又好像没有本质变化。直到我认真看了一项关于 LLM 联网搜索的基准测试才意识到问题可能从一开始就找错了方向。这项测试的标题本身就非常直白在 LLM 联网搜索中更多次搜索胜过更好的搜索引擎。换句话说同样一个模型对一个查询多搜几轮、多取几块信息效果往往比把底层引擎从“一般”换成“更好”还要明显。这个判断乍看反直觉因为它挑战了“工具越强结果越强”的直觉。但放到 LLM 的工作方式里它其实一点都不意外。这篇文章想把背后的机制、落地方法和适用边界一次讲清楚也顺便聊聊为什么很多团队在这件事上花了冤枉钱。1. 先理解基准测试里比的不是“搜索质量”而是“组合效果”1.1 测试到底在控制什么变量一项把搜索能力接入 LLM 的基准测试测的往往不是“搜索引擎本身好不好”而是“模型 搜索”这个组合最终能不能答对问题。所以设计上一般会尽量控制住模型、提示词、结果处理方式这些变量只让两件事发生变化底层搜索引擎是谁返回的结果质量如何模型在回答之前允许执行几次搜索以及每轮搜索之间是否有信息补充。当这两组对照同时存在时标题给出的结论才有意义搜索次数对最终答案的影响大于搜索引擎本身的差异。这里有一个容易误读的地方。不是说所有搜索引擎都一样也不是说换引擎完全没用。而是说在“模型 搜索”这个组合里检索只是整个链路的一段。排序精度的差异在经过“取回 - 截断 - 拼接 - 生成”之后会被明显稀释。而搜索次数直接影响的是模型拿到的信息覆盖面。覆盖面才是决定答案能不能“拼出来”的关键而不只是“搜得准不准”。1.2 为什么“更好的引擎”没有带来碾压优势搜索引擎是为人类设计的不是为模型设计的。人的阅读习惯是看排名靠前的链接点进页面自己判断而 LLM 联网搜索通常只拿摘要片段然后把多个片段拼合成答案。这意味着人类眼里“排在最前面很重要”但模型拼答案时更需要的是不同来源、不同角度、不同时间点的片段组合主流搜索引擎在处理常见问题时精度差异很小真正的差距体现在长尾信息上长尾信息往往不在前三名里如果只取 top-k 个摘要再好的长尾内容也进不了上下文。所以把引擎从 A 换成 B改善的往往是检索精度的“上半场”。而 LLM 回答问题更像是在打“下半场”已经拿到一批材料之后能不能找到缺口、补齐证据、完成推理。这个下半场主要由搜索轮次和查询策略决定。从工程经验看这个判断对多数团队都是好消息。因为换引擎往往要改 API、改解析、改计费逻辑成本不低而增加搜索轮次通常只是改一个循环参数和查询生成逻辑。同样是提升效果后者的改动面小得多。2. 单次搜索为什么总是不够信息是拼出来的不是搜出来的2.1 一个查询只有一种措辞一次机会搜索的起点是一个查询字符串。模型用“什么原因导致某问题发生”去搜搜索引擎就会按这个措辞理解意图。但同一个问题换一个角度提问返回的结果可能完全不同。复杂问答很少只依赖一个页面就能完整回答它往往需要不同来源的不同说法相互印证不同时间点的信息做时效对比不同子问题分别检索再合并推理。单次搜索等于只给了模型一扇窗。窗口里有什么答案就局限在什么范围里。这也解释了一个常见困惑为什么模型明明能联网遇到稍微复杂一点的问题还是答得像在猜。不是模型不行是它只被允许看了一页资料。2.2 多轮搜索的本质让模型像人一样去“查资料”人在做一份调研时不会只搜一次就下结论。第一轮搜索往往是建立底图中间发现某个数字来源不可信会再搜一条验证某个专有名词不认识会再补一次定义查询写完初稿还可能要回头确认最新数据。模型的多次搜索做的其实是同样的事。只不过它需要自己判断“我还缺什么”然后生成下一轮查询。这恰恰是“搜索次数”能成为比“引擎质量”更稳定的预测因子的原因只要模型具备基本的查询改写能力多搜几轮就能稳定地扩大信息覆盖而引擎升级带来的边际收益会随着排序精度已经较高而迅速递减。换句话说更多搜索是在提升模型“看到更多世界”的概率换引擎只是让模型“把同一扇窗户擦得更干净”。2.3 多搜不是重复搜查询多样性才是关键这里要划一个重点。如果每一轮搜索都用同一个查询只是把结果页数增加那么多搜的优势会大打折扣。真正有效的“多搜”是让每轮查询之间产生差异把原问题拆成子问题例如“这个方案的适用场景”和“这个方案的局限”分开搜更换表述从“如何做 A”换成“A 的常见坑”加限定条件例如时间范围、站点来源、文件类型针对缺失信息做反问上一轮没提到成本下一轮就专门搜成本。基准测试把“更多搜索”和“更好引擎”放在一起比较本质上是在比较两种投资方向投资在检索精度上还是投资在探索广度上。至少在 LLM 问答这个场景里后者的回报更明显。注意如果发现日志里每一轮查询几乎一样那不是“多搜”是“重复搜”。多轮搜索的收益来自查询多样性而不是提交次数。3. 真正值得优化的是把“搜索次数”变成“搜索策略”3.1 一个可复用的三层检索框架把“多搜几次”工程化不能只是简单地把搜索函数多调用几次。直接把一个查询循环提交 5 遍浪费预算效果还不如单次搜索。我自己在项目里一般会用一个三层框架第一层基线检索。直接用原始问题去搜取回 3 到 5 个权威结果作为整轮回答的事实底座。第二层子问题补检。让模型先拆解问题列出 2 到 4 个必须回答的子问题逐个独立检索。这一层负责把覆盖面打开。第三层求证与补缺。把前两轮的结果合并让模型判断哪些关键信息缺失哪些来源相互冲突。对缺失信息做定向补搜对冲突信息增加一次“求证搜索”。最后收口时把三轮结果按来源权重和时效性合并去重再交给生成环节。这个框架的价值不是让模型每次都搜满 8 轮而是让每一轮搜索都有明确动机。搜索层查询来源主要作用典型轮次基线检索原始问题建立事实底座1子问题补检模型拆解出的子问题扩大信息覆盖面2-4求证与补缺缺失信息 / 冲突信息提升可信度1-33.2 框架、平台和工具链能帮你做哪些事现在很多 RAG 增强方案和 LLM 工具调用机制已经在支持这种多轮搜索。至少有三种落地方式让模型自己调用搜索工具通过 function calling / tool use模型每一轮都能决定搜什么、什么时候停。这种方式最灵活但对模型的自主性要求高。用工作流平台编排像 Dify 这类平台可以在节点里配置多次搜索、条件分支和结果合并适合不想写太多代码的团队。自己在应用层写循环把“查询生成 - 搜索 - 结果合并 - 判断是否继续”做成循环体。这种方式可定制性最高也是下一节最小流程的基础。选择哪种方式取决于你的模型对工具调用的支持程度以及你是否需要在中间环节插入人工判断。如果在某个 provider 上遇到工具调用 schema 被拒报错信息里出现类似 provider rejected the request schema or tool payload 的内容多半是模型版本不支持某个参数或者返回格式不匹配。这属于工具链层的兼容问题不一定要靠改搜索策略解决。3.3 成本和质量不是对立的是分级管理的多搜几次确实会带来 API 成本和延迟上升。但如果因此放弃多轮搜索等于把质量上限锁死在单次检索的覆盖面上。更务实的做法是按问题复杂度分级简单事实问题1 次搜索直接回答常规问答2 到 3 次搜索基线加一次子问题补检调研型问题4 到 6 次搜索完整走三层框架争议性问题或深度报告8 次以上并且在求证环节多加权重。判断一个查询属于哪一级可以在前端用另一个轻量模型做路由也可以用规则做关键词匹配。先分级再分配搜索预算成本就不会失控。4. 落地一个“多搜几次”的最小流程4.1 前置条件与最小实现实现这个流程需要四样东西一个支持工具调用或函数调用的 LLM一个搜索 API 或自建搜索引擎接口一个结果缓存避免不同会话对同一查询重复计费一个能把多轮搜索结果合并去重的处理函数。最小流程的代码结构大致长这样。注意这只是一个常见的实现骨架具体函数名和参数要以你使用的 SDK 为准不要直接照抄。# 示例结构多轮搜索的最小循环 def answer_with_multi_search(question, max_rounds3): merged_results {} query_list [question] # 第一轮原始问题 for round_idx in range(max_rounds): new_results [] for query in query_list: hits search_api(query, top_k5) new_results.extend(hits) merge_dedup(merged_results, new_results) # 按 URL/标题去重 # 判断是否还需要下一轮 evidence format_for_prompt(merged_results) need_more, next_queries llm_decide(evidence, question) if not need_more: break query_list next_queries # 通常是拆解后的子问题或补缺查询 # 收口合并 - 裁剪 - 生成 context truncate(format_for_prompt(merged_results), max_chars8000) return llm_generate(question, context)这个结构有三个关键点。第一每一轮的查询列表都必须来自上一轮的信息缺口而不是把同一个查询重复提交。第二结果合并一定要做去重和截断不然第 5 轮之后上下文里会出现大量重复段落。第三循环必须设置最大轮次防止模型在某个问题上无限搜索下去。4.2 参数理解先别急着把值拉满几个容易踩坑的参数逐个说一下top_k每一轮每个查询取几条结果。我一般取 3 到 5 条。取太多摘要片段互相重复还挤占上下文取太少覆盖面不够。每轮总结果数和 top_k 配合使用。理想状态是“每轮都有新信息”而不是“每轮都堆满”。max_rounds最大搜索轮次。默认给 3 轮足够做基线加子问题加一次补缺。调研型任务再调高但一般不建议超过 8。上下文裁剪合并后给生成模型的上下文长度。长上下文模型能装更多但不要指望模型依赖几万字背景去回答一个 50 字的问题注意力会被稀释。缓存用查询语句做 key加时间戳失效。同一问题被反复问时能省掉大量重复计费。这里有一个通用经验单次跑通只能说明流程没有断真正麻烦的是批量任务、异常重试和长期维护。所以不要一上来就把批量数拉满先用一条样例确认输入、输出和日志都正常再逐步加量。4.3 从单条到批量的推进路径建议按三步走单条样例验证用 5 到 10 条不同难度的问题跑一遍重点看查询是否多样化、结果是否去重、答案是否引用了新增信息。小批量稳定性测试跑 50 到 100 条统计平均搜索轮次、平均耗时、缓存命中率、失败率。这一阶段最容易暴露 provider 的限流和超时问题。批量与生产化加日志、加失败重试、加熔断、加评估集。每次改动搜索策略后都要用同一批评估题跑回归不然你无法判断是策略变好了还是运气变好了。5. 多搜了但没变好按这个顺序排查5.1 先把现象分清楚遇到“多搜了但效果没提升”时先别急着改参数按现象定位现象优先排查方向答案几乎没变化查询是否在重复同一个角度缓存是否命中了同一批结果答案越来越乱、越来越糊上下文塞入太多重复或无关片段合并去重失效搜索结果明明有模型却说找不到截断策略太激进关键片段被切掉调用报错提示 provider rejected tool payload 之类工具调用 schema 与模型版本不匹配整体超时或提示 request timed out搜索轮次串行太多耗时叠加需要并发和超时控制5.2 推荐的排查链路按下面的顺序查不要跳步先看日志把每一轮的查询、返回条数、摘要前 200 字都打出来。这一步能直接判断是不是“重复搜索”。再看输入多轮结果是否正确合并、去重、截断时间戳和来源信息有没有保留URL 是否完整。再看环境模型版本是否支持工具调用provider 对搜索工具的 schema 要求是什么API key 权限是否够用。再看参数top_k、每轮结果数、max_rounds 是否合理缓存 key 是否把同一问题误判成不同问题。最后回到策略如果前四步都正常那就是查询改写策略的问题。试着把问题拆得更细或在补缺环节加入“明确指出缺失信息”的要求。排查过程中数据是唯一的裁判。你不需要靠感觉判断“多搜到底有没有用”把一轮搜索和五轮搜索各跑 20 条评估题对比答案正确率和引用一致性结论会非常明显。6. 这个结论不是万能药边界和反例同样重要6.1 什么时候多搜是浪费并不是所有场景都适合多轮搜索。下面几种情况“多搜”带来的收益很低甚至可能变差简单实体查询例如“某产品发布时间是哪一年”一次搜索精确命中多搜只是增加延迟和成本。强实时低延迟场景客服机器人需要在几百毫秒内回复多轮搜索会让用户等待明显变长。上下文非常有限的场景如果生成阶段的上下文窗口只有 4K塞下三轮搜索结果后模型已经没有足够空间做推理。在这些场景里正确做法不是多搜而是用路由把简单问题引到单次搜索只让复杂问题走多轮流程。6.2 多来源也会带来新风险信息覆盖面扩大之后新问题出现了来源之间可能互相冲突。这时候模型需要判断谁更可信而不是简单地把所有信息平均一下。我在实践里的做法是保留每个结果的来源、时间和类型例如官网、第三方、论坛在提示词里要求模型优先采用官方或一手数据并明确说明冲突点对关键数字做二次求证未验证的数字在答案里标注不确定性。换句话说多轮搜索提升的是“资料收集能力”但“资料判断能力”仍然要靠提示词、评估集和人工抽检来兜底。不要指望多搜几轮之后模型就不会被错误网页带偏。6.3 这个经验真正适合谁适合的人群和场景正在做 RAG 增强问答、Agent 搜索、研究型内容生成的团队已经接入搜索 API 但对效果不满意的个人开发者想在 LLM 应用里把检索、验证、生成串成一条可持续优化链路的架构师。不太适合的场景简单 FAQ、纯知识库内部检索、对成本极端敏感且问题普遍简单的应用以及没有日志和评估体系的实验性项目。因为在后一类项目里你根本看不出多搜到底有没有带来提升所谓优化只是在碰运气。最后的经验先让模型学会“需要时才搜”回到最初那个判断。很多团队纠结于“哪个搜索引擎更好”其实是把问题想小了。对 LLM 应用来说检索不是终点它是推理的输入。同样一个模型拥有 5 次有策略的搜索机会通常比拥有 1 次更完美的搜索结果表现更好。这个结论的意义不只是让你去调大 max_rounds而是提醒你真正值得投入的地方是让模型学会判断“我还缺什么、下一步该搜什么”然后把搜索从一次性功能变成一种可持续优化的能力。如果你现在正在做 LLM 联网搜索我的建议是先别急着换搜索引擎。把你现有的搜索 API 留用先在同一个引擎上跑一组“1 次搜索 vs 3 次搜索 vs 5 次搜索”的对比评估。用 20 到 30 条真实问题记录答案正确率和引用一致性。绝大多数情况下你会亲眼看到搜索次数的差异比引擎选择的差异更明显。等到多轮策略稳定了再回去考虑是否值得为更好的引擎增加预算。