Blobok és fájlok indexelése több keresési dokumentum létrehozásához

Megjegyzés:

Azure AI Keresés a Azure portálon, REST API-kon és Azure SDK-k keresztül érhető el. Emellett a Foundry IQ-t is támogatja, amely a vállalati tartalmakat újrafelhasználható, engedélytudatos tudásbázisokká alakítja át az Microsoft Foundry portálon található ügynökök számára.

A következőkre vonatkozik: Blobindexerek, Fájlindexelők (előzetes verzió)

Az indexelők alapértelmezés szerint egyetlen keresési dokumentumként kezelik egy blob vagy fájl tartalmát. Ha részletesebb megjelenítést szeretne egy keresési indexben, beállíthatja az parsingMode értékeket, hogy több keresési dokumentumot hozzon létre egy blobból vagy fájlból. A sok keresési dokumentumot eredményező parsingMode értékek a következők: delimitedText (a CSV számára), jsonArray vagy jsonLines (a JSON számára), vagy markdown a oneToMany almódjával a markdown esetén.

Ezen elemzési módok bármelyikének használatakor a megjelenő új keresési dokumentumoknak egyedi dokumentumkulcsokkal kell rendelkezniük, és probléma merül fel annak meghatározásában, hogy az érték honnan származik. A szülőblob legalább egy egyedi értékkel metadata_storage_path propertyrendelkezik, de ha több keresési dokumentumhoz is hozzájárul, a kulcs már nem egyedi az indexben.

A probléma megoldásához a blobindexelő létrehoz egy AzureSearch_DocumentKey olyan fájlt, amely egyedileg azonosítja az egyetlen blob szülője által létrehozott gyermekkeresési dokumentumokat. Ez a cikk a funkció működését ismerteti.

Egy-többhöz kapcsolódó dokumentumkulcs

A dokumentumkulcs egyedileg azonosítja az egyes dokumentumokat egy indexben. Ha nincs megadva elemzési mód, és nincs explicit mezőleképezés a keresési dokumentumkulcs indexelődefiníciójában, a blobindexelő automatikusan dokumentumkulcsként leképezi azt metadata_storage_path property . Ez az alapértelmezett leképezés biztosítja, hogy az egyes blobok különálló keresési dokumentumként jelenjenek meg. Emellett szükségtelenné teszi, hogy manuálisan hozza létre ezt a mezőleképezést. Általában csak az azonos nevű és típusú mezők vannak automatikusan leképezve.

Egy a többhöz keresési dokumentum helyzetében nem lehet implicit dokumentumkulcsot kialakítani metadata_storage_path property. Áthidaló megoldásként az Azure AI Keresés létrehozhat egy dokumentumkulcsot a blobból kinyert minden egyes entitáshoz. A rendszer létrehoz egy AzureSearch_DocumentKey kulcsot, és hozzáadja minden keresési dokumentumhoz. Az indexelő nyomon követi az egyes blobokból létrehozott "sok dokumentumot", és a forrásadatok időbeli változásakor megcélozza a keresési index frissítéseit.

Alapértelmezés szerint, amikor nincs megadva explicit mezőleképezés a kulcsindex mezőhöz, a AzureSearch_DocumentKey a mezőleképezési függvény segítségével a base64Encode mezőre kerül leképezésre.

Example

Tegyük fel, hogy egy indexdefiníció a következő mezőkkel rendelkezik:

  • id
  • temperature
  • pressure
  • timestamp

A blobtárolóban pedig a következő struktúrájú blobok vannak:

Blob1.json

{ "temperature": 100, "pressure": 100, "timestamp": "2024-02-13T00:00:00Z" }
{ "temperature" : 33, "pressure" : 30, "timestamp": "2024-02-14T00:00:00Z" }

Blob2.json

{ "temperature": 1, "pressure": 1, "timestamp": "2023-01-12T00:00:00Z" }
{ "temperature" : 120, "pressure" : 3, "timestamp": "2022-05-11T00:00:00Z" }

Amikor létrehoz egy indexelőt, és beállítja a parsingMode értékét – anélkül, hogy jsonLines explicit mezőleképezést adna meg a kulcsmezőhöz, a következő leképezés implicit módon kerül alkalmazásra.

{
    "sourceFieldName" : "AzureSearch_DocumentKey",
    "targetFieldName": "id",
    "mappingFunction": { "name" : "base64Encode" }
}

Ez a beállítás az alábbi ábrához hasonló egyértelmű dokumentumkulcsokat eredményez (a rövidítéshez rövidített base64 kódolású azonosító).

azonosító hőmérséklet nyomás timestamp
aHR0 ... YjEuanNvbjsx 100 100 2024-02-13T00:00:00Z
aHR0 ... YjEuanNvbjsy 33 30 2024-02-14T00:00:00Z
aHR0 ... YjIuanNvbjsx 1 1 2023-01-12T00:00:00Z
aHR0 ... YjIuanNvbjsy 120 3 2022-05-11T00:00:00Z

Egyéni mezőleképezés indexkulcsmezőhöz

Tegyük fel, hogy a blobtároló az előző példával megegyező indexdefinícióval rendelkezik, és az alábbi struktúrával rendelkezik:

Blob1.json

recordid, temperature, pressure, timestamp
1, 100, 100,"2024-02-13T00:00:00Z" 
2, 33, 30,"2024-02-14T00:00:00Z" 

Blob2.json

recordid, temperature, pressure, timestamp
1, 1, 1,"20123-01-12T00:00:00Z" 
2, 120, 3,"2022-05-11T00:00:00Z" 

Amikor létrehoz egy indexelőt delimitedTextaz parsingMode használatával, természetesnek tűnhet, ha egy mezőleképezési függvényt állít be a kulcsmezőre az alábbiak szerint:

{
    "sourceFieldName" : "recordid",
    "targetFieldName": "id"
}

Ez a leképezés azonban nem eredményez négy dokumentum megjelenítését az indexben, mert a recordid mező nem egyedi a blobok között. Ezért javasoljuk, hogy alkalmazza az implicit mezőleképezést, amely a AzureSearch_DocumentKey tulajdonságból indul ki, és a „egy-a-többhöz” elemzési módok kulcs index mezőjére irányul.

Ha explicit mezőleképezést szeretne beállítani, győződjön meg arról, hogy a sourceField minden egyes entitáshoz különböző az összes blobban.

Megjegyzés:

A kinyert entitásonkénti egyediség biztosításával AzureSearch_DocumentKey alkalmazott megközelítés változhat, ezért nem szabad az alkalmazás igényeire támaszkodnia.

Az indexkulcs mezőjének megadása az adatokban

A korábbi példával megegyező indexdefiníciót feltételezve, és ha a parsingMode úgy van beállítva, hogy nincs explicit mezőleképezés megadva, így a leképezések az első példa szerint néznek ki, tételezzük fel, hogy a blobtároló a következő struktúrájú blobokat tartalmazza:

Blob1.json

id, temperature, pressure, timestamp
1, 100, 100,"2024-02-13T00:00:00Z" 
2, 33, 30,"2024-02-14T00:00:00Z"

Blob2.json

id, temperature, pressure, timestamp
1, 1, 1,"2023-01-12T00:00:00Z" 
2, 120, 3,"2022-05-11T00:00:00Z" 

Minden dokumentum tartalmazza a id mezőt, amely az key index mezőjeként van definiálva. Ebben az esetben a rendszer létrehoz egy egyedi AzureSearch_DocumentKeyfor the document, but it isn't used as the "key." Instead, the value of theazonosítókulcsfield is mapped to themezőt.

Az előző példához hasonlóan ez a leképezés nem eredményez négy dokumentum megjelenítését az indexben, mert a id mező nem egyedi a blobok között. Amikor ez a helyzet előfordul, bármely JSON-bejegyzés, amely megad egy id, összevonja a meglévő dokumentummal ahelyett, hogy egy újat töltene fel. Az index ezután a megadott idbejegyzés legújabb állapotát tükrözi.

Korlátozások

Ha az indexben lévő dokumentumbejegyzés egy fájl egy sorából jön létre, a jelen cikkben ismertetett módon a sor törlése a fájlból nem távolítja el automatikusan a megfelelő bejegyzést az indexből. A dokumentumbejegyzés törléséhez manuálisan kell elküldenie egy törlési kérelmet az indexnek a REST API törlési műveletével.

Következő lépések

Ha még nem ismeri a blobindexelés alapvető struktúráját és munkafolyamatát, először tekintse át az Azure Blob Storage és az Azure AI Keresés indexelését . A különböző blobtartalmak elemzési módjairól az alábbi cikkekben olvashat bővebben.