Создание индекса для агентного извлечения в Поиск с использованием ИИ Azure

В этой статье объясняются необходимые поля индекса и конфигурации для агентного поиска. Ни один из этих требований не является новым. Можно использовать существующий индекс, соответствующий условиям, даже если он был создан с более ранней версией API.

Каждый индексированные источники знаний зависят от базового индекса. В зависимости от настройки конвейера индекс может быть одним из следующих способов:

• Существующий: Автономный индекс, доступный через источник знаний поискового индекса. Индекс должен соответствовать критериям в этой статье.

• Создан: Индекс, который автоматически создается индексированным источником знаний. Созданные индексы соответствуют всем критериям по умолчанию.

Критерии для агентного извлечения

В следующей таблице элементы индекса, влияющие на агентный поиск, систематизированы по уровню требований.

Пример определения индекса

В следующем примере показан индекс, который подходит для агентного поиска. Он соответствует критериям наличия обязательных элементов и включает векторные поля в соответствии с рекомендуемой практикой.

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

Грамотно спроектированный индекс для генеративного ИИ или генерации с дополненным поиском (RAG) имеет следующие компоненты:

• Описание, которое может использовать LLM или агент для определения того, следует ли использовать или пропускать индекс.

• Фрагменты текста, понятного человеку, которые можно передать в LLM в качестве входных токенов для формирования ответа.

• Конфигурация семантического ранжировщика, поскольку агентское извлечение использует семантическое ранжирование уровня 2 (L2) для определения наиболее релевантных блоков.

• (Необязательно) Эквивалентные вектору версии фрагментов текста, доступных для чтения человека, для дополнительного векторного поиска.

Текст, разбитый на фрагменты, важен, потому что LLM потребляют и генерируют токенизированные строки удобочитаемого содержимого в формате обычного текста. По этой причине вам нужны searchable поля, которые содержат строки обычного текста и включаются retrievable в ответ. В Поиск с использованием ИИ Azure можно создать фрагментированные тексты с помощью созданных или сторонних решений.

Встроенное предположение для фрагментированного содержимого заключается в том, что исходные документы имеют большое количество многословного содержимого. Если ваш исходный контент представляет собой структурированные данные, например базу данных продуктов, индекс не должен использовать разбиение на фрагменты и вместо этого должен включать поля, соответствующие исходному источнику данных, такие как название продукта, категория или описание. Атрибуция searchable и retrievable также относится к структурированным данным. searchable делает содержимое доступным для запросов, а retrievable добавляет его в результаты поиска (данные для обоснования).

Содержимое вектора может быть полезным, так как оно добавляет поиск подобия к получению информации. Во время запроса, когда векторные поля присутствуют в индексе, агентная система поиска выполняет векторный запрос параллельно с текстовым запросом. Так как векторные запросы ищут аналогичное содержимое, а не совпадающие слова, векторный запрос может найти весьма релевантный результат, который может пропустить текстовый запрос. Добавление векторов может повысить качество данных обоснования, но не является строго обязательным. Поиск с использованием ИИ Azure имеет встроенный метод для векторизации.

Векторные поля используются только для выполнения запросов в Поиск с использованием ИИ Azure. Вам не нужен вектор в результатах, так как он не является человеческим или удобочитаемым LLM. Чтобы свести к минимуму требования к пространству, рекомендуется установить retrievable и stored в значение false. Дополнительные сведения см. в статье "Оптимизация векторного хранилища и обработки".

Если вы используете векторы, векторизатор , определенный в конфигурации векторного поиска, имеет решающее значение. Он определяет, используется ли поле вектора во время выполнения запроса. Векторизатор кодирует строковые подзапросы в векторы во время выполнения запроса для поиска по сходству векторов. Векторизатор должен быть той же моделью внедрения, используемой для создания векторов в индексе.

По умолчанию все searchable поля включаются в выполнение запроса, и все retrievable поля возвращаются в результатах. Вы можете выбрать поля, которые следует использовать для каждого действия в определении источника знаний индекса поиска.

Добавление описания

Поле индекса description — это определяемая пользователем строка, которую можно использовать для предоставления рекомендаций серверам LLMs и ПРОТОКОЛА MCP при принятии решения об использовании определенного индекса для запроса. Этот читаемый человеком текст бесценен, когда система должна получить доступ к нескольким индексам и принять решение на основе описания.

Описание индекса — это обновление схемы, и его можно добавить, не перестроив весь индекс.

• Длина строки составляет 4000 символов.

• Содержимое должно быть удобочитаемым в Юникоде. Вариант использования должен определить, какой язык следует использовать (например, английский или другой язык).

Добавление семантической конфигурации

Индекс должен иметь по крайней мере одну семантику. Семантическая конфигурация должна иметь следующее:

• Именованная конфигурация.
• Задайте 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"
               }
            ]
         }
      }
   ]
}

Добавление векторизатора

Если индекс содержит векторные поля, план запроса включает эти поля, если они имеют searchablevectorizer назначение.

Векторизатор задает модель внедрения, которая обеспечивает преобразование текста в вектор во время запроса. Он должен указывать на ту же модель внедрения, используемую для кодирования векторного содержимого в индексе. Вы можете использовать любую модель внедрения, поддерживаемую Поиск с использованием ИИ Azure. Векторизаторы задаются для векторных полей с помощью профиля вектора.

Определение векторного поля в примере индекса показывает ключевые атрибуты поля: 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. В определении векторизатора ничего не должно быть изменено для работы с агентическим извлечением.

"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, профили ранжирования оцениваются перед семантическим перераспределением. Фактический порядок семантически ранжированных результатов определяется свойством ранжированияOrder в индексе, которое либо задано 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": []
}

Добавление карты синонимов

Карты синонимов расширяют запросы, добавляя синонимы для именованных терминов. Например, у вас могут быть научные или медицинские термины для общих терминов.

Карты синонимов определяются как ресурс верхнего уровня в индексе поиска и назначаются полям. В примере коллекции полей не включена карта синонимов, но в следующем примере показано, как карте синонимов с вариантами написания названий стран и регионов можно назначить гипотетическому полю "locations".

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

Добавьте индекс в источник знаний

Если у вас уже существует автономный индекс, который уже существует и не создается источником знаний, создайте следующие объекты:

• Источник знаний индекса поиска для инкапсулирования индексированного содержимого.
• База знаний, представляющая собой один или несколько источников знаний и другие инструкции для агентного извлечения.

Связанное содержимое

• Агентическое извлечение в Поиск с использованием ИИ Azure
• Agentic RAG: создание подсистемы извлечения причин с помощью Поиск с использованием ИИ Azure (видео YouTube)
• Демонстрационная версия Azure OpenAI с использованием агентного извлечения