Last time around, we discussed how Large Language Models can select the appropriate tool and its required parameters out of freely flowing conversation text. We also introduced the formal concept of those tools, which are structurally described using an OpenAPI schema.

In this part 2 of the series, we are going to build two different .NET command line assistant applications, both taking advantage of the tool calling integration. We will orchestrate everything by hand - that is, we will only use the Azure OpenAI Service API directly (or rather using the .NET SDK for Azure OpenAI) - without any additional AI frameworks.

One of the fantastic capabilities of the Large Language Models is their ability to choose (based on a predefined set of tool definitions) the appropriate tool and its required parameters out of freely flowing conversation text. With that, they can act as facilitators of workflow orchestration, where they would instruct applications to invoke specific tools, with specific set of arguments.

OpenAI announced the built-in capability called function calling in the summer of last year, and by now it is an integral part of working with and building applications on top of the GPT models. The functionality was later renamed in the API to “tools”, to better express their broad scope and nature.

Today I am starting a new multi-post Azure OpenAI blog series focusing specifically on the tool capabilities. We will build a client application with .NET, and explore tool integration from different angles - using the Azure OpenAI .NET SDK directly, using the Assistants SDK and finally leveraging various orchestration frameworks such as Semantic Kernel and AutoGen. In today’s part one, we are going to introduce the basic concepts behind tool calling.

In my recent posts, I’ve been exploring various facets of the Azure OpenAI Service, discussing how it can power up our applications with AI. Today, I’m taking a slightly different angle - I want to dive into how we can enhance our projects further by integrating Azure OpenAI Service with Azure AI Speech. Let’s explore what this integration means and how it could lead to exciting, AI-powered applications.

For our Retrieval-Augmented-Generation (RAG) application, we setup AI Search in part 1, however so far we only used it using the basic keyword search.

In this part 4 of the series about bringing your own data to Azure OpenAI Service, we will go ahead and integrate vector search, as a more sophisticated way of performing the search across the Azure AI Search index within our RAG-pattern system.

I already covered vectorization and embeddings using the OpenAI embedding model on this blog, and we will be relying on the same principles here. I recommend reading through that article before continuing if you are not yet familiar with the concept of embeddings.

It is a common scenario to use Azure DevOps to build, sign and release iOS applications. Most of the tasks related to that can be handled by the Xcode@5 task, which provides support for all kinds of build activities around Xcode workspaces, and which is a de-facto shortcut for invoking xcodebuild command line tool.

The task is quite well documented, but it is not entirely obvious how to use it for building Swift Packages, as those come without Xcode workspaces. In this post we will quickly explore how to achieve that.

As you may know from the announcement on this blog (or from the image in the sidebar…), I wrote a quantum computing book titled “Introduction to Quantum Computing with Q# and QDK” which was published by Springer in May 2022. The source code samples used in the book were written against version 0.21.2112180703 of the QDK and the Q# language, which had been released on 14th December 2021. The code also works fine with all the newer versions of QDK lower than 1.0 - the last pre-1.0 release being 0.28.302812, from 15 September 2023.

Earlier this month, Microsoft announced the release of QDK 1.0, which brings in a big overhaul of the entire QDK ecosystem, as well as the Q# language itself. As a consequence, it also contains numerous breaking changes and feature gaps in the libraries and in the language itself.

As part of my commitment to keeping the samples used in the book up-to-date, I would like to share the updated samples.

In the last post of this series we set up a demo .NET client application that was able to call and utilize a GPT model hosted in Azure OpenAI Service, which in turn was integrated with our own custom data via Azure AI Search. We did this using the bare bones REST API - and in part three, it’s time to shift gears and explore how to accomplish similar task using the .NET SDK, which offers a more streamlined and less ceremonious approach over calling the HTTP endpoints directly.

For the last few years (2022, 2021 and 2020), around this time of the year, I published a special festive Q# blog post as part of the Q# Holiday Calendar, organized by Mariia Mykhailova from Microsoft Quantum . While this year there is unfortunately no “official” Q# calendar initiative, I would like to keep the 🎄 holiday spirit alive and prepared a special Q# blog post for this occasion.

Today, we are going to have a look at quantum certified deletion, with examples in Q#.

The Q# standard library is equipped with an extensive collection of array functions, meeting a wide array of algorithmic requirements. It further includes a variety of functions, types, and operations beneficial for generating random values and handling different probability distributions.

However, a somewhat notable omission is the lack of a built-in feature for shuffling or randomizing an existing array. In this blog post, we will build a straightforward helper operation to bridge this functional gap.

In the previous part of this series, we have successfully set up Azure AI Search, to have it ready for integration with Azure OpenAI Service. The ultimate goal is to take advantage of the retrieval-augmented-generation pattern, and enhancing our interactions with the GPT model with our own custom data.

Let’s continue building this today.