langs
Joined 15 years ago
Joined 15 years ago
I categorize the game's actions into three types: combat, deck-building, and other interactions.
For combat, MCTS is used. Yes, it's similar to the approach used in Go AI.
For deck-building, a sparse graph search is used: the goal is to rapidly identify winning deck templates within the graph structure.
Only the remaining aspects are delegated to the LLM to make reasoned decisions.
Parallelly, I'm working on an attention-based memory retrieval system that achieved SOTA on LongMemEval, LoCoMo, and code retrieval benchmarks. https://github.com/AttemorySystem/attemory/
Maybe later I'll build a live-streaming AI agent that plays Slay the Spire while conversing with viewers and remembering everything in chat!
Using attention for retrieval was inspired by a comment I saw in here long time ago: Prediction and retrieval are two sides of the same coin; to predict better, you must retrieve more accurately.
I'm still working on the improvement of algorithms, my tests shows the performance and accuracy will be improved a lot in the next release.
This aligns with the "zero tokens" approach described in this paper. :)
I tested it on the LoCoMo used in this paper, and also LongMemEval, both achieved SOTA results.
Writing code is indeed the bottleneck for same resource constrained companies.
Rapid code development creates more opportunities for trial and error, providing companies with more information for decision making, that previously might have been addressed by meetings.
Of course, this might bring other problems, but it might not right to generally speaking that writing code is not a bottleneck.
https://github.com/AttemorySystem/spire-agent
A retrieval engine that using attention to retrieval, achieved several SOTA results on multiple benchmarks(LongMemEval, LoCoMo, code search, etc)
https://github.com/AttemorySystem/attemory