[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

楽観的ロック vs 悲観的ロック:実際のトラブルから学ぶ排他制御

楽観的ロック vs 悲観的ロック:実際のトラブルから学ぶ排他制御

こんにちは! Qualitegプロダクト開発部です! 「楽観的ロックを実装したのに、まだ競合エラーが出るんですけど...」 これは私たちが実際に経験したことです。 本記事では、楽観的ロックと悲観的ロックの違いを、実際に発生したトラブルを通じて解説します。 抽象的な説明ではなく、 「なぜそれが必要なのか」「どんな問題を解決できるのか」 を実感できる内容を目指します。 目次 1. 問題の背景:並列処理で謎のエラー 2. ロックなしの世界:なぜ競合が起きるのか 3. 楽観的ロックの導入:期待と現実 4. 楽観的ロックの限界:解決できなかった問題 5. 悲観的ロックによる解決 6. 実装時のハマりポイント 7. どちらを選ぶべきか:判断基準 8. まとめ 1. 問題の背景:並列処理で謎のエラー 1.1 システムの概要 私たちが開発していたのは、 複数のワークスペースを切り替えて使用するAPIサーバー でした。 当社AI関係のプロダクトの一部だったのですが、結合テスト兼負荷テストを実行すると、まれに発生してしまっていました。 ユーザーは複数のワーキン

By Qualiteg プロダクト開発部
企業セキュリティはなぜ複雑になったのか? 〜AD+Proxyの時代から現代のクラウド対応まで〜

企業セキュリティはなぜ複雑になったのか? 〜AD+Proxyの時代から現代のクラウド対応まで〜

こんにちは! ChatGPTやClaudeといった生成AIサービスが業務に浸透し始めた今、 「AIに機密情報を送ってしまうリスク」 が新たなセキュリティ課題として浮上しています。 この課題に向き合う中で、私たちは改めて「企業のセキュリティアーキテクチャはどう変遷してきたのか」を振り返る機会がありました。 すると、ある疑問が浮かんできます。 「なんでこんなに複雑になってるんだっけ?」 企業のセキュリティ担当者なら、一度は思ったことがあるのではないでしょうか。 アルファベット3〜4文字の製品が乱立し、それぞれが微妙に重複した機能を持ち、設定は複雑化し、コストは膨らみ続けています。 当社ではAIセキュリティ関連プロダクトをご提供しておりますが、AI時代のセキュリティを考える上でも、この歴史を理解することは重要ではないかと考えました。 本記事では、企業ネットワークセキュリティの変遷を振り返りながら、「なぜこうなったのか」を整理してみたいと思います。 第1章:観測点を集約できた時代 ― オンプレAD + Proxy(〜2010年代前半) 統制しやすかったモデル かつ

By Qualiteg コンサルティング, Qualiteg AIセキュリティチーム
【IT温故知新】WS-* の栄光と黄昏:エンタープライズITはいかにして「実装」に敗北したか

【IT温故知新】WS-* の栄光と黄昏:エンタープライズITはいかにして「実装」に敗北したか

こんにちは。 —— 2003年のSOAから、2026年のAIへ —— この記事は、過去の技術動向を振り返り、そこから学べる教訓について考察してみたものです。 歴史は常に、後から見れば明らかなことが、当時は見えなかったという教訓を与えてくれます。 そして、今私たちが「正しい」と信じていることもまた、20年後には違う評価を受けているかもしれません。 だからこそ、振り返ることには意味があるとおもいます。同じ轍を踏まないために。 はじめに:20年前の熱狂を覚えていますか 2000年代初頭。 私はSOA(サービス指向アーキテクチャ)に本気で取り組んでいました。 当時、SOAは「次世代のエンタープライズアーキテクチャ」として、業界全体が熱狂していました。 カンファレンスに行けば満員御礼、ベンダーのブースには人だかり、書店にも関連の書籍がちらほらと。 SOAP、SOAP with attachments、JAX-RPC、WS-Security、WS-ReliableMessaging、WS-AtomicTransaction... 仕様書の山と格闘する日々でした。 あれから

By Qualiteg コンサルティング
DockerビルドでPythonをソースからビルドするとGCCがSegmentation faultする話

DockerビルドでPythonをソースからビルドするとGCCがSegmentation faultする話

こんにちは!Qualitegプロダクト開発部です! 本日は Docker環境でPythonをソースからビルドした際に発生した、GCCの内部コンパイラエラー(Segmentation fault) について共有します。 一見すると「リソース不足」や「Docker特有の問題」に見えますが、実際には PGO(Profile Guided Optimization)とLTO(Link Time Optimization)を同時に有効にした場合に、GCC自身がクラッシュするケースでした。 ただ、今回はDockerによって問題が隠れやすいという点もきづいたので、あえてDockerを織り交ぜた構成でのPythonソースビルドとGCCクラッシュについて実際に発生した題材をもとに共有させていただこうとおもいます 同様の構成でビルドしている方の参考になれば幸いです TL;DR * Docker内でPythonを --enable-optimizations --with-lto 付きでソースビルドすると GCCが internal compiler error(Segmentati

By Qualiteg プロダクト開発部