Claude Opus 5.5 vs. Sonnet 5.5 na triagem: o que medir antes de escolher

A questão não é qual modelo parece mais capaz, mas qual executa este fluxo com menos risco

Comparar Claude Opus 5.5 e Claude Sonnet 5.5 para atendimento ao cliente exige, antes de tudo, definir o que significa «fazer triagem». Nesta avaliação, a tarefa não seria responder ao cliente, redigir uma solução nem decidir, por conta própria, uma compensação. Consistiria em converter uma consulta breve em dados estruturados que ajudem uma pessoa ou um sistema subsequente a classificá-la e encaminhá-la à equipe adequada.

Essa distinção importa. Um modelo pode produzir uma resposta fluente e, ainda assim, identificar incorretamente o assunto, inventar um dado que o cliente não forneceu ou deixar de perceber que faltam informações. Para as equipes de operações, esses erros podem ser mais relevantes do que o tom ou a extensão da resposta. Por isso, a comparação deve medir campos concretos e decisões de encaminhamento, não impressões gerais sobre a qualidade da conversa.

As evidências verificadas disponíveis não permitem declarar um vencedor nesse fluxo. Não incluem uma avaliação compartilhada dos dois modelos com consultas de suporte, uma rubrica comum e resultados reproduzíveis de classificação, extração e encaminhamento. A documentação localizada sobre Sonnet 5.5 é útil para consultar informações sobre o próprio modelo, mas não estabelece seu desempenho em relação ao Opus 5.5 nesta tarefa. Uma comparação de configurações Medium identifica os dois modelos, mas o material verificado também não apresenta resultados de triagem.

Portanto, este guia não apresenta pontuações nem simula um teste já realizado. Propõe um protocolo que uma equipe pode aplicar se confirmar o acesso às variantes exatas e puder documentar as condições de cada execução. Até lá, qualquer recomendação sobre qual modelo escolher deve ser condicional. Para outras comparações de modelos, é possível consultar o índice de comparações, mas ele também não substitui uma avaliação alinhada ao fluxo e aos dados próprios da equipe.

Definir a tarefa e o contrato de saída antes de executar o teste

O primeiro passo é redigir uma especificação que não dependa das respostas de nenhum dos modelos. Para cada consulta, o sistema deve devolver apenas os campos de que o processo realmente precisa. Um esquema ilustrativo pode incluir categoria principal, categorias secundárias, quando aplicável, urgência, produto ou serviço mencionado, identificador explícito, informações ausentes, nível de confiança e uma decisão de continuar ou encaminhar para revisão. A equipe deve definir quais campos são obrigatórios e quais valores são permitidos.

A categoria não deve ser confundida com o encaminhamento. «Problema de cobrança» pode ser uma classificação válida, mas talvez não seja suficiente para direcionar o caso se a consulta também informar uma interrupção urgente do serviço. A rubrica deve especificar como tratar vários assuntos em uma mesma mensagem, se é permitido atribuir mais de uma categoria e qual regra determina a prioridade. Sem essa definição, duas pessoas avaliadoras podem pontuar de maneiras diferentes a mesma saída.

Também convém separar a validade sintática da correção semântica. Uma resposta pode respeitar perfeitamente um formato estruturado e preencher os campos com valores errados. E, no sentido inverso, pode interpretar corretamente a consulta, mas não cumprir o formato exigido pela integração. Essas dimensões devem ser avaliadas separadamente para que um problema operacional não fique escondido atrás de uma pontuação agregada.

Antes da execução, devem ser fixados as instruções, o esquema, as categorias, as regras de encaminhamento e o procedimento de pontuação. Alterações posteriores devem ser registradas como uma nova versão do teste; as regras não devem ser modificadas retroativamente para favorecer o resultado de um modelo.

Montar um conjunto que represente consultas reais, não apenas exemplos fáceis

Um teste útil precisa incluir casos claros e difíceis. Os exemplos claros permitem medir se o modelo reconhece a intenção quando ela é expressa diretamente. Os casos incompletos verificam se identifica informações ausentes. Os ambíguos mostram se solicita revisão ou escolhe uma categoria sem fundamento. Também são necessárias mensagens com vários assuntos, erros de digitação, abreviações e referências contextuais, desde que essas características existam no canal que se pretende avaliar.

O conjunto deve refletir a distribuição que a equipe espera processar, mas também conter exemplos suficientes de riscos pouco frequentes para que possam ser analisados separadamente. Se uma categoria urgente aparecer raramente no tráfego habitual, uma amostra aleatória pequena talvez não a inclua. A equipe pode acrescentar um bloco de casos de risco para avaliá-lo especificamente, sem esconder que esse bloco não representa a frequência real dos casos.

Cada caso deve ter um rótulo de referência e uma breve explicação da decisão esperada. Nos casos discutíveis, é preferível que duas pessoas revisem o critério e cheguem a um acordo sobre a referência antes de comparar os modelos. Se os próprios avaliadores não conseguirem resolver um exemplo com a política disponível, o caso deve ser marcado como duvidoso, excluído da pontuação principal ou analisado separadamente.

Para evitar que o conjunto se transforme em um teste memorizável, convém reservar casos que não serão usados para ajustar as instruções. As consultas devem ser anonimizadas e reduzidas aos dados necessários. Conversas identificáveis não devem ser copiadas para uma ferramenta antes de confirmar que o canal e as condições de tratamento autorizam esse uso.

Verificar se a comparação é realmente equivalente

O nome exibido em uma interface não basta para identificar o que está sendo testado. Antes da execução, é preciso registrar o identificador exato do modelo fornecido por cada canal, a data, a interface ou API utilizada e os parâmetros configuráveis. Se um dos acessos apontar para uma variante diferente, usar ferramentas adicionais ou aplicar uma configuração que o outro não oferece, deixa de ser uma comparação estritamente equivalente.

A documentação disponível para Sonnet 5.5 descreve mudanças, compatibilidade e outras informações sobre esse modelo, mas não abrange Opus 5.5 nem resolve, por si só, como igualar os dois acessos. A página de comparação fornecida pelo Artificial Analysis identifica configurações Medium dos dois modelos; isso delimita um par que poderia ser investigado, mas não demonstra que o canal operacional escolhido pela equipe ofereça os mesmos parâmetros nem que tenha medido o fluxo de suporte.

Se os controles não forem iguais, não se deve forçar uma equivalência fictícia. É possível realizar duas análises: uma sobre capacidade na configuração comum disponível e outra sobre desempenho operacional nos canais que seriam usados de fato. Na segunda, as diferenças precisam ficar explícitas. Também devem ser registrados limites de saída, ferramentas disponíveis, novas tentativas automáticas e quaisquer transformações aplicadas pela plataforma.

As instruções devem ser mantidas idênticas quando o objetivo for isolar o efeito do modelo. Se um prompt diferente for ajustado para cada um, a comparação será entre os conjuntos modelo-configuração, e não apenas entre os modelos. Esse experimento pode ser útil para escolher uma solução de produção, mas deve ser identificado corretamente e documentado como tal.

Medir a qualidade por dimensão e analisar os erros que mudam uma decisão

A pontuação principal deve ser desagregada. Para classificação, mede-se a proporção de rótulos corretos e apresenta-se o detalhamento por categoria: uma média geral pode esconder que o sistema falha justamente no tipo de consulta mais sensível. Para extração, cada campo é verificado separadamente, contabilizando tanto omissões quanto dados acrescentados sem respaldo. Quando o processo permitir vários valores, a rubrica deve indicar como pontuá-los.

A detecção de informações ausentes exige uma referência explícita: qual dado falta, se ele é realmente necessário e se a resposta correta é perguntar, deixar o campo vazio ou encaminhar o caso. Não basta premiar o modelo por dizer «não sei» com frequência. Uma abstenção desnecessária pode atrasar o suporte; deixar de se abster diante de uma incerteza relevante pode enviar o caso para a fila errada.

O encaminhamento deve ser medido considerando os dois tipos de erro. Um encaminhamento que a política não exige consome capacidade humana, enquanto deixar de encaminhar um caso incerto pode transformar uma suposição em uma decisão operacional. A equipe deve ponderar esses custos de acordo com suas consequências. Se o custo de não encaminhar for muito maior, pode ser definido um limiar conservador e publicado o efeito desse limiar sobre o volume adicional de revisões.

Os erros de formato devem ser contabilizados separadamente da qualidade do conteúdo. É possível informar a proporção de saídas que cumprem o esquema e, entre as saídas válidas, a proporção que também satisfaz os critérios de conteúdo. Também é importante revisar manualmente os erros de grande impacto: prioridade atribuída incorretamente, invenção de dados pessoais, encaminhamento equivocado e ausência de revisão.

As diferenças entre os modelos não devem ser consideradas conclusivas sem levar em conta a incerteza estatística e a revisão dos casos. Se o conjunto for pequeno, uma variação de poucos exemplos pode alterar muito a porcentagem. Publicar o numerador, o denominador e os erros observados ajuda mais a interpretar o resultado do que apresentar apenas uma nota.

Calcular latência e custo por caso aceito, não por impressão

A latência deve ser medida com um método constante: desde o envio da consulta até que a saída esteja disponível e validada. Convém informar a mediana e uma medida de cauda, como o percentil 95, além do número de execuções. As medições devem abranger as condições que a equipe espera encontrar em produção; uma execução isolada não representa necessariamente a variabilidade do serviço.

O custo exige documentar o canal, a data, as unidades faturadas e as tarifas vigentes para aquela configuração. Os materiais verificados aqui não bastam para confirmar uma comparação completa de preços aplicável aos dois modelos nos canais que uma equipe usaria. Não se deve transferir o preço de uma página secundária, de uma variante ou de outra data como se fosse o custo real da integração avaliada.

Uma métrica mais útil do que o custo nominal por chamada é o custo por caso aceito. Para calculá-lo, somam-se os custos observados das execuções e das revisões necessárias e divide-se o total pelo número de casos que atendem à rubrica. Se uma saída inválida provocar novas tentativas ou intervenção humana, esse trabalho também pode fazer parte do custo operacional, desde que o método seja definido e aplicado igualmente às duas alternativas.

O cálculo deve evitar misturar custos que não foram medidos. Se a infraestrutura, o tempo de revisão ou as novas tentativas forem excluídos, isso precisa ser indicado. O resultado serve para a configuração e o volume considerados, não como propriedade universal do modelo.

Tratar privacidade e governança como propriedades do canal

A privacidade não pode ser deduzida pelo nome do modelo nem por sua capacidade de classificar. Ela depende das condições do serviço específico: quais dados são enviados, por quanto tempo são conservados, quem pode acessá-los, se são usados para outros fins e quais controles o canal oferece. Essas condições podem variar entre uma interface de consumo, um serviço empresarial e uma API; portanto, não devem ser apresentadas como uma propriedade genérica de Opus 5.5 ou Sonnet 5.5.

Antes de testar consultas reais, a pessoa responsável deve identificar o canal, revisar as condições aplicáveis e obter a aprovação interna correspondente. Se essa verificação não estiver disponível, devem ser usados dados sintéticos ou devidamente anonimizados, considerando que a anonimização não elimina automaticamente todos os riscos. Também devem ser excluídos segredos, credenciais e dados pessoais que não sejam imprescindíveis para avaliar a tarefa.

Mesmo quando as condições de tratamento forem aceitáveis, a saída deve ser considerada uma sugestão até que a avaliação e o desenho dos controles justifiquem outra abordagem. Uma classificação incorreta pode afetar os prazos de resposta ou o atendimento recebido. Para decisões sobre prioridade, acesso, compensação ou encerramento, a política deve definir que revisão humana é necessária e como corrigir os erros.

Como publicar uma conclusão sem exagerar seu alcance

Um relatório útil apresentaria resultados totais e por tipo de consulta, juntamente com o protocolo, o número de casos, os rótulos de referência, as instruções e as configurações verificadas. Também explicaria as exclusões, os casos duvidosos, as falhas de maior impacto e as condições de acesso que não puderam ser igualadas. Quando as condições de publicação permitirem, os materiais necessários para repetir o teste devem ser compartilhados, retirando-se quaisquer dados que possam identificar clientes.

A conclusão deve se limitar à população, ao canal e à configuração avaliados. Se Sonnet 5.5 tiver um custo menor por caso aceito em um conjunto de consultas habituais, isso não provará que seja melhor para todos os tipos de suporte. Se Opus 5.5 detectar mais casos ambíguos em uma amostra específica, isso tampouco comprovará uma vantagem universal. O resultado pode justificar um teste em modo sombra ou um piloto com revisão humana, mas não uma automação imediata.

As condições para um teste em produção devem ser definidas com antecedência: percentual máximo de erros críticos, proporção de saídas válidas, política de encaminhamento, controles de privacidade e mecanismo de reversão. Se os critérios não forem atingidos, a opção prudente é manter a revisão humana ou não implantar a solução. Se os dois modelos falharem de maneira semelhante em uma categoria, talvez o problema esteja no esquema, na política ou na qualidade dos dados, e não em uma diferença que a escolha entre modelos possa resolver.

Com as evidências atualmente verificadas, não é possível recomendar um dos dois modelos como vencedor para triagem. É possível, porém, estabelecer o que falta para decidir: confirmar os identificadores e os canais, fixar uma rubrica, executar a mesma coleção de casos em condições documentadas e medir os erros que afetam a operação. Até que esses dados estejam disponíveis, qualquer escolha é uma hipótese a testar, não uma conclusão fundamentada.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.