#合成数据工程专项强化题库（第十六批：Self-Improvement、Rejection Sampling、验证流水线与规模化）

#一、高频问题速览

#二、逐题详细解答

#287. 什么是 Self-Improvement 合成数据？其核心闭环是什么？

#知识点

• Self-Improvement / Self-Play
• 内循环（Inner Loop）与外循环（Outer Loop）
• 合成训练信号
• 奖励模型 / 下游效用

#详细解答

Self-Improvement 合成数据 的核心思想是：让模型自己生成能够提高自身性能的训练数据，并用这些数据通过梯度更新或策略优化来微调模型，形成一个自我改进的闭环。

典型闭环结构（以 SEAL 为例）：

1. 生成器（Generator / Teacher）：基于当前策略或 prompt，为某个任务生成候选输出（如 self-edit、合成 QA 对、推理路径）。
2. 应用器（Applier / Student）：将这些合成样本用于内循环微调（SFT 或少量梯度步），得到更新后的学生模型。
3. 评估器（Evaluator）：在下游验证集或代理任务上评估学生模型的性能提升。
4. 外循环优化（Outer Loop）：把性能提升作为奖励信号，用 RL（如 PPO）或离线优化方法更新生成器的策略，使其未来能生成更有用的训练样本。

工程要点：

• 内循环要保守：步数和学习率不能太大，否则学生模型会在合成数据上灾难性过拟合。
• 保留真实数据：训练集中应混合一定比例的真实数据，防止分布漂移和风格退化。
• Reward 设计是关键：最终奖励应基于下游任务效用（accuracy、win-rate），而不是生成器自身的置信度，避免自举偏差（bootstrap bias）。

#288. Rejection Sampling 在合成数据中的作用是什么？K 值如何选择？

#知识点

• Rejection Sampling（拒绝采样）
• 奖励模型 / Critic
• 硬验收（Hard Verification）
• K 值（生成数）与成本权衡

#详细解答

Rejection Sampling 的作用：

在合成数据生成中，Rejection Sampling 指：为每个 prompt 生成 K 个候选输出，然后用一个评分器（奖励模型、执行器、或多模型投票）对每个候选打分，只保留得分最高的 top-m 样本用于后续训练。

它的核心价值是提供高质量、低噪声的训练信号。相比于直接用所有生成样本做 SFT，rejection sampling 能显著过滤掉低质量、错误或不相关的输出。

常见变体：

• RS + SFT：筛出高分样本后直接做监督微调。
• RS + DPO：把高分样本作为 preferred，低分样本作为 rejected，训练偏好模型。
• Critic-based Rejection：用专门的 Critic 模型评估样本复杂度或正确性，而不是单一 reward score。

K 值的选择：

• 经验范围：K 通常在 10–30 之间。对于简单任务，K=4–8 可能就足够；对于复杂推理任务，K=32 甚至更高才能覆盖到正确路径。
• 收益递减：K 增大时，找到更好样本的概率增加，但边际收益递减，而推理成本线性增长。
• 选择策略：在小规模验证集上实验，找到"质量提升开始变缓"的临界点作为 K 值。

工程风险：

• 如果评分模型本身有偏差，rejection sampling 会系统性放大这个偏差。
• 对于代码/数学等可验证任务，建议用执行器（executor）作为硬验收条件，而不是纯模型打分。

#289. Best-of-N 与 Self-Consistency 在合成数据筛选上有何区别？

#知识点

• Best-of-N（BoN）
• Self-Consistency（多数投票）
• 训练样本 vs 推理增强
• 推理路径聚合

#详细解答

Best-of-N：

• 目标：为训练集筛选出单个最优样本。
• 做法：生成 N 个响应，用奖励模型或执行器选出分数最高的一个，作为训练数据。
• 结果：训练集由"高质量峰值样本"组成，适合 SFT 或 DPO。
• 局限：只保留一个样本，丢弃了大量可能有价值的多样性路径。

Self-Consistency：

• 目标：通过聚合多条推理路径得到更可靠的答案，常用于推理时的答案增强（inference-time augmentation）。
• 做法：生成 N 个带有 CoT 的响应，对最终答案做多数投票（majority voting），选择出现频率最高的答案。
• 结果：得到的是更鲁棒的预测答案，而不是单个训练样本。
• 与训练的关系：Self-consistency 的结果可以被用来重新标注训练数据（即把多数投票选出的答案作为 gold label），但这本质上还是一种 BoN 或重标注策略。

关键区别：

互补用法：

• 先用 Self-Consistency 在推理时验证哪条推理路径更可靠。
• 再用 Best-of-N 把一致性高、得分高的路径选入训练集。

#290. 合成数据中的 Quality-Diversity Trade-off 如何平衡？

#知识点

• 质量（Quality）与多样性（Diversity）
• 分布收缩（Distribution Collapse）
• 语义多样性度量
• 簇覆盖与分层采样

#详细解答

Quality-Diversity Trade-off：

合成数据 pipeline 中，过度追求质量会导致分布收缩——模型只生成"安全、常见、高置信度"的样本，长尾场景和边缘案例被过滤掉，最终损害模型的泛化能力。

反之，过度追求多样性（如只用高温度采样）会引入大量低质量、有噪声的样本，训练信号不稳定，模型性能同样下降。

平衡策略：

1. 分层/主题均衡采样

• 在过滤前，先用聚类或主题模型把生成样本分成若干簇。
• 从每个簇中按质量排名选取 top-k，确保不同主题、难度、风格的样本都有代表。

2. 可控温度与多 checkpoint 生成

• 不要只用单一温度。可以混合：低温（t=0.3）生成高质量标准样本，中温（t=0.7）生成多样化变体，高温（t=1.0）生成创意/边缘样本。
• 使用多个不同 checkpoint（如预训练中期、SFT 后）分别生成，增加样本来源多样性。

3. 多样性奖励（Diversity Reward）

• 在过滤阶段，除了质量分，还引入一个多样性分。
• 例如：用 embedding 距离衡量候选样本与已选样本集的差异，优先选择能填补"语义空白"的样本。

4. 质量门槛 + 多样性优化

• 先设一个硬质量门槛（如 reward > 0.6 或执行器通过），过滤掉明显低质的样本。
• 在通过门槛的候选中，再用多样性优化策略（如 Maximal Marginal Relevance）选取最终训练集。

度量指标：

• 语义多样性：用 embedding 聚类的簇数、簇内熵、或 Vendi Score 衡量。
• 主题覆盖率：检查训练集中各主题/任务类型的比例是否与目标分布一致。

#291. 如何设计合成数据的验证/测评流水线（Verification Pipeline）？

#知识点

• 分层验证
• 模型作为判官（Model-as-a-Judge）
• 执行器验收
• 人工抽检
• CI/CD 集成

#详细解答

一个健壮的合成数据验证流水线应该分层设计，从低成本筛选到高成本精审：

第一层：格式与规则检查（低成本）

• 检查输出是否符合预期的 JSON/XML 格式。
• 长度过滤（过长/过短的异常样本）。
• 字符集检查、URL/敏感词黑名单过滤。
• 去重：Exact hash 去掉完全重复的样本。

第二层：启发式质量检查（中低成本）

• 检查答案是否与问题相关（如关键词重叠）。
• 对于代码：语法检查（AST 解析是否通过）。
• 对于数学：LaTeX 格式检查、符号一致性检查。

第三层：模型化评估（中成本）

• Reward Model / Judge Model：用强模型（如 GPT-4）作为判官，对候选样本的质量、相关性、正确性打分。
• 多模型投票：用多个不同模型分别评分，取平均或多数共识，降低单一模型的偏差。

第四层：硬验收（高成本但高置信度）

• 执行器验证：代码用单元测试跑通，数学用 CAS/SMT 求解器验证，SQL 查询在沙箱数据库中执行并对比结果。
• 只有通过硬验收的样本才能进入高优先级训练集。

第五层：人工抽检（最高成本）

• 对通过前面所有层级的样本进行随机抽样，由人工评估质量。
• 抽检率按风险等级设定（高风险任务 5–10%，低风险任务 1–2%）。
• 人工评估结果用于校准自动过滤器的阈值。

CI/CD 集成：

• 把验证流水线作为可重复执行的 pipeline 节点，每次生成新数据或更新模型后自动触发。
• 保留完整的验证日志和元数据，支持事后追溯。

#292. 大规模合成数据（百万级以上）的去重策略有哪些？

#知识点

• Exact Hash 去重
• MinHash + LSH（局部敏感哈希）
• Embedding 去重
• 分布式去重
• 代表性保留

#详细解答

大规模合成数据的去重不能只用简单的字符串比较，需要分阶段、分层处理：

阶段一：Exact Hash 去重（最快）

• 对文本做 MD5/SHA1 哈希，直接去掉完全重复的样本。
• 这一步能去掉 30–60% 的机械重复，成本极低。

阶段二：近似去重（MinHash + LSH）

• 把文本切成 n-gram（如 5-gram），计算 MinHash 签名。
• 用 LSH（Locality Sensitive Hashing）把相似文本分到同一个桶中。
• 设定 Jaccard 相似度阈值（如 0.85），超过阈值的样本视为近似重复，只保留质量更高的一个。
• 参数设定：签名长度和 band 数需要根据目标阈值和期望的 FP/FN 率来调优。

阶段三：语义去重（Embedding 聚类）

• 对关键子集（如高价值/高风险领域）用 embedding 模型编码，计算余弦相似度。
• 设定语义相似度阈值（如 0.95），聚类后每个簇只保留一个代表样本。
• 这种方法最精确，但计算成本最高，建议只在关键数据上使用。

分布式实现：

• 百万级以上的数据需要分布式处理。常用 MapReduce / Spark 流水线：
  1. 分片计算局部 MinHash 签名。
  2. 全局汇总 LSH banding 结果，生成重复候选对。
  3. 局部去重后再做一次全局合并。

代表性保留策略：

• 当发现重复样本时，保留策略可以是：
  • 保留质量评分更高的。
  • 保留来源更可靠的（如经过执行器验证的）。
  • 保留时间更新的。

#293. 合成数据导致模型 Collapse 的典型症状和根因是什么？

#知识点

• Model Collapse / 分布坍塌
• 模式单一化（Mode Collapse）
• 自举偏差（Bootstrap Bias）
• 偏差放大

#详细解答

典型症状：

1. 输出风格单一化：模型生成的文本越来越雷同，词汇多样性下降，句式趋于模板化。
2. 事实准确性下降：对训练数据分布内的问题表现尚可，但对边缘案例或新事实错误率上升。
3. 下游任务性能不升反降：尤其是在需要泛化能力的任务（如 OOD 推理、长尾分类）上。
4. Embedding 聚类覆盖度下降：用 t-SNE/UMAP 可视化发现样本聚类数量减少，簇内高度集中。

根因分析：

1. 自举偏差（Bootstrap Bias）

• 当模型用自己的输出去训练自己时，它会倾向于复制自己的"平均"行为，逐渐丢失数据分布的长尾部分。
• 每次迭代都会把分布向"安全区"压缩，形成恶性循环。

2. 过滤器的质量偏差

• 如果过滤器（reward model / judge model）对某些类型的样本有系统性偏好，合成数据会过度代表这些类型，其他类型逐渐消失。

3. 缺乏真实数据校准

• 如果训练集中合成数据占比过高（如 >80%），模型会逐渐遗忘真实世界的分布特征。

4. 奖励黑客（Reward Hacking）

• 模型可能学会欺骗评分器（如生成看似合理但实际错误的推理步骤），导致表面质量高但实际能力下降。

缓解策略：

• 混合真实数据：合成数据占比建议控制在 50% 以下，高风险任务更低。
• 多源生成器：使用多个不同模型/策略生成样本，避免单一模型的偏差被放大。
• 定期人工审核：抽检并校准自动过滤器的质量模型。
• 硬验收：对于可验证任务（代码、数学），用执行器而不是模型判官做最终把关。

#294. 如何用执行器/单元测试对代码/数学类合成数据做硬验收？

#知识点

• 硬验收（Hard Verification）
• 单元测试（Unit Test）
• 执行器沙箱
• SMT/Symbolic 求解器
• 编译与运行

#详细解答

硬验收的核心思想：

对于代码、数学、SQL 等结果可判定的任务，最强的质量验证不是模型判官，而是实际执行。只有通过执行器验证的样本，才能确保其正确性。

代码类数据的硬验收流程：

1. 语法检查：用编译器或 AST 解析器检查代码是否有语法错误。
2. 静态分析：检查是否有危险调用（如 os.system、eval）。
3. 沙箱执行：在隔离环境（Docker、firejail、内核沙箱）中运行代码。
4. 单元测试对比：运行预设的测试用例，检查输出是否与预期一致。
5. 通过标准：只有当所有公开测试用例（或一定比例）通过时，该代码样本才被接受。

数学类数据的硬验收流程：

1. 符号化验证：对于代数/几何问题，用 SymPy、WolframAlpha API 或 SMT 求解器验证推导过程和最终答案。
2. 数值验证：对于数值计算问题，用 Python 计算最终表达式的数值结果，与标准答案对比（允许浮点误差范围）。
3. 形式化证明检查：对于定理证明任务，用 Lean/Coq 等证明助手验证证明是否严谨。

SQL 类数据的硬验收：

1. 在沙箱数据库中执行生成的 SQL。
2. 对比查询结果与 gold result 是否一致（行数、列值、排序）。
3. 检查是否包含破坏性操作（DELETE/DROP），只允许 SELECT。

工程要点：

• 沙箱安全：执行器必须严格隔离，防止合成数据中的恶意代码破坏系统。
• 超时控制：每个执行任务设严格超时（如 5 秒），防止死循环拖垮系统。
• 测试用例覆盖：测试用例要覆盖常见边界条件，避免代码"碰巧"通过简单测试。

#295. 合成数据规模化时的成本优化策略有哪些？

#知识点

• 草案模型（Draft Model）
• 批量化生成
• 小模型打分
• Speculative Sampling
• 混合精度推理

#详细解答

合成数据规模达到百万级时，生成和验证成本会迅速膨胀。常用优化策略：

1. 小模型生成 + 大模型筛选

• 用成本低廉的小模型（如 7B 或蒸馏模型）批量生成候选样本。
• 只对通过初步过滤的候选，调用大模型（如 GPT-4/Claude）做高质量打分或重生成。
• 这能把高价模型调用量减少 80% 以上。

2. 批量化并行推理

• 利用 vLLM、TensorRT-LLM 等推理引擎的 batching 能力，把生成请求打包处理。
• 批量生成能显著提高 GPU 利用率，降低单样本成本。

3. Speculative Sampling 加速

• 用 draft model 生成候选 token，再由目标模型通过概率比快速接受/拒绝。
• 在 token 级减少目标模型的实际前向次数，尤其适合长文本生成场景。

4. 缓存与复用

• 对相似的 prompt（如相同任务模板、仅参数不同），缓存中间结果或 embedding，避免重复计算。
• 建立合成数据仓库，不同实验共享已通过验证的样本。

5. 分级验证策略

• 先用低成本启发式规则过滤掉 50% 以上的明显低质样本。
• 再用中等成本的模型判官筛选。
• 最后只对高优先级子集执行昂贵的硬验收和人工抽检。

6. 量化与蒸馏

• 生成器和评分器可以使用 INT8/INT4 量化模型，在精度损失可接受的情况下提升吞吐。
• 蒸馏一个专门用于质量判断的小模型，替代大模型判官。

#296. 合成数据中的隐私/版权泄露风险如何检测与缓解？

#知识点

• 数据泄露（Data Leakage）
• 近似重复检测
• 差分隐私（Differential Privacy）
• 版权与合规风险
• 人工抽检

#详细解答

风险来源：

合成数据由模型生成，但模型可能"记忆"训练语料中的特定片段，导致生成的样本与受版权保护的内容或敏感个人信息高度相似。

检测策略：

1. 近似重复检测

• 用 MinHash/LSH 或 embedding 相似度，将合成样本与已知的 copyrighted/PII 语料库做对比。
• 标记高相似度样本（如 n-gram 重叠率 > 40% 或 embedding 相似度 > 0.95）进行人工复核。

2. 敏感模式匹配

• 用正则表达式检测身份证号、手机号、邮箱、银行卡号、地址等 PII 模式。
• 对于代码，检测是否包含私有 API key、内部域名、员工姓名等。

3. 成员推断攻击（Membership Inference）

• 在学术研究中，可用成员推断方法检测合成样本是否"暴露"了训练数据的 membership。
• 工程上实现较复杂，通常只在高风险场景使用。

缓解策略：

1. 差分隐私（Differential Privacy）

• 在模型训练或推理阶段引入 DP 噪声，使生成的样本更难精确还原训练数据。
• 注意：推理层 DP 的效果通常弱于训练层 DP，且可能影响生成质量。

2. 去重与过滤

• 对高相似度样本执行强制删除或改写（paraphrase）。
• 对检测到 PII 的样本做 redaction 或丢弃。

3. 生成策略控制

• 降低生成温度，减少模型"照搬"记忆内容的可能性。
• 在 prompt 中明确加入"不要复制受版权保护内容"的指令约束（有一定效果但不完全可靠）。

4. 法务合规审查

• 对用于公开发布或商业产品的合成数据集，进行法务层面的版权审查。
• 高风险领域（医疗、金融）应增加人工抽检比例。

工程建议：

• 在合成数据 pipeline 中把"隐私/版权检查"作为独立节点，与质量检查并行运行。
• 保留完整的检测日志，记录被过滤样本的原因和来源，以便审计。