-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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: OpenAPI plugins don't correctly create kernel functions #6261
Comments
markwallace-microsoft
added
python
Pull requests for the Python Semantic Kernel
triage
labels
May 15, 2024
github-merge-queue bot
pushed a commit
that referenced
this issue
May 16, 2024
### Motivation and Context Python's OpenAPI manager `run_openapi_operation` was hard-coded to use certain parameters that would ultimately be built up to make an API request. This didn't allow the model to know which parameters were actually defined as required in the OpenAPI spec and would cause errors during 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 This PR does a quite major overhaul on the openapi manager, with the caveat that the code is going to be refactored / cleaned up in a next iteration (we're pressed for time right now). In the `_create_function_from_operation` method, the `rest_operation_params` are now built up from the operation which means we included the required parameters and will have them during function calling. This allows us to properly build up the url, headers, request body and paths to make the API call. - The concept samples were updated and are functioning with this latest code. - function calling was tested with the AzureKeyVault OpenAPI example and the model was able to automatically create a secret in a test key vault. - Old unit tests were removed. Note: in the next iteration new unit tests for all of the new functionality will be added. - In the next iteration, the entire `openapi_manager.py` file will be broken apart to separate files for classes/moels to clean it up. - Closes #6261 <!-- 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 - [ ] I didn't break anyone 😄
bochris
pushed a commit
to bochris/semantic-kernel
that referenced
this issue
May 16, 2024
### Motivation and Context Python's OpenAPI manager `run_openapi_operation` was hard-coded to use certain parameters that would ultimately be built up to make an API request. This didn't allow the model to know which parameters were actually defined as required in the OpenAPI spec and would cause errors during 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 This PR does a quite major overhaul on the openapi manager, with the caveat that the code is going to be refactored / cleaned up in a next iteration (we're pressed for time right now). In the `_create_function_from_operation` method, the `rest_operation_params` are now built up from the operation which means we included the required parameters and will have them during function calling. This allows us to properly build up the url, headers, request body and paths to make the API call. - The concept samples were updated and are functioning with this latest code. - function calling was tested with the AzureKeyVault OpenAPI example and the model was able to automatically create a secret in a test key vault. - Old unit tests were removed. Note: in the next iteration new unit tests for all of the new functionality will be added. - In the next iteration, the entire `openapi_manager.py` file will be broken apart to separate files for classes/moels to clean it up. - Closes microsoft#6261 <!-- 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 - [ ] I didn't break anyone 😄
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When importing an OpenAPI schema, the kernel functions that are created just have the following inputs:
Because of this, we aren't describing to the model the actual parameters that are required by the operation.
For example, the following parameters are not described to the LLM as part of the tool call in my sample's OpenAPI spec:
The text was updated successfully, but these errors were encountered: