On this episode: Stack Overflow senior data scientist Michael Geden tells Ryan and Ben about how data scientists evaluate large language models (LLMs) and their output. They cover the challenges involved in evaluating LLMs, how LLMs are being used to evaluate other LLMs, the importance of data validating, the need for human raters, and more needs and tradeoffs involved in selecting and fine-tuning LLMs.

---

The article discusses best practices for checking strings for null in coding. It outlines three common methods: using == null, is null, or string.IsNullOrEmpty().

In this article, we’ll get familiar with GraphQL and Strawberry Shake, a GraphQL tool that facilitates interaction with local and remote data. Subsequently, we will build an application using the .NET API, focusing on customers searching for available space in shipping containers using GraphQL. This article will not delve deeply into server-side implementation since we have […]

The post Introduction to Strawberry Shake and GraphQL in .NET appeared first on Code Maze.

Information

• Streamline your container build and publish with .NET 8 – Richard Lander
• The New C# Interceptors vs. AOP – Marek Sirkovský
• Computing code coverage for a .NET project – Gérald Barré
• A Clever Way To Implement Pessimistic Locking in EF Core – Milan Jovanovic
• Configure Renovate to update preview versions of NuGet packages – Anthony Simmon
• Implement a secure Blazor Web application using OpenID Connect and security headers – Damien Bowden
• Modular Monoliths and the “Critter Stack” – Jeremy D Miller
• Services share schema and contract, not class – Mark Seemann
• Data Anomaly Detection Using a Neural Autoencoder with C# – James McCaffrey
• How to build an in-memory Message Bus in TypeScript – Oskar Dudycz
• Snake draft sorting in SQL Server, part 2 – Aaron Bertrand

I hit a ceiling with my Artisanal APIs.json API profiling, in that I am pushing over a thousand individual APIs. It reminds me of running conferences, and once you get over 500 people, everything begins to change. I only have a little over 100 API providers, but when some API providers have 100+ individual APIs, it adds up very quickly. When you are working to properly profile APIs using OpenAPI and the operations around them with APIs.json, then augment with searching, ratings, and other overlays, it becomes a lot to deal with. But it really isn’t just the volume of data, it is about the cognitive load involved with working with so many different types of APIs at once–the context switching begins to kill ya. To help me make things more manageable I broke my Artisanal APIs.json work into what I am calling search nodes. I started with 12 individual topics, breaking down the top 25 API providers I have in the Artisanal index. It is just a start. I’ll dump more in there now that I have it all set up. But it is already more manageable to have things broken up into nodes. There is something about having things broken down into manageable and more meaningful chunks that changes the rules of the game. The scripts I run to automate things run faster. I feel less overwhelmed when I am working in the middle of the search index. We’ll see how it all plays out with the next couple of rounds of work, but I am feeling like I can more comfortably scale this all in a federated way. Once I got the APIs.json broken up into 12 separate repositories I needed a way to search across each of these nodes. To do this I wrote a simple starter search script, I just needed a way to spider the YAML in each repository. Each search node is defined using APIs.json, with individual APIs.json for each API provider, as well as a single central apis.json for each node index. I just needed what I am calling a network node with a single APIs.json that provides me with an index of the 12 individual topical search nodes-—with more coming soon. The search is janky as hell, but it works. I don’t want to overthink it and just get the bare minimum of what I need to prove that I can do this. I’ll harden the search over time. This is just a simple network search. I aim to index all my nodes using a database and provide a richer and faster API-driven search. I have things federated, and I have my automation in place to find and process new APIs that I want to profile. I have a new incubator repository setup where I am taking in any new APIs, but before it can graduate to one of the search nodes it has to have an OpenAPI. This is the line I’ve drawn between API intake and APIs that I...