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


Сопоставление обогащенных выходных данных с полями в индексе поиска в службе "Поиск ИИ Azure"

Схема этапов индексатора с выделенными сопоставлениями полей вывода.

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

Сопоставление выходных полей определяется в индексаторе и содержит следующие элементы:

"outputFieldMappings": [
  {
    "sourceFieldName": "document/path-to-a-node-in-an-enriched-document",
    "targetFieldName": "some-search-field-in-an-index",
    "mappingFunction": null
  }
],

В отличие fieldMappings от определения, которое сопоставляет путь между подробными исходными полями и полями индекса, outputFieldMappings определение сопоставляет обогащения в памяти с полями в индексе поиска.

Необходимые компоненты

  • Индексатор, индекс, источник данных и набор навыков.

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

Когда следует использовать сопоставление выходных полей

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

  • Векторы из навыков внедрения
  • Текст оптического распознавания символов (OCR) из навыков изображения
  • Расположения, организации или люди из навыков распознавания сущностей

Сопоставления полей выходных данных также можно использовать для:

  • Создайте несколько копий созданного содержимого (сопоставления полей вывода "один ко многим").

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

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

Определение сопоставления выходных полей

Сопоставления полей выходных данных добавляются в outputFieldMappings массив в определении индексатора, обычно помещаются после массива fieldMappings . Сопоставление полей вывода состоит из трех частей.

Rest API или Пакет SDK Azure можно использовать для определения сопоставлений полей вывода.

Совет

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

  1. Используйте create Indexer или Create or Update Indexer или эквивалентный метод в пакете SDK Azure. Ниже приведен пример определения индексатора.

    {
       "name": "myindexer",
       "description": null,
       "dataSourceName": "mydatasource",
       "targetIndexName": "myindex",
       "schedule": { },
       "parameters": { },
       "fieldMappings": [],
       "outputFieldMappings": [],
       "disabled": false,
       "encryptionKey": { }
     }
    
  2. outputFieldMappings Заполните массив, чтобы указать сопоставления. Сопоставление полей состоит из трех частей.

    "outputFieldMappings": [
      {
        "sourceFieldName": "/document/path-to-a-node-in-an-enriched-document",
        "targetFieldName": "some-search-field-in-an-index",
        "mappingFunction": null
      }
    ]
    
    Свойство Description
    sourceFieldName Обязательный. Указывает путь к обогащению содержимого. Примером может быть /document/content. Сведения о синтаксисе пути и примерах см . в разделе "Справочные обогащения" в наборе навыков поиска ИИ Azure.
    targetFieldName Необязательно. Указывает поле поиска, которое получает обогащенное содержимое. Целевые поля должны быть простыми полями верхнего уровня или коллекциями. Это не может быть путь к подфилду в сложном типе. Если вы хотите получить определенные узлы в сложной структуре, вы можете расположение отдельных узлов в памяти, а затем отправить выходные данные в коллекцию строк в индексе.
    сопоставлениеFunction Необязательно. Добавляет дополнительную обработку, предоставляемую функциями сопоставления, поддерживаемыми индексаторами. Для узлов обогащения кодирование и декодирование являются наиболее часто используемыми функциями.
  3. Всегда targetFieldName имя поля в индексе поиска.

  4. Это sourceFieldName путь к узлу в обогащенном документе. Это результат навыка. Путь всегда начинается с /document, и если индексируется из большого двоичного объекта, второй элемент пути — /content. Третий элемент — это значение, созданное навыком. Дополнительные сведения и примеры см. в статье "Справочные обогащения" в наборе навыков поиска ИИ Azure.

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

    {
        "name": "myIndexer",
        "dataSourceName": "myDataSource",
        "targetIndexName": "myIndex",
        "skillsetName": "myFirstSkillSet",
        "fieldMappings": [],
        "outputFieldMappings": [
            {
                "sourceFieldName": "/document/content/organizations/*/description",
                "targetFieldName": "descriptions",
                "mappingFunction": {
                    "name": "base64Decode"
                }
            },
            {
                "sourceFieldName": "/document/content/organizations",
                "targetFieldName": "orgNames"
            },
            {
                "sourceFieldName": "/document/content/sentiment",
                "targetFieldName": "sentiment"
            }
        ]
    }
    
  5. Назначьте все функции сопоставления, необходимые для преобразования содержимого поля, прежде чем он хранится в индексе. Для узлов обогащения кодирование и декодирование являются наиболее часто используемыми функциями.

Сопоставление полей вывода "один ко многим"

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

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

"outputFieldMappings": [
    { "sourceFieldName" : "/document/content/text_vector", "targetFieldName" : "vector_hnsw" }, 
    { "sourceFieldName" : "/document/content/text_vector", "targetFieldName" : "vector_eknn" },
    { "sourceFieldName" : "/document/content/text_vector", "targetFieldName" : "vector_narrow" }, 
    { "sourceFieldName" : "/document/content/text_vector", "targetFieldName" : "vector_no_stored" },
    { "sourceFieldName" : "/document/content/text_vector", "targetFieldName" : "vector_scalar" }       
  ]

Путь к исходному полю — это выходные данные навыка. В этом примере выходные данные text_vector. Целевое имя является необязательным свойством. Если вы не предоставляете целевое имя для сопоставления выходных данных, путь будет внедряться или точнее, /document/content/embedding.

{
  "name": "test-vector-size-ss",  
  "description": "Generate embeddings using AOAI",
  "skills": [
    {
      "@odata.type": "#Microsoft.Skills.Text.AzureOpenAIEmbeddingSkill",
      "name": "#1",
      "description": null,
      "context": "/document/content",
      "resourceUri": "https://my-demo-eastus.openai.azure.com",
      "apiKey": null,
      "deploymentId": "text-embedding-ada-002",
      "dimensions": 1536,
      "modelName": "text-embedding-ada-002",
      "inputs": [
        {
          "name": "text",
          "source": "/document/content"
        }
      ],
      "outputs": [
        {
          "name": "embedding",
          "targetName": "text_vector"
        }
      ],
      "authIdentity": null
    }
  ]
}

Неструктурированные сложные структуры в коллекцию строк

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

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

Ниже приведен пример документа в Azure Cosmos DB с вложенным JSON:

{
   "palette":"primary colors",
   "colors":[
      {
         "name":"blue",
         "medium":[
            "acrylic",
            "oil",
            "pastel"
         ]
      },
      {
         "name":"red",
         "medium":[
            "acrylic",
            "pastel",
            "watercolor"
         ]
      },
      {
         "name":"yellow",
         "medium":[
            "acrylic",
            "watercolor"
         ]
      }
   ]
}

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

{
  "name": "my-test-index",
  "defaultScoringProfile": "",
  "fields": [
    { "name": "id", "type": "Edm.String", "searchable": false, "retrievable": true, "key": true},
    { "name": "palette", "type": "Edm.String", "searchable": true, "retrievable": true },
    { "name": "colors", "type": "Collection(Edm.ComplexType)",
      "fields": [
        {
          "name": "name",
          "type": "Edm.String",
          "searchable": true,
          "retrievable": true
        },
        {
          "name": "medium",
          "type": "Collection(Edm.String)",
          "searchable": true,
          "retrievable": true,
        }
      ]
    }
  ]
}

Ниже приведен пример определения индексатора, выполняющего импорт. Обратите внимание, что сопоставления полей отсутствуют и набор навыков.

{
  "name": "my-test-indexer",
  "dataSourceName": "my-test-ds",
  "skillsetName": null,
  "targetIndexName": "my-test-index",

  "fieldMappings": [],
  "outputFieldMappings": []
}

Результатом является следующий пример документа поиска, аналогичный исходному в Azure Cosmos DB.

{
  "value": [
    {
      "@search.score": 1,
      "id": "11bb11bb-cc22-dd33-ee44-55ff55ff55ff",
      "palette": "primary colors",
      "colors": [
        {
          "name": "blue",
          "medium": [
            "acrylic",
            "oil",
            "pastel"
          ]
        },
        {
          "name": "red",
          "medium": [
            "acrylic",
            "pastel",
            "watercolor"
          ]
        },
        {
          "name": "yellow",
          "medium": [
            "acrylic",
            "watercolor"
          ]
        }
      ]
    }
  ]
}

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

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

В следующем примере определения индекса используются коллекции строк для получения неструктурированных выходных данных:

{
  "name": "my-new-flattened-index",
  "defaultScoringProfile": "",
  "fields": [
    { "name": "id", "type": "Edm.String", "searchable": false, "retrievable": true, "key": true },
    { "name": "palette", "type": "Edm.String", "searchable": true, "retrievable": true },
    { "name": "color_names", "type": "Collection(Edm.String)", "searchable": true, "retrievable": true },
    { "name": "color_mediums", "type": "Collection(Edm.String)", "searchable": true, "retrievable": true}
  ]
}

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

{
  "name": "my-test-indexer",
  "dataSourceName": "my-test-ds",
  "skillsetName": null,
  "targetIndexName": "my-new-flattened-index",
  "parameters": {  },
  "fieldMappings": [   ],
  "outputFieldMappings": [
    {
       "sourceFieldName": "/document/colors/*/name",
       "targetFieldName": "color_names"
    },
    {
       "sourceFieldName": "/document/colors/*/medium",
       "targetFieldName": "color_mediums"
    }
  ]
}

Результаты определения приведены ниже. Упрощение структуры теряет контекст в этом случае. Связь между заданным цветом и средой, в которую она доступна, больше не существует. Однако в зависимости от вашего сценария результат, аналогичный следующему примеру, может быть именно тем, что вам нужно.

{
  "value": [
    {
      "@search.score": 1,
      "id": "11bb11bb-cc22-dd33-ee44-55ff55ff55ff",
      "palette": "primary colors",
      "color_names": [
        "blue",
        "red",
        "yellow"
      ],
      "color_mediums": [
        "[\"acrylic\",\"oil\",\"pastel\"]",
        "[\"acrylic\",\"pastel\",\"watercolor\"]",
        "[\"acrylic\",\"watercolor\"]"
      ]
    }
  ]
}