Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Uwaga
Wyszukiwanie AI platformy Azure jest dostępna za pośrednictwem portalu Azure, interfejsów API REST i Azure SDKs. Jest także podstawą Foundry IQ — zarządzanej warstwy wiedzy, która przekształca treści przedsiębiorstwa w bazy wiedzy wielokrotnego użytku z uwzględnieniem uprawnień dla agentów w portalu Microsoft Foundry.
W tym artykule opisano wymagane pola indeksu i konfigurację dla wyszukiwania agentowego. Żadne z tych wymagań nie są nowe. Możesz użyć istniejącego indeksu spełniającego kryteria, nawet jeśli został utworzony przy użyciu starszej wersji interfejsu API.
Każde indeksowane źródło wiedzy zależy od indeksu bazowego. W zależności od tego, jak skonfigurowano potok przetwarzania, indeks może być jednym z następujących elementów:
Istniejący: Samodzielny indeks, który jest udostępniany przez źródło wiedzy dla indeksu wyszukiwania. Indeks musi spełniać kryteria zawarte w tym artykule.
Generowane: Indeks utworzony automatycznie przez indeksowane źródło wiedzy. Wygenerowane indeksy domyślnie spełniają wszystkie kryteria.
Kryteria dla agentowej rekonstrukcji
Poniższa tabela porządkuje elementy indeksu wpływające na wyszukiwanie agentowe według poziomu wymagań.
| Element indeksu | Requirement | Notatki |
|---|---|---|
searchable i retrievable pola tekstowe |
Wymagane | Służy do wykonywania zapytań i pobierania wyników. |
| Konfiguracja semantyczna | Wymagane | Użyj defaultSemanticConfiguration lub przesłoń konfigurację semantyczną w źródle wiedzy. |
| Pola cytatu | Zalecane | Pola zdefiniowane przez użytkownika, które przypisują odpowiedzi do treści źródłowej, takie jak nazwa dokumentu, numer strony lub identyfikator fragmentu. |
| Pola wektorów i wektoryzator | Zalecane | Umożliwia konwersję tekstu na wektor w czasie wykonywania zapytania. |
| Profil punktacji | Optional | Zwiększa znaczenie dla określonych pól. Ustaw defaultScoringProfile opcję automatycznego stosowania. |
| Analizator | Optional | Określa sposób tokenizacji tekstu, na przykład obsługę białych znaków lub znaków specjalnych. |
| Mapy synonimów | Optional | Rozszerza zapytania o terminologię lub żargon. |
Przykładowa definicja indeksu
Poniższy przykład przedstawia indeks, który sprawdza się w przypadku wyszukiwania agentowego. Spełnia kryteria wymaganych elementów i zawiera pola wektorowe jako najlepsze rozwiązanie.
{
"name": "earth_at_night",
"description": "Contains images and descriptions of our planet in darkness as captured from space by Earth-observing satellites and astronauts on the International Space Station over the past 25 years.",
"fields": [
{
"name": "id", "type": "Edm.String",
"searchable": true, "retrievable": true, "filterable": true, "sortable": true, "facetable": true,
"key": true,
"stored": true,
"synonymMaps": []
},
{
"name": "page_chunk", "type": "Edm.String",
"searchable": true, "retrievable": true, "filterable": false, "sortable": false, "facetable": false,
"analyzer": "en.microsoft",
"stored": true,
"synonymMaps": []
},
{
"name": "page_chunk_vector_text_3_large", "type": "Collection(Edm.Single)",
"searchable": true, "retrievable": false, "filterable": false, "sortable": false, "facetable": false,
"dimensions": 3072,
"vectorSearchProfile": "hnsw_text_3_large",
"stored": false,
"synonymMaps": []
},
{
"name": "page_number", "type": "Edm.Int32",
"searchable": false, "retrievable": true, "filterable": true, "sortable": true, "facetable": true,
"stored": true,
"synonymMaps": []
},
{
"name": "chapter_number", "type": "Edm.Int32",
"searchable": false, "retrievable": true, "filterable": true, "sortable": true, "facetable": true,
"stored": true,
"synonymMaps": []
}
],
"semantic": {
"defaultConfiguration": "semantic_config",
"configurations": [
{
"name": "semantic_config",
"flightingOptIn": false,
"prioritizedFields": {
"prioritizedContentFields": [
{
"fieldName": "page_chunk"
}
],
"prioritizedKeywordsFields": []
}
}
]
},
"vectorSearch": {
"algorithms": [
{
"name": "alg",
"kind": "hnsw",
"hnswParameters": {
"metric": "cosine",
"m": 4,
"efConstruction": 400,
"efSearch": 500
}
}
],
"profiles": [
{
"name": "hnsw_text_3_large",
"algorithm": "alg",
"vectorizer": "azure_openai_text_3_large"
}
],
"vectorizers": [
{
"name": "azure_openai_text_3_large",
"kind": "azureOpenAI",
"azureOpenAIParameters": {
"resourceUri": "https://YOUR-AOAI-RESOURCE.openai.azure.com",
"deploymentId": "text-embedding-3-large",
"modelName": "text-embedding-3-large"
}
}
],
"compressions": []
}
}
Dobrze zaprojektowany indeks dla generatywnej sztucznej inteligencji lub generowania wspomaganego wyszukiwaniem (RAG) składa się z następujących elementów:
Opis, którego można użyć przez LLM lub agenta, aby określić, czy indeks powinien być używany, czy pomijany.
Fragmenty tekstu czytelnego dla człowieka, które można przekazać jako tokeny wejściowe do modułu LLM na potrzeby formułowania odpowiedzi.
Konfiguracja semantycznego klasyfikatora, ponieważ agentowe pobieranie używa klasyfikacji semantycznej poziomu 2 (L2) do zidentyfikowania najbardziej odpowiednich fragmentów danych.
(Opcjonalnie) Odpowiedniki wektorowe czytelnych dla człowieka fragmentów tekstu do uzupełniającego wyszukiwania wektorowego.
Tekst podzielony na fragmenty jest ważny, ponieważ modele LLM przetwarzają i generują tokenizowane ciągi treści w postaci zwykłego tekstu czytelnego dla człowieka. Z tego powodu należy wybrać searchable pola, które udostępniają ciągi zwykłego tekstu i są retrievable w odpowiedzi. W Wyszukiwanie AI platformy Azure można tworzyć tekst podzielony na fragmenty za pomocą wbudowanych rozwiązań lub rozwiązań innych firm.
Wbudowane założenie dotyczące fragmentowanej zawartości polega na tym, że oryginalne dokumenty źródłowe mają duże ilości obszernej treści. Jeśli zawartość źródłowa ma postać danych ustrukturyzowanych, takich jak baza danych produktów, indeks nie powinien stosować podziału na fragmenty, lecz zamiast tego zawierać pola odpowiadające oryginalnemu źródłu danych, takie jak nazwa produktu, kategoria lub opis. Atrybucja elementów searchable i retrievable dotyczy również danych ustrukturyzowanych.
searchable sprawia, że treść jest uwzględniana w zapytaniach, a retrievable dodaje ją do wyników wyszukiwania (dane źródłowe).
Zawartość wektorowa może być przydatna, ponieważ dodaje wyszukiwanie podobieństwa do wyszukiwania informacji. Podczas przetwarzania zapytania, gdy pola wektorów znajdują się w indeksie, silnik wyszukiwania agentów wykonuje zapytanie wektorowe równolegle do zapytania tekstowego. Ponieważ zapytania wektorowe wyszukują podobną zawartość, a nie pasujące wyrazy, zapytanie wektorowe może znaleźć bardzo istotny wynik, którego może przegapić zapytanie tekstowe. Dodawanie wektorów może zwiększyć i poprawić jakość danych źródłowych, ale nie jest bezwzględnie wymagane. Wyszukiwanie AI platformy Azure ma wbudowane podejście do wektoryzacji.
Pola wektorowe są używane tylko do wykonywania zapytań w Wyszukiwanie AI platformy Azure. Nie potrzebujesz wektora w wynikach, ponieważ nie jest czytelny dla człowieka ani języka LLM. Aby zminimalizować wymagania dotyczące miejsca, zalecamy ustawienie wartości retrievable i stored na false. Aby uzyskać więcej informacji, zobacz Optymalizowanie magazynu i przetwarzania wektorów.
Jeśli używasz wektorów, użycie wektoryzatora zdefiniowanego w konfiguracji wyszukiwania wektorów ma kluczowe znaczenie. Określa, czy pole wektorowe jest używane podczas wykonywania zapytania. Wektoryzator koduje podzapytania ciągów do wektorów w czasie wykonywania zapytań w celu wyszukiwania podobieństwa w wektorach. Wektoryzator musi być tym samym modelem osadzania używanym do tworzenia wektorów w indeksie.
Domyślnie wszystkie searchable pola są uwzględniane w wykonywaniu zapytania, a wszystkie retrievable pola są zwracane w wynikach. Możesz wybrać pola, które mają być używane dla każdej akcji w definicji źródła wiedzy indeksu wyszukiwania.
Dodawanie opisu
Pole indeksu description to ciąg zdefiniowany przez użytkownika, którego można użyć, aby zapewnić wskazówki dla serwerów LLMs i Model Context Protocol (MCP) podczas podejmowania decyzji o użyciu określonego indeksu dla zapytania. Ten czytelny dla człowieka tekst jest nieoceniony, gdy system musi uzyskać dostęp do kilku indeksów i podjąć decyzję na podstawie opisu.
Opis indeksu to aktualizacja schematu i można ją dodać bez konieczności ponownego kompilowania całego indeksu.
Długość ciągu wynosi maksymalnie 4000 znaków.
Zawartość musi być czytelna dla człowieka w formacie Unicode. Przypadek użycia powinien określać język do użycia (na przykład angielski lub inny język).
Dodawanie konfiguracji semantycznej
Indeks musi mieć co najmniej jedną konfigurację semantyczną. Konfiguracja semantyczna musi mieć:
- Nazwana konfiguracja.
- Ustawiono
prioritizedContentFieldsco najmniej jedno pole ciągu, które jest zarównosearchable, jak iretrievable.
Istnieją dwa sposoby określania semantycznej konfiguracji według nazwy. Jeśli dla indeksu parametr defaultSemanticConfiguration jest ustawiony na nazwaną konfigurację, podczas pobierania jest ona używana. Alternatywnie można określić konfigurację semantyczną w źródle wiedzy indeksu wyszukiwania.
W ramach konfiguracji prioritizedContentFields jest wymagany. Tytuł i słowa kluczowe są opcjonalne. W przypadku fragmentowanej zawartości możesz nie mieć żadnej z nich. Jeśli jednak dodasz rozpoznawanie jednostek lub wyodrębnianie kluczowych fraz, niektóre słowa kluczowe mogą być skojarzone z każdym fragmentem, które mogą być przydatne w scenariuszach wyszukiwania, na przykład w profilu oceniania.
Poniższy przykład przedstawia konfigurację semantyczną, która sprawdza się w wyszukiwaniu agentowym.
"semantic":{
"defaultConfiguration":"semantic_config",
"configurations":[
{
"name":"semantic_config",
"flightingOptIn":false,
"prioritizedFields":{
"titleField":{
"fieldName":""
},
"prioritizedContentFields":[
{
"fieldName":"page_chunk"
}
],
"prioritizedKeywordsFields":[
{
"fieldName":"Category"
},
{
"fieldName":"Tags"
},
{
"fieldName":"Location"
}
]
}
}
]
}
Uwaga
Odpowiedź zawiera title, terms i content, które odpowiadają priorytetowym polom w tej konfiguracji.
Dodawanie wektoryzatora
Jeśli indeks zawiera pola wektorowe, plan zapytania zawiera te pola, jeśli są searchable i mają przypisanie vectorizer .
Wektoryzator określa model osadzania, który zapewnia konwersje tekstu na wektory w czasie wykonywania zapytania. Musi wskazywać ten sam model osadzania używany do kodowania zawartości wektorowej w indeksie. Możesz użyć dowolnego modelu osadzania obsługiwanego przez Wyszukiwanie AI platformy Azure. Można określić wektoryzatory w polach wektorów za pomocą profilu wektorowego.
Definicja pola wektora w przykładzie indeksu przedstawia atrybuty pola klucza: dimensions, czyli liczbę osadzonych elementów wygenerowanych przez model i vectorSearchProfile.
{
"name": "page_chunk_text_3_large", "type": "Collection(Edm.Single)",
"searchable": true, "retrievable": false, "filterable": false, "sortable": false, "facetable": false,
"dimensions": 3072,
"vectorSearchProfile": "hnsw_text_3_large",
"stored": false,
"synonymMaps": []
}
Profile wektorów to konfiguracje wektoryzatorów, algorytmów i technik kompresji. Każde pole wektorowe może używać tylko jednego profilu, ale indeks może mieć wiele w przypadku, gdy chcesz mieć unikatowe profile dla każdego pola wektora.
Wykonywanie zapytań na wektorach i wywoływanie wektoryzatora zwiększa ogólne opóźnienie żądania, ale jeśli zależy Ci na wyszukiwaniu według podobieństwa, może to być opłacalny kompromis.
Poniższy przykład przedstawia wektoryzator, który działa na potrzeby wyszukiwania agentowego, tak jak występuje w konfiguracji vectorSearch. W definicji wektoryzatora nie ma nic, co należy zmienić, aby pracować z agenticznym pobieraniem.
"vectorSearch": {
"algorithms": [
{
"name": "alg",
"kind": "hnsw",
"hnswParameters": {
"metric": "cosine",
"m": 4,
"efConstruction": 400,
"efSearch": 500
}
}
],
"profiles": [
{
"name": "hnsw_text_3_large",
"algorithm": "alg",
"vectorizer": "azure_openai_text_3_large"
}
],
"vectorizers": [
{
"name": "azure_openai_text_3_large",
"kind": "azureOpenAI",
"azureOpenAIParameters": {
"resourceUri": "https://YOUR-AOAI-RESOURCE.openai.azure.com",
"deploymentId": "text-embedding-3-large",
"modelName": "text-embedding-3-large"
}
}
],
"compressions": []
}
Dodawanie profilu oceniania
Profile punktacji są kryteriami podnoszenia istotności. Są one stosowane do pól niewektorowych (tekst i liczby) i są oceniane podczas wykonywania zapytania, chociaż dokładne zachowanie zależy od wersji interfejsu API używanej do utworzenia indeksu.
Profil punktacji bardziej prawdopodobnie doda wartość do rozwiązania, jeśli indeks jest oparty na danych ustrukturyzowanych. Dane ustrukturyzowane są indeksowane w wielu dyskretnych polach, co oznacza, że profil oceniania może mieć kryteria, które są przeznaczone dla zawartości lub cech określonego pola.
Jeśli utworzysz indeks przy użyciu wersji 2025-05-01-preview lub nowszej, profil ocen zostanie wykonany jako ostatni. Jeśli indeks jest tworzony przy użyciu wcześniejszej wersji API, profile oceniania są analizowane przed semantycznym ponownym ocenianiem. Rzeczywista kolejność wyników sklasyfikowanych semantycznie jest określana przez właściwość rankingOrder w indeksie, która jest ustawiona na boostedRerankerScore (zastosowano profil oceniania) lub rerankerScore (bez profilu oceniania).
Możesz użyć dowolnego profilu oceniania, który ma sens dla indeksu. Poniższy przykład przedstawia profil oceniania, który podnosi ocenę trafności wyniku wyszukiwania, jeśli dopasowanie zostanie znalezione w określonym polu. Pola są ważone z pomocą mnożników wzmacniających. Jeśli na przykład w polu „Kategoria” zostanie znalezione dopasowanie, zwiększony wynik zostanie pomnożony przez 5.
"scoringProfiles": [
{
"name": "boostSearchTerms",
"text": {
"weights": {
"Location": 2,
"Category": 5
}
}
}
]
Dodawanie analizatora
Analizatory mają zastosowanie do pól tekstowych i mogą być analizatorami języków lub analizatorami niestandardowymi, które kontrolują tokenizację w indeksie, takie jak zachowywanie znaków specjalnych lub białych znaków.
Analizatory są definiowane w indeksie wyszukiwania i przypisywane do pól. Przykład kolekcji pól zawiera odwołanie analizatora do fragmentów tekstu. W tym przykładzie analizator domyślny (standardowy Lucene) jest zastępowany analizatorem języka Microsoft dla języka angielskiego.
{
"name": "page_chunk", "type": "Edm.String",
"searchable": true, "retrievable": true, "filterable": false, "sortable": false, "facetable": false,
"analyzer": "en.microsoft",
"stored": true,
"synonymMaps": []
}
Dodawanie mapy synonimów
Mapy synonimów rozszerzają zapytania, dodając synonimy dla nazwanych terminów. Na przykład możesz mieć terminy naukowe lub medyczne dla typowych terminów.
Mapy synonimów są definiowane jako zasób najwyższego poziomu w indeksie wyszukiwania i przypisywane do pól. Przykład kolekcji pól nie zawiera mapy synonimów, ale w poniższym przykładzie pokazano, jak mapa synonimów z pisowniami wariantów nazw krajów/regionów może zostać przypisana do hipotetycznego pola "lokalizacje".
{
"name":"locations",
"type":"Edm.String",
"searchable":true,
"synonymMaps":[ "country-region-synonyms" ]
}
Dodawanie indeksu do źródła wiedzy
Jeśli masz już autonomiczny indeks, który już istnieje i nie jest generowany przez źródło wiedzy, utwórz następujące obiekty:
- Źródło wiedzy dla indeksu wyszukiwania obejmujące zindeksowaną zawartość.
- Baza wiedzy reprezentująca jedno lub więcej źródeł wiedzy oraz inne instrukcje dotyczące wyszukiwania agentowego.