Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python: Introduce the new function calling abstraction, FunctionChoiceBehavior #6910

Merged
merged 41 commits into from
Jun 27, 2024

Conversation

moonbox3
Copy link
Contributor

@moonbox3 moonbox3 commented Jun 22, 2024

Motivation and Context

The current FunctionCallBehavior has allowed us to utilize auto function calling for OpenAI type models. As we proceed to support more AI connectors, that differ from OpenAI models, we need to be able to handle functions for all models that support function calling.

Description

In this PR:

  • We introduce a new function calling abstraction called FunctionChoiceBehavior which has three types: Auto, Required, and None.
  • One is able to configure the function_choice_behavior along with fully qualified function names (e.g., plugin1.function1), maximum_auto_invoke_attempts or auto_invoke_kernel_functions in yaml and JSON prompts. We have a new concept example showing how to do this for for yaml and JSON prompts.
    • If the fully qualified names are specified in the config file, they take precedence over the filters, if specified at a later point.
  • To make sure this isn't a breaking change, we still handle the previous FunctionCallBehavior, but so we can make decisions on the new FunctionChoiceBehavior we map the FunctionCallBehavior to FunctionChoiceBehavior. Each time FunctionCallBehavior is updated, FunctionChoiceBehavior will be updated, too.
    • The _process_tool_call() method in the open_ai_chat_completion_base needs to maintain the argument name as function_call_behavior as we cannot introduce a breaking change.
  • All concept samples have been converted to use FunctionChoiceBehavior.
  • New unit tests have been added for FunctionChoiceBehavior and we still currently support FunctionCallBehavior tests to make sure we haven't broken the backwards compatibility.
  • Added deprecated typing decorators to classes/methods to alert users that it would be best to transition to FunctionChoiceBehavior even though FunctionCallBehavior is still supported.
  • The FunctionCallingStepwisePlanner was updated to use the new FunctionChoiceBehavior.
  • Closes Python: Full support for abstracted function calling content #6496, Python: revisit when function call behavior is finalized, and other function calling models are added #6458
  • Addresses Python - Required Functions do not work correctly #6626

Contribution Checklist

@markwallace-microsoft
Copy link
Member

markwallace-microsoft commented Jun 22, 2024

Py3.10 Test Coverage

Python 3.10 Test Coverage Report •
FileStmtsMissCoverMissing
semantic_kernel
   kernel.py1557254%142, 149–158, 196–204, 275–311, 339, 341–345, 361–405, 409–420
semantic_kernel/connectors/ai
   function_calling_utils.py11373%28–30
   function_choice_behavior.py93496%61, 121–128
   prompt_execution_settings.py50198%46
semantic_kernel/connectors/ai/open_ai/services
   open_ai_chat_completion_base.py1687058%100, 104, 124, 149–153, 178, 186, 188, 192, 210–215, 233–261, 264–275, 290–297, 308–316, 332–339, 360, 368, 374–377, 389–392, 423
semantic_kernel/contents
   function_call_content.py82791%49, 56, 58, 69, 71, 73, 122
semantic_kernel/functions
   kernel_function_from_prompt.py162796%165–166, 187, 207, 232, 252, 335
semantic_kernel/planners/function_calling_stepwise_planner
   function_calling_stepwise_planner.py1164363%133–223, 258–263
TOTAL666876489% 

Python 3.10 Unit Test Overview

Tests Skipped Failures Errors Time
1567 1 💤 0 ❌ 0 🔥 24.536s ⏱️

Copy link
Member

@eavanvalkenburg eavanvalkenburg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

couple of comments, mostly small things, biggest one is wondering if we can simplify the function choice behavior class a bit further?

@moonbox3 moonbox3 enabled auto-merge June 26, 2024 20:52
@moonbox3 moonbox3 disabled auto-merge June 26, 2024 23:38
@moonbox3 moonbox3 removed the request for review from SergeyMenshykh June 27, 2024 01:19
Copy link
Member

@eavanvalkenburg eavanvalkenburg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a bunch of comments...

Copy link
Member

@eavanvalkenburg eavanvalkenburg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some minor comments, overal looks great!

python/semantic_kernel/kernel.py Outdated Show resolved Hide resolved
python/semantic_kernel/kernel.py Outdated Show resolved Hide resolved
…tegration tests for function choice behavior.
Copy link
Member

@eavanvalkenburg eavanvalkenburg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Love it, looks great!

@moonbox3 moonbox3 enabled auto-merge June 27, 2024 20:20
@moonbox3 moonbox3 added this pull request to the merge queue Jun 27, 2024
@moonbox3 moonbox3 removed this pull request from the merge queue due to a manual request Jun 27, 2024
@moonbox3 moonbox3 added this pull request to the merge queue Jun 27, 2024
Merged via the queue into microsoft:main with commit 8381e50 Jun 27, 2024
23 checks passed
@moonbox3 moonbox3 deleted the func_calling_abstraction branch June 27, 2024 20:53
@moonbox3 moonbox3 linked an issue Jul 3, 2024 that may be closed by this pull request
LudoCorporateShark pushed a commit to LudoCorporateShark/semantic-kernel that referenced this pull request Aug 25, 2024
…eBehavior (microsoft#6910)

### Motivation and Context

The current `FunctionCallBehavior` has allowed us to utilize auto
function calling for OpenAI type models. As we proceed to support more
AI connectors, that differ from OpenAI models, we need to be able to
handle functions for all models that support function calling.

<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
  1. Why is this change required?
  2. What problem does it solve?
  3. What scenario does it contribute to?
  4. If it fixes an open issue, please link to the issue here.
-->

### Description

In this PR:
- We introduce a new function calling abstraction called
`FunctionChoiceBehavior` which has three types: Auto, Required, and
None.
- One is able to configure the `function_choice_behavior` along with
fully qualified function names (e.g., plugin1.function1),
`maximum_auto_invoke_attempts` or `auto_invoke_kernel_functions` in yaml
and JSON prompts. We have a new concept example showing how to do this
for for yaml and JSON prompts.
- If the fully qualified names are specified in the config file, they
take precedence over the filters, if specified at a later point.
- To make sure this isn't a breaking change, we still handle the
previous `FunctionCallBehavior`, but so we can make decisions on the new
`FunctionChoiceBehavior` we map the `FunctionCallBehavior` to
`FunctionChoiceBehavior`. Each time `FunctionCallBehavior` is updated,
`FunctionChoiceBehavior` will be updated, too.
- The `_process_tool_call()` method in the
`open_ai_chat_completion_base` needs to maintain the argument name as
`function_call_behavior` as we cannot introduce a breaking change.
- All concept samples have been converted to use
`FunctionChoiceBehavior`.
- New unit tests have been added for `FunctionChoiceBehavior` and we
still currently support `FunctionCallBehavior` tests to make sure we
haven't broken the backwards compatibility.
- Added `deprecated` typing decorators to classes/methods to alert users
that it would be best to transition to `FunctionChoiceBehavior` even
though `FunctionCallBehavior` is still supported.
- The `FunctionCallingStepwisePlanner` was updated to use the new
`FunctionChoiceBehavior`.
- Closes microsoft#6496, microsoft#6458
- Addresses microsoft#6626 

<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->

### Contribution Checklist

<!-- Before submitting this PR, please make sure: -->

- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
python Pull requests for the Python Semantic Kernel
Projects
Archived in project
6 participants