Indexek keresése az Azure AI Searchben

Az Azure AI Searchben a keresési index a kereshető tartalom, amely elérhető a keresőmotor számára az indexeléshez, a teljes szöveges kereséshez, a vektorkereséshez, a hibrid kereséshez és a szűrt lekérdezésekhez. Az indexeket séma határozza meg, és a keresési szolgáltatásba menti, az adatok importálása pedig második lépésként történik. Ez a tartalom az elsődleges adattárakon kívül létezik a keresési szolgáltatásban, ami a modern keresési alkalmazásokban várt ezredmásodpercnyi válaszidőhöz szükséges. Az indexelőalapú indexelési forgatókönyvek kivételével a keresési szolgáltatás soha nem csatlakozik a forrásadatokhoz, és nem is lekérdezéseket végez.

Ha keresési indexet szeretne létrehozni és kezelni, ez a cikk segít megérteni a következő szempontokat:

• Tartalom (dokumentumok és séma)
• Fizikai adatstruktúra
• Alapszintű műveletek

Szívesebben dolgozik azonnal? Lásd: Keresési index létrehozása.

Keresési index sémája

Az Azure AI Searchben az indexek keresési dokumentumokat tartalmaznak. A dokumentum elméletileg az indexben lévő kereshető adatok egyetlen egysége. Előfordulhat például, hogy egy kiskereskedő minden termékhez rendelkezik dokumentumtal, a hírügynökségek minden cikkhez rendelkeznek dokumentumokkal, az utazási helyeken pedig minden egyes szállodához és célhelyhez egy dokumentum tartozik, és így tovább. Ezeket a fogalmakat jobban ismert adatbázis-megfelelőkre kell leképeznie: a keresési index egy táblával egyenlő, a dokumentumok pedig nagyjából egyenértékűek a tábla soraival.

A dokumentum szerkezetét az indexséma határozza meg, ahogyan az az alábbi példában is látható. A "mezők" gyűjtemény általában az index legnagyobb része, ahol minden mező neve el van nevezve, adattípushoz van rendelve, és a használat módját meghatározó megengedhető viselkedéssel van hozzárendelve.

{
  "name": "name_of_index, unique across the service",
  "fields": [
    {
      "name": "name_of_field",
      "type": "Edm.String | Collection(Edm.String) | Collection(Edm.Single) | Edm.Int32 | Edm.Int64 | Edm.Double | Edm.Boolean | Edm.DateTimeOffset | Edm.GeographyPoint",
      "searchable": true (default where applicable) | false (only Edm.String and Collection(Edm.String) fields can be searchable),
      "filterable": true (default) | false,
      "sortable": true (default where applicable) | false (Collection(Edm.String) fields cannot be sortable),
      "facetable": true (default where applicable) | false (Edm.GeographyPoint fields cannot be facetable),
      "key": true | false (default, only Edm.String fields can be keys),
      "retrievable": true (default) | false,
      "analyzer": "name_of_analyzer_for_search_and_indexing", (only if 'searchAnalyzer' and 'indexAnalyzer' are not set)
      "searchAnalyzer": "name_of_search_analyzer", (only if 'indexAnalyzer' is set and 'analyzer' is not set)
      "indexAnalyzer": "name_of_indexing_analyzer", (only if 'searchAnalyzer' is set and 'analyzer' is not set)
      "normalizer":  "name_of_normalizer", (applies to fields that are filterable)
      "synonymMaps": "name_of_synonym_map", (optional, only one synonym map per field is currently supported)
      "dimensions": "number of dimensions used by an emedding models", (applies to vector fields only, of type Collection(Edm.Single))
      "vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations, a field can use just one)
    }
  ],
  "suggesters": [ ],
  "scoringProfiles": [ ],
  "analyzers":(optional)[ ... ],
  "charFilters":(optional)[ ... ],
  "tokenizers":(optional)[ ... ],
  "tokenFilters":(optional)[ ... ],
  "defaultScoringProfile": (optional) "...",
  "corsOptions": (optional) { },
  "encryptionKey":(optional){ },
  "semantic":(optional){ },
  "vectorSearch":(optional){ }
}

Más elemek össze vannak csukva a rövidség kedvéért, de az alábbi hivatkozások részletes információkat tartalmaznak:

• A javaslattevők támogatják a típuselőréses lekérdezéseket, például az automatikus kiegészítést.
• A scoringProfiles a relevanciahangoláshoz használatos.
• Az elemzők a sztringek tokenekké való feldolgozására szolgálnak a nyelvi szabályok vagy az elemző által támogatott egyéb jellemzők szerint.
• A corsOptions vagy a cross-origin remote scripting (CORS) olyan alkalmazásokhoz használható, amelyek különböző tartományokból érkező kéréseket ad ki.
• A encryptionKey az indexben lévő bizalmas tartalmak dupla titkosítását konfigurálja.
• a szemantika teljes szöveges és hibrid kereséssel konfigurálja a szemantikai rerankingot.
• A vectorSearch vektormezőket és lekérdezéseket konfigurál.

Meződefiníciók

A keresési dokumentumokat az Index létrehozása kérelem törzsében található "mezők" gyűjtemény határozza meg. Mezőkre van szüksége a dokumentumazonosításhoz (kulcsokhoz), a kereshető szöveg tárolásához, valamint a szűrők, aspektusok és rendezés mezőihez. Szükség lehet olyan adatok mezőire is, amelyeket egy felhasználó soha nem lát. Előfordulhat például, hogy a keresési pontszám növeléséhez a pontozási profilban használható haszonkulcsok vagy marketingösztönzések mezőit szeretné használni.

Ha a bejövő adatok hierarchikus jellegűek, akkor az indexen belül összetett típusként jelölhetők, beágyazott struktúrákhoz. A beépített mintaadatkészlet, a Hotels (Hotelek) egy cím (több almezőt tartalmaz) használatával szemlélteti az összetett típusokat, amelyek egy-az-egyhez kapcsolatban állnak az egyes szállodákkal, valamint egy Olyan komplex szobák gyűjteményt, amelyekben több szoba van társítva az egyes szállodákkal.

Mezőattribútumok

A mezőattribútumok határozzák meg a mező használatát, például azt, hogy teljes szöveges keresésben, részletes navigációban, rendezési műveletekben stb. használják-e.

A sztringmezőket gyakran "kereshetőként" és "lekérdezhetőként" jelölik meg. A keresési eredmények szűkítéséhez használt mezők közé tartozik a "rendezhető", a "szűrhető" és a "facetable".

Attribútum	Leírás
"kereshető"	Teljes szöveg vagy vektor kereshető. A szövegmezők lexikális elemzésnek vannak alávetve, például szótörést az indexelés során. Ha egy kereshető mezőt egy olyan értékre állít be, mint a "napos nap", akkor az belsőleg a "napos" és a "nap" egyedi jogkivonatokra lesz felosztva. További részletek az A teljes szöveges keresés működése című cikkben.
"szűrhető"	Szűrhető – A $filter lekérdezések hivatkoznak rá. Szűrhető típusú Edm.String mezők, vagy Collection(Edm.String) nem esnek szófeltörés alá, ezért az összehasonlítások csak pontos egyezéseket tartalmaznak. Ha például egy ilyen f mezőt "napos nap" értékre állít be, $filter=f eq 'sunny' akkor nem talál egyezést, csak $filter=f eq 'sunny day' az lesz.
"rendezhető"	Rendezhető – A rendszer alapértelmezés szerint érték szerint rendezi a találatokat, de a dokumentumok mezői alapján végzett rendezés is konfigurálható. A típusmezők Collection(Edm.String) nem lehetnek "rendezhetőek".
"facetable"	Kategorizálható – Általában akkor használják, ha a keresési eredményeket a kategóriánkénti találatok számával együtt kell bemutatni (például szállodák egy adott városban). Ez a beállítás nem használható típusmezőkkel Edm.GeographyPoint. A szűrhető, a "rendezhető" vagy a "facetable" típusú Edm.String mezők hossza legfeljebb 32 kilobájt lehet. Részletek az Index létrehozása (REST API) című cikkben.
"kulcs"	Kulcs – Az indexen belüli dokumentumok egyedi azonosítója. Kulcsmezőként egyetlen Edm.String típusú mezőt kell megadni.
"lekért"	Lekérdezhető – Megadja, hogy a mező visszaadható-e egy keresési eredményben. Ez akkor hasznos, ha egy mezőt (például haszonkulcsot) szeretne szűrőként, rendezési vagy pontozási mechanizmusként használni, de nem szeretné, hogy a mező látható legyen a végfelhasználó számára. Ennek a tulajdonságnak az értéke key tulajdonságú mezők esetén csak true lehet.

Új mezők bármikor megadhatók, a meglévő meződefiníciók azonban az index élettartamára rögzülnek. A fejlesztők ezért általában egyszerű indexek létrehozására vagy ötletek kipróbálására használják a portált, vagy a portál oldalain néznek utána egy beállításnak. Egy index rendszeres kiegészítése hatékonyabb az index újraépítését megkönnyítő kódalapú megközelítéssel.

Feljegyzés

Az index létrehozásához használt API-k eltérő alapértelmezett viselkedéssel rendelkeznek. A REST API-k esetében a legtöbb attribútum alapértelmezés szerint engedélyezve van (például a "kereshető" és a "lekérdezhető" igaz a sztringmezőkre), és gyakran csak akkor kell beállítania őket, ha ki szeretné kapcsolni őket. A .NET SDK esetében az ellenkezője igaz. Bármely olyan tulajdonság esetében, amelyet nem állít be explicit módon, az alapértelmezett beállítás a megfelelő keresési viselkedés letiltása, kivéve, ha kifejezetten engedélyezi azt.

Fizikai struktúra és méret

Az Azure AI Searchben az index fizikai szerkezete nagyrészt belső megvalósítás. Hozzáférhet a sémához, lekérdezheti a tartalmát, monitorozhatja a méretét és kezelheti a kapacitást, de a fürtöket (indexeket, szegmenseket és más fájlokat és mappákat) a Microsoft belsőleg kezeli.

Az indexméretet az Azure Portal Indexek lapján, vagy a keresési szolgáltatással szemben kiadott GET INDEX kéréssel figyelheti. Szolgáltatásstatisztikai kérést is kibocsáthat, és ellenőrizheti a tárterület méretét.

Az index méretét a következő határozza meg:

• Dokumentumok mennyisége és összetétele
• Attribútumok az egyes mezőkön
• Indexkonfiguráció (pontosabban, hogy javaslatot tesz-e)

A dokumentum összetételét és mennyiségét az határozza meg, hogy mit szeretne importálni. Ne feledje, hogy a keresési indexnek csak kereshető tartalmat kell tartalmaznia. Ha a forrásadatok bináris mezőket tartalmaznak, hagyja ki ezeket a mezőket, kivéve, ha AI-bővítést használ a tartalom feltöréséhez és elemzéséhez, hogy kereshető szöveges információkat hozzon létre.

A mezőattribútumok határozzák meg a viselkedést. Ezeknek a viselkedéseknek a támogatása érdekében az indexelési folyamat létrehozza a szükséges adatstruktúrákat. Egy típusmező Edm.Stringesetében például a "kereshető" teljes szöveges keresést hív meg, amely fordított indexeket keres a tokenizált kifejezéshez. Ezzel szemben a "szűrhető" vagy a "rendezhető" attribútum támogatja a nem módosított sztringek iterációit. A következő szakaszban látható példa az index méretének a kiválasztott attribútumok alapján történő változásait mutatja be.

A javaslattevők olyan szerkezetek, amelyek támogatják a típusalapú vagy automatikus kiegészítésű lekérdezéseket. Így ha javaslatot tesz, az indexelési folyamat létrehozza a szó szerinti karakter egyezéséhez szükséges adatstruktúrát. A javaslattevők a mezőszinten vannak implementálva, ezért csak azokat a mezőket válassza ki, amelyek a típuselőzéshez ésszerűek.

Példa az attribútumok és javaslattevők tárolási következményeire

Az alábbi képernyőkép az attribútumok különböző kombinációiból eredő indextárolási mintákat mutatja be. Az index az ingatlan mintaindexén alapul, amelyet egyszerűen létrehozhat az Adatok importálása varázsló és a beépített mintaadatok használatával. Bár az indexsémák nem jelennek meg, az index neve alapján következtethet az attribútumokra. A realestate-searchable indexben például a "kereshető" attribútum van kiválasztva, és semmi más, a realestate-retrieveable indexben a "beolvasható" attribútum van kiválasztva, és semmi más, és így tovább.

Bár ezek az indexvariánsok némileg mesterségesek, az attribútumok tárolási hatásának széles körű összehasonlításához hivatkozhatunk rájuk:

• A "beolvasható" nincs hatással az index méretére.
• A "szűrhető", a "rendezhető", a "facetable" több tárhelyet használ fel.
• A javaslattevőnek nagy lehetősége van az index méretének növelésére, de nem annyira, mint amit a képernyőkép jelezne (az összes olyan mező ki van jelölve, amely javaslattevő-tudatossá tehető, ami a legtöbb index esetében nem valószínű).

Az előző táblázatban sem tükröződik az elemzők hatása. Ha az edgeNgram tokenizert használja a karaktersorozatoka, ab, abc, abcd () szó szerinti tárolására, az index nagyobb, mint a standard elemző használata esetén.

Alapműveletek és interakciók

Most, hogy jobban tudja, mi az index, ez a szakasz az index futásidejű műveleteit mutatja be, beleértve az egyetlen indexhez való csatlakozást és biztonságossá tételt.

Feljegyzés

Az indexek kezelésekor vegye figyelembe, hogy az indexek áthelyezéséhez vagy másolásához nincs portál- vagy API-támogatás. Ehelyett az ügyfelek általában egy másik keresési szolgáltatásra irányítják az alkalmazás üzembehelyezési megoldását (ha ugyanazt az indexnevet használják), vagy módosítsa a nevet úgy, hogy másolatot készítsen az aktuális keresési szolgáltatásról, majd hozza létre.

Indexelkülönítés

Az Azure AI Searchben egyszerre egy indexet kell használnia, ahol az összes indexhez kapcsolódó művelet egyetlen indexet céloz meg. Nincs fogalma a kapcsolódó indexek, illetve a független indexek összekapcsolása sem az indexeléshez, sem a lekérdezéshez.

Folyamatosan elérhető

Az index azonnal elérhető a lekérdezésekhez az első dokumentum indexelése után, de nem lesz teljes mértékben működőképes, amíg az összes dokumentum indexel. Belsőleg a keresési index el van osztva partíciók között, és replikákon fut. A fizikai index belsőleg van kezelve. A logikai indexet Ön kezeli.

Az indexek folyamatosan elérhetők, és nem tudják szüneteltetni vagy offline állapotba helyezni. Mivel folyamatos működésre lett tervezve, a tartalom bármilyen frissítése vagy maga az index hozzáadása valós időben történik. Emiatt előfordulhat, hogy a lekérdezések ideiglenesen hiányos eredményeket adnak vissza, ha egy kérés egybeesik egy dokumentumfrissítéssel.

Figyelje meg, hogy a lekérdezés folytonossága létezik a dokumentumműveletek (frissítés vagy törlés) és az aktuális index meglévő szerkezetét és integritását nem befolyásoló módosítások (például új mezők hozzáadása) esetében. Ha szerkezeti frissítéseket kell végeznie (meglévő mezőket kell módosítania), ezeket általában egy legördülő és újraépítési munkafolyamattal kezelik egy fejlesztési környezetben, vagy az index új verziójának létrehozásával az éles szolgáltatásban.

Az indexek újraépítésének elkerülése érdekében egyes kis módosításokat végző ügyfelek úgy döntenek, hogy egy mező "verziószámát" választják úgy, hogy létrehoznak egy újat, amely egy korábbi verzióval együtt létezik. Idővel ez elavult mezők vagy elavult egyéni elemződefiníciók formájában árva tartalomhoz vezet, különösen egy olyan éles indexben, amely költséges replikálni. Ezeket a problémákat az index tervezett frissítéseivel az index életciklus-kezelésének részeként kezelheti.

Végpontkapcsolat és biztonság

Minden indexelési és lekérdezési kérés egy indexet céloz meg. A végpontok általában a következők egyike:

Végpont	Csatlakozás és hozzáférés-vezérlés
<your-service>.search.windows.net/indexes	Az indexek gyűjteményét célozza meg. Index létrehozása, listázása vagy törlésekor használatos. Rendszergazda jogosultságok szükségesek ezekhez a műveletekhez, amelyek rendszergazdai jogosultságokkal érhetők elAPI-kulcsok vagy keresési közreműködői szerepkör.
<your-service>.search.windows.net/indexes/<your-index>/docs	Egyetlen index dokumentumgyűjteményét célozza meg. Index vagy adatfrissítés lekérdezésekor használatos. A lekérdezésekhez az olvasási jogosultságok elegendőek, és lekérdezési API-kulcsokkal vagy adatolvasó szerepkörrel érhetők el. Az adatfrissítéshez rendszergazdai jogosultságokra van szükség.

Csatlakozás az Azure AI Search szolgáltatáshoz

1. Kezdje az Azure Portallal. Az Azure-előfizetők vagy a keresési szolgáltatást létrehozó személy kezelhetik a keresési szolgáltatást az Azure Portalon. Egy Azure-előfizetéshez közreműködői vagy magasabb szintű engedélyek szükségesek a szolgáltatások létrehozásához vagy törléséhez. Ez az engedélyszint elegendő egy keresési szolgáltatás teljes kezeléséhez az Azure Portalon.

2. Próbáljon ki más ügyfeleket programozott hozzáféréshez. Az első lépésekhez az alábbi rövid útmutatókat ajánljuk:

   • Rövid útmutató: REST
   • Rövid útmutató: Azure SDK-k

Következő lépések

Gyakorlati tapasztalatot szerezhet az indexek létrehozásához az Azure AI Search szinte bármilyen mintájának vagy útmutatójának használatával. Elsőként a tartalomjegyzékben szereplő rövid útmutatók bármelyikét választhatja.

Érdemes azonban megismerkednie az index adatokkal való betöltésének módszertanával is. Az indexdefiníció és az adatimportálási stratégiák a tandemben vannak definiálva. Az alábbi cikkek további információt nyújtanak az indexek létrehozásáról és betöltéséről.

• Keresési index létrehozása
• Vektortároló létrehozása
• Indexalias létrehozása
• Adatimportálás áttekintése
• Index betöltése