ベイズ統計について

ベイズの定理

ベイズの定理では以下の式が成立します。

 \mathrm{P(B_{i} | A{i})} = \dfrac{\mathrm{P(A_{i} | B_{i})} \mathrm{P(B_{i})}}{\mathrm{P(A_{i})}}

 \mathrm{P(B_{i})}では、「Bという状態である確率」「データの発生源」に該当する事前確率です。
 \mathrm{P(A_{i})}では、「結果的にAという事象が発生する確率」「観測」に該当するとします。

ベイズの定理の左辺を見ていただくと・・・
 \mathrm{P(B_{i} | A_{i})}を意味するのは、「Aという観測・事象が発生している中でBの状態であった確率」を指します。
ベイズの定理が非常に応用される要因としてあげられるのは、「観測に対して、その原因である確率」を算出できます。
ゆえに時間の逆行、原因論です。

推定

推定って何すんの?

上記のベイズの定理の考えを応用して・・・
 \mathrm{f(μ, σ | x)} = \dfrac{
\mathrm{f(x| μ, σ)}
\mathrm{f(μ, σ)}
}{\mathrm{f(x)}}

ここでの(μ, σ)は確率分布を決定するときの平均, 標準偏差のパラメータです。
xは与えられた観測データとします。

確率分布のパラメータ(μ, σ)が決定された中で、 \mathrm{f(x| μ, σ)}を求める機会が多かったのではないでしょうか。
ちなみに \mathrm{f(x| μ, σ)}を尤度関数と呼びます。
しかしベイズ推定では順序を逆にさせ、 \mathrm{f(μ, σ | x)}が最大となるパラメータ(μ, σ)を探します。

 \dfrac{
\mathrm{f(x| μ, σ)}
\mathrm{f(μ, σ)}
}{\mathrm{f(x)}} \propto 
\mathrm{f(x| μ, σ)}
\mathrm{f(μ, σ)}

ベイズ推定ではθに依存しない分母\mathrm{f(x)}を除いて、上記の式に変換してやります。

どんな確率分布かは不明だが、観測データXは何らかの確率分布を介して生成してるので、
その分布のパラメータを求めに行こうというのがベイズ推定や最尤推定です。

最尤推定 vs ベイズ推定

最尤推定の弱点

最尤推定ではパラメータを以下のように決定します。
事前確率θ=(μ, σ)のパラメータ、観測データをXとします。

全ての観測データXのうちに i 回、勝利する確率を知りたいとします。
最尤推定ではi 回勝利するような確率分布のパラメータを知りたいわけです。

 argmax_{θ}(\mathrm{f(X | θ)})

これを求めたいのです。

微分計算などをとりあえず省きます。(書くのがだるい)

 θ =  \dfrac{i}{N}

こうなります。
これではサンプル数Nに依存してしまい、サンプル数少ないときどうすんねん!となります。
そうです!最尤推定はサンプル数に依存してしまう傾向にあり、サンプル数が少ない際に信頼性が欠点と言わざる得ません。

ベイズ推定の強み

ここでベイズ推定の登場です。
ベイズ推定では左辺の事後確率 \mathrm{P(B_{i} | A{i})}を最大にします。

 \mathrm{P(B_{i} | A{i})} = \dfrac{\mathrm{P(A_{i} | B_{i})} \mathrm{P(B_{i})}}{\mathrm{P(A_{i})}}

ブログが続かなくなってきたので、Note・Zenn・Twitterに移行しました

Note・Twitterに移行しました

なぜか?

個人ブログだと「人に見られている」意識が低く、「誰かの為になるような記事」と「自分の為になる記事」を両立したくなったことです。
自分の箱庭でもあるこちらのブログでは、見られている意識が小さく、投稿後に編集したり、他人から見て読みにくい文章を書いてしまったりと、
配慮に欠ける行動に移してしまっていることが原因です。

後ブログが続かないと学習意欲も薄まっていき、「このままではダメだ!」と思い決意。
家族内でCOVID19の陽性者が発生して、自宅隔離となったので、これを機に。

Note

こちらでは個人的に思う事・心理状態・趣味について話します。

どちらかというと、誰かに共感してもらえたら良いな程度の比較的自由な記事を書きます。
自分の中での日記代わりです。

note.com

Twitter

こちらではIT関連のトレンド・AI論文・時事・都市開発について呟きます。

ITエンジニアになりたいので、自分が興味を持っている都市×ITのニュースなどを拾っていきます。
#ネオユニメモ のタグで自分が収集したニュースに関するまとめを呟いています。

twitter.com

twitter.com

コンセプト・趣味・需要のバランスが取れたコンテンツを模索したいです。

Zenn

技術系記事を投稿します。
記事の中にも、「問題」→「解決」がはっきりとしたフォーマットで記事投稿できるように頑張ります。

zenn.dev

モダンなWeb界隈調査【ヘッドレスCMS】

あらすじ

前回このような記事を書きました。やっぱり色々と勉強していましたが、モダンな情報を調べて自分の知識の穴を縫っていく方が明らかに効率が良いことを痛感しています。その為にはネットの海を彷徨う事の重要性が身に染みます。
melheaven.hatenadiary.jp

ヘッドレスCMSとは

何じゃそれ・・・。CMSはWebサイトを構成するコンテンツ(文章や画像、動画)を一元で管理するシステムです。さらに具体的に説明すると、CMSはフロントエンド機能である『コンテンツを表示するView』とバックエンド機能である『API経由でコンテンツを取得する機能』により成立しています。CMSではWordpressが有名ですね。

ヘッド=Viewを指しており、ヘッドレスCMS = 後者の『API経由でコンテンツを取得する機能』のみのCMSであるという事です。

blog.microcms.io

ヘッドレスCMSで何ができるか?

ブログの場合だと、サービス上の入力フォームから記事コンテンツを登録して、登録データをAPIとして公開してくれます。
サイトにアクセスがあった場合に、サイトからヘッドレスCMSに登録されたコンテンツをAPIで呼び出すシステムとなります。
www.maxmouse.co.jp

通常CMSの問題点

CMSの何がいけなかったのでしょうか?ヘッドレスCMSでなくてはならなかった理由は何なのか?

CMSでの欠点は以下の通りです。

  1. フロントエンド+バックエンドを同一的にCMSが管理している為、片方のシステムを変更したい時、もう片方に影響が出る
  2. フロントエンド(デザインなど)の自由度が低め
  3. 動的ファイル+コンテンツデータのやり取りから、HTMLの生成を行う為、表示速度が遅い
  4. 上記に加えてセキュリティリスクが高い

ヘッドレスCMSの強み

上記の通常CMSの問題点がヘッドレスCMSに繋がってきます。

1と2に関しては、フロントエンドとバックエンドの機能を独立化できる為、一方のコード変更が他方に及ぼす影響は薄いことが強みです。つまりバックエンドの事を考えずに、フロントエンド設計をできます。時代に沿うようなモダンなフロントエンドを考えている場合や経験豊富なフロントエンドエンジニアがいる場合はこちらのメリットが光りますね。

3に関しては、以前のSSGやJamSTackと組み合わせることでさらに利点が光ります。ヘッドレスCMS+静的サイトジェネレータで既にコンテンツが表示されたHTMLを配信しているのみで表示速度が向上します。

4に関しては、配信ファイルがHTML/CSS/JavaScriptのみで構成されたファイルなので、システムの堅牢性向上に繋がります。

ただ学習コストが通常CMSと比較して高めなので、時間が迫られていて技術にに自信がない場合は選択する必要はなさそうです。

有名どころだとmicroCMSやContentfulなどがあります。

あるサーバーのコンテンツ管理用のヘッドレスCMSでコンテンツを呼び出し、静的サイトジェネレータで静的ファイルに出力します。
これで静的ファイルを閲覧者の元へ配信すれば良いだけなのです。

digitoo.trans-cosmos.co.jp