Indexování objektů blob a souborů za účelem vytvoření více vyhledávacích dokumentů

Poznámka:

Azure AI Vyhledávač je k dispozici prostřednictvím portálu Azure, rozhraní REST API a Sady Azure SDK. Podporuje také Foundry IQ, spravovanou znalostní vrstvu, která transformuje podnikový obsah na opakovaně použitelné znalostní báze s podporou oprávnění pro agenty na portálu Microsoft Foundry.

Platí pro: Indexery blobů, Indexery souborů (ve verzi Preview)

Indexer ve výchozím nastavení zachází s obsahem objektu blob nebo souboru jako s jedním prohledávacím dokumentem. Pokud chcete podrobnější reprezentaci v indexu vyhledávání, můžete nastavit hodnoty parsingMode pro vytvoření více vyhledávacích dokumentů z jednoho objektu blob nebo souboru. Hodnoty parsingMode, které vedou k mnoha dokumentům vyhledávání, zahrnují delimitedText (pro CSV), jsonArray nebo jsonLines (pro JSON), či markdown s dílčím režimem oneToMany pro markdown.

Když použijete některý z těchto režimů analýzy, nové dokumenty hledání, které se objeví, musí mít jedinečné klíče dokumentu a vzniká problém při určování, odkud tato hodnota pochází. Nadřazený blob má alespoň jednu jedinečnou hodnotu ve formě metadata_storage_path property, ale pokud touto hodnotou přispívá do více než jednoho vyhledávacího dokumentu, klíč už není jedinečný v indexu.

Aby se tento problém vyřešil, indexer objektů blob vygeneruje AzureSearch_DocumentKey jedinečný identifikátor každého podřízeného vyhledávacího dokumentu vytvořeného z nadřazeného objektu blob. Tento článek vysvětluje, jak tato funkce funguje.

Klíč dokumentu 1:N

Klíč dokumentu jednoznačně identifikuje každý dokument v indexu. Pokud není zadán žádný režim analýzy a neexistuje žádné explicitní mapování polí v definici indexeru pro klíč dokumentu vyhledávání, indexer objektů blob automaticky mapuje metadata_storage_path property jako klíč dokumentu. Toto výchozí mapování zajišťuje, aby se každý objekt blob zobrazil jako samostatný vyhledávací dokument. Eliminuje také potřebu ručního vytvoření tohoto mapování polí. Za normálních okolností jsou pole s identickými názvy a typy jedinými namapovanými automaticky.

Ve scénáři vyhledávání dokumentů 1:N není možné použít implicitní klíč dokumentu založený na metadata_storage_path property. Jako alternativní řešení může Azure AI Vyhledávač vygenerovat klíč dokumentu pro každou jednotlivou entitu extrahovanou z objektu blob. Systém vygeneruje volaný AzureSearch_DocumentKey klíč a přidá ho do každého hledaného dokumentu. Indexer sleduje "mnoho dokumentů" vytvořených z každého objektu blob a může cílit na aktualizace indexu vyhledávání, když se zdrojová data v průběhu času změní.

Pokud není zadáno žádné explicitní mapování polí pro pole indexu klíče, AzureSearch_DocumentKey mapuje se na něj pomocí base64Encode funkce mapování polí.

Example

Předpokládejme definici indexu s následujícími poli:

  • id
  • temperature
  • pressure
  • timestamp

Váš kontejner blobů obsahuje objekty blob s následující strukturou:

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" }

Když vytvoříte indexer a nastavíte parsingMode na jsonLines – bez zadání explicitních mapování polí pro pole klíče, následující mapování se použije implicitně.

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

Výsledkem tohoto nastavení jsou nejednoznačné klíče dokumentu, podobně jako na následujícím obrázku (ID kódování base64 se zkracuje kvůli stručnosti).

ID Teplota tlak časové razítko
aHR0 ... YjEuanNvbjsx 100 100 2024-02-13T00:00:00Z
aHR0 ... YjEuanNvbjsy 33 30 2024-02-14T00:00:00Z
aHR0 ... YjIuanNvbjsx 1 1 12.1.2023 00:00:00 UTC
aHR0 ... YjIuanNvbjsy 120 3 2022-05-11T00:00:00Z

Mapování vlastních polí pro pole klíče indexu

Předpokládejme, že kontejner objektů blob má stejnou definici indexu jako v předchozím příkladu s následující strukturou:

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" 

Při vytváření indexeru s delimitedTextparsingMode může být přirozené nastavit funkci mapování polí na klíčové pole následujícím způsobem:

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

Toto mapování ale nevede k tomu, že by v indexu byly zobrazeny čtyři dokumenty, protože recordid pole není jedinečné napříč objekty blob. Proto doporučujeme použít implicitní mapování polí aplikované z vlastnosti AzureSearch_DocumentKey na pole klíčového indexu v režimech analýzy typu 1:N.

Pokud chcete nastavit explicitní mapování polí, ujistěte se, že je pole sourceField jedinečné pro každou jednotlivou entitu napříč všemi objekty blob.

Poznámka:

Přístup používaný zajištěním AzureSearch_DocumentKey jedinečnosti u extrahované entity se může změnit, a proto byste neměli spoléhat na jeho hodnotu pro potřeby vaší aplikace.

Zadání pole indexového klíče v datech

Za předpokladu, že je stejná definice indexu jako v předchozím příkladu a parsingMode je nastavená na jsonLines bez zadání explicitních mapování polí, aby mapování vypadala jako v prvním příkladu, předpokládejme, že kontejner objektů blob má objekty blob s následující strukturou:

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" 

Každý dokument obsahuje id pole, které je definováno jako key pole v indexu. V této situaci systém vygeneruje jedinečné pole `AzureSearch_DocumentKeyfor the document, but it isn't used as the "key." Instead, the value of theidfield is mapped to thekey`.

Podobně jako v předchozím příkladu toto mapování nemá za následek zobrazení čtyř dokumentů v indexu, protože id pole není jedinečné napříč objekty blob. Pokud dojde k této situaci, jakákoli položka JSON, která určuje id , způsobí sloučení s existujícím dokumentem místo nahrání nového dokumentu. Index pak odráží nejnovější stav položky se zadaným id.

Omezení

Když se položka dokumentu v indexu vytvoří z řádku v souboru, jak je vysvětleno v tomto článku, odstranění tohoto řádku ze souboru automaticky neodebere odpovídající položku z indexu. Pokud chcete odstranit položku dokumentu, musíte ručně odeslat požadavek na odstranění do indexu pomocí operace odstranění rozhraní REST API.

Další kroky

Pokud ještě neznáte základní strukturu a pracovní postup indexování objektů blob, měli byste nejprve zkontrolovat indexování služby Azure Blob Storage pomocí služby Azure AI Vyhledávač . Další informace o parsování režimů pro různé typy obsahu objektů blob najdete v následujících článcích.