[AI数理]徹底的に交差エントロピー(3)

[AI数理]徹底的に交差エントロピー(3)

おはようございます!(株) Qualiteg 研究部です。

今回は、尤度関数から交差エントロピーを導いていきたいとおもいます!

4章 尤度関数から交差エントロピーを導く

さて、今までは 20回ぶんサイコロを投げて、起こった事象(出た目が1なのか、2なのか、・・・、6なのか) を数えた結果を以下の表のようにまとめました。

では、こんどは、1回ぶんサイコロを投げたときどうのようになるかみてみます。

1回サイコロをなげた結果が 1の目 だった場合は、以下のように書くことができます。
(でた目のところに✔マークをいれただけです)

さて、?だと計算にもっていきづらいので、出た目のところを \(1\) にして、出なかった目は \(0\) と置き換えることにします。

( \(1\) が記載されている目は その目にとっては 頻度 = 確率 = \(1\) と考え、 \(0\) が記載されている目は、その試行では出なかったので、 頻度 = 確率 = \(0\) と考えると理解しやすいかもしれません。)

すると、結果 列は以下のように \(1\) と \(0\) であらわすことができます。

さらに、さきほどまでの表にも書いていたように 結果 列を、ふたたび、 事象が起こる頻度 として \(t\) で表現すると、以下のようになります。

これを再度、対数尤度関数の式で表記すると

$$
\log L=\sum_{k=1}^{6} t_{k} \log y_{k} \tag{4.1}
$$

はい、この 式 \((4.1)\) これは 式 \((3.6)\) とまったく同じです。ただし、裏にある設定は、 1回だけの試行についての対数尤度関数(※) のように解釈できる点が 式 \((3.6)\) と異なる点です。

1回だけの試行についての対数尤度関数 というと、かえってやっかいですが、よくかんがえてみると、尤度というのはそもそも複数の確率の積になっているため、1回の試行についてのだけに着目したときの対数尤度関数は 尤度 というよりも 指数つきで表現された確率に対数をとっただけのもので実質、ただの 確率 です。では、なぜこのようなまどろっこしい解釈をわざわざするかというと、後半にでてくる 交差エントロピー の式への呼び水とするためです。

では、「1の目が出る」という事象が起こった 1回だけの試行について、 式 \((3.7)\) を実際に計算してみましょう。

$$
\begin{aligned}
\log L= &t_{1} \log y_{1} + t_{2} \log y_{2} + t_{3} \log y_{3} + t_{4} \log y_{4} + t_{5} \log y_{5} + t_{6} \log y_{6} &
\
= &1 \cdot \log y_{1} + 0 \cdot \log y_{2} + 0 \cdot \log y_{3} + 0 \cdot \log y_{4} + 0 \cdot \log y_{5} + 0 \cdot \log y_{6}
\end{aligned}
$$

頻度 \(t\) は 1つだけ \(1\) で、あとは \(0\) になるので、このようにシンプルな計算となりますね。

今回はサイコロだったので 6個の事象 が対象でしたが、これを \(K\) 個の事象というふうに一般化すると

$$
\log L=\sum_{k=1}^{K} t_{k} \log y_{k} \tag{4.2}
$$

のように書くことができます。

この式 \((4.2)\) は 1件あたりの対数尤度関数、もうすこし統計学的な言い方をすれば 1つの標本データ あたりの 対数尤度関数 となります。

対数尤度関数は大きくなるほど、確からしいパラメータ \(y_{k}\) を持つことになりますが、 Deep Learning 等の機械学習では損失関数が 小さくなるように 学習させていきますので、式 \((4.2)\) にマイナスをつけた式 \((4.3)\) のことを 交差エントロピー関数 と呼びます。

交差エントロピー関数(標本データ1件ぶんバージョン)

$$
\ - \log L=\sum_{k=1}^{K} t_{k} \log y_{k} \tag{4.3}
$$

これで交差エントロピー関数を導くことができました。

めでたしめでたし👏

え? ちがう?

伏線の回収忘れ?

「サイコロの各目の確率 \(y\) の話はどうなった?」

「対数尤度関数の導関数が \(0\) になる点をみつけて、サイコロの各目がでる確率求めないの?]

「対数尤度関数の微分して \(0\) になった点は極大または極小であって、最大ではないでしょう?」

「いやいや、待て、尤度関数に対数つけたのは、微分しやすくなるからでしょう。対数尤度関数は微分しないわけ?」

はい、おっしゃるとおりですね、この点については、「補足」にて別途説明いたします。

といいますのも、サイコロの各目がでる確率は最尤推定の手法にて求められますが、本シリーズは「交差エントロピー関数」を導き出す部分が主眼なので、「交差エントロピー」がうっすら見えてきた今、サイコロの目の確率推定トピックは少しあとまわしにさせていただき、もうすこし交差エントロピーを掘り下げてみたいとおもいますので、おつきあいくださいませ!

それでは、また次回お会いしましょう!


参考文献
https://blog.qualiteg.com/books/


navigation

Read more

LLM推論基盤プロビジョニング講座 第3回 使用モデルの推論時消費メモリ見積もり

LLM推論基盤プロビジョニング講座 第3回 使用モデルの推論時消費メモリ見積もり

こんにちは!前回はLLMサービスへのリクエスト数見積もりについて解説しました。今回は7ステッププロセスの3番目、「使用モデルの推論時消費メモリ見積もり」について詳しく掘り下げていきます。 GPUメモリがリクエスト処理能力を決定する LLMサービス構築において、GPUが同時に処理できるリクエスト数はGPUメモリの消費量によって制約されます。 つまり、利用可能なGPUメモリがどれだけあるかによって、同時に何件のリクエストを処理できるかがほぼ決まります。 では、その具体例として、Llama3 8B(80億パラメータ)モデルをNVIDIA RTX A5000(24GB)にロードするケースを考えてみましょう。 このGPUには24GBのGPUメモリがありますが、すべてをリクエスト処理に使えるわけではありません。最初にモデル自体が一定量のメモリを消費し、残りの領域で実際のリクエスト処理を行います。 GPUメモリ消費の二大要素 GPUの消費メモリ量は主に以下の2つの要素によって決まります 1. モデルのフットプリント LLMをGPUに読み込んだときに最初に消費されるメモリ

By Qualiteg コンサルティング
システムとcondaのC++標準ライブラリ(libstdc++)のバージョン違い問題による事象と対処法解説

システムとcondaのC++標準ライブラリ(libstdc++)のバージョン違い問題による事象と対処法解説

こんにちは! 先日、dlibをつかったPythonアプリケーション(conda環境で動作する)作っていたところ、以下のようなエラーに遭遇しました。 ImportError: /home/mlu/anaconda3/envs/example_env/bin/../lib/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /home/mlu/anaconda3/envs/example_env/lib/python3.10/site-packages/_dlib_pybind11.cpython-310-x86_64-linux-gnu.so) 「dlib_pybind11モジュールがGLIBCXX_3.4.32を要求してるけど、みつからない!」という感じのエラーですね。

By Qualiteg プロダクト開発部
LLM推論基盤プロビジョニング講座 第2回 LLMサービスのリクエスト数を見積もる

LLM推論基盤プロビジョニング講座 第2回 LLMサービスのリクエスト数を見積もる

こんにちは! 今回はLLM推論基盤プロビジョニング講座 第2回です! STEP2 LLMサービスへのリクエスト数見積もり それでは、早速、LLM推論基盤プロビジョニングの第2ステップである「リクエスト数見積もり」の重要性と方法を解説いたします。 LLMサービスを構築する際に必要となるGPUノード数を適切に見積もるためには、まずサービスに対して想定されるリクエスト数を正確に予測する必要があります。 リクエスト数見積もりの基本的な考え方 LLMサービスへの想定リクエスト数から必要なGPUノード数を算出するプロセスは、サービス設計において非常に重要です。過小評価すればサービス品質が低下し、過大評価すれば無駄なコストが発生します。このバランスを適切に取るための基礎となるのがリクエスト数の見積もりです。 想定リクエスト数の諸元 リクエスト数を見積もるための5つの重要な要素(諸元)をみてみましょう。 1. DAU(Daily Active Users): 1日あたりの実際にサービスを利用するユーザー数です。これはサービスの規模を示す最も基本的な指標となります。 2. 1日

By Qualiteg コンサルティング
Zoom会議で肩が踊る?自動フレーミング映像安定化とAIによる性能向上の可能性

Zoom会議で肩が踊る?自動フレーミング映像安定化とAIによる性能向上の可能性

こんにちは! 本日は、自動フレーミング映像の安定化に関するアルゴリズム・ノウハウを解説いたします 第1章 問題の背景と目的 バストアップ映像を撮影する際、特にオンラインミーティングやYouTubeなどのトーク映像では、人物がうなずく、首を振るなどの自然な動作をした際に「首まわりや肩がフレーム内で上下に移動してしまう」という現象がしばしば起こります。これは、多くの場合カメラや撮影ソフトウェアが人物の「目や顔を画面中央に保とう」とする自動フレーミング機能の働きに起因します。 撮影対象の人物が頭を下げた際に、映像のフレーム全体が相対的に上方向へシフトし、その結果、本来動いていないはずの肩の部分が映像内で持ち上がっているように見えてしまう現象です。 本稿では、この問題を撮影後の後処理(ポストプロセッシング)のみを用いて、高速、高い精度かつロバストに解決する手法をご紹介します。 前半では、従来のCV(コンピュータービジョン)の手法を使い高速に処理する方法をご紹介します。後半では、AIを使用してより安定性の高い性能を実現する方法について考察します。 第2章 古典手法による肩の上下

By Qualiteg 研究部