Florian Bernd - Elasticsearch Labs

LINQ to Elasticsearch ES|QL：C#を記述してElasticsearchをクエリ

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

v9.3.4およびv8.19.18以降のElasticsearch .NETクライアントには、実行時にC# LINQ式をElasticsearchクエリ言語（ES|QL）クエリに変換する Language Integrated Query（LINQ）プロバイダーが含まれています。ES|QL文字列を手作業で記述する代わりに、 Where、 Select、 OrderBy、 GroupByなどの標準演算子を使用してクエリを構成します。このプロバイダーは、結果セットのサイズに関係なくメモリ使用量を一定に保つ行ごとのストリーミングを含め、変換、パラメータ化、結果の逆シリアル化を処理します。

最初のクエリ

まず、Elasticsearchインデックスにマップする普通のCLRオブジェクト（POCO）を定義します。プロパティ名は、標準的なSystem.Text.Json属性（[JsonPropertyName]など）または設定されたJsonNamingPolicyを通じてES|QL列名に解決されます。クライアントの他の部分に適用されるソースシリアル化ルールは、ここでも同様に適用されます。

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

型を指定すると、クエリは次のようになります。

プロバイダーはこれを次のES|QLに変換します。

いくつか注意すべき点があります。

プロパティ名の解決： p.Priceは[JsonPropertyName] 属性のためprice_usdになり、p.BrandはデフォルトのcamelCase命名規則に従って brandになります。
パラメーターのキャプチャ：C#変数 minPriceとbrandは、名前付きパラメーター（?minPrice、?brand）としてキャプチャされます。これらはJSONペイロード内のクエリ文字列とは別に送信されるため、インジェクション攻撃を防ぎ、サーバー側のクエリプランのキャッシュを可能にします。
ストリーミング：QueryAsyncはIAsyncEnumerableを返します。Elasticsearchからデータが到着すると、行は1つずつマテリアライズされます。

また、実行せずに生成されたクエリとそのパラメーターを検査することもできます。

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

これはどのように機能するのでしょうか？LINQ の簡単なおさらい

LINQプロバイダーを可能にするメカニズムは、IEnumerableとIQueryableの区別にあります。

.Where(p => p.Price > 100) を IEnumerable 上で呼び出すと、ラムダは Func にコンパイルされます。これは、ランタイムがインプロセスで実行する通常のデリゲートです。これはLINQ-to-Objectsです。

同じメソッドを IQueryable で呼び出すと、C#コンパイラはラムダを Expression> でラップします。これは実行可能な形式ではなく、コードの構造を表すデータ構造です。式ツリーは実行時に検査、分析、および別の言語への変換を行うことができます。

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

IQueryProviderインターフェースは拡張ポイントです。どのプロバイダーでも、これらの式ツリーをターゲット言語に変換するために CreateQuery と Execute を実装できます。Entity FrameworkはSQLを発行するためにこれを使用します。LINQからES|QLへのプロバイダーはこれをES|QLの生成に使用します。

上記のクエリの式ツリーは次のようになります。

例のクエリに対する式ツリー。

ツリーは内側から外側にネストされています。Takeが OrderByDescendingをラップし、これがWhereをラップし、これがFrom, をルート定数EsqlQueryable をラップします。Where述語自体がBinaryExpressionノードのサブツリーであり、&&、>=、および==演算子に対してMemberExpressionリーフがプロパティアクセス用、minPriceおよびbrand変数用のクロージャキャプチャ用に存在します。これは、プロバイダーが最終的なES|QLを生成するために使用するデータ構造です。

内部構造：変換パイプライン

LINQ式からクエリ結果までの経路は、6段階のパイプラインをたどります。

データ変換パイプラインの概要。

1. 式ツリーのキャプチャ

.Where()、.OrderBy()、.Take()などの演算子をIQueryable に連鎖させると、標準のLINQインフラストラクチャーが式ツリーを構築します。EsqlQueryable はIQueryable を実装し、EsqlQueryProvider に委譲します。

2. 変換

クエリが実行されると（列挙、 ToList()の呼び出し、またはawait foreach)使用によって）、 EsqlExpressionVisitorは式ツリーを内側から外側へと走査します。各LINQメソッド呼び出しを専門のビジターに送信します。

ビジター

翻訳します

対象

WhereClauseVisitor

.Where(predicate)

WHERE 条件

SelectProjectionVisitor

.Select(selector)

EVAL + KEEP + RENAME

訪問者別にグループ化

.GroupBy().Select()

STATS ... BY

OrderByVisitor

.OrderBy() / .ThenBy()

SORTフィールド [ASC\|DESC]

EsqlFunctionTranslator

EsqlFunctions.*、Math.*、文字列メソッド

80+ ES|QL関数

翻訳中、式で参照されるC#変数は名前付きパラメーターとしてキャプチャされます。

3. クエリモデル

ビジターは直接文字列を生成しません。代わりに、QueryCommandオブジェクト、すなわち不変の中間表現を生成します。FromCommand、WhereCommand、SortCommand、およびLimitCommandの各々が、1つのES|QL処理コマンドを表しています。これらはEsqlQueryモデルに集められます。

クエリモデルとコマンドパターン。

この中間モデルは、式ツリーと出力形式の両方から切り離されています。フォーマット前に検査、傍受（IEsqlQueryInterceptor経由）、または修正が可能です。

4. フォーマット

EsqlFormatter 各QueryCommandを順番に訪問し、最終的なES|QL文字列を生成します。各コマンドは1行になり、ES|QLが処理コマンドを連鎖させるために使用するパイプ (|) 演算子で区切られます。特殊文字を含む識別子は自動的にバッククォートでエスケープされます。

5. 実行

フォーマットされたES|QL文字列とキャプチャされたパラメーターは、JSONペイロードとしてElasticsearchの/_queryエンドポイントに送信されます。IEsqlQueryExecutorインターフェースはトランスポートレイヤーを抽象化し、ここで階層型パッケージアーキテクチャが登場します。

6. マテリアライズ

EsqlResponseReader JSON応答をストリーム化し、結果セット全体をバッファリングせずに処理します。ColumnLayoutツリーは、1クエリにつき1回事前に計算され、フラットなES|QL列名（address.street、address.cityなど）をネストされたPOCOプロパティにマップします。各行はTインスタンスに組み立てられ、 IEnumerable または IAsyncEnumerableによって1行ずつ生成されます。

レイヤーアーキテクチャ

LINQ to ES|QL機能は、以下の3つのパッケージに分かれています。

パッケージアーキテクチャー。Elastic.Esql は純粋な変換エンジンです。HTTPへの依存関係は一切なく、式ビジター、クエリモデル、フォーマッター、レスポンスリーダーが含まれています。スタンドアロンで使用すると、Elasticsearch接続がなくてもES|QLクエリを構築および検査できます。これは、テスト、クエリロギング、または独自の実行レイヤーの構築に役立ちます。

// 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 は軽量なスタンドアロンのES|QLクライアントです。Elastic.Transportを経由してElastic.Esql上にHTTP実行を追加します。もしアプリケーションが他のElasticsearch APIではなく、ES|QLのみを必要とする場合、これが最小限の依存関係オプションです。

Elastic.Clients.Elasticsearch は完全なElasticsearch .NETクライアントです。また、Elastic.Esql を基盤とし、client.Esql名前空間を通じてLINQプロバイダーを公開します。これはほとんどのアプリケーションで推奨されるエントリーポイントです。

どちらの実行層パッケージも、変換と転送をつなぐ戦略インターフェースであるIEsqlQueryExecutorの独自の実装を提供します。

これら3つのパッケージはすべて、ソース生成のJsonSerializerContextと併用する場合、ネイティブAOTと互換性があります。完全なクライアントについては、Native AOTのドキュメントをご覧ください。

基本を超えて

上記の例では、フィルタリング、ソート、ページネーションについて説明しています。このプロバイダーはより幅広い操作をサポートしています。

アグリゲーション

GroupBySelectの集約関数と組み合わせると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

予測

Select匿名型を持つと、 EVAL、 KEEP、 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

豊富な関数ライブラリ

80以上のES|QL関数が EsqlFunctionsクラスを通じて利用可能で、日付/時間、文字列、数学、IP、パターンマッチング、スコアリングをカバーしています。標準的なMath.*およびstring.*メソッドも変換されています。

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

ルックアップ結合

クロスインデックス検索はES|QL LOOKUP JOINに変換されます。

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

未加工のES|QLエスケープハッチ

LINQプロバイダーでまだサポートされていないES|QL機能については、生のフラグメントを追加できます。

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

サーバー側の非同期クエリ

実行時間の長いクエリについては、サーバー上でバックグラウンド処理を行うように設定します。

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

サーバー側の非同期クエリは、通常のタイムアウトしきい値を超える可能性のある長時間実行される分析クエリや大規模データセットの処理、あるいはロードバランサー、APIゲートウェイ、プロキシなど、厳格なHTTPタイムアウトを強制するタイムアウトに敏感な環境で特に役立ちます。非同期クエリは、結果の取得から提出を切り離すことで接続切断を回避します。

はじめに

LINQ to ES|QLは次のバージョンから利用可能です。

Elastic.Clients.Elasticsearch v9.3.4 (9.x ブランチ)
Elastic.Clients.Elasticsearch v8.19.18（8.xブランチ）

NuGetからのインストール：

dotnet add package Elastic.Clients.Elasticsearch

エントリーポイントはclient.Esqlにあります。

メソッド

戻り値

ユースケース

Query(...)

IEnumerable

同期実行

QueryAsync(...)

IAsyncEnumerable

非同期ストリーミング

CreateQuery()

IEsqlQueryable

高度な構成と検査

SubmitAsyncQueryAsync(...)

EsqlAsyncQuery

長時間実行されるサーバー側クエリ

クエリオプション、複数フィールドへのアクセス、ネストされたオブジェクト、複数値フィールドの処理など、機能の詳細についてはLINQ to ES|QLのドキュメントを参照してください。

まとめ

LINQ to ES|QLは、C# LINQの完全な表現力をElasticsearchのES|QLクエリ言語にもたらし、クエリ文字列を手作業で作成することなく、厳密に型付けされた構成可能なクエリを書くことができます。自動パラメーターキャプチャ、ストリーミングマテリアライゼーション、スタンドアロン変換から完全なElasticsearchクライアントまで拡張できる階層型パッケージアーキテクチャーにより、あらゆる規模の.NETアプリケーションに自然に適合します。最新のクライアントをインストールし、LINQ式をインデックスに向け、残りはプロバイダーに任せましょう。

AIエージェント開発におけるMicrosoftセマンティックカーネル向けElasticsearch Vector Store Connectorの使い方

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

Microsoft Semantic Kernel チームと連携して、 Microsoft Semantic Kernel (.NET) ユーザー向けに Semantic Kernel Elasticsearch Vector Store Connector が利用可能になったことを発表します。セマンティックカーネルは、ベクターストアからのより関連性の高いデータ駆動型の応答を使用して大規模言語モデル (LLM) を強化する機能など、エンタープライズグレードの AI エージェントの構築を簡素化します。Semantic Kernel は、Elasticsearch などの Vector Stores と対話するためのシームレスな抽象化レイヤーを提供し、レコードのコレクションの作成、一覧表示、削除や、個々のレコードのアップロード、取得、削除などの重要な機能を提供します。

すぐに使用できるセマンティックカーネル Elasticsearch ベクターストアコネクタは、セマンティックカーネルベクターストアの抽象化をサポートしており、開発者は AI エージェントの構築時に Elasticsearch をベクターストアとしてプラグインすることが非常に簡単になります。

Elasticsearch はオープンソースコミュニティに強固な基盤を持ち、最近AGPL ライセンスを採用しました。これらのツールは、オープンソースの Microsoft Semantic Kernel と組み合わせることで、強力なエンタープライズ対応ソリューションを提供します。このコマンドcurl -fsSL https://elastic.co/start-local | sh (詳細についてはstart-localを参照) を実行して数分で Elasticsearch を起動し、ローカルで開始できます。その後、AI エージェントを本番稼働させながら、クラウドホストバージョンまたはセルフホストバージョンに移行できます。

このブログでは、Semantic Kernel を使用する際にSemantic Kernel Elasticsearch Vector Store Connector を使用する方法について説明します。コネクタの Python バージョンは将来提供される予定です。

高レベルのシナリオ: Semantic Kernel と Elasticsearch を使用した RAG アプリの構築

次のセクションでは例を見ていきます。大まかに言うと、ユーザーの質問を入力として受け取り、回答を返す RAG (Retrieval Augmented Generation) アプリケーションを構築しています。LLM として Azure OpenAI (ローカル LLMも使用可能)、ベクターストアとして Elasticsearch、すべてのコンポーネントを結び付けるフレームワークとして Semantic Kernel (.net) を使用します。

RAG アーキテクチャに精通していない場合は、次の記事で簡単に概要を把握できます: https://www.elastic.co/search-labs/blog/retrieval-augmented-generation-rag 。

回答は、Elasticsearch vectorstore から取得され、質問に関連するコンテキストが入力する LLM によって生成されます。応答には、LLM によってコンテキストとして使用されたソースも含まれます。

RAGの例

この具体的な例では、社内のホテルデータベースに保存されているホテルについてユーザーが質問できるアプリケーションを構築します。ユーザーは例えばさまざまな基準に基づいて特定のホテルを検索したり、ホテルのリストを要求したりできます。

サンプルデータベースでは、100 件のエントリを含むホテルのリストを生成しました。コネクタのデモをできるだけ簡単に試せるように、サンプルサイズは意図的に小さくなっています。実際のアプリケーションでは、特に非常に大量のデータを扱う場合、Elasticsearch コネクタは `InMemory` ベクトルストア実装などの他のオプションよりも優位性を発揮します。

完全なデモアプリケーションは、Elasticsearch ベクターストアコネクタリポジトリにあります。

まず、必要な NuGet パッケージと using ディレクティブをプロジェクトに追加することから始めましょう。

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;

これで、データモデルを作成し、セマンティックカーネル固有の属性を指定して、ストレージモデルスキーマとテキスト検索のヒントを定義できるようになりました。

///

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

ストレージモデルスキーマ属性 (`VectorStore*`) は、Elasticsearch Vector Store Connector の実際の使用に最も関連しています。具体的には次のようになります。

VectorStoreRecordKey レコードクラスのプロパティを、ベクトルストアにレコードが格納されるキーとしてマークします。
VectorStoreRecordData レコードクラスのプロパティを 'data' としてマークします。
VectorStoreRecordVector レコードクラスのプロパティをベクトルとしてマークします。

これらの属性はすべて、ストレージモデルをさらにカスタマイズするために使用できるさまざまなオプションパラメーターを受け入れます。たとえば、 VectorStoreRecordKey の場合、異なる距離関数や異なるインデックスタイプを指定することが可能です。

テキスト検索属性 ( TextSearch* ) は、この例の最後のステップで重要になります。これらについては後ほど説明します。

次のステップでは、セマンティックカーネルエンジンを初期化し、コアサービスへの参照を取得します。実際のアプリケーションでは、サービスコレクションに直接アクセスするのではなく、依存性注入を使用する必要があります。同じことがハードコードされた構成とシークレットにも当てはまります。これらは、代わりに構成プロバイダーを使用して読み取る必要があります。

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

vectorStoreCollectionサービスを使用してコレクションを作成し、いくつかのデモレコードを取り込むことができるようになりました。

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

これは、セマンティックカーネルが、複雑なベクトルストアの使用を、いくつかの単純なメソッド呼び出しにまで削減する方法を示しています。

内部的には、Elasticsearch に新しいインデックスが作成され、必要なすべてのプロパティマッピングが作成されます。その後、データセットは完全に透過的にストレージモデルにマッピングされ、最終的にインデックスに保存されます。以下は Elasticsearch でのマッピングの様子です。

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

embeddings.GenerateEmbeddingsAsync()は、構成された Azure AI Embeddings Generation サービスを透過的に呼び出しました。

このデモの最後のステップでは、さらに多くの魔法が観察できます。

InvokePromptAsyncを 1 回呼び出すだけで、ユーザーがデータについて質問したときに、次のすべての操作が実行されます。

1.ユーザーの質問の埋め込みが生成される

2. ベクトルストアで関連するエントリを検索する

3. クエリの結果はプロンプトテンプレートに挿入されます

4. 最終プロンプトの形式で実際のクエリがAIチャット補完サービスに送信されます。

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

以前データモデルで定義したTextSearch*属性を覚えていますか?これらの属性により、プロンプトテンプレート内の対応するプレースホルダーを使用できるようになります。これらのプレースホルダーには、ベクターストア内のエントリからの情報が自動的に入力されます。

「屋上バーがあるホテルをすべて教えてください。」という質問に対する最終的な回答は次のとおりです。

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

答えは、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

この例は、Microsoft Semantic Kernel を使用すると、よく考えられた抽象化によって複雑さが大幅に軽減され、非常に高いレベルの柔軟性が実現されることを示しています。たとえば、コードの 1 行を変更するだけで、コードの他の部分をリファクタリングすることなく、使用されているベクトルストアまたは AI サービスを置き換えることができます。

同時に、このフレームワークは、`InvokePrompt` 関数やテンプレート、検索プラグインシステムなどの膨大な高レベル機能を提供します。

完全なデモアプリケーションは、Elasticsearch ベクターストアコネクタリポジトリにあります。

Elasticsearchで他に何ができるのか

Elasticsearch とセマンティックカーネル: 次は何?

.NET で GenAI アプリケーションを構築する際に、Elasticsearch ベクターストアを Semantic Kernel に簡単にプラグインする方法を示しました。次回の Python 統合にご期待ください。
Semantic Kernel はハイブリッド検索などの高度な検索機能の抽象化を構築するため、Elasticsearch Connect を使用すると、.NET 開発者は Semantic Kernel を使用しながらそれらを簡単に実装できるようになります。

Elasticsearch .NET クライアントの進化: NEST から Elastic.Clients.Elasticsearch へ

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

.NET クライアントと NEST の紹介

.NET の世界では、Elasticsearch との統合は長い間NESTライブラリによって促進されてきました。このライブラリは、開発者が Elasticsearch の強力な検索機能や分析機能と対話するための堅牢なインターフェースとして機能します。NEST 、Elasticsearch 用のネイティブ .NET クライアントの必要性から生まれ、豊富な機能セットとシームレスな統合機能により、開発者の間で急速に人気を博しました。

Elasticsearch の最初のコミットから約 14 年とわずか 8 か月間、NEST は Elasticsearch のリリースを忠実に追跡してきました。

NEST から Elastic.Clients.Elasticsearch への移行

Elasticsearch が進化するにつれて、 NESTの複雑なコードベースの維持がますます困難になりました。私たちは、クライアント開発に対してより持続可能なアプローチが必要であることを認識し、.NET クライアントを根本から再設計する取り組みを始めました。最初のベータ版をリリースするのにほぼ 1 年かかり、すべてのサーバーエンドポイントのサポートに近づくまでにさらに 1 年かかりました。最も難しい決断の 1 つは、保守性を優先するためにライブラリの範囲を縮小することでした。

現在の Elasticsearch API サーフェスのサイズを考えると、450 を超えるエンドポイントと 3000 近くのタイプ (リクエスト、レスポンス、クエリ、集計など) を手動で管理することはもはや現実的ではありません。言語クライアントと Elasticsearch 間の一貫性、正確性、およびタイムリーな調整を保証するために、8.x クライアントと多くの関連タイプは、共有仕様から自動的にコード生成されるようになりました。これは、Azure、AWS、Google Cloud Platform などの SDK とライブラリ間でクライアントとサーバーの整合性を維持するための一般的なソリューションです。

Elasticsearch 仕様は、 NESTから型マッピングをエクスポートすることによって 8 年以上前に作成されましたが、クライアントチームの懸命な努力により、同じ仕様を使用して新しい .NET クライアント (および Java、Go などの複数の他の言語のクライアント) を作成できるようになりました。

バージョン 8.13 のリリースにより、 NESTの廃止が正式に発表されました。Elasticsearch がElastic.Clients.Elasticsearchに移行するにつれて、 NEST段階的に廃止され、年末にサポートが終了します。スムーズな移行を実現し、潜在的な中断を最小限に抑えるために、開発者は移行作業を早期に開始することを強くお勧めします。Elastic.Clients.Elasticsearchを採用すると、最新のサーバー機能との互換性が確保されるだけでなく、廃止される機能に対してもアプリケーションの将来性が保証されます。

Elastic.Clients.Elasticsearch: 機能と変更点の概要

v8 クライアントElastic.Clients.Elasticsearchに切り替えると、Elasticsearch 8 のすべての新機能にアクセスできるようになり、ライブラリ自体も大幅に最新化されますが、以前のバージョンに比べて便利な機能が少なくなります。新しいコア機能には、クエリ言語ES|QL 、最新の機械学習 (ML) 機能、OpenTelemetry 互換アクティビティの形式での改善された診断機能などがあります。バージョン 8.13 以降、 Elastic.Clients.Elasticsearch Elasticsearch 8 のほぼすべてのサーバー機能をサポートします。

たとえば、重要な重大な変更は集計に関連しています。NESTでは、Fluent API の使用は次のようになります。

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

一方、v8 クライアントでは次の構文が必要です。

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

NEST v7 から .NET クライアント v8 への移行

包括的な移行ガイドは、こちらでご覧いただけます:移行ガイド: NEST v7 から .NET Client v8 へ。