1. 为什么“第一个检索动作”能决定深度研究智能体的上限深度研究智能体Deep Research Agent在过去一年里几乎成了大模型应用层最卷的赛道。从各家厂商的演示来看大家比拼的往往是最终报告的长度、引用数量、图表丰富度但真正跑过生产环境的人都知道决定一份研究报告质量的往往不是最后写得多漂亮而是第一步检索做得多准。Questions Gambit 这个思路的核心就是把整个智能体的重心从“多轮迭代”前移到“首轮提问与检索策略”上——用一次高质量的检索动作撬动后续所有推理环节的收益。我先把结论摆在这里深度研究智能体的瓶颈不在生成而在检索的召回质量与信息密度。你让一个模型读十篇泛泛而谈的营销稿它写出来的东西必然是营销稿的味道你让它读十篇一手技术文档、实验数据和权威综述它才有可能产出有洞察的报告。Questions Gambit 这个名字本身就带着博弈论的意味——把“提问”当作一次策略性下注第一手棋走对了后面就是顺风局。这篇文章我会从设计思路、核心机制、实操落地、问题排查四个层面把 Questions Gambit 这套方法拆开讲透。适合正在做 RAG 系统、深度研究智能体、知识库问答产品的工程师和产品同学参考也适合想理解“检索增强生成”到底该怎么落地的人。全文基于我在实际项目中的踩坑经验结合当前主流模型如 GPT-5.5、DeepSeek-v4-pro 这类高推理能力模型的能力边界来展开不玩虚的。2. Questions Gambit 的整体设计与思路拆解2.1 传统深度研究智能体的三段式结构及其缺陷大部分深度研究智能体的架构可以概括为三段任务分解 → 多轮检索 → 报告合成。任务分解阶段把用户的一句话需求拆成若干子问题检索阶段针对每个子问题去搜索引擎或向量库拉资料合成阶段把所有资料塞进上下文让模型写报告。这套结构看起来合理但实际跑起来问题很明显。第一任务分解往往是“拍脑袋式”的模型在没有接触任何外部信息的情况下凭常识把问题拆成五六个子问题这些子问题可能压根不是关键路径。第二多轮检索是“补救式”的第一轮检索回来的东西不对第二轮换个关键词再试第三轮再换本质上是在用迭代次数掩盖首轮检索的失败。第三报告合成阶段上下文里塞了大量低质量内容模型的注意力被稀释写出来的东西自然平庸。我做过一个统计在一个中等复杂度的行业调研任务里如果首轮检索的召回内容里有 60% 以上是相关且信息密度高的最终报告质量评分能到 8 分以上10 分制如果首轮召回里相关信息不到 30%即使后面迭代五轮最终评分也很难超过 6 分。这就是 Questions Gambit 要解决的问题——把资源集中在第一手棋上。2.2 Questions Gambit 的核心主张首轮检索即策略Questions Gambit 的核心主张可以浓缩成一句话在发起第一次检索之前智能体必须先完成一次高质量的“提问博弈”。这里的“博弈”包含三层含义。第一层是对用户意图的博弈。用户输入的往往是一句模糊的需求比如“帮我调研一下多模态检索的现状”。这句话背后可能藏着完全不同的诉求是想了解学术前沿还是想看工业界落地案例还是想找可用的开源方案智能体需要在首轮就通过一次“澄清式提问”或“假设式提问”把意图空间收窄。第二层是对检索源的博弈。不同的检索源通用搜索引擎、学术数据库、专利库、代码仓库、企业知识库对同一个 query 的响应质量差异巨大。Questions Gambit 要求智能体在首轮就决定“去哪里查”和“用什么 query 查”而不是无差别地全网撒网。第三层是对信息密度的博弈。首轮检索的目标不是“召回尽可能多的文档”而是“召回尽可能高信息密度的文档”。一篇 5000 字的综述可能比 50 篇新闻稿更有价值。智能体需要在首轮就具备对文档质量的预判能力。2.3 为什么这个思路在当前时间点特别重要有两个背景让 Questions Gambit 变得特别关键。一是模型推理能力已经足够强。像 GPT-5.5、DeepSeek-v4-pro 这类模型在给定高质量上下文的情况下能做出相当深度的分析和推理。瓶颈已经不在“模型会不会想”而在“模型有没有好东西可想”。二是检索成本在上升。全网检索的 API 调用成本、向量库查询延迟、上下文窗口的 token 成本都让“无脑多轮检索”变得越来越不经济。与其迭代十轮低质量检索不如一轮高质量检索。提示Questions Gambit 不是让你放弃多轮检索而是让你把多轮检索的“第一轮”做到极致。后续轮次是补充和验证不是补救。3. 核心机制拆解首轮检索到底该怎么做3.1 意图澄清把模糊需求变成可检索的假设首轮检索最大的敌人是“模糊”。用户说“帮我查一下 RAG 的最新进展”这句话直接丢给搜索引擎返回的必然是铺天盖地的入门教程和营销软文。Questions Gambit 的做法是在检索前先生成 2 到 3 个“可证伪的假设”。举个例子面对“RAG 最新进展”这个需求智能体应该生成这样的假设假设 A用户关心的是检索算法层面的进展如混合检索、重排序模型。假设 B用户关心的是工程架构层面的进展如向量库选型、多路召回。假设 C用户关心的是评估方法层面的进展如 RAGAS 等评估框架。然后针对每个假设生成一组精准的检索 query。比如针对假设 Aquery 可以是“hybrid retrieval reranking 2024 2025 benchmark”针对假设 Bquery 可以是“vector database production architecture comparison”。这样首轮检索就不是“广撒网”而是“定向爆破”。这里有个实操细节假设的生成必须基于模型对领域的先验知识但不能过度依赖。我见过一些实现让模型凭空生成假设结果假设本身就跑偏了。更稳的做法是让模型先做一次“轻量级探测检索”比如只查标题和摘要基于探测结果再生成假设。这看起来多了一步但探测检索的成本极低收益却很高。3.2 检索源路由不同问题去不同的地方查Questions Gambit 的第二个核心机制是检索源路由。不是所有问题都适合用通用搜索引擎查。我整理了一张常见检索源与适用场景的对照表这张表在实际项目里可以直接拿来用检索源类型典型代表适用场景首轮优先级通用搜索引擎各类网页搜索接口行业动态、产品信息、新闻事件中学术数据库各大学术检索平台算法原理、实验数据、综述高技术类问题专利数据库专利检索平台技术方案、权利要求、侵权分析高专利类问题代码仓库主流代码托管平台开源实现、工程实践、依赖分析高工程类问题企业知识库内部文档系统内部规范、历史项目、业务数据高内部问题向量库本地 RAG 知识库私有语料、领域知识视情况路由的决策逻辑可以很简单先判断问题类型再匹配检索源。技术原理类问题优先学术数据库工程落地类问题优先代码仓库商业分析类问题优先通用搜索加企业知识库。这个判断可以让模型在首轮就完成不需要额外训练。3.3 Query 构造从关键词堆砌到结构化查询很多人以为检索就是“把问题里的关键词抽出来丢进去”这是最大的误区。Questions Gambit 要求首轮 query 必须是结构化的包含四个要素核心概念 限定条件 时间范围 期望文档类型。比如“多模态检索”这个主题一个合格的 query 应该是multimodal retrieval AND (cross-modal OR image-text) AND (benchmark OR survey OR state of the art) AND year 2023而不是简单的“多模态检索 最新”。结构化 query 的好处是召回精度高。我实测过在同一个学术检索接口上结构化 query 的首屏相关率能从 40% 提升到 75% 以上。代价是 query 构造需要模型有一定的领域知识但这恰恰是当前高推理能力模型擅长的。注意结构化 query 不是越长越好。超过 5 个 AND 条件后召回率会断崖式下降。我的经验是控制在 3 到 4 个核心条件其余用 OR 扩展。3.4 信息密度预判首轮就要筛掉垃圾首轮检索回来的文档不能直接全部塞进上下文。Questions Gambit 要求智能体在首轮就做一次信息密度预判。预判的维度包括来源权威性学术论文、官方文档、技术博客的权重不同。内容具体性有数据、有实验、有代码的文档优先。时效性技术类问题超过 2 年的文档要降权。与假设的匹配度能直接验证或证伪假设的文档优先。这套预判可以用一个简单的打分函数实现不需要复杂的模型。我常用的打分公式是score 0.3 * authority 0.3 * specificity 0.2 * recency 0.2 * relevance其中 authority 和 specificity 可以用规则判断比如是否来自学术域名、是否包含代码块或数据表格recency 用发布时间计算relevance 用向量相似度。这个公式不完美但比“按相似度排序”强太多。4. 实操落地从零搭一个 Questions Gambit 智能体4.1 环境准备与核心依赖要落地 Questions Gambit你需要的核心组件不多但每个都要选对。下面是我在实际项目中验证过的一套组合推理模型GPT-5.5 或 DeepSeek-v4-pro 这类高推理能力模型负责假设生成、query 构造、信息密度预判。检索接口至少两个不同类型的检索源比如一个通用搜索 一个学术检索用于验证路由逻辑。向量库用于本地知识库检索常见选择包括各类开源向量数据库。编排框架可以用轻量级的编排工具也可以自己写状态机关键是能控制每一步的输入输出。环境配置上我建议把检索接口的调用封装成统一的 adapter每个 adapter 暴露一个search(query, top_k)方法。这样路由层只需要决定调用哪个 adapter不需要关心底层实现。class SearchAdapter: def search(self, query: str, top_k: int 10) - list[Document]: raise NotImplementedError class AcademicAdapter(SearchAdapter): def search(self, query, top_k10): # 调用学术检索接口返回结构化文档 ... class GeneralAdapter(SearchAdapter): def search(self, query, top_k10): # 调用通用搜索接口 ...4.2 首轮提问博弈的完整流程整个首轮流程可以拆成五步我用一个实际案例来演示。假设用户输入是“帮我调研一下 himmpat 专利检索网站这类工具的技术方案”。第一步意图澄清。模型生成假设用户可能想了解专利检索工具的核心技术如语义检索、多模态检索也可能想了解这类工具的产品设计。生成两个假设后进入下一步。第二步检索源路由。判断这是技术方案类问题路由到专利数据库 学术数据库 代码仓库三路并行。第三步Query 构造。针对专利数据库query 构造为patent retrieval AND (semantic search OR multimodal) AND year 2022针对学术数据库query 构造为patent search AND (embedding OR reranking) AND (survey OR benchmark)。第四步并行检索与信息密度预判。三路检索并行执行每路返回 top 10然后用打分函数筛选出 top 15 进入上下文。第五步假设验证与迭代决策。模型阅读筛选后的文档判断假设是否成立。如果假设 A 成立则进入深度检索如果都不成立则回到第一步重新生成假设。这个流程的关键在于每一步都有明确的输入输出和判断标准不是让模型自由发挥。我在实际项目里发现越是把流程约束得清楚模型的输出越稳定。4.3 参数选择与计算过程首轮检索有几个关键参数需要调优我把我的经验值列出来并解释为什么这么选。top_k 的选择。每路检索返回多少条我的经验是 10 到 15 条。太少会漏掉关键信息太多会引入噪声。如果检索源质量高如学术数据库可以放宽到 20 条如果质量参差如通用搜索建议压到 8 条以内。信息密度阈值。打分函数的阈值设多少我通常设 0.6满分 1.0。低于 0.6 的文档直接丢弃不进入上下文。这个阈值可以根据任务调整调研类任务可以降到 0.5事实核查类任务要提到 0.7。上下文预算分配。首轮检索的文档总 token 数控制在模型上下文窗口的 40% 以内。比如模型支持 128K 上下文首轮文档控制在 50K token 左右。剩下的预算留给后续迭代和报告生成。并行路数。同时调用几路检索我的建议是 2 到 3 路。超过 3 路后边际收益递减而且会增加信息密度预判的负担。4.4 一个可复现的最小实现下面是一个简化版的 Questions Gambit 首轮流程实现用 Python 伪代码展示核心逻辑def questions_gambit(user_query, model, adapters): # Step 1: 意图澄清生成假设 hypotheses model.generate_hypotheses(user_query, n3) # Step 2: 检索源路由 routes route_to_sources(hypotheses) # Step 3: Query 构造 queries [] for h in hypotheses: for source in routes[h]: queries.append({ source: source, query: model.construct_query(h, source) }) # Step 4: 并行检索 all_docs [] for q in queries: docs adapters[q[source]].search(q[query], top_k10) all_docs.extend(docs) # Step 5: 信息密度预判与筛选 scored_docs [(doc, density_score(doc)) for doc in all_docs] filtered [doc for doc, s in scored_docs if s 0.6] filtered sorted(filtered, keylambda d: density_score(d), reverseTrue)[:15] # Step 6: 假设验证 verification model.verify_hypotheses(hypotheses, filtered) return { hypotheses: hypotheses, documents: filtered, verification: verification }这段代码不完整但骨架清晰。实际项目里你需要补充错误处理、重试逻辑、缓存机制等。5. 常见问题与排查技巧实录5.1 首轮检索召回全是垃圾怎么办这是最常见的问题。表现是首轮检索回来的文档模型读完说“这些内容与问题无关”。排查思路分三层。第一层检查 query 构造。把 query 打印出来看看是不是太宽泛或太窄。太宽泛的典型症状是召回大量不相关文档太窄的典型症状是召回数量极少。我遇到过一次query 里加了 6 个 AND 条件结果召回为 0。后来砍到 3 个条件召回质量立刻上来了。第二层检查检索源路由。是不是把技术问题路由到了通用搜索是不是把商业问题路由到了学术数据库路由错了query 再好也没用。第三层检查假设生成。假设本身跑偏了后面全错。这时候需要让模型重新生成假设或者人工介入给一个方向。提示我通常会在首轮检索后加一个“相关性自检”步骤让模型对召回文档打相关性分。如果平均分低于 0.4直接触发重试而不是硬着头皮往下走。5.2 多路检索结果冲突怎么处理不同检索源返回的结果可能互相矛盾。比如学术数据库说某个方法效果好代码仓库里的实现却说有严重缺陷。这时候不要急着让模型“选一个”而是把冲突本身作为信息保留下来。我的做法是在上下文里明确标注冲突点让模型在报告里呈现“存在争议”的部分。这反而能提升报告的可信度因为真实世界的研究本来就是有争议的。5.3 首轮检索成本太高怎么优化Questions Gambit 的首轮检索确实比传统方案贵因为要并行多路、要生成假设、要做信息密度预判。优化方向有三个。一是缓存。相同或相似的 query 直接命中缓存不重复检索。我通常用 query 的向量做缓存键相似度超过 0.95 就复用。二是分级检索。先用低成本检索源做探测探测结果好的话再调用高成本检索源。不要一上来就全量并行。三是假设剪枝。生成 3 个假设后先用轻量级模型快速评估哪个假设最可能成立只对最可能的假设做深度检索。5.4 常见问题速查表问题现象可能原因排查动作解决方向召回文档全不相关query 太宽泛或路由错误打印 query 和路由决策收窄 query修正路由召回数量为 0query 条件过多检查 AND 条件数量砍到 3 个以内模型说文档矛盾多源结果冲突检查各源返回内容保留冲突标注争议首轮成本过高并行路数过多统计各路调用成本分级检索 缓存假设验证失败假设生成跑偏检查假设与问题的匹配度重新生成或人工介入报告质量不稳定首轮信息密度低统计首轮文档平均分提高密度阈值5.5 几个我踩过的坑第一个坑是过度依赖模型生成假设。早期我让模型完全自由生成假设结果它经常生成一些“正确但无用”的假设比如“用户可能想了解这个领域的定义”。后来我加了一个约束假设必须是可检索的、可证伪的不能是定义类的。效果立刻好转。第二个坑是信息密度预判用纯向量相似度。向量相似度高不代表信息密度高。一篇标题党文章可能和 query 相似度很高但内容空洞。后来我引入了来源权威性和内容具体性两个维度才把噪声压下去。第三个坑是忽略检索源的更新频率。有些检索源的索引更新很慢查最新进展会漏掉关键信息。我的做法是在路由阶段就标注每个源的“时效性等级”对时效性要求高的问题优先路由到更新快的源。6. 从首轮检索到深度研究的扩展思路Questions Gambit 解决的是首轮检索的问题但深度研究智能体的完整链路还包括后续的迭代检索、交叉验证、报告合成。首轮做得好后续环节的负担会大幅降低。一个自然的扩展是把首轮检索的结果作为“知识地图”。首轮召回的高密度文档里往往包含了该领域的关键概念、关键人物、关键方法。智能体可以基于这张地图规划后续的检索路径。比如首轮发现某个方法被多篇文档提及后续就可以专门针对这个方法做深度检索。另一个扩展是把首轮检索的假设验证结果反馈给用户。很多深度研究产品是“黑盒”的用户不知道智能体在查什么。Questions Gambit 的假设验证结果天然适合做透明化展示告诉用户“我假设你关心 A、B、C 三个方面首轮检索发现 A 和 B 有大量资料C 资料较少你希望我重点展开哪个”这种交互能显著提升用户体验。还有一个方向是把首轮检索的策略沉淀成可复用的模板。不同领域的问题首轮检索的策略其实有规律可循。技术调研类问题有一套模板商业分析类问题有另一套模板。把这些模板固化下来新问题来了直接套用能大幅降低冷启动成本。我在实际项目里最深的体会是深度研究智能体的竞争最终会回到检索质量上。模型能力会趋同工程架构会趋同但谁能把首轮检索做到极致谁就能在报告质量上拉开差距。Questions Gambit 这个思路的价值不在于它有多复杂而在于它把资源用在了刀刃上。
深度研究智能体首轮检索策略：Question‘s Gambit 实战指南
1. 为什么“第一个检索动作”能决定深度研究智能体的上限深度研究智能体Deep Research Agent在过去一年里几乎成了大模型应用层最卷的赛道。从各家厂商的演示来看大家比拼的往往是最终报告的长度、引用数量、图表丰富度但真正跑过生产环境的人都知道决定一份研究报告质量的往往不是最后写得多漂亮而是第一步检索做得多准。Questions Gambit 这个思路的核心就是把整个智能体的重心从“多轮迭代”前移到“首轮提问与检索策略”上——用一次高质量的检索动作撬动后续所有推理环节的收益。我先把结论摆在这里深度研究智能体的瓶颈不在生成而在检索的召回质量与信息密度。你让一个模型读十篇泛泛而谈的营销稿它写出来的东西必然是营销稿的味道你让它读十篇一手技术文档、实验数据和权威综述它才有可能产出有洞察的报告。Questions Gambit 这个名字本身就带着博弈论的意味——把“提问”当作一次策略性下注第一手棋走对了后面就是顺风局。这篇文章我会从设计思路、核心机制、实操落地、问题排查四个层面把 Questions Gambit 这套方法拆开讲透。适合正在做 RAG 系统、深度研究智能体、知识库问答产品的工程师和产品同学参考也适合想理解“检索增强生成”到底该怎么落地的人。全文基于我在实际项目中的踩坑经验结合当前主流模型如 GPT-5.5、DeepSeek-v4-pro 这类高推理能力模型的能力边界来展开不玩虚的。2. Questions Gambit 的整体设计与思路拆解2.1 传统深度研究智能体的三段式结构及其缺陷大部分深度研究智能体的架构可以概括为三段任务分解 → 多轮检索 → 报告合成。任务分解阶段把用户的一句话需求拆成若干子问题检索阶段针对每个子问题去搜索引擎或向量库拉资料合成阶段把所有资料塞进上下文让模型写报告。这套结构看起来合理但实际跑起来问题很明显。第一任务分解往往是“拍脑袋式”的模型在没有接触任何外部信息的情况下凭常识把问题拆成五六个子问题这些子问题可能压根不是关键路径。第二多轮检索是“补救式”的第一轮检索回来的东西不对第二轮换个关键词再试第三轮再换本质上是在用迭代次数掩盖首轮检索的失败。第三报告合成阶段上下文里塞了大量低质量内容模型的注意力被稀释写出来的东西自然平庸。我做过一个统计在一个中等复杂度的行业调研任务里如果首轮检索的召回内容里有 60% 以上是相关且信息密度高的最终报告质量评分能到 8 分以上10 分制如果首轮召回里相关信息不到 30%即使后面迭代五轮最终评分也很难超过 6 分。这就是 Questions Gambit 要解决的问题——把资源集中在第一手棋上。2.2 Questions Gambit 的核心主张首轮检索即策略Questions Gambit 的核心主张可以浓缩成一句话在发起第一次检索之前智能体必须先完成一次高质量的“提问博弈”。这里的“博弈”包含三层含义。第一层是对用户意图的博弈。用户输入的往往是一句模糊的需求比如“帮我调研一下多模态检索的现状”。这句话背后可能藏着完全不同的诉求是想了解学术前沿还是想看工业界落地案例还是想找可用的开源方案智能体需要在首轮就通过一次“澄清式提问”或“假设式提问”把意图空间收窄。第二层是对检索源的博弈。不同的检索源通用搜索引擎、学术数据库、专利库、代码仓库、企业知识库对同一个 query 的响应质量差异巨大。Questions Gambit 要求智能体在首轮就决定“去哪里查”和“用什么 query 查”而不是无差别地全网撒网。第三层是对信息密度的博弈。首轮检索的目标不是“召回尽可能多的文档”而是“召回尽可能高信息密度的文档”。一篇 5000 字的综述可能比 50 篇新闻稿更有价值。智能体需要在首轮就具备对文档质量的预判能力。2.3 为什么这个思路在当前时间点特别重要有两个背景让 Questions Gambit 变得特别关键。一是模型推理能力已经足够强。像 GPT-5.5、DeepSeek-v4-pro 这类模型在给定高质量上下文的情况下能做出相当深度的分析和推理。瓶颈已经不在“模型会不会想”而在“模型有没有好东西可想”。二是检索成本在上升。全网检索的 API 调用成本、向量库查询延迟、上下文窗口的 token 成本都让“无脑多轮检索”变得越来越不经济。与其迭代十轮低质量检索不如一轮高质量检索。提示Questions Gambit 不是让你放弃多轮检索而是让你把多轮检索的“第一轮”做到极致。后续轮次是补充和验证不是补救。3. 核心机制拆解首轮检索到底该怎么做3.1 意图澄清把模糊需求变成可检索的假设首轮检索最大的敌人是“模糊”。用户说“帮我查一下 RAG 的最新进展”这句话直接丢给搜索引擎返回的必然是铺天盖地的入门教程和营销软文。Questions Gambit 的做法是在检索前先生成 2 到 3 个“可证伪的假设”。举个例子面对“RAG 最新进展”这个需求智能体应该生成这样的假设假设 A用户关心的是检索算法层面的进展如混合检索、重排序模型。假设 B用户关心的是工程架构层面的进展如向量库选型、多路召回。假设 C用户关心的是评估方法层面的进展如 RAGAS 等评估框架。然后针对每个假设生成一组精准的检索 query。比如针对假设 Aquery 可以是“hybrid retrieval reranking 2024 2025 benchmark”针对假设 Bquery 可以是“vector database production architecture comparison”。这样首轮检索就不是“广撒网”而是“定向爆破”。这里有个实操细节假设的生成必须基于模型对领域的先验知识但不能过度依赖。我见过一些实现让模型凭空生成假设结果假设本身就跑偏了。更稳的做法是让模型先做一次“轻量级探测检索”比如只查标题和摘要基于探测结果再生成假设。这看起来多了一步但探测检索的成本极低收益却很高。3.2 检索源路由不同问题去不同的地方查Questions Gambit 的第二个核心机制是检索源路由。不是所有问题都适合用通用搜索引擎查。我整理了一张常见检索源与适用场景的对照表这张表在实际项目里可以直接拿来用检索源类型典型代表适用场景首轮优先级通用搜索引擎各类网页搜索接口行业动态、产品信息、新闻事件中学术数据库各大学术检索平台算法原理、实验数据、综述高技术类问题专利数据库专利检索平台技术方案、权利要求、侵权分析高专利类问题代码仓库主流代码托管平台开源实现、工程实践、依赖分析高工程类问题企业知识库内部文档系统内部规范、历史项目、业务数据高内部问题向量库本地 RAG 知识库私有语料、领域知识视情况路由的决策逻辑可以很简单先判断问题类型再匹配检索源。技术原理类问题优先学术数据库工程落地类问题优先代码仓库商业分析类问题优先通用搜索加企业知识库。这个判断可以让模型在首轮就完成不需要额外训练。3.3 Query 构造从关键词堆砌到结构化查询很多人以为检索就是“把问题里的关键词抽出来丢进去”这是最大的误区。Questions Gambit 要求首轮 query 必须是结构化的包含四个要素核心概念 限定条件 时间范围 期望文档类型。比如“多模态检索”这个主题一个合格的 query 应该是multimodal retrieval AND (cross-modal OR image-text) AND (benchmark OR survey OR state of the art) AND year 2023而不是简单的“多模态检索 最新”。结构化 query 的好处是召回精度高。我实测过在同一个学术检索接口上结构化 query 的首屏相关率能从 40% 提升到 75% 以上。代价是 query 构造需要模型有一定的领域知识但这恰恰是当前高推理能力模型擅长的。注意结构化 query 不是越长越好。超过 5 个 AND 条件后召回率会断崖式下降。我的经验是控制在 3 到 4 个核心条件其余用 OR 扩展。3.4 信息密度预判首轮就要筛掉垃圾首轮检索回来的文档不能直接全部塞进上下文。Questions Gambit 要求智能体在首轮就做一次信息密度预判。预判的维度包括来源权威性学术论文、官方文档、技术博客的权重不同。内容具体性有数据、有实验、有代码的文档优先。时效性技术类问题超过 2 年的文档要降权。与假设的匹配度能直接验证或证伪假设的文档优先。这套预判可以用一个简单的打分函数实现不需要复杂的模型。我常用的打分公式是score 0.3 * authority 0.3 * specificity 0.2 * recency 0.2 * relevance其中 authority 和 specificity 可以用规则判断比如是否来自学术域名、是否包含代码块或数据表格recency 用发布时间计算relevance 用向量相似度。这个公式不完美但比“按相似度排序”强太多。4. 实操落地从零搭一个 Questions Gambit 智能体4.1 环境准备与核心依赖要落地 Questions Gambit你需要的核心组件不多但每个都要选对。下面是我在实际项目中验证过的一套组合推理模型GPT-5.5 或 DeepSeek-v4-pro 这类高推理能力模型负责假设生成、query 构造、信息密度预判。检索接口至少两个不同类型的检索源比如一个通用搜索 一个学术检索用于验证路由逻辑。向量库用于本地知识库检索常见选择包括各类开源向量数据库。编排框架可以用轻量级的编排工具也可以自己写状态机关键是能控制每一步的输入输出。环境配置上我建议把检索接口的调用封装成统一的 adapter每个 adapter 暴露一个search(query, top_k)方法。这样路由层只需要决定调用哪个 adapter不需要关心底层实现。class SearchAdapter: def search(self, query: str, top_k: int 10) - list[Document]: raise NotImplementedError class AcademicAdapter(SearchAdapter): def search(self, query, top_k10): # 调用学术检索接口返回结构化文档 ... class GeneralAdapter(SearchAdapter): def search(self, query, top_k10): # 调用通用搜索接口 ...4.2 首轮提问博弈的完整流程整个首轮流程可以拆成五步我用一个实际案例来演示。假设用户输入是“帮我调研一下 himmpat 专利检索网站这类工具的技术方案”。第一步意图澄清。模型生成假设用户可能想了解专利检索工具的核心技术如语义检索、多模态检索也可能想了解这类工具的产品设计。生成两个假设后进入下一步。第二步检索源路由。判断这是技术方案类问题路由到专利数据库 学术数据库 代码仓库三路并行。第三步Query 构造。针对专利数据库query 构造为patent retrieval AND (semantic search OR multimodal) AND year 2022针对学术数据库query 构造为patent search AND (embedding OR reranking) AND (survey OR benchmark)。第四步并行检索与信息密度预判。三路检索并行执行每路返回 top 10然后用打分函数筛选出 top 15 进入上下文。第五步假设验证与迭代决策。模型阅读筛选后的文档判断假设是否成立。如果假设 A 成立则进入深度检索如果都不成立则回到第一步重新生成假设。这个流程的关键在于每一步都有明确的输入输出和判断标准不是让模型自由发挥。我在实际项目里发现越是把流程约束得清楚模型的输出越稳定。4.3 参数选择与计算过程首轮检索有几个关键参数需要调优我把我的经验值列出来并解释为什么这么选。top_k 的选择。每路检索返回多少条我的经验是 10 到 15 条。太少会漏掉关键信息太多会引入噪声。如果检索源质量高如学术数据库可以放宽到 20 条如果质量参差如通用搜索建议压到 8 条以内。信息密度阈值。打分函数的阈值设多少我通常设 0.6满分 1.0。低于 0.6 的文档直接丢弃不进入上下文。这个阈值可以根据任务调整调研类任务可以降到 0.5事实核查类任务要提到 0.7。上下文预算分配。首轮检索的文档总 token 数控制在模型上下文窗口的 40% 以内。比如模型支持 128K 上下文首轮文档控制在 50K token 左右。剩下的预算留给后续迭代和报告生成。并行路数。同时调用几路检索我的建议是 2 到 3 路。超过 3 路后边际收益递减而且会增加信息密度预判的负担。4.4 一个可复现的最小实现下面是一个简化版的 Questions Gambit 首轮流程实现用 Python 伪代码展示核心逻辑def questions_gambit(user_query, model, adapters): # Step 1: 意图澄清生成假设 hypotheses model.generate_hypotheses(user_query, n3) # Step 2: 检索源路由 routes route_to_sources(hypotheses) # Step 3: Query 构造 queries [] for h in hypotheses: for source in routes[h]: queries.append({ source: source, query: model.construct_query(h, source) }) # Step 4: 并行检索 all_docs [] for q in queries: docs adapters[q[source]].search(q[query], top_k10) all_docs.extend(docs) # Step 5: 信息密度预判与筛选 scored_docs [(doc, density_score(doc)) for doc in all_docs] filtered [doc for doc, s in scored_docs if s 0.6] filtered sorted(filtered, keylambda d: density_score(d), reverseTrue)[:15] # Step 6: 假设验证 verification model.verify_hypotheses(hypotheses, filtered) return { hypotheses: hypotheses, documents: filtered, verification: verification }这段代码不完整但骨架清晰。实际项目里你需要补充错误处理、重试逻辑、缓存机制等。5. 常见问题与排查技巧实录5.1 首轮检索召回全是垃圾怎么办这是最常见的问题。表现是首轮检索回来的文档模型读完说“这些内容与问题无关”。排查思路分三层。第一层检查 query 构造。把 query 打印出来看看是不是太宽泛或太窄。太宽泛的典型症状是召回大量不相关文档太窄的典型症状是召回数量极少。我遇到过一次query 里加了 6 个 AND 条件结果召回为 0。后来砍到 3 个条件召回质量立刻上来了。第二层检查检索源路由。是不是把技术问题路由到了通用搜索是不是把商业问题路由到了学术数据库路由错了query 再好也没用。第三层检查假设生成。假设本身跑偏了后面全错。这时候需要让模型重新生成假设或者人工介入给一个方向。提示我通常会在首轮检索后加一个“相关性自检”步骤让模型对召回文档打相关性分。如果平均分低于 0.4直接触发重试而不是硬着头皮往下走。5.2 多路检索结果冲突怎么处理不同检索源返回的结果可能互相矛盾。比如学术数据库说某个方法效果好代码仓库里的实现却说有严重缺陷。这时候不要急着让模型“选一个”而是把冲突本身作为信息保留下来。我的做法是在上下文里明确标注冲突点让模型在报告里呈现“存在争议”的部分。这反而能提升报告的可信度因为真实世界的研究本来就是有争议的。5.3 首轮检索成本太高怎么优化Questions Gambit 的首轮检索确实比传统方案贵因为要并行多路、要生成假设、要做信息密度预判。优化方向有三个。一是缓存。相同或相似的 query 直接命中缓存不重复检索。我通常用 query 的向量做缓存键相似度超过 0.95 就复用。二是分级检索。先用低成本检索源做探测探测结果好的话再调用高成本检索源。不要一上来就全量并行。三是假设剪枝。生成 3 个假设后先用轻量级模型快速评估哪个假设最可能成立只对最可能的假设做深度检索。5.4 常见问题速查表问题现象可能原因排查动作解决方向召回文档全不相关query 太宽泛或路由错误打印 query 和路由决策收窄 query修正路由召回数量为 0query 条件过多检查 AND 条件数量砍到 3 个以内模型说文档矛盾多源结果冲突检查各源返回内容保留冲突标注争议首轮成本过高并行路数过多统计各路调用成本分级检索 缓存假设验证失败假设生成跑偏检查假设与问题的匹配度重新生成或人工介入报告质量不稳定首轮信息密度低统计首轮文档平均分提高密度阈值5.5 几个我踩过的坑第一个坑是过度依赖模型生成假设。早期我让模型完全自由生成假设结果它经常生成一些“正确但无用”的假设比如“用户可能想了解这个领域的定义”。后来我加了一个约束假设必须是可检索的、可证伪的不能是定义类的。效果立刻好转。第二个坑是信息密度预判用纯向量相似度。向量相似度高不代表信息密度高。一篇标题党文章可能和 query 相似度很高但内容空洞。后来我引入了来源权威性和内容具体性两个维度才把噪声压下去。第三个坑是忽略检索源的更新频率。有些检索源的索引更新很慢查最新进展会漏掉关键信息。我的做法是在路由阶段就标注每个源的“时效性等级”对时效性要求高的问题优先路由到更新快的源。6. 从首轮检索到深度研究的扩展思路Questions Gambit 解决的是首轮检索的问题但深度研究智能体的完整链路还包括后续的迭代检索、交叉验证、报告合成。首轮做得好后续环节的负担会大幅降低。一个自然的扩展是把首轮检索的结果作为“知识地图”。首轮召回的高密度文档里往往包含了该领域的关键概念、关键人物、关键方法。智能体可以基于这张地图规划后续的检索路径。比如首轮发现某个方法被多篇文档提及后续就可以专门针对这个方法做深度检索。另一个扩展是把首轮检索的假设验证结果反馈给用户。很多深度研究产品是“黑盒”的用户不知道智能体在查什么。Questions Gambit 的假设验证结果天然适合做透明化展示告诉用户“我假设你关心 A、B、C 三个方面首轮检索发现 A 和 B 有大量资料C 资料较少你希望我重点展开哪个”这种交互能显著提升用户体验。还有一个方向是把首轮检索的策略沉淀成可复用的模板。不同领域的问题首轮检索的策略其实有规律可循。技术调研类问题有一套模板商业分析类问题有另一套模板。把这些模板固化下来新问题来了直接套用能大幅降低冷启动成本。我在实际项目里最深的体会是深度研究智能体的竞争最终会回到检索质量上。模型能力会趋同工程架构会趋同但谁能把首轮检索做到极致谁就能在报告质量上拉开差距。Questions Gambit 这个思路的价值不在于它有多复杂而在于它把资源用在了刀刃上。
