当AI开始批量"造人"：一个让合成图像数据集变得可信的工程方案

你有没有想过，训练一个能识别"人"的AI模型，到底需要多少张照片？

答案通常是几十万张，甚至几百万张。这些照片过去只能靠人工去拍、去标注、去筛选，成本高得吓人。于是这几年大家开始琢磨一件事：既然AI生成图片已经这么厉害了，能不能让AI自己批量造出这些训练数据？

听起来很美好，对吧？打开一个图像生成模型，输入"一个在海滩上的年轻女性"，几秒钟就能得到一张以假乱真的照片。理论上，你可以这样生成几万张、几十万张，凑成一个数据集。

但这里有一个几乎所有人都低估的陷阱。

生成一张成功的图片，和生成一整个成功的数据集，是两件完全不同的事情。这句话初听可能有点反直觉，毕竟"一张图能做好，一万张不就是重复一万次吗"是大多数人的第一反应。可事实并非如此。北京邮电大学的研究者Zhishan Zou在这篇论文里指出的问题恰恰是：单张图片生成得再逼真，堆在一起也未必是一个好数据集。

为什么"重复生成"造不出好数据集

这里的核心矛盾在于，一张图片只需要对一个具体的描述负责，而一个数据集需要对整个"分布"负责。

打个比方。假设你要给一个陌生人描述"中国人长什么样"，你不能只给他看一张你邻居的照片就说这就是标准答案。你得让他看到南方人、北方人、老人、小孩、穿正装的、穿运动服的、在办公室的、在菜市场的，各种各样的样本，他才能建立起一个靠谱的认知。如果每次生成图片都是让AI"随便发挥"，AI大概率会像一个偷懒的画家，反复画自己最擅长、最喜欢的那几种构图和人物类型，你以为自己攒了一万张多样化的照片，实际上可能只是同一种审美偏好被复制了一万遍。

这就是论文里提到的第一个坑：如果直接让大语言模型自由生成提示词（也就是描述文本），那些提示词会不自觉地带上语言模型本身的偏好，导致数据集在语义上并不像看起来那么多样。

第二个坑更隐蔽，涉及到属性之间的"常识兼容性"。

如果你分别独立地随机选择一个人的年龄、职业、穿着和场景，你可能会随机组合出"一个八十岁老人穿着婴儿装在攀岩馆里"这种荒谬的搭配。单独看每个属性都合理，年龄合理，穿着合理，场景合理，但拼在一起就是常识错误。这种独立采样导致的属性冲突，如果不加处理，会让生成出来的图片一批批地显得"怪怪的"，即便AI把每个元素都画得很精细。

第三个坑是质量控制在规模化之后必然会失控。

单张图片你可以肉眼检查一遍，但如果是几万张的量级，人工逐张审核基本不可能，靠感觉抽查又难免漏掉系统性问题，比如AI经常把人的手指画错、把多个人的脸拼接错位、或者生成的图片其实和描述文本对不上。这些错误在小规模下是瑕疵，在数据集规模下是会污染整个训练效果的系统性噪声。

> 人脸中心化数据集（human-centric dataset）：指的是图片内容以人物及其活动、互动、所处环境为核心可视内容的图像集合，常用于训练人像识别、姿态估计等视觉模型。

面对这三个坑，论文提出了一套叫做**Poplar**的完整流水线，试图用系统性的工程手段，把"造一堆好照片"这件事从碰运气变成可控可审计的过程。

Specify：先想清楚要造什么，再决定怎么说

Poplar的第一步叫Specify（规定），核心思路是把"这个数据集里应该出现什么内容"和"这句话该怎么措辞"这两件事彻底拆开处理。

这个拆分听起来简单，但背后的思路值得说一说。

如果你直接跟一个语言模型说"帮我写一百个人物照片的描述"，语言模型会同时决定"这个人是谁、在做什么"和"这句话具体怎么写"两件事。问题是，语言模型对"这个人是谁"这件事其实没有太强的责任感，它更擅长把一句话写得通顺好看，至于内容是否覆盖了足够多样的人群、场景、活动，它并不会主动去关心。

Poplar的做法是先用结构化的方式采样属性。论文里给出了一个公式，一个候选样本由一组属性组成，比如身份描述、服装、姿态或动作、场景、镜头视角、光照、构图、摄影风格,每一个维度都从一个可配置的概率分布里单独采样出来。这样做的好处是，数据集的构建者可以直接查看和调整每个维度的采样比例,比如想让"户外场景"多一点，"室内场景"少一点，直接改配置就行，而不需要去猜语言模型这次心情好不好。

采样完属性之后,系统会检查这些属性组合是否符合常识。论文用了一个逻辑与的公式来表示这个检验过程，简单说就是要求所有相关的兼容性规则同时被满足，才认为这个组合是有效的。具体规则包括年龄和场景是否匹配（比如八十岁老人一般不会出现在极限运动场景）、性别和服装的搭配是否合理、文化背景和服装风格是否协调、多人场景里每个人的脸型发型表情姿态是否各自独立而不重复。

> 常识兼容性约束（commonsense compatibility constraints）：一组用来判断随机采样出来的属性组合是否符合现实逻辑的规则集合，目的是过滤掉像"婴儿穿正装开会"这样的荒谬搭配，而不是限制罕见但合理的组合，比如一个纹身的老奶奶依然会被允许存在。

只有通过了这层检验的属性组合，才会被交给语言模型去转化成一段自然语言描述。这时候语言模型的角色变了，它不再是"内容策划者"，而是纯粹的"翻译官"，负责把结构化的属性字段串联成一句通顺的话，同时不能偷偷改变已经定好的内容。论文里管这个角色叫"verbalizer"（语言表达者），而不是"content generator"（内容生成者）。这个区分乍看是文字游戏，实际上决定了整个系统能不能被审计,如果语言模型既定内容又定表达，出了问题你根本没法追溯到底是内容规划错了还是表达错了。

除了内容层面的规划，Poplar还额外做了一件很聪明的事，叫作"摄影导向的提示词设计"。

现在的图像生成模型有个通病：只要你描述一个人和一个场景，它默认就会给你一张"摆拍风格"的精修照片,光线完美、构图讲究、表情刻意。可现实中的人像照片根本不是这样的，大部分是随手拍的、朋友帮忙拍的、自拍的，带着直闪光灯的生硬光影、随意的构图、甚至轻微的模糊。

Poplar的解法是在每个提示词里额外加入一层"拍摄条件"的描述，明确说明这张照片是被谁拍的、用什么设备拍的、镜头角度是什么、光线条件如何，甚至要写清楚"拍照的人和设备本身不在画面里"这种细节，避免生成结果里出现奇怪的镜像手机或者多余的自拍杆。

论文里给了一个很直观的对比实验。同样描述一个在沙滩上穿着棕色上衣的女性，如果只写内容层的描述,一个漂亮的年轻女性优雅地站在沙滩上，光线唯美，效果精致电影感,几个不同的图像生成模型（GPT Image 2、Seedream 4.5、Qwen-Image-2.0）生成出来的都是那种杂志封面级别的精修照片。而一旦在提示词里加上"由朋友的手机拍摄，直闪光灯打在脸上，姿态略微前倾"这样的拍摄层描述，同样几个模型生成出来的画面立刻变成了那种带点随意感、构图不完美但真实感更强的生活照。

这个对比其实很说明问题。如果不做这层拍摄条件的设计，会发生什么？你会得到一个数据集，里面全是"完美摆拍"，而现实世界里绝大多数人像照片根本不长这样。用这种数据训练出来的模型，一旦遇到真实场景里那些光线不均匀、构图随意的照片，识别效果可能会打折扣，因为它压根没在训练数据里见过这种"不完美"的正常照片。

这就好比你想让一个学生学会认路，但你只给他看过城市规划图上那种笔直宽敞的林荫大道，从没让他见过真实生活里那些歪歪扭扭的小巷子和临时施工的路障。等他真的走到大街上，反而会因为见过的样本太单一而认不出常见的场景。

Render：让生成引擎只管画画,别管别的

Poplar流水线的第二个环节叫Render（渲染），它负责把前面规划好的结构化内容和自然语言描述真正变成一张图片。

这一步有个设计原则挺值得说的：Poplar本身不发明新的图像生成模型，而是把一个现成的、预训练好的图像生成器当作一个"可替换的渲染后端"来使用。

这个决定看似平平无奇，实际上关乎整个系统的生命周期。图像生成技术这两年迭代速度快得惊人，今天最好的模型半年后可能就落后了。如果Poplar把某个具体模型的架构死死绑定在流水线里，那这套系统很快就会过时。把生成器设计成可插拔的组件，意味着以后有更好的模型出现，直接换掉底层引擎就行，不需要动前面的属性规划逻辑，也不需要动后面的质量审查逻辑。

论文里实际用的渲染后端是Krea 2 Turbo模型配合一个叫Krea2-realism-V2的适配器。

> 适配器（adapter）：一种附加在基础生成模型上的小型调整模块，这里的作用是让生成结果的纹理、光照、相机质感更偏向自然真实，而不改变基础模型本身的结构。

提示词负责告诉生成器"画什么内容"，适配器负责让画出来的东西"看起来更像真实照片而不是插画感的AI图"，两者分工明确。

渲染阶段还有一个值得展开讲的设计，叫做多宽高比生成。

如果一个数据集里所有图片都是同一个宽高比，比如清一色的正方形构图，那这个数据集其实隐含了一种很狭窄的构图偏好。真实世界的人像照片有竖屏的自拍、有横屏的合照、有各种长宽比例。Poplar为此设计了一个采样机制，会根据具体的属性内容自动选择合适的画布比例，比如镜子自拍和全身照更适合竖版构图，多人合影和环境类照片更适合横版构图。系统一共支持五种比例：1:1、2:3、3:2、3:4、4:3。需要说明的是，这五种比例是用来让整个数据集的构图更丰富，并不是说每条提示词都要生成五次。

渲染完成后，Poplar还加了一层"初步视觉过滤"，这一步是纯粹基于图像本身的技术检测，不涉及任何语义理解。具体做法是测量图片的平均色彩饱和度和接近灰色像素的比例来判断是不是意外生成了近乎黑白的图片，再计算灰度边缘响应的方差来判断图片是不是异常模糊或者细节丢失严重。每张保存下来的图片文件还会被重新打开验证一遍，确保没有文件损坏或者截断的问题。

这一步的阈值设置得相当保守，论文特意强调这个阶段只负责剔除明显的技术性失败，不负责给图片打审美分数。一旦某张图片没通过这层检测，它会被归档记录下具体的失败指标，然后系统会用相同的提示词换一个新的随机种子重新生成一次。

这个"重试"机制其实很关键。想象一下你在一个流水线上组装产品，某个零件明显有裂痕，你肯定不会把它硬塞进最终产品里，而是直接扔回返工区用新的材料重新做一个，同时把这次失败的原因记下来方便后续排查。如果不做这层检测，会发生什么？那些技术性的生成失败,比如模糊、灰阶异常、文件损坏,会原封不动地混进后面更昂贵的语义审查环节，浪费审查资源不说，还可能因为审查环节没有专门针对这类问题设计规则而被漏放行。

Inspect：让AI自己给AI生成的图片挑错

如果说前两步解决的是"内容规划得对不对"和"画得像不像真实照片"，那么Poplar的第三步Inspect（审查）解决的是一个更棘手的问题：这张图片看起来技术上没毛病，但它是不是真的忠实反映了原本想要的内容？

这一步的必要性来自一个很扎心的事实。现在的图像生成模型经常会"只听懂一半的话"。比如提示词里明明写了两个人，生成出来的图可能只有一个人；或者提示词说的是一个人在做瑜伽，生成出来的姿势却完全对不上；又或者出现更隐蔽的问题，比如画面里两个人的脸长得一模一样，明显是同一张脸被复制粘贴了两次，又或者衣服的接缝处出现了诡异的拼贴痕迹，甚至偶尔会生成不合适的裸露内容。

这些问题有一个共同特点：单纯从像素层面看，图片可能是清晰的、色彩正常的，完全能通过前一步的技术性过滤，但它在语义上是错的，甚至是有害的。

论文里给出了一组挺直观的反面案例分类，包括拼贴痕迹、主体重复、人物布局异常或者脸部不可见、常识违反、还有其他各类生成失败模式。这些案例被特意展示出来，是为了说明一件事：光靠文件层面的技术检测，是抓不住这些问题的。

Poplar的解法是引入一个视觉语言模型作为最后一道审查关卡，具体用的是Qwen3.5-27B-FP8这个模型，对每张候选图片进行一次结构化的审查。

> 视觉语言模型（vision-language model）：一种同时能"看图"又能"读懂文字描述"的AI模型，能够判断一张图片的具体内容是否和文字描述相符，这里被用来充当自动化的质检员角色。

这个审查过程被设计成结构化输出，而不是简单地打一个"好/坏"的分数。审查结果会包含几类信息：一是内在缺陷标记，包括明显的AI生成痕迹、拼贴或重复布局、脸部缺失或被裁切、解剖结构或物体交互错误、内容不合理、露骨裸露、单色或损坏输出;二是提示词不匹配列表，会对比人数、性别呈现、场景、服装、年龄范围、是否有可见的脸这几个维度和原始提示词是否一致，并给每处不匹配标注严重程度是"关键"、"主要"还是"轻微";此外还会记录画面里实际可见的人数、服装描述、脸部是否可见、模型对这次判断的置信度，以及支撑判断的简明证据。

论文给出了一个清晰的判定规则:只有当没有任何内在缺陷被标记，并且没有任何"关键"或"主要"级别的不匹配被报告时，这张图片才会被系统判定为合格保留。

这套设计背后的用意其实是拒绝用一个模糊的总分来决定图片的去留。

如果只给一个笼统的分数，比如"这张图 7.5分，及格"，你根本没法知道这张图到底哪里出了问题，也没法在事后复查审查标准是不是设得太严或者太松。而结构化的多维度记录，让每一次拒绝都有据可查，你可以清楚地看到这张图是因为"人数不对"被拒的，还是因为"脸部看不清"被拒的。

这就好比一个餐厅后厨的质检流程。如果质检员只说"这道菜不合格"，厨师根本不知道下次该改进什么，是火候不对、调料放多了，还是摆盘不整齐？但如果质检记录写清楚"咸度超标、摆盘歪斜、食材新鲜度合格"，这份记录不仅决定了这道菜今天上不上桌，还能反过来帮厨房改进整个流程。Poplar的结构化审查记录起到的正是这个作用,不只是一个"通过/不通过"的开关，而是一份可以事后复盘、可以用来调整整个生成策略的诊断报告。

还有一个细节值得单独说一下：审查环节被明确禁止修改或者重写原始提示词。

一张图片如果通过了审查，它保留的是最初生成时那个字节都不变的提示词。这个设计初衷是为了保护整个系统的可追溯性,如果审查模型可以在看到生成结果之后回头修改提示词，那"提示词和生成结果是否匹配"这件事本身就失去了检验的意义，相当于考试的时候允许改题目来凑答案。

Poplar-9K：11765张候选里留下的9401张

理论说了这么多，最终还是要看实际跑出来的结果。

论文团队用四块NVIDIA GeForce RTX 4090显卡跑了一次完整的Poplar流水线，构建出了一个叫做**Poplar-9K**的开源数据集。

整个构建过程产出了11765张候选图片，全部提交给视觉语言质量审查环节。每张候选图片都配有它对应的摄影导向提示词和结构化属性记录，并且已经按照前面说的规则渲染在五种构图比例之一上。

经过审查之后，9401张图片被保留下来，2364张被拒绝，整体的接受率是79.9%。

这个79.9%的数字挺有意思，它意味着即便有了前面精心设计的属性采样、常识约束、摄影导向提示词这么多道关卡，最终仍然有超过五分之一的图片没能通过最后的语义审查。这从侧面说明了图像生成本身的不确定性有多大，也说明了这道最后关卡确实在发挥实际作用，而不是走过场。

数据集的统计特征也挺值得看一眼。9401张图片里一共包含10877个被描绘的人物,这个数字比图片数量多，是因为一部分图片里有多个人同时出现。年龄分布上，年轻成年人占比最大，但整个数据集也覆盖了从三十多岁到七十多岁的人群。在13个采样的文化背景描述符里，各个群体的占比大致在6.9%到8.5%之间，说明在这套采样配置下覆盖得比较均衡。

服装分布覆盖了休闲装、时尚风格、居家服、运动装、街头风、工作装、正装以及一些特定文化风格的服饰，其中休闲装占比最高，达到18.8%，紧接着是偏时尚女性风格的15.5%和居家服的12.3%。场景分布则呈现出更长的尾部特征，即便是最高频的一个具体场景，占比也只有3.8%，覆盖了家庭内部空间、社区街道、公共场所、旅行场景和各种户外环境。

需要特别澄清的一点是，这些年龄和文化背景的统计数字，反映的是生成时设定的合成属性，而不是从生成图像里反推出来的真实人口统计标签，更不代表任何真实存在的个体身份。这一点论文在"范围与局限"部分特别强调过。

Poplar-9K的可复现性设计:不只是给你图片，还给你整个过程

这篇论文一个挺打动我的地方，是它对"可复现性"这件事的执念。

论文提到了Datasheets for Datasets和Data Cards这两个已有的数据集文档化倡议，核心理念是要向下游用户清楚地传达一个数据集的构建动机、组成方式、构建过程和适用场景。Poplar在这个基础上更进了一步，做法是把人类可读的数据集说明和一份可执行的构建记录绑在一起发布。

> Datasheets for Datasets 和 Data Cards：两种数据集文档化规范，倡导数据集发布时应附带清晰的说明文档，交代数据从哪来、怎么构建的、适合用在什么场景，避免数据集变成一个来源不明的黑箱。

具体来说，发布出来的配置文件固定了分类体系的版本、随机种子、候选图片预算、模型标识符、宽高比集合、渲染参数、预过滤阈值和审查规则。提示词生成分两个可恢复的批次完成，全部用Qwen3.5-27B-FP8跑的。渲染环节用的是Krea 2 Turbo加Krea2-realism-V2适配器，缩放系数1.5，推理步数8步，引导系数为0，画布的长边不超过1024像素。审查阶段同样用Qwen3.5-27B-FP8，采用确定性解码，每张图片只调用一次模型。

每个阶段都会持续追加JSONL格式的记录，并且跳过已经处理完的标识符，这意味着如果整个生成过程中途被打断，重新启动之后不会把之前已经生成好的样本悄悄覆盖掉。

> JSONL：一种每行都是一个独立JSON对象的文本文件格式，方便逐条追加记录，也方便在系统中断后按行恢复进度，不需要重新处理已完成的部分。

对于每一张最终保留下来的图片，发布出来的数据附带四层溯源信息：不可变的原始提示词及其哈希值、结构化属性和对应的分类体系版本、渲染设置（包括尺寸、请求的种子和实际使用的种子、以及初步过滤阶段的历史记录）、以及最终的结构化审查记录。而那些被拒绝的候选图片，也没有被简单丢弃，而是在一份独立的审计清单里保留了问题类别、严重程度、可见证据和置信度。

这套设计想解决的问题其实很实际。如果一个数据集只告诉你"这里有9401张图"，却不告诉你这些图是怎么筛出来的、被拒绝的2364张长什么样、拒绝的理由是什么，那这个数据集对使用者来说就是一个不透明的黑箱，你没法判断它是不是符合你自己的需求，也没法在发现问题之后去追溯到底是哪个环节出的错。Poplar选择把这11765到9401的整个筛选漏斗完整暴露出来，这意味着任何研究者都可以拿着这份审计记录去复核审查标准是不是过严或者过松，甚至可以直接替换掉审查规则重新跑一遍。

论文自己承认的局限,也挺重要

这篇论文有一点让我觉得挺踏实的，就是作者没有回避这套方法的局限性，专门用一节篇幅讲了"范围与局限"。

论文明确指出，Poplar是一个数据集构建项目，不是一个新的图像生成模型，也不是新的语言模型，更不是一个新的学习型质量评估指标。Poplar-9K的规模是刻意保持"适度"的，它演示的是一种可配置的采样策略，而不是声称能够复现真实人类摄影的完整分布。

前面提到的那些兼容性规则，虽然能减少明显的属性冲突，但这些规则本身不可避免地包含了设计者的主观判断，一些不常见但依然合理的属性组合可能因此被低估。

自动化审查这一环也不是万无一失的。视觉语言模型可能会漏掉一些细微的图像瑕疵，也可能误判一张其实合格的图片。像素层面的确定性检测也只能覆盖很窄一部分技术性问题。正因如此，论文才选择把审查证据和被拒绝样本的元数据一并公开，让使用者有机会自己去审查甚至替换这套审查策略。

论文的最后一句提醒也很直接：数据集里生成的人物都是合成出来的，不应该被当作真实个体的记录。任何涉及身份识别、人口统计测量或者高风险决策的应用场景，都需要超出这个项目范畴的额外验证。

写在后面

读完这篇论文，我最大的感触是它把一个大家容易忽视的问题摆到了台面上：合成数据集的"可信度"不是靠单张图片的逼真程度堆出来的，而是靠一整套流程设计撑起来的。

有个细节我觉得特别值得单拎出来说,论文里提到那个79.9%的接受率。这个数字某种程度上打破了我原来的一个默认假设,我以为既然前面已经用常识约束筛掉了大部分不合理的属性组合，最后的图片质量应该会更稳。但实际情况是，超过五分之一的候选图片依然在最后一关被刷掉了，这说明属性层面的正确不能保证渲染层面的正确，语义规划得再周密，生成模型本身依然会在细节上出岔子，比如多画一张脸、少画一根手指。这提醒我们，任何试图用AI批量生产内容的系统，中间每一层的误差都是真实存在且会累积的，靠单一环节的完美设计根本堵不住所有漏洞。

另外一个让我有点意外的地方是，论文特意强调审查模型不能修改提示词。这个约束乍看是个小细节，但仔细想想，它其实是整套系统"诚实性"的根基,如果允许审查环节回头改提示词去凑合生成结果，整个数据集的可信度就会从根上垮掉。这种对"事后不能篡改记录"的坚持，让我联想到了一些审计和会计领域的基本原则，本质上是一样的逻辑。

这套流程目前还没能解决的一个问题是：审查完全依赖一个视觉语言模型的主观判断，如果这个模型本身存在偏见或者盲点，这些偏见会不会系统性地渗透进最终的数据集里？这大概是下一步值得追问的方向。

Q&A

Q1：Poplar是什么？

A：Poplar是一套用于批量生成人像为中心图像数据集的工程流水线，由Specify、Render、Inspect三个阶段组成，分别负责属性规划与提示词生成、图像渲染、以及AI自动质量审查，目的是让合成数据集在语义多样性、常识合理性、视觉真实感和图文一致性上都可控。

Q2：Poplar-9K数据集是怎么来的？

A：研究团队用四块NVIDIA RTX 4090显卡跑Poplar流水线，一共生成了11765张候选图片，经过视觉语言模型逐张审查后，保留了9401张图片，拒绝了2364张，最终接受率为79.9%，构成了开源的Poplar-9K数据集。

Q3：Poplar-9K里的人物是真实存在的人吗？

A：不是，数据集里的所有人物都是AI生成的合成图像，年龄和文化背景等统计信息反映的是生成时设定的属性，不代表任何真实个体的身份，也不应被当作人口统计学的真实标签使用。