Hello Markus!



 CesMak:

training worked, however the result is not so good


I would ask how well the training worked, and how you measured that.
Common practice is to break your dataset into two pieces: a training
dataset that you use to train your network, and a test / validation
dataset that you do not train on and that you use to test your trained
network.
You want to track your loss function, usually for every batch, since
you have it per-batch anyway, and your “accuracy” function, again,
usually for every batch, since you already have the per-batch
prediction, and the extra cost of calculating the accuracy is not
that much.
For a conventional classification problem, the accuracy function is
the fraction of predictions that are correct – that is, how often you
predicted the best card to play for the sample hand.  If you always
make the correct prediction, your accuracy would be 1 (100%, if
you prefer that).  If your predictions were effectively random, your
accuracy would be 0.01667 – you would guess the right move one
time in sixty.
If your network is training well, then you should see your loss fall
to a number that is close (in some units) to zero, and your accuracy
rise up close to one.  If this isn’t happening, your network isn’t really
training well.  (It might be training as well as it can, given the difficulty
of the problem, but not really training well.)
You also want to track the loss and accuracy of your network on your
test dataset – that is, on samples that were not used in training the
network.  If it’s not too expensive, you can evaluate your test loss and
accuracy every batch.  In any event, you should probably run your
test evaluation at least once every epoch.  Your network can “train”
well – low loss, high accuracy – on your training set, but still not
perform well on your test set.  This is often referred to as “overfitting”
or “not generalizing.”
If your network is overfitting, there are some things you can try.  Try
fewer parameters and try regularization / weight decay.  There is
some thinking that ReLU activations are likely to generalize better
than things like tanh().  You can also reduce overfitting by training
on more data, if, of course, you have it.
If your network is not training well, try running the training longer.
The training process sometimes hits “plateaus.”  Try changing
the learning rate – both larger and smaller.  Try using a different
optimizer, e.g., switch SGD for Adam (or vice versa).  It can also be
worth changing your network architecture, in particular, adding more
and/or wider layers (both of which translate to more parameters).
These “bigger” networks are likely to train more slowly, but may end
up performing better after the slower training.
Lastly, if your network is training and generalizing well – that is, if
it is performing well on your test dataset, in particular, achieving a
high accuracy – but not playing a good game, then there is something
unrealistic with the data you are training on.  After all, if your network
is doing a good job predicting the moves chosen by your “MCTS”
scheme, but not playing well, then presumably your MCTS system
shouldn’t be playing well either.
Charts as your training progresses of your loss and accuracy on
both your training and test datasets would help give a sense of
which scenario is likely to be playing out.
(As for other learning methods that might be useful for your card game,
I don’t have much to say.  I don’t know much about potentially relevant
learning methods, and I don’t have much intuition about your specific
use case.)
Good luck.
K. Frank