Hi, I would like to ask whether KataGo could support temporarily giving a specific root move additional search priority while keeping the normal search running on the same tree.
The use case comes from analysis GUIs. Sometimes a user suspects that a move with very low visits, or even a move not shown among the main candidates, may be a blind spot and wants KataGo to investigate it more deeply.
Currently this can be approximated with allow, for example by running a restricted analysis that only allows that move. However, this creates a separate restricted search state rather than adding the result back into the normal search tree.
What I am wondering about is behavior conceptually like:
Normal search:
A 12000 visits
B 7000 visits
C 3500 visits
O4 100 visits
User requests:
Ensure O4 reaches at least 3000 visits
While this request is active:
O4 would receive additional root search priority.
Other moves would still be searched normally.
The additional visits for O4 would accumulate directly in the existing normal search tree.
Once O4 reaches the requested visit count, the extra priority would be removed.
Normal PUCT/search behavior would then continue using the updated statistics.
The interesting part is that, if O4 was genuinely underexplored and turns out to be better than the existing candidates, KataGo could naturally continue allocating visits to it and correct the move ordering itself.
So this would be different from restricting the search to a subset of moves. The goal is not to reduce exploration, but to let a user explicitly investigate a suspected blind spot without discarding the normal search.
I noticed that KataGo already has some root-level mechanisms such as rootHintLoc and rootDesiredPerChildVisitsCoeff that can influence visit allocation, although I understand their semantics and implementation details are different.
Would something like this be feasible with the current search architecture?
More specifically:
Is there already an internal mechanism that could support this without clearing the search tree?
If not, would a transient per-root-move "minimum visits" or "search priority" API make sense?
Would there be any major correctness or search-quality concerns with letting a GUI temporarily request this?
The exact GTP/API syntax is not important to me. I am mainly interested in whether this behavior is compatible with KataGo's search design and whether it could be useful as a general analysis feature.
Hi, I would like to ask whether KataGo could support temporarily giving a specific root move additional search priority while keeping the normal search running on the same tree.
The use case comes from analysis GUIs. Sometimes a user suspects that a move with very low visits, or even a move not shown among the main candidates, may be a blind spot and wants KataGo to investigate it more deeply.
Currently this can be approximated with allow, for example by running a restricted analysis that only allows that move. However, this creates a separate restricted search state rather than adding the result back into the normal search tree.
What I am wondering about is behavior conceptually like:
Normal search:
A 12000 visits
B 7000 visits
C 3500 visits
O4 100 visits
User requests:
Ensure O4 reaches at least 3000 visits
While this request is active:
O4 would receive additional root search priority.
Other moves would still be searched normally.
The additional visits for O4 would accumulate directly in the existing normal search tree.
Once O4 reaches the requested visit count, the extra priority would be removed.
Normal PUCT/search behavior would then continue using the updated statistics.
The interesting part is that, if O4 was genuinely underexplored and turns out to be better than the existing candidates, KataGo could naturally continue allocating visits to it and correct the move ordering itself.
So this would be different from restricting the search to a subset of moves. The goal is not to reduce exploration, but to let a user explicitly investigate a suspected blind spot without discarding the normal search.
I noticed that KataGo already has some root-level mechanisms such as rootHintLoc and rootDesiredPerChildVisitsCoeff that can influence visit allocation, although I understand their semantics and implementation details are different.
Would something like this be feasible with the current search architecture?
More specifically:
Is there already an internal mechanism that could support this without clearing the search tree?
If not, would a transient per-root-move "minimum visits" or "search priority" API make sense?
Would there be any major correctness or search-quality concerns with letting a GUI temporarily request this?
The exact GTP/API syntax is not important to me. I am mainly interested in whether this behavior is compatible with KataGo's search design and whether it could be useful as a general analysis feature.