Conversation
Merge ProtectionsYour pull request matches the following merge protections and will not be merged until they are valid. 🔴 Enforce conventional commitThis rule is failing.Make sure that we follow https://www.conventionalcommits.org/en/v1.0.0/
|
|
I think what you are describing is best achieved with a custom context type. We could call it a A note on what Sessions are: Contexts are immutable. A If you want to be able to refer to previous contexts, it might be easier to simply forgo sessions and use the functional style: ctx_0: Context = ...
mot_1, ctx_1 = b.act(ctx_0, ...)
mot_2, ctx_2 = b.act(ctx_1, ...)
mot_2, ctx_2 = b.act(ctx_2, ...)representing the trajectory: This trajectory need not be a line, of course, it could be a tree or any acyclic DAG. Additionally, -- [1]: In some earlier version of the codebase I played around with even using the subset of But I'll take a deeper look tomorrow AM. |
Purpose:
Problems:
aactare automatically added to the context, hence if the output of a node is to serve as the input to another node, this is challenging as it will be added twice (once as output and once as input)Solutions:
labelsto each context node that allows for control as to how much of the context is visible on a particular actionnullactions where generation occurs from the existing context and the input (which isNone), is not added to the context.Here's an example of the Context that is used for generation in each node in a multi-node tool calling setup with the proposed solutions
Thought Node:
Tool Calling Node: