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


Определение проекций в хранилище знаний

Note

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

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

В этой статье вы узнаете синтаксис для каждого типа проекции:

Помните, что проекции определяются в knowledgeStore свойстве набора навыков.

"knowledgeStore" : {
    "storageConnectionString": "DefaultEndpointsProtocol=https;AccountName=<Acct Name>;AccountKey=<Acct Key>;",
    "projections": [
      {
        "tables": [ ],
        "objects": [ ],
        "files": [ ]
      }
    ]
}

Если вам нужно больше фона перед началом работы, просмотрите этот контрольный список , чтобы получить советы и рабочий процесс.

Tip

При разработке проекций включите кэширование обогащения (предварительная версия), чтобы можно было повторно использовать существующие обогащения при редактировании определений проекции. Кэширование обогащения — это предварительная функция, поэтому обязательно используйте REST API предварительной версии в запросе индексатора. Без кэширования простые изменения в проекции приведут к полной повторной обработке обогащенного содержимого. Кэширование обогащений позволяет выполнять итерацию по проекциям без каких-либо расходов на обработку набора навыков.

Requirements

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

Кроме проекций файлов, которые принимают только двоичные изображения, источник должен быть следующим:

  • Допустимый JSON
  • Путь к узлу в дереве обогащения (например, "source": "/document/objectprojection")

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

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

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

Определение проекции таблицы

Проекции данных таблиц рекомендуется использовать в сценариях, которые требуют исследования данных, например, анализа с помощью Power BI или нагрузок, работающих с фреймами данных. Раздел таблиц массива проекций — это список таблиц, которые требуется проецировать.

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

Property Description
tableName Определяет имя новой таблицы, созданной в службе хранилища таблиц Azure.
generatedKeyName Имя столбца для ключа, который однозначно идентифицирует каждую строку. Значение создается системой. Если это свойство не указано, столбец создается автоматически и использует имя таблицы и слово "ключ" в качестве основы для именования.
source Путь к узлу в дереве обогащения. Узел должен быть ссылкой на сложную фигуру, которая определяет, какие столбцы создаются в таблице.

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

Note

Табличные проекции подпадают под ограничения на хранение, установленные службой хранилища Azure. Размер сущности не может превышать 1 МБ, а одно свойство не может превышать 64 КБ. Эти ограничения делают таблицы хорошим решением для хранения большого количества небольших сущностей.

Пример одной таблицы

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

"projections" : [
  {
    "tables": [
      { "tableName": "Hotels", "generatedKeyName": "HotelId", "source": "/document/tableprojection" }
    ]
  }
]

Столбцы являются производными от источника. Следующая фигура данных, содержащая HotelId, HotelName, Category и Description, приведет к созданию этих столбцов в таблице.

{
    "@odata.type": "#Microsoft.Skills.Util.ShaperSkill",
    "name": "#3",
    "description": null,
    "context": "/document",
    "inputs": [
    {
        "name": "HotelId",
        "source": "/document/HotelId"
    },
    {
        "name": "HotelName",
        "source": "/document/HotelName"
    },
    {
        "name": "Category",
        "source": "/document/Category"
    },
    {
        "name": "Description",
        "source": "/document/Description"
    },
    ],
    "outputs": [
    {
        "name": "output",
        "targetName": "tableprojection"
    }
    ]
}

Пример нескольких таблиц (срезов)

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

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

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

Шаблон для нескольких таблиц состоит из следующих элементов:

  • Одна таблица в качестве родительской или основной таблицы
  • Другие таблицы, содержащие срезы обогащенного содержимого

Например, предположим, что навык Shaper выводит элемент "EnrichedShape", содержащий информацию об отеле, а также обогащенное содержимое, включая ключевые фразы, локации и организации. Основная таблица содержит поля, описывающие отель (идентификатор, имя, описание, адрес, категория). Ключевые фразы получат столбец ключевых фраз. Сущности получат столбцы сущностей.

"projections" : [
  {
    "tables": [
    { "tableName": "MainTable", "generatedKeyName": "HotelId", "source": "/document/EnrichedShape" },
    { "tableName": "KeyPhrases", "generatedKeyName": "KeyPhraseId", "source": "/document/EnrichedShape/*/KeyPhrases/*" },
    { "tableName": "Entities", "generatedKeyName": "EntityId", "source": "/document/EnrichedShape/*/Entities/*" }
    ]
  }
]

Отношения именования

Свойства generatedKeyName и referenceKeyName используются, чтобы связать данные между таблицами или даже между типами проекций. Каждая строка дочерней таблицы имеет свойство, указывающее на родительский элемент. Имя столбца или свойства дочернего элемента — referenceKeyName из родительского элемента. referenceKeyName Если этот параметр не указан, служба по умолчанию устанавливает его на generatedKeyName родителя.

Power BI использует эти созданные ключи для обнаружения связей в таблицах. Если столбцу в дочерней таблице необходимо присвоить другое имя, установите свойство referenceKeyName в родительской таблице. Одним из примеров является установка generatedKeyName как идентификатора в таблице tblDocument и referenceKeyName в качестве DocumentID. Это приведет к тому, что столбец в таблицах tblEntities и tblKeyPhrases, содержащий идентификатор документа, получит имя DocumentID.

Определение проекции объекта

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

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

Property Description
storageContainer Определяет имя нового контейнера, созданного в службе хранилища Azure.
generatedKeyName Имя столбца для ключа, который однозначно идентифицирует каждую строку. Значение создается системой. Если это свойство не указано, столбец создается автоматически и использует имя таблицы и слово "ключ" в качестве основы для именования.
source Путь к узлу в дереве обогащения, который служит корнем проекции. Узел обычно является ссылкой на сложные данные, которые определяют структуру блоба.

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

"knowledgeStore": {
  "storageConnectionString": "an Azure storage connection string",
  "projections" : [
    {
      "tables": [ ]
    },
    {
      "objects": [
        {
        "storageContainer": "hotels",
        "source": "/document/objectprojection",
        }
      ]
    },
    {
        "files": [ ]
    }
  ]
}

Это выходные данные, полученные из навыка Формировщика под названием "objectprojection". Каждый объект имеет представление JSON для каждого входного поля.

    {
      "@odata.type": "#Microsoft.Skills.Util.ShaperSkill",
      "name": "#3",
      "description": null,
      "context": "/document",
      "inputs": [
        {
          "name": "HotelId",
          "source": "/document/HotelId"
        },
        {
          "name": "HotelName",
          "source": "/document/HotelName"
        },
        {
          "name": "Category",
          "source": "/document/Category"
        },
        {
          "name": "keyPhrases",
          "source": "/document/HotelId/keyphrases/*"
        },
      ],
      "outputs": [
        {
          "name": "output",
          "targetName": "objectprojection"
        }
      ]
    }

Определение проекции файла

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

Чтобы определить проекцию файла, используйте files массив в свойстве проекций. Проекция файлов имеет три обязательных свойства:

Property Description
storageContainer Определяет имя нового контейнера, созданного в службе хранилища Azure.
generatedKeyName Имя столбца для ключа, который однозначно идентифицирует каждую строку. Значение создается системой. Если это свойство не указано, столбец создается автоматически и использует имя таблицы и слово "ключ" в качестве основы для именования.
source Путь к узлу в дереве обогащения, который является корнем проекции. Для файлов изображений источник всегда /document/normalized_images/*. Проекции файлов действуют только в normalized_images коллекции. Ни индексаторы, ни набор навыков не будут проходить через исходный ненормализованный образ.

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

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

"projections": [
    {
        "tables": [ ],
        "objects": [ ],
        "files": [
            {
                "storageContainer": "myImages",
                "source": "/document/normalized_images/*"
            }
        ]
    }
]

Тестовые проекции

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

  1. Установите свойство storageConnectionString хранилища знаний на допустимую строку подключения учетной записи общего назначения V2.

  2. Обновите набор навыков путем выдачи запроса PUT с определением проекции в тексте набора навыков.

  3. Запустите индексатор, чтобы приступить к выполнению набора навыков.

  4. Отслеживайте выполнение индексатора для проверки прогресса и обнаружения ошибок.

  5. Используйте портал Azure для проверки создания объектов в службе хранения Azure.

  6. Если вы проектируете таблицы, импортируйте их в Power BI для обработки таблиц и визуализации. В большинстве случаев служба Power BI автообнаружает связи между таблицами.

Общие проблемы

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

  • Строковые обогащения не формируются в допустимый JSON. Если строки обогащены, например merged_content обогащена ключевыми фразами, обогащенное свойство представляется как дочерний элемент merged_content в дереве обогащения. Представление по умолчанию не является хорошо сформированным JSON. Во время проекции обязательно преобразуйте обогащение в допустимый объект JSON с именем и значением. Использование функции Shaper или определение встроенных фигур помогает устранить эту проблему.

  • Отсутствие /* в конце исходного пути. Если источником проекции является /document/projectionShape/keyPhrases, то массив ключевых фраз проецируется как одиночный объект или строка. Вместо этого укажите /document/projectionShape/keyPhrases/* для пути к источнику, чтобы получить одну строку или объект для каждой из ключевых фраз.

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

Дальнейшие шаги

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