国际象棋：Alpha-Beta中的错误

时间：2016-07-03 20:06:37

标签： algorithm artificial-intelligence chess minimax alpha-beta-pruning

我正在实现一个国际象棋引擎，我编写了一个相当复杂的alpha-beta搜索例程，其中包含静止搜索和转置表。但是，我正在观察一个奇怪的错误。

评估函数使用方块表，就像这个用于典当：

static int ptable_pawn[64] = {  
   0,  0,  0,  0,  0,  0,  0,  0,
  30, 35, 35, 40, 40, 35, 35, 30,
  20, 25, 25, 30, 30, 25, 25, 20,
  10, 20, 20, 20, 20, 20, 20, 10,
   3,  0, 14, 15, 15, 14,  0,  3,
   0,  5,  3, 10, 10,  3,  5,  0,
   5,  5,  5,  5,  5,  5,  5,  5,
   0,  0,  0,  0,  0,  0,  0,  0
};

当它转过黑色时，表格会在x轴上反射出来。具体来说，如果你很好奇，那么查找会发生这样的情况，其中A-H列映射到0-7，行是白色的0-7行：

int ptable_index_for_white(int col, int row) {
    return col+56-(row*8);
}

int ptable_index_for_black(int col, int row) {
    return col+(row*8);
}

因此，h4（坐标7,3）上的一个棋子值白色为3点（厘米），而f6（坐标5,5）上的棋子值为3厘米（黑色）。

整个评估功能目前是方块表和材料。

在更大的搜索深度，我的引擎正在选择一些真正可怕的动作。考虑从起始位置生成的此输出：

Iterative Deepening Analysis Results (including cached analysis)
Searching at depth 1... d1 [+0.10]: 1.b1c3 
    (4 new nodes, 39 new qnodes, 0 qnode aborts, 0ms), 162kN/s
Searching at depth 2... d2 [+0.00]: 1.e2e4 d7d5 
    (34 new nodes, 78 new qnodes, 0 qnode aborts, 1ms), 135kN/s
Searching at depth 3... d3 [+0.30]: 1.d2d4 d7d5 2.c1f4 
    (179 new nodes, 1310 new qnodes, 0 qnode aborts, 4ms), 337kN/s
Searching at depth 4... d4 [+0.00]: 1.g1f3 b8c6 2.e2e4 d7d5 
    (728 new nodes, 2222 new qnodes, 0 qnode aborts, 14ms), 213kN/s
Searching at depth 5... d5 [+0.20]: 1.b1a3 g8f6 2.d2d4 h8g8 3.c1f4 
    (3508 new nodes, 27635 new qnodes, 0 qnode aborts, 103ms), 302kN/s
Searching at depth 6... d6 [-0.08]: 1.d2d4 a7a5 2.c1f4 b7b6 3.f4c1 c8b7 
    (21033 new nodes, 112915 new qnodes, 0 qnode aborts, 654ms), 205kN/s
Searching at depth 7... d7 [+0.20]: 1.b1a3 g8f6 2.a1b1 h8g8 3.d2d4 g8h8 4.c1f4 
    (39763 new nodes, 330837 new qnodes, 0 qnode aborts, 1438ms), 258kN/s
Searching at depth 8... d8 [-0.05]: 1.e2e4 a7a6 2.e4e5 a6a5 3.h2h4 d7d6 4.e5d6 c7d6 
    (251338 new nodes, 2054526 new qnodes, 0 qnode aborts, 12098ms), 191kN/s

在深度8处​​，请注意黑色打开时会移动“... a7a6 ... a6a5”，根据方块表，这些动作很可怕。此外，“h2h4”对白人来说是一个可怕的举动。为什么我的搜索功能会选择这种奇怪的动作？值得注意的是，这只是在更深的地方开始发生（深度3处的移动看起来很好）。

此外，搜索经常会使作品失误！考虑以下立场：

Blunder

引擎推荐了一个可怕的错误（3 ... f5h3），不知何故错过了明显的回复（4. g2h3）：

Searching at depth 7... d7 [+0.17]: 3...f5h3 4.e3e4 h3g4 5.f2f3 g8f6 6.e4d5 f6d5 
    (156240 new nodes, 3473795 new qnodes, 0 qnode aborts, 17715ms), 205kN/s

不涉及静止搜索，因为错误发生在第1层（!!）。

以下是我的搜索功能的代码。对不起它太冗长了：我尽可能简化，但我不知道哪些部分与bug无关。我认为我的算法有些巧妙。

该实现几乎完全基于维基百科的this one。 （更新：我已经大大简化了搜索，我的错误仍然存​​在。）

// Unified alpha-beta and quiescence search
int abq(board *b, int alpha, int beta, int ply) {
    pthread_testcancel(); // To allow search worker thread termination
    bool quiescence = (ply <= 0);

    // Generate all possible moves for the quiscence search or normal search, and compute the
    // static evaluation if applicable.
    move *moves = NULL;
    int num_available_moves = 0;
    if (quiescence) moves = board_moves(b, &num_available_moves, true); // Generate only captures
    else moves = board_moves(b, &num_available_moves, false); // Generate all moves
    if (quiescence && !useqsearch) return relative_evaluation(b); // If qsearch is turned off

    // Abort if the quiescence search is too deep (currently 45 plies)
    if (ply < -quiesce_ply_cutoff) { 
        sstats.qnode_aborts++;
        return relative_evaluation(b);
    }

    // Allow the quiescence search to generate cutoffs
    if (quiescence) {
        int score = relative_evaluation(b);
        alpha = max(alpha, score);
        if (alpha >= beta) return score;
    }

    // Update search stats
    if (quiescence) sstats.qnodes_searched++;
    else sstats.nodes_searched++;

    // Search hueristic: sort exchanges using MVV-LVA
    if (quiescence && mvvlva) nlopt_qsort_r(moves, num_available_moves, sizeof(move), b, &capture_move_comparator);

    move best_move_yet = no_move;
    int best_score_yet = NEG_INFINITY;
    int num_moves_actually_examined = 0; // We might end up in checkmate
    for (int i = num_available_moves - 1; i >= 0; i--) { // Iterate backwards to match MVV-LVA sort order
        apply(b, moves[i]);
        // never move into check
        coord king_loc = b->black_to_move ? b->white_king : b->black_king; // for side that just moved
        if (in_check(b, king_loc.col, king_loc.row, !(b->black_to_move))) {
            unapply(b, moves[i]);
            continue;
        }
        int score = -abq(b, -beta, -alpha, ply - 1);
        num_moves_actually_examined++;
        unapply(b, moves[i]);
        if (score >= best_score_yet) {
            best_score_yet = score;
            best_move_yet = moves[i];
        }
        alpha = max(alpha, best_score_yet);
        if (alpha >= beta) break;
    }

    // We have no available moves (or captures) that don't leave us in check
    // This means checkmate or stalemate in normal search
    // It might mean no captures are available in quiescence search
    if (num_moves_actually_examined == 0) {
        if (quiescence) return relative_evaluation(b); // TODO: qsearch doesn't understand stalemate or checkmate
        coord king_loc = b->black_to_move ? b->black_king : b->white_king;
        if (in_check(b, king_loc.col, king_loc.row, b->black_to_move)) return NEG_INFINITY; // checkmate
        else return 0; // stalemate
    }

    // record the selected move in the transposition table
    evaltype type = (quiescence) ? qexact : exact;
    evaluation eval = {.best = best_move_yet, .score = best_score_yet, .type = type, .depth = ply};
    tt_put(b, eval);
    return best_score_yet;
}

/* 
 * Returns a relative evaluation of the board position from the perspective of the side about to move.
 */
int relative_evaluation(board *b) {
    int evaluation = evaluate(b);
    if (b->black_to_move) evaluation = -evaluation;
    return evaluation;
}

我正在调用这样的搜索：

int result = abq(b, NEG_INFINITY, POS_INFINITY, ply);

编辑：即使我简化了搜索例程，错误仍然存​​在。发动机简单地弄掉了碎片。您可以通过将其加载到XBoard（或任何其他与UCI兼容的GUI）并在强引擎上播放来轻松查看。在manlio的要求下，我上传了代码：

这是GitHub存储库（链接已删除;问题在上面的代码段中）。它将在OS X或任何* nix系统上使用“make”构建。

2 个答案:

答案 0 :(得分：4)

if (score >= best_score_yet) {

应该是：

if (score > best_score_yet) {
或者你会考虑不好的举动。第一个best_move_yet将是正确的（因为best_score_yet = NEG_INFINITY），但score == best_score_yet的其他移动不一定更好。

更改该行：

起始位置 

Iterative Deepening Analysis Results (including cached analysis)
Searching at depth 1... d1 [+0.10]: 1.e2e4 
    (1 new nodes, 4 new qnodes, 0 qnode aborts, 0ms, 65kN/s)
    (ttable: 1/27777778 = 0.00% load, 0 hits, 0 misses, 1 inserts (with 0 overwrites), 0 insert failures)
Searching at depth 2... d2 [+0.00]: 1.e2e4 g8f6 
    (21 new nodes, 41 new qnodes, 0 qnode aborts, 0ms, 132kN/s)
    (ttable: 26/27777778 = 0.00% load, 0 hits, 0 misses, 25 inserts (with 0 overwrites), 0 insert failures)
Searching at depth 3... d3 [+0.30]: 1.d2d4 g8f6 2.c1f4 
    (118 new nodes, 247 new qnodes, 0 qnode aborts, 5ms, 73kN/s)
    (ttable: 187/27777778 = 0.00% load, 0 hits, 0 misses, 161 inserts (with 0 overwrites), 0 insert failures)
Searching at depth 4... d4 [+0.00]: 1.e2e4 g8f6 2.f1d3 b8c6 
    (1519 new nodes, 3044 new qnodes, 0 qnode aborts, 38ms, 119kN/s)
    (ttable: 2622/27777778 = 0.01% load, 0 hits, 0 misses, 2435 inserts (with 0 overwrites), 1 insert failures)
Searching at depth 5... d5 [+0.10]: 1.g2g3 g8f6 2.f1g2 b8c6 3.g2f3 
    (10895 new nodes, 35137 new qnodes, 0 qnode aborts, 251ms, 184kN/s)
    (ttable: 30441/27777778 = 0.11% load, 0 hits, 0 misses, 27819 inserts (with 0 overwrites), 0 insert failures)
Searching at depth 6... d6 [-0.08]: 1.d2d4 g8f6 2.c1g5 b8c6 3.g5f6 g7f6 
    (88027 new nodes, 249718 new qnodes, 0 qnode aborts, 1281ms, 264kN/s)
    (ttable: 252536/27777778 = 0.91% load, 0 hits, 0 misses, 222095 inserts (with 0 overwrites), 27 insert failures)
Searching at depth 7... d7 [+0.15]: 1.e2e4 g8f6 2.d2d4 b8c6 3.d4d5 c6b4 4.g1f3 
    (417896 new nodes, 1966379 new qnodes, 0 qnode aborts, 8485ms, 281kN/s)
    (ttable: 1957490/27777778 = 7.05% load, 0 hits, 0 misses, 1704954 inserts (with 0 overwrites), 817 insert failures)

在测试位置时：

Calculating...
Iterative Deepening Analysis Results (including cached analysis)
Searching at depth 1... d1 [+2.25]: 3...g8h6 4.(q)c3d5 (q)d8d5 
    (1 new nodes, 3 new qnodes, 0 qnode aborts, 0ms, 23kN/s)
    (ttable: 3/27777778 = 0.00% load, 0 hits, 0 misses, 3 inserts (with 0 overwrites), 0 insert failures)
Searching at depth 2... d2 [-0.13]: 3...f5e4 4.c3e4 (q)d5e4 
    (32 new nodes, 443 new qnodes, 0 qnode aborts, 3ms, 144kN/s)
    (ttable: 369/27777778 = 0.00% load, 0 hits, 0 misses, 366 inserts (with 0 overwrites), 0 insert failures)
Searching at depth 3... d3 [+0.25]: 3...g8h6 4.c3e2 h6g4 
    (230 new nodes, 2664 new qnodes, 0 qnode aborts, 24ms, 122kN/s)
    (ttable: 2526/27777778 = 0.01% load, 0 hits, 0 misses, 2157 inserts (with 0 overwrites), 0 insert failures)
Searching at depth 4... d4 [-0.10]: 3...g8f6 4.e3e4 f5e6 5.f1b5 
    (2084 new nodes, 13998 new qnodes, 0 qnode aborts, 100ms, 162kN/s)
    (ttable: 15663/27777778 = 0.06% load, 0 hits, 0 misses, 13137 inserts (with 0 overwrites), 2 insert failures)
Searching at depth 5... d5 [+0.15]: 3...g8f6 4.f1e2 h8g8 5.g2g4 f5e4 6.(q)c3e4 (q)f6e4 
   (38987 new nodes, 1004867 new qnodes, 0 qnode aborts, 2765ms, 378kN/s)
   (ttable: 855045/27777778 = 3.08% load, 0 hits, 0 misses, 839382 inserts (with 0 overwrites), 302 insert failures)

答案 1 :(得分：3)

我很乐意看看实际的回购，但我已经多次实现类似游戏算法的确切问题。我会告诉你是什么原因造成我的问题，你可以检查一下你是否犯了同样的错误。这些按照我猜测最有可能解决问题的顺序列出。

Plys不是移动，移动应该每次迭代增加2（这是一层是多少）

这个错误几乎总是表现为对第一个玩家的几乎所有动作做出糟糕的选择，因为他们永远看不到做出坏动作的后果。你避免这种情况的方法是将移动增加2（或者更多地通过游戏中的玩家数量增加，但是你使用minmax这样它的2）。这可以确保每位玩家始终在下一回合中寻找后果。

必须始终从当前玩家的角度进行评估

这个听起来很明显，但我发誓每次实施评估功能时我都会这样做。在设计评估时，我们总是从第一个玩家的角度设计它，当我们应该做的是设计它以返回当前玩家的评价。我们可以判断哪个玩家轮到了，因为我们拥有完整的棋盘状态，所以没有必要传递它。

如果您的评估电话不是您的minmax功能中的第一个电话，但是您已经通过这种方式实施，那么这个问题尤其难以调试，因此这不是一个问题。

评估函数必须是对称的

当它发生时，这是一个特别讨厌的错误。这个想法是，同一个玩家会根据他们是输赢来评估同一个位置。

以国际象棋为例，作为获胜球员，你想赢得最少数量的动作，但如果你输了，你想要输掉最长的动作数。对此的一个典型解决方案是说，如果你要获胜，可以在较少数量的动作中为获胜添加奖励，但如果你将失去，则为更长的序列添加奖励。这导致根据情况在相反的原因上添加奖励，并从评估中移除对称性，使得玩家A不等于-Player B.当您失去这种对称性时，您不能再将值传递回游戏树，你必须在每一步重新评估它们。

但诀窍是像这样做的调整总是错误的。通过深度静态评估，如果找到有保证的胜利，它将会提前切断。通过迭代深化解决方案，它仍然会首先找到先前的胜利。除非对手犯错，否则5中的配偶永远不会成为4中的配偶，所以不需要这样的调整。

仔细检查您是否没有与转置表冲突

我无法看到您的转置表的实现，但如果您处理的状态多于分配给存储的状态，则必须确保它在您信任该值之前处于相同的位置。我怀疑这是一个问题，因为看起来你只看了几百万个节点，但仔细检查它总是好的。此外，请确保您的哈希函数足够随机，以避免定期冲突。

mtd_f不应参考转置表

mtd_f是一个直通函数，可以在第一次调用negamax时正确处理转置表。您正在使用其中的值，因为它现在已经实现，但只是删除该代码将清理实现并正确处理它。此外，您应该在每次迭代时将评估传递给mtd_f函数，而不是每次都尝试加载它。

相关问题
最新问题