Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/toptobes/simulacra


https://github.com/toptobes/simulacra

Last synced: about 8 hours ago
JSON representation

Awesome Lists containing this project

README 

        
# Simulacra



## Usage



Env variables:  

|- `(Required)` `OPENAI_TOKEN`  

|- `(Required)` `ASTRA_CLIENT_ID`  

|- `(Required)` `ASTRA_CLIENT_SECRET`  

|- `(Required)` `ASTRA_CLIENT_KEYSPACE`  

|- `(Optional)` `EMBED_SERVICE_URL` (default: `http://localhost:5000/embed`)  

\- `(Optional)` `NUM_AGENTS` (default: `3`)



Place your secure connect bundle in `simulacra/secrets/secure-connect-.zip`  

Then you can just run `./gradlew run`



**Prefer stopping the program through the command line or some other way which ensures

that the shutdown hooks are ran**



## Base Architecture



*I'm sorry*



### God

The user has the ability to interact with items, run db queries, and more through the

command line.



When given a list of places or agents or something, the interpreter utilizes jaro-winkler

similarity to allow you to just type the start of an area/agent/whatever, and leaves room

for typos.



### Sim Clock



The heart of the simulation is the SimClock which holds the `ScheduledExecutorService`-based event

loop, and the time of the simulation as a `LocalDateTime`. The `TIME_GRANULARITY` represents at what

fixture time is passed (10m by default)



Within the loop, the correct `Moment` for each loop is determined, of which there are three types:  

 - `ReactiveMoment` - This is the most common moment, run for every `TIME_GRANULARITY` of the day.

It's where the agent reacts to its surroundings and determines what it wants to do for that specific

moment.

 - `ProactiveMoment` - Run once an hour (sim time), it's when the agent determines its base plan

for the hour, or for the day, if that's necessary.

 - `ReflectiveMoment` - Run once a day, it's when the agent redoes its executive agent summary. 



### The Environment



The "world" is a hierarchy of world -> areas -> subareas -> items, which each being represented as a node

containing the set of nodes beneath it.



### Agents



Agents are represented as a single class which contains everything it needs within. You'll notice

some functions are something like named `xxxxxxV2`, which are alternate implementations of certain 

functions that haven't really been tested much, but might have potential to go somewhere.



### Conversations



Conversations between agents happen on a separate, concurrent, loop, and aren't processed in the main

loop while they're in conversation (and therefore don't participate in Moments so don't react to

their surroundings or anything). This allows them to converse as fast as they want instead of having 

a single message every 10 min (sim time).



### Agent/environment generation



This could probably be improved upon, but it works as it is. When `SimFactory.loadSimulation()` is called,

it looks in two places for already existing agents before generating new ones:

 - `simulacra/config/agents.yaml` - Where you can put your own custom agents

 - `simulacra/cache/agents.yaml` - Where previously generated agents are stored



Then, it generates *roughly* the number of agents remaining, if needed (it doesn't generate) the

exact number as it leaves it up to the AI to determine how many agents are generated per family,

for concurrency and simplicity purposes, though this could be fixed if needed.



It generates roughly 1 new workplace for every 12 agents, assuming that about half of them don't work.

It also assumes roughly 3 agents per house when averaged.



It's not great, but it's good enough for shallow, face value, which is mostly the goal of this project

anyway.



## Differences from the paper



That the goals of the paper and this project are quite different. That paper aims more for realism,

while we're going for "quantity over quality" to demonstrate astra's capabilities over pure plausibility.



Plus, the code in the official implementation ended up being quite different (more complex and much longer)

than what was expected from the paper. Since the code was open sourced ~2 weeks after this project started,

this project was somewhat misguided from the start (in reference to the original), but again, it does what

it set out to do.



## Next steps



To scale to a larger amount of agents, the first and foremost task would be to use Llama 2

or something as OpenAI's rate-limiting hit as hard and fast as a semi. 



However, the Function Service will have to be adapted to work with Llama, but that shouldn't

be too hard to do. One possible method is to just reuse the JSON output generated by the

ObjectMapper used in the OpenAI server as that has the appropriate mixins to serialize

the response class.



Better error handling may be required, but it's not horrible as it is, as it doesn't stop the

program on errors.



Conversations need more testing though, and the ability for agents to have their own local

WorldMap instead of being omniscient of the world around them is required lest the AI be

overwhelmed by the amount of choices when given an enumeration of the areas available to

the agent when heavily scaled. Plus, realism. The agent should be able to learn of new

places through conversations and such.



Also, a method for resetting the status of an item once an agent leaves the subarea may be

necessary so as not to accidentally pollute items.



Unfortunately, interacting with the AI is kinda finicky, and it gives once in a blue moon errors that aren't

really possible to replicate, and I'm hoping it doesn't screw us over when running many, many agents at once.



Lastly, a way to present the results needs to be figured out; saying that we ran 1M agents is cool and all,

but it doesn't mean much without some form of visualization.