Um modelo de tarefas do operador personalizado.

Para criar um trabalho de rotulagem personalizado, você precisa atualizar o modelo de tarefa do operador, mapear os dados de entrada do seu arquivo de manifesto para as variáveis usadas no modelo e mapear os dados de saída para o Amazon S3. Para saber mais sobre os atributos avançados que usam a automação do Liquid, consulte Adicionar automação com o Liquid.

As seções a seguir descrevem as etapas necessárias.

Modelo de tarefa do operador

Um modelo de tarefa do operador é um arquivo usado pelo Ground Truth para personalizar a interface de usuário (UI) do operador. Você pode criar um modelo de tarefa de trabalho usando HTML, CSS JavaScript, linguagem de modelo Liquid e elementos HTML do Crowd. O Liquid é usado para automatizar o modelo. Os elementos HTML do Crow são usados para incluir ferramentas comuns de anotação e fornecer a lógica para enviar para o Ground Truth.

Use os tópicos a seguir para saber como criar um modelo de tarefa do operador. Você pode ver um repositório de exemplos de modelos de tarefas para trabalhadores da Ground Truth em GitHub.

Usando o modelo básico de tarefas do trabalhador no console de SageMaker IA

Você pode usar um editor de modelos no console Ground Truth para começar a criar um modelo. Esse editor inclui vários modelos básicos predefinidos. Ele é compatível com preenchimento automático para o código HTML e Elementos HTML do Crowd.

Use a seção a seguir para aprender a visualizar localmente um modelo desenvolvido no console.

Visualizando os modelos de tarefas de trabalho localmente

Você deve usar o console para testar como o modelo processa os dados recebidos. Para testar a aparência e funcionamento do HTML e dos elementos personalizados do modelo, você pode usar seu navegador.

O exemplo de trecho de código a seguir carrega o código necessário para renderizar os elementos HTML personalizados. Use isso caso deseje desenvolver a aparência do seu modelo no editor de sua escolha, e não no console.

<script src="https://assets.crowd.aws/crowd-html-elements.js"></script>

Como criar uma amostra simples de tarefa em HTML

Agora que você tem o modelo de tarefa base do operador, você pode usar este tópico para criar um modelo de tarefa simples baseado em HTML.

Veja a seguir um exemplo de entrada de um arquivo de manifesto de entrada.

{
  "source": "This train is really late.",
  "labels": [ "angry" , "sad", "happy" , "inconclusive" ],
  "header": "What emotion is the speaker feeling?"
}

No modelo de tarefa HTML, precisamos mapear as variáveis do arquivo de manifesto de entrada para o modelo. A variável do exemplo de manifesto de entrada seria mapeada usando a seguinte sintaxe task.input.source, task.input.labels e task.input.header:

Veja a seguir uma amostra simples de modelo de tarefa de trabalho em HTML para análise de tweets. Todas as tarefas começam e terminam com os elementos <crowd-form> </crowd-form>. Como os elementos HTML padrão de <form>, todo o seu código de formulário deve estar entre eles. O Ground Truth gera as tarefas dos operadores diretamente do contexto especificado no modelo, a menos que você implemente uma pré-anotação Lambda. O objeto taskInput retornado pelo Ground Truth ou Lambda de pré-anotação é o objeto task.input nos modelos.

Para uma tarefa simples de análise de tweets, use o elemento <crowd-classifier>. Ela requer os seguintes atributos:

O elemento <crowd-classifier> requer pelo menos os três elementos filhos a seguir.

Uma versão simples dessa ferramenta ficaria assim. A variável {{ task.input.source }} é o que especifica os dados de origem do seu arquivo de manifesto de entrada. A {{ task.input.labels | to_json }} é um exemplo de um filtro variável para transformar a matriz em uma representação JSON. O atributo categories deve ser JSON.

<script src="https://assets.crowd.aws/crowd-html-elements.js"></script>
<crowd-form>
  <crowd-classifier
    name="tweetFeeling"
    categories="='{{ task.input.labels | to_json }}'"
    header="{{ task.input.header }}'"
  >
     <classification-target>
       {{ task.input.source }}
     </classification-target>

    <full-instructions header="Sentiment Analysis Instructions">
      Try to determine the sentiment the author
      of the tweet is trying to express.
      If none seem to match, choose "cannot determine."
    </full-instructions>

    <short-instructions>
      Pick the term that best describes the sentiment of the tweet.
    </short-instructions>

  </crowd-classifier>
</crowd-form>

Você pode copiar e colar o código no editor no fluxo de trabalho de criação de tarefas de rotulagem do Ground Truth para visualizar a ferramenta ou experimentar uma demonstração desse código no CodePen.

Dados de entrada, ativos externos e o modelo de tarefa

As seções a seguir descrevem o uso de ativos externos, os requisitos de formato de dados de entrada e quando considerar o uso de funções do Lambda de pré-anotação.

Requisitos de formato de dados de entrada

Ao criar um arquivo de manifesto de entrada para usar em seu trabalho de rotulagem personalizado do Ground Truth, você deve armazenar os dados no Amazon S3. Os arquivos de manifesto de entrada também devem ser salvos no mesmo local Região da AWS em que seu trabalho de rotulagem personalizado do Ground Truth deve ser executado. Além disso, ele pode ser armazenado em qualquer bucket do Amazon S3 que seja acessível ao perfil de serviço IAM que você usa para executar o trabalho de rotulagem personalizado no Ground Truth.

Os arquivos de manifesto de entrada devem usar o formato de linhas JSON ou JSON delimitado por nova linha. Cada linha é delimitada por uma quebra de linha padrão, \n ou \r\n. Cada linha também deve ser um objeto JSON válido.

Cada objeto JSON no arquivo manifesto deve conter uma das seguintes chaves: source-ref ou source. O valor das chaves é interpretado da seguinte forma:

Para saber mais sobre como formatar seus arquivos de manifesto de entrada, consulte Arquivos de manifesto de entrada.

Sua função do Lambda de pré-anotação

Opcionalmente, você pode especificar uma função do Lambda de pré-anotação para gerenciar como os dados do arquivo de manifesto de entrada são tratados antes da rotulagem. Se você especificou o par de valores-chave isHumanAnnotationRequired, deverá usar uma função do Lambda de pré-anotação. Quando a Ground Truth envia à função do Lambda de pré-anotação uma solicitação formatada em JSON, ela usa os seguintes esquemas:

{
  "version": "2018-10-16",
  "labelingJobArn": arn:aws:lambda:us-west-2:555555555555:function:my-function
  "dataObject" : {
    "source-ref": s3://input-data-bucket/data-object-file-name
  }
}

{
      "version": "2018-10-16",
      "labelingJobArn" : arn:aws:lambda:us-west-2:555555555555:function:my-function
      "dataObject" : {
        "source": Sue purchased 10 shares of the stock on April 10th, 2020
      }
    }

A seguir está a resposta esperada da função do Lambda quando isHumanAnnotationRequired é usado.

{
  "taskInput": {
    "source": "This train is really late.",
    "labels": [ "angry" , "sad" , "happy" , "inconclusive" ],
    "header": "What emotion is the speaker feeling?"
  },
  "isHumanAnnotationRequired": False
}

Uso de ativos externos

Os modelos personalizados SageMaker do Amazon Ground Truth permitem que scripts externos e folhas de estilo sejam incorporados. Por exemplo, o bloco de código a seguir demonstra como você adicionaria uma folha de estilos localizada em https://www.example.com/my-enhancement-styles.css ao seu modelo.

<script src="https://www.example.com/my-enhancment-script.js"></script>
<link rel="stylesheet" type="text/css" href="https://www.example.com/my-enhancement-styles.css">

Se encontrar erros, verifique se o servidor de origem está enviando o tipo MIME e os cabeçalhos de codificação corretos com os ativos.

Por exemplo, os tipos MIME e de codificação para scripts remotos são: application/javascript;CHARSET=UTF-8.

O MIME e o tipo de codificação das folhas de estilo remotas são: text/css;CHARSET=UTF-8.

Dados de saída e seu modelo de tarefa

As seções a seguir descrevem os dados de saída de um trabalho de rotulagem personalizado e quando considerar o uso de uma função do Lambda pós-anotação.

Dados de saída

Quando seu trabalho de rotulagem personalizado é concluído, os dados são salvos no bucket do Amazon S3 especificado quando o trabalho de rotulagem foi criado. Os dados são salvos em um arquivo output.manifest.

Neste exemplo, o objeto JSON é formatado para legibilidade, no arquivo de saída real, e o objeto JSON está em uma única linha.

{
  "source" : "This train is really late.",
  "labelAttributeName" : {},
  "labelAttributeName-metadata": { # These key values pairs are added by Ground Truth
    "job_name": "test-labeling-job",
    "type": "groundTruth/custom",
    "human-annotated": "yes",
    "creation_date": "2021-03-08T23:06:49.111000",
    "worker-response-ref": "s3://amzn-s3-demo-bucket/test-labeling-job/annotations/worker-response/iteration-1/0/2021-03-08_23:06:49.json"
  }
}

Usando uma pós-anotação Lambda para consolidar os resultados de seus operadores

Por padrão, o Ground Truth salva as respostas dos operadores não processadas no Amazon S3. Para ter um controle mais refinado sobre como as respostas são tratadas, você pode especificar uma função do Lambda pós-anotação. Por exemplo, uma função do Lambda pós-anotação pode ser usada para consolidar a anotação se vários operadores tiverem rotulado o mesmo objeto de dados. Para saber mais sobre como criar funções do Lambda de pós-anotação, consulte Lambda de pós-anotação.

Se você quiser usar uma função do Lambda de pós-anotação, ela deverá ser especificada como parte da AnnotationConsolidationConfig em uma solicitação CreateLabelingJob.

Para saber mais sobre como a consolidação de anotações funciona, consulte Consolidação de anotações.