跳到正文

DEEP RESEARCH PROJECT INTERVIEW · Q13 / 25

Deep Research 训练的种子问题从哪里来,怎样避免一开始就把数据做偏?

从日志、专家、公开数据与模型扩写出发,讲清 Deep Research 种子的分布、去重、合规、泄漏和版本验收。

作者与复核:吴师兄内容依据:公开教程、代码示例与工程推导查看关联教程 →查看吴师兄公开作品 →

25 道题目Q13
本页内容25 节

30 秒先说结论

种子应由真实查询、专家补题、公开可许可数据和受控模型扩写互补获得。先建立领域、类型、难度、证据、工具、答案状态和时效矩阵,再做合规、可验证、去重与试跑。按 family 和 source group 切分后增强,规模以清洗后覆盖为准。

训练一个会搜索、访问、计算和综合证据的 Agent,要从一批值得研究的问题开始,不能跳过种子设计直接生成轨迹。

这批问题就是种子数据。

种子很小,却决定后面所有扩写、轨迹生成和训练的方向。如果种子九成是“搜一次就能回答”的事实题,后面即使扩成很多条,模型学到的仍然是默认 Search;如果种子都来自同一个领域或一种表达,模型换个对象就可能失效。

更麻烦的是,真实日志、专家编写、公开数据和模型扩写各有偏差。日志贴近用户,但可能含隐私、噪声和现有产品偏见;专家题质量高,却容易从理想流程出发;模型扩写速度快,也最容易把同一题换几十种说法,制造“数量很多、信息很少”的假繁荣。

所以面试官真正想问的是:

种子问题从哪些来源互补获得,怎样定义难度与可验证性,如何去重、分层和防止泄漏,又怎样让每条种子都能追溯到来源与验收记录?

种子问题和训练轨迹有什么区别?

种子问题定义“要研究什么”。

轨迹记录“系统怎样一步步完成”。

一条种子可以由 Teacher 或真实环境采样出多条轨迹,也可以先经过改写、参数变化和组合扩展,形成一个问题族。

如果种子本身含糊、不可验证或答案已经泄漏,后面的轨迹再完整也没有价值。

因此种子阶段要先验收问题契约:对象是谁,时间范围是什么,需要哪些证据,何时算完成,是否允许无答案。

不要在种子里预写一个虚构的完美过程。种子是任务入口,不是让模型照抄的故事。

也不要把最终答案硬塞进问题文本。参考答案与证据只供轨迹验证和评测使用,模型可见字段与评分字段必须分开。

种子问题与训练轨迹的职责差别

种子控制任务分布,轨迹才记录行动、工具结果和最终答案。

来源一:真实查询日志

真实日志最接近实际用户表达。

它能暴露错别字、指代、模糊范围、真实约束和用户经常追问的内容,这些往往不是专家会主动写出的标准题。

但日志不是天然高质量数据。

一些问题本来就不适合 Deep Research,只需直接回答或一次检索;一些问题依赖用户私有上下文,脱离会话后无法理解;一些问题可能含姓名、账号、合同、公司内部信息和敏感业务。

日志进入候选池前,要先确认使用授权、脱敏规则和保留期限。随后做会话补全、意图聚类、噪声过滤和人工抽检。

脱敏不能只用正则删除号码。替换实体后还要检查问题是否仍然成立,是否因为删除上下文变成不可回答。

现有系统的日志还会反映产品能力偏差。某工具难用,用户可能已经不再问相关问题。只按日志频率采样,会把“目前做不到”误当成“用户不需要”。

来源二:领域专家编写

专家适合补充低频但重要的场景、边界条件和高风险问题。

他们可以把真实业务目标写成可验证任务,并指出必须使用的原始来源、禁止忽略的条件和常见错误。

专家题也有风险。

它们常常表达过于规范,与真实用户语言不同;可能默认太多领域背景;也可能围绕理想流程设计,忽略工具访问和公开证据的现实限制。

所以专家编写需要模板。至少要求问题、业务动机、对象范围、时间范围、预期证据、可能工具、完成条件和高风险误答。

写完后再由非专家阅读,检查问题能否独立理解;由工程人员试跑,检查公开环境中是否可执行;由数据审核确认没有把答案写进问题。

专家题承担的是补齐真实分布中能力缺口的任务,堆砌领域术语只会制造虚假的专业感。

来源三:公开 QA、知识库与文档语料

公开 QA 数据适合提供基础事实、实体和问题结构,但很多题一步即可回答,不能直接等同于 Deep Research 任务。

知识库和文档语料可以反向生成问题,因为证据范围相对明确,便于验证答案是否可由材料推出。

使用前要检查许可证、再分发限制、个人信息和内容时效。公开可访问不等于可以任意复制进训练集。

从文档生成问题时,要防止“看答案出题”导致提示过强。问题不能照抄原句中的专有表达,也不能把正确段落标题直接放进 query。

还要加入无答案或证据不足样本。若每个问题都保证文档中有完整答案,模型会学会无论如何都给结论。

公开数据更适合作为基础来源和冷启动材料,复杂度升级与真实分布仍需后续设计。

来源四:模型扩写

模型可以把一个高质量种子改成多种自然表达,改变参数、约束或组合方式,帮助覆盖语言差异。

它只能产生候选,不能自己生成、自己验收、自己决定全部通过。

最常见问题是同质化。十个改写只换语序和同义词,语义难度、证据路径和工具选择完全相同。

第二个问题是事实漂移。更换实体后,原答案和证据不再成立。

第三个问题是难度虚高。问题变长、限定词变多,看起来复杂,实际上仍然只需查一个页面。

第四个问题是范围失控。模型加入无法公开核验的内部信息、实时数据或模糊主观要求。

扩写后要重新跑可回答性、证据、去重和难度检查。不能因为母题通过,就默认所有子题通过。

四类来源怎样互补?

真实日志负责贴近用户表达和现有需求。

专家题补关键边界与低频高价值场景。

公开资料提供可许可、可验证的基础题源。

模型扩写补语言、参数和组合多样性。

实际配比不能从别的项目直接复制。冷启动阶段日志少,专家与公开资料可能更多;产品运行后,真实查询可以逐步校准分布。

每个来源都要有单独质量报表。若模型扩写通过率低,就调整生成与审核,不用其他来源平均值掩盖。

最终采样根据能力矩阵缺口决定,而不是哪种来源更容易批量获得就多用哪种。

种子矩阵应该有哪些维度?

第一是领域或业务主题。

第二是任务类型,例如事实核验、比较选型、趋势梳理、原因分析和方案设计。

第三是问题难度。难度应由必要证据、推理跳数、对象数量、冲突和工具步骤定义,不按句子长度。

第四是证据结构。单一原始来源、多来源互证、来源冲突、时效更新和无答案需要分别覆盖。

第五是工具需求。直接完成、Search、Search 加 Visit、Scholar、计算和组合工具都要有合理样本。

第六是答案状态。有确定答案、条件性答案、部分答案和无法公开核验。

第七是语言与表达。标准问法、口语、错别字、指代和省略可以适量覆盖。

第八是风险与时效。稳定背景、当前版本、动态事件和高风险决策不能混成一种验收标准。

Deep Research 种子数据覆盖矩阵

数量要落在能力维度上,才能发现模型究竟缺哪类问题。

怎样判断一条种子真的“复杂”?

先问是否必须访问多个独立证据。

再问是否存在对象、版本、时间或指标需要对齐。

再问某一步结果是否会改变下一步计划。

再问能否只靠一个搜索摘要回答。如果可以,它可能只是检索题,不是完整研究题。

还要检查问题是否因为写得含糊才“难”。“全面分析某技术”缺少范围和完成条件,Agent 跑很多步只是因为任务没定义好。

好的复杂题是研究结构复杂,但任务契约清楚。例如需要比较多个对象、核对不同来源、解释条件差异,并在证据不足时保留缺口。

难度标签应通过最小可行轨迹和人工复核校准。模型预测的“难题”只能作为初筛,不能直接当标签。

每条种子要通过哪些质量门?

意图清楚:独立阅读能知道要解决什么。

范围可执行:对象、时间和交付边界足以规划。

证据可验证:存在允许使用的公开或授权资料,或者明确标记无答案。

答案不泄漏:问题文本没有包含结论、正确页面或评分字段。

来源合规:许可证、隐私、用户授权和保留策略明确。

非重复:不是另一题的简单同义改写或参数伪变化。

难度真实:复杂度来自研究路径,不是冗长表达。

分布有价值:它补充能力矩阵中的真实缺口。

任一关键门失败,就退回修改或删除。不要用一个总分把隐私问题和表述小问题平均掉。

去重为什么要按“问题族”做?

字符串去重只能找到完全相同文本。

语义近似可以发现同义改写,但两个文本相似的问题可能有不同时间和约束,不能全部合并。

更稳妥的单位是问题族。母题、语言改写、参数变体和组合追问共享 family ID,同时保存各自差异。

同一问题族可以在训练中保留多个有价值表达,但不能同时进入训练、验证和测试集。否则模型在测试中只是见到了另一个说法。

去重还要看预期证据路径。两个问法都需要同一来源和同一主张,通常高度重复;文本相似但一个问历史、一个问当前,可能属于不同任务。

人工抽查重点看聚类边界和被判为“新问题”的大批模型扩写,防止数量被同义句撑大。

如何防止训练与评测泄漏?

先按问题族切分,再进行任何增强。

同一文档段落生成的多个问题也应建立 source group,避免相同证据跨集合。

时间敏感数据可以做时间切分,让测试集包含训练截止后出现的新版本,检验真正的研究行为,而不是记忆事实。

参考答案、正确来源、人工解释和评分标签与模型输入分开存储。运行脚本明确哪些字段可见。

Teacher 生成轨迹时,也不能无意读取测试答案或人工评分说明。

数据版本升级后重新计算族关系。新扩写若与旧测试题高度相似,应进入隔离或重新划分,而不是直接加入训练。

泄漏审计要保留结果。只说“做过随机切分”不足以证明评测可信。

provenance 应该记录什么?

每条种子需要稳定 ID、来源类型、原始记录或文档的受控引用、创建时间、生成方式、Prompt 或规则版本、审核人或审核流程、许可与隐私状态。

模型扩写还要指向母题和变换类型。

日志种子要记录脱敏与会话补全方式,但不能在训练数据中保留原始敏感内容。

专家题记录业务动机和预期证据,而不是只写“人工编写”。

质量状态应区分候选、自动通过、人工通过、退回、删除和过期。题目修改后生成新版本,旧审核不能自动继承。

这些字段让团队能回答某一类错误来自哪个来源、哪版生成器和哪条审核规则,也支持删除与合规追踪。

多个审核人意见不一致怎么办?

种子问题是否复杂、是否可回答,往往不是简单的对错标签。

先为每个标签写可操作定义和正反例。例如“需要多源”要说明是业务上必须交叉验证,还是只是搜索结果碰巧很多;“无答案”要区分当前公开资料不足与问题本身没有确定答案。

初期让多个审核人对同一小批候选独立标注,再比较分歧集中在哪些字段。分歧高说明规则不清,不能只用多数票把标签定下来。

争议样本由更熟悉领域和证据要求的人仲裁,同时把判定理由补进指南。后续模型辅助审核也使用同一标准,不让它自由创造新口径。

审核一致不代表标签一定正确。还要通过轨迹试跑和下游训练观察验证。例如大家都把某题标成复杂,但基线 Agent 一次 Visit 就能完成,就应回头修正难度定义。

审核记录保存规则版本。指南更新后,受影响的旧样本需要重新检查,不能因为曾经人工通过就永久有效。

产品和工具变化后,旧种子会不会过时?

会。

新增工具可能让原本需要多步搜索的问题变成一次结构化查询,工具下线也可能让旧任务无法执行。

来源页面、产品版本和业务流程变化,会使参考证据和完成条件失效。

因此种子要有有效期或复核状态。稳定概念题可以低频复核,当前版本、政策和动态事件需要更积极更新。

数据漂移不只看用户问法变化,还要看问题类型、工具分布、无答案比例和失败原因。新日志中大量出现一个未覆盖主题,才说明需要补种子;不能简单把所有新日志都加入。

旧种子过时后,可以保留作历史版本研究,但必须修改时间范围和证据,不得继续当当前问题训练。

每次工具或任务 Schema 升级都应回放代表性种子,检查问题是否仍可执行、难度是否变化和原标签是否成立。

为什么要小批发布而不是一次造完?

种子质量问题会在轨迹阶段被放大。

一条范围错误的母题经过多轮扩写,可能变成一整个错误问题族;一种工具分布偏差进入 Teacher 采样后,会产生大量相似动作。

更稳妥的方式是小批候选经过合规、去重、分布和试跑后发布,再从轨迹失败与模型错误中决定下一批补什么。

每批设置硬门:隐私和许可不通过直接拒绝,答案泄漏与证据不可验证不能靠总分弥补。软指标用于观察表达多样性、类别覆盖和审核成本。

发布后冻结版本,记录样本 ID 列表和数据指纹。下一批新增或修订时产生新版本,训练结果才能与具体数据快照对应。

这种增量方式不会自动保证效果,却能让问题更早暴露,也能避免计划规模被误写成已经验收的数据。

一个教学反例:看起来有很多种子,其实只有一个问题

下面是教学设计,不代表真实数据规模。

母题是“比较方案 A 与 B 的部署差异”。

扩写器生成“方案 A 和 B 如何部署”“A 与 B 部署方式有什么不同”“部署 A 还是 B 更合适”等一批文本。

若它们的对象、证据、约束和完成条件完全相同,这只是语言改写,不是新的研究能力。

另一条变体加入“在离线环境、有限运维条件下比较,并说明证据不足处”。它改变了约束和报告要求,可能形成有价值的新任务,但仍要重新核验资料是否可支持。

数据统计应同时报告样本数、问题族数和能力单元覆盖。只报总条数,会掩盖同质化。

种子数据应该怎样验收?

第一层是自动结构与合规检查。

第二层是语义去重、family 与 source group 检查。

第三层是分布检查,查看领域、类型、难度、证据、工具和答案状态。

第四层是可执行性试跑。用一个基线 Agent 或人工最小轨迹判断是否真的需要预期步骤,证据是否可获得。

第五层是人工抽检,重点看隐私、许可、复杂度、无答案和模型扩写边界。

第六层是下游验证。少量生成轨迹后,观察工具分布、失败模式和最终可核验性,再回到种子阶段修正。

种子问题从候选到发布的验收流程

种子通过文本检查还不够,必须验证分布、证据和可执行性。

规模应该怎样决定?

不要从一个目标总数倒推需要制造多少问题。

先建立能力矩阵和最小覆盖,再逐批生成、审核和试跑。某类样本通过率低或轨迹经常失败,先修定义与来源,不要继续扩量。

计划文档中的种子数和扩展数可能来自不同阶段、不同草案或笔误,不能把它们合并成已经完成的事实。

真正可用规模应以清洗后、去重后、合规后并通过版本验收的数据为准,同时报告问题族和分布,不只报文件行数。

数据越多,审核、去重和版本治理成本也越高。高质量少量种子先证明流水线,再按模型错误和覆盖缺口扩展,比一次生成大量同质题更稳妥。

面试官继续追问,怎么接?

追问一:真实日志是不是最好的种子?

它最贴近用户,但包含噪声、隐私和现有产品偏差。需要脱敏、授权、聚类和专家补缺,不能直接当金标准。

追问二:怎样判断模型扩写不是重复?

同时比较语义、关键槽位、预期证据路径和工具计划,并按问题族管理。只换说法属于表达多样性,不等于能力新增。

追问三:问题越长就越难吗?

不是。难度来自必要证据、推理跳数、对象、冲突和动态规划。含糊和冗长只会让任务定义变差。

追问四:种子为什么要有无答案题?

真实研究常遇到证据不足。没有这类种子,模型容易学会每题都强行给确定结论。

追问五:怎么防止训练测试泄漏?

按问题族和证据来源组切分,再做增强;参考答案与模型可见字段隔离,并定期做跨版本相似性审计。

怎样把种子数据设计讲成完整方案

Deep Research 的种子数据定义要研究什么,后续轨迹才记录怎么完成。来源上我会组合真实查询、专家补题、公开可许可数据和受控模型扩写,但任何来源都只先进入候选池。日志需要授权、脱敏和会话补全;专家题要试跑;公开数据检查许可与时效;模型扩写重新做事实与去重验证。

我会建立领域、任务类型、难度、证据结构、工具需求、答案状态、表达和风险时效矩阵,按覆盖缺口采样。每题检查意图、范围、证据可验证、无泄漏、合规、非重复和难度真实,并保存 provenance、family ID、source group 和审核版本。数据集按问题族与证据来源切分后再增强,避免同义题跨训练和测试。

规模以清洗、去重、合规和验收后的可用数据为准,不照搬计划数字,同时报告问题族和能力覆盖。先用小批种子生成轨迹,观察工具分布和失败模式,再回到矩阵补缺。每个种子都应代表一项真实、可验证且值得模型学习的研究能力,尽快堆条数不构成目标。

Deep Research 种子数据检查清单

种子数据入池前的四项核验

随机抽一条种子回查来源、证据路径、问题族和下游轨迹,确认它代表的是能力缺口,而不是新增了一种说法。

  • 每条种子能否说明来源、许可、脱敏和审核版本?
  • 难度是否来自真实证据路径,而不是句子长度和含糊范围?
  • family 与 source group 是否阻止增强题跨训练、验证和测试?
  • 是否以清洗后分布和下游轨迹质量决定扩量,而不是只看总数?

INTERVIEW FOLLOW-UPS

面试官会怎样继续追问?

这些追问会继续检查方案取舍、验证方法和项目事实。
  1. Q01

    真实日志是不是最好的种子?

  2. Q02

    怎样判断模型扩写不是重复?

  3. Q03

    问题越长就越难吗?

  4. Q04

    如何防止训练测试泄漏?

PROJECT CHECK

换成你的项目,这几件事能否说清楚?

  • 四类来源分别经过授权、证据和质量审核
  • 按能力矩阵采样并校准真实难度
  • 用 family 与 source group 去重和切分
  • 以清洗后分布与轨迹试跑决定扩量
用自己的项目经历练一次