Source of 評価関数 - Computer Shogi Wiki

  # 評価関数

評価関数は、ある局面がどれくらい良いか悪いかを数値で表す仕組みである。
[探索](/shogi/shogiwiki/search/)は先読みの枠組みを提供し、評価関数は葉局面の良し悪しを与える。
この2つが合わさって、将棋AIは手を選ぶ。

## 概要

[ミニマックス法](/shogi/shogiwiki/search/minimax/)や[negamax](/shogi/shogiwiki/search/negamax/)では、
探索の途中で深さ制限に達した局面に値を与える必要がある。
その役割を担うのが評価関数である。

評価関数は通常、

- 手番側にとって良い局面なら正
- 悪い局面なら負

となるように設計される。

## 古典的な評価要素

古典的な手作り評価では、次のような特徴量を足し合わせることが多い。

- 駒得
- 駒の位置
- 玉の安全度
- 駒の働き
- 歩や持ち駒の形
- 攻めと受けのバランス

チェスでは Shannon の線形評価式が出発点として有名であり、
将棋でも同様に複数の特徴量を重み付き和で足し合わせる設計が広く用いられてきた。

## 実装例

単純化した例では、駒得と簡単な位置評価だけで書ける。

```cpp
int evaluate(const Position& pos) {
    int score = 0;

    score += materialScore(pos);
    score += pieceSquareScore(pos);
    score += kingSafetyScore(pos);
    score += mobilityScore(pos);

    return pos.sideToMove() == BLACK ? -score : score;
}
```

## 手作り評価と学習評価

評価関数には大きく分けて、

- 人手で特徴量と重みを設計する方式
- 学習で重みや表現を獲得する方式

がある。

将棋では、

- Bonanza 系の特徴量学習
- KPPT 系
- [NNUE](/shogi/shogiwiki/search/nnue/)

といった発展が大きな流れである。

## 将棋実装で重要な話題

### 三駒関係

- 詳細: [三駒関係](/shogi/shogiwiki/search/three-piece-relationship/)
- 玉と2駒の関係を特徴量として持たせる発想。
- KPPT 系や Bonanza 系の評価関数を読む入口になる。

### BonaPiece

- 詳細: [BonaPiece](/shogi/shogiwiki/search/bonapiece/)
- Bonanza 系で使われる駒番号体系。
- 特徴量配列の添字と差分更新の基盤になる。

### elmo式学習

- 詳細: [elmo式学習](/shogi/shogiwiki/search/elmo-style-learning/)
- 評価値だけでなく勝敗情報も教師へ混ぜる方向の学習法として語られる。
- WCSC27 以後の実戦的な学習評価の流れを理解しやすい。

### nnue-pytorch

- 詳細: [nnue-pytorch](/shogi/shogiwiki/search/nnue-pytorch/)
- NNUE 学習器の代表的公開実装。
- 将棋向け NNUE 学習環境を設計する際の参照先として便利である。

### 知識蒸留

- 詳細: [知識蒸留](/shogi/shogiwiki/search/knowledge-distillation/)
- 強い教師モデルの知識を軽いモデルへ移す学習法。
- NNUE や policy/value 系の軽量化とも相性が良い。

## 探索との関係

評価関数だけが強くても、探索が浅いと tactical miss が起こる。
逆に探索だけ深くても、評価関数が弱いと局面判断を誤る。

そのため、将棋AIでは

- [探索](/shogi/shogiwiki/search/)
- [静止探索](/shogi/shogiwiki/search/quiescence-search/)
- 評価関数

をセットで調整する必要がある。

## NNUE との関係

近年の将棋AIでは、CPU 上で高速に使える学習評価関数として
[NNUE](/shogi/shogiwiki/search/nnue/)が広く使われている。
そのため現在の評価関数記事では、手作り評価の総論と NNUE への橋渡しの両方が重要である。

## 注意点

- 特徴量同士に重複があると調整しにくくなる
- 探索と評価の役割分担が曖昧だと保守しにくい
- 手番基準の符号規約を崩すと探索コードと噛み合わなくなる

## 関連項目

- [探索](/shogi/shogiwiki/search/)
- [ミニマックス法](/shogi/shogiwiki/search/minimax/)
- [negamax](/shogi/shogiwiki/search/negamax/)
- [静止探索](/shogi/shogiwiki/search/quiescence-search/)
- [NNUE](/shogi/shogiwiki/search/nnue/)
- [Piece-Square Tables](/shogi/shogiwiki/search/piece-square-tables/)
- [三駒関係](/shogi/shogiwiki/search/three-piece-relationship/)
- [BonaPiece](/shogi/shogiwiki/search/bonapiece/)

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

- Chessprogramming Wiki: Evaluation
  https://www.chessprogramming.org/Evaluation
- Chessprogramming Wiki: Evaluation Function
  https://www.chessprogramming.org/Evaluation_Function
- Chessprogramming Wiki: Neural Networks
  https://www.chessprogramming.org/Neural_Networks
- やねうら王公式サイト: 〖連載〗評価関数を作ってみよう！
  https://yaneuraou.yaneu.com/2020/11/17/make-evaluate-function/
- Artificial Intelligence as Structural Estimation: Economic Interpretations of Deep Blue, Bonanza, and AlphaGo
  https://arxiv.org/abs/1710.10967
評価関数 evaluation
