Egyszerű lekérdezési szintaxis a Azure AI Keresés

A teljes szöveges keresési forgatókönyvek esetében Azure AI Keresés 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. A gyakori használati esetekre terjed ki, és megpróbálja értelmezni a kérést, még akkor is, ha az nem tökéletesen van összeállítva. 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 search paraméterében á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 filter kifejezésekre orderby vonatkozó szabályokkal.

Bár az egyszerű elemző a Apache Lucene Simple Query Parser osztályon alapul, a Azure AI Keresés 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)

A példa egy egyszerű lekérdezést mutat be, megkülönböztetve a "queryType": "simple" által, é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=2025-09-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.

Kulcsszavas keresés kifejezésekre és mondatokra

A search paraméterhez átadott sztringek tartalmazhatnak kifejezéseket vagy fogalmakat bármilyen támogatott nyelven, logikai operátorokat, precedencia operátorokat, helyettesítő vagy előtag karaktereket a "kezdő" lekérdezésekhez, escape karaktereket és URL-kódolt 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 a Roach Motel (idézőjelek nélkül) keresés dokumentumokat keres, amelyek bárhol tartalmazzák a Roach és/vagy Motel kifejezéseket, bármilyen sorrendben, akkor a "Roach Motel" (idézőjelekkel) csak azokat a dokumentumokat találja meg, amelyek az egész kifejezést pontosan ebben a sorrendben tartalmazzák (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\"": . Ha az Azure SDK-ket használja, a kereső kliens kihagyja az idézőjeleket, amikor szerializálja a kereső kifejezést. A keresési kifejezés "Roach Motel" lehet.

Alapértelmezés szerint a search paraméterben átadott összes karakterlánc 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. Azure AI Keresés megkeresi azokat a dokumentumokat, amelyek bármelyik vagy az összes kifejezést tartalmazzák, beleértve a szöveg elemzése során talált változatokat is.

Bármennyire is egyértelműnek hangzik, a lekérdezések végrehajtásának egy aspektusa van a Azure AI Keresés, amely might váratlan eredményeket eredményez, és nem csökkenti a keresési eredményeket, mivel 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, attól függ, hogy bele van-e foglalva egy NOT operátor, mely egy searchMode paraméterbeállítással kombinálva határozza meg, hogy a NOT hogyan értelmezhető a AND vagy OR viselkedések szempontjából. További információkért tekintse meg az operátort a NOTlogikai 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 azokra a dokumentumokra, amelyek tartalmazzák a pool-t, a ocean-t, vagy mindkettőt. Mivel a OR az alapértelmezett kötőoperátor, azt is kihagyhatja, így a pool ocean egyenértékű a pool | ocean-vel.
- 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 a any vagy a 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 a pool - ocean egyezni fog azokkal a dokumentumokkal, amelyek vagy a kifejezést pool tartalmazzák, vagy azokkal, amelyek nem tartalmazzák a kifejezést ocean.

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 searchMode=any például, pool - ocean megfelel a "medence" kifejezést tartalmazó dokumentumoknak, és az összes olyan dokumentumnak, amely nem tartalmazza az "óceán" kifejezést. Ez vitathatatlanul intuitívabb viselkedés az - operátor számára. Ezért érdemes megfontolnia a searchMode=all használatát a searchMode=any helyett, ha a keresést az emlékezet helyett a pontosságra szeretné optimalizálni, és a felhasználók gyakran használják a - 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 használnak operátort egy lekérdezésben, ellentétben az e-kereskedelmi oldalakkal, amelyekben fejlettebb navigációs struktúrák vannak.

Előtag-lekérdezések

Az "azzal kezdődő" 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 egyszerű szöveges karakterrel kell kezdődnie az utótag operátor hozzáadása előtt.

Karakter Példa Használat
* A lingui* egyezni fog a "nyelvi" vagy a "linguini" kifejezéssel. 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 köztes tagot keres, használja a teljes Lucene szintaxist a helyettesítő karakteres kereséshez.

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 tokenjének részei, akkor a lekérdezésben egy fordított perjelet (\) kell előtagként alkalmaznia. Tegyük fel például, hogy egy egyéni elemzőt használtál a teljes kifejezés tokenizálásához, és az index tartalmazza a "Luxury+Hotel" sztringet. Ha pontos egyezést szeretne kapni ezen a tokenen, szúrjon be egy escape 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 kiiktatni, 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.

  • A szuffix operátort * csak akkor kell escape-elni, ha ez az utolsó karakter a szóköz előtt van. Ha a * középen (például a következőben 4*4=16) jelenik meg, nincs szükség menekülésre.

Megjegyzé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 Microsoft természetes nyelv-elemzők, amelyek megőrzik az elválasztott 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 '=' példák a fenntartott karakterekre, mivel ezek elválasztják a paramétereket, és megadják az értékeket az Azure AI Keresés-ben. 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 elemző a szóközökkel elválasztott karaktersorozatokat tokeneknek tekinti (tehát a "❤" emoji tokennek tekinthető).

  • Egy nyelvi elemző, például a Microsoft angol elemző (en.microsoft), tokenként kezeli a "$" vagy a "€" sztringet.

Megerősítés céljából tesztelheti az elemzőt, hogy lássa, milyen tokenek jönnek létre egy adott karakterlánchoz. Ahogyan várható, előfordulhat, hogy nem kap teljes tokenizálást egyetlen elemzőtől. Egy 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_en, description_fr, stb. nyelvelemzők esetén).

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 magában foglalja a search-t és olyan egyéb paramétereket, mint például a 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

Amennyiben programozott módon szeretne lekérdezéseket létrehozni, tekintse át az "Azure AI Keresésben végzett teljes szövegkeresést", hogy megértse a lekérdezés feldolgozásának szakaszait és a szövegelemzés hatásait.

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

  • Last updated on