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

Egyszerű lekérdezési szintaxis az Azure AI Searchben

  • Cikk

A teljes szöveges keresési forgatókönyvek esetében az Azure AI Search két Lucene-alapú lekérdezési nyelvet implementál, mindegyiket egy lekérdezéselemzőhöz igazítva. Az egyszerű lekérdezéselemző az alapértelmezett. Kiterjed a gyakori használati esetekre és a kérések értelmezésére tett kísérletekre, még akkor is, ha az nem teljesen áll össze. A másik elemző a Lucene Query Parser , amely fejlettebb lekérdezésszerkezeteket támogat.

Ez a cikk az egyszerű lekérdezéselemző lekérdezésszintaxis-referenciája.

Mindkét elemző lekérdezési szintaxisa a lekérdezési kérelem paraméterében search átadott lekérdezési kifejezésekre vonatkozik, és nem tévesztendő össze az OData szintaxissal, a saját szintaxisával, valamint az ugyanazon kérelemben szereplő kifejezésekre és orderby kifejezésekre filter vonatkozó szabályokkal.

Bár az egyszerű elemző az Apache Lucene Simple Query Parser osztályon alapul, az Azure AI Searchben való implementációja kizárja a homályos keresést. Ha homályos keresésre van szüksége, fontolja meg inkább a teljes Lucene-lekérdezés szintaxisát.

Példa (egyszerű szintaxis)

Ez a példa egy egyszerű lekérdezést mutat be, amely "queryType": "simple" megkülönbözteti és érvényes szintaxissal rendelkezik. Bár a lekérdezés típusa alább van beállítva, ez az alapértelmezett érték, és kihagyható, kivéve, ha egy másik típusból próbál visszaállni. Az alábbi példa egy független kifejezésekre való keresés, amely azt követeli meg, hogy az összes egyező dokumentum tartalmazza a "készletet".

POST https://{{service-name}}.search.windows.net/indexes/hotel-rooms-sample/docs/search?api-version=2024-07-01
{
  "queryType": "simple",
  "search": "budget hotel +pool",
  "searchMode": "all"
}

A searchMode paraméter ebben a példában releváns. Amikor logikai operátorok szerepelnek a lekérdezésben, általában úgy kell beállítania searchMode=all , hogy az összes feltétel megfeleltetve legyen. Ellenkező esetben használhatja az alapértelmezett searchMode=any beállítást, amely a visszahívást részesíti előnyben a precizitással szemben.

További példákat az Egyszerű lekérdezés szintaxisa című témakörben talál. A lekérdezési kérelemről és a paraméterekről további információt a Dokumentumok keresése (REST API) című témakörben talál.

Kulcsszavak keresése kifejezésekre és kifejezésekre

A paraméternek search átadott sztringek bármilyen támogatott nyelven tartalmazhatnak kifejezéseket vagy kifejezéseket, logikai operátorokat, elsőbbségi operátorokat, helyettesítő karaktereket vagy előtagokat a "kezdő" lekérdezésekhez, a feloldó karaktereket és az URL-kódolási karaktereket. A search paraméter megadása nem kötelező. A meghatározatlan keresés (search=* vagy search=" ") az első 50 dokumentumot adja vissza tetszőleges (nem módosított) sorrendben.

  • A kifejezéskeresés egy vagy több kifejezés lekérdezése, ahol a kifejezések bármelyike egyezésnek minősül.

  • A kifejezéskeresés pontosan idézőjelek " "közé zárt kifejezés. Ha például Roach Motel (idézőjelek nélkül) olyan dokumentumokat keres, amelyek bármilyen sorrendben és/vagy Motel tetszőleges sorrendben találhatókRoach, (idézőjelekkel) csak azokat a dokumentumokat egyezik meg, "Roach Motel" amelyek az egész kifejezést tartalmazzák, és ebben a sorrendben (a lexikális elemzés továbbra is érvényes).

A keresési ügyféltől függően előfordulhat, hogy el kell menekülnie az idézőjelek elől egy kifejezéskeresésben. Például egy POST-kérelemben a kérelem törzsében egy kifejezéskeresés "Roach Motel" lehet megadva a következőként "\"Roach Motel\"": . Az Azure SDK-k használata esetén a keresési ügyfél feloldja az idézőjeleket, amikor szerializálja a keresési szöveget. A keresési kifejezés "Roach Motel" lehet.

Alapértelmezés szerint a paraméterben átadott összes sztring search lexikális elemzésen megy keresztül. Győződjön meg arról, hogy tisztában van a használt elemző tokenizálási viselkedésével. Gyakran előfordul, hogy amikor a lekérdezés eredményei váratlanok, az ok a kifejezések tokenizálásának módjára vezethető vissza a lekérdezési időpontban. A kimenet megerősítéséhez tesztelheti a tokenizálást adott sztringeken .

Az egy vagy több kifejezéssel rendelkező szöveges bemenetek a lekérdezés végrehajtásának érvényes kiindulópontjának minősülnek. Az Azure AI Search megfelel a bármely vagy az összes kifejezést tartalmazó dokumentumnak, beleértve a szöveg elemzése során talált változatokat is.

Bármennyire is egyértelműnek hangzik, az Azure AI Searchben a lekérdezések végrehajtásának egy olyan aspektusa van, amely váratlan eredményeket eredményezhet , és a keresési eredmények csökkentése helyett egyre több kifejezést és operátort ad hozzá a bemeneti sztringhez. Az, hogy ez a bővítés ténylegesen bekövetkezik-e, egy NOT operátor belefoglalásától függ, egy searchMode paraméterbeállítással kombinálva, amely meghatározza, hogy a NOT hogyan értelmezhető az adott vagy viselkedési viszonyban AND OR . További információkért tekintse meg az operátort a NOT logikai operátorok alatt.

Logikai operátorok

Logikai operátorokat beágyazhat egy lekérdezési sztringbe egyezés pontosságának javítása érdekében. Az egyszerű szintaxisban a logikai operátorok karakteralapúak. A szöveges operátorok, például az AND szó nem támogatottak.

Karakter Példa Használat
+ pool + ocean Egy AND művelet. Például azt írja elő, pool + ocean hogy egy dokumentumnak mindkét feltételt tartalmaznia kell.
| pool | ocean A OR művelet akkor talál egyezést, ha bármelyik kifejezés megtalálható. A példában a lekérdezési motor egyezést ad vissza az egyiket pool vagy ocean mindkettőt tartalmazó dokumentumokon. Mivel OR ez az alapértelmezett kötőkötő operátor, azt is kihagyhatja, ez pedig pool ocean a megfelelője pool | ocean.
- pool – ocean A NOT művelet egyezéseket ad vissza azon dokumentumokon, amelyek kizárják a kifejezést.

A searchMode lekérdezéskérelem paramétere azt szabályozza, hogy az NOT operátorral ANDrendelkező kifejezés szerepel-e a lekérdezésben, vagy ORmás kifejezésekkel van-e megadva (feltéve, hogy a többi kifejezésben nincsenek logikai operátorok). Az érvényes értékek közé tartozik vagy any all.

searchMode=any növeli a lekérdezések visszahívását további eredmények beírásával, és alapértelmezés szerint - "VAGY NEM" néven lesz értelmezve. Például egyezni fog azokkal a dokumentumokkal, amelyek vagy a kifejezést tartalmazzák, pool - ocean vagy azokat, amelyek nem tartalmazzák a kifejezéstocean.pool

searchMode=all növeli a lekérdezések pontosságát kevesebb eredmény beiktatásával, és alapértelmezés szerint - "ÉS NEM" néven lesz értelmezve. A lekérdezés pool - ocean például searchMode=anymegfelel a "készlet" kifejezést tartalmazó dokumentumoknak, és az összes olyan dokumentumnak, amely nem tartalmazza az "ocean" kifejezést. Ez vitathatatlanul intuitívabb viselkedés az - operátor számára. Ezért érdemes megfontolnia searchMode=all searchMode=any ahelyett, hogy a visszahívás helyett a pontosságra szeretné optimalizálni a keresést, és a felhasználók gyakran használják az operátort a - keresésekben.

Amikor egy searchMode beállítás mellett dönt, vegye figyelembe a különböző alkalmazások lekérdezéseinek felhasználói interakciós mintáit. Az információt kereső felhasználók nagyobb valószínűséggel tartalmaznak operátort egy lekérdezésben, szemben a beépítettebb navigációs struktúrákkal rendelkező e-kereskedelmi webhelyekkel.

Előtag-lekérdezések

A "kezdő" lekérdezések esetében adjon hozzá egy utótag operátort (*) a kifejezés hátralévő részére helyőrzőként. Az utótag-lekérdezésnek legalább egy alfanumerikus karakterrel kell kezdődnie, mielőtt hozzáadja az utótag operátort.

Karakter Példa Használat
* lingui* "nyelvi" vagy "linguini" A csillag (*) egy vagy több tetszőleges hosszúságú karaktert jelöl, figyelmen kívül hagyva az esetet.

A szűrőkhöz hasonlóan az előtag-lekérdezések pontos egyezést keresnek. Ezért nincs relevanciapontozás (minden találat 1,0 keresési pontszámot kap). Vegye figyelembe, hogy az előtag-lekérdezések lassúak lehetnek, különösen akkor, ha az index nagy, és az előtag kis számú karakterből áll. Egy alternatív módszer, például az él n-gram tokenizálása gyorsabb lehet. Az előtagkeresést használó kifejezések legfeljebb 1000 karakter hosszúságúak lehetnek.

Az egyszerű szintaxis csak az előtag egyeztetését támogatja. Ha egy kifejezés végén vagy közepén egyező utótagot vagy utótagot keres, használja a teljes Lucene szintaxist a helyettesítő karakterek kereséséhez.

Keresési operátorok szökése

Az egyszerű szintaxisban a keresési operátorok a következő karaktereket tartalmazzák: + | " ( ) ' \

Ha ezek a karakterek az index egy jogkivonatának részei, akkor a lekérdezésben egy fordított perjel (\) előtaggal kell előtagot képeznie. Tegyük fel például, hogy egy egyéni elemzőt használt a teljes kifejezés jogkivonatának létrehozásához, és az index tartalmazza a "Luxury+Hotel" sztringet. Ha pontos egyezést szeretne kapni ezen a jogkivonaton, szúrjon be egy feloldó karaktert: search=luxury\+hotel.

A tipikusabb esetekben a dolgok egyszerűvé tétele érdekében a szabály alól két kivétel van, ahol nincs szükség a menekülésre:

  • A NOT operátort - csak akkor kell megmenekíteni, ha ez az első karakter a szóköz után. Ha a - középen (például a be 3352CDD0-EF30-4A2E-A512-3B30AF40F3FD) jelenik meg, kihagyhatja a menekülést.

  • Az utótag operátort * csak akkor kell megmenekíteni, ha ez az utolsó karakter a szóköz előtt. Ha a * középen (például a következőben 4*4=16) jelenik meg, nincs szükség menekülésre.

Feljegyzés

Alapértelmezés szerint a standard elemző törli és megszakítja a szavakat a kötőjeleken, a szóközökön, az ampereken és más karaktereken a lexikális elemzés során. Ha speciális karaktereket szeretne a lekérdezési sztringben tartani, szükség lehet egy elemzőre, amely megőrzi őket az indexben. Egyes lehetőségek közé tartoznak a Microsoft természetes nyelvelemzői, amelyek megőrzik a kötőjeles szavakat, vagy egy egyéni elemzőt az összetettebb mintákhoz. További információ: Részleges kifejezések, minták és speciális karakterek.

Nem biztonságos és fenntartott karakterek kódolása URL-címekben

Győződjön meg arról, hogy minden nem biztonságos és fenntartott karakter URL-címben van kódolva. A "#" például nem biztonságos karakter, mert egy URL-cím töredék-horgonyazonosítója. A karaktert az URL-címben való használat esetén kódolni %23 kell. A "&" és a "=" a fenntartott karakterekre példa, mivel elválasztják a paramétereket, és értékeket adnak meg az Azure AI Searchben. További információ: RFC1738: Uniform Resource Locators (URL).

A nem biztonságos karakterek a következők " ` < > # % { } | \ ^ ~ [ ]: . A fenntartott karakterek a következők ; / ? : @ = + &: .

Speciális karakterek

A speciális karakterek az olyan pénznemszimbólumoktól kezdve, mint a "$" vagy a "€", az emojikig terjedhetnek. Számos elemző , beleértve az alapértelmezett standard elemzőt is, kizárja a speciális karaktereket az indexelés során, ami azt jelenti, hogy nem jelennek meg az indexben.

Ha speciális karakterábrázolásra van szüksége, hozzárendelhet egy elemzőt, amely megőrzi őket:

  • A whitespace analyzer a fehér szóközök által elválasztott karaktersorozatokat tokeneknek tekinti (tehát a "❤" emoji jogkivonatnak minősül).

  • Egy nyelvelemző, például a Microsoft English Analyzer (en.microsoft) jogkivonatként használja a "$" vagy a "€" sztringet.

Megerősítés céljából tesztelheti az elemzőt , hogy lássa, milyen jogkivonatok jönnek létre egy adott sztringhez. Ahogy várható volt, előfordulhat, hogy nem kap teljes jogkivonatot egyetlen elemzőtől. A megkerülő megoldás több olyan mező létrehozása, amely ugyanazt a tartalmat tartalmazza, de különböző elemző-hozzárendelésekkel (például description_endescription_frnyelvelemzők esetén stb.).

Unicode-karakterek használata esetén győződjön meg arról, hogy a szimbólumok megfelelően vannak feloldva a lekérdezés URL-címében (például a "❤" a feloldósorozatot %E2%9D%A4+használja). Egyes webes ügyfelek automatikusan elvégzik ezt a fordítást.

Elsőbbség (csoportosítás)

Zárójelek használatával allekérdezéseket hozhat létre, beleértve a zárójeles utasításban szereplő operátorokat is. Például motel+(wifi|luxury) megkeresi a "motel" kifejezést és a "wifi" vagy a "luxus" (vagy mindkettő) kifejezést tartalmazó dokumentumokat.

Lekérdezésméretkorlátok

Ha az alkalmazás programozott módon hoz létre keresési lekérdezéseket, javasoljuk, hogy úgy tervezzen meg, hogy ne hozzon létre kötetlen méretű lekérdezéseket.

  • GET esetén az URL-cím hossza nem haladhatja meg a 8 KB-ot.

  • A POST (és bármely más kérés) esetében, ahol a kérelem törzse és search egyéb paraméterek, például filter és orderby, a maximális méret 16 MB. További korlátok a következők:

    • A keresési záradék maximális hossza 100 000 karakter.
    • A záradékok search maximális száma az (AND vagy OR által elválasztott kifejezésekben) 1024.
    • Az előtagkereséshez a keresési kifejezés maximális mérete 1000 karakter.
    • A lekérdezések bármely egyes kifejezésének méretére vonatkozó korlát is körülbelül 32 KB.

További információ a lekérdezési korlátokról: API-kérések korlátai.

Következő lépések

Ha programozott módon fog lekérdezéseket létrehozni, tekintse át a teljes szöveges keresést az Azure AI Searchben , hogy megismerje a lekérdezésfeldolgozás szakaszait és a szövegelemzés következményeit.

A lekérdezések felépítésével kapcsolatos további információkért tekintse át az alábbi cikkeket is: