Indeksowanie obiektów blob i plików w celu utworzenia wielu dokumentów wyszukiwania

Dotyczy: indeksatory obiektów blob, indeksatory plików (wersja zapoznawcza)

Domyślnie indeksator traktuje zawartość obiektu blob lub pliku jako pojedynczy dokument wyszukiwania. Jeśli chcesz bardziej szczegółową reprezentację w indeksie wyszukiwania, możesz ustawić wartości parsingMode , aby utworzyć wiele dokumentów wyszukiwania z jednego obiektu blob lub pliku. Wartości parsingMode, które prowadzą do powstania wielu dokumentów wyszukiwania, obejmują delimitedText (dla pliku CSV), jsonArray lub jsonLines (dla formatu JSON), lub markdown z trybem podrzędnym oneToMany dla języka markdown.

W przypadku korzystania z dowolnego z tych trybów analizowania nowe dokumenty wyszukiwania, które pojawiają się, muszą mieć unikatowe klucze dokumentów i pojawia się problem podczas określania, skąd pochodzi ta wartość. Obiekt blob nadrzędny ma co najmniej jedną unikatową wartość w postaci metadata_storage_path property, ale jeśli przypisuje tę wartość do więcej niż jednego dokumentu w wyszukiwarce, klucz nie jest już unikatowy w indeksie.

Aby rozwiązać ten problem, indeksator blobów generuje unikatowy AzureSearch_DocumentKey dla każdego podrzędnego dokumentu wyszukiwania utworzonego z pojedynczego nadrzędnego obiektu blob. W tym artykule wyjaśniono, jak działa ta funkcja.

Klucz dokumentu jeden do wielu

Klucz dokumentu jednoznacznie identyfikuje każdy dokument w indeksie. Jeśli nie określono trybu analizowania i jeśli w definicji indeksatora nie ma jawnego mapowania pól dla klucza dokumentu wyszukiwania, indeksator obiektów blob automatycznie mapuje metadata_storage_path property element jako klucz dokumentu. To domyślne mapowanie gwarantuje, że każdy blob będzie wyświetlany jako odrębny dokument wyszukiwania. Eliminuje również konieczność ręcznego tworzenia tego mapowania pól. Zwykle pola o identycznych nazwach i typach są jedynymi mapowanych automatycznie.

W scenariuszu wyszukiwania dokumentów w schemacie jeden do wielu, ukryty klucz dokumentu oparty na metadata_storage_path property nie jest możliwy. Aby obejść ten problem, usługa Wyszukiwanie AI platformy Azure może wygenerować klucz dokumentu dla każdej jednostki wyodrębnionej z obiektu blob. System generuje klucz o nazwie AzureSearch_DocumentKey i dodaje go do każdego dokumentu wyszukiwania. Indeksator śledzi "wiele dokumentów" utworzonych na podstawie każdego blobu i może kierować aktualizacje do indeksu wyszukiwania, gdy dane źródłowe zmieniają się w czasie.

Domyślnie, gdy nie określono jawnych mapowań pól dla pola indeksu klucza, AzureSearch_DocumentKey jest do niego mapowany, przy użyciu funkcji mapowania pól base64Encode.

Example

Przyjmij definicję indeksu z następującymi polami:

• id
• temperature
• pressure
• timestamp

Kontener na obiekty blob zawiera obiekty blob o następującej strukturze:

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

Podczas tworzenia indeksatora i ustawiania parametru parsingMode na jsonLines — bez określania jawnych mapowań pól dla pola klucza, następujące mapowanie jest stosowane niejawnie.

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

Ta konfiguracja prowadzi do jednoznacznych kluczy dokumentów, jak pokazano na poniższej ilustracji (identyfikator zakodowany w base64 skrócony dla przejrzystości).

Niestandardowe mapowanie pól dla pola klucza indeksu

Zakładając, że jest ta sama definicja indeksu co w poprzednim przykładzie, załóżmy, że kontener blobów zawiera obiekty o następującej strukturze:

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" 

Podczas tworzenia indeksatora z delimitedTextparsingMode może wydawać się naturalne, aby skonfigurować funkcję mapowania pól w polu klucza w następujący sposób:

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

Jednak to mapowanie nie powoduje wyświetlania czterech dokumentów w indeksie, ponieważ recordid pole nie jest unikatowe w obiektach blob. W związku z tym zalecamy użycie niejawnego mapowania pól zastosowanego z AzureSearch_DocumentKey właściwości do pola indeksu klucza dla trybów analizowania "jeden do wielu".

Jeśli chcesz skonfigurować jawne mapowanie pól, upewnij się, że pole źródłowe jest odrębne dla każdej jednostki we wszystkich obiektach blob.

Określanie pola klucza indeksu w danych

Przyjmując tę samą definicję indeksu co w poprzednim przykładzie i parsingMode jest ustawiony na jsonLines bez określania jawnych mapowań pól, tak aby mapowania wyglądały jak w pierwszym przykładzie, załóżmy, że kontener obiektów blob ma obiekty blob z następującą strukturą:

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żdy dokument zawiera pole id, które jest zdefiniowane jako pole key w indeksie. W takiej sytuacji system generuje unikatowe pole `AzureSearch_DocumentKeyfor the document, but it isn't used as the "key." Instead, the value of theidfield is mapped to thekey`.

Podobnie jak w poprzednim przykładzie, to mapowanie nie powoduje wyświetlania czterech dokumentów w indeksie, ponieważ id pole nie jest unikatowe w obiektach blob. W takiej sytuacji każdy wpis JSON, który określa id, powoduje scalanie z istniejącym dokumentem, zamiast przesyłać nowy. Następnie indeks odzwierciedla bieżący stan wpisu z elementem określonym id.

Ograniczenia

Gdy wpis dokumentu w indeksie jest tworzony na podstawie wiersza w pliku, zgodnie z opisem w tym artykule, usunięcie tego wiersza z pliku nie powoduje automatycznego usunięcia odpowiedniego wpisu z indeksu. Aby usunąć wpis dokumentu, należy ręcznie przesłać żądanie usunięcia do indeksu przy użyciu operacji usuwania interfejsu API REST.

Dalsze kroki

Jeśli nie znasz jeszcze podstawowej struktury i przepływu pracy indeksowania obiektów blob, najpierw zapoznaj się z tematem Indeksowanie usługi Azure Blob Storage za pomocą usługi Wyszukiwanie AI platformy Azure . Aby uzyskać więcej informacji na temat trybów analizowania dla różnych typów zawartości obiektów blob, zapoznaj się z następującymi artykułami.