DAGWorks-Inc / burr

Build applications that make decisions (chatbots, agents, simulations, etc...). Monitor, trace, persist, and execute on your own infrastructure.
https://burr.dagworks.io
BSD 3-Clause Clear License
1.28k stars 71 forks source link

feat: `ActionGraph` vs. `StateGraph` #420

Open zilto opened 1 week ago

zilto commented 1 week ago

Currently, the .visualize() method returns a graph where actions are nodes and transitions are edges. Parameters allow to display conditional edges and state values that are read/written. Let's call this the action graph. This helps understand the logic of the application and shows the previous/next action at runtime.

Here's an example:

image

Another relevant visualization would be the state graph where state fields are nodes and actions are edges. Currently, there are no visual tools to know all the state fields before execution. This puts emphasis on the dataflow of the application (converts a state machine graph to a dataflow, similar to Hamilton). During monitoring or debugging, we can number nodes with a sequence_id to know when it was last updated.

image

This graph being confusing is not indicative of the value of the plot, but rather that simplification could be made. It becomes obvious that feedback_history is redundant with the many persisted instance of feedback

(This other graph structure is key to create rollback mechanisms. If the field input_document is updated on sequence 1 and 7, and you want to rollback the value of input_document when at sequence 10, we know we have to rollback to sequence 1 (or do some diff with 7 rather "undo" each step from 10 to 1)