Evaluation Overlap evaluation-overlap evaluation-overlap

  # Evaluation Overlap

Evaluation Overlap は、
複数の評価項目が同じ局面要素を重複して数えてしまう問題を指す。
評価関数を大きくするほど起こりやすく、調整を難しくする原因になる。

## 概要

たとえば、

- [King Safety](/shogi/shogiwiki/search/king-safety/)
- [Mobility](/shogi/shogiwiki/search/mobility/)
- [Piece-Square Tables](/shogi/shogiwiki/search/piece-square-tables/)

のすべてが「飛車が王の近くに利いている」ことを別々に加点すると、
本来より大きな値になってしまう。

これが evaluation overlap である。

## なぜ問題か

overlap が大きいと、

- パラメータ調整が不安定になる
- どの特徴が効いているか分かりにくい
- 一部局面だけ極端な評価になりやすい

という問題が起こる。

そのため評価関数設計では、
「この特徴は別の項目で既に数えていないか」を意識する必要がある。

## 実装上の工夫

対策としては、

- 項目の責務を明確に分ける
- 相関の高い特徴を統合する
- 学習で重みを調整する
- phase ごとに重みを変える

などがある。

```cpp
score += kingSafety(pos);
score += mobility(pos);

// 近すぎる概念を別で足しすぎない
// score += rookPressureNearKing(pos);
```

## 将棋AIでの位置づけ

将棋は、

- 囲い
- 持ち駒
- 成り
- 攻め駒の集中

など局面要素が多いので、
評価項目を増やすと overlap が起こりやすい。

特に
[パターン認識](/shogi/shogiwiki/search/pattern-recognition/) と
[NNUE](/shogi/shogiwiki/search/nnue/) 以前の手作り評価では、
設計者が overlap を意識して整理することが重要だった。

## 注意点

- overlap は「同じ特徴を二重に数える」だけでなく、強く相関する項目でも起こる
- 学習評価でも feature design 次第では残る
- 完全に無くすより、管理可能な範囲に抑えることが現実的である

## 関連項目

- [評価関数](/shogi/shogiwiki/search/evaluation-function/)
- [Material](/shogi/shogiwiki/search/material/)
- [King Safety](/shogi/shogiwiki/search/king-safety/)
- [Mobility](/shogi/shogiwiki/search/mobility/)

## 参考にしたホームページ

- [Chessprogramming Wiki: Evaluation Overlap](https://www.chessprogramming.org/Evaluation_Overlap)
- [Chessprogramming Wiki: Evaluation](https://www.chessprogramming.org/Evaluation)
- [Chessprogramming Wiki: Evaluation Function Draft](https://www.chessprogramming.org/Evaluation_Function_Draft)