Megosztás a következőn keresztül:

Az OData-gyűjteményszűrők működésének ismertetése az Azure AI Searchben

  • Cikk

Ez a cikk olyan fejlesztőknek nyújt hátteret, akik összetett lambdakifejezésekkel írnak speciális szűrőket. A cikk azt ismerteti, hogy miért léteznek a gyűjteményszűrőkre vonatkozó szabályok, ha megvizsgáljuk, hogyan hajtja végre az Azure AI Search ezeket a szűrőket.

Amikor az Azure AI Search gyűjteménymezőire készít szűrőt, a lambdakifejezésekkel együtt használhatja az operátorokat és all az any operátorokat. A Lambda-kifejezések olyan logikai kifejezések, amelyek egy tartományváltozóra hivatkoznak. A lambda kifejezést használó szűrőkben az operátorok és all az any operátorok a legtöbb programozási nyelvben hasonlóak egy for hurokhoz, a tartományváltozó a ciklusváltozó szerepét veszi át, a lambda kifejezés pedig a hurok törzse. A tartományváltozó a ciklus iterációja során veszi át a gyűjtemény "aktuális" értékét.

Legalábbis így működik fogalmilag. Az Azure AI Search a valóságban egészen más módon implementálja a szűrőket a hurkok működéséhez for . Ideális esetben ez a különbség láthatatlan lenne az Ön számára, de bizonyos helyzetekben nem. A végeredmény az, hogy vannak szabályok, amelyeket be kell tartania a lambda kifejezések írásakor.

Megjegyzés:

További információ a gyűjteményszűrők szabályairól, beleértve a példákat is: OData-gyűjteményszűrők hibaelhárítása az Azure AI Searchben.

Miért korlátozottak a gyűjteményszűrők?

Három alapvető oka van annak, hogy a szűrőfunkciók nem támogatottak teljes mértékben az összes gyűjteménytípus esetében:

  1. Bizonyos adattípusok esetében csak bizonyos operátorok támogatottak. Például nincs értelme összehasonlítani a logikai értékeket true , és false használni lt, gtés így tovább.
  2. Az Azure AI Search nem támogatja a korrelált keresést a típusmezőkben Collection(Edm.ComplexType).
  3. Az Azure AI Search invertált indexekkel hajt végre szűrőket minden adattípuson, beleértve a gyűjteményeket is.

Az első ok csak az OData nyelv és az EDM típusú rendszer definiálásának következménye. Az utolsó kettőt részletesebben a cikk további részében ismertetjük.

Ha összetett objektumok gyűjteményére több szűrési feltételt alkalmaz, a feltételek korrelálnak, mert a gyűjtemény minden egyes objektumára vonatkoznak. Az alábbi szűrő például azokat a szállodákat adja vissza, amelyek legalább egy deluxe szobával rendelkeznek, és a díjszabása 100-nál kisebb:

    Rooms/any(room: room/Type eq 'Deluxe Room' and room/BaseRate lt 100)

Ha a szűrés nem volt javítva, a fenti szűrő olyan szállodákat adhat vissza, ahol egy szoba deluxe, és egy másik szoba alapkamata 100-nál alacsonyabb. Ennek nem lenne értelme, mivel a lambda kifejezés mindkét záradéka ugyanarra a tartományváltozóra vonatkozik, nevezetesen room. Ezért vannak korrelálva az ilyen szűrők.

A teljes szöveges kereséshez azonban nem lehet egy adott tartományváltozóra hivatkozni. Ha az alábbihoz hasonló teljes Lucene-lekérdezést ad ki mezős kereséssel:

    Rooms/Type:deluxe AND Rooms/Description:"city view"

akkor lehet, hogy a szállodák vissza, ahol egy szoba deluxe, és egy másik szoba említi a "városnézet" a leírásban. Az alábbi dokumentum például megegyezik a lekérdezéssel Id1 :

{
  "value": [
    {
      "Id": "1",
      "Rooms": [
        { "Type": "deluxe", "Description": "Large garden view suite" },
        { "Type": "standard", "Description": "Standard city view room" }
      ]
    },
    {
      "Id": "2",
      "Rooms": [
        { "Type": "deluxe", "Description": "Courtyard motel room" }
      ]
    }
  ]
}

Ennek az az oka, hogy Rooms/Type a mező összes elemzett kifejezésére hivatkozik a Rooms/Type teljes dokumentumban, és ehhez Rooms/Descriptionhasonlóan az alábbi táblázatokban látható módon.

A teljes szöveges keresés tárolási módja Rooms/Type :

Kifejezés a következőben: Rooms/Type Dokumentumazonosítók
Deluxe 1, 2
normál 1

A teljes szöveges keresés tárolási módja Rooms/Description :

Kifejezés a következőben: Rooms/Description Dokumentumazonosítók
Courtyard 2
Város 1
Kert 1
Nagy 1
Motel 2
Szoba 1, 2
normál 1
Suite 1
megtekintés 1

Tehát ellentétben a fenti szűrő, amely alapvetően azt mondja, "egyezés dokumentumok, ahol a szoba Type egyenlő "Deluxe Szoba", és hogy ugyanaz a szoba BaseRate kevesebb, mint 100", a keresési lekérdezés azt mondja, "egyezés dokumentumok, ahol Rooms/Type a "deluxe" és Rooms/Description a "városnézet" kifejezést. Az utóbbi esetben nem létezik olyan különálló helyiség, amelynek mezői korrelálhatók.

Fordított indexek és gyűjtemények

Észrevehette, hogy a lambdakifejezésekre sokkal kevesebb korlátozás vonatkozik az összetett gyűjtemények esetében, mint az olyan egyszerű gyűjtemények esetében, mint az Collection(Edm.Int32), Collection(Edm.GeographyPoint)stb. Ennek az az oka, hogy az Azure AI Search az összetett gyűjteményeket aldokumentumok tényleges gyűjteményeként tárolja, míg az egyszerű gyűjtemények egyáltalán nem gyűjteményként vannak tárolva.

Vegyük például egy szűrhető sztringgyűjtési mezőt, például seasons egy online kereskedő indexében. Az indexbe feltöltött dokumentumok némelyike a következőképpen nézhet ki:

{
  "value": [
    {
      "id": "1",
      "name": "Hiking boots",
      "seasons": ["spring", "summer", "fall"]
    },
    {
      "id": "2",
      "name": "Rain jacket",
      "seasons": ["spring", "fall", "winter"]
    },
    {
      "id": "3",
      "name": "Parka",
      "seasons": ["winter"]
    }
  ]
}

A mező értékei seasons egy fordított indexnek nevezett struktúrában vannak tárolva, amely a következőképpen néz ki:

Term Dokumentumazonosítók
Tavaszi 1, 2
Nyári 1
Esik 1, 2
Téli 2, 3

Ez az adatstruktúra úgy lett kialakítva, hogy nagy sebességgel válaszoljon egy kérdésre: Mely dokumentumokban jelenik meg egy adott kifejezés? A kérdés megválaszolása inkább egy egyszerű egyenlőség-ellenőrzéshez hasonlít, mint egy gyűjteményen keresztüli hurok. Valójában ez az oka annak, hogy a sztringgyűjtemények esetében az Azure AI Search csak összehasonlító operátorként teszi lehetővé eq a lambda kifejezésen belül.any

Következő lépésként áttekintjük, hogyan kombinálható több egyenlőségi ellenőrzés ugyanazon a tartományváltozón or. Az algebra és a kvantátorok disztribúciós tulajdonságának köszönhetően működik. Ez a kifejezés:

    seasons/any(s: s eq 'winter' or s eq 'fall')

egyenértékű a következő értékeket:

    seasons/any(s: s eq 'winter') or seasons/any(s: s eq 'fall')

és a két any alkifejezés mindegyike hatékonyan végrehajtható az invertált index használatával. Emellett a kvantátorok tagadási törvényének köszönhetően ez a kifejezés:

    seasons/all(s: s ne 'winter' and s ne 'fall')

egyenértékű a következő értékeket:

    not seasons/any(s: s eq 'winter' or s eq 'fall')

ezért lehet használni allneandés .

Megjegyzés:

Bár a részletek túlmutatnak a jelen dokumentum hatókörén, ugyanezek az alapelvek kiterjednek a térbeli pontok gyűjteményeinek távolság- és metszetvizsgálatára is. Ezért a következőben any:

  • geo.intersects nem lehet negated
  • geo.distance összehasonlítása lt a le
  • kifejezéseket kombinálni kell a orand

A converse szabályok a következőre vonatkoznak all: .

A kifejezések szélesebb köre engedélyezett, ha például olyan adattípusok gyűjteményére szűr, amelyek támogatják a lt, gt, le, és ge operátorokat, például Collection(Edm.Int32) . Pontosabban használhatja és használhatja andoranyis mindaddig, amíg a mögöttes összehasonlító kifejezések tartomány-összehasonlításokba vannak kombinálva a használatávaland, amelyeket aztán tovább kombinál a rendszer.or A logikai kifejezések ezen struktúráját disjunctive Normal Form (DNF) néven nevezzük, más néven "AND-k ORs-ének". Ezzel szemben az ilyen adattípusok lambda-kifejezéseinek all conjunctive Normal Form (CNF) formában kell lenniük, más néven "ORs AND-k" néven. Az Azure AI Search lehetővé teszi az ilyen tartomány-összehasonlításokat, mivel invertált indexekkel hatékonyan hajthatja végre őket, ugyanúgy, mint a sztringek gyors kifejezéskeresését.

Összefoglalva: a lambda kifejezésben megengedett ökölszabály:

  • Belül anymindig engedélyezve van a pozitív ellenőrzés, például egyenlőség, tartomány-összehasonlítás, geo.intersectsvagy geo.distance összehasonlítás lt vagy le (a "közelség" olyan, mint az egyenlőség a távolság ellenőrzésekor).
  • or Belül anymindig engedélyezett. Csak olyan adattípusokhoz használható and , amelyek képesek a tartomány-ellenőrzések kifejezésére, és csak akkor, ha az AND-k (DNF) ORs-eit használja.
  • Belül alla szabályok megfordulnak. Csak negatív ellenőrzések engedélyezettek, mindig használhatók and , és csak az ORS-ek (CNF) AND-jeiként kifejezett tartományellenőrzésekhez használható or .

A gyakorlatban ezek azok a szűrők, amelyeket nagy valószínűséggel használ. Még mindig hasznos megérteni a határokat, hogy mi lehetséges mégis.

Az érvényes gyűjteményszűrők írása című témakörben konkrét példákat talál arra, hogy milyen típusú szűrők engedélyezettek és melyek nem.

További lépések