Udostępnij za pośrednictwem

Definiowanie projekcji indeksu dla indeksowania nadrzędno-podrzędnego

  • Artykuł

W przypadku indeksów zawierających fragmenty dokumentów projekcja indeksu określa sposób mapowania zawartości nadrzędny-podrzędny na pola w indeksie wyszukiwania indeksowania jeden do wielu. Projekcja indeksu umożliwia wysyłanie zawartości do:

  • Pojedynczy indeks, w którym pola nadrzędne powtarzają się dla każdego fragmentu, ale ziarno indeksu znajduje się na poziomie fragmentu. Samouczek RAG jest przykładem tego podejścia.

  • Co najmniej dwa indeksy, w których indeks nadrzędny ma pola powiązane z dokumentem nadrzędnym, a indeks podrzędny jest zorganizowany wokół fragmentów. Indeks podrzędny jest podstawowym korpusem wyszukiwania, ale indeks nadrzędny może służyć do zapytań wyszukiwania, gdy chcesz pobrać pola nadrzędne określonego fragmentu lub dla niezależnych zapytań.

Większość implementacji jest pojedynczym indeksem zorganizowanym wokół fragmentów z polami nadrzędnymi, takimi jak nazwa pliku dokumentu, powtarzana dla każdego fragmentu. Jednak system jest przeznaczony do obsługi oddzielnych i wielu indeksów podrzędnych, jeśli jest to wymagane. Usługa Azure AI Search nie obsługuje sprzężeń indeksu, więc kod aplikacji musi obsługiwać indeks, który ma być używany.

Projekcja indeksu jest definiowana w zestawie umiejętności. Odpowiada za koordynowanie procesu indeksowania, który wysyła fragmenty zawartości do indeksu wyszukiwania wraz z zawartością nadrzędną skojarzoną z każdym fragmentem. Poprawia sposób działania fragmentowania danych natywnych, zapewniając więcej opcji kontrolowania indeksowania zawartości nadrzędny-podrzędny.

W tym artykule wyjaśniono, jak utworzyć schemat indeksu i wzorce projekcji indeksatora na potrzeby indeksowania jeden do wielu.

Wymagania wstępne

  • Potok indeksowania oparty na indeksatorze.

  • Indeks (co najmniej jeden), który akceptuje dane wyjściowe potoku indeksatora.

  • Obsługiwane źródło danych zawierające zawartość, którą chcesz fragmentować. Może to być wektor lub zawartość niewektorowa.

  • Umiejętność dzieląca zawartość na fragmenty, umiejętność dzielenia tekstu lub niestandardową umiejętność, która zapewnia równoważne funkcje.

Zestaw umiejętności zawiera projekcję indeksatora, która kształtuje dane dla indeksowania jeden do wielu. Zestaw umiejętności może również mieć inne umiejętności, takie jak umiejętność osadzania, taka jak AzureOpenAIEmbedding , jeśli twój scenariusz obejmuje wektoryzację zintegrowaną.

Zależność od przetwarzania indeksatora

Indeksowanie "jeden do wielu" jest zależne od zestawów umiejętności i indeksowania opartego na indeksatorze, które obejmuje następujące cztery składniki:

  • Źródło danych
  • Co najmniej jeden indeks zawartości z możliwością wyszukiwania
  • Zestaw umiejętności zawierający projekcję indeksu*
  • Indeksator

Dane mogą pochodzić z dowolnego obsługiwanego źródła danych, ale założeniem jest to, że zawartość jest wystarczająco duża, że chcesz ją fragmentować, a przyczyną fragmentowania jest implementacja wzorca RAG, który zapewnia uziemienie danych do modelu czatu. Lub wdrażasz wyszukiwanie wektorów i musisz spełnić mniejsze wymagania dotyczące rozmiaru danych wejściowych modeli osadzania.

Indeksatory ładują indeksowane dane do wstępnie zdefiniowanego indeksu. Sposób definiowania schematu i używania co najmniej jednego indeksu jest pierwszą decyzją, którą należy podjąć w scenariuszu indeksowania jeden do wielu. W następnej sekcji omówiono projekt indeksu.

Tworzenie indeksu dla indeksowania jeden do wielu

Niezależnie od tego, czy tworzysz jeden indeks dla fragmentów, które powtarzają wartości nadrzędne, czy oddzielne indeksy umieszczania pól nadrzędny-podrzędny, indeks podstawowy używany do wyszukiwania jest przeznaczony dla fragmentów danych. Musi mieć następujące pola:

  • Pole klucza dokumentu unikatowo identyfikujące każdy dokument. Należy go zdefiniować jako typ Edm.String z analizatorem keyword .

  • Pole kojarzące każdy fragment z elementem nadrzędnym. Musi być typu Edm.String. Nie może to być pole klucza dokumentu i musi mieć filterable ustawioną wartość true. Jest on określany jako parent_id w przykładach i jako przewidywany klucz wartości w tym artykule.

  • Inne pola zawartości, takie jak pola tekstowe lub wektoryzowane fragmenty.

Indeks musi istnieć w usłudze wyszukiwania przed utworzeniem zestawu umiejętności lub uruchomieniem indeksatora.

Schemat pojedynczego indeksu obejmujący pola nadrzędne i podrzędne

Pojedynczy indeks zaprojektowany wokół fragmentów z zawartością nadrzędną powtarzaną dla każdego fragmentu jest dominującym wzorcem scenariuszy wyszukiwania RAG i wektorów. Możliwość skojarzenia prawidłowej zawartości nadrzędnej z każdym fragmentem jest włączona za pośrednictwem projekcji indeksu.

Poniższy schemat jest przykładem spełniającym wymagania projekcji indeksu. W tym przykładzie pola nadrzędne to parent_id i tytuł. Pola podrzędne są fragmentami wektorów i wektorów niewektorowych. Chunk_id jest identyfikatorem dokumentu tego indeksu. Parent_id i tytuł są powtarzane dla każdego fragmentu w indeksie.

Do utworzenia indeksu można użyć witryny Azure Portal, interfejsów API REST lub zestawu Azure SDK.

{
    "name": "my_consolidated_index",
    "fields": [
        {"name": "chunk_id", "type": "Edm.String", "key": true, "filterable": true, "analyzer": "keyword"},
        {"name": "parent_id", "type": "Edm.String", "filterable": true},
        {"name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "sortable": true, "retrievable": true},
        {"name": "chunk", "type": "Edm.String","searchable": true,"retrievable": true},
        {"name": "chunk_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": false, "stored": false, "dimensions": 1536, "vectorSearchProfile": "hnsw"}
    ],
    "vectorSearch": {
        "algorithms": [{"name": "hsnw", "kind": "hnsw", "hnswParameters": {}}],
        "profiles": [{"name": "hsnw", "algorithm": "hnsw"}]
    }
}

Dodawanie projekcji indeksu do zestawu umiejętności

Projekcje indeksu są definiowane wewnątrz definicji zestawu umiejętności i są definiowane głównie jako tablica selectors, gdzie każdy selektor odpowiada innego indeksu docelowego w usłudze wyszukiwania. Ta sekcja rozpoczyna się od składni i przykładów kontekstu, a następnie odwołania do parametrów.

Wybierz kartę dla różnych składni interfejsu API. Obecnie nie ma obsługi portalu do konfigurowania projekcji, poza edytowaniem definicji JSON zestawu umiejętności. Zapoznaj się z przykładem REST dla formatu JSON.

Projekcje indeksów są ogólnie dostępne. Zalecamy najnowszy stabilny interfejs API:

Oto przykładowy ładunek definicji projekcji indeksu, którego można użyć do projekcji poszczególnych stron wyjściowych według umiejętności Dzielenie tekstu jako własnych dokumentów w indeksie wyszukiwania.

"indexProjections": {
    "selectors": [
        {
            "targetIndexName": "my_consolidated_index",
            "parentKeyFieldName": "parent_id",
            "sourceContext": "/document/pages/*",
            "mappings": [
                {
                    "name": "chunk",
                    "source": "/document/pages/*",
                    "sourceContext": null,
                    "inputs": []
                },
                {
                    "name": "chunk_vector",
                    "source": "/document/pages/*/chunk_vector",
                    "sourceContext": null,
                    "inputs": []
                },
                {
                    "name": "title",
                    "source": "/document/title",
                    "sourceContext": null,
                    "inputs": []
                }
            ]
        }
    ],
    "parameters": {
        "projectionMode": "skipIndexingParentDocuments"
    }
}

Dokumentacja parametrów

Parametry projekcji indeksu Definicja
selectors Parametry dla głównego korpusu wyszukiwania, zwykle ten zaprojektowany wokół fragmentów.
projectionMode Opcjonalny parametr zawierający instrukcje dla indeksatora. Jedyną prawidłową wartością tego parametru jest skipIndexingParentDocuments, i jest używana, gdy indeks fragmentów jest podstawowym korpusem wyszukiwania i należy określić, czy pola nadrzędne są indeksowane jako dodatkowe dokumenty wyszukiwania w indeksie fragmentowanym. Jeśli nie ustawisz skipIndexingParentDocumentsparametru , w indeksie uzyskasz dodatkowe dokumenty wyszukiwania, które mają wartość null dla fragmentów, ale wypełnione tylko polami nadrzędnymi. Jeśli na przykład pięć dokumentów współtworzy 100 fragmentów indeksu, liczba dokumentów w indeksie wynosi 105. Pięć dokumentów utworzonych lub nadrzędnych zawiera wartości null dla pól fragmentów (podrzędnych), co znacznie różni się od większości dokumentów w indeksie. Zalecamy projectionMode ustawienie wartości skipIndexingParentDocument.

Selektory mają następujące parametry w ramach ich definicji.

Parametry selektora Definicja
targetIndexName Nazwa indeksu, w którym są przewidywane dane indeksu. Jest to pojedynczy indeks fragmentowany z powtarzającymi się polami nadrzędnymi lub indeks podrzędny, jeśli używasz oddzielnych indeksów dla zawartości nadrzędnej-podrzędnej.
parentKeyFieldName Nazwa pola zawierającego klucz dokumentu nadrzędnego.
sourceContext Adnotacja wzbogacania, która definiuje stopień szczegółowości mapowania danych na poszczególne dokumenty wyszukiwania. Aby uzyskać więcej informacji, zobacz Kontekst umiejętności i język adnotacji wejściowych.
mappings Tablica mapowań wzbogaconych danych na pola w indeksie wyszukiwania. Każde mapowanie składa się z następujących elementów:
name: nazwa pola w indeksie wyszukiwania, do którego powinny być indeksowane dane.
source: ścieżka adnotacji wzbogacania, z którą powinny zostać pobrane dane.

Każda z nich mapping może również rekursywnie definiować dane za pomocą opcjonalnego sourceContext pola i inputs , podobnie jak w przypadku magazynu wiedzy lub umiejętności kształtowania. W zależności od aplikacji te parametry umożliwiają kształtowanie danych na pola typu Edm.ComplexType w indeksie wyszukiwania. Niektóre maszyny LLM nie akceptują złożonego typu w wynikach wyszukiwania, więc używany moduł LLM określa, czy mapowanie typu złożonego jest przydatne, czy nie.

Parametr mappings jest ważny. Należy jawnie mapować każde pole w indeksie podrzędnym, z wyjątkiem pól identyfikatora, takich jak klucz dokumentu i identyfikator nadrzędny.

To wymaganie jest sprzeczne z innymi konwencjami mapowania pól w usłudze Azure AI Search. W przypadku niektórych typów źródeł danych indeksator może niejawnie mapować pola na podstawie podobnych nazw lub znanych cech (na przykład indeksatory obiektów blob używają unikatowej ścieżki magazynu metadanych jako domyślnego klucza dokumentu). Jednak w przypadku projekcji indeksatora należy jawnie określić każde mapowanie pól po stronie "wiele" relacji.

Nie twórz mapowania pól dla pola klucza nadrzędnego. W ten sposób zakłóca śledzenie zmian i synchronizowane odświeżanie danych.

Obsługa dokumentów nadrzędnych

Teraz, gdy znasz już kilka wzorców indeksowania "jeden do wielu", porównajmy kluczowe różnice między poszczególnymi opcjami. Projekcje indeksów skutecznie generują dokumenty "podrzędne" dla każdego dokumentu nadrzędnego, który jest uruchamiany przez zestaw umiejętności. Istnieje kilka opcji obsługi dokumentów nadrzędnych.

  • Aby wysyłać dokumenty nadrzędne i podrzędne do oddzielnych indeksów, ustaw targetIndexName dla definicji indeksatora indeksator indeksu i ustaw targetIndexName selektor projekcji indeksu na indeks podrzędny.

  • Aby zachować dokumenty nadrzędne i podrzędne w tym samym indeksie, ustaw indeksator targetIndexName i projekcję targetIndexName indeksu na ten sam indeks.

  • Aby uniknąć tworzenia dokumentów wyszukiwania nadrzędnego i zapewnienia, że indeks zawiera tylko dokumenty podrzędne o jednolitym ziarnie, ustaw targetIndexName dla definicji indeksatora i selektora na ten sam indeks, ale dodaj dodatkowy parameters obiekt po selectors, z kluczem projectionMode ustawionym na skipIndexingParentDocuments, jak pokazano poniżej:

    "indexProjections": {
    "selectors": [
        ...
    ],
    "parameters": {
        "projectionMode": "skipIndexingParentDocuments"
    }
}

Przeglądanie mapowań pól

Indeksatory są powiązane z trzema różnymi typami mapowań pól. Przed uruchomieniem indeksatora sprawdź mapowania pól i dowiedz się, kiedy należy używać każdego typu.

Mapowania pól są definiowane w indeksatorze i używane do mapowania pola źródłowego na pole indeksu. Mapowania pól są używane do ścieżek danych, które windują dane ze źródła i przekazują je do indeksowania bez pośredniego kroku przetwarzania umiejętności. Zazwyczaj indeksator może automatycznie mapować pola o tej samej nazwie i typie. Jawne mapowania pól są wymagane tylko wtedy, gdy występują rozbieżności. W indeksowaniu "jeden do wielu" i omówionych do tej pory wzorcach może nie być konieczne mapowanie pól.

Mapowania pól wyjściowych są definiowane w indeksatorze i używane do mapowania wzbogaconej zawartości wygenerowanej przez zestaw umiejętności na pole do indeksu głównego. W wzorcach jeden do wielu opisanych w tym artykule jest to indeks nadrzędny w rozwiązaniu dwuindeksowym. W przykładach przedstawionych w tym artykule indeks nadrzędny jest rozrzedżony, z tylko polem tytułu i to pole nie jest wypełniane zawartością z przetwarzania zestawu umiejętności, więc nie mapujemy pól wyjściowych.

Mapowania pól projekcji indeksatora służą do mapowania zawartości wygenerowanej przez zestaw umiejętności na pola w indeksie podrzędnym. W przypadkach, gdy indeks podrzędny zawiera również pola nadrzędne (podobnie jak w rozwiązaniu skonsolidowanego indeksu), należy skonfigurować mapowania pól dla każdego pola zawierającego zawartość, w tym pola tytułu na poziomie nadrzędnym, przy założeniu, że tytuł ma być wyświetlany w każdym fragmentowanym dokumencie. Jeśli używasz oddzielnych indeksów nadrzędnych i podrzędnych, projekcje indeksatora powinny mieć mapowania pól tylko dla pól na poziomie podrzędnym.

Uwaga

Mapowania pól wyjściowych i mapowania pól projekcji indeksatora akceptują wzbogacone węzły drzewa dokumentów jako dane wejściowe źródła. Znajomość sposobu określania ścieżki do każdego węzła jest niezbędna do skonfigurowania ścieżki danych. Aby dowiedzieć się więcej na temat składni ścieżki, zobacz Dokumentacja ścieżki do wzbogaconych węzłów i definicji zestawu umiejętności, aby zapoznać się z przykładami.

Uruchamianie indeksatora

Po utworzeniu źródła danych, indeksów i zestawu umiejętności możesz utworzyć i uruchomić indeksator. Ten krok powoduje przejście potoku do wykonania.

Możesz wykonać zapytanie względem indeksu wyszukiwania po zakończeniu przetwarzania w celu przetestowania rozwiązania.

Cykl życia zawartości

W zależności od bazowego źródła danych indeksator zwykle zapewnia ciągłe śledzenie zmian i wykrywanie usuwania. W tej sekcji opisano cykl życia zawartości indeksowania jeden do wielu w odniesieniu do odświeżania danych.

W przypadku źródeł danych, które zapewniają śledzenie zmian i wykrywanie usuwania, proces indeksatora może pobierać zmiany w danych źródłowych. Za każdym razem, gdy uruchamiasz indeksator i zestaw umiejętności, projekcje indeksu są aktualizowane, jeśli zestaw umiejętności lub bazowe dane źródłowe uległy zmianie. Wszelkie zmiany pobierane przez indeksator są propagowane przez proces wzbogacania do projekcji w indeksie, zapewniając, że przewidywane dane są bieżącą reprezentacją zawartości w źródle danych źródłowych. Działanie odświeżania danych jest przechwytywane w przewidywanej wartości klucza dla każdego fragmentu. Ta wartość jest aktualizowana po zmianie danych bazowych.

Uwaga

Chociaż można ręcznie edytować dane w projektowanych dokumentach przy użyciu interfejsu API wypychania indeksu, należy tego unikać. Ręczne aktualizacje indeksu są zastępowane podczas następnego wywołania potoku, przy założeniu, że dokument w danych źródłowych jest aktualizowany, a źródło danych ma włączone śledzenie zmian lub wykrywanie usuwania.

Zaktualizowana zawartość

Jeśli dodasz nową zawartość do źródła danych, nowe fragmenty lub dokumenty podrzędne zostaną dodane do indeksu podczas następnego uruchomienia indeksatora.

Jeśli zmodyfikujesz istniejącą zawartość w źródle danych, fragmenty są aktualizowane przyrostowo w indeksie wyszukiwania, jeśli używane źródło danych obsługuje wykrywanie śledzenia zmian i usuwania. W przypadku egzaminu, jeśli wyraz lub zdanie zmieni się w dokumencie, fragment w indeksie docelowym zawierającym ten wyraz lub zdanie zostanie zaktualizowany podczas następnego uruchomienia indeksatora. Inne typy aktualizacji, takie jak zmiana typu pola i niektóre przypisania, nie są obsługiwane dla istniejących pól. Aby uzyskać więcej informacji na temat dozwolonych aktualizacji, zobacz Aktualizowanie schematu indeksu.

Niektóre źródła danych, takie jak Usługa Azure Storage , domyślnie obsługują śledzenie zmian i usuwania na podstawie znacznika czasu. Inne źródła danych, takie jak OneLake, Azure SQL lub Azure Cosmos DB, muszą być skonfigurowane do śledzenia zmian.

Usunięta zawartość

Jeśli zawartość źródłowa już nie istnieje (na przykład jeśli tekst zostanie skrócony, aby mieć mniej fragmentów), odpowiedni dokument podrzędny w indeksie wyszukiwania zostanie usunięty. Pozostałe dokumenty podrzędne również otrzymują aktualizację klucza w celu uwzględnienia nowej wartości skrótu, nawet jeśli ich zawartość nie zmieniła się w inny sposób.

Jeśli dokument nadrzędny zostanie całkowicie usunięty ze źródła danych, odpowiednie dokumenty podrzędne zostaną usunięte tylko wtedy, gdy usunięcie zostanie wykryte przez definicję dataDeletionDetectionPolicy źródła danych. Jeśli nie masz skonfigurowanego dokumentu nadrzędnego dataDeletionDetectionPolicy i musisz usunąć go ze źródła danych, należy ręcznie usunąć dokumenty podrzędne, jeśli nie są już potrzebne.

Prognozowana wartość klucza

Aby zapewnić integralność danych dla zaktualizowanej i usuniętej zawartości, odświeżanie danych w indeksowaniu "jeden do wielu" opiera się na przewidywanej wartości klucza po stronie "wiele". Jeśli używasz wektoryzacji zintegrowanej lub kreatora importu i wektoryzacji danych, prognozowana wartość klucza jest parent_id polem po stronie fragmentowanej lub "wiele" indeksu.

Przewidywana wartość klucza jest unikatowym identyfikatorem generowanym przez indeksator dla każdego dokumentu. Zapewnia unikatowość i umożliwia prawidłowe działanie śledzenia zmian i usuwania. Ten klucz zawiera następujące segmenty:

  • Losowy skrót gwarantujący unikatowość. Ten skrót zmienia się, jeśli dokument nadrzędny jest aktualizowany w kolejnych uruchomieniach indeksatora.
  • Klucz dokumentu nadrzędnego.
  • Ścieżka adnotacji wzbogacania, która identyfikuje kontekst wygenerowany przez ten dokument.

Jeśli na przykład podzielisz dokument nadrzędny z wartością klucza "aa1b22c33" na cztery strony, a następnie każda z tych stron będzie projektowana jako własny dokument za pomocą projekcji indeksu:

  • aa1b22c33
  • aa1b22c33_pages_0
  • aa1b22c33_pages_1
  • aa1b22c33_pages_2

Jeśli dokument nadrzędny jest aktualizowany w danych źródłowych, na przykład w wyniku większej liczby fragmentowanych stron, losowe zmiany skrótu, dodawane są więcej stron, a zawartość każdego fragmentu jest aktualizowana tak, aby pasowała do dowolnego elementu w dokumencie źródłowym.

Przykład oddzielnych indeksów nadrzędny-podrzędny

W tej sekcji przedstawiono przykłady oddzielnych indeksów nadrzędnych i podrzędnych. Jest to nietypowy wzorzec, ale możliwe, że mogą istnieć wymagania aplikacji, które najlepiej spełniają przy użyciu tego podejścia. W tym scenariuszu projektujesz zawartość nadrzędno-podrzędną na dwa oddzielne indeksy.

Każdy schemat zawiera pola dla określonego ziarna, z polem identyfikatora nadrzędnego wspólnego dla obu indeksów do użycia w zapytaniu odnośnika. Podstawowy korpus wyszukiwania jest indeksem podrzędnym, ale następnie wydaj zapytanie odnośnika, aby pobrać pola nadrzędne dla każdego dopasowania w wyniku. Usługa Azure AI Search nie obsługuje sprzężeń w czasie wykonywania zapytań, więc kod aplikacji lub warstwa aranżacji musi scalić lub sortować wyniki, które mogą być przekazywane do aplikacji lub procesu.

Indeks nadrzędny ma pole i tytuł parent_id. Parent_id jest kluczem dokumentu. Nie potrzebujesz konfiguracji wyszukiwania wektorowego, chyba że chcesz wektorować pola na poziomie dokumentu nadrzędnego.

{
    "name": "my-parent-index",
    "fields": [

        {"name": "parent_id", "type": "Edm.String", "filterable": true},
        {"name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "sortable": true, "retrievable": true},
    ]
}

Indeks podrzędny zawiera pola fragmentowane oraz pole parent_id. Jeśli używasz zintegrowanej wektoryzacji, profilów oceniania, semantycznego rankera lub analizatorów, ustawisz je w indeksie podrzędnym.

{
    "name": "my-child-index",
    "fields": [
        {"name": "chunk_id", "type": "Edm.String", "key": true, "filterable": true, "analyzer": "keyword"},
        {"name": "parent_id", "type": "Edm.String", "filterable": true},
         {"name": "chunk", "type": "Edm.String","searchable": true,"retrievable": true},
        {"name": "chunk_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": false, "stored": false, "dimensions": 1536, "vectorSearchProfile": "hnsw"}
    ],
    "vectorSearch": {
        "algorithms": [{"name": "hsnw", "kind": "hnsw", "hnswParameters": {}}],
        "profiles": [{"name": "hsnw", "algorithm": "hnsw"}]
    },
    "scoringProfiles": [],
    "semanticConfiguration": [],
    "analyzers": []
}

Oto przykład definicji projekcji indeksu, która określa ścieżkę danych, która indeksator powinien używać do indeksowania zawartości. Określa nazwę indeksu podrzędnego w definicji projekcji indeksu i określa mapowania każdego pola podrzędnego lub na poziomie fragmentu. Jest to jedyne miejsce, w których określono nazwę indeksu podrzędnego.

"indexProjections": {
    "selectors": [
        {
            "targetIndexName": "my-child-index",
            "parentKeyFieldName": "parent_id",
            "sourceContext": "/document/pages/*",
            "mappings": [
                {
                    "name": "chunk",
                    "source": "/document/pages/*",
                    "sourceContext": null,
                    "inputs": []
                },
                {
                    "name": "chunk_vector",
                    "source": "/document/pages/*/chunk_vector",
                    "sourceContext": null,
                    "inputs": []
                }
            ]
        }
    ]
}

Definicja indeksatora określa składniki potoku. W definicji indeksatora nazwa indeksu, która ma być podana, jest indeksem nadrzędnym. Jeśli potrzebujesz mapowań pól dla pól na poziomie nadrzędnym, zdefiniuj je w polach outputFieldMappings. W przypadku indeksowania "jeden do wielu", które używa oddzielnych indeksów, definicja indeksatora może wyglądać podobnie do poniższego przykładu.

{
  "name": "my-indexer",
  "dataSourceName": "my-ds",
  "targetIndexName": "my-parent-index",
  "skillsetName" : "my-skillset"
  "parameters": { },
  "fieldMappings": (optional) Maps fields in the underlying data source to fields in an index,
  "outputFieldMappings" : (required) Maps skill outputs to fields in an index,
}

Następny krok

Fragmentowanie danych i indeksowanie jeden do wielu są częścią wzorca RAG w usłudze Azure AI Search. Przejdź do poniższego samouczka i przykładowego kodu, aby dowiedzieć się więcej na ten temat.

Jak utworzyć rozwiązanie RAG przy użyciu usługi Azure AI Search