Relevancia a kulcsszókeresésben (BM25 pontozás)
Ez a cikk a teljes szöveges keresés keresési pontszámainak kiszámításához használt BM25 relevanciapontozási algoritmust ismerteti. A BM25 relevanciája kizárólag a teljes szöveges keresésre használható. A szűrőlekérdezések, az automatikus kiegészítés és a javasolt lekérdezések, a helyettesítő karakterek és a homályos keresési lekérdezések nem pontozottak vagy rangsorolva a relevancia szempontjából.
A teljes szöveges keresésben használt pontozási algoritmusok
Az Azure AI Search a következő pontozási algoritmusokat biztosítja a teljes szöveges kereséshez:
Algoritmus | Használat | Tartomány |
---|---|---|
BM25Similarity |
Kijavítottuk a 2020 júliusa után létrehozott összes keresési szolgáltatás algoritmusát. Ezt az algoritmust konfigurálhatja, de nem válthat régebbire (klasszikusra). | Korlátos. |
ClassicSimilarity |
A 2020. júliust megelőző régebbi keresési szolgáltatások alapértelmezett értéke. A régebbi szolgáltatásokban a BM25-öt is választhatja, és indexenkénti alapon választhatja ki a BM25 algoritmust. | 0 < 1,00 |
A BM25 és a klasszikus egyaránt TF-IDF-szerű lekérési függvények, amelyek a kifejezés gyakoriságát (TF) és az inverz dokumentum gyakoriságát (IDF) használják változóként az egyes dokumentumlekérdezési párok relevanciájának kiszámításához, amelyet aztán a rangsorolási eredményekhez használnak. Bár a klasszikushoz fogalmilag hasonló, a BM25 olyan valószínűségi információlekérésben gyökerezik, amely intuitívabb egyezéseket hoz létre a felhasználói kutatások alapján.
A BM25 speciális testreszabási lehetőségeket kínál, például lehetővé teszi a felhasználó számára, hogy eldöntse, hogyan skálázható a relevanciapont a egyeztetett kifejezések kifejezési gyakoriságával.
A BM25 rangsorolásának működése
A relevanciapontszámozás egy keresési pontszám (@search.score) számítására utal, amely egy elem relevanciájának mutatójaként szolgál az aktuális lekérdezés kontextusában. A tartomány nem kötött. Minél magasabb a pontszám, annál relevánsabb az elem.
A keresési pontszám kiszámítása a sztringbemenet és maga a lekérdezés statisztikai tulajdonságai alapján történik. Az Azure AI Search megkeresi a keresési kifejezésekkel egyező dokumentumokat (a keresési módtól függően néhányat vagy az összeset), előnyben részesítve a keresési kifejezés számos példányát tartalmazó dokumentumokat. A keresési pontszám még magasabb lesz, ha a kifejezés ritka az adatindexben, de gyakori a dokumentumban. A számítási relevancia ezen megközelítésének alapja a TF-IDF vagy a kifejezés frekvencia inverz dokumentum gyakorisága.
A keresési pontszámok a találatkészlet egészében megismételhetők. Ha több találat is azonos keresési pontszámmal rendelkezik, az azonos pontszámú elemek sorrendje nincs meghatározva, és nem stabil. Futtassa újra a lekérdezést, és előfordulhat, hogy az elemek eltolódnak, különösen akkor, ha az ingyenes szolgáltatást vagy a több replikával rendelkező számlázható szolgáltatást használja. Két azonos pontszámú elem esetén nincs garancia arra, hogy előbb megjelenik az egyik.
Ha meg szeretné szakítani a döntetlent az ismétlődő pontszámok között, hozzáadhat egy $orderby záradékot az első sorrendhez pontszám szerint, majd rendezhet egy másik rendezhető mező szerint (például $orderby=search.score() desc,Rating desc
).
A rendszer csak az indexben vagy searchFields
a lekérdezésben megjelölt searchable
mezőket használja a pontozáshoz. Csak a lekérdezésben select
megadottként retrievable
megjelölt mezők vagy mezők jelennek meg a keresési eredményekben, a keresési pontszámukkal együtt.
Feljegyzés
Az A @search.score = 1
nem pontozott vagy nem rangsorolt eredményhalmazt jelöl. A pontszám minden eredményben egységes. A nem pontozott eredmények akkor fordulnak elő, ha a lekérdezési űrlap zavaros keresés, helyettesítő vagy regex lekérdezés, vagy üres keresés (search=*
néha szűrőkkel párosítva, ahol a szűrő az elsődleges eszköz egyezés visszaadására).
Az alábbi videószegmens gyorsan elérhetővé válik az Azure AI Searchben használt általánosan elérhető rangsorolási algoritmusok magyarázatához. A teljes videót a további háttérért tekintheti meg.
Pontszámok szöveges eredményekben
Az eredmények rangsorolásakor @search.score
a tulajdonság az eredmények rendezéséhez használt értéket tartalmazza.
Az alábbi táblázat a pontozási tulajdonságot, az algoritmust és a tartományt azonosítja.
Keresési módszer | Paraméter | Pontozási algoritmus | Tartomány |
---|---|---|---|
teljes szöveges keresés | @search.score |
BM25 algoritmus az indexben megadott paraméterekkel. | Korlátos. |
Pontszám variációja
A keresési pontszámok általános relevanciaérzetet közvetítenek, amely tükrözi az egyezés erősségét az azonos eredményhalmazban lévő többi dokumentumhoz képest. A pontszámok azonban nem mindig konzisztensek az egyik lekérdezéstől a másikig, így a lekérdezések használatakor kis eltéréseket tapasztalhat a keresési dokumentumok sorrendjében. Ennek okaira több magyarázat is létezik.
Ok | Leírás |
---|---|
Azonos pontszámok | Ha több dokumentum is ugyanazt a pontszámot használja, azok bármelyike megjelenhet először. |
Adatingadozás | Az index tartalma a dokumentumok hozzáadása, módosítása vagy törlésekor változik. A kifejezés gyakorisága az indexfrissítések idővel történő feldolgozásakor változik, ami hatással van az egyező dokumentumok keresési pontszámára. |
Több replika | A több replikát használó szolgáltatások esetében a rendszer az egyes replikákra párhuzamosan bocsát ki lekérdezéseket. A keresési pontszám kiszámításához használt indexstatisztikákat replikánként számítja ki a rendszer, az eredményeket egyesítve és rendezve a lekérdezési válaszban. A replikák többnyire egymás tükörképei, de a statisztikák az állapot kis eltérései miatt eltérhetnek. Előfordulhat például, hogy egy replika törölte a statisztikájukhoz hozzájáruló dokumentumokat, amelyeket más replikákból egyesítettek. A replikánkénti statisztikák különbségei általában észrevehetőbbek a kisebb indexekben. A következő szakasz további információt nyújt erről a feltételről. |
Horizontális skálázási hatások a lekérdezési eredményekre
A szegmens egy index darabja. Az Azure AI Search szegmensekre bontja az indexeket, hogy felgyorsítsa a partíciók hozzáadását (a szegmensek új keresési egységekbe való áthelyezésével). A keresési szolgáltatásban a szegmenskezelés implementálási részlet és nem konfigurálható, de az index horizontális felosztásának ismerete segít megérteni a rangsorolási és automatikus kiegészítési viselkedések időnkénti rendellenességeit:
Rangsorolási anomáliák: A keresési pontszámokat először a szegmens szintjén számítjuk ki, majd összesítjük egyetlen eredményhalmazba. A szegmenstartalom jellemzőitől függően előfordulhat, hogy az egyik szegmens egyezései magasabbak, mint a másiké. Ha a keresési eredményekben az intuitív rangsorolást észleli, az valószínűleg a horizontális skálázás hatásainak köszönhető, különösen akkor, ha az indexek kicsik. Ezeket a rangsorolási anomáliákat elkerülheti, ha úgy dönt, hogy globálisan számítja ki a pontszámokat a teljes indexben, de ez teljesítménybeli büntetést von maga után.
Automatikus kiegészítési anomáliák: Automatikus kiegészítési lekérdezések, amelyekben a részben megadott kifejezés első néhány karakterében egyezések jönnek létre, fogadjon el egy homályos paramétert, amely megbocsátja a helyesírás kis eltéréseit. Az automatikus kiegészítés esetében a homályos egyezés az aktuális szegmensen belüli kifejezésekre van korlátozva. Ha például egy szegmens tartalmazza a "Microsoft"-t, és a "mikro" kifejezés részleges kifejezése be van írva, a keresőmotor a "Microsoft" kifejezéssel fog egyezni az adott szegmensben, de az index fennmaradó részeit tartalmazó többi szegmensben nem.
Az alábbi ábra a replikák, partíciók, szegmensek és keresési egységek közötti kapcsolatot mutatja be. Egy példát mutat be arra, hogy egy adott index hogyan van átfogva egy szolgáltatás négy keresési egységén két replikával és két partícióval. A négy keresési egység mindegyike az index szegmenseinek csak a felét tárolja. A bal oldali oszlop keresési egységei a szegmensek első felét tárolják, amely az első partíciót tartalmazza, míg a jobb oldali oszlopban lévők a szegmensek második felét tárolják, amely a második partíciót tartalmazza. Mivel két replika létezik, minden indexszilánk két példánya van. A felső sor keresési egységei egy példányt tárolnak, amely az első replikát tartalmazza, míg az alsó sorban lévők egy másik példányt tárolnak, amely a második replikát tartalmazza.
A fenti diagram csak egy példa. A partíciók és replikák számos kombinációja lehetséges, legfeljebb 36 keresési egységig.
Feljegyzés
A replikák és partíciók száma egyenletesen 12-re oszlik (pontosabban 1, 2, 3, 4, 6, 12). Az Azure AI Search előre osztja el az egyes indexeket 12 szegmensre, így egyenlő részekben osztható el az összes partíción. Ha például a szolgáltatás három partícióval rendelkezik, és létrehoz egy indexet, minden partíció az index négy szegmensét fogja tartalmazni. Hogy az Azure AI Search hogyan szilánkokat oszt meg egy indexben, az implementáció részletei, a későbbi kiadásokban változhat. Bár a szám ma 12, nem várható, hogy ez a szám mindig 12 lesz a jövőben.
Pontozási statisztikák és ragadós munkamenetek
A méretezhetőség érdekében az Azure AI Search horizontálisan osztja el az indexeket horizontálisan, horizontálisan, ami azt jelenti, hogy az index egyes részei fizikailag elkülönülnek egymástól.
Alapértelmezés szerint egy dokumentum pontszáma a szegmensen belüli adatok statisztikai tulajdonságai alapján lesz kiszámítva. Ez a megközelítés általában nem jelent problémát nagy adathalmazok esetében, és jobb teljesítményt nyújt, mint az összes szegmens információi alapján kiszámítani a pontszámot. Ennek a teljesítményoptimalizálásnak a használata két nagyon hasonló dokumentumot (vagy akár azonos dokumentumot) okozhat, amelyek eltérő relevanciapontszámmal végződhetnek, ha különböző szegmensekbe kerülnek.
Ha inkább az összes szegmens statisztikai tulajdonságai alapján szeretné kiszámítani a pontszámot, ezt lekérdezési paraméterként (scoringStatistics=global
vagy a lekérdezési kérelem törzsparamétereként) is megteheti"scoringStatistics": "global"
.
POST https://[service name].search.windows.net/indexes/hotels/docs/search?api-version=2024-07-01
{
"search": "<query string>",
"scoringStatistics": "global"
}
A használat scoringStatistics
biztosítja, hogy az ugyanabban a replikában lévő összes szegmens ugyanazt az eredményt adja. Ennek ellenére a különböző replikák kissé eltérhetnek egymástól, mivel mindig frissülnek az index legújabb módosításaival. Bizonyos esetekben előfordulhat, hogy a felhasználók konzisztensebb eredményeket szeretnének kapni egy lekérdezési munkamenet során. Ilyen esetekben a lekérdezések részeként is megadható sessionId
. Ez sessionId
egy egyedi sztring, amelyet egy egyedi felhasználói munkamenetre hivatkozva hoz létre.
POST https://[service name].search.windows.net/indexes/hotels/docs/search?api-version=2024-07-01
{
"search": "<query string>",
"sessionId": "<string>"
}
Mindaddig, amíg ugyanazt sessionId
használja, a rendszer minden tőle telhetőt megtesz annak érdekében, hogy ugyanazt a replikát célozza meg, ezzel növelve a felhasználók által látott eredmények konzisztenciáját.
Feljegyzés
Ugyanazon sessionId
értékek ismételt újrafelhasználása megzavarhatja a kérések terheléselosztását a replikák között, és hátrányosan befolyásolhatja a keresési szolgáltatás teljesítményét. A munkamenet-azonosítóként használt érték nem kezdődhet "_" karakterrel.
Relevanciahangolás
Az Azure AI Searchben a kulcsszókereséshez és a hibrid lekérdezés szöveges részéhez konfigurálhatja a BM25-algoritmus paramétereit, valamint hangolhatja a keresési relevanciát, és az alábbi mechanizmusokkal növelheti a keresési pontszámokat.
Módszer | Megvalósítás | Leírás |
---|---|---|
BM25-algoritmus konfigurálása | Keresési index | Konfigurálja, hogy a dokumentum hossza és a kifejezés gyakorisága hogyan befolyásolja a relevanciapontszámot. |
Pontozási profilok | Keresési index | Adjon meg feltételeket az egyezés keresési pontszámának a tartalom jellemzői alapján történő növeléséhez. Például növelheti a találatokat a bevételi potenciáljuk alapján, előléptetheti az újabb elemeket, vagy növelheti a túl hosszú leltárban lévő elemeket. A pontozási profil az indexdefiníció része, amely súlyozott mezőkből, függvényekből és paraméterekből áll. A meglévő indexeket a pontozási profil módosításaival frissítheti anélkül, hogy az index újraépítése történne. |
Szemantikai rangsorolás | Lekérdezési kérelem | Gépi olvasási megértést alkalmaz a keresési eredményekre, előtérbe hozva a szemantikailag relevánsabb találatokat. |
featuresMode paraméter | Lekérdezési kérelem | Ezt a paramétert többnyire egy BM25 rangsorolt pontszám kicsomagolására használják, de egyéni pontozási megoldást biztosító kódban is használható. |
featuresMode paraméter (előzetes verzió)
A keresési dokumentumok kérései támogatnak egy featuresMode paramétert, amely részletesebben ismerteti a BM25 relevanciapontszámát a mező szintjén. Míg a számítás a @searchScore
teljes dokumentumra vonatkozik (mennyire releváns ez a dokumentum a lekérdezés kontextusában), a featuresMode az egyes mezőkkel kapcsolatos információkat fedi fel egy struktúrában @search.features
kifejezve. A struktúra tartalmazza a lekérdezésben használt összes mezőt (vagy adott mezőket a lekérdezésben a searchFieldsen keresztül, vagy az indexben kereshetőként tulajdonított összes mezőt).
Minden mezőhöz @search.features
adja meg a következő értékeket:
- A mezőben található egyedi tokenek száma
- Hasonlósági pontszám vagy a mező tartalmának a lekérdezési kifejezéshez viszonyított hasonlóságának mértéke
- Kifejezés gyakorisága vagy a lekérdezési kifejezés számának száma a mezőben
A "leírás" és a "cím" mezőket megcélozó lekérdezések esetében a következőhöz @search.features
hasonló válasz jelenhet meg:
"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
}
}
}
]
Ezeket az adatpontokat egyéni pontozási megoldásokban használhatja fel, vagy az információk segítségével hibakeresési relevanciával kapcsolatos problémákat kereshet.
A featuresMode paraméter nincs dokumentálva a REST API-kban, de használhatja egy előzetes REST API-hívásban, amely a BM25-rangsorolt szöveges (kulcsszóalapú) kereséseket keresi.
Rangsorolt találatok száma teljes szöveges lekérdezési válaszban
Ha nem lapozást használ, a keresőmotor alapértelmezés szerint a teljes szöveges keresés 50 legmagasabb rangsorolási egyezését adja vissza. A top
paraméterrel kisebb vagy nagyobb számú elemet adhat vissza (egyetlen válaszban akár 1000-et is). Használhatja skip
és next
használhatja a találatokat. A lapozás határozza meg az egyes logikai oldalakon található eredmények számát, és támogatja a tartalomnavigációt. További információ: Alakzatkeresési eredmények.
Ha a teljes szöveges lekérdezés egy hibrid lekérdezés része, beállíthatja maxTextRecallSize
, hogy növelje vagy csökkentse a lekérdezés szöveges oldaláról származó eredmények számát.
A teljes szöveges keresésre legfeljebb 1000 egyezés vonatkozik (lásd az API válaszkorlátait). Ha 1000 találatot talál, a keresőmotor már nem keres többet.