Florian Bernd - Elasticsearch Labs

LINQ para Elasticsearch ES|QL: escreva Consultas em C# e Consulte o Elasticsearch

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

A partir das versões 9.3.4 e 8.19.18, o cliente Elasticsearch .NET inclui um provedor de Consulta Integrada em Linguagem (LINQ) que traduz expressões LINQ em C# para a Linguagem de Consulta Elasticsearch (ES|QL) em tempo de execução. Em vez de escrever manualmente as strings ES|QL, você compõe consultas usando Where, Select, OrderBy, GroupBy e outros operadores padrão. O provedor cuida da tradução, parametrização e desserialização dos resultados, inclusive o streaming por linha que mantém o uso da memória constante, independentemente do tamanho do conjunto de resultados.

Sua primeira consulta

Comece definindo um objeto CLR simples (POCO) que mapeia para o seu índice Elasticsearch. Os nomes das propriedades são resolvidos para nomes de coluna ES|QL via atributos System.Text.Json padrão, como [JsonPropertyName], ou via JsonNamingPolicy configurado. As mesmas regras de serialização de origem que se aplicam ao restante do cliente também se aplicam aqui.

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

Com o tipo definido, uma consulta fica assim:

O provedor traduz isso para o seguinte ES|QL:

Há alguns detalhes a serem observados:

Resolução do nome da propriedade: p.Price se torna price_usd por causa do atributo [JsonPropertyName], e p.Brand se torna brand seguindo a política de nomenclatura padrão camelCase.
Captura de parâmetros: As variáveis C# minPrice e brand são capturadas como parâmetros nomeados (?minPrice, ?brand). Eles são enviados separadamente da string de consulta na carga JSON, o que evita injeções e permite o armazenamento em cache do plano de consulta no lado do servidor.
Streaming: QueryAsync retorna IAsyncEnumerable. As linhas são materializadas uma de cada vez à medida que chegam do Elasticsearch.

Você também pode inspecionar a consulta gerada e seus parâmetros sem executá-la:

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

Como funciona? Uma breve revisão sobre o LINQ

O mecanismo que torna possíveis os provedores LINQ é a distinção entre IEnumerable e IQueryable.

Quando você chama .Where(p => p.Price > 100) em um IEnumerable, o lambda compila para um Func, um delegado regular que o runtime executa em processo. Isto é LINQ-to-Objects.

Quando você chama o mesmo método em um IQueryable, o compilador C# envolve o lambda em um Expression> em vez disso. Essa é uma estrutura de dados que representa a estrutura do código em vez de sua forma executável. A árvore de expressões pode ser inspecionada, analisada e traduzida para outra linguagem em tempo de execução.

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

A interface IQueryProvider é o ponto de extensão. Qualquer provedor pode implementar CreateQuery e Execute para traduzir essas árvores de expressão para um idioma de destino. O Entity Framework usa isso para emitir SQL. O provedor LINQ to ES|QL o usa para emitir ES|QL.

A árvore de expressões para a consulta acima fica assim:

Árvore de expressões para a consulta de exemplo.

A árvore é aninhada do avesso: Take envolve OrderByDescending, que envolve Where, que envolve From, que envolve a raiz EsqlQueryable constante. O predicado Where é ele próprio uma subárvore de BinaryExpression nós para os operadores &&, >= e ==, com folhas MemberExpression para acessos a propriedades e capturas de fechamento para as variáveis minPrice e brand. Essa é a estrutura de dados que o provedor percorre para produzir o ES|QL final.

Nos bastidores: O pipeline de tradução

O caminho de uma expressão LINQ até os resultados da consulta segue um pipeline de seis estágios:

Visão geral do pipeline de tradução.

1. Captura da árvore de expressão

Quando você encadeia .Where(), .OrderBy(), .Take() e outros operadores em um IQueryable, a infraestrutura padrão do LINQ constrói uma árvore de expressões. EsqlQueryable implementa IQueryable e delega para EsqlQueryProvider.

2. Tradução

Quando a consulta é executada (enumerando, chamando ToList() ou usando await foreach)), o EsqlExpressionVisitor percorre a árvore de expressões de dentro para fora. Ele despacha cada chamada de método LINQ para um visitante especializado:

Visitante

Traduz

Para

WhereClauseVisitor

.Where(predicate)

Condição ONDE

SelectProjectionVisitor

.Select(selector)

EVAL + KEEP + RENOMEAR

GroupByVisitor

.GroupBy().Select()

ESTATÍSTICAS ... POR

OrderByVisitor

.OrderBy() / .ThenBy()

Campo SORT [ASC\|DESC]

EsqlFunctionTranslator

EsqlFunctions.*, Math.*, métodos de string

80+ funções ES|QL

Durante a tradução, as variáveis C# referenciadas em expressões são capturadas como parâmetros nomeados.

3. Modelo de consulta

Os visitantes não produzem diretamente as strings. Em vez disso, produzem QueryCommand objetos, uma representação intermediária imutável. Um FromCommand, um WhereCommand, um SortCommand, e um LimitCommand, cada um representando um comando de processamento ES|QL. Eles são coletados para um modelo EsqlQuery.

Modelo de consulta e padrão de comando.

Esse modelo intermediário é desacoplado tanto da árvore de expressão quanto do formato de saída. Ele pode ser inspecionado, interceptado (via IEsqlQueryInterceptor) ou modificado antes da formatação.

4. Formatação

EsqlFormatter visita cada QueryCommand em ordem e gera a string final do ES|QL. Cada comando se transforma em uma linha, separada pelo operador pipe (|), que o ES|QL utiliza para encadear comandos de processamento. Identificadores que contêm caracteres especiais são automaticamente escapados com backticks.

5. Execução

A string ES|QL formatada e os parâmetros capturados são enviados para o endpoint /_query do Elasticsearch no corpo da requisição, como JSON. A interface IEsqlQueryExecutor abstrai a camada de transporte, e é aí que a arquitetura de pacotes em camadas se aplica.

6. Materialização

EsqlResponseReader transmite a resposta JSON sem armazenar todo o conjunto de resultados na memória. Uma árvore ColumnLayout , pré-computada uma vez por consulta, mapeia ES|QL nomes de colunas (como address.street, address.city) para propriedades aninhadas do POCO. Cada linha é montada em uma instância T e gerada uma de cada vez via IEnumerable ou IAsyncEnumerable.

A arquitetura em camadas

A funcionalidade LINQ para ES|QL é dividida em três pacotes:

Arquitetura de pacotes. Elastic.Esql é o motor de tradução puro. Ele não tem dependência HTTP e contém os visitantes de expressões, o modelo de consulta, o formatador e o leitor de resposta. Você pode usá-lo de forma independente para criar e inspecionar consultas ES|QL sem nenhuma conexão com o Elasticsearch. Isso é útil para testes, logging de consultas ou para criar a sua camada de execução.

// 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 é um cliente ES|QL leve e independente. Ele adiciona a execução HTTP além de Elastic.Esql via Elastic.Transport. Se sua aplicação só precisa do ES|QL e nenhuma das outras APIs do Elasticsearch, essa é a opção de dependência mínima.

Elastic.Clients.Elasticsearch é o cliente completo do Elasticsearch .NET. Também se baseia em Elastic.Esql e expõe o provedor LINQ via espaço de nome client.Esql. Esse é o ponto de entrada recomendado para a maioria das aplicações.

Ambos os pacotes da camada de execução fornecem a própria implementação do IEsqlQueryExecutor, a interface estratégica que conecta tradução e transporte.

Todos os três pacotes são compatíveis com o Native AOT quando usados com um JsonSerializerContext gerado por fonte. Para as informações completas sobre o cliente, consulte a documentação do Native AOT.

Além do básico

O exemplo acima abordou filtragem, classificação e paginação. O provedor aceita um conjunto mais amplo de operações.

Agregações

GroupBy, combinado com funções agregadas em Select, traduz-se em 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

Projeções

Select, com tipos anônimos gera os comandos EVAL, KEEP e 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

Biblioteca repleta de funções

Mais de 80 funções ES|QL estão disponíveis via classe EsqlFunctions, cobrindo data/hora, string, matemática, IP, correspondência de padrões e pontuação. Métodos Math.* padrão e string.* também são traduzidos:

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

PESQUISAR ENTRAR

Consultas cruzadas de índice traduzem-se para 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 }));

Acesso direto ao ES|QL bruto

Para recursos do ES|QL que ainda não são cobertos pelo provedor LINQ, você pode adicionar fragmentos brutos:

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

Consultas assíncronas do lado do servidor

Para consultas de longa duração, envie-as para processamento em segundo plano no servidor:

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

Consultas assíncronas do lado do servidor são úteis principalmente em consultas analíticas de longa duração/processamento de grandes conjuntos de dados que podem exceder os tempos-limite típicos, ou em ambientes sensíveis a tempo-limite com balanceadores de carga, gateways de API ou proxies que impõem tempos-limite de HTTP rigorosos. Consultas assíncronas evitam quedas de conexão ao separar o envio da obtenção dos resultados.

Para começar

LINQ to ES|QL está disponível a partir de:

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

Instale do NuGet:

dotnet add package Elastic.Clients.Elasticsearch

Os pontos de entrada estão em client.Esql:

Método

Returns

Caso de uso

Query(...)

IEnumerable

Execução síncrona

QueryAsync(...)

IAsyncEnumerable

Streaming assíncrono

CreateQuery()

IEsqlQueryable

Composição avançada e inspeção

SubmitAsyncQueryAsync(...)

EsqlAsyncQuery

Consultas de longa duração no servidor

Para obter a referência completa de recursos, incluindo opções de consulta, acesso a vários campos, objetos aninhados e tratamento de campos de vários valores, consulte a documentação do LINQ to ES|QL.

Conclusão

Do LINQ para ES|QL traz toda a expressividade do C# LINQ para a linguagem de consulta ES|QL do Elasticsearch, para que você escreva consultas componíveis e com tipagem forte sem precisar criar manualmente as strings de consulta. Com captura automática de parâmetros, materialização em streaming e arquitetura de pacotes em camadas que se adapta de traduções independentes ao cliente completo do Elasticsearch, ele se integra naturalmente a aplicações .NET de qualquer tamanho. Instale o cliente mais recente, direcione suas expressões LINQ para um índice e deixe o provedor cuidar do resto.

Como usar o conector Elasticsearch Vector Store para o Microsoft Semantic Kernel no desenvolvimento de agentes de IA

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

Em colaboração com a equipe do Microsoft Semantic Kernel , estamos anunciando a disponibilidade do Semantic Kernel Elasticsearch Vector Store Connector para usuários do Microsoft Semantic Kernel (.NET). O Semantic Kernel simplifica a criação de agentes de IA de nível empresarial, incluindo a capacidade de aprimorar grandes modelos de linguagem (LLMs) com respostas mais relevantes e orientadas por dados de um Repositório de Vetores. O Semantic Kernel fornece uma camada de abstração perfeita para interagir com armazenamentos vetoriais como o Elasticsearch, oferecendo recursos essenciais como criar, listar e excluir coleções de registros, além de carregar, recuperar e excluir registros individuais.

O conector Semantic Kernel Elasticsearch Vector Store, pronto para uso, oferece suporte às abstrações de armazenamento vetorial do Semantic Kernel, o que facilita muito para os desenvolvedores a integração do Elasticsearch como um armazenamento vetorial durante a criação de agentes de IA.

O Elasticsearch possui uma base sólida na comunidade de código aberto e adotou recentemente a licença AGPL. Em conjunto com o Microsoft Semantic Kernel de código aberto, essas ferramentas oferecem uma solução poderosa e pronta para uso empresarial. Você pode começar localmente executando o Elasticsearch em poucos minutos executando este comando curl -fsSL https://elastic.co/start-local | sh (consulte start-local para obter detalhes) e migrar para versões hospedadas na nuvem ou auto-hospedadas à medida que coloca seus agentes de IA em produção.

Neste blog, veremos como usar o conector Elasticsearch Vector Store do Semantic Kernel ao utilizar o Semantic Kernel. Uma versão em Python do conector será disponibilizada futuramente.

Cenário geral: Construindo um aplicativo RAG com Semantic Kernel e Elasticsearch.

Na seção seguinte, analisaremos um exemplo. Em linhas gerais, estamos construindo um aplicativo RAG (Retrieval Augmented Generation) que recebe uma pergunta do usuário como entrada e retorna uma resposta. Usaremos o Azure OpenAI (também é possível usar um LLM local ) como LLM, o Elasticsearch como repositório de vetores e o Semantic Kernel (.NET) como framework para integrar todos os componentes.

Se você não estiver familiarizado com arquiteturas RAG, pode ter uma breve introdução com este artigo: https://www.elastic.co/search-labs/blog/retrieval-augmented-generation-rag.

A resposta é gerada pelo LLM, que é alimentado com contexto relevante para a pergunta, obtido do armazenamento de vetores do Elasticsearch. A resposta também inclui a fonte que foi usada como contexto pelo LLM.

Exemplo RAG

Neste exemplo específico, criamos um aplicativo que permite aos usuários fazer perguntas sobre hotéis armazenados em um banco de dados interno de hotéis. O usuário poderia, por exemplo... Pesquise um hotel específico com base em diferentes critérios ou solicite uma lista de hotéis.

Para o banco de dados de exemplo, geramos uma lista de hotéis contendo 100 entradas. O tamanho da amostra é intencionalmente pequeno para permitir que você experimente a demonstração do conector da maneira mais fácil possível. Em uma aplicação do mundo real, o conector Elasticsearch mostraria suas vantagens sobre outras opções, como a implementação de armazenamento vetorial `InMemory`, especialmente ao trabalhar com quantidades extremamente grandes de dados.

A aplicação de demonstração completa pode ser encontrada no repositório do conector de armazenamento vetorial do Elasticsearch.

Vamos começar adicionando os pacotes NuGet necessários e usando as diretivas ao nosso projeto:

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;

Agora podemos criar nosso modelo de dados e fornecer a ele atributos específicos do Semantic Kernel para definir o esquema do modelo de armazenamento e algumas dicas para a pesquisa de texto:

///

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

Os atributos do esquema do modelo de armazenamento (`VectorStore*`) são os mais relevantes para o uso prático do conector Elasticsearch Vector Store, a saber:

VectorStoreRecordKey Marcar uma propriedade em uma classe de registro como a chave sob a qual o registro é armazenado em um armazenamento vetorial.
VectorStoreRecordData Marcar uma propriedade em uma classe de registro como 'dados'.
VectorStoreRecordVector Para marcar uma propriedade em uma classe de registro como um vetor.

Todos esses atributos aceitam vários parâmetros opcionais que podem ser usados para personalizar ainda mais o modelo de armazenamento. No caso de VectorStoreRecordKey , por exemplo, é possível especificar uma função de distância diferente ou um tipo de índice diferente.

Os atributos de pesquisa de texto (TextSearch*) serão importantes na última etapa deste exemplo. Voltaremos a eles mais tarde.

Na próxima etapa, inicializamos o mecanismo do Kernel Semântico e obtemos referências aos serviços principais. Em uma aplicação do mundo real, a injeção de dependência deve ser usada em vez de acessar diretamente a coleção de serviços. O mesmo se aplica à configuração e aos segredos embutidos no código, que devem ser lidos usando um provedor de configuração :

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

O serviço vectorStoreCollection agora pode ser usado para criar a coleção e para inserir alguns registros de demonstração:

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

Isso demonstra como o Semantic Kernel reduz o uso de um armazenamento vetorial com toda a sua complexidade a algumas chamadas de método simples.

Nos bastidores, um novo índice é criado no Elasticsearch e todos os mapeamentos de propriedades necessários são criados. Nosso conjunto de dados é então mapeado de forma completamente transparente para o modelo de armazenamento e, finalmente, armazenado no índice. Abaixo, você pode ver como os mapeamentos aparecem no Elasticsearch.

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

As chamadas embeddings.GenerateEmbeddingsAsync() invocaram de forma transparente o serviço de geração de incorporações de IA do Azure configurado.

Ainda mais magia pode ser observada na última etapa desta demonstração.

Com apenas uma chamada para InvokePromptAsync, todas as seguintes operações são realizadas quando o usuário faz uma pergunta sobre os dados:

1. É gerado um elemento incorporado para a pergunta do usuário.

2. O repositório de vetores é pesquisado em busca de entradas relevantes.

3. Os resultados da consulta são inseridos em um modelo de prompt.

4. A consulta propriamente dita, na forma da mensagem final, é enviada ao serviço de autocompletar do chat por 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());

Lembra-se dos atributos TextSearch* que definimos anteriormente em nosso modelo de dados? Esses atributos nos permitem usar marcadores correspondentes em nosso modelo de prompt, que são preenchidos automaticamente com as informações de nossas entradas no repositório vetorial.

A resposta final à nossa pergunta "Por favor, mostre-me todos os hotéis que possuem um bar na cobertura" é a seguinte:

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

A resposta correta refere-se à seguinte entrada em nosso arquivo 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

Este exemplo demonstra muito bem como a utilização do Microsoft Semantic Kernel permite uma redução significativa da complexidade através das suas abstrações bem concebidas, além de proporcionar um elevado nível de flexibilidade. Ao alterar uma única linha de código, por exemplo, o armazenamento de vetores ou os serviços de IA utilizados podem ser substituídos sem a necessidade de refatorar qualquer outra parte do código.

Ao mesmo tempo, a estrutura fornece um enorme conjunto de funcionalidades de alto nível, como a função `InvokePrompt`, ou o sistema de plugins de modelo ou de pesquisa.

A aplicação de demonstração completa pode ser encontrada no repositório do conector de armazenamento vetorial do Elasticsearch.

O que mais é possível fazer com o Elasticsearch?

Elasticsearch e Semantic Kernel: O que vem a seguir?

Mostramos como o armazenamento de vetores do Elasticsearch pode ser facilmente integrado ao Semantic Kernel durante a criação de aplicações GenAI em .NET. Fique atento para a integração com Python em breve.
À medida que o Semantic Kernel cria abstrações para recursos de pesquisa avançados, como a pesquisa híbrida, a conexão com o Elasticsearch permitirá que os desenvolvedores .NET os implementem facilmente ao usar o Semantic Kernel.

Evolução do cliente Elasticsearch .NET: do NEST ao Elastic.Clients.Elasticsearch

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

Introdução ao cliente .NET e ao NEST

No mundo .NET, a integração com o Elasticsearch tem sido facilitada há muito tempo pela biblioteca NEST , que serve como uma interface robusta para os desenvolvedores interagirem com os poderosos recursos de pesquisa e análise do Elasticsearch. NEST, que surgiu da necessidade de um cliente .NET nativo para o Elasticsearch, rapidamente ganhou popularidade entre os desenvolvedores por seu rico conjunto de recursos e capacidades de integração perfeitas.

Durante quase 14 anos e apenas 8 meses após o primeiro commit do Elasticsearch, o NEST tem acompanhado fielmente os lançamentos do Elasticsearch.

Transição do NEST para o Elastic.Clients.Elasticsearch

À medida que o Elasticsearch evoluiu, a manutenção da complexa base de código do NEST tornou-se cada vez mais difícil. Reconhecemos a necessidade de uma abordagem mais sustentável para o desenvolvimento de clientes e embarcamos em uma jornada para redesenhar o cliente .NET desde a sua base. Levamos quase um ano para lançar a primeira versão beta e mais um ano para chegar perto de oferecer suporte a todos os endpoints de servidor. Uma das decisões mais difíceis foi reduzir o escopo da biblioteca para priorizar a facilidade de manutenção.

Considerando o tamanho da superfície da API do Elasticsearch hoje, não é mais viável manter manualmente mais de 450 endpoints e quase 3000 tipos (requisições, respostas, consultas, agregações, etc.). Para garantir um alinhamento consistente, preciso e oportuno entre os clientes de linguagem e o Elasticsearch, os clientes da versão 8.x e muitos dos tipos associados agora são gerados automaticamente a partir de uma especificação compartilhada. Essa é uma solução comum para manter o alinhamento entre cliente e servidor em SDKs e bibliotecas, como as do Azure, AWS e Google Cloud Platform.

A especificação do Elasticsearch foi criada há mais de 8 anos exportando os mapeamentos de tipo de NEST e, graças ao trabalho árduo da equipe de clientes, agora podemos usar a mesma especificação para criar um novo cliente .NET (e clientes para várias outras linguagens, como Java, Go, etc.).

Com o lançamento da versão 8.13, a descontinuação de NEST foi oficialmente anunciada. À medida que o Elasticsearch migra para Elastic.Clients.Elasticsearch, NEST será gradualmente descontinuado, chegando ao fim de sua vida útil no final do ano. Recomenda-se vivamente aos desenvolvedores que iniciem os esforços de migração o quanto antes para garantir uma transição tranquila e mitigar quaisquer potenciais interrupções. A adoção do Elastic.Clients.Elasticsearch não só garante a compatibilidade com os recursos mais recentes do servidor, como também protege os aplicativos contra funcionalidades obsoletas no futuro.

Elastic.Clients.Elasticsearch: visão geral de recursos e alterações

A mudança para o cliente v8 Elastic.Clients.Elasticsearch permite o acesso a todos os novos recursos do Elasticsearch 8 e também traz inúmeras modernizações para a própria biblioteca, mas também implica uma redução nos recursos de conveniência em comparação com seu antecessor. Algumas das novas funcionalidades principais incluem a linguagem de consulta ES|QL, capacidades modernas de aprendizagem automática (ML) e diagnósticos melhorados sob a forma de atividades compatíveis com OpenTelemetry. A partir da versão 8.13, Elastic.Clients.Elasticsearch suporta quase todos os recursos de servidor do Elasticsearch 8.

Uma importante mudança disruptiva, por exemplo, está relacionada às agregações. Em NEST, o uso da API fluente se parece com isto:

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

enquanto o cliente v8 requer a seguinte sintaxe:

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

Migrando do NEST v7 para o cliente .NET v8

Um guia de migração completo está disponível aqui: Guia de migração: do NEST v7 para o .NET Client v8.