Como montar uma frase curta de treino que realmente funciona
O que é uma frase curta de treino e por que a maioria das pessoas erra
Uma frase curta de treino é uma string de texto simples associada a um intent específico dentro de um sistema de NLU. Não é mágica, é apenas dados. O erro mais comum que vejo é pessoa criar cinco variações idênticas e chamar de "treino suficiente". Um modelo que vê apenas dez frases parecidas com "qual o horário?" não generaliza nada. Ele decora. Quando alguém pergunta "vocês fecham mais cedo ?", ele falha porque a variação lexical foi além do que ele viu. Eu trabalho com isso há anos e já vi projetos inteiros queimados porque o time de produto achava que frases curtas de treino era coisa de cinco minutos. Não é. A diferença entre um bot que funciona e um que não funciona está em quantas variações você consegue gerar antes de treinar e testar.Workflow prático
Comece listando os intents do seu domínio. Para cada intent, escreva a forma canônica e depois expanda. Use três categorias de variação: substituição lexical, reordenação e paráfrase estrutural. Para o intent de verificação de horário, por exemplo:"qual o horário de funcionamento" — canônica "vocês abrem agora" — variação lexical + coloquial
👉 Clique no botão abaixo para saber mais sobre o assunto!
"a partir de que horas vocês atendem" — reordenação + expansão "o atendimento começa às quantas" — reformulação total
O número ideal por intent varia. Em sistemas de atendimento ao cliente, eu nunca entro em produção com menos de 40 frases por intent. Em domínios técnicos, como telemedicina ou fintech, onde a ambiguidade é maior, uso entre 60 e 100.Um problema real que eu enfrentei e a solução
Num projeto de triagem médica, tínhamos um intent chamado "marcar consulta" e outro "cancelar consulta". O modelo estava acertando 97% nos testes internos. Nas primeiras duas semanas em produção, a acurácia despencou para 61%. A causa? Usuários do interior falando "quero destravar a consulta" quando na verdade queriam remarcar. O termo "destravar" era completamente novo para o modelo. A solução foi duplamente chatamente prática: primeiro, fiz um dump de todas as transcrições reais dos primeiros 30 dias, extrai as utterances que o modelo classificou errado, agrupei por padrão e criei novos exemplos para o intent "remarcar" baseados na linguagem real, não na linguagem que eu achava que os usuários usariam. Segundo, implementei um pipeline de curadoria automática que flagrautterances com confiança entre 0.4 e 0.6 para revisão humana antes de serem adicionadas ao treino. Isso reduziu o drift de classificação em cerca de 73% no mês seguinte. O trabalho extra foi absurdo. Mas foi o que separou o projeto de fracassar ou sobreviver.Como estruturar os dados para exportar
O formato mais comum é JSON, mas o conteúdo importa mais que a extensão. Cada intent deve ter uma lista de examples e, quando possível, uma lista de negative examples — frases que não pertencem àquele intent. Sem negative examples, o modelo tende a classificar tudo como o intent mais frequente. Um exemplo real de estrutura:{ "intent": "ver_horario", "examples": [ "qual o horario", "quando abrem", "horario de funcionamento", "voces abrem as quantas", "a que horas abre", "funcionamento agora", "horario atual", "ate que horas voces ficam abertos", "fechamento hoje", "hora de inicio do atendimento" ], "negative_examples": [ "qual o preço", "quero marcar", "onde fica a unidade", "como chego la" ] }
Note que incluí "fechamento hoje" e "ate que horas voces ficam abertos" como positivas mesmo sendo semanticamente próximas mas syntaticamente diferentes. O modelo precisa ver a variação, não apenas o sinônimo perfeito.