RealUnify: Do Unified Models Truly Benefit from Unification? A Comprehensive Benchmark

Paper: arXiv:2509.24897 Code: FrankYang-17/RealUnify Code reference: main @ 0b76a109 (2025-10-10)

1. Motivation (研究动机)

统一多模态模型的核心承诺不是“一个模型会看图也会画图”这么简单，而是理解能力与生成能力应该互相增益：理解侧的知识、常识、逻辑、数学推理能让生成结果更准确；生成侧的可视化与 mental simulation 又能帮助模型完成更复杂的视觉理解。RealUnify 要回答的就是这个更尖锐的问题：architectural unification 是否真的带来了 capability synergy，还是只是把理解与生成两个功能放在同一个系统里共存。

现有评测的缺口在于，大多数 benchmark 只测单向能力或并列能力。理解类 benchmark 测 VQA / multiple-choice / OCR 等，生成类 benchmark 测 prompt fidelity、审美、文本对齐或局部 reasoning；一些 unified benchmark 也只是把理解任务和生成任务放进同一套表格里，并不能判断“完成这个任务是否必须依赖两种能力的交互”。因此，如果一个模型在理解任务上强、生成任务上也能跑，传统评测仍然无法区分它是“真统一”还是“两个能力彼此隔离”。

这件事值得研究，是因为下一代 general-purpose multimodal AI 需要处理的是现实问题而不是孤立任务：例如先根据数学/物理/常识约束推导出应画什么，再生成满足约束的图像；或者先把打乱、裁剪、标注、变换后的视觉输入在脑中重构出来，再回答问题。若统一模型不能在这些任务中把 understanding 与 generation 联动起来，那么“统一架构”本身并不能保证智能提升，后续就需要新的训练策略、数据构造和 inductive bias。

Figure 1 解读：这张图把统一模型评测分成几个阶段：Stage 1 只测理解或生成的单项能力；Stage 1.5 把两类任务放到同一 benchmark 里但仍不要求交互；Stage 2 开始考察单向增益；RealUnify 进一步要求双向 synergy，即 $u n d ers t an d in g \to g e n er a t i o n$ 与 $g e n er a t i o n \to u n d ers t an d in g$ 都要被任务显式触发。

2. Idea (核心思想)

RealUnify 的核心 insight 是：评测统一模型不应只问模型是否具备两种能力，而要问它是否能在同一个任务链条中让一种能力成为另一种能力的必要中间步骤。因此 benchmark 的样本被设计成两条互补轴线：Understanding Enhances Generation (UEG) 与 Generation Enhances Understanding (GEU)。

关键创新是 dual-evaluation protocol。Direct evaluation 让模型端到端完成任务，近似真实部署；stepwise evaluation 把任务拆成两个显式阶段，用来诊断失败到底来自单项能力不足，还是来自两项能力无法自动整合。这个设计让 RealUnify 不只是“又一个综合榜单”，而是一个用于定位 unified model bottleneck 的诊断工具。

与 MME-Unify / UniEval 这类综合评测不同，RealUnify 的任务不是简单覆盖理解与生成两个栏目；与 WISE、T2I-CoReBench 等 T2I reasoning benchmark 不同，它不仅看理解是否帮助生成，还反过来看生成/重构/可视化是否能帮助理解。论文用 1,000 个 human-annotated instances、10 个类别、32 个 subtasks，把“能力协同”做成了可测量对象。

Benchmark	Category	QA	Tasks	Subtasks	Annotation	Eval	Und.	Gen.	Ability Synergy
MME-Unify	Unified	4,104	14	-	Mixed	Direct	✓	✓	✗
UniEval	Unified	1,234	13	81	(M)LLM	Direct	✓	✓	✗
WISE	T2I	1,000	3	25	Mixed	Direct	✗	✓	✗
MMBench	I2T	3,217	6	20	Mixed	Direct	✓	✗	✗
RealUnify	Unified	1,000	10	32	Human	Direct/Step	✓	✓	✓

3. Method (方法)

3.1 Overall framework：双向协同评测

RealUnify 将任务组织成两大类：UEG 评估理解是否能提升生成，GEU 评估生成/重构是否能提升理解。每个样本都不是单独的生成或选择题，而是刻意让模型先用一种能力推导出中间信息，再用另一种能力完成最终任务。

Figure 2 解读：上半部分是 UEG，模型必须先理解 prompt 中隐含的 world knowledge、commonsense、math、logic、science 或 code execution，再把推理结果落实为图像；下半部分是 GEU，模型面对被打乱、变换、遮挡、需要导航的视觉输入，理想路径是先生成或重构中间视觉状态，再完成 multiple-choice reasoning。

直觉上，direct evaluation 是“模型自己决定是否、何时、如何调用内部生成/理解能力”；stepwise evaluation 则是“外部强制拆解任务链条”。如果 stepwise 明显好于 direct，说明模型可能有单项能力但不能自发协同；如果 stepwise 仍然差，说明单项能力本身也不足。RealUnify 的价值正是在于把这两种失败分开。

3.2 UEG：Understanding Enhances Generation

UEG 的输出是图像，输入是需要先理解或推理的文本指令。论文设计了 6 个类别，每类 direct 与 stepwise 各 100 个样本：

World Knowledge：要求生成内容符合客观世界知识，覆盖 Animals & Plants、Food、Architecture、Culture、Sports、Technology、Lifestyle 7 个知识域。
Commonsense Reasoning：要求图像符合日常常识、物理直觉、人类活动和常见物体关系。
Mathematical Reasoning (MR-I)：生成前必须完成数值计算、概率估计、比例推理或约束方程求解。
Logical Reasoning：需要追踪显式/隐式条件，让生成图像满足组合条件或反事实约束。
Scientific Reasoning：覆盖 Physics、Chemistry、Biology、Geography 4 个科学域，要求根据科学原理推导可观察结果。
Code-to-Image (C2I)：模型先解析代码和输入，推断程序执行后的文本指令，再生成对应图像。

Figure 7 解读：这一组展示 UEG 的第一批代表样例。每个 panel 的关键不是“画得好不好”，而是模型是否先完成了隐藏的理解步骤：例如知识检索、常识判断、数学计算、逻辑条件合成、科学现象推断或代码执行结果推导。

Figure 9 解读：第二组 UEG 样例强调同一类别内部的多样性。RealUnify 不是只测 prompt-following，而是把 prompt-following 建立在 reasoning correctness 上；如果中间推理错了，最终图像即使美观也会被判错。

3.3 GEU：Generation Enhances Understanding

GEU 的输出是 multiple-choice answer，输入是图像、问题和候选项。它要求模型用生成式可视化或 mental reconstruction 辅助理解，包含 4 个类别，每类 direct 与 stepwise 各 100 个样本：

Mental Reconstruction (MR-II)：图像被切成不同粒度的 patches 后打乱，模型需要根据空间、匹配、关系线索重构原图语义，再回答问题。
Mental Tracking (MT)：输入是由彩色线段构成的数字，模型要追踪多步颜色变换，例如先把 blue 改成 green，再把 green 改成 yellow，最后回答某个颜色对应的数字。
Attentional Focusing (AF)：考察模型是否能聚焦复杂视觉输入中的关键区域。传统方法可能用 crop、bbox、super-resolution；统一模型的理想路径是直接利用生成能力突出目标区域，帮助理解。
Cognitive Navigation (CN)：包含 maze navigation 与 map navigation。前者用合成迷宫，后者使用 Google Search API 来源地图，要求模型求最短路线或按约束路径导航。

Figure 8 解读：GEU 样例把“生成”从最终输出变成理解过程中的工具。模型需要在脑内或显式中间图里重排 patches、更新颜色状态、放大注意区域或规划路径，最后才做选择题。

Figure 10 解读：第二组 GEU 样例显示 direct answer 往往不够，因为视觉输入被扰动或信息分布复杂。stepwise protocol 要求模型先生成中间图像或编辑结果，再把这个中间结果作为理解输入。

3.4 Data construction and annotation

数据构造强调人工可靠性。UEG prompts 由 10 名 human experts 手工设计，之后由 3 名额外 reviewers 独立检查 correctness、objectivity 和 answer uniqueness，只有一致通过的样本被保留。GEU 中 Mental Reconstruction、Mental Tracking、Cognitive Navigation 使用自动数据构造 pipeline，再经过人工过滤与验证；Attentional Focusing 从 BLINK 与 HR-Bench 采样后再人工核验；Cognitive Navigation 的 map images 来自 Google Search API，问题与答案由专家给出。

任务分布保持均衡：UEG 6 类各 100 个 direct / 100 个 stepwise 样本，共 600；GEU 4 类各 100 个 direct / 100 个 stepwise 样本，共 400；总计 1,000 / 1,000。

Figure 4 解读：统计图对应上面的均衡设计：10 个任务类别被分成 UEG 与 GEU 两组，并进一步展开为 32 个 subtasks。这样的设计避免 benchmark 被单一任务类型主导，使 total score 更接近“跨能力协同”的平均表现。

3.5 Direct evaluation 与 stepwise evaluation

Direct evaluation 中，UEG 要求模型直接根据问题生成 target image；GEU 则给定 image、question 和 A/B/C/D options，模型直接输出最合适选项。UEG 生成结果用 polling-based judging：每个生成图像附带一组 yes/no verification questions，由 Gemini 2.5 Pro 判断图像是否满足所有约束。

Figure 3 解读：polling evaluation 把图像质量评估拆成一组可验证 yes/no 问题。只有当生成图像在所有关键问题上都与 ground truth 一致时，该样本才计为正确；这比单一整体打分更适合检查多约束生成。

Stepwise evaluation 显式拆成 2 个阶段。UEG 中，模型先用纯文本解决理解/推理问题，得到 refined instruction，再用该 instruction 生成图像；GEU 中，模型先根据输入生成或编辑中间图像，再基于该图回答选择题。记第 $i$ 个 UEG 样本的验证问题集为 $Q_{i}$ ，judge 输出为 $J (I_{i}, q)$ ，标准答案为 $a_{q}$ ，则代码实现的样本级分数可写为： $S_{i}^{U EG} = 1 [\forall q \in Q_{i}, J (I_{i}, q) = a_{q}] .$ GEU 中，如果模型回复经解析后的选项为 $\overset{y}{^}_{i} \in {A, B, C, D}$ ，标准答案为 $y_{i}$ ，则： $S_{i}^{GE U} = 1 [\overset{y}{^}_{i} = y_{i}], A c c_{t} = \frac{1}{N _{t}} \sum_{i \in t} S_{i} .$ released code 中每个 task 的 denominator 写成 100，与 Table 6 的均衡样本数一致；total accuracy 则等价于所有 task 的均衡平均。

3.6 Released code pseudocode

论文没有训练 loss 或 model architecture 修改；开源仓库主要释放 benchmark、README 与 evaluation scripts。伪代码基于 main@0b76a109 的 eval/eval_generation.py 与 eval/eval_understanding.py。

def score_ueg_generated_image(item, judge_model):
    item = copy.deepcopy(item)
    max_retry = 15
    image_path = item["generated_image"]
    if image_path in ("", None) or not os.path.exists(image_path):
        item["score"] = 0
        return item
 
    for qa in item["question_list"]:
        question = qa["question"]
        gt_answer = qa["answer"].lower()
        response = ""
        for _ in range(max_retry):
            prompt = (
                "Please answer the following question based on the image:\n"
                f"Question: {question}\n\n"
                "You should only reply yes or no, and do not provide any other extra content."
            )
            response = judge_model(prompt, image_file=image_path)
            if response:
                break
        if response.lower().strip() != gt_answer:
            item["score"] = 0
            return item
 
    item["score"] = 1
    return item

def extract_characters_regex_like_code(response: str) -> str:
    response = response.strip().upper()
    for prefix in ["ANSWER:", "THE ANSWER IS", "OPTION", "CHOICE"]:
        response = response.replace(prefix, "")
    if len(response.split()) > 10 and not re.search("[ABCD]", response):
        return ""
    match = re.search(r"[ABCD]", response)
    return "" if match is None else match.group(0)
 
 
def score_geu_multiple_choice(item):
    pred = extract_characters_regex_like_code(item["response"])
    return int(pred == item["answer"].strip().upper())

def evaluate_generation_file(json_file, result_dir):
    data = load_jsonl(json_file) if json_file.endswith(".jsonl") else load_json(json_file)
    with ProcessPoolExecutor(max_workers=16) as executor:
        scored = list(executor.map(score_ueg_generated_image, data))
    result_path = result_dir / f"{model_name}.json"
    save_json(scored, result_path)
    return compute_per_task_accuracy(scored, denominator_per_task=100)

论文公式与 released code 实现差异：论文把 Gemini 2.5 Pro judge 与 direct/stepwise protocol 描述为评测流程的一部分，但仓库中的 get_response_from_judge_model() 是 TODO/pass，需要使用者自行接入 Gemini 2.5 Pro 或其它 judge API；具体 gap: get_response_from_judge_model() 是 TODO/pass。仓库也不包含统一模型推理 wrapper 或训练配置，只提供数据说明与打分脚本。因此 note 中的 code mapping 只锚定 benchmark evaluation，不把论文结果误写成“一键可复现实验”。

Code reference: main @ 0b76a109 (2025-10-10) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
UEG direct / stepwise result file protocol	`README.md`	`UEG_direct.json`, `UEG_step.json`, `prompt`, `new_prompt`, `generated_image` fields
GEU direct / stepwise result file protocol	`README.md`	`GEU_direct.json`, `GEU_step.json`, `evaluation_prompt`, `edit_prompt`, `edit_image`, `response` fields
UEG polling judge	`eval/eval_generation.py`	`process_one()`, `get_response_from_judge_model()`
UEG per-task accuracy	`eval/eval_generation.py`	`evaluate_accuracy()`, `task_dic`, denominator `100`
GEU multiple-choice parsing	`eval/eval_understanding.py`	`extract_characters_regex()`, regex over `[ABCD]`
GEU per-task / total accuracy	`eval/eval_understanding.py`	`cal_multiple_choice_acc()`

4. Experimental Setup (实验设置)

4.1 Dataset and scale

RealUnify 共有 1,000 个 human-annotated instances，并在 direct 与 stepwise 两种设置下各评一次。任务分布如下：

Group	Task	Number (Direct / Stepwise)
UEG	World Knowledge	100 / 100
UEG	Commonsense Reasoning	100 / 100
UEG	Mathematical Reasoning	100 / 100
UEG	Logical Reasoning	100 / 100
UEG	Scientific Reasoning	100 / 100
UEG	Code-to-Image	100 / 100
GEU	Mental Reconstruction	100 / 100
GEU	Mental Tracking	100 / 100
GEU	Attentional Focusing	100 / 100
GEU	Cognitive Navigation	100 / 100
Total	-	1,000 / 1,000

4.2 Models and baselines

Unified models 共 12 个：BAGEL-7B、OmniGen2、Ovis-U1-3B、UniWorld-V1、UniPic2-Metaquery-9B、OneCAT-3B、MIO、ILLUME+、Show-o2、Janus-Pro、BLIP3-o，以及 closed-source Gemini-2.5-Flash-Image / Nano Banana。

Specialized baselines 用于估计单项能力上界：understanding 侧为 Gemini 2.5 Pro、GPT-4.1、Qwen2.5-VL-7B；generation 侧为 FLUX.1 Kontext、Qwen-Image、GPT-Image-1。论文还组合 Gemini 2.5 Pro 与 GPT-Image-1 做 stepwise upper-bound style comparison。

4.3 Metrics and protocols

UEG 指标是生成图像通过 Gemini 2.5 Pro polling questions 的 accuracy；GEU 指标是 multiple-choice accuracy。所有表中数值都是百分比。Direct protocol 测端到端协同；stepwise protocol 显式拆解 understanding / generation，以定位 bottleneck。Judge reliability 额外比较 Gemini 2.5 Pro、Qwen2.5-VL 与 4 位 human experts 的平均人工评测。

4.4 Training / inference configuration

这不是训练新模型的论文，论文未报告新的 training loss 或训练超参数（如 GPU/steps、LR、batch）。实验使用各模型官方默认或推荐设置；released code 只包含评测脚本与数据字段约定。可复现相关的明确配置是：UEG judge 推荐 Gemini 2.5 Pro；eval_generation.py 默认 MAX_RETRY=15、ProcessPoolExecutor(max_workers=16)；GEU 用 A/B/C/D parser 计算选择题正确率。

5. Experimental Results (实验结果)

5.1 Main RealUnify results

主结果显示：现有 unified models 在 direct evaluation 下并没有表现出强协同。UEG 中最佳 open-source direct avg 是 UniPic2 / OneCAT 的 37.5，远低于 proprietary Nano Banana 的 63.0；GEU 中 open-source 模型理解能力相对更强，例如 BAGEL direct GEU avg 为 39.3、Ovis-U1 为 39.0、BLIP3-o 为 37.5，而 Nano Banana direct GEU avg 只有 31.8。

Model	UEG Avg direct/step	GEU Avg direct/step	Total direct/step
Nano Banana	63.0 / -	31.8 / -	50.5 / -
MIO	14.5 / 18.3	25.8 / 20.3	19.0 / 19.1
Janus-Pro	25.0 / 25.2	25.3 / -	25.1 / -
ILLUME+	29.7 / 32.3	27.8 / 27.5	28.9 / 30.4
Show-o2	28.0 / 29.5	30.3 / -	28.9 / -
OmniGen2	30.3 / 32.5	32.5 / 30.8	31.2 / 31.8
UniPic2	37.5 / 40.5	24.0 / 23.8	32.1 / 33.8
UniWorld-V1	35.0 / 35.2	32.3 / 28.5	33.9 / 32.5
Ovis-U1	31.2 / 39.3	39.0 / 29.5	34.3 / 35.4
BLIP3-o	33.0 / 36.0	37.5 / -	34.8 / -
OneCAT	37.5 / 39.0	31.3 / 29.3	35.0 / 35.1
BAGEL	32.7 / 47.7	39.3 / 35.8	35.3 / 42.9

最关键的诊断结果来自 direct/stepwise 差异：UEG stepwise 普遍提升，尤其 BAGEL 从 32.7 提升到 47.7，说明模型并非完全没有相关知识，而是 direct setting 下不能自动把理解结果转成生成约束；GEU stepwise 反而常下降，例如 BAGEL 从 39.3 降到 35.8、Ovis-U1 从 39.0 降到 29.5，说明把生成作为显式中间步骤并不天然提升理解，当前生成能力在解决真实问题时仍可能引入噪声。

5.2 Specialist comparison and upper bound

与 specialized models 比较时，generation specialists 在 UEG 上仍强：GPT-Image-1 total 62.2、Qwen-Image 52.2、FLUX.1 Kontext 40.0；Nano Banana 63.0 接近甚至略高于 GPT-Image-1，但 open-source unified models 仍有明显差距。GEU 中 understanding specialists 的 total 为 Gemini 2.5 Pro 54.8、GPT-4.1 38.5、Qwen2.5-VL 34.5；BAGEL 39.3、Ovis-U1 39.0、BLIP3-o 37.5，说明部分 unified models 的理解侧已经接近或超过一些 specialist baseline。

Setting	Model / Combination	Key exact result
UEG specialist	GPT-Image-1	62.2 total
UEG specialist	Qwen-Image	52.2 total
UEG specialist	FLUX.1 Kontext	40.0 total
GEU specialist	Gemini 2.5 Pro	54.8 total
GEU specialist	GPT-4.1	38.5 total
GEU specialist	Qwen2.5-VL	34.5 total
UEG combined SOTA	Gemini 2.5 Pro + GPT-Image-1 stepwise	72.7 total
GEU combined SOTA	GPT-Image-1 + Gemini 2.5 Pro stepwise	31.8 total

72.7 的 UEG upper-bound 说明，如果先用强理解模型得到正确中间语义，再交给强生成模型，RealUnify 的许多复杂生成任务是可解的；但现有 unified open-source direct/stepwise 仍远达不到这个水平。GEU combined SOTA 只有 31.8，反而说明 photorealistic generation 并不等于 problem-solving generation：生成中间图若不能精确服务问题，可能削弱理解。

5.3 Judge reliability

Judge comparison 显示 Gemini 2.5 Pro 与 human experts 更接近：Nano Banana 63.0 / - vs human 59.3 / -；BAGEL 32.7 / 47.7 vs human 31.5 / 44.2；OneCAT 37.5 / 39.0 vs human 36.0 / 38.8；OmniGen2 30.3 / 32.5 vs human 27.7 / 30.3。Qwen2.5-VL 的分数偏离更大，例如 Nano Banana 70.7 / -、BAGEL 35.3 / 59.0，因此论文采用 Gemini 2.5 Pro 作为主要 judge 是有经验验证的。

5.4 Qualitative cases and failure modes

Figure 5 解读：这两个 case 展示 stepwise execution 的正面作用。UEG 中 BAGEL 先理解 prompt 中需要的对象是 lightsaber，再生成相应图像；GEU 中即便中间重构不完美，也能提供足够线索帮助选择正确答案。

Figure 6 解读：这组 oracle case 表明问题不只是“模型没有自动拆解任务”。即使提供 ground-truth intermediate result，BAGEL 仍可能失败，只是性能有所改善；这说明部分 bottleneck 也来自单项理解或生成能力本身不足。

Figure 11 解读：失败模式包括 attribute entanglement、数量错误、attribute fidelity 不足和 spatial relationship confusion。它们共同指向一个问题：模型能生成看似合理的图，但很难在多对象、多属性、多空间约束下精确满足任务条件。

Figure 12 解读：第二组失败覆盖 fingers/text 等细粒度细节、违反物理或常识的场景，以及 object misclassification。对于 RealUnify 这种要求多能力协同的任务，这些基础生成误差会被放大成最终任务失败。

5.5 Overall conclusion and limitations

总体结论是：当前 unified models 已经具备一定理解与生成单项能力，但离真正 synergetic unification 仍很远。UEG stepwise 提升说明模型拥有可用知识却不能端到端整合；GEU stepwise 下降说明生成中间图还不能稳定服务理解；specialist upper bound 又证明任务本身不是不可解，而是现有统一模型缺少把两种能力可靠耦合起来的训练机制。

论文明确暴露的限制包括：生成侧仍常出现属性缠绕、数量错误、细节变形、文本失真、物理/常识违背和类别混淆；开源仓库的评测脚本需要用户自行接入 judge/model API，不能直接复现实验表格；论文也没有提出新的统一模型训练方法，而是提供 benchmark 与诊断证据。因此，RealUnify 更像是“问题定义与压力测试”，不是解决统一模型协同问题的算法方案。

Paper Notes

探索

RealUnify: Do Unified Models Truly Benefit from Unification? A Comprehensive Benchmark

RealUnify: Do Unified Models Truly Benefit from Unification? A Comprehensive Benchmark

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 Overall framework：双向协同评测

3.2 UEG：Understanding Enhances Generation

3.3 GEU：Generation Enhances Understanding

3.4 Data construction and annotation

3.5 Direct evaluation 与 stepwise evaluation

3.6 Released code pseudocode

4. Experimental Setup (实验设置)

4.1 Dataset and scale

4.2 Models and baselines

4.3 Metrics and protocols

4.4 Training / inference configuration

5. Experimental Results (实验结果)

5.1 Main RealUnify results

5.2 Specialist comparison and upper bound

5.3 Judge reliability

5.4 Qualitative cases and failure modes

5.5 Overall conclusion and limitations

目录