Open gavento opened 1 year ago
How to implement filtering:
A. Either just swithching individual tags between visible/hidden-subtree/hidden-wrapper (the tag classes then hint which tags are by default hidden, or are easily toggleable (if there are many tags). B. Or just have full JSON-path-based filter, with the default settings hiding classes as in case 3 above.
My first impression is that we want to have some standard tags for games, queries, and utility wrappers anyway, and then we can do 2. (e.g. as default filter) or 3. (explicit hidabilty of nodes, though less sure about that) And then we can look into B. (JSON-path - is it good or is it whack?) while starting with just A. (The MVP could be just having toggles for known hidable classes (from 2.) and maybe 3 toggles for all of T-wrapper and T-hidden and T-hidable.
Not very high priority in the UI but making some decent early judgment calls about how we use tags may be good early.
@spirali , @klao What do you think?
Note that the functionality is mostly there thanks to @spirali 's recent work. The kind+tag semantics and more general filters are still to be decided and created, though.
Logged contexts have different semantics and usage, for example: root context, entire game/experiment, individual game moves&observations, main structure of agent deliberation, queries to LLMs, and auxiliary structures like repeat_on_failure.
It would be useful to have several broad categories for those, for better UI view customization and also post-processing. For example:
Why: both for readability in the GUI (see just "a dialog" instead of "a dialog split into rounds", by default see only the last iteration of repeat_on_failure, etc.) and semantically when working with the data (so that e.g. only "agent messages" can be selected from a complex dialogue interaction split into phases/rounds etc., without e.g. having to scan into round subtrees manually and explicitely - or even deal with what the rounds are and if they are there) (edited)
How: Think about tags and their types, and filter based on them.
H-foo
is hidden by default,S-bar
is a wrapper/structural tag, ... This is not very elegant, though may be convenient. Also needs good naming to be intuitive.action
,game
,observation
,repeated-on-failure
...) and define their classses. Having standard tags may be useful practice anyway.T-wrapper
,T-hidden
orT-hidable
to the node. Explicit, does allow the same tag to be hidden/not hidden dep. on the context. Better for the default setting, but not better for classifying the tags themselves.