“piebes” — Fediverse search results on home.social

Tero Keski-Valkama @[email protected] · 2023-04-22 · 12:22 UTC

Relating to my last post, what is the best way to encode chatbot discourse processes?

In the past, with IBM Watson and similar, the process was pretty strictly defined like this:

1. Interrogate the user to find out which procedure they need.

2. Select procedure, the procedure is a web form which requires a set of inputs from the user. Name, date of reservation, number of people eating, special preferences, those sorts of things.

3. Interrogate the input fields from the user to fill up the form.

4. When the form is done, confirm from the user that it it fine, and then submit it.

Ok, nowadays the chatbots are way more versatile, but for some cases the above workflow is still fine. For more complex use cases we can take inspiration from role-playing games and robotics:

Behavior Trees!
https://shorturl.at/bKWY1

With behavior trees you can compose pretty complex discourse processes without the complexity becoming unmagageable. You can easily isolate the specific process parts while having many simultaneous options open for the chatbot.

It's a very powerful architectural pattern which is very relevant in this context. It's a generalization of the old Watson scheme and can easily encode those types of processes as well.

Note also that while the chatbot processes in the past were designed to constrain and guide the user, as the user was the intelligent element making choices and evaluations, now the chatbot is also an intelligent element and makes choices and evaluations as well. So the process gets conditions and triggers from both the user/client and the chatbot, and also from your runner module and your backend systems.

To be clear, the behavior trees are not running on the user or on the bot, they are run on the runner process. They herd both the user and the bot to conclusions of specific procedures.

Why are behavior trees needed, why not just give the bot the information about what is needed and let it run the process?

First of all the prompt size limits. If you describe your process to the bot, it eats your context limits very quickly. Also, the bot tends to improvise, which further makes you add stuff to the prompts to reduce that.

It is much better to feed the process to the bot in pieces only when needed.

Also, when you need for example something machine readable to produce some complex item, and also something human-readable to describe the same, it often makes sense to first tell the bot to describe in human-readable prose what its evaluation or conclusion is, and then separately tell it to produce the same in a machine-readable form. Then you get the two outputs separately which your runner process combines into a conclusion.

That would be a sequential node in a behavior tree executing through the human-readable output first and then the machine-readable output.

All the #AutoGPT style agents and other processes can also be described as behavior trees. Just feed the chatbot think-command step prompts in sequence while separately managing the backend as per commands.

Plug-ins become pluggable #BehaviorTrees, which might be as simple as describing the end point and handling the related commands.

#autogpt #behaviortrees