QA do Contact Center da DiDi Substitui uma Caixa-Preta pelo Amazon Bedrock

A DiDi substituiu uma ferramenta opaca de garantia de qualidade depois que suas verificações de intenção alcançaram apenas 38% de precisão. Seu novo sistema de QA do contact center da DiDi teria elevado esse índice para 86%.

A empresa desenvolveu a substituição com a AWS para seu International Business Group. O sistema processa conversas de suporte em espanhol e português nos serviços de transporte por aplicativo, entrega de comida e serviços financeiros. Ele também avalia conformidade e identifica reclamações emergentes de clientes.

Isso é mais do que outra empresa adicionando um grande modelo de linguagem ao suporte ao cliente. A DiDi transferiu um controle interno relevante de um fornecedor externo para uma arquitetura que sua própria equipe pode inspecionar e modificar. A principal disputa, portanto, é entre automação terceirizada e opaca e IA transparente e controlada pela própria empresa.

A AWS e a DiDi divulgaram o sistema em um estudo de caso sobre QA de contact center em 8 de setembro de 2026. A maior parte dos indicadores de desempenho vem da validação em produção da DiDi e não passou por auditoria independente.

Ainda assim, os resultados merecem atenção. Eles mostram como contexto restrito, verificações determinísticas e saídas estruturadas podem ser mais importantes do que reescrever repetidamente um prompt.

O Que Mudou no QA do Contact Center da DiDi

A DiDi não substituiu um modelo por outro. Ela dividiu a garantia de qualidade em três pipelines controlados, com funções e requisitos de evidência distintos.

O primeiro pipeline verifica a intenção. Os representantes de atendimento ao cliente atribuem a cada conversa um motivo de contato, que posiciona o caso na árvore hierárquica de classificação da DiDi. O sistema verifica se esse motivo atribuído corresponde ao que o cliente discutiu.

Se o rótulo parecer incorreto, o pipeline recomenda uma alternativa. Ele também examina conversas classificadas como “Outros”, nas quais nenhuma categoria existente pareceu adequada. Esses casos podem revelar lacunas na própria taxonomia.

O segundo pipeline avalia a conformidade. Ele pontua diversos critérios de qualidade enquanto extrai insights operacionais da mesma conversa. A DiDi afirma que sua precisão média na pontuação de conformidade superou 90% durante a validação em produção.

O terceiro pipeline analisa dados de Voz do Cliente. Voz do Cliente, ou VOC, significa evidências agregadas sobre problemas dos clientes, sentimento, resultados e causas recorrentes. A DiDi usa esse pipeline sob demanda quando as equipes de operações precisam compreender um padrão em desenvolvimento.

Registros de chat ao vivo e transcrições de chamadas entram primeiro em uma camada de pré-processamento. A saída de conversão de fala em texto das chamadas é normalizada para o mesmo formato de conversa usado no chat. Os registros resultantes seguem então pelos pipelines de QA apropriados.

Esse esquema comum é importante. Diferenças entre voz e chat não deveriam obrigar cada componente de análise posterior a implementar sua própria lógica de ingestão. O sistema separa o processamento de canais das tarefas de raciocínio que vêm depois.

O negócio internacional da DiDi opera em 14 países e regiões, segundo as empresas. Sua organização de suporte atende conversas em espanhol e português de dezenas de milhões de usuários em três linhas de negócio.

Nessa escala, a revisão manual consegue inspecionar apenas uma parcela limitada das interações. No entanto, a alternativa terceirizada tinha seu próprio problema. A DiDi afirma que seu sistema anterior não oferecia transparência de raciocínio suficiente para explicar julgamentos históricos ou apoiar mudanças rápidas.

Uma pontuação de conformidade reprovada pode afetar treinamento, auditorias e prioridades operacionais. Um rótulo de intenção incorreto pode distorcer relatórios sobre os motivos pelos quais os clientes precisam de ajuda. Portanto, um julgamento sem explicação não é apenas inconveniente para um desenvolvedor.

A substituição associa uma cadeia de raciocínio a cada julgamento do modelo. Os revisores podem ver a justificativa declarada para uma pontuação, examinar a conversa original e comparar a decisão com a regra aplicável.

Essa rastreabilidade cria a tensão central do artigo. Trazer o sistema para dentro da DiDi melhora a visibilidade e o controle, mas também torna a DiDi responsável por validação, segurança, configuração e precisão contínua.

A DiDi agora controla as definições que moldam o resultado. Ela também assume as consequências quando essas definições são incompletas ou incorretas.

Por Que o Isolamento de Contexto Superou Mais Ajustes de Prompt

O maior ganho de precisão relatado veio de mostrar menos informações ao modelo no momento certo, e não de adicionar mais instruções.

O projeto inicial de verificação de intenção da DiDi seguiu uma abordagem intuitiva. Ele colocava a árvore completa de motivos de contato ao lado da conversa e pedia ao modelo que julgasse o rótulo selecionado pelo representante.

O modelo então comparava o rótulo escolhido com todas as alternativas disponíveis. Quando encontrava uma categoria que parecia um pouco mais precisa, tendia a rejeitar uma seleção que, de outro modo, seria razoável.

Esse comportamento gerava correção excessiva. Um modelo encarregado de encontrar o melhor rótulo pode se comportar de forma diferente de um modelo questionado sobre se um rótulo existente é aceitável. Combinar essas decisões em um único prompt tornou a distinção menos clara.

A DiDi afirma que várias rodadas de ajuste de prompt não resolveram o problema. A equipe concluiu que o modelo havia recebido o ambiente de decisão errado.

O pipeline de intenção reformulado separa verificação de classificação. Durante a verificação, o modelo recebe a conversa e apenas o motivo de contato atual do representante. Ele decide se esse rótulo se encaixa razoavelmente na interação.

A árvore completa de classificação permanece oculta nessa etapa. Esse isolamento de informações impede o modelo de procurar alternativas marginalmente melhores antes de responder à pergunta mais restrita.

Somente uma verificação reprovada abre a etapa de classificação. O modelo então recebe a taxonomia completa, juntamente com o raciocínio da primeira etapa. Ele recomenda outra categoria e fornece uma pontuação de confiança e justificativa.

A DiDi trata os rótulos “Outros” por meio de um processo separado de três níveis. Primeiro, o sistema procura uma correspondência adequada entre categorias irmãs. Em seguida, ele pesquisa toda a árvore se a ramificação local não oferecer resposta.

Se nenhuma das buscas produzir uma categoria apropriada, o pipeline identifica uma possível lacuna na taxonomia. Ele pode então sugerir que os operadores adicionem um rótulo, em vez de forçar a conversa para uma categoria existente inadequada.

Segundo a DiDi, esse design de dois níveis elevou a precisão da verificação de intenção de 38% para 86%. Isso representa um aumento de 48 pontos percentuais, com base na validação em produção informada pela empresa.

O mecanismo oferece uma lição prática para equipes de IA empresarial. Mais contexto não é automaticamente um contexto melhor. Opções adicionais podem alterar a tarefa que o modelo aparentemente precisa resolver.

Isso importa porque muitos prompts empresariais combinam diversas decisões em nome da eficiência. Um único pedido pode solicitar que um modelo classifique uma conversa, justifique o resultado, verifique a conformidade com políticas, resuma o caso e recomende uma ação.

Cada objetivo adicional cria outra oportunidade para que instruções e evidências interfiram umas nas outras. Também torna a análise de falhas mais difícil, pois os desenvolvedores não conseguem identificar facilmente qual parte do contexto alterou a resposta.

Em vez disso, a abordagem da DiDi trata o contexto como parte da arquitetura da aplicação. A equipe decide quais informações se tornam visíveis em cada ponto de decisão, assim como o software convencional controla o acesso a variáveis e estados.

Esse design também produz limites de falha mais claros. Um resultado de verificação questionável pertence à primeira etapa. Um rótulo substituto ruim pertence à segunda. Uma categoria ausente pertence à governança da taxonomia.

O resultado não é uma alegação universal de que sistemas em múltiplas etapas sempre superam prompts únicos. Cada etapa adicionada cria latência, complexidade operacional e mais um componente a monitorar.

A DiDi não publicou tamanho da amostra, distribuição de classes, intervalos de confiança ou desempenho por idioma e linha de negócio. Essas omissões limitam comparações com outros sistemas de QA para contact centers.

Ainda assim, a mudança relatada desafia um hábito comum nas empresas. As equipes frequentemente respondem a um comportamento decepcionante do modelo expandindo instruções ou trocando modelos fundacionais. A DiDi mudou o fluxo de informações.

Essa é uma forma mais profunda de engenharia de prompt. Ela transfere a responsabilidade de uma redação engenhosa para o design do sistema, as definições de dados e os limites explícitos de decisão.

Um Sistema Próprio Coloca a IA Terceirizada Sob Pressão

O desafio mais forte da DiDi aos fornecedores terceirizados de QA não é a alegação de precisão do modelo. É o argumento de que a lógica de julgamento se tornou infraestrutura estratégica.

Uma plataforma terceirizada pode reduzir o trabalho de implementação. Ela pode reunir transcrição, avaliação, dashboards e fluxos de trabalho em um único produto gerenciado. Os compradores evitam manter cada componente por conta própria.

No entanto, essa conveniência se torna uma restrição quando o fornecedor não revela como chegou a um julgamento. A DiDi afirma que sua solução anterior tomava decisões de QA sem uma trilha de auditoria suficiente.

A limitação se tornou mais séria à medida que os padrões mudaram. O suporte em espanhol para transporte por aplicativo não usa necessariamente os mesmos critérios que o suporte em português para serviços financeiros. Novas políticas criam outras combinações.

Uma implementação controlada pelo fornecedor pode exigir alterações personalizadas, retreinamento ou atualizações de produto antes que esses padrões cheguem à produção. Nesse intervalo, regras antigas e novas podem coexistir.

A DiDi transferiu as definições de políticas para uma configuração externa. O pipeline de avaliação usa um modelo de prompt e, em seguida, insere o idioma, a linha de negócio, a definição do critério, a regra de aprovação e a regra de reprovação para cada ticket.

Adicionar outro critério não exige reescrever cada prompt específico por idioma. Os operadores atualizam a configuração, e a aplicação monta o contexto necessário ao receber uma conversa.

O pipeline avalia diversos itens de conformidade em uma única chamada ao modelo. Ele também retorna insights comerciais estruturados, incluindo métricas relacionadas à resolução de problemas e à satisfação do cliente.

O Amazon Bedrock Tool Use restringe a resposta a uma estrutura JSON definida. Cada item de pontuação contém um julgamento e sua justificativa correspondente. A capacidade de uso de ferramentas permite que as aplicações descrevam a entrada esperada da ferramenta e processem os dados estruturados resultantes.

A saída estruturada resolve apenas o problema do formato da resposta. Um JSON válido não garante que a pontuação subjacente esteja correta. Por isso, a DiDi adiciona verificações determinísticas após a geração.

Por exemplo, o modelo pode identificar possíveis erros de ortografia. O código da aplicação então conta apenas os erros nas mensagens do representante e aplica o limite definido ao número verificado.

O sistema também calcula em código os tempos de espera por resposta. Ele insere esses valores no prompt, em vez de pedir ao modelo que os deduza a partir de carimbos de data e hora.

Esse padrão híbrido atribui julgamentos semânticos ao modelo de linguagem e fatos calculáveis ao software convencional. Ele evita usar geração probabilística quando um cálculo direto pode fornecer uma resposta reproduzível.

Essa distinção é central para a abordagem de sistema próprio. A DiDi pode inspecionar quais decisões pertencem ao modelo, quais pertencem ao código e quais dependem da configuração comercial.

A arquitetura também usa o Amazon Bedrock porque o serviço expõe vários modelos fundacionais por meio de uma interface comum. A DiDi afirma que a escolha do modelo pode mudar sem reconstruir cada pipeline em torno de outra integração específica de fornecedor.

A portabilidade entre modelos ainda tem limites. Modelos diferentes interpretam prompts e esquemas de maneiras distintas, portanto mudar de modelo exige uma nova avaliação. Uma API comum reduz parte do trabalho de integração, mas não torna os comportamentos intercambiáveis.

A segurança cria outro ponto de pressão. As conversas com clientes podem conter nomes, informações de contato, dados financeiros, dados de localização e reclamações sensíveis. Transferir esses registros para um fluxo de trabalho de IA amplia o sistema que precisa ser governado.

A DiDi afirma que a implementação usa endpoints de VPC por meio do AWS PrivateLink, criptografia e controles granulares de Identity and Access Management. A AWS documenta que uma conexão privada pode acessar o Bedrock sem um gateway de internet ou endereço IP público.

O sistema também aplica Amazon Bedrock Guardrails antes da inferência do modelo. Ele mascara informações de identificação pessoal e usa verificações de embasamento contextual para sinalizar respostas sem suporte suficiente.

A AWS descreve Guardrails como políticas que avaliam prompts e respostas em áreas que incluem informações sensíveis, tópicos proibidos e conteúdo indesejado. Seus controles de guardrail podem bloquear ou mascarar conteúdo de acordo com a política configurada.

Essas medidas não eliminam o trabalho de governança. A DiDi ainda precisa definir regras de acesso, retenção, escalonamento, revisão e tratamento regional dos dados de clientes.

O mesmo ônus se aplica à lógica de negócios. Ter um sistema transparente significa manter suas taxonomias, critérios de avaliação, conjuntos de validação e processo de monitoramento. A empresa trocou a opacidade do fornecedor pela responsabilidade interna.

Assim, fornecedores terceirizados sofrem pressão de dois lados. Eles precisam igualar a conveniência de um produto gerenciado e, ao mesmo tempo, expor evidências, configurabilidade e controle suficientes para que clientes corporativos confiem em julgamentos consequentes.

A resposta não precisa ser a divulgação integral do código. Os fornecedores podem oferecer rastros de decisão, regras versionadas, ferramentas de avaliação, resultados exportáveis e uma separação mais clara entre a saída do modelo e verificações determinísticas.

O caso da DiDi sugere que um painel simples de precisão já não é suficiente. Os compradores precisam cada vez mais saber qual modelo, versão de prompt, definição de política e regra de pós-processamento produziu cada pontuação.

Essa exigência transforma a observabilidade em um recurso de produto. Ela também torna a propriedade interna mais atraente para empresas com capacidade de engenharia suficiente e operações adequadamente especializadas.

O Que os Números de Precisão Não Mostram

Os ganhos relatados são relevantes, mas as evidências públicas não permitem estabelecer como o sistema funciona em todos os mercados, idiomas, categorias ou políticas em mudança.

Os índices de intenção de 38% e 86% vêm da validação em produção da DiDi. O relato da AWS não informa quantas conversas foram testadas nem como os avaliadores definiram um resultado correto.

Também não apresenta a precisão em espanhol em comparação ao português. O desempenho pode variar entre sotaques, vocabulário regional, canais de atendimento, linhas de negócio e profundidade de classificação.

O equilíbrio entre classes também importa. Um conjunto de dados dominado por dúvidas comuns sobre transporte por aplicativo pode produzir uma pontuação geral forte, ao mesmo tempo que oculta resultados fracos para casos menos frequentes de serviços financeiros.

A mesma cautela se aplica às pontuações de conformidade acima de 90%. O material publicado não informa quantos critérios foram incluídos, se cada critério recebeu o mesmo peso ou como os humanos resolveram divergências.

A precisão também pode ocultar custos de erro diferentes. Uma falsa violação de ortografia é inconveniente, enquanto uma avaliação incorreta relacionada à conduta regulamentada em serviços financeiros pode ter consequências mais graves.

Por isso, uma avaliação em produção deve acompanhar precisão e recall para critérios individuais, e não apenas uma média única. Ela também deve monitorar divergências entre revisores humanos e o sistema automatizado.

Rastros de raciocínio ajudam os revisores a investigar decisões, mas não são prova. Um modelo de linguagem pode produzir uma explicação plausível para uma resposta errada.

A camada de validação determinística reduz esse risco para fatos mensuráveis. Ela não pode transformar todo julgamento de política em um cálculo. Tom, qualidade da resolução, empatia e adequação contextual ainda exigem interpretação.

Os Guardrails introduzem outra limitação. Eles podem filtrar informações sensíveis e testar o embasamento, mas a própria AWS recomenda validação contínua à medida que as salvaguardas subjacentes mudam. Um controle configurado não deve ser tratado como uma garantia permanente.

A supervisão humana continua necessária, especialmente para pontuações contestadas e critérios de maior risco. As equipes de revisão precisam de um caminho de recurso que possa corrigir tanto a decisão individual quanto a regra subjacente.

O relato público também carece de métricas operacionais. Ele não informa latência do modelo, custo de processamento, taxa de substituição manual, carga de trabalho dos revisores ou a porcentagem de conversas que exigem escalonamento.

Esses números revelariam se uma precisão melhor do modelo se traduz em operações melhores. Um sistema preciso ainda pode enfrentar dificuldades se responder lentamente demais, exigir correções manuais frequentes ou se tornar caro em volume total.

A comparação com outras implementações acrescenta uma perspectiva útil. A fornecedora de serviços financeiros Empower descreveu anteriormente outra implementação de QA baseada em Bedrock, que processava milhares de transcrições diariamente.

Seu sistema automatizado de QA combinava Amazon Connect Contact Lens com Bedrock. A Empower afirmou que ampliou a cobertura de QA em vinte vezes e reduziu o tempo de revisão de dias para minutos.

As implementações não são diretamente comparáveis. A Empower usou transcrições previamente redigidas de uma infraestrutura de contact center da AWS, enquanto a DiDi descreveu seu próprio pré-processamento e arquitetura de três pipelines.

Ainda assim, ambos os casos apontam para a mesma direção competitiva. Empresas querem revisar mais conversas, explicar avaliações e reduzir o intervalo entre problemas dos clientes e ações operacionais.

A contribuição distinta da DiDi é seu relato de um projeto que falhou. Inserir toda a taxonomia em uma única chamada produziu uma verificação de intenção fraca, apesar dos ajustes repetidos nos prompts.

Essa falha torna o caso mais útil do que uma simples história de sucesso de fornecedor. Ela mostra que o acesso ao modelo, por si só, não oferece garantia de qualidade confiável.

A incerteza restante diz respeito à manutenção. As taxonomias mudam, o comportamento dos clientes se altera e a linguagem das políticas evolui. Os provedores de modelos também atualizam versões disponíveis e recursos de suporte.

A DiDi precisará de conjuntos de avaliação versionados que preservem exemplos representativos de cada idioma, canal, linha de negócio e critério de alto risco. Caso contrário, uma melhoria de configuração em uma área pode reduzir discretamente o desempenho em outra.

Equipes que desenvolvem sistemas semelhantes devem preservar as evidências por trás de cada lançamento. Uma base de conhecimento de engenharia pesquisável pode conectar requisitos, resultados de testes, versões de prompts e revisões de incidentes sem tratar explicações geradas como verdade absoluta.

Essa prática sustenta a verdadeira promessa da transparência. A visibilidade só é útil quando as equipes conseguem reconstruir o que mudou, por que mudou e como a nova versão se comportou.

O Próximo Teste É Saber se a DiDi Pode Ampliar o Controle

Três sinais determinarão se a arquitetura da DiDi se torna um sistema operacional duradouro para QA ou permanece uma implementação bem-sucedida com validação pública limitada.

O primeiro sinal é o desempenho em idiomas e linhas de negócio adicionais. A DiDi afirma que planeja expandir o sistema além de sua cobertura atual.

Essa expansão testará se a configuração dinâmica realmente limita o trabalho de manutenção. Um novo idioma muda mais do que instruções traduzidas. Ele pode introduzir expressões regionais, expectativas culturais, erros de transcrição e requisitos de política diferentes.

Se a precisão permanecer estável em novas implementações, o resultado reforçará a tese da DiDi sobre gestão de contexto. Quedas acentuadas sugeririam que os ganhos atuais dependem fortemente do ambiente de validação existente em espanhol e português.

O segundo sinal é a integração entre pipelines. A DiDi planeja conectar de forma mais profunda a verificação de intenção, a pontuação de conformidade e a análise de VOC.

Hoje, cada pipeline tem um propósito distinto. A integração pode criar um ciclo de feedback no qual tendências de reclamações revelam classificações ausentes, falhas repetidas de classificação atualizam a taxonomia e descobertas de conformidade orientam o treinamento.

Ela também pode propagar erros. Um agrupamento defeituoso de problemas pode influenciar mudanças na taxonomia, que então afetam verificações de intenção e relatórios gerenciais.

Portanto, uma integração bem-sucedida exige proveniência. Cada recomendação posterior deve manter links para as conversas, campos extraídos, versão de configuração e saída do modelo que a produziram.

O terceiro sinal são evidências operacionais além da precisão. Divulgações futuras devem incluir taxas de substituição humana, padrões de falsos positivos, latência de processamento, tempo de revisão e desempenho por categoria.

Essas medições mostrariam se o sistema permanece útil após o período inicial de validação. Também ajudariam compradores a comparar arquiteturas de propriedade própria com produtos gerenciados de contact center.

A análise de VOC oferece o teste imediato mais claro. A DiDi descreveu um aumento nas reclamações sobre taxas de cancelamento nos mercados da América Latina. A equipe de operações acionou uma análise que agrupou conversas multilíngues e produziu um relatório estruturado em minutos.

O pipeline começa extraindo campos de cada conversa em paralelo. Esses campos incluem o tipo de problema, sentimento, resultado e possível causa raiz.

Em seguida, um modelo de embeddings mede a similaridade semântica entre rótulos de problemas. Embeddings são representações numéricas que posicionam significados relacionados próximos uns dos outros, permitindo que o sistema una reclamações redigidas de formas diferentes.

Essa etapa usa cálculos de distância e classificações por frequência, em vez de saída generativa. A DiDi afirma que o projeto torna o agrupamento determinístico e reproduzível.

O modelo de linguagem recebe apenas os agrupamentos de alta frequência durante a geração do relatório. Ele cria um resumo executivo, identifica pontos críticos e sugere ações a partir de um conjunto menor e estruturado de evidências.

Esse pipeline volta a aplicar o isolamento de informações. O modelo não recebe milhares de conversas brutas em um único prompt excessivamente grande. Cada etapa restringe as evidências necessárias para a decisão seguinte.

A DiDi afirma que o processo reduziu a minutos um trabalho que antes levava horas. A alegação se tornará mais convincente se relatórios futuros mostrarem se as equipes de operações agiram mais rapidamente ou evitaram danos repetidos aos clientes.

Velocidade, por si só, não é o objetivo. Um relatório rápido com uma causa raiz incorreta pode direcionar recursos para a intervenção errada.

A implementação mais robusta combinará detecção mais rápida com resultados mensuráveis. Eles podem incluir menos contatos repetidos, melhor resolução de problemas, menor reincidência de reclamações ou correção mais rápida de um problema de política.

Para desenvolvedores, a lição imediata é projetar os limites dos modelos antes de refinar os prompts. Defina quais evidências cada chamada precisa, quais saídas exigem um esquema e quais fatos devem ser calculados em código.

Compradores corporativos devem exigir a mesma clareza dos fornecedores. Solicitem regras versionadas, decisões auditáveis, validação por categoria, fluxos de escalonamento e controles de acesso que reflitam a sensibilidade dos dados de conversas.

Profissionais do conhecimento devem se importar porque esse padrão se estende além do atendimento. Qualquer sistema que classifica documentos, avalia trabalho ou resume problemas recorrentes pode falhar quando recebe opções irrelevantes ou combina tarefas incompatíveis.

A garantia de qualidade do contact center da DiDi é, portanto, um teste da capacidade organizacional tanto quanto do desempenho do modelo. A empresa assumiu o controle do contexto, das definições e da validação, em vez de terceirizar toda a camada de julgamento.

Essa responsabilidade produzirá resultados estáveis à medida que idiomas, políticas e modelos mudam? Acompanhe as métricas de expansão, as trilhas de evidências entre pipelines e as taxas de intervenção humana. Esses sinais mostrarão se uma IA empresarial transparente consegue superar a caixa-preta ao longo do tempo.