Singapore Airlines troca chatbot baseado em scripts por LLM e dobra o CSAT

É uma dor conhecida de quem já montou suporte ao cliente: o chatbot baseado em scripts. Cada intenção precisa ser descrita, cada ramificação desenhada com antecedência, e a pessoa escreve algo como "meu voo foi cancelado, e eu tenho transfer e hotel, o que faço?". Em resposta, o bot mostra um menu de cinco itens. A Singapore Airlines passou por isso e reescreveu seu bot Kris com LLM. A companhia divulga números e detalhes de arquitetura dos quais dá para tirar algumas lições.

O que mudou no Kris

No esquema antigo, baseado em dialog-flow, a cobertura de temas dependia de quantos diálogos tinham sido descritos manualmente. Se a intenção necessária não existia, a conversa na maioria das vezes ia para um atendente, embora a questão pudesse ser resolvida por autoatendimento. Escalar um sistema assim é difícil: cada novo tema significa uma nova ramificação.

Após a migração para a API da OpenAI, o bot passou a interpretar sozinho a intenção do cliente em linguagem livre, responde com base em uma base de conhecimento, mantém a conversa sobre vários temas ao mesmo tempo e transfere o chat a um funcionário humano junto com o contexto. Atualmente, o Kris responde a perguntas gerais, trata solicitações especiais, informa sobre interrupções de voos em tempo real e executa parte das transações. Os próximos passos incluem alteração de reservas, operações com bagagem e cenários agênticos mais complexos.

Resultado segundo a companhia: o CSAT dobrou. Separadamente, os atendentes ganharam uma ferramenta de resumo de chamadas, baseada na mesma API, para gastarem menos tempo na análise após a conversa. O tempo médio de tratamento de uma solicitação caiu cerca de 10%.

Flight Recommender: o modelo chama ferramentas, em vez de inventar preços

O segundo produto é o Flight Recommender. O cliente descreve a viagem em linguagem natural, em vez de ficar ajustando filtros de datas e destinos repetidamente. O uso quase triplicou em um ano.

O sistema não funciona na lógica de "o modelo conhece os voos por conta própria". Entre o modelo e o usuário há uma camada de orquestração conectada aos dados de tarifas e disponibilidade de assentos. O modelo interpreta o pedido, chama as ferramentas necessárias e reconta o resultado em linguagem humana. Preços e disponibilidade vêm dos sistemas da companhia, não da memória do modelo.

Em torno disso foram montados mecanismos de proteção: validação de entrada e saída, tratamento de solicitações maliciosas e inadequadas, redução de alucinações, manuseio de dados pessoais e acesso apenas ao contexto necessário para cada pedido. O próximo passo é transformar a busca em um diálogo no qual a ideia possa ser refinada sem recomeçar do zero.

IA em todo o ciclo de desenvolvimento, não só no código

A parte do caso mais aplicável para equipes diz respeito ao desenvolvimento. Os modelos são usados nas etapas de esclarecimento de requisitos, análise de reuniões com stakeholders, redação de especificações, busca de casos-limite, geração de casos de teste, revisão de arquitetura e divisão de tarefas grandes em partes verificáveis.

Exemplo do texto: para uma funcionalidade comercial, a equipe primeiro pediu ao modelo que questionasse as premissas e encontrasse requisitos ambíguos. Só depois disso a IA ajudou a construir opções de design, planos de implementação, testes e código. Nas atividades selecionadas, o ganho de produtividade chegou a 20%. O papel das pessoas passou da produção de artefatos para a definição de tarefas, a revisão e a validação.

Há também a plataforma interna Jarvis, com controle de acesso. Nela, os funcionários trabalham com PDF, Word, Excel e apresentações, e montam seus próprios workflows e pequenas bases de conhecimento. Mais de 60% do pessoal a utiliza mensalmente.

O que considerar ao ler

Este é um caso do site da OpenAI, ou seja, um material com finalidade comercial. A metodologia de medição do CSAT não foi divulgada, e não está claro com o que exatamente se comparou nem em que período. Os números de tempo de tratamento (cerca de 10%) e de desenvolvimento (até 20%) são bem mais modestos que o "dobro" do título. Convém tratá-los como uma referência realista, e não como uma promessa.

Conclusão prática para equipes que constroem suporte ou busca:

• Bots baseados em scripts esbarram na cobertura manual de temas. Um LLM com base de conhecimento remove essa limitação, mas exige uma base de qualidade e uma transferência cuidadosa ao atendente, com contexto.
• Os fatos (preços, disponibilidade, status de voos) devem vir de ferramentas, deixando o modelo para entender o pedido e formular a resposta.
• Guardrails, controle de dados pessoais e revisão humana devem ser incluídos desde o início, e não depois do primeiro incidente.
• Vale implantar a verificação de requisitos e a geração de edge cases antes da geração automática de código: é aí que a equipe da Singapore Airlines descreve o benefício mais evidente.