跳到主内容
Deep Research 训练的种子问题从哪里来，怎样避免一开始就把数据做偏？ · AlgoMooc
学大模型 / Agent / Deep Research 训练的种子问题从哪里来，怎样避免一开始就把数据做偏？ 一些问题本来就不适合 Deep Research，只需直接回答或一次检索；一些问题依赖用户私有上下文，脱离会话后无法理解；一些问题可能含姓名、账号、合同、公司内部信息和敏感业务。
日志进入候选池前，要先确认使用授权、脱敏规则和保留期限。随后做会话补全、意图聚类、噪声过滤和人工抽检。
脱敏不能只用正则删除号码。替换实体后还要检查问题是否仍然成立，是否因为删除上下文变成不可回答。
现有系统的日志还会反映产品能力偏差。某工具难用，用户可能已经不再问相关问题。只按日志频率采样，会把“目前做不到”误当成“用户不需要”。
来源二：领域专家编写 专家适合补充低频但重要的场景、边界条件和高风险问题。
他们可以把真实业务目标写成可验证任务，并指出必须使用的原始来源、禁止忽略的条件和常见错误。
它们常常表达过于规范，与真实用户语言不同；可能默认太多领域背景；也可能围绕理想流程设计，忽略工具访问和公开证据的现实限制。
所以专家编写需要模板。至少要求问题、业务动机、对象范围、时间范围、预期证据、可能工具、完成条件和高风险误答。
写完后再由非专家阅读，检查问题能否独立理解；由工程人员试跑，检查公开环境中是否可执行；由数据审核确认没有把答案写进问题。
专家题承担的是补齐真实分布中能力缺口的任务，堆砌领域术语只会制造虚假的专业感。
来源三：公开 QA、知识库与文档语料 公开 QA 数据适合提供基础事实、实体和问题结构，但很多题一步即可回答，不能直接等同于 Deep Research 任务。
知识库和文档语料可以反向生成问题，因为证据范围相对明确，便于验证答案是否可由材料推出。
使用前要检查许可证、再分发限制、个人信息和内容时效。公开可访问不等于可以任意复制进训练集。
从文档生成问题时，要防止“看答案出题”导致提示过强。问题不能照抄原句中的专有表达，也不能把正确段落标题直接放进 query。
还要加入无答案或证据不足样本。若每个问题都保证文档中有完整答案，模型会学会无论如何都给结论。
公开数据更适合作为基础来源和冷启动材料，复杂度升级与真实分布仍需后续设计。
来源四：模型扩写 模型可以把一个高质量种子改成多种自然表达，改变参数、约束或组合方式，帮助覆盖语言差异。
它只能产生候选，不能自己生成、自己验收、自己决定全部通过。
最常见问题是同质化。十个改写只换语序和同义词，语义难度、证据路径和工具选择完全相同。
第二个问题是事实漂移。更换实体后，原答案和证据不再成立。
第三个问题是难度虚高。问题变长、限定词变多，看起来复杂，实际上仍然只需查一个页面。
第四个问题是范围失控。模型加入无法公开核验的内部信息、实时数据或模糊主观要求。
扩写后要重新跑可回答性、证据、去重和难度检查。不能因为母题通过，就默认所有子题通过。
四类来源怎样互补？ 实际配比不能从别的项目直接复制。冷启动阶段日志少，专家与公开资料可能更多；产品运行后，真实查询可以逐步校准分布。
每个来源都要有单独质量报表。若模型扩写通过率低，就调整生成与审核，不用其他来源平均值掩盖。
最终采样根据能力矩阵缺口决定，而不是哪种来源更容易批量获得就多用哪种。
种子矩阵应该有哪些维度？ 第二是任务类型，例如事实核验、比较选型、趋势梳理、原因分析和方案设计。
第三是问题难度。难度应由必要证据、推理跳数、对象数量、冲突和工具步骤定义，不按句子长度。
第四是证据结构。单一原始来源、多来源互证、来源冲突、时效更新和无答案需要分别覆盖。
第五是工具需求。直接完成、Search、Search 加 Visit、Scholar、计算和组合工具都要有合理样本。
第六是答案状态。有确定答案、条件性答案、部分答案和无法公开核验。
第七是语言与表达。标准问法、口语、错别字、指代和省略可以适量覆盖。
第八是风险与时效。稳定背景、当前版本、动态事件和高风险决策不能混成一种验收标准。
数量要落在能力维度上，才能发现模型究竟缺哪类问题。
怎样判断一条种子真的“复杂”？ 再问能否只靠一个搜索摘要回答。如果可以，它可能只是检索题，不是完整研究题。
还要检查问题是否因为写得含糊才“难”。“全面分析某技术”缺少范围和完成条件，Agent 跑很多步只是因为任务没定义好。
好的复杂题是研究结构复杂，但任务契约清楚。例如需要比较多个对象、核对不同来源、解释条件差异，并在证据不足时保留缺口。
难度标签应通过最小可行轨迹和人工复核校准。模型预测的“难题”只能作为初筛，不能直接当标签。
每条种子要通过哪些质量门？ 证据可验证：存在允许使用的公开或授权资料，或者明确标记无答案。
答案不泄漏：问题文本没有包含结论、正确页面或评分字段。
任一关键门失败，就退回修改或删除。不要用一个总分把隐私问题和表述小问题平均掉。
去重为什么要按“问题族”做？ 语义近似可以发现同义改写，但两个文本相似的问题可能有不同时间和约束，不能全部合并。
更稳妥的单位是问题族。母题、语言改写、参数变体和组合追问共享 family ID，同时保存各自差异。
同一问题族可以在训练中保留多个有价值表达，但不能同时进入训练、验证和测试集。否则模型在测试中只是见到了另一个说法。
去重还要看预期证据路径。两个问法都需要同一来源和同一主张，通常高度重复；文本相似但一个问历史、一个问当前，可能属于不同任务。
人工抽查重点看聚类边界和被判为“新问题”的大批模型扩写，防止数量被同义句撑大。
如何防止训练与评测泄漏？ 同一文档段落生成的多个问题也应建立 source group，避免相同证据跨集合。
时间敏感数据可以做时间切分，让测试集包含训练截止后出现的新版本，检验真正的研究行为，而不是记忆事实。
参考答案、正确来源、人工解释和评分标签与模型输入分开存储。运行脚本明确哪些字段可见。
Teacher 生成轨迹时，也不能无意读取测试答案或人工评分说明。
数据版本升级后重新计算族关系。新扩写若与旧测试题高度相似，应进入隔离或重新划分，而不是直接加入训练。
泄漏审计要保留结果。只说“做过随机切分”不足以证明评测可信。
provenance 应该记录什么？ 每条种子需要稳定 ID、来源类型、原始记录或文档的受控引用、创建时间、生成方式、Prompt 或规则版本、审核人或审核流程、许可与隐私状态。
日志种子要记录脱敏与会话补全方式，但不能在训练数据中保留原始敏感内容。
专家题记录业务动机和预期证据，而不是只写“人工编写”。
质量状态应区分候选、自动通过、人工通过、退回、删除和过期。题目修改后生成新版本，旧审核不能自动继承。
这些字段让团队能回答某一类错误来自哪个来源、哪版生成器和哪条审核规则，也支持删除与合规追踪。
多个审核人意见不一致怎么办？ 种子问题是否复杂、是否可回答，往往不是简单的对错标签。
先为每个标签写可操作定义和正反例。例如“需要多源”要说明是业务上必须交叉验证，还是只是搜索结果碰巧很多；“无答案”要区分当前公开资料不足与问题本身没有确定答案。
初期让多个审核人对同一小批候选独立标注，再比较分歧集中在哪些字段。分歧高说明规则不清，不能只用多数票把标签定下来。
争议样本由更熟悉领域和证据要求的人仲裁，同时把判定理由补进指南。后续模型辅助审核也使用同一标准，不让它自由创造新口径。
审核一致不代表标签一定正确。还要通过轨迹试跑和下游训练观察验证。例如大家都把某题标成复杂，但基线 Agent 一次 Visit 就能完成，就应回头修正难度定义。
审核记录保存规则版本。指南更新后，受影响的旧样本需要重新检查，不能因为曾经人工通过就永久有效。
产品和工具变化后，旧种子会不会过时？ 新增工具可能让原本需要多步搜索的问题变成一次结构化查询，工具下线也可能让旧任务无法执行。
来源页面、产品版本和业务流程变化，会使参考证据和完成条件失效。
因此种子要有有效期或复核状态。稳定概念题可以低频复核，当前版本、政策和动态事件需要更积极更新。
数据漂移不只看用户问法变化，还要看问题类型、工具分布、无答案比例和失败原因。新日志中大量出现一个未覆盖主题，才说明需要补种子；不能简单把所有新日志都加入。
旧种子过时后，可以保留作历史版本研究，但必须修改时间范围和证据，不得继续当当前问题训练。
每次工具或任务 Schema 升级都应回放代表性种子，检查问题是否仍可执行、难度是否变化和原标签是否成立。
为什么要小批发布而不是一次造完？ 一条范围错误的母题经过多轮扩写，可能变成一整个错误问题族；一种工具分布偏差进入 Teacher 采样后，会产生大量相似动作。
更稳妥的方式是小批候选经过合规、去重、分布和试跑后发布，再从轨迹失败与模型错误中决定下一批补什么。
每批设置硬门：隐私和许可不通过直接拒绝，答案泄漏与证据不可验证不能靠总分弥补。软指标用于观察表达多样性、类别覆盖和审核成本。
发布后冻结版本，记录样本 ID 列表和数据指纹。下一批新增或修订时产生新版本，训练结果才能与具体数据快照对应。
这种增量方式不会自动保证效果，却能让问题更早暴露，也能避免计划规模被误写成已经验收的数据。
一个教学反例：看起来有很多种子，其实只有一个问题 扩写器生成“方案 A 和 B 如何部署”“A 与 B 部署方式有什么不同”“部署 A 还是 B 更合适”等一批文本。
若它们的对象、证据、约束和完成条件完全相同，这只是语言改写，不是新的研究能力。
另一条变体加入“在离线环境、有限运维条件下比较，并说明证据不足处”。它改变了约束和报告要求，可能形成有价值的新任务，但仍要重新核验资料是否可支持。
数据统计应同时报告样本数、问题族数和能力单元覆盖。只报总条数，会掩盖同质化。
种子数据应该怎样验收？ 第二层是语义去重、family 与 source group 检查。
第三层是分布检查，查看领域、类型、难度、证据、工具和答案状态。
第四层是可执行性试跑。用一个基线 Agent 或人工最小轨迹判断是否真的需要预期步骤，证据是否可获得。
第五层是人工抽检，重点看隐私、许可、复杂度、无答案和模型扩写边界。
第六层是下游验证。少量生成轨迹后，观察工具分布、失败模式和最终可核验性，再回到种子阶段修正。
种子通过文本检查还不够，必须验证分布、证据和可执行性。
规模应该怎样决定？ 先建立能力矩阵和最小覆盖，再逐批生成、审核和试跑。某类样本通过率低或轨迹经常失败，先修定义与来源，不要继续扩量。
计划文档中的种子数和扩展数可能来自不同阶段、不同草案或笔误，不能把它们合并成已经完成的事实。
真正可用规模应以清洗后、去重后、合规后并通过版本验收的数据为准，同时报告问题族和分布，不只报文件行数。
数据越多，审核、去重和版本治理成本也越高。高质量少量种子先证明流水线，再按模型错误和覆盖缺口扩展，比一次生成大量同质题更稳妥。
面试官继续追问，怎么接？
追问一：真实日志是不是最好的种子？ 它最贴近用户，但包含噪声、隐私和现有产品偏差。需要脱敏、授权、聚类和专家补缺，不能直接当金标准。
追问二：怎样判断模型扩写不是重复？ 同时比较语义、关键槽位、预期证据路径和工具计划，并按问题族管理。只换说法属于表达多样性，不等于能力新增。
追问三：问题越长就越难吗？ 不是。难度来自必要证据、推理跳数、对象、冲突和动态规划。含糊和冗长只会让任务定义变差。
追问四：种子为什么要有无答案题？ 真实研究常遇到证据不足。没有这类种子，模型容易学会每题都强行给确定结论。
追问五：怎么防止训练测试泄漏？ 按问题族和证据来源组切分，再做增强；参考答案与模型可见字段隔离，并定期做跨版本相似性审计。
怎样把种子数据设计讲成完整方案
Deep Research 的种子数据定义要研究什么，后续轨迹才记录怎么完成。来源上我会组合真实查询、专家补题、公开可许可数据和受控模型扩写，但任何来源都只先进入候选池。日志需要授权、脱敏和会话补全；专家题要试跑；公开数据检查许可与时效；模型扩写重新做事实与去重验证。
我会建立领域、任务类型、难度、证据结构、工具需求、答案状态、表达和风险时效矩阵，按覆盖缺口采样。每题检查意图、范围、证据可验证、无泄漏、合规、非重复和难度真实，并保存 provenance、family ID、source group 和审核版本。数据集按问题族与证据来源切分后再增强，避免同义题跨训练和测试。
规模以清洗、去重、合规和验收后的可用数据为准，不照搬计划数字，同时报告问题族和能力覆盖。先用小批种子生成轨迹，观察工具分布和失败模式，再回到矩阵补缺。每个种子都应代表一项真实、可验证且值得模型学习的研究能力，尽快堆条数不构成目标。
种子数据入池前的四项核验 随机抽一条种子回查来源、证据路径、问题族和下游轨迹，确认它代表的是能力缺口，而不是新增了一种说法。
每条种子能否说明来源、许可、脱敏和审核版本？
难度是否来自真实证据路径，而不是句子长度和含糊范围？
family 与 source group 是否阻止增强题跨训练、验证和测试？
是否以清洗后分布和下游轨迹质量决定扩量，而不是只看总数？
