Rancore ha scritto:ArabicLawrence ha scritto:Rancore ha scritto:[...]
Automill invece probabilmente resta aperto perché è un archetipo complicato da draftare per un bot. E' difficile capire che <a href="https://www.cardtrader.com/api/metagame_it/v1/magic/Golgari Grave-Troll/shop" class="CardTraderTooltip" target="_blank">Golgari Grave-Troll</a> e <a href="https://www.cardtrader.com/api/metagame_it/v1/magic/Urborg Lhurgoyf/shop" class="CardTraderTooltip" target="_blank">Urborg Lhurgoyf</a> sono sinergiche con, per dire, <a href="https://www.cardtrader.com/api/metagame_it/v1/magic/Living Death/shop" class="CardTraderTooltip" target="_blank">Living Death</a>.
[...]
Ma aggiungere a ogni carta i tag degli archetipi non risolve questo problema, vero? Chiedo su Github, perché mi pare che almeno in teoria dovrebbe farlo
Non ho mai sentito parlare di un'eventuale funzione che faccia questa cosa, ma ci starebbe! Fammi sapere che ti dicono
https://discord.com/channels/592787488523943937/721758433988182016/1105925143349432320
DEKKARU ha scritto: —
10/05/2023 20:31
nope
the bots do not see any attribute of any card
they are only trained on the relationships between cards in decks, drafts, and cubes
There's still lots of improvements I'm working on ATM
ryancsaxe ha scritto: —
11/05/2023 16:06
One thing to note about this: it’s very possible the draft bots have a very good understanding of this but the deckbuilder does not.
The actual problem of deckbuilding, maybe un-intuitively, is MUCH harder than drafting for these types of algorithms. So if you often see those cards in a drafted pool together, but not in the final deck, note that that does not imply the underlying system misses the synergistic relationship.
Aggiungo questa parte che è interessante:
https://discord.com/channels/592787488523943937/721758433988182016/1108030489211707422
ryancsaxe ha scritto: —
16/05/2023 15:57
Assuming [the deckbuilder code] didn't move from where it last was: https://github.com/dekkerglen/CubeCobraML/blob/main/model/model.py
The deckbuilder and drafter are actually parts of the same model, described above.
You can think of this Machine Learning Algorithm as "multi-task" . . . it is a single algorithm that accomplishes card-recommendations, draft picking, and deck building
The first part of the algorithm is an "encoder". It takes an arbitrary collection of cards, and learns how to compress the information from that collection in order to make decisions.
The second part of the algorithm is a "decoder", and each task (recommendation, draft, build) has it's own separate decoder.
The reason why, I expect, the deckbuilder is worse than the drafter is two fold:
deckbuilding is, computationally speaking, a much more difficult task that cannot be described via a single continuous operation (drafting is rank all cards in the pack, take the card with the highest rank. While deckbuilding has a lot more going on in it and is not going to be as optimized via the same "grab top K" process. However, that is how it currently works @DEKKARU correct me if I'm wrong here, as maybe you implemented some heuristics on top for inference that I don't know about)
because of the above, the objective function for the draft component of the model is identical to what we want to deploy for the live drafter. However, the objective function for the build component of the model is not. This is why I say an optimal deckbuilder is much harder, and would require a lot of innovation on the algorithmic side
If you're interested in all of that, you can check out the deckbuilder code I wrote for retail limited here: https://github.com/RyanSaxe/mtg/tree/main
Retail limited is waaaaaay simpler than cube, and I had to do a ton of work to get the deckbuilder functioning the way I wanted. Much more than that of drafting.
Also, to be more clear:
my retail Limited deckbuilder model training code: https://github.com/RyanSaxe/mtg/blob/main/mtg/ml/models.py#L391
my retail Liimted deckbuilder model inference code: https://github.com/RyanSaxe/mtg/blob/main/mtg/ml/display.py#L328
You can see I had to write like 100 lines of code to get the model to properly calibrate the basics it learned to add by using heuristics.
[Replying to "does that mean that disenchant gets more respect in an artifact cube?"]
Yup! Because the "encoder" takes a "collection of cards", that collection gives you information about the cube, and it will learn how seeing particular cards means things about different environments and how this perturbs the value of cards. In part, this is why the drafter feels so good.
However, we technically don't give the drafter/builder a representation of the entire cube when it makes the decisions. So the above is a soft statement, not a hard statement. Does that make sense?