{"componentChunkName":"component---src-templates-post-js","path":"/blog/2024/05/13/semantic-kernel-plugins/","result":{"data":{"post":{"html":"

In my previous post, I introduced you to foundational concepts of Semantic Kernel, offering a glimpse into its potential. Now, when I was learning about the what and the why, that wasn’t enough for me to fully understand the concepts and that’s why I started writing these series.

\n\n

Semantic Kernel Series:

\n

✔️ Part one: Intro\r\n
\r\n✔️ Part two: Plugins\r\n
\r\n✔️ Part three: Planners and Native Function plugins

\n

You can find the code on my GitHub repository here.

\n

In order for us to learn about the concepts, the best way is with a story, and I chose DevOps because I was interested in finding better ways to automate daily tasks in that space for my course. Let’s go through the context and see what we’re trying to achieve.

\n

Context

\n

I want to use Semantic Kernel to generate Azure DevOps pipelines/GitHub Actions workflow for my application with simple and details instructions (aka prompts). Now the application might have multiple tiers and each might have dependency with one another and I wanted to see how this will work out.

\n

The first thing we need after we have our starter project (use my previous post to create yours), is to define our prompts. I want to use plugins at this point since it is very easy with them to get my prompts introduced to the kernel and execute them based on different inputs.

\n

Setup

\n

Here is what we need to get the whole setup working:

\n\n

Prompts

\n

As I mentioned we would use plugins and their functions to be able to get our input passed to our Azure OpenAI service via the kernel. Technically we could add these as inline code and it works perfectly, however, that would mean we have to define these one by one and it just blows our code base. A much better way is to use the built in feature of the kernel which allows us to load multiple plugins with their functions from a directory.

\n

All you need is a folder which contains all your plugins, and for each plugin, a subdirectory per function. Every function which is mapped to our prompts will need two files:

\n\n

Plugin setup

\n

Let’s set our plugin and its function up. As mentioned we intend to generate either an Azure DevOps Pipeline, or GitHub Actions workflow, so one plugin and two function will do the job. Our directory structure will look like this:

\n

\n \n \n \n \n

\n

DevOps is the name of our plugin, and AzDevOps and GitHubActions are our function names.

\n

Prompt text

\n

You can write your prompts however you like, just make sure you follow the principles of prompt engineering which in short is all about the details and be as specific as you can.

\n

Here is how mine looks like for GitHub Actions:

\n\n \n Copy\n \n \n
INSTRUCTIONS:\r\n\r\nGenerate workflow YAML files to deploy an application to Azure from GitHub Actions.\r\n\r\nRULES:\r\n\r\n- All YAML files must be complete\r\n- YAML files must be listed one by one\r\n- Every file is indicated with \"FILE:\" followed by it's path\r\n- Every file content must begin and end with #-----#\r\n- All pipelines should use either GitHub hosted runners with latest ubuntu version.\r\n- All YAML files should contain two stages for build and deploy where deploy depends on build\r\n\r\nDESCRIPTION:{{$input}}
\n

The details of how the workflow is going to be generated is outlined in details and at the end I have left a placeholder for a variable called $input which will be passed by the user to the kernel later.

\n

And here is what the config.json looks like for this prompt:

\n\n \n Copy\n \n \n
{\r\n  \"schema\": 1,\r\n  \"description\": \"Create pipeline YAML files for GitHub Actions\",\r\n  \"type\": \"completion\",\r\n  \"completion\": {\r\n    \"max_tokens\": 1000,\r\n    \"temperature\": 0.5,\r\n    \"top_p\": 0,\r\n    \"presence_penalty\": 0,\r\n    \"frequency_penalty\": 0\r\n  },\r\n  \"input\": {\r\n    \"parameters\": [\r\n      {\r\n        \"name\": \"input\",\r\n        \"description\": \"The description of the deployment to be be created\",\r\n        \"defaultValue\": \"\"\r\n      }\r\n    ]\r\n  }\r\n}
\n

You don’t need to know the details of the parameters for now, all that is important is the definition of the input parameter and the fact that we intend to use the completion feature of Azure OpenAI.

\n

Input

\n

For our inputs, I also would like to use files, but you don’t have to follow this convention, this just keeps the code clean and short so it’s more understandable for me and other beginners learning the concepts.

\n

I have created a folder called desc which includes two files one for an application written with .Net 8 and one for a node based application.

\n

Here is the content of the node based input file:

\n\n \n Copy\n \n \n
This is an application written in NodeJs and has below components:\r\n\r\n- A front end app which is written in React and uses create-react-app starter. This will be hosted in an Azure Static Web App and is stored in the `frontend` directory.\r\n- A backend API which is going to be hosted in an Azure Function as the backend for the static web app in the `api` directory.\r\n- The API uses a Cosmos DB database as its datastore.
\n

Setting up the kernel

\n

In order to setup the kernel we need a few things:

\n
    \n
  • The information about the Azure OpenAI service like endpoint, key and model number.
    • \n
  • A way for the user to specify which input and prompt to use.
    • \n
  • Setting up the kernel so it knows about our Azure OpenAI service and our plugin directory.
    • \n
  • Calling the kernel and getting the result.
    • \n
\n

We already covered how to setup the Azure OpenAI part with the kernel in our first post, here I just show you how to load the plugins from the directory:

\n();\r\n\r\n// loading the plugins from the plugin directory\r\nvar skillImport = kernel.ImportPluginFromPromptDirectory(pluginDirectories!);\r\n\r\n// read user's task description from given file\r\nstring description = await File.ReadAllTextAsync(file.FullName!);\r\n\r\n// this is a data structure that holds temporary data while the kernel task runs\r\nvar context = new KernelArguments();\r\n\r\n// associate user's description with "input" variable\r\nstring key = "input";\r\ncontext.Add(key, description);\r\n\r\n// call the kernel and tell it which plugin function to call and pass to the LLM\r\nvar result = await kernel.InvokeAsync(skillImport[function], context);\r\nConsole.WriteLine(result.GetValue());`, `2496903402599359500`)\"\n >\n \n Copy\n \n \n
//reading the name of the plugin directory from our configuration\r\nvar pluginDirectories = Configuration!.GetSection(\"PluginSettings:Root\").Get<string>();\r\n\r\n// loading the plugins from the plugin directory\r\nvar skillImport = kernel.ImportPluginFromPromptDirectory(pluginDirectories!);\r\n\r\n// read user's task description from given file\r\nstring description = await File.ReadAllTextAsync(file.FullName!);\r\n\r\n// this is a data structure that holds temporary data while the kernel task runs\r\nvar context = new KernelArguments();\r\n\r\n// associate user's description with \"input\" variable\r\nstring key = \"input\";\r\ncontext.Add(key, description);\r\n\r\n// call the kernel and tell it which plugin function to call and pass to the LLM\r\nvar result = await kernel.InvokeAsync(skillImport[function], context);\r\nConsole.WriteLine(result.GetValue<string>());
\n

Output

\n

You can find the full code for this post here. Simply clone the code, build and run it passing the required information like so:

\n\n \n Copy\n \n \n
git clone https://github.com/yashints/semantic-kernel-devops.git\r\n\r\ncd semantic-kernel-devops\r\n\r\ndotnet restore\r\n\r\ndotnet build\r\n\r\ndotnet run -- -i .\\desc\\dotnet.txt -f GitHubActions
\n

I am passing the .Net application prompt and tell the kernel to create a GitHub Actions workflow.

\n

The result will look like this:

\n\n \n Copy\n \n \n
FILE: .github/workflows/dotnet.yml\r\n#-----#\r\nname: Build and Deploy\r\n\r\non:\r\n  push:\r\n    branches:\r\n      - master\r\n\r\njobs:\r\n  build:\r\n    name: Build\r\n    runs-on: ubuntu-latest\r\n    strategy:\r\n      matrix:\r\n        dotnet-version: ['8.x']\r\n        \r\n    steps:\r\n    - name: Checkout code\r\n      uses: actions/checkout@v2\r\n      \r\n    - name: Setup .NET Core\r\n      uses: actions/setup-dotnet@v1\r\n      with:\r\n        dotnet-version: ${{ matrix.dotnet-version }}\r\n\r\n    - name: Restore dependencies\r\n      run: dotnet restore\r\n      \r\n    - name: Build\r\n      run: dotnet build --configuration Release --no-restore\r\n      \r\n    - name: Test\r\n      run: dotnet test --no-restore --verbosity normal\r\n\r\n  deploy:\r\n    needs: build\r\n    runs-on: ubuntu-latest\r\n    steps:\r\n    - name: Login via Az module\r\n      uses: azure/login@v1\r\n      with:\r\n        creds: ${{ secrets.AZURE_CREDENTIALS }}\r\n\r\n    - name: 'Run Azure Functions Action'\r\n      uses: Azure/functions-action@v1\r\n      id: fa\r\n      with:\r\n        app-name: 'myFunctionApp'\r\n        package: 'api'\r\n        publish-profile: ${{ secrets.AZURE_FUNCTIONAPP_PUBLISH_PROFILE }}\r\n\r\n    - name: 'Deploy to Azure Web App'\r\n      uses: azure/webapps-deploy@v2\r\n      with:\r\n        app-name: 'myWebApp'\r\n        package: 'frontend'\r\n        publish-profile: ${{ secrets.AZURE_WEBAPP_PUBLISH_PROFILE }}\r\n#-----#
\n

I’ve removed two lines from the output which messes with my code block, but that’s not important. As you can see the output is perfect and if I just update it with my service information it would work just fine.

\n
Note: You need to update the appsettings.json or add a development version and update it with your service information to get the full code working. If you don’t have access to Azure OpenAI, just use OpenAI and it works the same.
\n

What next?

\n

So far we have created our prompts, dynamically loaded them as plugins and functions and then called our kernel passing the input to be passed to our LLM. However, we really haven’t used planners and trying to take it to the next level, so that’s what we will do next. If you liked this post, please share and spread the word too.

","timeToRead":6,"frontmatter":{"unformattedDate":"2024-05-13T00:00:00.000Z","date":"May 13, 2024","title":"Semantic kernel series - Part two - Plugins","subtitle":null,"id":null,"author":"Yaser Adel Mehraban","gravatar":null,"canonical_url":null,"tags":["semantickernel","AI","OpenAi","plugins"],"thumbnail":{"childImageSharp":{"gatsbyImageData":{"layout":"constrained","placeholder":{"fallback":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAYAAAB/Ca1DAAAACXBIWXMAABYlAAAWJQFJUiTwAAACJElEQVR42mWSS28TMRSF81/5B6yQWCFA7NiwQEgtCKWsEooCNCgpoVmkNI8mbRXoCwV1ans843lkyERK85gcfG+VopaRrLE919+ce3xyuPOkaYowDBEPY8RxzHOpJA8hJYIw4G+0H4URvyeTyc353F2gMQZKKsgLCS01PM/D2ckZ+kd9nJ/9grgQvE+gIAjgOA6SJLkNXCwWmM1mmM/mUEohHacYNAcoPC5gZ20HnWIHxSdF1NfraBVaeP+0iN38LtJhiktxyfD5fI4sy66BBFsulzx83+eC4+/HqL6uollqovtlH9/ebqP9qYVOuYPqmyp6lR5i27KQghWSKILmMgtJrKLJdMqS2TMh4bougiiACX1oo6FjAy+yc1/bPQMTGbjahbS+jkYjTO158jK35/zGo3oFL9sNXFmlURTZC1BcLKyXoaew/UPjXinEqz0fgbb+2n2yhn4qhOAOa7UayuUycvLPEFsnfRA4W2ascFVMYN9VaP908XzLx+e2vSS7luIfkBSOx2M+NxgMbnt407ItouEFHszQxiQxSCKJOLI2xAG3TMBVHbVMF8IeEuTK9k8LglJMqG163FMXnVIHzQ8tHHw9Qq96gH27PiwfInRCrqGIUV5XSWEggWhBg/68ikH3Yxf5B3lsPHyHxkYDlRcVrN1fx+azTahTxUDKIWWXFBLnv2BTBMgb3/h8y1pruMplJZ7vXftmUyAcwd3Qd/JwFey/m20pUEgeM6QAAAAASUVORK5CYII="},"backgroundColor":"transparent","images":{"fallback":{"src":"/static/5d276e3388107f4c25e22e895f6d8490/97211/sk.png","srcSet":"/static/5d276e3388107f4c25e22e895f6d8490/6aa3c/sk.png 750w,\n/static/5d276e3388107f4c25e22e895f6d8490/f9352/sk.png 1080w,\n/static/5d276e3388107f4c25e22e895f6d8490/91ff4/sk.png 1366w,\n/static/5d276e3388107f4c25e22e895f6d8490/97211/sk.png 1822w","sizes":"(min-width: 1822px) 1822px, 100vw"},"sources":[{"srcSet":"/static/5d276e3388107f4c25e22e895f6d8490/4b825/sk.webp 750w,\n/static/5d276e3388107f4c25e22e895f6d8490/8989a/sk.webp 1080w,\n/static/5d276e3388107f4c25e22e895f6d8490/b35cf/sk.webp 1366w,\n/static/5d276e3388107f4c25e22e895f6d8490/e992f/sk.webp 1822w","type":"image/webp","sizes":"(min-width: 1822px) 1822px, 100vw"}]},"width":1822,"height":1029}}},"cover":{"childImageSharp":{"gatsbyImageData":{"layout":"constrained","placeholder":{"fallback":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAKCAIAAAA7N+mxAAAACXBIWXMAAAsTAAALEwEAmpwYAAAB6ElEQVR42h2NyY7TQBRF/c9I/ARLVrBgwwq2oB5QNxLdwXZiO24nHTzPLs9V5aE8Jo4ot3R0dfSe7nvMwUdaSvS8M/Leg0OIxxANFH9ldMsBVGNSj3E9UcmaGdRTgAeABi9vGCluDDi9BEgJsRIiFWAra4xkTQ1gu+j1uHYK4mR1jAc3rcx11Zb9NUIDw4JaSrs74XTHK7es8ij8e5L138LxWTEftgfFybiDxR6tx91BdlJWMW6ethtFT9rFL3uGiyqpGBR41tHFrS5+cwnaBXTXsF1icg2bJWivEVlCcnXoiizUfbIY6KymhOFAJWW94FWCg+WgOcWdWYwunv3qHDUXWnbwvIImG00WnFw0GXDU4PyatAxnF5JTCSaSvFryW8reb49hS0/YcKaY5azDWcezhtZcpZx0NB8T+lnLZBe/OFCwMWvkrJ5xRin4LUVcIWJARNCJ+bhH8w7Mf51pn40nSMstw9tY2PCH+x+8lt7y6k/29Et29/GwNkMiRmTNkAhBK+f91++Xd+/Pm4AemgTQMKJX3Txwnz5+3lrlzoFbF239SgK9FBIpeoMK/Qy6l7T7dj9++DLvklEuRs7FzOY1YvXij5rzVsmZBWdDzkW8kfFawuspr9LMOGcdUnZeIUZvbqNnNf0PLeoPWB7eedUAAAAASUVORK5CYII="},"backgroundColor":"transparent","images":{"fallback":{"src":"/static/9dd7e334f99df27d871a581fa1226847/a2195/socialpreview.png","srcSet":"/static/9dd7e334f99df27d871a581fa1226847/cadb4/socialpreview.png 750w,\n/static/9dd7e334f99df27d871a581fa1226847/a2195/socialpreview.png 800w","sizes":"(min-width: 800px) 800px, 100vw"},"sources":[{"srcSet":"/static/9dd7e334f99df27d871a581fa1226847/11ba1/socialpreview.webp 750w,\n/static/9dd7e334f99df27d871a581fa1226847/5f042/socialpreview.webp 800w","type":"image/webp","sizes":"(min-width: 800px) 800px, 100vw"}]},"width":800,"height":400}}},"img":{"publicURL":"/static/5d276e3388107f4c25e22e895f6d8490/sk.png"},"socialPreview":{"publicURL":"/static/9dd7e334f99df27d871a581fa1226847/socialpreview.png"}}}},"pageContext":{"title":"Semantic kernel series - Part two - Plugins","postPath":"/blog/2024/05/13/semantic-kernel-plugins","nextPost":"/blog/2024/05/27/semantic-kernel-planners","previousPost":"/blog/2024/04/30/semantic-kernel"}},"staticQueryHashes":[],"slicesMap":{}}