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


Использование приложений рабочих процессов для распознавания бесед или оркестрации

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

Общие сведения о оркестрации

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

Оркестрация состоит из двух этапов:

  1. Прогнозирование вызываемого дочернего проекта.
  2. Маршрутизация речевых фрагментов в целевое дочернее приложение и возврат ответа дочернего приложения.

Преимущества оркестрации

  • Очистить декомпозицию и ускорить разработку:

    • Если общая схема имеет значительное количество доменов, подход оркестрации может помочь разложить приложение на несколько дочерних приложений (каждый обслуживающий определенный домен). Например, в автомобильном приложении может быть домен навигации или домен мультимедиа.
    • Параллельное разработка каждого приложения домена упрощается. Люди и команды с определенным опытом в области домена могут работать над отдельными приложениями совместно и параллельно.
    • Так как каждое доменное приложение меньше, цикл разработки становится быстрее. Приложения домена меньшего размера занимают гораздо меньше времени для обучения, чем одно большое приложение.
  • Более гибкие пороговые значения оценки достоверности:

    • Так как отдельные дочерние приложения служат каждому домену, легко задать отдельные пороговые значения для разных дочерних приложений.
  • Улучшения качества ИИ при необходимости:

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

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

Недостатки оркестрации

  • Избыточные сущности в дочерних приложениях:

    • Если требуется, чтобы определенная предварительно созданная сущность возвращалась во всех речевых фрагментах независимо от домена, например Quantity.Number или Geography.Locationнет способа добавления сущности в приложение оркестрации (это модель только для намерений). Необходимо добавить его во все отдельные дочерние приложения.
  • Efficiency:

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

    • Обучение приложения оркестрации не позволяет детализировать данные между тестами и наборами обучения. Например, нельзя обучить разделение 90-10 для дочернего приложения A, а затем обучить разделение 80-20 для дочернего приложения B. Это ограничение может быть незначительным, но стоит помнить.

Общие сведения о неструктурированных архитектурах

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

Преимущества плоской архитектуры

  • Простота.

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

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

Недостатки плоской архитектуры

  • Неуправляемые для больших приложений:

    • Для больших приложений (например, более 50 намерений или сущностей) может стать трудно отслеживать изменяющиеся схемы и наборы данных. Эта трудность очевидна в случаях, когда приложение должно обслуживать несколько доменов. Например, в автомобильном приложении может быть домен навигации или домен мультимедиа.
  • Ограниченный контроль над совпадением сущностей:

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