レコメンドのオフライン評価でRecall@kの方がPrecision@kより用いられる理由

概要

一般にRecallとPrecisionの違いなどは記事がありますが、Recall@kとPrecision@kの違い、そしてレコメンドエンジンを評価する現場ではRecall@kが評価指標としてよく用いられる理由については解説している専門書、記事が英語、日本語とも見当たらなかったので自分なりに考えてみました。

一般的なRecallとPrecisionの定義

Recallの定義は、

$$Recall := \frac{TP} {TP + FN} \\ \quad \\ = \frac {正解だと思って正解だったアイテム数} {正解だと思って正解だったアイテム数 + 不正解だと思ったが実は正解だったアイテム数} \\ \quad \\ = \frac {正解だと思って正解だったアイテム数} {本来正解のアイテム数}$$

一方Precisionの定義は、

$$Precision := \frac {TP} {TP + FP} \\ \quad \\ = \frac {正解だと思って正解だったアイテム数} {正解だと思って正解だったアイテム数 + 正解だと思って実は不正解だったアイテム数} \\ \quad \\ = \frac {正解だと思って正解だったアイテム数} {正解と判定したアイテム数}$$

となります。

PrecisionとRecallのトレードオフ

従って、本来正解のアイテム全て正解と判定するようになんでも正解といえばRecallは1になりますが、Precisionは最小になり、正解と確実にわかったもののみ正解と判断するモデルならばPrecisionは最大、Recallは最小になります。

レコメンドでよく用いられるRecall@kとPrecision@k

Recall@kなどは、Recall@10、Recall@20などとして用います。
Recall@kの定義は、全てのユーザーやアイテムの数をNとして、

$$Recall@k := \frac{1} {N} \sum_{i \in \{1,...,N\}} {\frac{TP_i@k} {TP_i@k + FN_i}} \\ \quad \\ = \frac{1} {N} \sum_{i \in \{1,...,N\}} {\frac {k個オススメしたうち、正解だったアイテム数} {k個オススメしたうち、正解だったアイテム数 + 不正解だと思ったが実は正解だったアイテム数}} \\ \quad \\ = \frac{1} {N} \sum_{i \in \{1,...,N\}} {\frac {k個オススメしたうち、正解だったアイテム数} {実際の正解アイテム数}}$$

Precision@kの定義は、

$$Precision@k := \frac{1} {N} \sum_{i \in \{1,...,N\}} {\frac{TP_i@k} {TP_i@k + FP_i@k}} \\ \quad \\ = \frac{1} {N} \sum_{i \in \{1,...,N\}} {\frac {k個オススメしたうち、正解だったアイテム数} {k個オススメしたうち、正解だったアイテム数 + k個オススメしたうち、実は不正解だったアイテム数}} \\ \quad \\ = \frac{1} {N} \sum_{i \in \{1,...,N\}} {\frac {k個オススメしたうち、正解だったアイテム数} {k}}$$

となります。

Recall@kとPrecision@kのトレードオフは存在するか？

この定義を見ると、分母がkでバウンドされていることに気づきます。いい加減なモデルを作ると、Recall@10、Precision@10などがともに悪くなってしまうことがわかります。

なぜ現場ではRecall@kが使われることが多いのか

定義の違いを考えると、異なる部分は分母のうち、正解データに絞るかどうかという点です。専門書などでも触れられているのをみたことはありませんが、Precision@kだと、取れた正解データ（実際のユーザーの遷移データなどから取ってきます）の量が少ないと小さく見積もられてしまいます。データの量に応じて精度が変わってくるということが起こるわけです。
それに対して、Recall@kではその影響が抑えられています。
なので、レコメンドエンジンのモデルの精度を測る時の指標はRecall@kがよく用いられるということかと思います。