Experimenting With Chat Stream (Pirate Example)

[VentureTactics]

This workflow helps illustrate how ancestor context applies (or doesn't apply) to the various conversations within a Chat Stream.

[rpggio]

Thanks for the example, @VentureTactics!

RE adjusting the chat role, we could use frontmatter props to make it editable

Your experiment illustrates a primary issue with Chat Stream, which is understanding precisely how the context will be composed. Some ideas that come to mind:

• For each unique generation node (a node that has has been issued a Generate command), produce a generated document note that makes explicit the context used. If the user re-runs generation on that node, the generated doc is overwritten.
• Same idea as above, but within in the canvas. Create a chained copy of the notes showing the exact context. Something like 'Unwrap context' command.
• Enable the use of multi-select to pick which nodes to include. Arrows in that case are used only to determine node ordering (in combination with node x/y pos).

[VentureTactics]

Great ideas there @rpggio.

Re: overriding generation context docs:

Only challenge with the context override is that nodes are often re-used in multiple chats, even in the same canvas.

In fact, I'd say that's one of the huge benefits this plugin unlocks. :)

For example, what if you actually want to generate a response from the same command more than one time without destroying the previous generation, or un-linking it by destroying the arrows (which is useful if you're trying to compare outputs)?

So maybe it would work as long as it was non-destructive to each generation. It should work as long as the context is logged to a particular generation and not overridden by a subsequent generation.

Another challenge is how, if each generation also linked the full thread, in workflows with many compounding generations, would those links be detected and added to the context window? Not sure if it works that way, but if it does, all the previous thread information would crowd the context window and possibly confuse the model.

This can probably be fixed with proper back-end logic, though, if you placed the context linked in the frontmatter, and ignored all previous context links for the thread other than the most recent one upon generation.

Re: Unwrap context

Good idea, though if the context was linked in the frontmatter of a generation (in a way that keeps it from being included in generations when this node is an ancestor), someone could just use the hover editor plugin and hold CTR when hovering over the context link to see and manipulate it.

It seems like the logic for the node merge idea and this thread context idea would be closely related via a similar compiling mechanism. There should still be the option for both, of course.

Re: multi-select to include nodes.

Yeah, that makes sense. Canvas groups, or tags, colors, and similar, can also be useful.

Honestly, as long as the context only includes true ancestor nodes that are only up-stream of the arrows, the logic should work fine. In my image example, it worked perfectly because I didn't want it to know the context from the 'First' generation until I linked it with my 'Fourth (context)' arrow. I only wanted it to know information up-stream until connected (although it would be interesting to see what can be accomplished with bidirectional edge connections).