Migração para a entidade de criação V3

A criação na V3 fornece um novo tipo de entidade, a entidade de machine learning, juntamente com a capacidade de adicionar relações a ela e a outras entidades ou recursos do aplicativo. Atualmente, não há nenhuma data até a qual a migração precisa ser concluída.

As entidades podem ser decompostas na V3

As entidades criadas com as APIs de criação V3, por meio das APIs ou com o portal, permitem que você crie um modelo de entidade em camadas com um pai e filhos. O pai é conhecido como a entidade de machine learning, e os filhos são conhecidos como subentidades da entidade com machine learning.

Cada subentidade também é uma entidade de machine learning, mas com as opções de configuração adicionadas dos recursos.

Comparação dessas novas relações com a criação V2

A criação V2 fornecia entidades hierárquicas e compostas juntamente com funções e recursos para realizar essa mesma tarefa. Como as entidades, os recursos e as funções não estavam explicitamente relacionados entre si, era difícil entender como o LUIS subentendia as relações durante a previsão.

Com a V3, a relação é explícita e projetada pelos autores do aplicativo. Isso permite que você, como autor do aplicativo:

  • Veja visualmente como o LUIS está prevendo essas relações, nos exemplos de enunciados
  • Teste essas relações com o painel de teste interativo ou no ponto de extremidade
  • Use essas relações no aplicativo cliente, por meio de um objeto .json bem estruturado, nomeado e aninhado

Planejamento

Ao fazer a migração, considere o seguinte no seu plano de migração:

  • Fazer backup do aplicativo LUIS e realiza a migração em um aplicativo separado. Ter um aplicativo V2 e V3 disponível ao mesmo tempo permite que você valide as alterações necessárias e o impacto nos resultados da previsão.
  • Capturar métricas de sucesso da previsão atual
  • Capturar informações do painel atual como um instantâneo do status do aplicativo
  • Examinar as intenções, as entidades, as listas de frases, os padrões e os testes em lote existentes
  • Os seguintes elementos podem ser migrados sem alteração:
    • Intenções
    • Entidades
      • Entidade de expressão regular
      • Entidade de lista
    • Recursos
      • Lista de frases
  • Os seguintes elementos precisam ser migrados com alterações:
    • Entidades
      • Entidade hierárquica
      • Entidade composta
    • Funções: as funções só podem ser aplicadas a uma entidade de machine learning (pai). Elas não podem ser aplicadas às subentidades
    • Testes em lotes e padrões que usam as entidades hierárquicas e compostas

Ao projetar seu plano de migração, reserve algum tempo para examinar as entidades de machine learning finais, depois que todas as entidades hierárquicas e compostas tiverem sido migradas. Embora uma migração direta funcione, depois que você fizer a alteração e examinar os resultados do teste em lote e o JSON de previsão, o JSON mais unificado poderá levar você a fazer alterações para que as informações finais entregues ao aplicativo do lado do cliente sejam organizadas de maneira diferente. Isso é semelhante à refatoração de código e deve ser tratado com o mesmo processo de revisão que a sua organização tem em vigor.

Se você não tiver testes em lotes em vigor para seu modelo V2 e migrar os testes em lotes para o modelo V3 como parte da migração, não poderá validar como a migração afetará os resultados de previsão do ponto de extremidade.

Migração de entidades V2

Ao começar a migração para o modelo de criação V3, você deve considerar como migrar para a entidade de machine learning, as subentidades e os recursos.

A tabela a seguir indica quais entidades precisam migrar de um design de entidade V2 para V3.

Tipo de entidade de criação V2 Tipo de entidade de criação V3 Exemplo
Entidade composta Entidade com machine learning saiba mais
Entidade hierárquica função da entidade de machine learning saiba mais

Migrar a entidade composta V2

Cada filho da entidade composta V2 deve ser representado com uma subentidade da entidade de machine learning V3. Se o filho composto for uma expressão regular e predefinida ou uma entidade de lista, isso deverá ser aplicado como um recurso obrigatório na subentidade.

Considerações ao planejar a migração de uma entidade composta para uma entidade de machine learning:

  • As entidades filho não podem ser usadas em padrões
  • As entidades filho não são mais compartilhadas
  • As entidades filho precisarão ser rotuladas se forem usadas para não serem de machine learning

Recursos existentes

Qualquer lista de frases usada para impulsionar as palavras na entidade composta deve ser aplicada como um recurso à entidade de machine learning (pai), à entidade de subentidade (filho) ou à intenção (se a lista de frases só se aplicar a uma intenção). Planeje adicionar o recurso à entidade em que ela deve aumentar mais significativamente. Não adicione o recurso genericamente à entidade de machine learning (pai) se ela aumentará mais significativamente a previsão de uma subentidade (filho).

Novos recursos

Na criação V3, adicione uma etapa de planejamento para avaliar as entidades como possíveis recursos para todas as entidades e intenções.

Exemplo de entidade

Esta entidade é apenas um exemplo. Sua migração da entidade pode exigir outras considerações.

Considere uma entidade composta V2 para modificar um order de pizza que usa:

  • datetimeV2 predefinido para a hora de entrega
  • lista de frases para aumentar determinadas palavras, como pizza, torta, borda e cobertura
  • entidade de lista para detectar coberturas como cogumelos, azeitonas e pepperoni.

Um exemplo de enunciado para essa entidade é:

Change the toppings on my pie to mushrooms and delivery it 30 minutes later

A seguinte tabela demonstra a migração:

Modelos V2 Modelos V3
Pai – entidade de componente chamada Order Pai – entidade de machine learning chamada Order
Filho – datetimeV2 predefinido * Migre a entidade predefinida para o novo aplicativo.
* Adicione o recurso obrigatório no pai para o datetimeV2 predefinido.
Filho – entidade de lista para coberturas * Migre a entidade de lista para o novo aplicativo.
* Em seguida, adicione um recurso obrigatório no pai para a entidade de lista.

Migrar a entidade hierárquica V2

Na criação V2, uma entidade hierárquica era fornecida antes das funções existirem no LUIS. As duas cumpriam a mesma finalidade de extrair entidades com base no uso de contexto. Se você tem entidades hierárquicas, considere-as como entidades simples com funções.

Na criação V3:

  • Uma função pode ser aplicada na entidade de machine learning (pai).
  • Uma função não pode ser aplicada a nenhuma subentidade.

Esta entidade é apenas um exemplo. Sua migração da entidade pode exigir outras considerações.

Considere uma entidade hierárquica V2 para modificar um order de pizza:

  • em que cada filho determina uma cobertura original ou a cobertura final

Um exemplo de enunciado para essa entidade é:

Change the topping from mushrooms to olives

A seguinte tabela demonstra a migração:

Modelos V2 Modelos V3
Pai – entidade de componente chamada Order Pai – entidade de machine learning chamada Order
Filho – entidade hierárquica com cobertura de pizza original e final * Adicione a função a Order para cada cobertura.

Substituição da restrição de alteração de API pelo recurso obrigatório

Essa alteração foi feita em maio de 2020 na conferência //Build e só se aplica às APIs de criação v3 quando um aplicativo usa um recurso restrito. Se você estiver migrando da criação v2 para a criação v3 ou não tiver usado recursos restritos v3, pule esta seção.

Funcionalidade: capacidade de exigir uma entidade existente como um recurso para outro modelo e apenas extrair esse modelo se a entidade for detectada. A funcionalidade não foi alterada, mas a API e a terminologia foram.

Terminologia anterior Nova terminologia
constrained feature
constraint
instanceOf
required feature
isRequired

Migração automática

Desde 19 de junho de 2020, você não tem permissão para criar restrições de modo programático usando a API de criação anterior que expunha essa funcionalidade.

Todos os recursos de restrição existentes serão migrados automaticamente para o sinalizador de recurso obrigatório. Nenhuma alteração programática é necessária para a sua API de previsão e nenhuma alteração resultante na qualidade da precisão da previsão.

Alterações do portal do LUIS

A versão prévia do portal do LUIS referenciava essa funcionalidade como uma restrição. O portal atual do LUIS designa essa funcionalidade como um recurso obrigatório.

API de criação anterior

Essa funcionalidade era aplicada na API Criar Entidade Filho de criação de versão prévia como parte da definição de uma entidade, usando a propriedade instanceOf do filho de uma entidade:

{
    "name" : "dayOfWeek",
    "instanceOf": "datetimeV2",
    "children": [
        {
           "name": "dayNumber",
           "instanceOf": "number",
           "children": []
        }
    ]
}

Nova API de criação

Essa funcionalidade agora é aplicada com a API Adicionar relação de recursos de entidade usando as propriedades featureName e isRequired. O valor da propriedade featureName é o nome do modelo.

{
    "featureName": "YOUR-MODEL-NAME-HERE",
    "isRequired" : true
}

Próximas etapas