Replies: 2 comments
-
Thans for sharing! We've begun to realize similar behaviors on our side. Having a simpler scripting language for the LLM to produce yields better results and you can do more complex things (like loops, complex object support, and more). To this end, we're working on a PR to support a planner that uses Handlebars under-the-covers: #3428 |
Beta Was this translation helpful? Give feedback.
0 replies
-
@joe-chiu - check out the new planner updates - https://devblogs.microsoft.com/semantic-kernel/migrating-from-the-sequential-and-stepwise-planners-to-the-new-handlebars-and-stepwise-planner/ |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
When I first saw Semantic Kernel, I was particularly interested in its planner idea to use LLM to compose available functions on its own to achieve a given goal. I was so excited about the idea that as a learning exercise, I implemented a small project doing the same, so I could compare note with Semantic Kernel source later to see how our implementations differ.
I found that the LLM was very good at picking function to use as expected. The challenge is more about how to wire these functions together. The planners from SK (Action / Sequential) each has its own JSON or XML steps specifications that it demands a lot of prompt tokens to explain to the LLM, and I felt that a lot "brain power" of the LLM is spent on following the rather intricate format. It also presents a bigger challenge for lesser / smaller open source models to follow these very complex prompts from the planners.
In my implementation, I gravitated towards a simple script-like language for the planner to express its plan.
I found that it has much less unnecessary syntactical complexity comparing to XML or JSON, and it's perhaps more expressive yet easier to read. I then wrote a simple interpreter to run this script to execute the plan. For example, below is a short example of the code that the planner emitted. The data and execution flow between functions are easy to see and follow and the print() statement allows for all steps to build towards the final output - in this case, building towards a longer story with illustrations. My theory is that this would be easier for other LLM like Llama2 to follow but I am yet to test the theory.
Just sharing the idea for you to consider for Semantic Kernel planners. You can see the code in my repo.
https://github.com/joe-chiu/LlmPlanningDemo/blob/main/README.md
Beta Was this translation helpful? Give feedback.
All reactions