Relevance při hledání klíčových slov (bodování BM25)
Tento článek vysvětluje algoritmus vyhodnocování relevance BM25, který se používá k výpočtu skóre hledání pro fulltextové vyhledávání. Relevance BM25 je výhradní pro fulltextové vyhledávání. Filtrování dotazů, automatického dokončování a navrhovaných dotazů, vyhledávání se zástupnými znamény a přibližných vyhledávacích dotazů nevyhodnotuje ani seřadí podle relevance.
Algoritmy bodování používané při fulltextové vyhledávání
Azure AI Search poskytuje následující algoritmy bodování pro fulltextové vyhledávání:
| Algoritmus | Využití | Rozsah |
|---|---|---|
BM25Similarity |
Pevný algoritmus pro všechny vyhledávací služby vytvořené po červenci 2020 Tento algoritmus můžete nakonfigurovat, ale nemůžete přepnout na starší (klasický). | Neomezený. |
ClassicSimilarity |
Výchozí nastavení starších vyhledávacích služeb, které předchází červenci 2020. Ve starších službách se můžete přihlásit k BM25 a zvolit algoritmus BM25 pro jednotlivé indexy. | 0 < 1,00 |
BM25 i Classic jsou funkce načítání podobné TF-IDF, které používají frekvenci termínů (TF) a inverzní frekvenci dokumentů (IDF) jako proměnné k výpočtu skóre relevance pro každou dvojici dotazů dokumentu, která se pak používá pro výsledky řazení. I když se koncepčně podobá klasickému modelu, BM25 je kořenem v pravděpodobnostním načítání informací, které vytváří intuitivnější shody měřené výzkumem uživatelů.
BM25 nabízí pokročilé možnosti přizpůsobení, například umožnit uživateli rozhodnout se, jak se skóre relevance škáluje s frekvencí termínů odpovídajících termínů.
Jak funguje hodnocení BM25
Bodování relevance odkazuje na výpočet skóre hledání (@search.score), které slouží jako indikátor relevance položky v kontextu aktuálního dotazu. Rozsah není nevázaný. Čím vyšší je ale skóre, tím relevantnější položka.
Skóre hledání se vypočítá na základě statistických vlastností vstupu řetězce a samotného dotazu. Azure AI Search najde dokumenty, které odpovídají hledanému výrazu (některé nebo všechny v závislosti na modulu searchMode), a upřednostňuje dokumenty, které obsahují mnoho instancí hledaného termínu. Skóre hledání je ještě vyšší, pokud je termín v indexu dat vzácný, ale společný v dokumentu. Základem tohoto přístupu k výpočtům relevance se označuje jako TF-IDF nebo frekvence inverzních dokumentů.
Skóre hledání je možné opakovat v celé sadě výsledků. Pokud má více přístupů stejné skóre hledání, pořadí stejných shodnocených položek není definováno a není stabilní. Spusťte dotaz znovu a může se zobrazit pozice posunu položek, zejména pokud používáte bezplatnou službu nebo fakturovatelnou službu s více replikami. Vzhledem k dvěma položkám s identickým skóre neexistuje žádná záruka, že se jedna zobrazí jako první.
Chcete-li přerušit vazby mezi opakujícími se skóre, můžete přidat klauzuli $orderby k prvnímu pořadí podle skóre a pak pořadí podle jiného seřazeného pole (například$orderby=search.score() desc,Rating desc).
K bodování se používají pouze pole označená jako searchable v indexu nebo searchFields v dotazu. Ve výsledcích hledání se vrátí pouze pole označená jako retrievablepole nebo pole zadaná v select dotazu spolu s jejich skóre hledání.
Poznámka:
A @search.score = 1 označuje nehodnocenou nebo neseřazenou sadu výsledků. Skóre je jednotné pro všechny výsledky. Nehodnocené výsledky se zobrazí, když je formulář dotazu přibližný hledání, zástupné znamény nebo dotazy regulárního výrazu nebo prázdné hledání (search=*někdy spárované s filtry, kde je filtr primárním prostředkem pro vrácení shody).
Následující video segment rychle předává vysvětlení obecně dostupných algoritmů řazení používaných ve službě Azure AI Search. Na celé video se můžete podívat na další pozadí.
Skóre ve výsledcích textu
Pokaždé, když jsou výsledky seřazené, @search.score vlastnost obsahuje hodnotu použitou k seřazení výsledků.
Následující tabulka identifikuje vlastnost bodování, algoritmus a rozsah.
| Metoda vyhledávání | Parametr | Algoritmus bodování | Rozsah |
|---|---|---|---|
| Fulltextové vyhledávání | @search.score |
Algoritmus BM25 používající parametry zadané v indexu. | Neomezený. |
Varianta skóre
Skóre hledání vyjadřuje obecný smysl pro relevanci a odráží sílu shody vzhledem k ostatním dokumentům ve stejné sadě výsledků. Skóre ale nejsou vždy konzistentní z jednoho dotazu na další, takže při práci s dotazy si můžete všimnout malých nesrovnalostí v tom, jak jsou hledané dokumenty seřazené. Existuje několik vysvětlení, proč k tomu může dojít.
| Příčina | Popis |
|---|---|
| Identické skóre | Pokud má více dokumentů stejné skóre, může se některý z nich objevit jako první. |
| Volatilita dat | Obsah indexu se při přidávání, úpravách nebo odstraňování dokumentů liší. Frekvence termínů se změní, protože aktualizace indexu se zpracovávají v průběhu času, což má vliv na skóre hledání odpovídajících dokumentů. |
| Více replik | U služeb používajících více replik se dotazy vydávají na každou repliku paralelně. Statistiky indexu použité k výpočtu skóre hledání se počítají na základě jednotlivých replik s výsledky sloučenými a seřazenými v odpovědi dotazu. Repliky se většinou zrcadlí, ale statistiky se můžou lišit v důsledku malých rozdílů ve stavu. Jedna replika může například odstranit dokumenty, které přispívají do statistiky, které byly sloučeny z jiných replik. Rozdíly ve statistikách jednotlivých replik jsou obvykle výraznější v menších indexech. Následující část obsahuje další informace o této podmínce. |
Efekty horizontálního dělení na výsledky dotazu
Horizontální oddíl je blok indexu. Azure AI Search rozdělí index do horizontálních oddílů, aby se proces přidávání oddílů zrychlil (přesunutím horizontálních oddílů do nových jednotek vyhledávání). Ve vyhledávací službě je správa horizontálních oddílů podrobností implementace a nekonfigurovatelná, ale znalost horizontálního dělení indexu pomáhá pochopit občasné anomálie při řazení a chování automatického dokončování:
Anomálie řazení: Skóre hledání se nejprve počítají na úrovni horizontálních oddílů a pak se agregují do jedné sady výsledků. V závislosti na vlastnostech obsahu horizontálních oddílů můžou být shody z jednoho horizontálního oddílu seřazené výš než shody v druhém. Pokud si všimnete čítačů intuitivního řazení ve výsledcích hledání, je to s největší pravděpodobností způsobeno vlivem horizontálního dělení, zejména pokud jsou indexy malé. Těmto anomáliím řazení se můžete vyhnout tím, že se rozhodnete vypočítat skóre globálně v celém indexu, ale tím dojde k penalizaci výkonu.
Automatické dokončování anomálií: Automatické dokončování dotazů, ve kterých jsou shody provedeny na prvních několika znacích částečně zadaného termínu, přijměte přibližný parametr, který odpouští malé odchylky v pravopisu. U automatického dokončování je přibližné porovnávání omezené na termíny v rámci aktuálního horizontálního oddílu. Pokud například horizontální oddíl obsahuje "Microsoft" a zadá se částečný termín "mikro", bude vyhledávací modul v tomto horizontálním oddílu odpovídat hodnotě Microsoft, ale ne v jiných horizontálních oddílech, které obsahují zbývající části indexu.
Následující diagram znázorňuje vztah mezi replikami, oddíly, horizontálními oddíly a jednotkami vyhledávání. Ukazuje příklad, jak se jeden index rozděluje do čtyř jednotek hledání ve službě se dvěma replikami a dvěma oddíly. Každý ze čtyř jednotek vyhledávání ukládá pouze polovinu horizontálních oddílů indexu. Vyhledávací jednotky v levém sloupci ukládají první polovinu horizontálních oddílů, které tvoří první oddíl, zatímco ty v pravém sloupci ukládají druhou polovinu horizontálních oddílů, které tvoří druhý oddíl. Vzhledem k tomu, že existují dvě repliky, existují dvě kopie každého horizontálního oddílu indexu. Jednotky vyhledávání v horním řádku ukládají jednu kopii, která tvoří první repliku, zatímco ty v dolním řádku ukládají další kopii, která tvoří druhou repliku.
Výše uvedený diagram je pouze jedním příkladem. Je možné použít mnoho kombinací oddílů a replik, maximálně 36 celkového počtu jednotek vyhledávání.
Poznámka:
Počet replik a oddílů se rovnoměrně dělí na 12 (konkrétně 1, 2, 3, 4, 6, 12). Azure AI Search předem rozdělí každý index na 12 horizontálních oddílů, aby se mohl rozdělit do stejných částí napříč všemi oddíly. Pokud má například vaše služba tři oddíly a vytvoříte index, každý oddíl bude obsahovat čtyři horizontální oddíly indexu. Způsob horizontálního dělení indexu ve službě Azure AI Search představuje podrobnosti implementace, které se můžou v budoucích verzích změnit. I když je číslo dnes 12, neměli byste očekávat, že by toto číslo v budoucnu vždy bylo 12.
Statistiky vyhodnocování a rychlé relace
Kvůli škálovatelnosti azure AI Search distribuuje každý index horizontálně prostřednictvím procesu horizontálního dělení, což znamená, že části indexu jsou fyzicky oddělené.
Ve výchozím nastavení se skóre dokumentu počítá na základě statistických vlastností dat v rámci horizontálního oddílu. Tento přístup obecně není problémem u velkého korpusu dat a poskytuje lepší výkon než výpočet skóre na základě informací napříč všemi horizontálními oddíly. Použití této optimalizace výkonu může způsobit, že dva velmi podobné dokumenty (nebo dokonce stejné dokumenty) skončí s různými skóre relevance, pokud skončí v různých horizontálních oddílech.
Pokud dáváte přednost výpočtu skóre na základě statistických vlastností napříč všemi horizontálními oddíly, můžete to udělat tak scoringStatistics=global , že přidáte jako parametr dotazu (nebo ho přidáte "scoringStatistics": "global" jako základní parametr požadavku dotazu).
POST https://[service name].search.windows.net/indexes/hotels/docs/search?api-version=2024-07-01
{
"search": "<query string>",
"scoringStatistics": "global"
}
Použití scoringStatistics zajistí, aby všechny horizontální oddíly ve stejné replice poskytovaly stejné výsledky. To znamená, že různé repliky se můžou mírně lišit od sebe, protože se neustále aktualizují o nejnovější změny indexu. V některých scénářích můžete chtít, aby uživatelé získali konzistentnější výsledky během "relace dotazů". V takových scénářích můžete zadat sessionId jako součást dotazů. Jedná se sessionId o jedinečný řetězec, který vytvoříte, který odkazuje na jedinečnou uživatelskou relaci.
POST https://[service name].search.windows.net/indexes/hotels/docs/search?api-version=2024-07-01
{
"search": "<query string>",
"sessionId": "<string>"
}
Pokud se použije stejný postup, provede se pokus o dosažení stejného sessionId cíle na stejnou repliku a zvýší konzistenci výsledků, které uvidí vaši uživatelé.
Poznámka:
Opakované použití stejných sessionId hodnot může narušit vyrovnávání zatížení požadavků napříč replikami a nepříznivě ovlivnit výkon vyhledávací služby. Hodnota použitá jako sessionId nemůže začínat znakem _.
Upřesnění relevance
Ve službě Azure AI Search můžete pro vyhledávání klíčových slov a textovou část hybridního dotazu nakonfigurovat parametry algoritmu BM25 a ladit relevanci vyhledávání a zvýšit skóre hledání pomocí následujících mechanismů.
| Přístup | Implementace | Popis |
|---|---|---|
| Konfigurace algoritmu BM25 | Index vyhledávání | Nakonfigurujte, jak délka dokumentu a frekvence období ovlivňují skóre relevance. |
| Profily skórování | Index vyhledávání | Zadejte kritéria pro zvýšení skóre hledání shody na základě charakteristik obsahu. Můžete například zvýšit počet shod na základě jejich potenciálních výnosů, zvýšit úroveň novějších položek nebo zvýšit počet položek, které byly v inventáři příliš dlouho. Bodovací profil je součástí definice indexu, která se skládá z vážených polí, funkcí a parametrů. Existující index můžete aktualizovat o změny hodnoticího profilu bez nutnosti opětovného sestavení indexu. |
| Sémantické řazení | Žádost o dotaz | Aplikuje strojové čtení na výsledky hledání a podporuje více sémanticky relevantních výsledků na začátek. |
| featuresMode – parametr | Žádost o dotaz | Tento parametr se většinou používá k rozbalení skóre seřazeného podle BM25, ale dá se použít v kódu, který poskytuje vlastní bodovací řešení. |
featuresMode – parametr (Preview)
Žádosti o vyhledávací dokumenty podporují parametr featuresMode, který poskytuje podrobnější informace o skóre relevance BM25 na úrovni pole. Zatímco se @searchScore vypočítává pro celý dokument (jak je tento dokument relevantní v kontextu tohoto dotazu), funkceMode odhalí informace o jednotlivých polích, jak je vyjádřeno ve @search.features struktuře. Struktura obsahuje všechna pole použitá v dotazu (buď konkrétní pole prostřednictvím vyhledávacích polí v dotazu, nebo všechna pole, která jsou přiřazená jako prohledávatelná v indexu).
Pro každé pole @search.features zadejte následující hodnoty:
- Počet jedinečných tokenů nalezených v poli
- Skóre podobnosti nebo míra toho, jak je obsah pole podobný, vzhledem k termínu dotazu
- Frekvence termínů nebo počet nalezených termínů v poli
U dotazu, který cílí na pole popis a název, může odpověď, která obsahuje @search.features , vypadat takto:
"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
}
}
}
]
Tyto datové body můžete využívat ve vlastních řešeních bodování nebo pomocí informací ladit problémy s relevanci vyhledáváním.
Parametr featuresMode není zdokumentovaný v rozhraních REST API, ale můžete ho použít při volání rozhraní REST API ve verzi Preview pro vyhledávání v dokumentech pro vyhledávání textu (klíčové slovo), které je seřazené podle BM25.
Počet seřazených výsledků v odpovědi na fulltextový dotaz
Pokud ve výchozím nastavení nepoužíváte stránkování, vrátí vyhledávací web prvních 50 nejlepších shod pro fulltextové vyhledávání. Pomocí parametru top můžete vrátit menší nebo větší počet položek (až 1 000 v jedné odpovědi). Výsledky můžete použít skip a next zobrazit na stránce. Stránkování určuje počet výsledků na každé logické stránce a podporuje navigaci v obsahu. Další informace najdete v tématu Výsledky hledání obrazců.
Fulltextové vyhledávání podléhá maximálnímu limitu 1 000 shod (viz limity odpovědí rozhraní API). Jakmile se najde 1 000 shod, vyhledávací web už nebude hledat víc.