Using your own data with GPT models in Azure OpenAI - Part 2

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.

dotnet-script 1.5 is out with .NET 8.0 support

This morning, we released version 1.5 of dotnet-script. The latest release introduces support for .NET 8.0 and C# 12 and is available, as usually, through Github releases and on Nuget. You will need to have at least the .NET SDK 8.0.100 installed to take advantage of that feature set.

Using your own data with GPT models in Azure OpenAI - Part 1

There is no question that the emergence of generative AI is going to significantly alter various aspects of our daily lives. At the same time, most of the large language models (LLMs) are designed as general-purpose black boxes and their utility is initially confined to the data they were trained on. However, it is possible to extend their functionality and reasoning to any custom data set, be it private or public, even without the massive effort that would be needed to retrain or even fine-tune them.

We are going to start exploring that concept today with a multi-part post series on “bringing your own data” to Azure OpenAI. In part one today, we will set up the necessary Azure resources and prepare the stage for a client application integration, which will follow in parts two and further.

Accessing private members without reflection in .NET 8.0

One of the cool new features coming in .NET 8.0 is the ability to take advantage of a zero-overhead approach to access private members, via the UnsafeAccessorAttribute. This is a great improvement over the traditional, slow, reflection-based approach, as the new functionality is not only fast (compile-time) but also compatible with Native AOT.

Let’s have a quick look at the feature, which was originally tracked by this Github issue.

dotnet WASI applications in .NET 8.0

At the end of last year I blogged about using .NET 7 and the prototype dotnet WASI SDK from Steve Sanderson to build WASM-WASI applications. That SDK is now deprecated and the WASI workload has instead been integrated into the main .NET 8, which will ship in November this year. The workload is still flagged as experimental, but there is now commitment from the .NET runtime and SDK teams to make the WASM-WASI experience first class in .NET.

In this post we will explore where this workload is at today, and what we can and can’t do with it at this stage.

Using embeddings model with Azure OpenAI Service

I recently blogged about building GPT-powered applications with Azure OpenAI Service. In that post, we looked at using the text-davinci-003 model to provide classification capabilities for natural text - more specifically, we categorized and rated scientific papers based on the interest area (note that the recommended model for this task now is gpt-35-turbo now).

In today’s post we are going to continue exploring Azure OpenAI Service, this time looking at the embeddings model, text-embedding-ada-002.

Announcing Strathweb.Dilithium - a set of ASP.NET helper libraries for post quantum cryptography

Earlier this year I blogged about post-quantum cryptography in .NET using Dilithium and Kyber. This was then followed by another post, which showed how Dilithium can be wired into a popular .NET Identity Server, Duende Identity Server, for token signing purposes.

Today I would like to announce Strathweb.Dilithium, a set of .NET helper libraries to facilitate working with Dilithium in ASP.NET Core projects.

Calling Rust code from Swift on iOS and macOS

In the last post we covered how UniFFI can be used to elegantly create C bindings and generate bridge C# code that allows for calling native code written in Rust from a C# program. Today, we are going to build upon that, and we will show - in a true cross platform fashion - how the same core Rust library we used last time around, and the same toolchain that we have already set up, can be used to generate similar bindings for Swift. This will enable us to reuse our native Rust code in an iOS or macOS application.

Calling Rust code from C#

There are plenty of reasons to be excited about Rust. Rust provides cross-platform compatibility and can compile to nearly any platform, including Windows, iOS, Android, and many more. One of Rust’s core features is its focus on memory safety. It accomplishes this through its ownership model, which helps prevent common bugs such as null pointer dereferencing, dangling pointers, and data races.

All of this makes Rust an excellent alternative to C++/C for implementing shared logic and algorithms, spanning many different platforms.

In this post we shall see how we can integrate Rust into program written in C# - and how a native library built with Rust can be called into from a .NET application.

QIR Runner for ARM64 Macs is now available

In January I blogged about using the QIR Runner as an alternative (or even preferred!) way for simulating your Q# programs locally. The main reason behind that were performance gains (QIR runner is written in Rust), standardization (same intermediate format used as input into the simulator and the quantum hardware) and the complete incompatibility of the default QDK full state simulator with ARM64 processor architecture (even under x64 emulation).

One major limitation of the QIR Runner was that it was also x64 compatible only, but at least still worked well on ARM processors under emulation. This limitation has now been addressed.


Hi! I'm Filip W., a cloud architect from Zürich 🇨🇭. I like Toronto Maple Leafs 🇨🇦, Rancid and quantum computing. Oh, and I love the Lowlands 🏴󠁧󠁢󠁳󠁣󠁴󠁿.

You can find me on Github and on Mastodon.

My Introduction to Quantum Computing with Q# and QDK book
Microsoft MVP