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 nebo 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í:

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ů. Další informace najdete v tématu Konfigurace algoritmu vyhodnocování.

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

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). Další informace najdete v tématu $orderby.

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

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í vrácenou pro každou shodu, algoritmus a rozsah.

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.

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

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

Upřesnění relevance

Ve službě Azure AI Search můžete nakonfigurovat parametry algoritmu BM25 a ladit relevanci vyhledávání a zvýšit skóre hledání pomocí těchto mechanismů:

featuresMode – parametr (Preview)

Žádosti o vyhledávací dokumenty podporují parametr featuresMode, který poskytuje podrobnější informace o skóre relevance 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í dokumentů.

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

Chcete-li vrátit více nebo méně výsledků, použijte parametry topstránkování , skipa next. Stránkování určuje počet výsledků na každé logické stránce a prochází celou datovou část. Další informace naleznete v tématu Jak pracovat s výsledky hledání.

Viz také

• Profily bodování
• Reference k rozhraní REST API
• Rozhraní API pro hledání dokumentů
• Azure AI Search .NET SDK