よばれていることがわかります。https://github.com/scikit-learn/scikit-learn/blob/7389dba/sklearn/metrics/ranking.py#L535この引数をみて1つ解決した疑問があります。含まれていませんでした。計算するべきではないかという気もします。省かれていたということがここにきてわかります。してもう一度実行してみます。含まれ、ROCカーブの座標が先ほどより1点増えました。この座標はあってもなくてもROCカーブの下の面積を出す上で影響がない点であったこともわかります。ROCカーブを軽くするためにデフォルトではこのような点は省かれているようです。よばれて、閾値をどんどん下げていったときに検出されるスパムメールと非スパムメールの個数を出しています。いま最低限必要な動作のみ抜き出し、コメントをアレンジしたものです。したがって変化させていったときに検出される非スパムメールとスパムメールの個数です。それぞれ最後のインデックスの値で割って割合(fpr、tpr)に直しています。場合は先に不要な座標の除去が行われます。必要な動作を抜き出すと以下です。面積を求めさせているだけです。ROCカーブの下の面積は台形則で求められている(各座標を直線で結んだ折れ線の下の面積が求められている)ことがわかります。AUCの計算方法はとても簡単でしたね。自分で適当に実装できそうです。何がいいたいのかというと自分は適当にやって失敗したんですか、適当だからといってやるべきではないのは、スコア降順にソートした上でROCカーブの座標を1点ずつ拾っていくことだと思います。これをやるとROCカーブはスコア同値のデータの中でラベル1とラベル0がどう並んでいるかに依存します。曲線」の面積なので、定義に沿っていないかなり粗い下からの評価になってしまうと思います)。小さいAUCになります。これに三角形を補えばいい気もしますが、カーブの座標からはどう三角形を補うべきかの情報が失われています(長方形の短冊を埋めるような三角形を補う、だと誤りです。同じスコアによって描かれた辺だけを三角形で埋める必要があります)。同じ方法でやればいいと思います。0)を判定することを目指すものだと思います。評価されているのは不思議さがあると思います。スパムメールか否かを判定するモデルでは、モデルはメールの色々な特徴からスパムらしさを説明しようとすると思います。判定したデータの中にも「スパムらしい特徴をとても強くもつなあ」「スパムらしい特徴をまあまあもつなあ」という違いはあると思います。丸められる前のモデルのスパムらしさのスコア付けを評価するものです。AUC」をみたいのかというと、「そもそも実は最終判定ではなくスコアがほしい」というケースがあると思います。閾値は後から適当に調整するので、スコアをよこせということです。最終判定のみがほしい場合でも、精度・感度は同程度のモデルが2つ出来上がってきたとして、2つとも検出漏れはないが誤検出はあるとして、スパムと誤判定された非スパムメールに対する内部スコアが「閾値は超えてしまったが少し超えてしまっただけで多くのスパムメールのスコアよりは小さい」というモデルと、「多くのスパムメールのスコアよりも大きくなってしまっている」というモデルだったら後者の方が判断の根拠が心配な気はします。この場合、後者の方がAUCが小さくなります。Uncer...以下の論文を読みます。...以下の論文を読みます。Edi...以下の本を読みます。Series以下の論文を読みます。解釈誤りは筆者に帰属します。注目記事はてなブログをはじめよう!cookie-boxさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。