Relevans i nyckelordssökning (BM25-bedömning)

Den här artikeln förklarar algoritmen för relevansbedömning i BM25 som används för att beräkna sökpoäng för fulltextsökning. BM25-relevans är exklusiv för fulltextsökning. Filterfrågor, komplettera automatiskt och föreslagna frågor, jokerteckensökning eller fuzzy-sökfrågor poängsätts inte eller rangordnas inte för relevans.

Bedömningsalgoritmer som används i fulltextsökning

Azure AI Search innehåller följande bedömningsalgoritmer för fulltextsökning:

Både BM25 och Classic är TF-IDF-liknande hämtningsfunktioner som använder termfrekvensen (TF) och den omvända dokumentfrekvensen (IDF) som variabler för att beräkna relevanspoäng för varje dokumentfrågepar, som sedan används för rangordningsresultat. Även om BM25 konceptuellt liknar klassiskt är det rotat i probabilistisk informationshämtning som ger mer intuitiva matchningar, mätt i användarforskning.

BM25 erbjuder avancerade anpassningsalternativ, till exempel att låta användaren bestämma hur relevanspoängen skalar med termfrekvensen för matchade termer. Mer information finns i Konfigurera bedömningsalgoritmen.

Följande videosegment snabbsnabbas till en förklaring av de allmänt tillgängliga rankningsalgoritmerna som används i Azure AI Search. Du kan titta på hela videon för mer bakgrund.

Så här fungerar BM25-rankning

Relevansbedömning refererar till beräkningen av en sökpoäng (@search.score) som fungerar som en indikator på ett objekts relevans i kontexten för den aktuella frågan. Intervallet är obundet. Men ju högre poäng, desto mer relevant är objektet.

Sökpoängen beräknas baserat på statistiska egenskaper för strängindata och själva frågan. Azure AI Search hittar dokument som matchar söktermer (vissa eller alla, beroende på searchMode), vilket gynnar dokument som innehåller många instanser av söktermen. Sökpoängen ökar ännu högre om termen är sällsynt i dataindexet, men vanlig i dokumentet. Grunden för den här metoden för databehandlingsrelevans kallas TF-IDF eller termfrekvens-inverterad dokumentfrekvens.

Sökresultat kan upprepas i en resultatuppsättning. När flera träffar har samma sökpoäng är ordningen på samma poängsatta objekt odefinierad och inte stabil. Kör frågan igen och du kan se objekt flytta position, särskilt om du använder den kostnadsfria tjänsten eller en fakturerbar tjänst med flera repliker. Med tanke på två objekt med en identisk poäng finns det ingen garanti för att en visas först.

Om du vill bryta oavgjort mellan upprepade poäng kan du lägga till en $orderby-sats i första ordningen efter poäng och sedan sortera efter ett annat sorterbart fält (till exempel $orderby=search.score() desc,Rating desc). Mer information finns i $orderby.

Endast fält som är markerade som searchable i indexet eller searchFields i frågan används för bedömning. Endast fält som har markerats som retrievable, eller fält som anges i select frågan, returneras i sökresultaten, tillsammans med deras sökpoäng.

Poäng i ett textresultat

När resultaten rangordnas @search.score innehåller egenskapen det värde som används för att sortera resultaten.

I följande tabell identifieras den bedömningsegenskap som returneras för varje matchning, algoritm och intervall.

Poängvariant

Sökpoäng förmedlar en allmän relevanskänsla som återspeglar matchningens styrka i förhållande till andra dokument i samma resultatuppsättning. Men poängen är inte alltid konsekventa från en fråga till en annan, så när du arbetar med frågor kanske du ser små skillnader i hur sökdokument sorteras. Det finns flera förklaringar till varför detta kan inträffa.

Horisontell partitioneringseffekter på frågeresultat

En shard är ett segment av ett index. Azure AI Search delar upp ett index i shards för att göra processen med att lägga till partitioner snabbare (genom att flytta shards till nya sökenheter). I en söktjänst är shardhantering en implementeringsinformation och kan inte konfigureras, men att veta att ett index är fragmenterat hjälper till att förstå tillfälliga avvikelser i rangordnings- och automatisk kompletteringsbeteenden:

• Rankningsavvikelser: Sökpoäng beräknas först på shardnivå och aggregeras sedan till en enda resultatuppsättning. Beroende på egenskaperna för shardinnehåll kan matchningar från en shard rangordnas högre än matchningar i en annan. Om du ser intuitiva räknare i sökresultat beror det troligtvis på effekterna av horisontell partitionering, särskilt om indexen är små. Du kan undvika dessa rankningsavvikelser genom att välja att beräkna poäng globalt i hela indexet, men detta medför en prestandastraff.

• Autokomplettera avvikelser: Komplettera automatiskt frågor, där matchningar görs på de första flera tecknen i en delvis angiven term, accepterar en fuzzy-parameter som förlåter små avvikelser i stavning. För automatisk komplettering begränsas fuzzy-matchning till termer inom den aktuella sharden. Om en shard till exempel innehåller "Microsoft" och en partiell term för "mikro" anges matchar sökmotorn "Microsoft" i fragmentet, men inte i andra shards som innehåller de återstående delarna av indexet.

Följande diagram visar relationen mellan repliker, partitioner, fragment och sökenheter. Den visar ett exempel på hur ett enda index sträcker sig över fyra sökenheter i en tjänst med två repliker och två partitioner. Var och en av de fyra sökenheterna lagrar bara hälften av indexets fragment. Sökenheterna i den vänstra kolumnen lagrar den första halvan av fragmenten, som består av den första partitionen, medan de i den högra kolumnen lagrar den andra halvan av fragmenten, som består av den andra partitionen. Eftersom det finns två repliker finns det två kopior av varje indexshard. Sökenheterna på den översta raden lagrar en kopia, bestående av den första repliken, medan de på den nedre raden lagrar en annan kopia, som består av den andra repliken.

Diagrammet ovan är bara ett exempel. Många kombinationer av partitioner och repliker är möjliga, upp till högst 36 totala sökenheter.

Poängstatistik och klibbiga sessioner

För skalbarhet distribuerar Azure AI Search varje index horisontellt genom en horisontell partitioneringsprocess, vilket innebär att delar av ett index är fysiskt åtskilda.

Som standard beräknas poängen för ett dokument baserat på statistiska egenskaper för data i ett fragment. Den här metoden är vanligtvis inte ett problem för en stor mängd data och ger bättre prestanda än att behöva beräkna poängen baserat på information över alla shards. Med den här prestandaoptimeringen kan det dock leda till att två mycket liknande dokument (eller till och med identiska dokument) får olika relevanspoäng om de hamnar i olika fragment.

Om du föredrar att beräkna poängen baserat på de statistiska egenskaperna för alla shards kan du göra det genom att lägga till scoringStatistics=global som en frågeparameter (eller lägga till "scoringStatistics": "global" som en brödtextparameter för frågebegäran).

POST https://[service name].search.windows.net/indexes/hotels/docs/search?api-version=2024-07-01
{
    "search": "<query string>",
    "scoringStatistics": "global"
}

Om du använder scoringStatistics ser du till att alla shards i samma replik ger samma resultat. Med det sagt kan olika repliker skilja sig något från varandra eftersom de alltid uppdateras med de senaste ändringarna i ditt index. I vissa scenarier kanske du vill att användarna ska få mer konsekventa resultat under en "frågesession". I sådana scenarier kan du ange en som en sessionId del av dina frågor. sessionId är en unik sträng som du skapar för att referera till en unik användarsession.

POST https://[service name].search.windows.net/indexes/hotels/docs/search?api-version=2024-07-01
{
    "search": "<query string>",
    "sessionId": "<string>"
}

Så länge samma sessionId sak används görs ett bästa försök att rikta in sig på samma replik, vilket ökar konsekvensen för de resultat som användarna ser.

Relevansjustering

I Azure AI Search kan du konfigurera BM25-algoritmparametrar och justera sökrelevans och öka sökpoängen genom följande mekanismer:

featuresMode-parameter (förhandsversion)

Begäranden om sökdokument stöder en featuresMode-parameter som ger mer information om en relevanspoäng på fältnivå. @searchScore Medan är beräknat för dokumentets all-up (hur relevant är det här dokumentet i samband med den här frågan), visar featuresMode information om enskilda fält, som uttrycks i en @search.features struktur. Strukturen innehåller alla fält som används i frågan (antingen specifika fält via sökfält i en fråga eller alla fält som tillskrivs som sökbara i ett index).

För varje fält @search.features ger du följande värden:

• Antal unika token som finns i fältet
• Likhetspoäng, eller ett mått på hur likt innehållet i fältet är, i förhållande till frågetermen
• Termfrekvens eller antalet gånger som frågetermen hittades i fältet

För en fråga som riktar sig mot fälten "description" och "title" kan ett svar som innehåller @search.features se ut så här:

"value": [
 {
    "@search.score": 5.1958685,
    "@search.features": {
        "description": {
            "uniqueTokenMatches": 1.0,
            "similarityScore": 0.29541412,
            "termFrequency" : 2
        },
        "title": {
            "uniqueTokenMatches": 3.0,
            "similarityScore": 1.75451557,
            "termFrequency" : 6
        }
    }
 }
]

Du kan använda dessa datapunkter i anpassade bedömningslösningar eller använda informationen för att felsöka problem med sökrelevans.

Parametern featuresMode finns inte dokumenterad i REST-API:erna, men du kan använda den vid ett REST API-förhandsgranskningsanrop till Sök dokument.

Antal rankade resultat i ett frågesvar i fulltext

Om du inte använder sidnumrering returnerar sökmotorn som standard de 50 högst rankade matchningarna för fulltextsökning. Du kan använda parametern top för att returnera ett mindre eller större antal objekt (upp till 1 000 i ett enda svar). Fulltextsökning omfattas av en maximal gräns på 1 000 matchningar (se API-svarsgränser). När 1 000 matchningar har hittats letar sökmotorn inte längre efter fler.

Om du vill returnera mer eller mindre resultat använder du växlingsparametrarna top, skipoch next. Växling är hur du fastställer antalet resultat på varje logisk sida och navigerar genom den fullständiga nyttolasten. Mer information finns i Så här arbetar du med sökresultat.

Se även

• Bedömningsprofiler
• REST API-referens
• API för sökdokument
• Azure AI Search .NET SDK