Adicionar métricas não melhora necessariamente a compreensão. Muitos painéis incluem várias medidas do mesmo comportamento subjacente. As métricas tornam-se mais úteis para o diagnóstico quando combinadas em pares mutuamente destrutivos: custo e qualidade, contenção e sentimento, ou precisão e latência.
Os pares adequados mudam à medida que um produto de IA passa da fase-piloto para a produção. A medição deve acompanhar as decisões que a equipa precisa de tomar em cada fase.
A monitorização operacional e a medição estratégica têm finalidades diferentes. As equipas podem acompanhar centenas de sinais do sistema, recorrendo apenas a alguns pares para orientar as decisões sobre o produto.
As métricas de referência podem contar uma história convincente e, ainda assim, deixar por resolver uma decisão importante sobre o produto.
O assistente de IA da Klarna foi publicamente associado a uma maior taxa de processamento, custos mais baixos e índices de satisfação dos clientes comparáveis aos dos agentes humanos. No ano seguinte, a empresa decidiu aumentar o acesso ao apoio humano, tendo o seu diretor executivo reconhecido que fora dada demasiada importância à redução de custos.
Isto não constituiu uma rejeição do assistente de IA nem da tecnologia subjacente. Foi um ajuste ao equilíbrio entre a automatização e o atendimento humano, à medida que a empresa aprendia com a utilização do produto. À medida que a automatização passou a assumir um maior número de consultas simples e de elevado volume, a Klarna precisava de agentes humanos preparados para lidar com casos complexos e sensíveis.
Depois de definirem desde o início o que um produto deve alcançar, a maioria das organizações que desenvolvem produtos de IA acabará por enfrentar a mesma pergunta: está realmente a funcionar?
Quando a resposta não é clara, o impulso habitual é adicionar mais métricas. Três tornam-se 10 e depois 10 tornam-se 30. O painel fica mais completo, mas a compreensão da equipa pode não melhorar.
O problema nem sempre está na qualidade de cada medida, mas sim na relação entre elas. A satisfação dos clientes, o Net Promoter Score, as avaliações e as taxas de aprovação podem fornecer sinais úteis, mas também refletir mudanças semelhantes no sentimento geral. Quando evoluem em conjunto, confirmam que algo aconteceu, mas não explicam necessariamente porquê.
Por isso, as equipas de IA devem olhar além das métricas que coincidem entre si e identificar medidas que revelem resultados concorrentes. Estes pares mutuamente destrutivos revelam e ajudam a monitorizar o impacto dos compromissos subjacentes ao desempenho do produto, permitindo tomar melhores decisões.
Numa implementação anterior ao lançamento, a equipa conjunta estava a desenvolver um agente de voz de IA em tempo real para chamadas recebidas pelo apoio ao cliente. Uma das questões mais difíceis não dizia respeito à seleção ou à orquestração do modelo. Era saber como poderia a organização determinar se o produto estava a funcionar quando os clientes começassem a utilizá-lo em grande escala.
O quadro inicial utilizava três medidas:
Taxa de contenção: frequência com que a IA resolve uma chamada sem a transferir para uma pessoa.
Taxa de encaminhamento: frequência com que uma chamada é transferida para um agente humano.
Taxa de resolução: frequência com que o problema do cliente acaba por ser resolvido.
Cada medida era razoável. Em conjunto, porém, não conseguiam responder a uma pergunta óbvia: se os encaminhamentos aumentarem, o que nos diz isso?
A equipa dividiu os encaminhamentos em oito subtipos. Depois, acrescentou medidas de abandono, percurso e tempo, pontuações de compreensão da linguagem e resolução por tipo de consulta. O quadro acabou por incluir 31 métricas distribuídas por seis categorias.
Conseguia descrever os encaminhamentos em pormenor, mas continuava sem diagnosticar de forma fiável a respetiva causa. A maioria das métricas eram variações do mesmo comportamento, pelo que evoluíam em conjunto em vez de testarem explicações concorrentes.
O painel tornara-se descritivo, em vez de servir para o diagnóstico.
A equipa não precisava de mais um nível de decomposição. Precisava de métricas que se limitassem mutuamente.
Chamamos-lhes pares mutuamente destrutivos: duas medidas em que melhorar uma de forma isolada pode prejudicar o resultado representado pela outra. O nome descreve o modo de falha criado por uma otimização unilateral, não o estado pretendido.
Quando ambos os lados se mantêm saudáveis, o produto poderá estar a funcionar de forma sustentável. Quando divergem, o sentido dessa divergência ajuda a equipa a decidir onde investigar.
O que tínhamos | Par mutuamente destrutivo | O que o par pode revelar |
|---|---|---|
Taxa de encaminhamento dividida em oito subtipos | Taxa de encaminhamento ↔ tempo até ao encaminhamento | Um encaminhamento imediato pode indicar um problema de confiança ou enquadramento; um encaminhamento posterior pode indicar que o sistema não consegue concluir a tarefa. |
Taxa de contenção e taxa de resolução apresentadas separadamente | Taxa de contenção ↔ sentimento do cliente | Se a contenção representa uma resolução satisfatória ou o abandono da tentativa pelo cliente. |
Taxa de resolução por tipo de intenção | Taxa de resolução ↔ profundidade da conversa | Se uma resolução bem-sucedida é eficiente ou exige uma interação desgastante. |
Para analisar melhor como isto se manifesta e o que fazer com esta informação, consideremos a taxa de encaminhamento e o tempo até ao encaminhamento. A equipa não saberá como os clientes se comportam até receber chamadas reais, mas pode definir as hipóteses que precisa de testar.
Se mais chamadas começarem a ser encaminhadas e os clientes abandonarem a experiência de IA nos primeiros 30 segundos, a equipa deve investigar a confiança, a informação prestada, o tom e as interações iniciais. Se os clientes pedirem o encaminhamento após passarem vários minutos a tentar realizar uma tarefa, é mais provável que o problema esteja na capacidade ou na cobertura do fluxo de trabalho.
O valor global dos encaminhamentos é o mesmo. A decisão sobre o produto é diferente.
Um par útil não comprova por si só a causa. Restringe o âmbito da investigação e torna mais clara a decisão seguinte.
O exemplo da Klarna apresentado anteriormente mostra como este princípio se aplica quando o custo e a qualidade do serviço interagem. Demonstra como um modelo operacional assente em IA pode evoluir à medida que uma empresa monitoriza o impacto dos compromissos e aprende com a implementação.
Em fevereiro de 2024, a empresa comunicou que o seu assistente de IA tinha gerido 2,3 milhões de conversas no primeiro mês, realizado trabalho equivalente ao de 700 agentes a tempo inteiro e alcançado índices de satisfação dos clientes comparáveis aos dos agentes humanos. A Klarna estimou que o assistente contribuiria para um aumento dos lucros de 40 milhões de dólares em 2024. Estes eram resultados comunicados pela própria Klarna, não uma avaliação independente.
Em maio de 2025, o diretor executivo da Klarna afirmou que a empresa dera demasiada importância à redução de custos no apoio ao cliente e anunciou planos para aumentar o acesso ao apoio humano. Isto representou um ajuste ao equilíbrio entre o serviço automatizado e o humano, não uma rejeição do assistente de IA ou da tecnologia subjacente.
Os dados públicos demonstram por que motivo as medidas de eficiência devem ser consideradas em conjunto com as necessidades de diferentes clientes e interações. Um sistema de IA pode ter um bom desempenho médio, embora alguns casos complexos, sensíveis ou invulgares continuem a beneficiar de um canal humano acessível.
Monitorizar ambos os lados desta relação ajuda uma empresa a decidir onde a automatização cria valor, onde o apoio humano continua a ser importante e como o equilíbrio deve mudar à medida que surgem novos dados.
Outros pares mutuamente destrutivos em produtos de IA podem incluir:
Par mutuamente destrutivo | Risco que ajuda a revelar |
|---|---|
Precisão da resposta ↔ latência da resposta | Um sistema tecnicamente preciso, mas demasiado lento para o fluxo de trabalho. |
Conclusão de tarefas ↔ taxa de intervenção do utilizador | Um fluxo de trabalho de IA que conclui tarefas que os utilizadores refazem repetidamente. |
Custo por interação ↔ qualidade avaliada do resultado | Poupanças obtidas à custa da experiência do cliente ou do trabalhador. |
Adoção ↔ tempo até à obtenção de valor | Aumento dos registos sem um valor correspondente para os utilizadores. |
O objetivo não é fazer com que ambas as medidas aumentem indefinidamente. É tornar o compromisso visível antes que uma otimização unilateral crie um problema operacional.
Surgiu um desafio semelhante numa implementação de apoio a jogadores para uma empresa de jogos para dispositivos móveis. O sistema tratava problemas de grande volume, como a perda de progresso, contestações de pagamentos e o acesso a contas.
As medidas de eficiência eram importantes porque o sistema operava em grande escala. Mas o apoio a jogadores não é apenas uma fila operacional. Os jogadores chegam muitas vezes frustrados porque algo já correu mal noutra parte da sua experiência.
Esse ponto de partida altera a forma como os dados de satisfação dos clientes devem ser interpretados. Um jogador cujo problema tenha sido corretamente resolvido pode, ainda assim, indicar uma satisfação baixa por ter perdido o progresso. Interpretar essa pontuação sem contexto pode penalizar a interação com o apoio devido a uma frustração surgida anteriormente no percurso do cliente.
Por isso, a equipa precisava de distinguir o sentimento inicial do cliente do efeito da experiência de apoio. A pergunta mais útil não era: «O jogador ficou satisfeito?» Era antes: «A interação melhorou a situação em relação ao ponto de partida do jogador?»
Essa comparação pode ajudar a distinguir a frustração com o produto da qualidade do apoio, desde que a equipa disponha de uma forma fiável de medir ambas.
Os produtos de IA mudam, mas as respetivas métricas permanecem muitas vezes inalteradas.
Durante uma fase-piloto, a questão central poderá ser se o sistema é suficientemente fiável para justificar a continuação do investimento:
Consegue concluir de forma fiável a tarefa principal?
Os utilizadores confiam nele o suficiente para continuar?
Como se comporta fora dos cenários mais comuns?
É possível identificar as falhas e recuperar delas em segurança?
Estas perguntas favorecem pares como:
sucesso na tarefa principal ↔ desempenho em casos extremos;
taxa de automatização ↔ taxa de intervenção humana; e
velocidade de conclusão ↔ confiança do utilizador.
Quando o produto se torna importante para as operações, as perguntas mudam:
Consegue crescer em escala sem reduzir a qualidade?
A sua viabilidade económica melhora com a utilização?
O desempenho mantém-se estável à medida que a adoção aumenta?
As intervenções humanas ocorrem nos momentos certos?
Os pares correspondentes podem passar a ser:
custo por interação ↔ qualidade avaliada do resultado;
amplitude da adoção ↔ profundidade da utilização; e
taxa de automatização ↔ exposição ao risco operacional.
As métricas iniciais não estão necessariamente erradas. Respondem às perguntas que eram importantes numa fase anterior.
O risco surge durante a transição. As métricas da fase-piloto tendem a persistir porque as equipas sabem como apresentá-las e ninguém é responsável por decidir quando as retirar. Medidas que antes promoviam a aprendizagem podem transformar-se gradualmente em métricas de vaidade.
Por isso, os pares devem ter um ciclo de vida. As equipas devem introduzi-los para uma decisão específica, avaliar se continuam a revelar um compromisso relevante e retirá-los quando o produto ou a decisão mudar.
Os sistemas de IA exigem observabilidade detalhada, alertas, garantia de qualidade e avaliação. A remoção desses sinais dificultaria a operação segura do produto. Mas a monitorização operacional não é o mesmo que a medição destinada à liderança.
A monitorização ajuda as equipas a detetar incidentes, rastrear falhas e compreender o comportamento do sistema. As métricas de decisão ajudam os responsáveis pelo produto e pelo negócio a decidir se devem investir, intervir, mudar de rumo ou aceitar um compromisso.
Uma organização pode monitorizar centenas de sinais técnicos e operacionais, destacando apenas dois ou três pares mutuamente destrutivos para uma decisão específica sobre o produto. Manter reduzido este nível de decisão facilita a definição de prioridades.
A frequência de revisão adequada depende do produto. Um sistema novo ou em rápida evolução pode exigir revisões semanais das decisões, enquanto um produto maduro pode permitir uma frequência mensal ou trimestral. O princípio é mais importante do que o intervalo: rever o par com frequência suficiente para agir antes de o compromisso se tornar dispendioso ou inseguro.
Um par só se torna útil quando a organização concorda sobre o que acontecerá se este se deteriorar.
Isto exige mais do que definir um limite crítico para a divergência. As equipas devem considerar três condições:
Falha absoluta: uma medida ultrapassa um limiar inaceitável, independentemente da outra.
Divergência: uma medida melhora enquanto o seu contrapeso se deteriora.
Deterioração conjunta: ambos os lados pioram, o que sugere um problema mais abrangente no produto ou na operação.
Cada par deve ter:
um responsável identificado;
uma decisão clara que ajude a tomar;
limiares ou critérios de avaliação acordados;
um processo de investigação; e
um conjunto de possíveis intervenções.
Sem esses elementos, a organização está a observar o produto em vez de o gerir.
Antes de adicionar outra medida, escolha uma decisão importante sobre o produto e responda a estas perguntas. Registe as respostas para que a revisão termine com um próximo passo acordado.
1. Que decisão precisamos de tomar com a ajuda destas métricas?
Seja específico: estamos a decidir se devemos alargar a automatização, mudar de modelo ou melhorar a transferência para uma pessoa? Identifique a decisão antes de escolher as medidas.
2. Se este número melhorar, o que poderá piorar?
Identifique o resultado que precisa de proteger e uma medida que revele possíveis danos. Por exemplo, combine o custo por interação com a qualidade avaliada do resultado para verificar se as respostas mais baratas continuam a ser úteis.
3. O que poderão os números de referência estar a ocultar?
Analise ambas as medidas para os mesmos utilizadores, tarefas e período e procure depois grupos que estejam a obter piores resultados. Considere também as condições iniciais: a baixa satisfação pode refletir uma frustração anterior à interação com o apoio.
4. O que nos levaria a agir e quem é responsável pela resposta?
Defina critérios para agir quando uma medida ultrapassar um limite inaceitável, quando uma melhorar e a outra piorar, ou quando ambas se deteriorarem. Acorde quem irá investigar, o que verificará primeiro e quando comunicará as conclusões.
5. Este par continua adequado à fase atual do produto?
Decida se deve mantê-lo, substituí-lo ou retirá-lo. Uma fase-piloto pode centrar-se na fiabilidade das tarefas e na confiança dos utilizadores; um serviço em produção pode exigir uma análise mais atenta do custo e da qualidade. Defina uma data para reavaliar a escolha.
A medição de produtos de IA deve fazer mais do que descrever o desempenho. Deve revelar os compromissos que a organização está a assumir e tornar mais clara a decisão seguinte.