Closed gavento closed 1 year ago
Mostly achieved after #7 but with some outstanding bikeshedding:
llm
module is not just about llms, but more about engines (some of them LLMs), parsing (from LLMs), ...Mixture of high-level with some low-level naming bits. Incomplete but good to be criticized!
contex
- Context, logging, context loading/filtering, special context types
store
module? (to have more than JSON in time)util/
to context
(Blob, Html, ...)__log__
to less generic (to make it future-proof), e.g. _log_to_context
ui
- servers for browser, console, ...
actors
memory
as submodule, moving format
under memoryexperimental
- experimental memory implsexperimental
- experimental actor implscontrib
? (eh) keep them in experimental
forever? (nah) some other module naming scheme here? (maybe) or separate into other dirs? (e.g. move one-shot agent into models
? nah) (or have top-level contrib
-like dir? seems like cop-out, ...)text
- text utils: json_parsing, fmtstring, parse_tag
parse_json
, parse_tag
, ...models
(or llm
, text_models
?) - engine wrapping (as integration of other engines still with logging and common interface), our engines (maybe remove in favor of langchain only), query_for_json
and friends (query for example of a JSON, cache of examples)
experimental
- experimental engines and functionality (future: query LLM with activation vectors)utils
- minimalistic
colors
- add simple color manipulation (for context styling), have pseudo_random_color
hereext
- as is now, general integrations with other services/libraries/...
I want users and prospective developers to have a mental model of this being both:
experimental
and contrib
modules - to invite people to just write their concrete (and unpolished) semi-general LLM agents and their modules@spirali @klao please add more:
I agree with new code structure (especially to move server stuff outside of context module)
I would make "actors" only for generic abstract API. And then have different module for all actor implementations with some substrucutre (I do not have right name for the module now).
Activation vectors will probably needs one extra feature: storing binary data next to context jsons and have a link to these files in contexts. We cannot probably store it directly into context json because of size.
The only thing that is in my mind is "add_event" for instant context, that now have clash with "Events" in memory subsystem.
Closed by #29
Includes some stability of the log JSON (for better backwards compatibility vs future UI updates and other tools), and having examples / starting templates for users based on that.
If we run experiments in Google colab, I expect it to have an issue with the UI (as the port opened on the colab server is not accessible). @spirali would this be solved by Jupyter-like lab UI-embed into colab? Or is there some other solution? (Or another notebook hosting? ;-)