Crie um conjunto de dados para treinamento de IA a partir dos documentos que você já tem

Seu histórico de suporte pode ajudar a treinar um modelo que classifique solicitações, mas as informações estão espalhadas entre chamados e respostas. O Beeuni pode reunir as conversas que você escolher, transformá-las em exemplos rotulados e verificar campos ausentes e duplicatas. Você revisa os rótulos duvidosos e recebe um conjunto de dados JSONL, com um registro JSON por linha e links para os chamados originais.

Defina o comportamento antes do formato do arquivo

Imagine que você quer que um modelo classifique as solicitações recebidas. Cada exemplo precisa incluir uma solicitação e uma categoria aprovada. Se quiser que as respostas se baseiem em um manual, o exemplo precisa incluir uma pergunta, um texto de apoio e uma resposta verificada. Transformar cada parágrafo em uma pergunta não garante que as respostas estejam corretas ou sejam úteis.

Conecte o serviço que contém o material ou dê ao agente acesso ao repositório de documentação. Comece com uma coleção identificada por nome ou com um intervalo de datas. Para a documentação pública, especifique o site e as seções que devem ser incluídas. Antes de revisar os primeiros exemplos, peça ao agente que liste as fontes coletadas e as páginas que não conseguiu ler.

Comece resolvendo um pequeno problema de rotulagem

Considere uma equipe de suporte fictícia que está preparando um classificador de solicitações. Ela quer quatro rótulos: cobrança, acesso à conta, ajuda com o produto e precisa de revisão. Por meio de um conector autorizado ao suporte, o agente lê tickets encerrados de um intervalo de datas acordado. Colete apenas os campos necessários para a rotulagem e o rastreamento da fonte, deixando de fora dados de contato e anexos sem relação com o caso. A fila à qual cada ticket foi encaminhado não indica necessariamente o rótulo correto: um atendente de cobrança pode ter respondido a uma pergunta sobre acesso encaminhada por engano.

Salve uma cópia das fontes no computador, com as referências dos tickets, a regra de seleção e o horário da coleta. Execute a conversão com base nessa cópia para que a edição de um ticket no meio da revisão não altere os exemplos sem que ninguém perceba. O agente pode escrever e executar os scripts de extração e validação e, em seguida, entregar o conjunto de dados, os scripts e o relatório de revisão juntos.

Comece com solicitações que incluam mensagens curtas, conversas longas e mais de um assunto. Decida o que será incluído na entrada no momento da previsão. Se o modelo verá apenas a primeira mensagem do cliente, não inclua a resolução final na entrada de treinamento. Caso contrário, ele aprenderá com informações que seu aplicativo não terá quando uma nova solicitação chegar.

Escreva a regra para a terceira linha antes de pedir ao agente que rotule o restante. Você pode direcionar os casos com base no impedimento imediato ou encaminhar para revisão qualquer solicitação com intenções conflitantes. As duas políticas podem ser razoáveis. Misturá-las entre os anotadores gera exemplos inconsistentes para o modelo aprender.

Use as divergências para melhorar o guia de rotulagem

Peça a dois revisores que rotulem, de forma independente, o mesmo pequeno lote. Guarde os rótulos originais e a decisão final. Quando houver divergência, registre o motivo: falta de contexto, categorias sobrepostas ou erro de rotulagem. Um agente pode reunir esses casos em um arquivo de revisão, mas a pessoa responsável pelo fluxo de trabalho deve definir a política de direcionamento.

Se uma decisão alterar o guia de rotulagem, revise os exemplos anteriores afetados pela regra. No classificador fictício, escolher o “impedimento imediato” coloca a solicitação de cancelamento na categoria de acesso à conta. Outras mensagens que combinam dificuldades para entrar com questões de pagamento também devem ser tratadas da mesma forma. Corrigir apenas a linha contestada mantém a inconsistência nos exemplos mais antigos.

Mantenha as mensagens de origem separadas das variantes sintéticas. Reescrever uma solicitação dez vezes pode ajudar a contemplar diferentes formas de expressão, mas não acrescenta dez situações independentes. Se gerar variantes, registre o exemplo de origem e revise o significado delas. Uma pequena mudança, como trocar “fui cobrado” por “serei cobrado”, pode alterar o rótulo correto.

Mantenha um registro de revisão antes de gerar os dados de treinamento

Use um esquema intermediário que mantenha a fonte junto de cada exemplo. Um registro fictício para revisão de um conjunto de dados de perguntas e respostas poderia ter esta aparência. A pergunta e a resposta do conjunto de dados devem vir de materiais próprios que tenham sido verificados.

{"id":"sample-001","source":"sample-handbook.txt","section":"Opening hours","question":"When does the desk open?","answer":"The desk opens at 9 a.m.","review_status":"pending","split":"unassigned"}

Este é um esquema de trabalho, não um payload de API de treinamento. Após a revisão, converta os registros aprovados para o formato exigido pela ferramenta de treinamento. Mantenha as referências às fontes e as decisões de revisão em um arquivo complementar, caso a ferramenta aceite apenas mensagens ou pares de entrada e saída.

Forneça ao agente verificações que ele possa executar

• Estrutura: analise cada linha de JSONL e exija os campos esperados e os tipos de valor corretos.
• Fontes: verifique se cada exemplo aponta para uma fonte e uma seção existentes.
• Duplicatas: compare o texto normalizado e, depois, revise separadamente as duplicatas aproximadas. Textos semelhantes ainda podem descrever fatos diferentes.
• Privacidade: procure dados pessoais e credenciais; em seguida, revise os registros sinalizados antes da exportação.
• Cobertura: conte os exemplos por categoria e liste as categorias com pouco ou nenhum material revisado.

Um script pode verificar se uma referência de fonte existe. Ele não pode comprovar que a resposta decorre dessa fonte. Examine as respostas, inclusive os exemplos com contexto ausente ou trechos contraditórios. Mantenha os exemplos gerados separados dos registros aprovados.

Não coloque o mesmo caso nos dados de treinamento e de teste

Decida o que a avaliação deve medir. Para testar o desempenho em documentos inéditos, mantenha todos os exemplos de um documento na mesma divisão. Quando vários arquivos descreverem o mesmo caso, agrupe-os por caso. Dividir as linhas aleatoriamente pode fazer com que uma resposta de avaliação quase igual apareça no treinamento.

Peça os arquivos train.jsonl e validation.jsonl, um manifesto das fontes e um relatório de validação. O relatório deve incluir a contagem de registros, os registros rejeitados, os grupos de duplicatas e a regra de divisão. Depois que o conjunto de dados passar por essas verificações, você poderá pedir ao Beeuni para executar um experimento de ajuste fino no computador de treinamento conectado.

Para o classificador, uma entrega utilizável inclui, junto dos arquivos JSONL, as definições dos rótulos, os campos de entrada e a regra para solicitações ambíguas. Inclua o script de preparação e suas configurações para que outro desenvolvedor possa reproduzir a conversão. Registre de qual lote de fontes veio a exportação; um arquivo chamado final.jsonl não informa ao revisor o que mudou desde a exportação anterior.

Se a fonte inicial for uma planilha, o guia de limpeza de CSV aborda identificadores e valores ausentes. Para colocar a preparação de conjuntos de dados atrás da sua própria interface, comece pelo guia do SDK.