Részletes navigáció hozzáadása a keresési eredményekhez

A faceted navigáció a lekérdezési eredmények önvezérelt szűrésére szolgál egy keresőalkalmazásban, ahol az alkalmazás űrlapvezérlőket kínál a dokumentumok csoportjaira (például kategóriákra vagy márkákra) történő keresés hatókörének meghatározásához, és Azure AI Keresés biztosítja az adatstruktúrákat és a szűrőket a felhasználói élményhez.

Ebben a cikkben megismerheti a Azure AI Keresés jellemző navigációs struktúrájának visszaállításának lépéseit. Miután megismerte az alapfogalmakat és az ügyfeleket, folytassa a Facettelési példákkal, ahol különböző használati esetek szintaxisával ismerkedhet meg, beleértve az alapszintű facettelést és az egyedi számításokat.

További funkciók érhetők el az előzetes verziójú API-kon keresztül:

• hierarchikus arculati struktúrák
• aspektusszűrés
• tulajdonság-összesítések

Az arculati navigációs példák az előzetes verziójú funkciók szintaxisát és használatát adják meg.

Szűrési navigáció egy keresési oldalon

Az aspektusok dinamikusak, mert minden egyes lekérdezési eredményhalmazon alapulnak. A keresési válasz magában hordozza az eredményben lévő dokumentumok közötti navigáláshoz használt összes aspektusgyűjtőt. A lekérdezés először végrehajtásra kerül, majd az aktuális eredmények alapján megformálják a metszeteket, és azok egy facettázott navigációs struktúrává állnak össze.

Az Azure AI Keresés esetében a facettek egy réteg mélyek, és csak akkor lehetnek hierarchikusak, ha az előzetes verziójú API-t használja. Ha nem ismeri a facettált navigációs struktúrákat, a következő példában láthat egyet a bal oldalon. A darabszám az egyes aspektusokhoz tartozó egyezések számát jelzi. Ugyanaz a dokumentum több aspektusban is megjeleníthető.

Az aspektusok segíthetnek megtalálni, amit keres, miközben biztosíthatja, hogy ne kapjon nulla eredményt. Fejlesztőként az aspektusok lehetővé teszik, hogy a keresési index navigálásához a legokosabb keresési feltételeket tegye közzé.

Arculati navigáció a kódban

Az aspektusok engedélyezve vannak egy index támogatott mezőiben, majd meg vannak adva egy lekérdezésben. A rendszer a válasz elején visszaadja a strukturált navigációs struktúrát, majd az eredményeket.

A következő REST-példa egy üres lekérdezés ("search": "*"), amely a teljes indexre terjed ki (lásd a beépített szállodák mintáját). A facets paraméter a "Kategória" mezőt adja meg.

POST https://{{service_name}}.search.windows.net/indexes/hotels-sample/docs/search?api-version={{api_version}}
{
    "search": "*",
    "queryType": "simple",
    "select": "",
    "searchFields": "",
    "filter": "",
    "facets": [ "Category"], 
    "orderby": "",
    "count": true
}

A példa válasza a strukturált navigációs struktúrával kezdődik. A struktúra a "Kategória" értékekből és az egyes szállodák számából áll. Ezt követi a többi keresési eredmény, itt vágva csak egy dokumentumot a rövidség kedvéért. Ez a példa több okból is jól működik. A mező aspektusainak száma a korlát alá esik (alapértelmezés szerint 10), így mindegyik megjelenik, és az 50 szálloda indexében szereplő összes szálloda pontosan az egyik ilyen kategóriában jelenik meg.

{
    "@odata.context": "https://demo-search-svc.search.windows.net/indexes('hotels-sample')/$metadata#docs(*)",
    "@odata.count": 50,
    "@search.facets": {
        "Category": [
            {
                "count": 13,
                "value": "Budget"
            },
            {
                "count": 12,
                "value": "Resort and Spa"
            },
            {
                "count": 9,
                "value": "Luxury"
            },
            {
                "count": 7,
                "value": "Boutique"
            },
            {
                "count": 5,
                "value": "Suite"
            },
            {
                "count": 4,
                "value": "Extended-Stay"
            }
        ]
    },
    "value": [
        {
            "@search.score": 1.0,
            "HotelId": "1",
            "HotelName": "Stay-Kay City Hotel",
            "Description": "The hotel is ideally located on the main commercial artery of the city in the heart of New York. A few minutes away is Time's Square and the historic centre of the city, as well as other places of interest that make New York one of America's most attractive and cosmopolitan cities.",
            "Category": "Boutique",
            "Tags": [
                "pool",
                "air conditioning",
                "concierge"
            ],
            "ParkingIncluded": false,
        },
        . . . 
    ]
}

Aspektusok engedélyezése mezőkön

Egyszerű szöveget vagy numerikus tartalmat tartalmazó új mezőkhöz adhat hozzá aspektusokat. A támogatott adattípusok közé tartoznak a sztringek, dátumok, logikai mezők és numerikus mezők (vektorok azonban nem).

Használhatja a Azure portal, REST API-kat, Azure SDK-kat vagy bármely olyan módszert, amely támogatja az indexséma létrehozását vagy frissítését Azure AI Keresés. Első lépésként határozza meg, hogy mely mezőket érdemes használni az arcfelismeréshez.

Adja meg, hogy mely mezőket szeretné attribútumként használni

Az aspektusok egyértékű mezők és gyűjtemények alapján számíthatók ki. A faceted navigációban a legjobban működő mezők a következő jellemzőkkel rendelkeznek:

• Emberi olvasásra alkalmas (nem vektoros) tartalom.
• Alacsony számosság (néhány különböző érték, amelyek a keresési korpusz dokumentumaiban ismétlődnek).
• Rövid leíró értékek (egy vagy két szó), amelyek jól jelennek meg egy navigációs struktúrában.

A mezőn belüli értékek, és nem maga a mezőnév, az aspektusokat egy strukturált navigációs struktúrában állítják elő. Ha az aspektus egy Szín nevű sztringmező, az aspektusok kékek, zöldek és a mező bármely más értéke. Tekintse át a mezőértékeket, és győződjön meg arról, hogy nincsenek elírások, null értékek vagy burkolati különbségek. Érdemes normalizálót rendelni egy szűrhető és csoportosítható mezőhöz, hogy kisimítsa a szöveg kisebb eltéréseit. A "Kanada", a "KANADA" és a "kanada" például egy gyűjtőbe lennének normalizálva.

A nem támogatott mezők elkerülése

A meglévő mezőkre, vektormezőkre vagy típusmezőkre Edm.GeographyPointCollection(Edm.GeographyPoint)nem állíthat be aspektusokat.

Összetett mezőcsoportokban a "facetable" értéknek null értékűnek kell lennie.

Kezdés új meződefiníciókkal

A mezők indexelt állapotát befolyásoló attribútumok csak mezők létrehozásakor állíthatók be. Ez a korlátozás az aspektusokra és szűrőkre vonatkozik.

Ha az index már létezik, hozzáadhat egy új meződefiníciót, amely aspektusokat biztosít. Az index meglévő dokumentumai null értéket kapnak az új mezőhöz. Ez a null érték az index legközelebbi frissítésekor lesz lecserélve.

{
  "name": "hotels-sample",  
  "fields": [
    { "name": "hotelId", "type": "Edm.String", "key": true, "searchable": false, "sortable": false, "facetable": false },
    { "name": "Description", "type": "Edm.String", "filterable": false, "sortable": false, "facetable": false },
    { "name": "HotelName", "type": "Edm.String", "facetable": false },
    { "name": "Category", "type": "Edm.String", "filterable": true, "facetable": true },
    { "name": "Tags", "type": "Collection(Edm.String)", "filterable": true, "facetable": true },
    { "name": "Rating", "type": "Edm.Int32", "filterable": true, "facetable": true },
    { "name": "Location", "type": "Edm.GeographyPoint" }
  ]
}

Aspektusok visszaadása egy lekérdezésben

Ne feledje, hogy a rendszer dinamikusan számítja ki a aspektusokat egy lekérdezési válasz eredményeiből. Csak az aktuális lekérdezés által talált dokumentumokra vonatkozó aspektusokat kapja meg.

Ajánlott eljárások az aspektusok használatához

Ez a szakasz az alkalmazásfejlesztéshez hasznos tippek és kerülő megoldások gyűjteménye.

Javasoljuk a C#: Keresés hozzáadása webalkalmazásokhoz példát, mely tartalmazza a bemutató réteg kódját is a fácett navigációhoz. A minta szűrőket, javaslatokat és automatikus kiegészítést is tartalmaz. JavaScriptet és Reactet használ a bemutató réteghez.

Facettált navigációs struktúra inicializálása nem minősített vagy üres keresési karakterlánccal

Érdemes inicializálni egy keresési oldalt egy nyitott lekérdezéssel ("search": "*") a részletes navigációs struktúra teljes kitöltéséhez. Amint megadja a lekérdezési kifejezéseket a kérelemben, a facettált navigációs struktúra a teljes index helyett csak az eredmények találataira korlátozódik. Ez a gyakorlat hasznos az aspektusok és a szűrési viselkedés ellenőrzéséhez a tesztelés során. Ha megfeleltetési feltételeket tartalmaz a lekérdezésben, a válasz kizárja a nem egyező dokumentumokat, amelyek a aspektusok kizárásának lehetséges alsóbb rétegbeli hatásával járnak.

Facettek törlése

A felhasználói élmény tervezésekor ne felejtsen el hozzáadni egy mechanizmust az aspektusok törléséhez. Az aspektusok törlésének gyakori módszere, hogy egy nyitott lekérdezést ad ki a lap alaphelyzetbe állításához.

A facettálás letiltása a tárhely megtakarítása és a teljesítmény javítása érdekében.

A teljesítmény és storage optimalizálás érdekében állítsa be a "facetable": false olyan mezőkhöz, amelyeket soha nem szabad aspektusként használni. Ilyenek például az egyedi értékek sztringmezői, például egy azonosító vagy egy terméknév, amelyek megakadályozzák a véletlen (és hatástalan) használatát a célzott navigációban. Ez az ajánlott eljárás különösen fontos a REST API esetében, amely alapértelmezés szerint lehetővé teszi a sztringmezők szűrőit és aspektusait.

Ne feledje, hogy a faceted navigációban nem használhat Edm.GeographyPoint mezőket vagy Collection(Edm.GeographyPoint) mezőket. Ne feledje, hogy az aspektusok az alacsony számosságú mezőkön működnek a legjobban. A geokoordináták feloldása miatt ritkán fordul elő, hogy egy adott adathalmazban bármely két koordináta-készlet egyenlő. Ezért a földrajzi koordináták esetében nem támogatottak az aspektusok. Hely szerinti szűréshez használjon város vagy régió mezőt.

Hibás adatok ellenőrzése

Amikor előkészíti az adatokat az indexeléshez, ellenőrizze a null értékeket, a helyesírási hibákat vagy a kis- és nagybetűk eltéréseit, valamint ugyanazon szó egy- és többes verzióját. Alapértelmezés szerint a szűrők és aspektusok nem esnek át lexikális elemzésen vagy helyesírás-ellenőrzésen (előzetes verzió), ami azt jelenti, hogy egy "facetable" mező összes értéke potenciális aspektus, még akkor is, ha a szavak egy karakterrel eltérnek.

A normalizálók mérsékelhetik az adateltéréseket, javítva a kis- és nagybetűk, valamint a karakterkülönbségek okozta eltéréseket. Ellenkező esetben az adatok vizsgálatához ellenőrizheti a mezőket a forrásuknál, vagy futtathat olyan lekérdezéseket, amelyek az indexből adnak vissza értékeket.

Az index nem a legjobb hely null értékek vagy érvénytelen értékek kijavítására. Ki kell javítania az adatproblémákat a forrásban, feltéve, hogy az egy adatbázis vagy állandó tároló, vagy az indexelés előtti adattisztítási lépés során.

Aspektusgyűjtők rendelése

Bár egy gyűjtőn belül rendezhet, a navigációs struktúrában lévő aspektusgyűjtők sorrendjének szabályozására nincs paraméter. Ha egy adott sorrendben szeretné megjeleníteni a facet vödröket, akkor azokat az alkalmazáskódban kell megadnia.

Eltérések a aspektusok számában

Bizonyos körülmények között előfordulhat, hogy a skálázási architektúra miatt az aspektusok száma nem teljesen pontos. Minden keresési index több szegmensre oszlik, és minden szegmens a dokumentumszám alapján jelenti a legfelső N-aspektusokat, amelyeket aztán egyetlen eredménybe egyesít. Mivel az egyes töredékhez csak az N legjobb aspektusok tartoznak, előfordulhat, hogy kihagy néhány illeszkedő dokumentumot, vagy kevesebbet számol belőlük az aspektus válaszában.

A pontosság garantálása érdekében mesterségesen megnövelheti a darabszám:<számot> egy nagy számra, hogy az egyes szegmensekből teljes jelentéskészítést kényszerítsen ki. Korlátlan aspektusokat is megadhat "count": "0" . Vagy beállíthatja a "darabszám" értékét egy olyan értékre, amely nagyobb vagy egyenlő a facettázott mező egyedi értékeinek számával. Ha például egy öt egyedi értékkel rendelkező "méret" mezővel néz szembe, beállíthatja "count:5" , hogy az összes egyezés szerepeljen a aspektusválaszban.

Ezzel a kerülő megoldással a lekérdezések késése megnő, ezért csak akkor használja, ha szükséges.

A szűrt eredmények aszinkron módon történő navigációs struktúrájának megőrzése

Az Azure AI Keresés-ben az aspektusok csak az aktuális eredményekhez léteznek. Gyakori alkalmazáskövetelmény azonban, hogy megőrizze a statikus aspektusokat, hogy a felhasználó fordított módon navigáljon, és a keresési tartalmakon keresztül más útvonalakat is felfedezzen.

Ha dinamikus részletezési felület mellett statikus aspektuskészletet szeretne, két szűrt lekérdezéssel valósíthatja meg: az egyik hatóköre az eredményekre terjed ki, a másik pedig az aspektusok statikus listájának létrehozására navigációs célokra.

Nagy szempontszámok kiegyensúlyozása szűrőkkel

A keresési eredmények és a túl nagy aspektusú találatok szűrők hozzáadásával vághatók le. Az alábbi példában a felhőalapú számítástechnika lekérdezésében 254 elem rendelkezik belső specifikációval tartalomtípusként. Ha az eredmények túl nagyok, a szűrők hozzáadása további feltételek hozzáadásával segítheti a felhasználókat a lekérdezés finomításában.

Az elemek nem zárják ki egymást. Ha egy elem megfelel mindkét szűrő feltételeinek, mindegyikben számolják. Ez a duplikáció akkor lehetséges, ha a dokumentumcímkézés megvalósításához gyakran használt Collection(Edm.String) mezőkön facettálunk.

Search term: "cloud computing"
Content type
   Internal specification (254)
   Video (10)

Következő lépések