Tam metin aramasının Azure 'da nasıl çalıştığı Bilişsel AramaHow full text search works in Azure Cognitive Search

Bu makale, Lucene tam metin aramasının Azure Bilişsel Arama nasıl çalıştığını daha ayrıntılı olarak anlayabilmek isteyen geliştiricilere yöneliktir.This article is for developers who need a deeper understanding of how Lucene full text search works in Azure Cognitive Search. Azure Bilişsel Arama metin sorguları için çoğu senaryoda beklenen sonuçları sorunsuz bir şekilde teslim eder, ancak bazen "kapalı" olarak görünen bir sonuç elde edebilirsiniz.For text queries, Azure Cognitive Search will seamlessly deliver expected results in most scenarios, but occasionally you might get a result that seems "off" somehow. Bu durumlarda, Lucene sorgu yürütme (sorgu ayrıştırma, sözcük analizi, belge eşleştirme, Puanlama) dört aşamasında bir arka plana sahip olmak, Sorgu parametrelerine veya dizin yapılandırmasına yönelik istenen değişiklikleri sunacak şekilde belirlemenize yardımcı olabilir sonucu.In these situations, having a background in the four stages of Lucene query execution (query parsing, lexical analysis, document matching, scoring) can help you identify specific changes to query parameters or index configuration that will deliver the desired outcome.

Not

Azure Bilişsel Arama tam metin araması için Lucene kullanır, ancak Lucene tümleştirmesi ayrıntılı değildir.Azure Cognitive Search uses Lucene for full text search, but Lucene integration is not exhaustive. Azure Bilişsel Arama için önemli olan senaryoları etkinleştirmek üzere Lucene işlevselliğini seçmeli olarak kullanıma sunar ve genişlettik.We selectively expose and extend Lucene functionality to enable the scenarios important to Azure Cognitive Search.

Mimariye genel bakış ve diyagramArchitecture overview and diagram

Tam metin arama sorgusunun işlenmesi, arama terimlerini ayıklamak üzere sorgu metnini ayrıştırmaya başlar.Processing a full text search query starts with parsing the query text to extract search terms. Arama altyapısı, eşleşen koşullara sahip belgeleri almak için bir dizin kullanır.The search engine uses an index to retrieve documents with matching terms. Tek tek sorgu terimleri bazen bölünür ve yeni formlara reconstituted, bu da olası bir eşleşme olarak ele alınabilecek daha geniş bir net.Individual query terms are sometimes broken down and reconstituted into new forms to cast a broader net over what could be considered as a potential match. Daha sonra bir sonuç kümesi, eşleşen her bir belgeye atanan bir ilgi puanına göre sıralanır.A result set is then sorted by a relevance score assigned to each individual matching document. Derecelendirilen listenin en üstünde bulunanlar çağıran uygulamaya döndürülür.Those at the top of the ranked list are returned to the calling application.

Yeniden oluşturuldu, sorgu yürütme dört aşamaya sahiptir:Restated, query execution has four stages:

  1. Sorgu ayrıştırmaQuery parsing
  2. Sözcük temelli analizLexical analysis
  3. Belge alımıDocument retrieval
  4. SonuçScoring

Aşağıdaki diyagramda, bir arama isteğini işlemek için kullanılan bileşenler gösterilmektedir.The diagram below illustrates the components used to process a search request.

Azure Bilişsel Arama Lucene sorgu mimarisi diyagramı

Başlıca bileşenlerKey components İşlevsel açıklamaFunctional description
Sorgu ÇözümleyicileriQuery parsers Sorgu işleçlerinden sorgu koşullarını ayırın ve arama altyapısına gönderilmek üzere sorgu yapısını (bir sorgu ağacı) oluşturun.Separate query terms from query operators and create the query structure (a query tree) to be sent to the search engine.
ÇözümleyicileriAnalyzers Sorgu koşullarında sözcük temelli analiz gerçekleştirin.Perform lexical analysis on query terms. Bu işlem, sorgu terimlerini dönüştürmeyi, kaldırmayı veya genişletmeyi içerebilir.This process can involve transforming, removing, or expanding of query terms.
DizinIndex Dizinli belgelerden ayıklanan aranabilir terimleri depolamak ve düzenlemek için kullanılan etkili bir veri yapısı.An efficient data structure used to store and organize searchable terms extracted from indexed documents.
Arama altyapısıSearch engine Tersine çevrilmiş dizinin içeriğine göre eşleşen belgeleri alır ve puanlar.Retrieves and scores matching documents based on the contents of the inverted index.

Arama isteğinin anatomumuAnatomy of a search request

Arama isteği, bir sonuç kümesinde döndürülmelidir öğesinin tüm bir belirtimidir.A search request is a complete specification of what should be returned in a result set. En basit biçimde, her türlü ölçütü olmayan boş bir sorgudur.In simplest form, it is an empty query with no criteria of any kind. Daha gerçekçi bir örnek, muhtemelen bir filtre ifadesi ve sıralama kurallarıyla belirli alanlara kapsamlı parametreler, birkaç sorgu terimi içerir.A more realistic example includes parameters, several query terms, perhaps scoped to certain fields, with possibly a filter expression and ordering rules.

Aşağıdaki örnek, REST APIkullanarak Azure bilişsel arama 'e gönderebilecek bir arama isteğidir.The following example is a search request you might send to Azure Cognitive Search using the REST API.

POST /indexes/hotels/docs/search?api-version=2019-05-06
{
    "search": "Spacious, air-condition* +\"Ocean view\"",
    "searchFields": "description, title",
    "searchMode": "any",
    "filter": "price ge 60 and price lt 300",
    "orderby": "geo.distance(location, geography'POINT(-159.476235 22.227659)')", 
    "queryType": "full" 
}

Bu istek için arama motoru şunları yapar:For this request, the search engine does the following:

  1. Fiyatın en az $60 ve $300 ' den küçük olduğu belgeleri filtreler.Filters out documents where the price is at least $60 and less than $300.
  2. Sorguyu yürütür.Executes the query. Bu örnekte, arama sorgusu ifadelerden ve terimlerden oluşur: "Spacious, air-condition* +\"Ocean view\"" (kullanıcılar genellikle noktalama işareti girmez, ancak örnek eklemek, çözümleyicilerin onu nasıl işleyeceğini açıklamamızı sağlar).In this example, the search query consists of phrases and terms: "Spacious, air-condition* +\"Ocean view\"" (users typically don't enter punctuation, but including it in the example allows us to explain how analyzers handle it). Bu sorgu için, arama motoru, "okyanus görünümü" ve ek olarak "spacemi" veya "AIR-Condition" önekiyle başlayan şartlar için searchFields belirtilen Açıklama ve başlık alanlarını tarar.For this query, the search engine scans the description and title fields specified in searchFields for documents that contain "Ocean view", and additionally on the term "spacious", or on terms that start with the prefix "air-condition". searchMode parametresi, bir terimin açıkça gerekli olmadığı durumlarda (+), herhangi bir dönem (varsayılan) veya tümü ile eşleştirmek için kullanılır.The searchMode parameter is used to match on any term (default) or all of them, for cases where a term is not explicitly required (+).
  3. Elde edilen otel kümesini, belirli bir Coğrafya konumuna yakınlığa göre sıralar ve ardından çağıran uygulamaya geri döner.Orders the resulting set of hotels by proximity to a given geography location, and then returned to the calling application.

Bu makalenin çoğu, arama sorgusununişlenmesiyle ilgilidir: "Spacious, air-condition* +\"Ocean view\"".The majority of this article is about processing of the search query: "Spacious, air-condition* +\"Ocean view\"". Filtreleme ve sıralama kapsam dışında.Filtering and ordering are out of scope. Daha fazla bilgi için bkz. Arama API başvurusu belgeleri.For more information, see the Search API reference documentation.

1. Aşama: sorgu ayrıştırmaStage 1: Query parsing

Belirtildiği gibi, sorgu dizesi isteğin ilk satırdır:As noted, the query string is the first line of the request:

 "search": "Spacious, air-condition* +\"Ocean view\"", 

Sorgu ayrıştırıcısı, işleçleri (örnekteki * ve + gibi) arama terimlerinden ayırır ve arama sorgusunu desteklenen bir türün alt sorguları halinde kaldırır:The query parser separates operators (such as * and + in the example) from search terms, and deconstructs the search query into subqueries of a supported type:

  • tek başına terimler için terim sorgusu (spacemlike gibi)term query for standalone terms (like spacious)
  • alıntı yapılan terimler için tümcecik sorgusu (okyanus görünümü gibi)phrase query for quoted terms (like ocean view)
  • bir önek * işleci (örneğin, Air koşulu) tarafından izlenen terimler için ön ek sorgusuprefix query for terms followed by a prefix operator * (like air-condition)

Desteklenen sorgu türlerinin tam listesi için bkz. Lucene sorgu söz dizimiFor a full list of supported query types see Lucene query syntax

Bir alt sorgu ile İlişkili işleçler, bir belgenin eşleşme olarak kabul edilmesi için "olması gereken" veya "olması" gerektiğini belirtir.Operators associated with a subquery determine whether the query "must be" or "should be" satisfied in order for a document to be considered a match. Örneğin, + işleci nedeniyle +"Ocean view" "gerekir".For example, +"Ocean view" is "must" due to the + operator.

Sorgu ayrıştırıcısı, arama motoruna geçiş yaptığı bir sorgu ağacında (sorguyu temsil eden bir iç yapı) alt sorguları yeniden yapılandırır.The query parser restructures the subqueries into a query tree (an internal structure representing the query) it passes on to the search engine. Sorgu ayrıştırma işlevinin ilk aşamasında, sorgu ağacı şuna benzer.In the first stage of query parsing, the query tree looks like this.

Boolean sorgu searchmode any

Desteklenen çözümleyiciler: Simple ve Full LuceneSupported parsers: Simple and Full Lucene

Azure Bilişsel Arama, simple (varsayılan) ve fulliki farklı sorgu dili sunar.Azure Cognitive Search exposes two different query languages, simple (default) and full. queryType parametresini arama isteğinizle birlikte ayarlayarak sorgu ayrıştırıcısına, işleç ve sözdiziminin nasıl yorumlanacağını anlayabilmesi için hangi sorgu dilini kullanacağınızı söylemiş olursunuz.By setting the queryType parameter with your search request, you tell the query parser which query language you choose so that it knows how to interpret the operators and syntax. Basit sorgu dili sezgisel ve sağlam olduğundan, genellikle kullanıcı girişini istemci tarafı işleme olmadan olduğu gibi yorumlamak için uygundur.The Simple query language is intuitive and robust, often suitable to interpret user input as-is without client-side processing. Web araması altyapılarından tanıdık gelen sorgu işleçlerini destekler.It supports query operators familiar from web search engines. queryType=fullayarlayarak aldığınız tam Lucene sorgu dili, joker karakter, belirsiz, Regex ve alan kapsamlı sorgular gibi daha fazla işleç ve sorgu türü desteği ekleyerek varsayılan basit sorgu dilini genişletir.The Full Lucene query language, which you get by setting queryType=full, extends the default Simple query language by adding support for more operators and query types like wildcard, fuzzy, regex, and field-scoped queries. Örneğin, basit sorgu sözdiziminde gönderilen normal ifade bir ifade değil sorgu dizesi olarak yorumlanır.For example, a regular expression sent in Simple query syntax would be interpreted as a query string and not an expression. Bu makaledeki örnek istek, tam Lucene sorgu dilini kullanır.The example request in this article uses the Full Lucene query language.

Ayrıştırıcıda searchMode etkisiImpact of searchMode on the parser

Ayrıştırmayı etkileyen başka bir arama isteği parametresi searchMode parametredir.Another search request parameter that affects parsing is the searchMode parameter. Boolean sorguları için varsayılan işleci denetler: Any (varsayılan) veya ALL.It controls the default operator for Boolean queries: any (default) or all.

searchMode=any, varsayılan olarak, spacemli ve AIR koşulu arasındaki boşluk sınırlayıcısı veya (||), örnek sorgu metnini öğesine eşdeğer hale getirmek için:When searchMode=any, which is the default, the space delimiter between spacious and air-condition is OR (||), making the sample query text equivalent to:

Spacious,||air-condition*+"Ocean view" 

+"Ocean view"``+ gibi açık işleçler, Boolean sorgu oluşturma (terimin eşleşmesi gerekir ).Explicit operators, such as + in +"Ocean view", are unambiguous in boolean query construction (the term must match). Daha az belirgin, kalan koşulları yorumlama: spacve Hava durumu gibi.Less obvious is how to interpret the remaining terms: spacious and air-condition. Arama altyapısının okyanus görünümü ve spacemli ve Hava durumu ile eşleşmeleri bulması gerekir mi?Should the search engine find matches on ocean view and spacious and air-condition? Ya da okyanus görünümü ve kalan terimlerden birini bulmalıdır mi?Or should it find ocean view plus either one of the remaining terms?

Varsayılan olarak (searchMode=any), arama motoru daha geniş yorumu kabul eder.By default (searchMode=any), the search engine assumes the broader interpretation. Her iki alanın de eşleşmesi, yansıtılırken "veya" semantiğinin olması gerekir .Either field should be matched, reflecting "or" semantics. Daha önce gösterilen ilk sorgu ağacı, iki "i" işlemi ile, varsayılan olarak gösterilir.The initial query tree illustrated previously, with the two "should" operations, shows the default.

Artık searchMode=allbelirlediğimiz hakkında düşünün.Suppose that we now set searchMode=all. Bu durumda, alan "ve" işlemi olarak yorumlanır.In this case, the space is interpreted as an "and" operation. Kalan koşulların her ikisi de eşleşme olarak nitelendirmek için belgede bulunmalıdır.Each of the remaining terms must both be present in the document to qualify as a match. Elde edilen örnek sorgu şu şekilde yorumlanacaktır:The resulting sample query would be interpreted as follows:

+Spacious,+air-condition*+"Ocean view"

Bu sorgu için değiştirilen bir sorgu ağacı, eşleşen bir belge üç alt sorgunun kesişimi olan aşağıdaki gibi olacaktır:A modified query tree for this query would be as follows, where a matching document is the intersection of all three subqueries:

Boolean sorgusu searchmode tümü

Not

searchMode=all üzerinde searchMode=any seçme, temsilci sorguları çalıştırılarak en iyi şekilde ulaşan bir karardır.Choosing searchMode=any over searchMode=all is a decision best arrived at by running representative queries. İşleçler içermesi muhtemel olabilecek kullanıcılar (belge mağazalarını ararken ortak), searchMode=all Boole sorgu yapılarını bilgilendirir, sonuçları daha sezgisel bulabilir.Users who are likely to include operators (common when searching document stores) might find results more intuitive if searchMode=all informs boolean query constructs. searchMode ve işleçleri arasında karşılıklı yürütme hakkında daha fazla bilgi için bkz. basit sorgu söz dizimi.For more about the interplay between searchMode and operators, see Simple query syntax.

2. Aşama: sözcük AnaliziStage 2: Lexical analysis

Sözcük temelli çözümleyiciler, sorgu ağacı yapılandırıldıktan sonra terim sorgularını ve tümcecik sorgularını işler.Lexical analyzers process term queries and phrase queries after the query tree is structured. Çözümleyici, ayrıştırıcının kendisine verilen metin girdilerini kabul eder, metni işler ve sonra, belirteç oluşturma koşullarını sorgu ağacına dahil edilecek şekilde geri gönderir.An analyzer accepts the text inputs given to it by the parser, processes the text, and then sends back tokenized terms to be incorporated into the query tree.

En yaygın sözcük Analizi analizi, sorgu koşullarını belirli bir dile özgü kurallara göre dönüştüren dilsel analizler :The most common form of lexical analysis is linguistic analysis which transforms query terms based on rules specific to a given language:

  • Bir sorgu terimini bir sözcüğün kök biçiminde azaltmaReducing a query term to the root form of a word
  • Gerekli olmayan sözcükleri kaldırma (Ingilizce 'de "The" veya "ve" gibi stopwords)Removing non-essential words (stopwords, such as "the" or "and" in English)
  • Bileşik sözcüğü bileşen bölümlerine bölmeBreaking a composite word into component parts
  • Büyük harfli bir sözcüğün küçük harfleriLower casing an upper case word

Bu işlemlerin hepsi, Kullanıcı tarafından girilen metin girişi ve dizinde depolanan koşullar arasındaki farkları silme eğilimindedir.All of these operations tend to erase differences between the text input provided by the user and the terms stored in the index. Bu gibi işlemler metin işlemenin ötesine geçer ve dilin kendisi hakkında ayrıntılı bilgi ister.Such operations go beyond text processing and require in-depth knowledge of the language itself. Bu dil tanıma katmanını eklemek için Azure Bilişsel Arama, hem Lucene hem de Microsoft 'tan gelen dil Çözümleyicileri 'nin uzun listesini destekler.To add this layer of linguistic awareness, Azure Cognitive Search supports a long list of language analyzers from both Lucene and Microsoft.

Not

Çözümleme gereksinimleri, senaryonuza bağlı olarak en az düzeyde farklılık açabilir.Analysis requirements can range from minimal to elaborate depending on your scenario. Önceden tanımlanmış çözümleyiciler arasından birini seçerek veya kendi özel çözümleyicinizioluşturarak, sözlü çözümlemenin karmaşıklığını denetleyebilirsiniz.You can control complexity of lexical analysis by the selecting one of the predefined analyzers or by creating your own custom analyzer. Çözümleyiciler aranabilir alanlara kapsamlandırılır ve bir alan tanımının parçası olarak belirtilir.Analyzers are scoped to searchable fields and are specified as part of a field definition. Bu, alan temelinde sözcük temelli analizleri değiştirmenize olanak sağlar.This allows you to vary lexical analysis on a per-field basis. Belirtilmemiş, Standart Lucene Çözümleyicisi kullanılır.Unspecified, the standard Lucene analyzer is used.

Bizim örneğimizde, ilk sorgu ağacı, büyük bir "S" ve sorgu ayrıştırıcısının sorgu teriminin bir parçası olarak yorumladığı bir virgülle (bir virgül sorgu dili işleci olarak kabul edilmez) "Spacmerak" terimini içerir.In our example, prior to analysis, the initial query tree has the term "Spacious," with an uppercase "S" and a comma that the query parser interprets as a part of the query term (a comma is not considered a query language operator).

Varsayılan çözümleyici terimi işlediğinde, küçük harfli "okyanus görünümü" ve "spacemleri" olarak değişir ve virgül karakterini kaldırır.When the default analyzer processes the term, it will lowercase "ocean view" and "spacious", and remove the comma character. Değiştirilen sorgu ağacı şöyle görünür:The modified query tree will look as follows:

Analiz edilen koşullara sahip Boole sorgusu

Çözümleyici davranışlarını test etmeTesting analyzer behaviors

Bir çözümleyicinin davranışı Çözümle API 'sikullanılarak test edilebilir.The behavior of an analyzer can be tested using the Analyze API. Hangi koşulların hangi koşullara göre oluşturulacağını görmek için çözümlemek istediğiniz metni sağlayın.Provide the text you want to analyze to see what terms given analyzer will generate. Örneğin, standart çözümleyici 'nin "AIR-Condition" metnini nasıl işleyeceğini görmek için, aşağıdaki isteği verebilirsiniz:For example, to see how the standard analyzer would process the text "air-condition", you can issue the following request:

{
    "text": "air-condition",
    "analyzer": "standard"
}

Standart çözümleyici, giriş metnini aşağıdaki iki belirtece ayırır, bunlara başlangıç ve bitiş uzaklıkları (isabet vurgulama için kullanılır) ve konumlarına (tümcecik eşleştirmesi için kullanılır) gibi özniteliklere açıklama ekleyin:The standard analyzer breaks the input text into the following two tokens, annotating them with attributes like start and end offsets (used for hit highlighting) as well as their position (used for phrase matching):

{
  "tokens": [
    {
      "token": "air",
      "startOffset": 0,
      "endOffset": 3,
      "position": 0
    },
    {
      "token": "condition",
      "startOffset": 4,
      "endOffset": 13,
      "position": 1
    }
  ]
}

Sözcük temelli Analize özel durumlarExceptions to lexical analysis

Sözcük temelli analiz yalnızca, bir terim sorgusu veya bir tümcecik sorgusu için yalnızca tüm terimleri gerektiren sorgu türleri için geçerlidir.Lexical analysis applies only to query types that require complete terms – either a term query or a phrase query. Eksik terimlere sahip sorgu türleri – ön ek sorgusu, joker karakter sorgusu, Regex sorgusu veya benzer bir sorguya uygulanmaz.It doesn’t apply to query types with incomplete terms – prefix query, wildcard query, regex query – or to a fuzzy query. Örneğimizde terim air-condition* olan önek sorgusu da dahil olmak üzere bu sorgu türleri, analiz aşamasını atlayarak doğrudan sorgu ağacına eklenir.Those query types, including the prefix query with term air-condition* in our example, are added directly to the query tree, bypassing the analysis stage. Bu türlerin sorgu koşullarında gerçekleştirilen tek dönüşüm küçük harfe göre yapılır.The only transformation performed on query terms of those types is lowercasing.

3. Aşama: belge alımıStage 3: Document retrieval

Belge alımı, dizinde eşleşen koşullara sahip belgeleri bulmayı gösterir.Document retrieval refers to finding documents with matching terms in the index. Bu aşama bir örnek aracılığıyla en iyi şekilde anlaşıldı.This stage is understood best through an example. Aşağıdaki basit şemaya sahip bir oteller diziniyle başlayalım:Let's start with a hotels index having the following simple schema:

{
    "name": "hotels",
    "fields": [
        { "name": "id", "type": "Edm.String", "key": true, "searchable": false },
        { "name": "title", "type": "Edm.String", "searchable": true },
        { "name": "description", "type": "Edm.String", "searchable": true }
    ] 
} 

Bu dizinin aşağıdaki dört belgeyi içerdiğini varsayalım:Further assume that this index contains the following four documents:

{
    "value": [
        {
            "id": "1",
            "title": "Hotel Atman",
            "description": "Spacious rooms, ocean view, walking distance to the beach."
        },
        {
            "id": "2",
            "title": "Beach Resort",
            "description": "Located on the north shore of the island of Kauaʻi. Ocean view."
        },
        {
            "id": "3",
            "title": "Playa Hotel",
            "description": "Comfortable, air-conditioned rooms with ocean view."
        },
        {
            "id": "4",
            "title": "Ocean Retreat",
            "description": "Quiet and secluded"
        }
    ]
}

Terimlerin dizini oluşturmaHow terms are indexed

Alımı anlamak için dizin oluşturma hakkında birkaç temel bilgi sağlamaya yardımcı olur.To understand retrieval, it helps to know a few basics about indexing. Depolama birimi, her aranabilir alan için bir ters bir dizindir.The unit of storage is an inverted index, one for each searchable field. Ters bir dizin içinde tüm belgelerden alınan tüm koşulların sıralanmış bir listesidir.Within an inverted index is a sorted list of all terms from all documents. Her bir terim, aşağıdaki örnekte olduğu gibi, oluştuğu belge listesi ile eşlenir.Each term maps to the list of documents in which it occurs, as evident in the example below.

Ters bir dizindeki koşulları oluşturmak için, arama motoru, sorgu işleme sırasında ne olduğu gibi, belgelerin içeriği üzerinde sözlü analiz gerçekleştirir:To produce the terms in an inverted index, the search engine performs lexical analysis over the content of documents, similar to what happens during query processing:

  1. Metin girişleri , çözümleyici yapılandırmasına bağlı olarak, bir çözümleyici 'ye, daha düşük noktalama işaretlerine ve bu şekilde çıkarılır.Text inputs are passed to an analyzer, lower-cased, stripped of punctuation, and so forth, depending on the analyzer configuration.
  2. Belirteçler metin analizinin çıktıdır.Tokens are the output of text analysis.
  3. Koşullar dizine eklenir.Terms are added to the index.

Bu, arama ve dizin oluşturma işlemlerinde aynı Çözümleyicileri kullanmak için yaygın, ancak gerekli değildir, bu sayede sorgu terimleri dizin içinde terimler gibi görünür.It's common, but not required, to use the same analyzers for search and indexing operations so that query terms look more like terms inside the index.

Not

Azure Bilişsel Arama, ek indexAnalyzer ve searchAnalyzer alan parametreleriyle dizin oluşturma ve arama için farklı çözümleyiciler belirlemenizi sağlar.Azure Cognitive Search lets you specify different analyzers for indexing and search via additional indexAnalyzer and searchAnalyzer field parameters. Belirtilmemişse, analyzer özelliğine sahip çözümleyici kümesi hem dizin oluşturma hem de arama için kullanılır.If unspecified, the analyzer set with the analyzer property is used for both indexing and searching.

Örnek belgeler için ters dizinInverted index for example documents

Örneğimize dönerek, başlık alanı için ters dizin şöyle görünür:Returning to our example, for the title field, the inverted index looks like this:

Sözleşme DönemiTerm Belge listesiDocument list
atmanatman 11
ununbeach 22
Otelhotel 1, 31, 3
Hintocean 44
Playaplaya 33
çareresort 33
çekilmeretreat 44

Başlık alanında, yalnızca otel iki belgede görünür: 1, 3.In the title field, only hotel shows up in two documents: 1, 3.

Açıklama alanı için dizin aşağıdaki gibidir:For the description field, the index is as follows:

Sözleşme DönemiTerm Belge listesiDocument list
teair 33
'nı veand 44
ununbeach 11
Koşulluconditioned 33
rahatlıklacomfortable 33
Uzaklıkdistance 11
Adasıisland 22
Kaua ʻ ıkauaʻi 22
kutusununlocated 22
Kuzeydoğunorth 22
Hintocean 1, 2, 31, 2, 3
/of 22
dayanıron 22
sessquiet 44
Odalarırooms 1, 31, 3
bölümludedsecluded 44
kısa birshore 22
spacmerakspacious 11
şunuthe 1, 21, 2
-to 11
görünümview 1, 2, 31, 2, 3
İzlenecekwalking 11
kullanılarakwith 33

Dizinli koşullara göre sorgu koşullarını eşleştirmeMatching query terms against indexed terms

Yukarıdaki ters dizinler verildiğinde, örnek sorguya geri dönelim ve örnek sorgumuz için eşleşen belgelerin nasıl bulunduğumuz hakkında bilgi verlim.Given the inverted indices above, let’s return to the sample query and see how matching documents are found for our example query. Son sorgu ağacının şöyle göründüğünü hatırlayın:Recall that the final query tree looks like this:

Analiz edilen koşullara sahip Boole sorgusu

Sorgu yürütme sırasında, tekil sorgular bağımsız olarak aranabilir alanlara göre yürütülür.During query execution, individual queries are executed against the searchable fields independently.

  • "Spacmerak" TermQuery, belge 1 (otel atman) ile eşleşir.The TermQuery, "spacious", matches document 1 (Hotel Atman).

  • "AIR-Condition *" PrefixQuery, herhangi bir belgeyle eşleşmez.The PrefixQuery, "air-condition*", doesn't match any documents.

    Bu, bazen geliştiricilerin kullandığı bir davranıştır.This is a behavior that sometimes confuses developers. Hava terimi belgede mevcut olsa da, varsayılan çözümleyici tarafından iki terime bölünür.Although the term air-conditioned exists in the document, it is split into two terms by the default analyzer. Kısmi terimler içeren ön ek sorgularının çözümlenmez olduğunu hatırlayın.Recall that prefix queries, which contain partial terms, are not analyzed. Bu nedenle, "AIR-Condition" ön ekine sahip terimler ters çevrilmiş dizinde aranabilir ve bulunamadı.Therefore terms with prefix "air-condition" are looked up in the inverted index and not found.

  • PhraseQuery, "okyanus görünümü", "okyanus" ve "Görünüm" terimlerini arar ve özgün belgedeki koşulların yakınlığını denetler.The PhraseQuery, "ocean view", looks up the terms "ocean" and "view" and checks the proximity of terms in the original document. Belgeler 1, 2 ve 3 ' ü Açıklama alanında bu sorguyla eşleştirin.Documents 1, 2 and 3 match this query in the description field. Bildirim belgesi 4 ' te, başlık içinde okyanus terimi bulunur, ancak tek sözcükler yerine "okyanus görünümü" ifadesini aradığımız için eşleşme olarak kabul edilmez.Notice document 4 has the term ocean in the title but isn’t considered a match, as we're looking for the "ocean view" phrase rather than individual words.

Not

Arama sorgusu, searchFields parametresi ile ayarlanan alanları, örnek arama isteğinde gösterildiği gibi sınırlandırmadığınız sürece Azure Bilişsel Arama dizinindeki tüm aranabilir alanlara göre bağımsız olarak yürütülür.A search query is executed independently against all searchable fields in the Azure Cognitive Search index unless you limit the fields set with the searchFields parameter, as illustrated in the example search request. Seçili alanlardan herhangi biri ile eşleşen belgeler döndürülür.Documents that match in any of the selected fields are returned.

Tüm sorgu için, söz konusu sorgu için, eşleşen belgeler 1, 2, 3 ' dir.On the whole, for the query in question, the documents that match are 1, 2, 3.

4. Aşama: PuanlamaStage 4: Scoring

Bir arama sonuç kümesindeki her belgeye bir ilgi puanı atanır.Every document in a search result set is assigned a relevance score. İlgi puanının işlevi, arama sorgusuna göre ifade edilen bir Kullanıcı sorusuna en iyi şekilde yanıt veren belgelerin daha yüksek bir şekilde derecelendirmesi.The function of the relevance score is to rank higher those documents that best answer a user question as expressed by the search query. Puan, eşleşen koşulların istatistiksel özelliklerine göre hesaplanır.The score is computed based on statistical properties of terms that matched. Puanlama formülünün temel tarafında tf/ıDF (terim sıklığı-ters belge sıklığı).At the core of the scoring formula is TF/IDF (term frequency-inverse document frequency). Nadir ve yaygın terimleri içeren sorgularda, TF/ıDF nadir terimi içeren sonuçları yükseltir.In queries containing rare and common terms, TF/IDF promotes results containing the rare term. Örneğin, Başkansorgusu ile eşleşen belgelerden, tüm vikipli makalelerdeki bir kuramsal dizinde, Başkan ile eşleşen belgeler , ile eşleşen belgelerden daha ilgili olarak değerlendirilir.For example, in a hypothetical index with all Wikipedia articles, from documents that matched the query the president, documents matching on president are considered more relevant than documents matching on the.

Puanlama örneğiScoring example

Örnek sorgumız ile eşleşen üç belgeyi geri çekin:Recall the three documents that matched our example query:

search=Spacious, air-condition* +"Ocean view"  
{
  "value": [
    {
      "@search.score": 0.25610128,
      "id": "1",
      "title": "Hotel Atman",
      "description": "Spacious rooms, ocean view, walking distance to the beach."
    },
    {
      "@search.score": 0.08951007,
      "id": "3",
      "title": "Playa Hotel",
      "description": "Comfortable, air-conditioned rooms with ocean view."
    },
    {
      "@search.score": 0.05967338,
      "id": "2",
      "title": "Ocean Resort",
      "description": "Located on a cliff on the north shore of the island of Kauai. Ocean view."
    }
  ]
}

Belge 1, sorgu en iyi şekilde eşleştiğinden, hem terimi hem de gerekli tümcecik görünümü Açıklama alanında gerçekleştiğinden sorgu en iyi şekilde eşleşti.Document 1 matched the query best because both the term spacious and the required phrase ocean view occur in the description field. Sonraki iki belge yalnızca tümcecik okyanus görünümüyleeşleşir.The next two documents match only the phrase ocean view. Belge 2 ve 3 ' ün ilgi puanı, sorguyla aynı şekilde eşleştirildiği halde farklı olduğunu ortaya çıkarmış olabilir.It might be surprising that the relevance score for document 2 and 3 is different even though they matched the query in the same way. Bunun nedeni, Puanlama formülünün yalnızca TF/ıDF 'den daha fazla bileşene sahip olmasından kaynaklanır.It's because the scoring formula has more components than just TF/IDF. Bu durumda, açıklama daha kısa olduğundan belge 3 ' te biraz daha yüksek bir puan atandı.In this case, document 3 was assigned a slightly higher score because its description is shorter. Alan uzunluğu ve diğer faktörlerin ilgi Puanını nasıl etkileyebileceğini anlamak için Lucene 'In pratik Puanlama formülü hakkında bilgi edinin.Learn about Lucene's Practical Scoring Formula to understand how field length and other factors can influence the relevance score.

Bazı sorgu türleri (joker karakter, ön ek, Regex) her zaman genel belge puanına bir sabit puanı katkıda bulunur.Some query types (wildcard, prefix, regex) always contribute a constant score to the overall document score. Bu, sorgu genişletmesi aracılığıyla bulunan eşleşmelerin sonuçlara dahil edilmesini sağlar, ancak derecelendirmeyi etkilemeksizin.This allows matches found through query expansion to be included in the results, but without affecting the ranking.

Bunun ne kadar önemli olduğunu gösteren bir örnek.An example illustrates why this matters. Önek aramaları dahil olmak üzere joker karakter aramaları tanıma göre belirsizdir, çünkü giriş çok büyük sayıda farklı terimlerde olası eşleşmelerin bulunduğu kısmi bir dizedir ("Tur", "touretes" ve " Tourmaline ").Wildcard searches, including prefix searches, are ambiguous by definition because the input is a partial string with potential matches on a very large number of disparate terms (consider an input of "tour*", with matches found on “tours”, “tourettes”, and “tourmaline”). Bu sonuçların doğası göz önüne alındığında, hangi koşulların diğerlerinden daha değerli olduğunu makul bir şekilde çıkarmanın bir yolu yoktur.Given the nature of these results, there is no way to reasonably infer which terms are more valuable than others. Bu nedenle, Puanlama joker karakter, ön ek ve normal ifade türündeki sorgularda sonuçladığı zaman terim sıklıklarını yok saydık.For this reason, we ignore term frequencies when scoring results in queries of types wildcard, prefix and regex. Kısmi ve tam koşulları içeren çok parçalı bir arama isteğinde, kısmi girdinin sonuçları, beklenmedik bir şekilde, beklenmeyen eşleşmelerin önüne geçmek için sabit bir puana eklenir.In a multi-part search request that includes partial and complete terms, results from the partial input are incorporated with a constant score to avoid bias towards potentially unexpected matches.

Puan ayarlamaScore tuning

Azure Bilişsel Arama ilgi puanlarını ayarlamaya yönelik iki yol vardır:There are two ways to tune relevance scores in Azure Cognitive Search:

  1. Puanlama profilleri , bir dizi kurala göre dereceli sonuçlar listesindeki belgeleri yükseltir.Scoring profiles promote documents in the ranked list of results based on a set of rules. Örneğimizde, başlık alanında, açıklama alanında eşleşen belgelerden daha alakalı olan belgeleri kabul eteceğiz.In our example, we could consider documents that matched in the title field more relevant than documents that matched in the description field. Ayrıca, dizinimizin her otel için bir fiyat alanı varsa, belgeleri daha düşük fiyatla yükseltebiliriz.Additionally, if our index had a price field for each hotel, we could promote documents with lower price. Arama dizinine Puanlama profilleri ekleme hakkında daha fazla bilgi edinin.Learn more how to add Scoring Profiles to a search index.
  2. Terim arttırma (yalnızca tam Lucene sorgu sözdiziminde kullanılabilir), sorgu ağacının herhangi bir bölümüne uygulanabilen ^ bir artırma işleci sağlar.Term boosting (available only in the Full Lucene query syntax) provides a boosting operator ^ that can be applied to any part of the query tree. Örneğimizde, Hava durumu*ön koşul üzerinde arama yapmak yerine, biri havayolu koşulunun veya ön koşulun tam terimini arayabilir, ancak tam terimiyle eşleşen belgeler, bir süre sorgusuna yükseltme uygulanarak daha yüksek bir şekilde derecelendirilir: * Hava durumu ^ 2 | | Hava durumu * *.In our example, instead of searching on the prefix air-condition*, one could search for either the exact term air-condition or the prefix, but documents that match on the exact term are ranked higher by applying boost to the term query: *air-condition^2||air-condition**. Terim artırmahakkında daha fazla bilgi edinin.Learn more about term boosting.

Dağıtılmış dizindeki PuanlamaScoring in a distributed index

Azure Bilişsel Arama 'deki tüm dizinler otomatik olarak birden çok parçaya bölünür ve bu da hizmet ölçeği artırma veya azaltma sırasında dizini birden çok düğüm arasında hızlıca dağıtmamızı sağlar.All indexes in Azure Cognitive Search are automatically split into multiple shards, allowing us to quickly distribute the index among multiple nodes during service scale up or scale down. Bir arama isteği verildiğinde, her parçaya bağımsız olarak verilir.When a search request is issued, it’s issued against each shard independently. Her parçanın sonuçları daha sonra birleştirilir ve puana göre sıralanır (başka bir sıralama tanımlanmazsa).The results from each shard are then merged and ordered by score (if no other ordering is defined). Puanlama işlevinin sorgu dönemi sıklığını, tüm parçalar arasında değil, parçadaki tüm belgelerde ters belge sıklığıyla karşılaştırdığından emin olmak önemlidir!It is important to know that the scoring function weights query term frequency against its inverse document frequency in all documents within the shard, not across all shards!

Bu, farklı parçalar üzerinde bulunduklarında aynı belgeler için bir uygunluk puanı farklı olabilir.This means a relevance score could be different for identical documents if they reside on different shards. Neyse ki, bu tür farklılıklar, daha fazla terim dağıtımı nedeniyle dizindeki belge sayısı büyüdükçe kaybolmaya eğilimlidir.Fortunately, such differences tend to disappear as the number of documents in the index grows due to more even term distribution. Verilen herhangi bir belgeyi hangi parçadan yerleştirilebileceğini varsaymak mümkün değildir.It’s not possible to assume on which shard any given document will be placed. Ancak, bir belge anahtarının değişmediğini varsayarsak, her zaman aynı parçaya atanır.However, assuming a document key doesn't change, it will always be assigned to the same shard.

Genel olarak, sipariş kararlılığı önemli olursa belge puanı belgeleri sıralamak için en iyi öznitelik değildir.In general, document score is not the best attribute for ordering documents if order stability is important. Örneğin, aynı puanı taşıyan iki belge verildiğinde, ilk olarak aynı sorgunun sonraki çalıştırmalarda görünen bir garanti yoktur.For example, given two documents with an identical score, there is no guarantee which one appears first in subsequent runs of the same query. Belge puanı, sonuç kümesindeki diğer belgelere göre yalnızca genel bir anlamlı fikir vermelidir.Document score should only give a general sense of document relevance relative to other documents in the results set.

SonuçConclusion

Internet arama altyapısının başarısı, özel veriler üzerinde tam metin araması için beklentiler oluşturdu.The success of internet search engines has raised expectations for full text search over private data. Neredeyse her türlü arama deneyimi için, şartlar yanlış yazıldığında veya tamamlanmadığında bile altyapının amacımızı anlaması beklenmektedir.For almost any kind of search experience, we now expect the engine to understand our intent, even when terms are misspelled or incomplete. Şimdiye kadar hiç belirttiğimiz eşdeğer terimleri veya eş anlamlıları temel alan eşleşmeler de bekleyebilir.We might even expect matches based on near equivalent terms or synonyms that we never actually specified.

Teknik açıdan, tam metin araması, gelişmiş dil analizi ve ilgili bir sonucu teslim etmek üzere sorgu şartlarını gösteren, genişleterek ve dönüştüren yollarla işlemek için önemli bir yaklaşım gerektiren çok karmaşıktır.From a technical standpoint, full text search is highly complex, requiring sophisticated linguistic analysis and a systematic approach to processing in ways that distill, expand, and transform query terms to deliver a relevant result. Devralınan karmaşıklıklar verildiğinde, bir sorgunun sonucunu etkileyebilecek birçok etken vardır.Given the inherent complexities, there are a lot of factors that can affect the outcome of a query. Bu nedenle, tam metin aramasının mekanizması anlamak için harcanan süreyi, beklenmeyen sonuçlarla çalışmaya çalışırken somut avantajlar sağlar.For this reason, investing the time to understand the mechanics of full text search offers tangible benefits when trying to work through unexpected results.

Bu makale, Azure Bilişsel Arama bağlamında tam metin aramasını araştırmakta.This article explored full text search in the context of Azure Cognitive Search. Sık karşılaşılan sorgu sorunlarını gidermeye yönelik olası nedenleri ve çözümleri tanımak için size yeterli bir arka plan sunabiliyoruz.We hope it gives you sufficient background to recognize potential causes and resolutions for addressing common query problems.

Sonraki adımlarNext steps

Ayrıca bkz.See also

Belgelerde ara REST APISearch Documents REST API

Basit sorgu söz dizimiSimple query syntax

Tam Lucene sorgu söz dizimiFull Lucene query syntax

Arama sonuçlarını işlemeHandle search results