Florian Bernd - Elasticsearch Labs

LINQ to Elasticsearch ES|QL: C# schreiben, Elasticsearch abfragen

Florian Bernd,Martijn Laarman — Wed, 01 Apr 2026 00:00:00 GMT

Ab v9.3.4 und v8.19.18 enthält der Elasticsearch .NET-Client einen Language Integrated Query (LINQ)-Provider, der C# LINQ-Ausdrücke in die Elasticsearch Query Language (ES|QL)-Abfragen zur Laufzeit übersetzt. Anstatt ES|QL-Zeichenfolgen von Hand zu schreiben, stellen Sie Abfragen mit Where, Select, OrderBy, GroupBy und anderen Standardoperatoren zusammen. Der Anbieter kümmert sich um die Übersetzung, Parametrisierung und Deserialisierung der Ergebnisse, einschließlich des zeilenweisen Streamings, das die Speichernutzung unabhängig von der Größe der Ergebnismenge konstant hält.

Ihre erste Abfrage

Definieren Sie zunächst ein einfaches altes CLR-Objekt (POCO), das auf Ihren Elasticsearch-Index abgebildet wird. Eigenschaftsnamen werden über Standardattribute System.Text.Json , wie z. B. [JsonPropertyName], oder über ein konfiguriertes JsonNamingPolicy in ES|QL-Spaltennamen aufgelöst. Die gleichen Regeln für die Quellenserialisierung, die für den Rest des Clients gelten, gelten auch hier.

using System.Text.Json.Serialization; public class Product { [JsonPropertyName("product_id")] public string Id { get; set; } public string Name { get; set; } public string Brand { get; set; } [JsonPropertyName("price_usd")] public double Price { get; set; } [JsonPropertyName("in_stock")] public bool InStock { get; set; } }

Nachdem der Typ festgelegt wurde, sieht eine Abfrage folgendermaßen aus:

Der Anbieter übersetzt dies in folgende ES|QL:

Ein paar Details, die zu beachten sind:

Namensauflösung der Eigenschaften: p.Price wird aufgrund des Attributs [JsonPropertyName] zu price_usd , und p.Brand wird gemäß der Standard-CamelCase-Namenskonvention zu brand .
Parametererfassung: Die C#-Variablen minPrice und brand werden als benannte Parameter erfasst (?minPrice, ?brand). Sie werden separat von der Abfragezeichenfolge im JSON-Payload gesendet, was Injektionen verhindert und serverseitiges Abfrageplan-Caching ermöglicht.
Streaming: QueryAsync gibtIAsyncEnumerable zurück. Zeilen werden einzeln materialisiert, sobald sie von Elasticsearch eintreffen.

Sie können auch die generierte Abfrage und ihre Parameter inspizieren, ohne sie auszuführen:

var query = client.Esql.CreateQuery() .Where(p => p.InStock && p.Price >= minPrice && p.Brand == brand) .OrderByDescending(p => p.Price) .Take(10); Console.WriteLine(query.ToEsqlString()); // FROM products | WHERE (in_stock == true AND price_usd >= 100) | SORT price_usd DESC | LIMIT 10 Console.WriteLine(query.ToEsqlString(inlineParameters: false)); // FROM products | WHERE (in_stock == true AND price_usd >= ?minPrice AND brand == ?brand) | SORT price_usd DESC | LIMIT 10 var parameters = query.GetParameters(); // { "minPrice": 100.0, "brand": "TechCorp" }

Wie funktioniert das? Eine kurze LINQ-Auffrischung

Der Mechanismus, der LINQ-Anbieter ermöglicht, ist die Unterscheidung zwischen IEnumerable und IQueryable.

Wenn Sie.Where(p => p.Price > 100) auf einem IEnumerableaufrufen, kompiliert die Lambda zu einem Func, einem regulären Delegierten, den die Laufzeit während des Prozesses ausführt. Dies ist LINQ-to-Objects.

Wenn Sie dieselbe Methode auf einem IQueryableaufrufen, umwickelt der C#-Compiler stattdessen das Lambda in einem Expression> . Dies ist eine Datenstruktur, die die Struktur des Codes repräsentiert und nicht seine ausführbare Form. Der Ausdrucksbaum kann zur Laufzeit inspiziert, analysiert und in eine andere Sprache übersetzt werden.

// IEnumerable: the lambda is a compiled delegate IEnumerable local = products.Where(p => p.Price > 100); // IQueryable: the lambda is an expression tree, a data structure IQueryable remote = queryable.Where(p => p.Price > 100);

Die IQueryProvider Schnittstelle ist der Erweiterungspunkt. Jeder Anbieter kann CreateQuery und Execute implementieren, um diese Ausdrucksbäume in eine Zielsprache zu übersetzen. Entity Framework verwendet dies, um SQL auszugeben. Der LINQ to ES|QL-Anbieter verwendet es, um ES|QL zu emittieren.

Der Ausdrucksbaum für die obige Abfrage sieht wie folgt aus:

Ausdrucksbaum für die Beispielabfrage.

Der Baum ist von innen nach außen verschachtelt: Take umschließt OrderByDescending, welches Where umschließt, welches From umschließt, welches die Wurzel EsqlQueryable Konstante umschließt. Das Where -Prädikat ist selbst ein Teilbaum von BinaryExpression Knoten für die Operatoren &&, >=, und == , mit MemberExpression Blättern für Eigenschaften-Zugriffe und Abschluss-Erfassungen für die Variablen minPrice und brand . Dies ist die Datenstruktur, die der Provider durchläuft, um das endgültige ES|QL zu erzeugen.

Unter der Haube: Die Übersetzungspipeline

Der Weg von einem LINQ-Ausdruck zu den Abfrageergebnissen folgt einer sechsstufigen Pipeline:

Überblick über die Übersetzungspipeline.

1. Erfassung des Ausdrucksbaums

Wenn man .Where(), .OrderBy(), .Take() und andere Operatoren auf einem IQueryable verkettet, erstellt die Standard-LINQ-Infrastruktur einen Ausdrucksbaum. EsqlQueryable implementiert IQueryable und delegiert an EsqlQueryProvider.

2. Übersetzung

Wenn die Abfrage ausgeführt wird (durch Enumerieren, Aufrufen von ToList() oder Verwenden von await foreach)), durchläuft EsqlExpressionVisitor den Ausdrucksbaum von innen nach außen. Es sendet jeden LINQ-Methodenaufruf an einen spezialisierten Besucher:

Besucher

Übersetzt

WhereClauseVisitor

.Where(predicate)

WHERE-Bedingung

SelectProjectionVisitor

.Select(selector)

EVAL + KEEP + RENAME

GroupByVisitor

.GroupBy().Select()

STATISTIKEN ... NACH

OrderByVisitor

.OrderBy() / .ThenBy()

SORT field [ASC\|DESC]

EsqlFunctionTranslator

EsqlFunctions.*, Math.*, string methods

80+ ES|QL functions

Bei der Übersetzung werden in Ausdrücken referenzierte C#-Variablen als benannte Parameter erfasst.

3. Abfragemodell

Die Besucher produzieren nicht direkt Zeichenfolgen. Stattdessen produzieren sie QueryCommand Objekte, eine unveränderliche Zwischenrepräsentation. Ein FromCommand, ein WhereCommand, ein SortCommand und ein LimitCommand, jeweils einen ES|QL-Verarbeitungsbefehl repräsentierend. Diese werden in einem EsqlQuery Modell gesammelt.

Abfragemodell und Befehlsmuster.

Dieses Zwischenmodell ist vom Ausdrucksbaum und vom Ausgangsformat entkoppelt. Es kann inspiziert, abgefangen (über IEsqlQueryInterceptor) oder vor der Formatierung modifiziert werden.

4. Formatierung

EsqlFormatter besucht jede QueryCommand in der richtigen Reihenfolge und erstellt die finale ES|QL-Zeichenfolge. Jeder Befehl wird zu einer Zeile, getrennt durch den Pipe-Operator (|), den ES|QL zur Verkettung von Verarbeitungsbefehlen verwendet. Bezeichner, die Sonderzeichen enthalten, werden automatisch mit Backticks versehen.

5. Ausführung

Die formatierte ES|QL-Zeichenfolge und erfasste Parameter werden als JSON-Payload an den /_query -Endpunkt von Elasticsearch gesendet. Die Schnittstelle IEsqlQueryExecutor abstrahiert die Transportschicht, an der die geschichtete Paketarchitektur zum Tragen kommt.

6. Materialisierung

EsqlResponseReader streamt die JSON-Reaktion, ohne das gesamte Ergebnis-Set in den Speicher zu puffern. Ein ColumnLayout -Baum, der einmal pro Abfrage vorab berechnet wird, ordnet flache ES|QL-Spaltennamen (wie address.street, address.city) verschachtelten POCO-Eigenschaften zu. Jede Zeile wird zu einer T -Instanz zusammengestellt und einzeln über IEnumerable oder IAsyncEnumerable zurückgegeben.

Die mehrschichtige Architektur

Die LINQ-to-ES|QL-Funktionalität ist auf drei Pakete aufgeteilt:

Paketarchitektur. Elastic.Esql ist die reine Übersetzungsmaschine. Es hat keine HTTP-Abhängigkeiten und enthält die Expression Visitors, das Abfragemodell, den Formatter und den Response Reader. Sie können es eigenständig verwenden, um ES|QL-Abfragen ohne Elasticsearch-Verbindung zu erstellen und zu inspizieren, was für Tests, Abfrageprotokollierung oder den Aufbau einer eigenen Ausführungsschicht nützlich ist.

// Translation-only: no Elasticsearch connection needed var provider = new EsqlQueryProvider(); var query = new EsqlQueryable(provider) .From("products") .Where(p => p.InStock) .OrderByDescending(p => p.Price); Console.WriteLine(query.ToEsqlString()); // FROM products | WHERE in_stock == true | SORT price_usd DESC

Elastic.Clients.Esql ist ein leichter, eigenständiger ES|QL-Client. Es fügt die HTTP-Ausführung über Elastic.Esql mittels Elastic.Transport hinzu. Wenn Ihre Anwendung nur ES|QL und keine der anderen Elasticsearch-APIs benötigt, ist dies die Option mit den geringsten Abhängigkeiten.

Elastic.Clients.Elasticsearch ist der vollständige Elasticsearch.NET-Client. Es baut außerdem auf Elastic.Esql auf und stellt den LINQ-Provider über den Namespace client.Esql bereit. Dies ist der empfohlene Einstieg für die meisten Anwendungen.

Beide Ausführungsschicht-Pakete bieten ihre eigene Implementierung von IEsqlQueryExecutor, der Strategieschnittstelle, die Übersetzung und Transport miteinander verbindet.

Alle drei Pakete sind mit Native AOT kompatibel, wenn sie mit einem quellgenerierten JsonSerializerContext verwendet werden. Für den vollständigen Client siehe die Native AOT-Dokumentation.

Über die Grundlagen hinaus

Das obige Beispiel umfasste das Filtern, Sortieren und Paginieren. Der Anbieter unterstützt ein breiteres Spektrum an Operationen.

Aggregationen

GroupBy, kombiniert mit Aggregatfunktionen in Select, übersetzt in ES|QL STATS ... BY:

var stats = client.Esql.Query(q => q .GroupBy(p => p.Brand) .Select(g => new { Brand = g.Key, Count = g.Count(), AvgPrice = g.Average(p => p.Price), MaxPrice = g.Max(p => p.Price) })); // -> FROM products | STATS COUNT(*), AVG(price_usd), MAX(price_usd) BY brand

Projektionen

Select, mit anonymen Typen erzeugt die Befehle EVAL, KEEP und RENAME:

var query = client.Esql.CreateQuery() .Select(p => new { ProductName = p.Name, p.Price, p.InStock }); // -> FROM products | KEEP name, price_usd, in_stock | RENAME name AS ProductName

Umfassende Funktionsbibliothek

Über 80 ES|QL-Funktionen sind über die EsqlFunctions -Klasse verfügbar und decken Datum/Uhrzeit, Zeichenfolgen, Mathematik, IP, Musterabstimmung und Wertung ab. Die Standardmethoden Math.* und string.* werden ebenfalls übersetzt:

.Where(p => p.Name.Contains("Pro")) // -> WHERE name LIKE "*Pro*" .Where(p => EsqlFunctions.CidrMatch( // -> WHERE CIDR_MATCH(ip, "10.0.0.0/8") p.IpAddress, "10.0.0.0/8"))

LOOKUP JOIN

Indexübergreifende Suchvorgänge werden in ES|QL LOOKUP JOIN übersetzt:

var enriched = client.Esql.Query(q => q .LookupJoin( "category-lookup-index", product => product.Id, category => category.CategoryId, (product, category) => new { product.Name, category!.CategoryLabel }));

Raw ES|QL Umgehungsmöglichkeit

Für ES|QL-Features, die vom LINQ-Anbieter noch nicht unterstützt werden, können Sie Rohfragmente anfügen:

var results = client.Esql.Query(q => q .Where(p => p.InStock) .RawEsql("| EVAL discounted = price_usd * 0.9"));

Serverseitige asynchrone Abfragen

Bei langlaufenden Abfragen sollten diese zur Hintergrundverarbeitung auf dem Server eingereicht werden:

await using var asyncQuery = await client.Esql.SubmitAsyncQueryAsync( q => q.Where(p => p.InStock), asyncQueryOptions: new EsqlAsyncQueryOptions { WaitForCompletionTimeout = TimeSpan.FromSeconds(5), KeepAlive = TimeSpan.FromMinutes(10) }); await asyncQuery.WaitForCompletionAsync(); await foreach (var product in asyncQuery.AsAsyncEnumerable()) Console.WriteLine(product.Name);

Serverseitige asynchrone Abfragen sind besonders nützlich für langlaufende analytische Abfragen / die Verarbeitung großer Datensätze, die die typischen Timeout-Schwellenwerte überschreiten könnten, oder in Timeout-sensiblen Umgebungen mit Load-Balancern, API-Gateways oder Proxys, die strikte HTTP-Timeouts durchsetzen. Asynchrone Abfragen vermeiden Verbindungsabbrüche, indem die Übermittlung von dem Abruf der Ergebnisse entkoppelt wird.

Erste Schritte

LINQ to ES|QL ist verfügbar ab:

Elastic.Clients.Elasticsearch v9.3.4 (9.x branch)
Elastic.Clients.Elasticsearch v8.19.18 (8.x Branch)

Installation über NuGet:

dotnet add package Elastic.Clients.Elasticsearch

Die Einstiegspunkte befinden sich auf client.Esql:

Methode

Rückgaben

Anwendungsfall

Query(...)

IEnumerable

Synchrone Ausführung

QueryAsync(...)

IAsyncEnumerable

Asynchrones Streaming

CreateQuery()

IEsqlQueryable

Erweiterte Zusammensetzung und Inspektion

SubmitAsyncQueryAsync(...)

EsqlAsyncQuery

Langlaufende serverseitige Abfragen

Eine vollständige Feature-Referenz – einschließlich Abfrageoptionen, Zugriff auf mehrere Felder, verschachtelter Objekte und der Verarbeitung mehrwertiger Felder – finden Sie in der LINQ to ES|QL-Dokumentation.

Fazit

LINQ to ES|QL bringt die volle Ausdruckskraft von C# LINQ in die ES|QL-Abfragesprache von Elasticsearch, sodass Sie stark typisierte, kombinierbare Abfragen schreiben können, ohne Abfragezeichenfolgen von Hand erstellen zu müssen. Mit automatischer Parametererfassung, Streaming-Materialisierung und einer geschichteten Paketarchitektur, die von eigenständiger Übersetzung zum vollständigen Elasticsearch-Client skaliert, fügt es sich natürlich in .NET-Anwendungen jeder Größe ein. Installieren Sie den neuesten Client, verweisen Sie Ihre LINQ-Ausdrücke auf einen Index und überlassen Sie den Rest dem Provider.

Wie man den Elasticsearch Vector Store Connector für Microsoft Semantic Kernel zur Entwicklung von KI-Agenten verwendet

Florian Bernd,Srikanth Manvi — Fri, 06 Dec 2024 00:00:00 GMT

In Zusammenarbeit mit dem Microsoft Semantic Kernel- Team geben wir die Verfügbarkeit des Semantic Kernel Elasticsearch Vector Store Connector für Microsoft Semantic Kernel (.NET)-Benutzer bekannt. Der semantische Kernel vereinfacht die Entwicklung von KI-Agenten auf Unternehmensebene und bietet unter anderem die Möglichkeit, große Sprachmodelle (LLMs) mit relevanteren, datengesteuerten Antworten aus einem Vektorspeicher zu erweitern. Semantic Kernel bietet eine nahtlose Abstraktionsschicht für die Interaktion mit Vektorspeichern wie Elasticsearch und stellt wichtige Funktionen wie das Erstellen, Auflisten und Löschen von Datensatzsammlungen sowie das Hochladen, Abrufen und Löschen einzelner Datensätze bereit.

Der sofort einsatzbereite Semantic Kernel Elasticsearch Vector Store Connector unterstützt die Abstraktionen des Semantic Kernel Vector Stores , was es Entwicklern sehr einfach macht, Elasticsearch als Vector Store beim Erstellen von KI-Agenten einzubinden.

Elasticsearch hat eine starke Verankerung in der Open-Source-Community und hat vor Kurzem die AGPL-Lizenz übernommen. In Kombination mit dem Open-Source-Microsoft Semantic Kernel bieten diese Tools eine leistungsstarke, unternehmensgerechte Lösung. Sie können lokal beginnen, indem Sie Elasticsearch in wenigen Minuten mit diesem Befehl curl -fsSL https://elastic.co/start-local | sh starten (siehe start-local für Details) und dann auf Cloud-gehostete oder selbstgehostete Versionen umsteigen, während Sie Ihre KI-Agenten produktiv einsetzen.

In diesem Blogbeitrag zeigen wir Ihnen, wie Sie den Semantic Kernel Elasticsearch Vector Store Connector in Verbindung mit Semantic Kernel verwenden. Eine Python-Version des Konnektors wird zu einem späteren Zeitpunkt verfügbar sein.

Szenario auf hoher Ebene: Entwicklung einer RAG-Anwendung mit Semantic Kernel und Elasticsearch

Im folgenden Abschnitt gehen wir ein Beispiel durch. Im Wesentlichen entwickeln wir eine RAG-Anwendung (Retrieval Augmented Generation), die eine Frage des Benutzers als Eingabe entgegennimmt und eine Antwort zurückgibt. Wir verwenden Azure OpenAI (ein lokales LLM kann ebenfalls verwendet werden) als LLM, Elasticsearch als Vektorspeicher und Semantic Kernel (.net) als Framework, um alle Komponenten miteinander zu verbinden.

Falls Sie mit RAG-Architekturen nicht vertraut sind, können Sie sich mit diesem Artikel eine kurze Einführung verschaffen: https://www.elastic.co/search-labs/blog/retrieval-augmented-generation-rag.

Die Antwort wird vom LLM generiert, der mit Kontextinformationen gespeist wird, die für die Frage relevant sind und aus dem Elasticsearch-Vektorspeicher abgerufen werden. Die Antwort enthält auch die Quelle, die vom LLM als Kontext verwendet wurde.

RAG-Beispiel

In diesem konkreten Beispiel entwickeln wir eine Anwendung, die es Benutzern ermöglicht, Fragen zu Hotels zu stellen, die in einer internen Hoteldatenbank gespeichert sind. Der Benutzer könnte z.B. Suchen Sie nach einem bestimmten Hotel anhand verschiedener Kriterien oder fordern Sie eine Liste von Hotels an.

Für die Beispieldatenbank haben wir eine Liste von Hotels mit 100 Einträgen generiert. Die Stichprobengröße ist bewusst klein gehalten, damit Sie die Konnektordemo so einfach wie möglich ausprobieren können. In einer realen Anwendung würde der Elasticsearch-Connector seine Vorteile gegenüber anderen Optionen, wie der `InMemory`-Vektorspeicherimplementierung, insbesondere bei der Arbeit mit extrem großen Datenmengen zeigen.

Die vollständige Demo-Anwendung finden Sie im Elasticsearch Vector Store Connector- Repository.

Beginnen wir damit, die erforderlichen NuGet-Pakete und die verwendeten Direktiven zu unserem Projekt hinzuzufügen:

dotnet add package "Elastic.Clients.Elasticsearch" -v 8.16.2 dotnet add package "Elastic.SemanticKernel.Connectors.Elasticsearch" -v 0.1.2 dotnet add package "Microsoft.Extensions.Hosting" -v 9.0.0 dotnet add package "Microsoft.SemanticKernel.Connectors.AzureOpenAI" -v 1.30.0 dotnet add package "Microsoft.SemanticKernel.PromptTemplates.Handlebars" -v 1.30.0using System; using System.IO; using System.Linq; using System.Threading.Tasks; using Elastic.Clients.Elasticsearch; using Elastic.Transport; using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.Hosting; using Microsoft.Extensions.VectorData; using Microsoft.SemanticKernel; using Microsoft.SemanticKernel.Data; using Microsoft.SemanticKernel.Embeddings; using Microsoft.SemanticKernel.PromptTemplates.Handlebars;

Wir können nun unser Datenmodell erstellen und es mit semantischen Kernel-spezifischen Attributen ausstatten, um das Speichermodellschema und einige Hinweise für die Textsuche zu definieren:

///

/// Data model for storing a "hotel" with a name, a description, a description embedding and an optional reference link. ///

public sealed record Hotel { [VectorStoreRecordKey] public required string HotelId { get; set; } [TextSearchResultName] [VectorStoreRecordData(IsFilterable = true)] public required string HotelName { get; set; } [TextSearchResultValue] [VectorStoreRecordData(IsFullTextSearchable = true)] public required string Description { get; set; } [VectorStoreRecordVector(Dimensions: 1536, DistanceFunction.CosineSimilarity, IndexKind.Hnsw)] public ReadOnlyMemory? DescriptionEmbedding { get; set; } [TextSearchResultLink] [VectorStoreRecordData] public string? ReferenceLink { get; set; } }

Die Attribute des Speichermodellschemas (`VectorStore*`) sind für die tatsächliche Verwendung des Elasticsearch Vector Store Connectors am relevantesten, nämlich:

VectorStoreRecordKey Eine Eigenschaft einer Datensatzklasse als Schlüssel zu kennzeichnen, unter dem der Datensatz in einem Vektorspeicher abgelegt wird.
VectorStoreRecordData Eine Eigenschaft einer Datensatzklasse als 'Daten' kennzeichnen.
VectorStoreRecordVector Eine Eigenschaft einer Datensatzklasse als Vektor kennzeichnen.

Alle diese Attribute akzeptieren verschiedene optionale Parameter, mit denen das Speichermodell weiter angepasst werden kann. Im Fall von VectorStoreRecordKey ist es beispielsweise möglich, eine andere Distanzfunktion oder einen anderen Indextyp anzugeben.

Die Textsuchattribute (TextSearch*) werden im letzten Schritt dieses Beispiels wichtig sein. Wir werden später auf sie zurückkommen.

Im nächsten Schritt initialisieren wir die Semantic Kernel Engine und erhalten Referenzen zu den Kerndiensten. In einer realen Anwendung sollte Dependency Injection anstelle des direkten Zugriffs auf die Service-Collection verwendet werden. Dasselbe gilt für die fest codierte Konfiguration und die Geheimnisse, die stattdessen mithilfe eines Konfigurationsanbieters gelesen werden sollten:

var builder = Host.CreateApplicationBuilder(args); // Register AI services. var kernelBuilder = builder.Services.AddKernel(); kernelBuilder.AddAzureOpenAIChatCompletion("gpt-4o", "https://my-service.openai.azure.com", "my_token"); kernelBuilder.AddAzureOpenAITextEmbeddingGeneration("ada-002", "https://my-service.openai.azure.com", "my_token"); // Register text search service. kernelBuilder.AddVectorStoreTextSearch(); // Register Elasticsearch vector store. var elasticsearchClientSettings = new ElasticsearchClientSettings(new Uri("https://my-elasticsearch-instance.cloud")) .Authentication(new BasicAuthentication("elastic", "my_password")); kernelBuilder.AddElasticsearchVectorStoreRecordCollection("skhotels", elasticsearchClientSettings); // Build the host. using var host = builder.Build(); // For demo purposes, we access the services directly without using a DI context. var kernel = host.Services.GetService()!; var embeddings = host.Services.GetService()!; var vectorStoreCollection = host.Services.GetService>()!; // Register search plugin. var textSearch = host.Services.GetService>()!; kernel.Plugins.Add(textSearch.CreateWithGetTextSearchResults("SearchPlugin"));

Der Dienst vectorStoreCollection kann nun verwendet werden, um die Sammlung zu erstellen und einige Demodatensätze einzulesen:

await vectorStoreCollection.CreateCollectionIfNotExistsAsync(); // CSV format: ID;Hotel Name;Description;Reference Link var hotels = (await File.ReadAllLinesAsync("hotels.csv")) .Select(x => x.Split(';')); foreach (var chunk in hotels.Chunk(25)) { var descriptionEmbeddings = await embeddings.GenerateEmbeddingsAsync(chunk.Select(x => x[2]).ToArray()); for (var i = 0; i < chunk.Length; ++i) { var hotel = chunk[i]; await vectorStoreCollection.UpsertAsync(new Hotel { HotelId = hotel[0], HotelName = hotel[1], Description = hotel[2], DescriptionEmbedding = descriptionEmbeddings[i], ReferenceLink = hotel[3] }); } }

Dies zeigt, wie Semantic Kernel die Verwendung eines Vektorspeichers mit all seiner Komplexität auf wenige einfache Methodenaufrufe reduziert.

Im Hintergrund wird in Elasticsearch ein neuer Index erstellt und alle notwendigen Eigenschaftszuordnungen werden angelegt. Unser Datensatz wird dann vollständig transparent in das Speichermodell abgebildet und schließlich im Index gespeichert. Nachfolgend sehen Sie, wie die Zuordnungen in Elasticsearch aussehen.

{ "mappings": { "properties": { "descriptionEmbedding": { "dims": 1536, "index": true, "index_options": { "type": "hnsw" }, "similarity": "cosine", "type": "dense_vector" }, "hotelName": { "type": "keyword" }, "description": { "type": "text" } } } }

Die embeddings.GenerateEmbeddingsAsync() -Aufrufe riefen transparent den konfigurierten Azure AI Embeddings Generation-Dienst auf.

Noch mehr Magie lässt sich im letzten Schritt dieser Demonstration beobachten.

Mit nur einem einzigen Aufruf von InvokePromptAsync werden alle folgenden Operationen ausgeführt, wenn der Benutzer eine Frage zu den Daten stellt:

1. Es wird eine Einbettung für die Frage des Benutzers generiert.

2. Der Vektorspeicher wird nach relevanten Einträgen durchsucht.

3. Die Ergebnisse der Abfrage werden in eine Eingabeaufforderungsvorlage eingefügt.

4. Die eigentliche Anfrage in Form der finalen Eingabeaufforderung wird an den KI-Chatvervollständigungsdienst gesendet.

// Invoke the LLM with a template that uses the search plugin to // 1. get related information to the user query from the vector store // 2. add the information to the LLM prompt. var response = await kernel.InvokePromptAsync( promptTemplate: """ Please use this information to answer the question: {{#with (SearchPlugin-GetTextSearchResults question)}} {{#each this}} Name: {{Name}} Value: {{Value}} Source: {{Link}} ----------------- {{/each}} {{/with}} Include the source of relevant information in the response. Question: {{question}} """, arguments: new KernelArguments { { "question", "Please show me all hotels that have a rooftop bar." }, }, templateFormat: "handlebars", promptTemplateFactory: new HandlebarsPromptTemplateFactory());

Erinnern Sie sich an die TextSearch* -Attribute, die wir zuvor in unserem Datenmodell definiert haben? Mithilfe dieser Attribute können wir in unserer Eingabeaufforderungsvorlage entsprechende Platzhalter verwenden, die automatisch mit den Informationen aus unseren Einträgen im Vektorspeicher befüllt werden.

Die endgültige Antwort auf unsere Frage „Bitte zeigen Sie mir alle Hotels mit einer Dachterrassenbar“ lautet wie folgt:

Console.WriteLine(response.ToString()); // > The hotel that has a rooftop bar is Skyline Suites. You can find more information about this hotel [here](https://example.com/yz567).

Die Antwort bezieht sich korrekt auf den folgenden Eintrag in unserer hotels.csv-Datei.

9; Skyline Suites; Offering panoramic city views from every suite, this hotel is perfect for those who love the urban landscape. Enjoy luxurious amenities, a rooftop bar, and close proximity to attractions. Luxurious and contemporary.; https://example.com/yz567

Dieses Beispiel zeigt sehr gut, wie die Verwendung des Microsoft Semantic Kernel durch seine durchdachten Abstraktionen eine signifikante Reduzierung der Komplexität ermöglicht und gleichzeitig ein sehr hohes Maß an Flexibilität gewährleistet. Durch die Änderung einer einzigen Codezeile können beispielsweise der Vektorspeicher oder die verwendeten KI-Dienste ersetzt werden, ohne dass ein anderer Teil des Codes umstrukturiert werden muss.

Gleichzeitig bietet das Framework eine enorme Menge an High-Level-Funktionalität, wie zum Beispiel die Funktion `InvokePrompt` oder das Template- oder Such-Plugin-System.

Die vollständige Demo-Anwendung finden Sie im Elasticsearch Vector Store Connector-Repository.

Was ist sonst noch mit Elasticsearch möglich?

Elasticsearch & Semantic Kernel: Was kommt als Nächstes?

Wir haben gezeigt, wie der Elasticsearch-Vektorspeicher beim Erstellen von GenAI-Anwendungen in .NET einfach in den Semantic Kernel eingebunden werden kann. Seien Sie gespannt auf die nächste Python-Integration.
Da Semantic Kernel Abstraktionen für fortgeschrittene Suchfunktionen wie die Hybridsuche erstellt, ermöglicht Elasticsearch Connect .NET-Entwicklern die einfache Implementierung dieser Funktionen bei der Verwendung von Semantic Kernel.

Die Entwicklung des Elasticsearch .NET-Clients: Von NEST zu Elastic.Clients.Elasticsearch

Florian Bernd — Tue, 16 Apr 2024 00:00:00 GMT

Einführung in den .NET-Client und NEST

In der .NET-Welt wird die Integration mit Elasticsearch seit langem durch die NEST -Bibliothek erleichtert, die als robuste Schnittstelle für Entwickler dient, um mit den leistungsstarken Such- und Analysefunktionen von Elasticsearch zu interagieren. NEST, entstanden aus dem Bedürfnis nach einem nativen .NET-Client für Elasticsearch, erfreute sich aufgrund seines umfangreichen Funktionsumfangs und seiner nahtlosen Integrationsmöglichkeiten schnell großer Beliebtheit bei Entwicklern.

Seit fast 14 Jahren und nur 8 Monaten nach dem ersten Commit von Elasticsearch verfolgt NEST die Elasticsearch-Releases zuverlässig.

Umstellung von NEST auf Elastic.Clients.Elasticsearch

Mit der Weiterentwicklung von Elasticsearch wurde die Wartung der komplexen Codebasis von NEST zunehmend schwieriger. Wir erkannten die Notwendigkeit eines nachhaltigeren Ansatzes für die Cliententwicklung und machten uns auf den Weg, den .NET-Client von Grund auf neu zu gestalten. Es dauerte fast ein Jahr, bis wir eine erste Beta-Version veröffentlichen konnten, und ein weiteres Jahr, bis wir nahezu jeden einzelnen Server-Endpunkt unterstützen konnten. Eine der schwierigsten Entscheidungen war, den Umfang der Bibliothek zu reduzieren, um stattdessen die Wartbarkeit zu priorisieren.

Angesichts des Umfangs der Elasticsearch-API-Oberfläche ist es heute nicht mehr praktikabel, über 450 Endpunkte und fast 3000 Typen (Anfragen, Antworten, Abfragen, Aggregationen usw.) manuell zu pflegen. Um eine konsistente, genaue und zeitnahe Abstimmung zwischen Sprachclients und Elasticsearch zu gewährleisten, werden die 8.x-Clients und viele der zugehörigen Typen jetzt automatisch aus einer gemeinsamen Spezifikation generiert. Dies ist eine gängige Lösung, um die Abstimmung zwischen Client und Server bei SDKs und Bibliotheken wie denen für Azure, AWS und die Google Cloud Platform aufrechtzuerhalten.

Die Elasticsearch-Spezifikation wurde vor über 8 Jahren durch den Export der Typzuordnungen aus NEST erstellt, und dank der harten Arbeit des Client-Teams können wir nun dieselbe Spezifikation verwenden, um einen neuen .NET-Client (und Clients für zahlreiche andere Sprachen wie Java, Go usw.) zu erstellen.

Mit der Veröffentlichung von Version 8.13 wurde die Abschaffung von NEST offiziell bekannt gegeben. Mit dem Übergang von Elasticsearch zu Elastic.Clients.Elasticsearch wird NEST schrittweise auslaufen und zum Jahresende endgültig eingestellt. Entwickler werden dringend gebeten, frühzeitig mit den Migrationsbemühungen zu beginnen, um einen reibungslosen Übergang zu gewährleisten und mögliche Störungen zu minimieren. Die Verwendung Elastic.Clients.Elasticsearch gewährleistet nicht nur die Kompatibilität mit den neuesten Serverfunktionen, sondern schützt Anwendungen auch vor veralteten Funktionen für die Zukunft.

Elastic.Clients.Elasticsearch: Funktionen und Änderungen im Überblick

Durch den Wechsel zum v8-Client Elastic.Clients.Elasticsearch erhalten Sie Zugriff auf alle neuen Funktionen von Elasticsearch 8 und profitieren zudem von zahlreichen Modernisierungen der Bibliothek selbst. Allerdings bedeutet dies auch eine Reduzierung der Komfortfunktionen im Vergleich zum Vorgänger. Zu den neuen Kernfunktionen gehören die Abfragesprache ES|QL, moderne Machine-Learning-Funktionen (ML) und verbesserte Diagnosemöglichkeiten in Form von OpenTelemetry-kompatiblen Aktivitäten. Ab Version 8.13 unterstützt Elastic.Clients.Elasticsearch nahezu alle Serverfunktionen von Elasticsearch 8.

Eine wichtige grundlegende Änderung betrifft beispielsweise Aggregationen. In NEST sieht die Verwendung der Fluent API folgendermaßen aus:

s => s .Aggregations(aggs => aggs .Children("name_of_child_agg", child => child .Aggregations(childAggs => childAggs .Average("average_per_child", avg => avg.Field(p => p.ConfidenceFactor)) .Max("max_per_child", max => max.Field(p => p.ConfidenceFactor)) .Min("min_per_child", min => min.Field(p => p.ConfidenceFactor)) ) ) )

Der V8-Client erfordert hingegen folgende Syntax:

s => s .Aggregations(aggs => aggs .Add("name_of_child_agg", agg => agg .Children(_ => {}) .Aggregations(childAggs => childAggs .Add("average_per_child", agg => agg.Avg(avg => avg.Field(p => p.ConfidenceFactor))) .Add("max_per_child", agg => agg.Max(max => max.Field(p => p.ConfidenceFactor))) .Add("min_per_child", agg => agg.Min(min => min.Field(p => p.ConfidenceFactor))) ) ) )

Migration von NEST v7 zu .NET-Client v8

Ein ausführlicher Migrationsleitfaden ist hier verfügbar: Migrationsleitfaden: Von NEST v7 zu .NET Client v8.