Stable Diffusion 3 は何が足りないか？

Stable Diffusion 3 mediumを使用してみたがDALLE3と比べてやはり差があった。[前回記事](https://qiita.com/nishiha/items/14ca8b9b2bf9749e4db8)
Stable Diffusion 3 Ultlaは使ったことはないのでStable Diffusion 3の真の性能は知らない。

論文からStable Diffusion 3とDALLE3の差について考えてみたい。
**推測で根拠のない適当なことを述べますがご了承ください。**

まず、**キャプション**について考えてみたい。

# LAION 5B のキャプション
Stable Diffusion 3の学習データがLAION 5Bであるのかどうかは不明だが(StableDiffusion2まではLAION 5Bの記述あり)、LAION 5BのキャプションはチューニングしたBLIPによって与えられている。

https://laion.ai/blog/laion-5b/#blip-inference-tuning

Laion2B-enの平均テキスト長は67であり、平均英単語を4~5長とすれば単語長やトークン長なら13～16程度かと推定される。


# NovelAIのキャプション
StableDiffusion1.5の派生であるNovelAI(NAI)はDanbooruという画像サイトのタグをキャプションとして学習している。
また、low qualityやworst qualityなどのnegative promptが有効なことを踏まえると、多分明言されてないものの質的評価付けラベルも付与していると考えられる。これに従うと絵柄が偏る(マスターピース顔と呼ばれる)が、クオリティが向上する。
質的評価の勝手なタグ付けは倫理的には良くないが(実際、他人の書いた絵に"低クオリティ"とラベル追加する事は何様だと思う)、良い絵を出力させるには必要だろう。

Stable Diffusion 3 はこのような質的評価の勝手なタグ付けはしているのか不明である。
(もししてなければnegative promptはあまり機能しないだろう)

またこのような画像に自動タグ付けするモデルとしてDeepDanbooruやWD14Taggerが知られている。

# Stable Diffusion 3のキャプション
下記論文中に**IMPROVED CAPTIONS（キャプションの改善）** の項目があり、論文によればStable Diffusion 3はCogVLMのキャプションとオリジナルのキャプションを50%で混ぜたもので学習している。なぜ混ぜているかと言うと、このVLMに例えば"doraemon"の知識がない場合、オリジナルキャプションにある"doraemon"というキャラクター名の情報がCogVLMの生成キャプションからは欠落するからである。

一方で、VLMによる生成キャプションとオリジナルのキャプションの長さについて詳細の情報は何もない。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299928/0ffc81a1-61e2-18f5-76dc-35ad9bb4ecdd.png)


https://arxiv.org/pdf/2403.03206


# DALLE-3のキャプション
論文によればimage captionerを新規に作ってfine-tuningしているが、このcaptionerの詳細はよく分からない。ChatGPTでキャプションを与えるGPT-4Vとはまた別物なのか。

以下は学習モデルのCLIPスコアである。
左の図は元のキャプションで生成したCLIPスコアであり、右図は詳細な生成キャプションで生成したCLIPスコアである。また、青赤黄の各線は学習した3モデルであり、それぞれ黄色が元のキャプション、赤が簡潔なキャプション、青が詳細なキャプションで学習している。

推論時が元のキャプションの場合、学習時のキャプションはあまり目立った改善効果はないがそれでも僅かに良い。
推論時が詳細な生成キャプションの場合、学習時の生成キャプションの違いは大きな改善効果がある。

要するに学習時に詳細な生成キャプションを用いる方がモデルの性能が高い。ただし、推論時のキャプションが短いと効果は薄い。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299928/921375b9-3fae-c8bd-2925-f9f51af45cf9.png)


https://cdn.openai.com/papers/dall-e-3.pdf


# VLMについて
Vison Language Modelの略である。またはLarge Vision-Language Models (LVLMs) ともいう。
構成は大体似たりよったりもので、ImageEncoderとLLMの間のMLP(またはQ-Former)のみを学習した後、LLM(Text Decoder)をfinetuningする。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299928/8887fd1b-0cc0-11f1-09e9-1e312adc4579.png)

https://huggingface.co/blog/vlms

## LLaVA(23年04月)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299928/cba2e192-5958-67a0-e4e2-e1a91428e175.png)

https://arxiv.org/pdf/2304.08485

## LLaVA-1.5(23年10月)
一層のprojectionから二層のMLPになっている。その他、いろいろな改良がある。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299928/486f47ba-b90a-2e17-9aa6-164b88562cdd.png)

https://arxiv.org/pdf/2310.03744

## CogVLM(23年11月)
MLPを学習させるほか、LLMに何か足してLLMの一部だけ学習している。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299928/eccd07b2-b34f-815b-5bd0-582da460b19b.png)

https://arxiv.org/pdf/2311.03079

## GPT-4V(23年11月)
https://openai.com/index/chatgpt-can-now-see-hear-and-speak/

## MoE-LLaVA(24年01月)
MoE-LLaVAはLLMのEmbeddingレイヤーを学習するのとMoE学習である。
全く読んでないが図を見る限り、Vision tokenとText tokenで適用する重みを場合分けするのならCogVLMと近く見える。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299928/6815d925-ee70-af1d-9f48-715b2417a997.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299928/3d64a8a6-19be-ac20-d678-5fdb563c8ae9.png)


https://arxiv.org/pdf/2401.15947v3

## CogVLM2-LLaMA3(24年05月)
LLMにllama3を使ったVLMがいくつか出ており、これらはGPT4Vに相当するスコアを出している。

https://github.com/THUDM/CogVLM2

## LLaVA-NeXT(24年01,05月)
https://llava-vl.github.io/blog/2024-01-30-llava-next/

https://llava-vl.github.io/blog/2024-05-10-llava-next-stronger-llms/


## MiniCPM-Llama3-V 2.5(24年05月)
https://github.com/OpenBMB/MiniCPM-V

MiniCPM-Llama3-V 2.5の性能比較にCogVLM(水色)とGPT-4Vの231106ver(濃橙色)の比較があり、同時期ではあるが性能はGPT-4Vの方が高い。
MiniCPM-Llama3-V 2.5はわずか8BのパラメータでGPT-4V-1106とほぼ同等の性能を得ている。GPT-4o、 GPT-4V-0409(GPT4turbo)比はどうなのか不明。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299928/d00c34a7-5db8-c481-963e-c92e135969c0.png)

## Japanese Stable VLM(23年11月)
StableDiffusion3を作ったStability AI自体もVLMモデルを開発している。(日本語用だが)

https://ja.stability.ai/blog/japanese-stable-vlm

# ここから妄想
## 生成キャプション
前述したように生成キャプションを利用するというのは随分と昔から行われている。
LAION 5BはBLIPで、StableDiffusion3はCogVLM、DALLE-3はGPT4Vかそれに類する生成キャプションを使用していると思われる。

一方でこのような画像にキャプションを与えるタスクや、画像に対する質問に答えるタスクは23年、24年で大幅に進歩している。

https://paperswithcode.com/sota/visual-question-answering-on-mm-vet

https://paperswithcode.com/sota/visual-question-answering-on-docvqa-test

https://paperswithcode.com/sota/visual-instruction-following-on-llava-bench


この場合、毎回生成キャプションを与えるというのはText Encoderの上段にImgae入力とVLMを繋げるのに等しい。
この構成は元画像を変換するという意味ではControlNetに一部近いようにも思える。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299928/8d9c1253-b2fc-a957-78d8-58344f64e3c8.png)

## 短いキャプションの学習限界
このように学習時には長い生成キャプションを用いた方が学習が進む。これは逆説的にいえばSD3にfine-tuningする際、従来の短い生成キャプションでは情報が欠落しており生成画像の多様性を確保できず、lossが思うように下がらないのではと思った。この過程に従えばSD3を再学習する際にも長い生成キャプションを利用しないとSD3の真の性能が発揮できず学習の進まないアンダーフィット(オーバーフィットの逆)が起こるかもしれない。
またDALL-E3の論文中で学習途中で生成キャプションのブレンド比率を65%に変えた場合の結果が大きく劣っているという記述が再学習の学習キャプションが短い場合のアンダーフィットなのではないかと推察する。

また、キャプションが文章の文脈を重視する場合、shuffle_captionによって変な文章が作成されるかもしれない。
生成キャプションの分布群が異なる場合、この生成キャプションの差異(CogVLMとWD14Tagger)に惑わされ、学習画像の分布群の違いを上手く学習出来ないかもしれない。

## VLMとobject detection(物体検出)
VLMの回答にオブジェクトの位置情報を回答させる問題がある場合、VLMのCLIP Image Encoderと同時に物体検出モデル(YOLOとか)を併用した方がオブジェクトの位置は回答しやすいかもしれない。

https://arxiv.org/pdf/2311.03356

## CLIP Text Encoderの代わりにVLMを使えないのか？
CLIPとVLMはImageとtextの関連を学習するという意味では近い。
自分がCLIPに対する疑念はCLIP Image Encoderの性能とCLIP Text Encoderの性能は両立しないのではという事である。

例えばライオンの画像を入れた場合、Image Encoderが賢くないなら、画像は「黄色いネコ科のたてがみのある四足歩行の動物」という風に特徴を抽出し、Text Encoderもライオンとは「黄色いネコ科のたてがみのある四足歩行の動物」という風に画像的要素に分解できる。一方でImage Encoderが十分に賢すぎるならライオンの画像に対してImage Encoderだけでこれが「ライオン」であると理解する。一方、Text Encoderはテキストのライオンとはつまり「ライオン」であるとトートロジーを返すだけである。

画像生成モデルは通常拡散モデルのCrossAttenttionの入力にCLIPのText Encoderのテキストから潜在変数への変換出力を使うが、VLMのLLMの中間層のinput textのtokenに相当する部分の出力を抜き出したものを使えないであろうか。VLMの方が最初は多くの重みを凍結して学習する分、Text Encoder(LLM)の破滅的忘却が起きにくいのではないだろうか。

## unCLIPとVLMの関係
画像をガウス分布の潜在変数に変換するのに現状はVAE encoderが使われる。おそらくガウス分布にしたい理由は拡散モデルでガウス分布のノイズへの拡散過程がガウス分布同士の場合簡単(最悪ノイズの足し算でもいい)だからだろう。

DALLE-2ではガウス分布の変換にVAE encoder、VAE decoderの代わりにCLIP Image Encoder、CLIP Image decoder(unCLIP)が代わりに使われている。これとVLMの類似性を示したい。

まず、VLMは入力が画像で、出力がテキストである。CLIP Image EncoderとLLMの重みを凍結して使い、間のMLPモデルを先に学習する。その後、LLMをファインチューニングする。
一方、unCLIPは入力がテキストであり、出力が画像である。text encoderとimage decoderの間にpriorがある。
こう考えるとunCLIPはVLMのテキストと画像が逆のモデルと考える事が出来るのではないかと思った。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299928/305df66e-d2ba-1aaa-7ea0-374cc9031225.png)

## Patch分割の逆変換
ほぼ妄想だが、VLMがMLPの学習だけで画像のパッチ分割の画像断片から言語tokenへの変換が学べるなら、言語tokenから画像断片への変換を学習出来ないだろうか？
ViTにおけるpatch分割の逆変換の関数を作ってCLIP Image decoder(unCLIP)をVAE Decoderの重みを元に学習できないだろうか？

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299928/ccba5993-cdbe-9e92-ad77-ee4299c4be59.png)

Partiは離散トークンにベクトル量子化(VQ)に変換してこれから画像に変換するdetokenizerによって画像に変換しているが、「画像(0~255x3ch)からガウス分布」、「ガウス分布から画像(0~255x3ch)」の変換モデルが明らかであれば(VAE等)中間にベクトル量子化を挟む必要は必ずしもないように思う。
このPartiの場合は「画像(0~255x3ch)から離散index(image tokenizer)」、「離散indexからガウス分布(embed)」、「ガウス分布からガウス分布(transformer)」、「ガウス分布から離散index(sigmoid,softmax)」、「離散indexから画像(0~255x3ch)(image detokenizer)」と経る。
無論Embeddingレイヤーは離散indexを容易かつ確実にガウス分布に変換するのが可能であり、Attentionにおいてランダムなガウス分布同士の内積の期待値はゼロであり、同じガウス分布の内積は1である。transformer中は「ガウス分布からガウス分布」の変換を維持できる。
ここでVison tokenを画像断片に変換してpatch分割の逆変換を経て並び替えているという意味では上述の妄想とPartiは似ているのではないだろうか。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/299928/2c587be0-2b94-9045-31ab-1a25a85195ec.png)



https://arxiv.org/pdf/2206.10789




# まとめ
Stable Diffusion 3もDALLE-3も論文内にCaptionの改善の記述があり、これらは重要なのかもしれない。これらはVLMによるキャプションであろう。
一方でこのVLMは発展が目まぐるしくこの半年くらいでもいろいろ進展がある。Stable Diffusion 3はCogVLMのキャプションを使用しているがこれは今となっては改善の余地があるのではと思った。

ファインチューニングする際、学習時の生成キャプションの長さが足りない事で学習が進まなかったりするのでは？とSD3のファインチューニングが上手く行かないニュースを見て思った。

https://ascii.jp/elem/000/004/209/4209874/