Поделиться через

Создание индекса для агентного извлечения в Azure AI Search

Замечание

Эта функция сейчас доступна в общедоступной предварительной версии. Этот предварительный просмотр предоставляется без соглашения об уровне обслуживания и не предназначается для производственных рабочих нагрузок. Некоторые функции могут не поддерживаться или их возможности могут быть ограничены. Для получения дополнительной информации см. Дополнительные условия использования для предварительных версий Microsoft Azure.

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

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

  • Созданный индекс, созданный из индексированного источника знаний. Индексированные источники знаний создают копию внешнего источника данных внутри индекса поиска с помощью полного конвейера индексатора (источник данных, набор навыков, индексатор и индекс) для автономного извлечения. Индексированные источники знаний создают копию внешнего источника данных внутри индекса поиска с помощью полного конвейера индексатора (источник данных, набор навыков, индексатор и индекс) для агентного поиска. Несколько источников знаний могут сформировать конвейер индексатора, который приводит к созданию поискового индекса. К ним относятся:

Созданный индекс основан на шаблоне, который соответствует всем критериям для баз знаний и агентного извлечения.

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

Замечание

Следующие источники знаний обращаются к внешним источникам напрямую и не требуют индекса поиска: источник веб-знаний (Bing) и SharePoint (remote).

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

Индекс, используемый в ретривации агента, должен иметь следующие элементы:

  • Строковые поля, обозначенные как searchable и retrievable.
  • Семантическая конфигурация с defaultSemanticConfiguration переопределением семантической конфигурации в источнике знаний.

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

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

При необходимости следующие элементы индекса повышают возможности оптимизации:

  • scoringProfile с defaultScoringProfile, для повышения релевантности
  • synonymMaps для терминологии или жаргона
  • analyzers для правил или шаблонов лингвистики (например, сохранения пробелов или специальных символов)

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

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

{
  "name": "earth_at_night",
  "description": "Contains images an 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",
          "apiKey": "<redacted>",
          "modelName": "text-embedding-3-large"
        }
      }
    ],
    "compressions": []
  }
}

Ключевые моменты:

Хорошо разработанный индекс, используемый для генеративного ИИ или генерации с расширенным извлечением (RAG), имеет следующие компоненты:

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

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

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

  • Опционально версии векторных эквивалентных фрагментов текста, удобочитаемых для человека, для дополнительного векторного поиска.

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

Встроенное предположение для разделённого на части содержимого заключается в том, что исходные документы содержат большое количество подробного текста. Если ваше исходное содержимое представлено в структурированных данных, например, в базе данных товаров, тогда ваш индекс должен отказаться от разделения на блоки и вместо этого включать поля, соответствующие исходному источнику данных (например, название товара, категория, описание и т. д.). Атрибуция 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":{
            "prioritizedFields":{
               "titleField":{
                  "fieldName":""
               },
               "prioritizedContentFields":[
                  {
                     "fieldName":"page_chunk"
                  }
               ],
               "prioritizedKeywordsFields":[
                  {
                     "fieldName":"Category"
                  },
                  {
                     "fieldName":"Tags"
                  },
                  {
                     "fieldName":"Location"
                  }
               ]
            }
         }
      }
   ]
}

Замечание

Ответ предоставляет title, terms и content, которые сопоставляют приоритетные поля в этой конфигурации.

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

Если у вас есть векторные поля в индексе, план запроса включает их, если они searchable, и имеют назначение vectorizer.

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

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

  {
    "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",
        "apiKey": "<redacted>",
        "modelName": "text-embedding-3-large"
      }
    }
  ],
  "compressions": []
}

Добавьте профиль оценки

Профили оценивания — это критерии повышения релевантности. Они применяются к невекторным полям (тексту и числам) и оцениваются во время выполнения запроса, хотя точное поведение зависит от версии API, используемой для создания индекса.

Профиль ранжирования, скорее всего, принесёт пользу вашему решению, если индекс основан на структурированных данных. Структурированные данные индексируются в несколько дискретных полей, что означает, что профиль оценки может иметь критерии, предназначенные для содержимого или характеристик определенного поля.

Если вы создаете индекс с помощью 2025-05-01-preview или более поздней версии, профиль оценки выполняется последним. Если индекс создан с использованием более ранней версии API, профили оценки анализируются перед семантическим перераспределением. Так как агентическое извлечение доступно в более новых API предварительных версий, профиль оценки выполняется последним. Фактический порядок семантически ранжированных результатов определяется свойством ранжированияOrder в индексе, которое либо задано boostedRerankerScore (профиль оценки был применен) либо rerankerScore (нет профиля оценки).

Вы можете использовать любой профиль оценки, который имеет смысл для индекса. Ниже приведен пример, который повышает оценку поиска совпадения, если совпадение найдено в определенном поле. Поля взвешиваются с помощью коэффициентов усиления. Например, если совпадение найдено в поле "Категория", увеличенная оценка умножается на 5.

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

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

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

Анализаторы определяются в индексе поиска и назначаются полям. Пример коллекции полей содержит ссылку анализатора на фрагменты текста. В этом примере анализатор по умолчанию (стандартный Lucene) заменяется анализатором языка Майкрософт для английского языка.

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

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

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

Связанный контент

  • Last updated on