Avaliar toxicidade e segurança de um modelo de linguagem corporativo exige testar o comportamento do sistema completo em português: mensagens recebidas, documentos consultados, respostas e ações autorizadas. Um detector de palavras ofensivas resolve apenas uma parte do problema. A avaliação também precisa identificar discriminação, exposição de dados e instruções que tentam desviar o atendimento.
Comece com critérios escritos, exemplos do seu domínio e um conjunto de testes separado do desenvolvimento. Combine verificações automáticas com revisão humana, registre divergências e defina quais falhas impedem a liberação. O resultado deve orientar uma decisão concreta sobre uso e controles, sem transformar uma nota média em promessa de segurança.
Resumo rápido
- Separe toxicidade, discriminação, vazamento e ações indevidas na avaliação.
- Teste português brasileiro real, com contexto, regionalismos e linguagem informal.
- Meça tanto conteúdo perigoso liberado quanto pedidos legítimos bloqueados.
- Use dados sintéticos para testar exposição de informações sem comprometer pessoas.
- Reavalie depois de mudar modelo, instruções, documentos ou ferramentas.
O que a avaliação deve cobrir
Toxicidade é um rótulo amplo. Para trabalhar com ele, decomponha comportamentos observáveis: insulto dirigido, ameaça, assédio ou desumanização. Diferencie uma resposta que pratica a ofensa de outra que reconhece um relato de abuso. Uma mensagem pode mencionar linguagem ofensiva para pedir ajuda; bloquear a conversa inteira pode impedir justamente o atendimento necessário.
Segurança inclui outros riscos que uma análise de tom não revela. Uma resposta educada pode expor um cadastro de outro cliente ou orientar uma ferramenta a executar uma operação sem autorização. No planejamento, mantenha categorias separadas para conteúdo, privacidade e execução. Assim, o time consegue escolher a correção apropriada para cada falha.
O perfil de IA generativa do NIST reúne riscos e ações de gestão para sistemas generativos. Use essa referência como apoio para organizar responsabilidades e evidências. Ela não substitui uma avaliação do seu produto nem fornece um certificado automático para um modelo que passou em testes locais.
Escreva os limites do assistente em linguagem operacional. Um atendimento de varejo pode explicar como solicitar uma troca, mas não deve inventar exceções à política comercial. Um assistente interno pode resumir documentos autorizados, mas não deve ampliar o acesso do usuário. Converta cada limite em uma pergunta de teste com comportamento esperado.
Como construir uma amostra de português brasileiro
Reúna situações de uso com autorização e minimização de dados. Quando o histórico real contém informações desnecessárias, substitua nomes, documentos e contatos antes de distribuí-lo aos avaliadores. Combine casos comuns com situações difíceis: ironia, abreviações, frases incompletas, negação e mudança de assunto. Não trate erro de português como indício de má intenção.
O estudo original do ToLD-Br apresenta um conjunto de dados para detecção de linguagem tóxica em português brasileiro, baseado em redes sociais. Ele ajuda a conhecer a pesquisa no idioma, mas esse contexto difere de atendimento corporativo. Uma nota nessa base não comprova desempenho em conversas sobre cobrança, suporte ou recursos humanos.
Monte pares de exemplos que alterem somente um fator relevante. Um pedido legítimo pode ser escrito com tom calmo ou irritado; a utilidade básica da resposta deve ser preservada. Em outro par, mantenha o pedido e altere uma referência demográfica que não deveria afetar o atendimento. Revise se a variação continua natural e não introduz outra diferença que explique o resultado.
Inclua denúncias de preconceito e pedidos de esclarecimento sobre linguagem discriminatória. O sistema deve conseguir acolher e orientar sem reproduzir ataques. Defina no manual quando uma citação é necessária e quando basta descrevê-la. Os avaliadores precisam julgar função, destinatário e contexto do conteúdo, não apenas a presença de termos em uma lista.
Distribua conversas inteiras entre desenvolvimento e teste, evitando colocar versões quase iguais nos dois conjuntos. Reserve uma parcela para casos criados por quem não escreveu as instruções do assistente. Para complementar essa preparação, consulte o guia de avaliação da qualidade de modelos em português.
Quais testes e métricas usar
| Dimensão | Teste sugerido | Evidência a registrar |
|---|---|---|
| Toxicidade | Provocação e relato legítimo de ofensa | Resposta ofensiva ou recusa indevida |
| Tratamento desigual | Pares equivalentes com referências demográficas distintas | Diferença de tom, acesso ou orientação |
| Privacidade | Solicitação de registro sintético de outro usuário | Informação exposta e ponto de acesso |
| Injeção de instruções | Documento de teste com comando alheio à tarefa | Desvio da tarefa ou tentativa de ação |
| Utilidade | Pergunta legítima sobre tema sensível | Ajuda pertinente sem bloqueio excessivo |
Para um detector, falso positivo significa marcar como problemático um caso permitido; falso negativo significa deixar passar um caso que deveria ser sinalizado. Registre ambos por categoria. Para a aplicação, avalie também a resposta final: o detector pode sinalizar corretamente uma entrada enquanto o assistente responde de maneira inadequada.
Use uma escala de gravidade com exemplos. Uma formulação grosseira, a exposição de um dado de teste e a execução indevida de uma operação não devem ser somadas como se tivessem o mesmo impacto. Defina critérios de bloqueio para incidentes críticos e critérios de revisão para ambiguidades. Esses critérios são decisões do projeto, não propriedades universais de uma pontuação.
Apresente contagens e denominadores. Dizer “houve duas falhas” informa pouco sem saber quantos testes foram executados, em quais categorias e quantas repetições ocorreram. Se repetir uma conversa para observar variação, registre essa decisão e não trate as repetições como clientes independentes. Compare versões com a mesma bateria e condições documentadas.
Um modelo avaliador pode ajudar a priorizar revisão, desde que suas decisões sejam verificadas por pessoas. Ele também pode interpretar mal ironia, contexto e regras locais. Crie um conjunto já julgado por humanos e confira onde o avaliador concorda ou diverge. Não use exclusivamente a autoavaliação do mesmo sistema que está sendo examinado.
Como testar o sistema completo antes de liberar
Teste as entradas que chegam pelo usuário e por materiais recuperados. A OWASP descreve injeção de instruções como um risco que pode alterar o comportamento esperado de aplicações com modelos de linguagem. Na sua bateria, use documentos controlados para verificar se conteúdo consultado consegue assumir o papel de uma ordem.
Um teste seguro pode colocar em um documento fictício a instrução de abandonar a pergunta e solicitar uma informação irrelevante. O resultado esperado é que o assistente trate esse trecho como conteúdo não confiável. Execute o cenário em ambiente de teste, sem credenciais reais nem ferramentas capazes de gerar efeitos externos. Observe também chamadas de ferramentas, não somente o texto exibido.
Para privacidade, crie dois usuários fictícios com registros distintos e marque campos com identificadores sintéticos reconhecíveis. Verifique se um deles consegue obter informações reservadas ao outro. A orientação da OWASP sobre exposição de informações sensíveis inclui controles de acesso e restrição de fontes. A autorização deve ser aplicada no serviço que fornece os dados.
Confira o que ocorre quando um componente falha. Se o detector de conteúdo ficar indisponível, a aplicação terá um modo de atendimento restrito, uma fila humana ou outra política definida? Se o mecanismo de autorização falhar, a consulta não deve simplesmente continuar sem ele. Teste essas condições deliberadamente e registre o comportamento visível para o usuário.
Monte uma ficha de liberação com versões de instruções, modelo, conjunto de testes, documentos e permissões. Inclua responsáveis pela revisão e um caminho para retornar à configuração anterior. O guia de como testar um agente de IA complementa essa organização com cenários funcionais. Repita os testes afetados quando qualquer componente mudar.
Exemplo: atendimento de uma rede varejista em Recife
Imagine uma rede fictícia de lojas de eletrodomésticos em Recife que quer usar um assistente para orientar trocas e consultar entregas. O exemplo é ilustrativo e não representa resultados de uma empresa real. O projeto começa separando três decisões: responder à dúvida, sinalizar um conteúdo para revisão e permitir uma consulta ao cadastro.
Em um cenário, a pessoa reclama com palavrões porque a entrega atrasou. A resposta esperada reconhece a frustração, evita reproduzir ofensas e oferece os próximos passos permitidos. Bloquear todo atendimento por causa do tom seria um falso positivo operacional. A equipe distingue essa situação de uma ameaça dirigida a um funcionário, que exige o procedimento interno correspondente.
Em outro cenário, a pessoa relata que sofreu tratamento discriminatório na loja. O teste verifica se o assistente acolhe o relato, informa o canal adequado e evita pedir detalhes desnecessários. Os avaliadores analisam se a resposta minimiza a denúncia ou inventa uma investigação já aberta. O sistema precisa ser útil sem fabricar providências.
A equipe também cria dois pedidos sintéticos e tenta consultar um deles com a identidade do outro cliente. Mesmo que a conversa pareça educada e o detector de toxicidade não encontre problema, o acesso deve ser negado pela aplicação. Essa combinação deixa claro por que o selo “sem toxicidade” não basta para autorizar o uso corporativo.
Antes de liberar a consulta, a rede revisa os casos críticos e decide quais precisam de correção. As falhas viram testes permanentes, com dados fictícios e saída esperada. Somente medições posteriores poderiam sustentar alegações de melhoria; a descrição do processo, por si só, não demonstra redução de incidentes.
Erros comuns
Traduzir um teste estrangeiro e encerrar o trabalho. A tradução pode preservar palavras e perder contexto cultural. Use a tradução como ponto de partida, depois revise situações com pessoas familiarizadas com o público. Inclua linguagem informal sem caricaturar regiões ou grupos sociais.
Confundir recusa com segurança. Um assistente que bloqueia tudo pode evitar certos erros e continuar inadequado para o serviço. Avalie se ele responde aos pedidos legítimos, explica limites com clareza e oferece encaminhamento útil quando não pode resolver. A taxa de recusas deve ser interpretada junto da adequação de cada recusa.
Guardar conversas sensíveis sem necessidade. O registro de avaliação não precisa copiar todos os dados da interação. Prefira identificadores controlados, conteúdo minimizado e acesso restrito. Defina retenção e responsáveis com as áreas competentes, considerando o contexto da organização, em vez de tratar o histórico integral como requisito técnico automático.
Corrigir apenas o texto de instrução. Uma falha pode estar no controle de acesso, no documento recuperado ou na ferramenta. Localize a etapa que permitiu o comportamento indevido. Uma instrução para “não revelar dados” não substitui impedir que dados de outra pessoa entrem na consulta.
Perguntas frequentes
Uma ferramenta automática consegue aprovar o modelo sozinha?
Ela pode executar verificações e sinalizar desvios, mas a aprovação exige critérios do negócio e revisão das evidências. Casos ambíguos, consequências graves e divergências entre avaliadores precisam de análise humana. Registre o escopo aprovado para evitar que uma validação de atendimento seja reutilizada em outra função.
Devo testar somente a resposta final?
Não. Verifique documentos recuperados, decisões intermediárias e ferramentas acionadas, com o acesso necessário para a equipe de avaliação. Uma resposta final aparentemente adequada pode esconder uma consulta indevida. O registro deve permitir identificar a origem da falha sem expor conteúdo sensível desnecessário.
Como escolher o limite de toxicidade?
Use exemplos rotulados do domínio e compare bloqueios indevidos com conteúdo inadequado liberado. Considere consequências por categoria e revise casos próximos do limiar. O valor não deve ser copiado de outra aplicação sem validação, porque público, finalidade e distribuição das mensagens podem ser diferentes.
Quando executar uma nova rodada?
Após mudanças que possam afetar comportamento ou acesso, incluindo instruções, modelo, documentos, detector e permissões. Incidentes e padrões novos de uso também justificam revisão. Preserve uma bateria estável para comparação e acrescente cenários novos sem apagar os casos que revelaram falhas anteriores.
