建立 Azure AI 搜尋服務中的代理檢索索引

註

Azure AI 搜尋服務可透過 Azure 入口網站、REST API 及 Azure SDK 取得。它同時也是 Foundry IQ 的基礎，這是一個管理式知識層，能將企業內容轉化為可重複使用、權限感知的知識庫，供 Microsoft Foundry 入口網站中的代理使用。

本文說明代理檢索所需的索引欄位與配置。這些要求都不是新的。你可以使用符合條件的現有索引，即使它是用較早的 API 版本建立的。

每個被索引的知識來源都依賴於一個底層索引。根據你如何設定管線，索引可以是以下之一：

現有： 透過搜尋索引知識來源公開的獨立索引。該指數必須符合本文的標準。
生成： 一個由被索引的知識來源自動建立的索引。生成的索引預設符合所有標準。

代理檢索的標準

下表依需求層級組織影響代理檢索的指標元素。

指標元素	需求	Notes
`searchable` 以及 `retrievable` 字串欄位	為必填項目	用於查詢執行與結果檢索。
語意設定	為必填項目	在知識來源中使用 `defaultSemanticConfiguration` 或覆蓋語意配置。
引用欄位	建議使用	使用者自訂欄位，將回應歸因於來源內容，例如文件名稱、頁碼或區塊編號。
向量場與向量化器	建議使用	可在查詢時啟用文字轉向量轉換。
得分概況	Optional	提升特定領域的相關性。設定 `defaultScoringProfile` 為自動套用。
分析器	Optional	控制文字的權杖化方式，例如空白字元或特殊字元的處理。
同義字對應	Optional	擴充查詢，加入術語或行話。

範例指數定義

以下範例展示了一個適用於代理檢索的指標。它符合所需元素的標準，並將向量場納入最佳實務。

{
  "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": []
  }
}

一個設計良好的生成式 AI 或檢索增強生成（RAG）指數包含以下組成部分：

一種描述，LLM 或代理人可以用來判斷是否應該使用或跳過某個索引。
可供人類閱讀的文字區塊，可做為輸入權杖傳遞給 LLM 用於組成答案。
語意排序配置，因為代理檢索使用第二層（L2）語意排序來識別最相關的區塊。
（可選）人類可讀文本塊的向量等效版本，用於輔助向量搜尋。

區塊化文字之所以重要，是因為 LLM 以人類可讀的純文字內容所組成的權杖化字串做為輸入和輸出。因此，您需要能提供純文字字串的 searchable 欄位，且這些欄位在回應中必須是 retrievable。在Azure AI 搜尋服務中，你可以使用內建或第三方解決方案來建立分塊文字。

分塊內容的內建假設是原始原始文件包含大量冗長內容。如果你的來源內容是結構化資料，例如產品資料庫，索引應避免分塊，而是包含對應原始資料來源的欄位，例如產品名稱、類別或描述。 searchable和retrievable的歸因也適用於結構化資料。 searchable 將內容納入查詢範圍，並 retrievable 加入搜尋結果（建立基礎資料）。

向量內容之所以有用，是因為它為資訊檢索加入 了相似性搜尋 。在查詢時，當索引中存在向量欄位時，代理檢索引擎會與文字查詢平行執行向量查詢。由於向量查詢尋找相似內容而非匹配詞彙，向量查詢能找到文字查詢可能忽略的高度相關結果。加入向量可以提升接地數據的品質，但並非絕對必要。 Azure AI 搜尋服務內建向量化方法。

向量欄位僅用於 Azure AI 搜尋服務的查詢執行。結果中不需要向量，因為它對人類或大型語言模型來說都無法讀取。為了減少空間需求，我們建議將retrievable和stored設為 false。欲了解更多資訊，請參閱優化向量儲存與處理。

如果你使用向量，在向量搜尋設定中定義向量化器是關鍵。它決定了你的向量場在查詢執行時是否被使用。向量器在查詢時將字串子查詢編碼成向量，以便對向量進行相似性搜尋。向量化器必須是用來建立索引向量的同一嵌入模型。

預設情況下，所有 searchable 欄位都會包含在查詢執行中，所有 retrievable 欄位也會在結果中回傳。你可以在搜尋索引知識來源定義中選擇每個動作要用哪些欄位。

新增描述

索引 description 欄位是使用者定義的字串，可以用來在決定使用特定索引來進行查詢時，為大型語言模型（LLM）和模型上下文協定（MCP）伺服器提供指引。當系統需要存取多個索引並根據描述做出決策時，這段可讀的文字非常寶貴。

索引描述是結構更新，你可以新增它而不用重建整個索引。

字串長度最多為 4,000 字元。
內容必須是人類可讀的，且必須以 Unicode 格式呈現。你的使用情境應該決定要用哪種語言（例如英文或其他語言）。

新增語意配置

索引必須至少有一個語意設定。語意配置必須具備：

具名設定。
至少將 prioritizedContentFields 設定為一個字串欄位，且該欄位必須同時為 searchable 和 retrievable。

有兩種方式可以以名稱指定語意配置。如果索引設定 defaultSemanticConfiguration 為命名配置，檢索會使用該配置。或者，你也可以在搜尋索引知識來源中指定語意配置。

在配置中， prioritizedContentFields 是必要的。標題與關鍵字為可選。對於分塊的內容，您可能兩者都沒有。不過，如果你加入實體辨識或關鍵片語擷取，每個區塊可能會有一些關鍵字，這些關鍵字在搜尋情境中可能非常有用，或許在評分設定檔中使用。

以下範例展示了一種適用於代理檢索的語意配置。

"semantic":{
   "defaultConfiguration":"semantic_config",
   "configurations":[
      {
         "name":"semantic_config",
         "flightingOptIn":false,
         "prioritizedFields":{
            "titleField":{
               "fieldName":""
            },
            "prioritizedContentFields":[
               {
                  "fieldName":"page_chunk"
               }
            ],
            "prioritizedKeywordsFields":[
               {
                  "fieldName":"Category"
               },
               {
                  "fieldName":"Tags"
               },
               {
                  "fieldName":"Location"
               }
            ]
         }
      }
   ]
}

註

回應會提供 title、 terms和 content，這些對應到此配置中的優先欄位。

加裝向量器

如果你的索引包含向量欄位，查詢計畫會包含這些欄位（如果是 searchable 且有 vectorizer 賦值）。

向量器指定一個嵌入模型，可在查詢時提供文字轉向量的轉換。它必須指向用來編碼索引向量內容的相同嵌入模型。你可以使用任何 Azure AI 搜尋服務支援的嵌入模型。你可以透過 向量剖面來指定向量場上的向量化器。

索引範例中的 向量場定義 顯示關鍵欄位屬性： dimensions，即模型產生的嵌入數量，以及 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": []
  }

向量剖面是向量器、演算法及壓縮技術的配置。每個向量場只能使用一個剖面，但你的索引可以擁有多個剖面，以便於你需要為每個向量場設定獨特剖面時使用。

查詢向量並呼叫向量器會增加整體請求的延遲，但如果你想要相似度搜尋，這樣做可能值得。

以下範例展示了一種在向量搜尋配置中用於代理檢索的向量化器。向量器定義中沒有需要修改才能支援代理檢索的部分。

"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": []
}

新增評分檔案

評分設定檔是相關性提升的準則。它們會套用在非向量欄位（文字和數字）上，並在查詢執行時評估，雖然具體行為取決於用於建立索引的 API 版本。

如果你的指數是基於結構化資料，評分輪廓更有可能為你的解決方案增添價值。結構化資料被索引為多個離散欄位，這意味著你的評分檔案可以針對特定欄位的內容或特徵設置標準。

如果您使用 2025-05-01-preview 或更新版本來建立索引，則評分設定檔會最後執行。若索引是使用較早的 API 版本建立，評分設定檔會在語意重新排序前進行評估。語意排序結果的實際順序由索引中的 rankingOrder 屬性決定，該屬性可設定為 boostedRerankerScore （已套用評分輪廓）或 rerankerScore （無評分輪廓）。

您可以使用任何對索引有意義的評分設定檔。以下範例顯示一個評分設定檔：如果相符結果出現在特定欄位中，則會提高其搜尋分數。欄位會透過提高倍數來進行加權。例如，若在「類別」欄位找到比賽，提升後的分數會乘以5。

"scoringProfiles": [
    {
      "name": "boostSearchTerms",
      "text": {
        "weights": {
          "Location": 2,
          "Category": 5
        }
      }
    }
]

新增分析儀

分析器適用於文字欄位，可以是語言分析器，也可以是自訂分析器，控制索引中的分詞，例如保留特殊字元或留白。

分析器是在搜尋索引中定義並指派到欄位。欄位集合範例包含文本區塊的分析器引用。在此範例中，預設的分析器（標準 Lucene）被 Microsoft 語言分析器取代，適用於英語。

{
  "name": "page_chunk", "type": "Edm.String",
  "searchable": true, "retrievable": true, "filterable": false, "sortable": false, "facetable": false,
  "analyzer": "en.microsoft",
  "stored": true,
  "synonymMaps": []
}

新增同義映射

同義映射透過新增命名術語的同義詞來擴展查詢範圍。例如，你可能會用科學或醫學術語來形容常用詞彙。

同義映射被定義為搜尋索引上的頂層資源，並指派到欄位。欄位收集範例中沒有包含同義詞地圖，但以下範例展示了如何將帶有國家/地區名稱不同拼寫的同義詞地圖，分配給假設的「地點」欄位。

{
    "name":"locations",
    "type":"Edm.String",
    "searchable":true,
    "synonymMaps":[ "country-region-synonyms" ]
}

將你的索引加入知識庫

如果你已經有一個獨立索引，且非由知識來源產生，請建立以下物件：

一個搜尋索引知識來源，用來封裝你被索引的內容。
一個代表一個或多個知識來源及其他指示的知識庫，用於代理檢索。

意見反應

此頁面對您有幫助嗎？

Last updated on 2026-09-17