Edição de 19/09: um corpus de aceitação para classificar pedidos

Uma etiqueta não é uma decisão sem consequências

Uma PME pretende separar pedidos de faturação, assistência técnica e alteração de contrato. A pergunta não é se o modelo reconhece exemplos limpos numa demonstração. É se consegue encaminhar os pedidos reais do serviço sem esconder mensagens ambíguas numa categoria conveniente.

Propomos começar por encaminhamento consultivo. A pessoa responsável conserva a decisão final e vê o texto que sustenta a etiqueta. Só depois de um ensaio documentado deve discutir-se automatização limitada. Não incluímos recrutamento, crédito ou diagnóstico neste caso; a aceitação descrita pertence apenas à fila de assistência escolhida.

Referências para avaliar, não uma receita obrigatória

O Playbook NIST MEASURE 2.1 recomenda documentar conjuntos de teste, métricas e ferramentas de TEVV. OWASP LLM09 recomenda verificação humana para conteúdo crítico ou sensível. O AI RMF é voluntário. A seleção do corpus e os critérios seguintes são propostas Velqory, não um requisito universal do NIST.

Curar o desacordo antes de avaliar o modelo

A nossa proposta começa com exemplos sintéticos ou dados cuja utilização tenha sido validada pelo responsável. Cada caso recebe categoria esperada, passagem justificativa e indicação de que precisa de esclarecimento. Dois conhecedores do serviço rotulam sem consultar a resposta do modelo; um terceiro resolve o desacordo e regista o motivo.

Não force consenso artificial. Uma mensagem que junta erro técnico e contestação de fatura pode exigir dois percursos ou contacto humano. Se a própria regra do serviço for omissa, marque o caso como regra por decidir. O classificador não deve receber a missão de resolver uma indefinição organizacional com uma etiqueta confiante.

O caso que uma média esconderia

Cenário hipotético: muitos pedidos simples de faturação são classificados corretamente, mas uma mensagem com alteração de contrato acaba na assistência técnica. Uma média favorável não responde à decisão de aceitação desse percurso. Propomos mostrar erros por categoria e, separadamente, casos que deveriam parar para esclarecimento.

Reserve exemplos para aceitação e não os use para afinar sucessivamente o prompt. Inclua mensagens curtas, termos locais, anexos ausentes e solicitações múltiplas. A revisão humana deve poder selecionar «não há informação suficiente» sem ser contada automaticamente como falha do revisor. Registe também a correção e o seu fundamento.

Uma autorização pequena, sustentada em casos

A matriz propõe condições internas, não resultados medidos. O dono da assistência escolhe previamente os erros que bloqueiam encaminhamento automático. Se um caso crítico falhar, a equipa não deve diluí-lo com mais exemplos fáceis; deve corrigir o percurso ou conservar confirmação humana nessa categoria.

Depois da aceitação, manter capacidade de corrigir

Guarde a versão do corpus, as regras de adjudicação, a configuração avaliada e os resultados caso a caso. A proposta permite automatizar apenas categorias cuja aceitação foi explicitamente registada; novas etiquetas e mensagens fora do âmbito regressam à fila humana. Uma alteração de modelo ou regra exige decidir que casos repetir.

Numa pequena equipa portuguesa, duas funções podem caber à mesma pessoa, mas o conflito deve ser visível e compensado com revisão adicional dos casos bloqueantes. Não apresentamos taxas de acerto ou uma amostra estatisticamente representativa. Este corpus serve uma decisão operacional delimitada; não demonstra qualidade universal nem dispensa o acompanhamento dos erros que surgirem.