bits/dims ってなんだよって言われて虚無になったので調べてみた


これまでのあらすじ

RealNVP なんかの 画像生成系の論文 を友人と共に 殴り合いながら 読んでいたときに出てきた、評価手法、bits/dims が気になって夜も眠れなくなった。
我々の明日はどっちだ

調べてみたら、良い感じの Reddit が出てきた

[Discussion] Calculation of bits/dims で良い感じに議論されていた。どうやら PixelRNN の論文で触れられているらしい。

PixelRNN の論文へGO

PixelRNNで該当部を探すと、こんな感じの文章が書いてあった。

For MNIST we report the negative log-likelihood in nats as it is common practice in the literature. For CIFAR-10 and ImageNet we report negative log-likelihoods in bits per dimension. The total discrete log-likelihood is normalized by the dimensionality of the images (e.g., 32 × 32 × 3 = 3072 for CIFAR-10).

面倒なので翻訳しよう。

MNIST については一般的な手法であるから底 e の負の対数尤度(自然対数を nats というらしい、落花生ではないようだ) で報告を行いました。CIFAR-10 や ImageNet に関しては、bits/dims を用いた負の対数尤度で報告を行いました。すべての離散対数尤度は、画像の次元数で正規化が行われました。(例えば、CIFAR-10 の場合では、32x32 = 3072)

つまり負の対数尤度の一種として bits/dims ということがあるらしい。画像の次元数で正規化が行われるということは、画像サイズに関わらない評価を行いたい、という意図を感じる。感じる。

実際に例を上げて計算してみる。

ページを戻してRedditの方で上げられている式を読み解いて、この bits/dims がどういう計算をしているのか見てみよう。

状況は以下を想定する。
- 負の対数尤度 L が 5371.78
- 画像の次元数 D が 32 x 32 * 3 = 3072

すると、
$\frac{L / D - log_e 128}{log_e2}$
$= \frac{5371.78/ 3072 - 4.852}{0.693}$
$= 4.477$

この $log_e 128 = log_e (256 = 2^8 / 2)$ というのが大変ひっかかるが、これは連続的な確率密度関数 (特にここでは Gaussian pdf)を離散的な尤度値に変換するための暗黙的な手続きとされているらしい。

どういう値が良いの?

係数がかかっているとはいえ、実質的には負の対数尤度と同じ方向と考えて問題なく、つまり最小化をすることになるので、小さい値 が良いと判断できる。
それ以外に考える点としては、大きい画像を学習データとしたときに、多少負の対数尤度的に悪くても 画像サイズで割っているため そのスコアの悪さを緩和できるということが挙げられるだろう。(このあたりが、画像サイズでの正規化、という意味なんだろうか)

それで、実装的にはどう処理しているの?

RealNVPは上記の方法で解決されている、OpenAI の Glow でもコードを見る限り同様に処理されていると思う。

もっと知りたいときは

Glowの issue でいい感じの質疑応答があった。
また、この bits/dims 周りのもっと詳しい話(恐らく初出)は NICE: NON-LINEAR INDEPENDENT COMPONENTS ESTIMATION
にある。