Is it meaningful to let neutral network model analyze less vertices to speedup computing? about katago HOT 9 CLOSED

That's an interesting suggestion. I don't see how this could be a good idea. The network and/or the MCTS search don't "know" which 3 moves will be the best 3 at the end of the search. So if you require the bot to prematurely pick 3 moves and only analyze those 3, there will be frequently cases where the 3 moves chosen won't contain the best move, and then you are in trouble - no matter how much analysis you do after that it will never be able to correct the error.

from katago.

I heard it that the raw network (1 visit per turn) is strong enough to beat 6D Go player. So I want to call KataGo in this way:

1. use a bit visits to get the top 3 vertices
2. use the most visits to analyze the top 3 only (send the 3 positions to engine and then analyze)

Perhaps parallel computing is needed for step 2, could I do it in gtp mod, or I have to do it in json protocol (parallel analysis engine)?

from katago.

You could do this, but it likely would harm the strength of the bot at high visits, and would not speed up the process (as you are still evaluating the same number of graph nodes).

from katago.

Yes, and there's a good chance it would harm the strength of the bot even at medium to low visits too. The reason that KataGo has been tuned explore the amount that it does (via the PUCT formula, FPU, and other adjustments) is because that's what produced the best final move selection in past experiments. It's still not going to be perfect, but probably enough tuning has gone into it that any arbitrary ways you could think of for adjusting it (such as limiting to the top 3 or whatever) will most likely give worse results.

from katago.

If you want to try it anyways, then yes you can "implement" it yourself via "allowMoves" in the analysis engine or "allow" in the GTP engine. Do two analysis, and make the second one restrict to a smaller number of moves based on the first analysis. Your expectation going in should be that this is to be unlikely to be helpful and likely to introduce more blind spots (because you are making the engine 100% blind to any move that is not recognized very quickly to be in the top 3). But if you test enough different ideas and are careful to gather data to compare it with baseline, eventually maybe someone can find a big improvement, so feel free to test it if you want and publish your results.

from katago.

I heard it that the raw network (1 visit per turn) is strong enough to beat 6D Go player. So I want to call KataGo in this way:

1. use a bit visits to get the top 3 vertices
2. use the most visits to analyze the top 3 only (send the 3 positions to engine and then analyze)

Perhaps parallel computing is needed for step 2, could I do it in gtp mod, or I have to do it in json protocol (parallel analysis engine)?

I've thought about this suggestion of yours, and there's nothing wrong with it for those machines with higher configurations. But for most home computers, which are not that well equipped, it is true that reducing the number of selected points can serve the theoretical purpose of increasing the speed and accuracy of the calculation. But I wonder if katago supports this algorithm. Need to further optimize
你的这个建议我也想过，对于那些配置比较高的机器来说无可厚非。但是对于大部分家用电脑，配置没那么好，的确减少选点可以起到提高计算速度精度的理论意义。但是不知道katago支持这种算法吗。需要进一步优化

from katago.

I tried, it works, thank you! And algorithm performance improvement is beyond my border. I seek efficiency so many years just because I'm on old weak hardware ;D

root@localhost:~/KataGo# ./katago gtp
analyze 100 maxmoves 3
=
info move Q16 visits 13 utility 0.0457608 winrate 0.530481 scoreMean 2.46073 scoreStdev 26.4767 scoreLead 2.46073 scoreSelfplay 1.24387 prior 0.0166064 lcb 0.505290 utilityLcb -0.0247750 weight 13.0000 order 0 pv Q16 C17 Q3 C3 Q5 info move Q4 visits 13 utility 0.0457608 winrate 0.530481 scoreMean 2.46073 scoreStdev 26.4767 scoreLead 2.46073 scoreSelfplay 1.24387 prior 0.0166064 lcb 0.505290 utilityLcb -0.0247750 weight 13.0000 isSymmetryOf Q16 order 1 pv Q4 C3 Q17 C17 Q15 info move D16 visits 13 utility 0.0457608 winrate 0.530481 scoreMean 2.46073 scoreStdev 26.4767 scoreLead 2.46073 scoreSelfplay 1.24387 prior 0.0166064 lcb 0.505290 utilityLcb -0.0247750 weight 13.0000 isSymmetryOf Q16 order 2 pv D16 R17 D3 R3 D5


analyze 1000 allow b q16,q4,d16 1
=
quitinfo move Q16 visits 1419 utility 0.0218856 winrate 0.513202 scoreMean 1.31044 scoreStdev 26.7675 scoreLead 1.31044 scoreSelfplay 0.460957 prior 0.0166064 lcb 0.511140 utilityLcb 0.0161130 weight 1418.36 order 0 pv Q16 C4 R3 C16 E3 R17 Q17 R16 R15 S15 info move Q4 visits 1419 utility 0.0218856 winrate 0.513202 scoreMean 1.31044 scoreStdev 26.7675 scoreLead 1.31044 scoreSelfplay 0.460957 prior 0.0166064 lcb 0.511140 utilityLcb 0.0161130 weight 1418.36 isSymmetryOf Q16 order 1 pv Q4 C16 R17 C4 E17 R3 Q3 R4 R5 S5 info move D16 visits 1419 utility 0.0218856 winrate 0.513202 scoreMean 1.31044 scoreStdev 26.7675 scoreLead 1.31044 scoreSelfplay 0.460957 prior 0.0166064 lcb 0.511140 utilityLcb 0.0161130 weight 1418.36 isSymmetryOf Q16 order 2 pv D16 R4 C3 R16 P3 C17 D17 C16 C15 B15


=

from katago.

@HackYardo - I would caution you that unless you have rigorously tested it and proven that it is stronger, your approach has a good chance to be inefficient, even on weak hardware. And by "inefficient" i mean that even on weak hardware, the same amount of computation spent with such a method is likely to produce a weaker final result and analysis than just running without such a method and searching more moves.

from katago.

from katago.