Principal Tags Como funciona o sistema de Tags da ClaudIA (Tagger)

Como funciona o sistema de Tags da ClaudIA (Tagger)

Última atualização em Jul 20, 2026

Quando usar

  • Você quer entender como a ClaudIA escolhe a tag final de cada ticket
  • Você está vendo muitos tickets com NO_TAG e precisa diagnosticar o motivo
  • Você está modelando conteúdos e quer garantir que sejam taggeados corretamente

Pré-requisitos

  • Acesso ao Hub do projeto
  • Conhecimento básico dos tipos de conteúdo (N1, N2, Interactive)

Sobre este artigo

O Tagger é o mecanismo responsável pela seleção e atribuição da tag final de cada ticket. Este artigo explica como ele decide qual tag aplicar e por que tickets podem ficar com NO_TAG.


Como o Tagger decide a tag

O Tagger usa como base um mecanismo avançado de detecção dos conteúdos utilizados pela ClaudIA durante a conversa. A partir dessa detecção, segue os passos:

Etapa 1 — Ordenar conteúdos por relevância

A IA avalia todos os conteúdos usados e identifica qual representa o principal assunto da conversa.

Etapa 2 — Aplicar a tag por hierarquia

O Tagger escolhe a tag seguindo uma ordem de prioridade. Ele aplica a primeira opção disponível, de cima para baixo:

  1. Conteúdo N2 (escalação) → se o ticket usou um conteúdo N2, a tag dele tem prioridade máxima

  2. Tag de agente especialista → se a conversa foi atendida pelos Agentes Especialistas e um agente especialista definiu uma tag, ela é usada em seguida

  3. Fluxo Controlado (conteúdo interativo) → se a conversa acionou um Fluxo Controlado, usa a tag desse conteúdo

  4. Conteúdo N1 mais relevante → na ausência dos anteriores, aplica a tag do conteúdo N1 com maior relevância

  5. Tag padrão → se nada acima se aplica, o ticket recebe a tag padrão do projeto (que pode ser NO_TAG ou outra tag configurada)

A ordem é sempre essa: N2 → agente especialista → Fluxo Controlado → N1 → tag padrão. O Tagger para na primeira opção que encontrar.

🎥 Vídeo explicativo detalhado


Troubleshooting: por que um ticket recebe NO_TAG?

A ClaudIA sempre tenta atribuir uma tag. O NO_TAG aparece quando ela não consegue identificar um conteúdo claro para classificar o ticket. Isso acontece em dois cenários:

1. Nenhum conteúdo foi usado na resposta

Comum em tickets curtos ou com interações incompletas:

  • Cliente enviou apenas saudação ou mensagem genérica

  • ClaudIA respondeu sem usar conteúdo estruturado da base

  • Conversa foi abandonada antes de se desenvolver

Nesse caso, o resultado depende da configuração do projeto:

  • Com tag padrão configurada → o ticket recebe a tag padrão (pode ser NO_TAG ou outra tag definida pelo projeto)

  • Sem tag padrão configurada → a ClaudIA ainda tenta adivinhar: ela resume a conversa e busca o conteúdo mais parecido na base. Só fica NO_TAG se não encontrar nada relevante

2. O conteúdo usado foi filtrado pela configuração

Mesmo quando há conteúdo, o ticket pode ficar NO_TAG se a configuração do projeto filtrar os tipos de conteúdo considerados. Exemplo: um projeto configurado para considerar apenas tags de conteúdo N2, mas a conversa usou só conteúdo N1 → como não há N2, o ticket cai na tag padrão.

A tag padrão é configurável por projeto. Por padrão ela é NO_TAG, mas o projeto pode definir outra tag para esses casos.

Funcionalidades que costumam gerar NO_TAG

Estes são exemplos comuns de respostas sem conteúdo estruturado — se vão virar NO_TAG ou não depende da configuração explicada acima:

  • Clarification / Enlightenment — pergunta vaga; ClaudIA pede esclarecimento sem usar conteúdos recuperados

  • Multiprompt — ClaudIA responde com prompts customizados que não usam conteúdo

  • Out of Office N1 — uma seção N2 ou Fluxo Controlado geraria transferência fora do horário, mas com encerramento N1 ativo, o Tagger pode desconsiderar a seção e aplicar NO_TAG


Observações