Florian Bernd - Elasticsearch Labs

LINQ to Elasticsearch ES|QL : écrire en C#, interroger Elasticsearch

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

À partir des versions 9.3.4 et 8.19.18, le client .NET Elasticsearch inclut un fournisseur LINQ (Language Integrated Query) qui traduit les expressions LINQ C# en requêtes ES|QL (Elasticsearch Query Language) à l'exécution. Au lieu d'écrire manuellement des chaînes ES|QL, vous composez vos requêtes à l'aide des fonctions Where, Select, OrderBy, GroupBy et d'autres opérateurs standard. Le fournisseur se charge de la traduction, du paramétrage et de la désérialisation des résultats, y compris le flux par ligne qui maintient l'utilisation de la mémoire constante, quelle que soit la taille de l'ensemble des résultats.

Votre première requête

Commencez par définir un objet CLR (POCO) classique qui correspond à votre index Elasticsearch. Les noms de propriétés sont résolus en noms de colonnes ES|QL via des attributs standard System.Text.Json, comme [JsonPropertyName], ou via un JsonNamingPolicy configuré. Les mêmes règles de sérialisation des sources que celles qui s'appliquent au reste du client s'appliquent également ici.

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; } }

Une fois le type défini, une requête ressemble à ceci :

Le fournisseur la traduit en ES|QL comme ceci :

Quelques détails à noter :

Résolution des noms de propriété : p.Price devient price_usd en raison de l'attribut [JsonPropertyName], et p.Brand devient brand conformément à la politique de dénomination camelCase par défaut.
Capture des paramètres : les variables C# minPrice et brand sont capturées comme paramètres nommés (?minPrice, ?brand). Elles sont envoyées séparément de la chaîne de requête dans la charge utile JSON, ce qui empêche l'injection et permet la mise en cache du plan de requête côté serveur.
Flux en continu : QueryAsync renvoie IAsyncEnumerable. Les lignes se matérialisent une à une à mesure de leur arrivée depuis Elasticsearch.

Vous pouvez également inspecter la requête générée et ses paramètres sans l'exécuter :

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" }

Comment ça marche ? Petit rappel sur LINQ

Le mécanisme qui rend possibles les fournisseurs LINQ est la distinction entre IEnumerable et IQueryable.

Lorsque vous appelez .Where(p => p.Price > 100) sur un IEnumerable, la lambda est compilée en un Func, un délégué standard que le runtime exécute en interne. C'est le principe du LINQ-to-Objects.

Lorsque vous appelez la même méthode sur un IQueryable, le compilateur C# enveloppe la lambda dans un Expression> à la place. Il s'agit d'une structure de données qui représente la structure du code plutôt que sa forme exécutable. L'arbre d'expression peut être inspecté, analysé et traduit dans un autre langage au moment de l'exécution.

// 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);

L’interface IQueryProvider est le point d’extension. Tout fournisseur peut implémenter CreateQuery et Execute pour traduire ces arbres d’expressions dans une langue cible. Entity Framework utilise ceci pour émettre du SQL. Le fournisseur LINQ to ES|QL l'utilise pour émettre ES|QL.

L'arbre d'expression de la requête ci-dessus ressemble à ceci :

Arbre d'expression de l'exemple de requête.

L'arbre est imbriqué de l'intérieur vers l'extérieur : Take englobe OrderByDescending, qui englobe Where, qui englobe From, qui englobe la racine constante EsqlQueryable. Le prédicat Where est lui-même un sous-arbre des nœuds BinaryExpression pour les opérateurs &&, >=, et les opérateurs ==, avec des feuilles MemberExpression pour les accès aux propriétés et des captures de fermeture pour les variables minPrice et brand. C'est cette structure de données que le fournisseur parcourt pour produire le code ES|QL final.

Sous le capot : le pipeline de traduction

Le chemin d'une expression LINQ vers les résultats de la requête suit un pipeline en six étapes :

Aperçu du pipeline de traduction.

1. Capture de l'arbre d'expressions

Lorsque vous chaînez .Where(), .OrderBy(), .Take() et d’autres opérateurs sur un IQueryable, l’infrastructure standard de LINQ construit un arbre d’expressions. EsqlQueryable met en œuvre IQueryable et délègue à EsqlQueryProvider.

2. Traduction

Lors de l'exécution de la requête (par énumération, appel de ToList() ou utilisation de await foreach)), le EsqlExpressionVisitor parcourt l'arbre d'expressions de l'intérieur vers l'extérieur. Il envoie chaque appel de méthode LINQ à un visiteur spécialisé :

Visiteur

Est traduit

WhereClauseVisitor

.Where(predicate)

Condition WHERE

SelectProjectionVisitor

.Select(selector)

EVAL + KEEP + RENAME

GroupByVisitor

.GroupBy().Select()

STATS ... BY

OrderByVisitor

.OrderBy() / .ThenBy()

Champ SORT [ASC\|DESC]

EsqlFunctionTranslator

EsqlFunctions.*, Math.*, méthodes string

Plus de 80 fonctions ES|QL

Lors de la traduction, les variables C# référencées dans les expressions sont capturées comme des paramètres nommés.

3. Modèle de requête

Les visiteurs ne produisent pas directement des chaînes de caractères. À la place, ils produisent des objets QueryCommand , une représentation intermédiaire immuable. Un objet FromCommand, un objet WhereCommand, un objet SortCommand et un objet LimitCommand, chacun représentant une commande de traitement ES|QL. Ces objets sont ensuite regroupés dans un modèle EsqlQuery.

Modèle de requête et schéma de commande.

Ce modèle intermédiaire est découplé de l'arbre d'expression et du format de sortie. Il peut être inspecté, intercepté (via IEsqlQueryInterceptor) ou modifié avant d'être formaté.

4. Formatage

EsqlFormatter parcourt chaque QueryCommand dans l'ordre et produit la chaîne ES|QL finale. Chaque commande devient une ligne, séparée par l'opérateur pipe (|) utilisé par ES|QL pour chaîner les commandes de traitement. Les identificateurs contenant des caractères spéciaux sont automatiquement échappés par des guillemets inversés.

5. Exécution

La chaîne ES|QL formatée et les paramètres capturés sont envoyés au point de terminaison /_query d'Elasticsearch sous forme de charge utile JSON. L'interface IEsqlQueryExecutor masque la couche transport, où l'architecture de packages en couches prend tout son sens.

6. Matérialisation

EsqlResponseReader transmet la réponse JSON sans mettre en mémoire tampon l'ensemble des résultats. Un arbre ColumnLayout, précalculé une fois par requête, mappe les noms de colonnes ES|QL plats (comme address.street, address.city) aux propriétés POCO imbriquées. Chaque ligne est assemblée dans une instance T et renvoyée une par une via IEnumerable ou IAsyncEnumerable.

L'architecture en couches

La fonctionnalité LINQ to ES|QL est répartie sur trois packages :

Architecture des packages. Elastic.Esql est le moteur de traduction pur. Il ne dépend d'aucun HTTP et intègre les visiteurs d'expressions, le modèle de requêtes, le formateur et le lecteur de réponses. Vous pouvez l'utiliser de manière autonome pour créer et analyser des requêtes ES|QL sans connexion à Elasticsearch, ce qui est utile pour les tests, la journalisation des requêtes ou la création de votre propre couche d'exécution.

// 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 est un client ES|QL léger et autonome. Il ajoute l'exécution HTTP en plus de Elastic.Esql via Elastic.Transport. Si votre application n'a besoin que d'ES|QL et d'aucune autre API Elasticsearch, il s'agit de l'option de dépendance minimale.

Elastic.Clients.Elasticsearch est le client complet Elasticsearch .NET. Il s'appuie également sur Elastic.Esql et expose le fournisseur LINQ via l'espace de noms client.Esql. C'est le point d'entrée recommandé pour la plupart des applications.

Les deux packages de la couche d'exécution fournissent leur propre implémentation de IEsqlQueryExecutor, l'interface de stratégie qui fait le lien entre la traduction et le transport.

Les trois packages sont compatibles avec Native AOT lorsqu'ils sont utilisés avec un JsonSerializerContext généré par la source. Pour le client complet, consultez la documentation Native AOT.

Au-delà des bases

L'exemple ci-dessus traitait du filtrage, du tri et de la pagination. Le fournisseur prend en charge un ensemble d'opérations plus étendu.

Agrégations

GroupBy, associé aux fonctions d'agrégation dans Select, se traduit en ES|QL STATS ... BYpar :

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

Projections

Select, avec des types anonymes, génère les commandes EVAL, KEEP et 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

Bibliothèque riche en fonctions

Plus de 80 fonctions ES|QL sont disponibles via la classe EsqlFunctions, couvrant la gestion des dates et heures, des chaînes de caractères, des opérations mathématiques, des adresses IP, la correspondance de modèles et le calcul de scores. Les méthodes standard Math.* et string.* se traduisent également par :

.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

Les recherches par index croisé se traduisent en ES|QL LOOKUP JOINpar :

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

Séquence d'échappement pour ES|QL brut

Pour les fonctionnalités ES|QL non encore prises en charge par le fournisseur LINQ, vous pouvez ajouter des fragments bruts :

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

Requêtes asynchrones côté serveur

Pour les requêtes de longue durée, soumettez-les pour un traitement en arrière-plan sur le serveur :

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);

Les requêtes asynchrones côté serveur sont particulièrement utiles pour les requêtes analytiques de longue durée/le traitement de grands ensembles de données, qui peuvent dépasser les seuils de délai d'expiration habituels, ou dans les environnements sensibles aux délais d'expiration avec équilibreurs de charge, passerelles API ou proxys qui imposent des délais d'expiration HTTP stricts. Les requêtes asynchrones évitent les interruptions de connexion en découplant la soumission et la récupération des résultats.

Premiers pas

LINQ to ES|QL est disponible à partir de :

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

Installation depuis NuGet :

dotnet add package Elastic.Clients.Elasticsearch

Les points d’entrée sont sur client.Esql:

Méthode

Retours

Cas d'utilisation

Query(...)

IEnumerable

Exécution synchrone

QueryAsync(...)

IAsyncEnumerable

Streaming asynchrone

CreateQuery()

IEsqlQueryable

Composition et inspection avancées

SubmitAsyncQueryAsync(...)

EsqlAsyncQuery

Requêtes de longue durée côté serveur

Pour une description complète des fonctionnalités, notamment les options de requête, l'accès à plusieurs champs, les objets imbriqués et la gestion des champs à valeurs multiples, consultez la documentation LINQ to ES|QL.

Conclusion

LINQ to ES|QL apporte toute la puissance d'expression de LINQ to C# au langage de requêtes ES|QL d'Elasticsearch, vous permettant d'écrire des requêtes fortement typées et composables sans avoir à les concevoir manuellement. Grâce à la capture automatique des paramètres, la matérialisation en flux continu et une architecture de packages modulaire scalable, allant d'une simple traduction à un client Elasticsearch complet, il s'intègre naturellement aux applications .NET de toute taille. applications .NET de toute taille. Installez le client le plus récent, configurez vos expressions LINQ pour qu'elles pointent vers un index, et laissez le fournisseur gérer le reste.

Comment utiliser le connecteur Elasticsearch Vector Store pour Microsoft Semantic Kernel pour le développement d'agents d'intelligence artificielle ?

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

En collaboration avec l'équipe de Microsoft Semantic Kernel, nous annonçons la disponibilité du connecteur Semantic Kernel Elasticsearch Vector Store, pour les utilisateurs de Microsoft Semantic Kernel (.NET). Semantic Kernel simplifie la création d'agents d'intelligence artificielle de niveau professionnel, notamment en permettant d'améliorer les grands modèles de langage (LLM) grâce à des réponses plus pertinentes et fondées sur des données provenant d'un magasin de vecteurs. Semantic Kernel fournit une couche d'abstraction transparente pour interagir avec les magasins vectoriels tels qu'Elasticsearch, offrant des fonctionnalités essentielles telles que la création, l'énumération et la suppression de collections d'enregistrements et le téléchargement, l'extraction et la suppression d'enregistrements individuels.

Le connecteur Semantic Kernel Elasticsearch Vector Store, prêt à l'emploi, prend en charge les abstractions du Semantic Kernel vector store, ce qui permet aux développeurs de brancher très facilement Elasticsearch en tant que magasin vectoriel lors de la création d'agents d'intelligence artificielle.

Elasticsearch est solidement ancré dans la communauté des logiciels libres et a récemment adopté la licence AGPL. Associés au noyau sémantique Microsoft open-source, ces outils offrent une solution puissante, prête pour l'entreprise. Vous pouvez commencer localement en démarrant Elasticsearch en quelques minutes en exécutant cette commande curl -fsSL https://elastic.co/start-local | sh (voir start-local pour plus de détails) et évoluer vers des versions hébergées dans le nuage ou auto-hébergées tout en mettant en production vos agents d'IA.

Dans ce blog, nous verrons comment utiliser le connecteur Semantic Kernel Elasticsearch Vector Store lors de l'utilisation de Semantic Kernel. Une version Python du connecteur sera disponible à l'avenir.

Scénario de haut niveau : Construire une application RAG avec Semantic Kernel & Elasticsearch

Dans la section suivante, nous présentons un exemple. À un niveau élevé, nous construisons une application RAG (Retrieval Augmented Generation) qui prend la question d'un utilisateur en entrée et renvoie une réponse. Nous utiliserons Azure OpenAI(un LLM local peut également être utilisé) comme LLM, Elasticsearch comme magasin de vecteurs et Semantic Kernel (.net) comme cadre pour relier tous les composants ensemble.

Si vous n'êtes pas familier avec les architectures RAG, vous pouvez vous familiariser rapidement avec cet article : https://www.elastic.co/search-labs/blog/retrieval-augmented-generation-rag.

La réponse est générée par le LLM qui est alimenté par le contexte, pertinent pour la question, récupéré à partir du vectorstore Elasticsearch. La réponse inclut également la source qui a été utilisée comme contexte par le LLM.

Exemple de GCR

Dans cet exemple spécifique, nous créons une application qui permet aux utilisateurs de poser des questions sur les hôtels stockés dans une base de données interne. L'utilisateur peut par exemple rechercher un hôtel spécifique, en fonction de différents critères, ou demander une liste d'hôtels.

Pour la base de données d'exemple, nous avons généré une liste d'hôtels contenant 100 entrées. La taille de l'échantillon est volontairement réduite pour vous permettre d'essayer la démo du connecteur aussi facilement que possible. Dans une application réelle, le connecteur Elasticsearch montrerait ses avantages par rapport à d'autres options, telles que l'implémentation du magasin vectoriel `InMemory`, en particulier lorsque l'on travaille avec de très grandes quantités de données.

L'application de démonstration complète se trouve dans le référentiel du connecteur Elasticsearch vector store.

Commençons par ajouter les paquets NuGet et les directives nécessaires à notre projet :

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;

Nous pouvons maintenant créer notre modèle de données et le doter d'attributs spécifiques au Semantic Kernel pour définir le schéma du modèle de stockage et quelques indications pour la recherche textuelle :

///

/// 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; } }

Les attributs du schéma du modèle de stockage (`VectorStore*`) sont les plus pertinents pour l'utilisation réelle du connecteur Elasticsearch Vector Store, à savoir :

VectorStoreRecordKey pour marquer une propriété d'une classe d'enregistrement comme étant la clé sous laquelle l'enregistrement est stocké dans un magasin vectoriel.
VectorStoreRecordData pour marquer une propriété d'une classe d'enregistrement comme "data".
VectorStoreRecordVector pour marquer une propriété d'une classe d'enregistrement en tant que vecteur.

Tous ces attributs acceptent divers paramètres facultatifs qui peuvent être utilisés pour personnaliser davantage le modèle de stockage. Dans le cas de VectorStoreRecordKey , par exemple, il est possible de spécifier une fonction de distance différente ou un type d'indice différent.

Les attributs de recherche de texte (TextSearch*) seront importants dans la dernière étape de cet exemple. Nous y reviendrons plus tard.

Dans l'étape suivante, nous initialisons le moteur du noyau sémantique et obtenons des références aux services de base. Dans une application réelle, l' injection de dépendances devrait être utilisée au lieu d'accéder directement à la collection de services. La même chose s'applique à la configuration et aux secrets codés en dur, qui doivent être lus à l'aide d'un fournisseur de configuration:

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"));

Le service vectorStoreCollection peut maintenant être utilisé pour créer la collection et ingérer quelques enregistrements de démonstration :

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] }); } }

Cela montre comment Semantic Kernel réduit l'utilisation d'un magasin de vecteurs, avec toute sa complexité, à quelques simples appels de méthodes.

Sous le capot, un nouvel index est créé dans Elasticsearch et tous les mappages de propriétés nécessaires sont créés. Notre ensemble de données est ensuite intégré de manière totalement transparente dans le modèle de stockage et finalement stocké dans l'index. Voici à quoi ressemblent les mappings dans Elasticsearch.

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

Le site embeddings.GenerateEmbeddingsAsync() appelle de manière transparente le service Azure AI Embeddings Generation configuré.

La dernière étape de cette démonstration est encore plus magique.

Avec un seul appel à InvokePromptAsync, toutes les opérations suivantes sont effectuées lorsque l'utilisateur pose une question sur les données :

1. L'intégration de la question de l'utilisateur est générée.

2. Le magasin de vecteurs est parcouru à la recherche d'entrées pertinentes

3. Les résultats de la requête sont insérés dans un modèle d'invite

4. La requête proprement dite, sous la forme de l'invite finale, est envoyée au service d'achèvement de chat de l'IA.

// 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());

Vous vous souvenez des attributs TextSearch* que nous avons définis précédemment dans notre modèle de données ? Ces attributs nous permettent d'utiliser les espaces réservés correspondants dans notre modèle d'invite, qui sont automatiquement remplis avec les informations provenant de nos entrées dans le magasin de vecteurs.

La réponse finale à notre question "Veuillez m'indiquer tous les hôtels qui disposent d'un bar sur le toit." est la suivante :

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).

La réponse se réfère correctement à l'entrée suivante dans notre fichier hotels.csv

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

Cet exemple montre très bien comment l'utilisation de Microsoft Semantic Kernel permet une réduction significative de la complexité grâce à ses abstractions bien pensées, tout en permettant un très haut niveau de flexibilité. En changeant une seule ligne de code, par exemple, le magasin de vecteurs ou les services d'intelligence artificielle utilisés peuvent être remplacés sans qu'il soit nécessaire de remanier une autre partie du code.

Dans le même temps, le cadre fournit un ensemble considérable de fonctionnalités de haut niveau, telles que la fonction `InvokePrompt`, ou le système de plugin de modèle ou de recherche.

L'application de démonstration complète se trouve dans le référentiel du connecteur Elasticsearch vector store.

Quelles sont les autres possibilités offertes par Elasticsearch ?

Elasticsearch & Semantic Kernel : Quelle est la prochaine étape ?

Nous avons montré comment le magasin vectoriel Elasticsearch peut être facilement intégré au Semantic Kernel lors de la construction d'applications GenAI en .NET. Restez à l'écoute pour une prochaine intégration de Python.
Comme Semantic Kernel construit des abstractions pour des fonctions de recherche avancées telles que la recherche hybride, la connexion Elasticsearch permettra aux développeurs .NET de les mettre en œuvre facilement tout en utilisant Semantic Kernel.

Evolution du client Elasticsearch .NET : De NEST à Elastic.Clients.Elasticsearch

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

Introduction au client .NET et à NEST

Dans le monde .NET, l'intégration avec Elasticsearch est depuis longtemps facilitée par la bibliothèque NEST, qui sert d'interface robuste aux développeurs pour interagir avec les puissantes capacités de recherche et d'analyse d'Elasticsearch. NESTnée de la nécessité de disposer d'un client .NET natif pour Elasticsearch, a rapidement gagné en popularité auprès des développeurs en raison de la richesse de ses fonctionnalités et de ses capacités d'intégration transparentes.

Depuis près de 14 ans et seulement 8 mois après le premier commit d'Elasticsearch, NEST suit fidèlement les versions d'Elasticsearch.

Passage de NEST à Elastic.Clients.Elasticsearch

Avec l'évolution d'Elasticsearch, la maintenance de la base de code complexe de NEST est devenue de plus en plus difficile. Nous avons reconnu la nécessité d'une approche plus durable du développement des clients et nous avons entrepris de redéfinir le client .NET à partir de zéro. Il nous a fallu près d'un an pour publier une première version bêta et un an de plus pour nous rapprocher de la prise en charge de tous les points d'extrémité du serveur. L'une des décisions les plus difficiles à prendre a été de réduire la portée de la bibliothèque afin de donner la priorité à la maintenabilité.

Compte tenu de la taille de la surface de l'API Elasticsearch aujourd'hui, il n'est plus pratique de maintenir plus de 450 points d'extrémité et près de 3000 types (demandes, réponses, requêtes, agrégations, etc.) à la main. Pour garantir un alignement cohérent, précis et opportun entre les clients linguistiques et Elasticsearch, les clients 8.x et de nombreux types associés sont désormais automatiquement générés par le code à partir d'une spécification partagée. Il s'agit d'une solution courante pour maintenir l'alignement entre le client et le serveur parmi les SDK et les bibliothèques, tels que ceux pour Azure, AWS et Google Cloud Platform.

La spécification Elasticsearch a été créée il y a plus de 8 ans en exportant les mappages de types de NEST et grâce au travail acharné de l'équipe clients, nous pouvons maintenant utiliser la même spécification pour créer un nouveau client .NET (et des clients pour de nombreux autres langages tels que Java, Go, etc.)

Avec la sortie de la version 8.13, l'abandon de NEST a été officiellement annoncé. Avec la transition d'Elasticsearch vers Elastic.Clients.Elasticsearch, NEST sera progressivement supprimé et atteindra sa fin de vie à la fin de l'année. Les développeurs sont fortement encouragés à commencer les efforts de migration dès le début afin d'assurer une transition en douceur et d'atténuer les perturbations potentielles. L'adoption du site Elastic.Clients.Elasticsearch permet non seulement d'assurer la compatibilité avec les dernières fonctionnalités du serveur, mais aussi de protéger les applications contre les fonctionnalités obsolètes.

Elastic.Clients.Elasticsearch : aperçu des fonctionnalités et des changements

Le passage au client v8 Elastic.Clients.Elasticsearch permet d'accéder à toutes les nouvelles fonctionnalités d'Elasticsearch 8 et apporte également de nombreuses modernisations à la bibliothèque elle-même, mais implique également une réduction des fonctionnalités de commodité par rapport à son prédécesseur. Parmi les nouvelles fonctionnalités de base, citons le langage de requête ES|QL, des capacités modernes d'apprentissage automatique (ML) et des diagnostics améliorés sous la forme d'activités compatibles avec OpenTelemetry. À partir de la version 8.13, Elastic.Clients.Elasticsearch prend en charge presque toutes les fonctionnalités serveur d'Elasticsearch 8.

Une rupture importante, par exemple, est liée aux agrégations. Dans NEST, l'utilisation de l'API fluide se présente comme suit :

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)) ) ) )

tandis que le client v8 requiert la syntaxe suivante :

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 de NEST v7 vers le client .NET v8

Un guide de migration complet est disponible ici : Guide de migration : De NEST v7 à .NET Client v8.