Agir, confirmar ou parar? Comportamento mais inteligente para assistentes de IA, wearables e robôs — Amit Desai

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Act, Confirm, or Stop? Smarter behavior for AI assistants, wearables & robots — Amit Desai · Canal: AI Engineer · 20:21 · Assistir no YouTube

Tópicos: Agentes de IA, Modelos multimodais, Robótica e sistemas autônomos

Resumo

Amit Desai argumenta que melhorar a satisfação com assistentes de voz não depende apenas de aumentar a precisão: também é possível escolher comportamentos mais adequados quando há incerteza. Ele apresenta uma abordagem que compara o custo para o usuário de agir incorretamente, parar ou pedir confirmação, usando uma função de custo chamada OUCH. Um exemplo de alto-falante inteligente mostra como otimizar os limiares de decisão pode reduzir o custo percebido sem alterar a precisão do sistema. A proposta pode ser adaptada a outras interfaces e se torna especialmente importante quando sistemas de IA executam ações digitais ou físicas.

Pontos-chave

A voz é uma interface natural, mas sujeita a erros cujas consequências podem crescer quando a IA passa a executar ações.
A precisão é apenas uma das maneiras de melhorar a satisfação; outra é escolher entre agir, parar ou confirmar diante da incerteza.
Os resultados indesejados têm custos diferentes para o usuário: tocar a música errada pode ser pior do que pedir que a pessoa repita o pedido.
A abordagem OUCH estima esses custos e otimiza os limiares de decisão para reduzir o custo total da experiência.
No exemplo apresentado, acrescentar comportamentos de parar e confirmar reduz o custo percebido sem mudar a precisão.
Os custos e limiares devem refletir a interface e as consequências de cada ação, como exibir opções na TV ou interromper o estado atual.
Um modelo de decisão em tempo real pode aplicar o mesmo princípio em diferentes dispositivos e situações.
Com assistentes que fazem chamadas, enviam e-mails ou controlam robôs, decisões mais cuidadosas diante da incerteza tornam-se essenciais.

Capítulos

Início	Capítulo	Resumo
00:01	Voz: potencial e riscos	A apresentação introduz o potencial natural da voz e o custo crescente dos erros quando sistemas de IA passam a executar ações.
04:52	Decidir quando parar	O exemplo do alto-falante mostra como atribuir custos diferentes a tocar uma música errada e pedir que o usuário repita o pedido.
11:55	Adicionar a opção de confirmar	O sistema passa a escolher entre agir, parar e confirmar, com a otimização dos limiares baseada nos custos de cada resultado.
16:19	Aplicar a abordagem a outras interfaces	O palestrante explica que os custos podem variar em assistentes de TV e em outras superfícies, embora o princípio permaneça.
18:27	Reduzir o custo da experiência	A conclusão destaca a importância de comportamentos mais inteligentes diante da incerteza em assistentes que realizam ações digitais ou físicas.

Citações

Há duas maneiras de melhorar a satisfação: aumentar a precisão e ajustar uma outra variável, que chamarei de decisão do sistema. — 02:15

Esses resultados não são igualmente ruins do ponto de vista do usuário. — 08:05

O sistema não ficou mais inteligente nesse sentido. Mas, com um comportamento inteligente, conseguimos produzir um assistente mais satisfatório para o usuário. — 11:23

Se você lembrar de uma ou duas palavras desta apresentação, que sejam: minimizar o ouch da experiência. — 19:36

Conceitos e entidades

Amit Desai (pessoa): Especialista em interfaces de voz que apresenta uma abordagem para melhorar a experiência do usuário diante da incerteza.
Voice AI (conceito): Sistemas de inteligência artificial que interagem por voz e podem interpretar pedidos e responder a eles.
Outcome User Cost Heuristic (OUCH) (conceito): Heurística apresentada para estimar o custo de diferentes resultados para o usuário e orientar a escolha do comportamento do sistema.
decision model (conceito): Modelo que escolhe, diante da incerteza, se o sistema deve agir, parar ou pedir confirmação.
embodied AI (conceito): IA incorporada a sistemas capazes de realizar ações físicas, além de fornecer respostas.
Alexa (ferramenta): Assistente de voz usado no exemplo de alto-falante inteligente da apresentação.

Tradução completa (pt-BR)

00:01 [música] Oi, pessoal. Tudo bem? Ei, Patricia, como você está? >> Então, é a última apresentação do dia, vamos fazer valer a pena. Certo. Deixe-me começar falando um pouco sobre mim. Sou especialista em voz e trabalho com IA de voz há muito tempo,

00:35 em diferentes plataformas e dispositivos, tanto na Alexa quanto na Roku, nas minhas próprias startups e, sabe, na loja de aplicativos. Minha perspectiva é um pouco diferente da de muitos outros profissionais de IA de voz. Acho que ela combina uma profunda experiência em interfaces de voz e intuição com novas abordagens técnicas

01:09 que, acredito, podem produzir experiências realmente mágicas. Acho que os dois lados são importantes, e isso é especialmente verdade nesta nova área em que estamos, com tecnologia de ponta, na qual a interface humana está basicamente sendo redefinida. Então, vou começar passando rapidamente pelos primeiros slides e depois chego à premissa. Acho que todo mundo sabe que a voz tem um potencial incrível. Acho que a voz tem poder em todos os lugares. É a interface mais natural. Os seres humanos adoram conversar. E o problema é que existe o outro lado: a

01:43 dor da voz. Então, há o poder e a dor. A voz é propensa a erros. Acho que esses erros vão continuar acontecendo por algum tempo. E acredito que o custo ou as consequências desses erros vão aumentar, especialmente quando passarmos de bots de IA conversacional para IA incorporada, em que, em vez de apenas dar respostas que podem estar erradas, teremos sistemas de IA realizando ações físicas ou digitais. Sabe, se o robô jogar

02:15 seu relógio no lixo, isso é muito pior do que tocar a música errada. Então, acho mesmo que é necessária uma nova abordagem. E aqui está o resumo da premissa que vamos explorar hoje. Há duas maneiras de melhorar a satisfação dos clientes ou usuários com um assistente de IA de voz: aumentar a precisão, algo que as pessoas conhecem — quero dizer, a precisão técnica — e usar outro controle que temos, mas que não estamos usando adequadamente.

02:48 Vou chamar isso de decisão do sistema, que vamos definir. Ela é ortogonal, ou seja, diferente da precisão. Acredito que essa abordagem, que usei em vários ambientes e com a qual tive algum sucesso, é uma área promissora que devemos considerar desenvolver. Deixe-me explicar isso com um exemplo simples de alto-falante inteligente e percorrer essa abordagem passo a passo, mas

03:19 é uma abordagem escalável que, acredito, pode ser aplicada a diferentes plataformas e dispositivos. Vamos começar. Suponha que todos nós estejamos criando um alto-falante inteligente, coincidentemente chamado Alexa, e que a Alexa seja muito simples. Ela só permite que você peça uma música, e ela toca uma canção. E, claro, ela vai tocar a música que você queria ou outra música. Ou vai acertar, ou vai errar. Isso não é muito diferente do que vocês já viram

03:51 por aí. Agora, vamos falar primeiro sobre precisão. Digamos que a definimos assim: pegamos mil pedidos falados, observamos a entrada e a saída, rotulamos os dados e analisamos. Este é o mapa dos mil pontos. Em 79% das vezes, ou seja, em 790 pontos, a música tocada estava correta. Digamos que pessoas tenham anotado os dados: 20%, ou 21%, eram músicas erradas. Essa é a precisão. Agora, como

04:22 eu disse, o primeiro controle é dedicar bastante tempo a melhorar a precisão, ponto percentual por ponto percentual, em qualquer camada da pilha. Se for um sistema em cascata, talvez haja uma camada de palavra de ativação, uma camada de reconhecimento automático de fala (ASR) e uma camada de NLU, que pode incluir classificação de intenção e extração de entidades, além de muitas outras camadas, VAD etc. Qualquer uma delas pode contribuir para os erros. Então, podemos dedicar tempo e talvez reduzir esses 210 erros para um número menor. Acho que essa é uma área conhecida que estamos abordando, mas o segundo controle, sobre o qual eu estava falando e que vamos explorar aqui, é manter a precisão exatamente igual. Então, 79%: o que poderíamos fazer em situações de incerteza para aumentar a satisfação aparente dos usuários? Acho que podemos fazer muita coisa. Vamos começar pelo sistema original: como eu disse, o usuário diz algo e o sistema toca uma música. Ou é a música certa, ou é a música errada.

04:52 Imediatamente, acho que o bom senso nos diz que poderíamos introduzir pelo menos um comportamento do sistema: parar, ou melhor, rejeitar a hipótese e não fazer nada. Então, agora há mais uma opção: o sistema pode decidir dizer “Desculpe, não entendi” ou “Desculpe, pode repetir?”. O desafio, claro, é saber quando decidir parar — quero dizer, quantitativamente. Aqui está uma maneira de visualizar isso, porque, se não

05:24 fizermos isso, provavelmente vamos recorrer a algum palpite, a uma estimativa grosseira, e vou provar que, se simplesmente fizermos um palpite, acabaremos numa situação pior do que com uma abordagem mais rigorosa. Então, vamos supor que eu peguei aqueles mil pontos de dados, que, como eu disse, foram anotados, e atribuímos uma pontuação de confiança — uma única pontuação — à hipótese gerada pelo sistema, entre zero e um. Digamos que ela esteja razoavelmente calibrada. Isso é uma simplificação, pois, se for um sistema em cascata, haverá várias camadas e várias pontuações de confiança, mas vamos supor isso por enquanto. Opa.

05:55 Então, teremos 790 pontos corretos e 210 errados. Cada um terá uma pontuação de confiança, e vamos representá-los graficamente, mostrando as distribuições. No eixo x, converti os valores de zero a um em porcentagens. A pergunta é: como escolhemos um limite t, de modo que, se o valor estiver à esquerda dele — ou seja, quando o sistema formar uma hipótese, se a pontuação de confiança c for menor que t, ele pare e diga

06:28 “Desculpe”; caso contrário, toque a música. A pergunta é: como escolhemos t? Até agora, tudo o que estou dizendo parece bastante intuitivo, mas é aqui que a intuição vai nos deixar na mão. Talvez digamos algo como: “Certo, não sei, vamos usar 65%”. Parece, sabe, uma sensação instintiva de que está razoavelmente confiante e que provavelmente é aí que devemos agir. Agora é quando começamos a pensar com mais rigor. Qualquer valor de t que escolhermos vai produzir resultados ruins. Ruins em dois aspectos. Um

07:01 deles é obviamente o lado esquerdo: sempre que o sistema para, isso é ruim. O usuário não quer que ele pare. Ele quer ouvir a música. O outro resultado ruim é tocar a música errada, o que também é ruim. Então, esses são dois tipos de resultados ruins. Mas aqui está a parte importante. Agora, detalhei o diagrama de árvore do lado direito. Os resultados ruins não são igualmente ruins. Não são a mesma coisa do ponto de vista do usuário. E, obviamente, vamos

07:33 pensar nisso. Se a música errada tocar — você pediu “Kiss” e começa a tocar “Kiss”, do Chris Brown, em vez da versão do Prince —, esse vai ser o maior custo para o usuário. Estou definindo o custo do ponto de vista do usuário. Primeiro, tenho que ouvir a música e perceber que não é o Prince. Depois, tenho que gritar por cima da Alexa para fazê-la parar. E aí tenho que pedir de novo. Tudo isso dá muito trabalho. Esse é definitivamente um resultado pior

08:05 do que o sistema parar e dizer: “Desculpe, não entendi”. No entanto, devemos ir além e tentar quantificar o quanto um resultado é pior do que outro. Há muitas maneiras de fazer isso, e acho que essa é uma área a ser explorada. Por enquanto, vamos considerar esta heurística: se esse resultado acontecer, quantos segundos a mais serão necessários para o usuário voltar ao sucesso, ou seja, para tocar a música que queria, “Kiss”, do Prince? Vou colocar alguns números aqui. Digamos que, no caso de uma música errada, sejam 10 segundos, se somarmos todo

08:37 o tempo.

09:10 as coisas que consegui fazer. E, se for um caso de “não entendi você”, são 4 segundos, porque esse é o tempo que levaria para você responder, além da latência extra. E é aqui que podemos começar a usar isso. Se voltarmos à nossa curva de distribuição para descobrir onde fica T, basicamente transformamos isso em um problema de minimizar uma função de custo. É uma função de custo para o usuário. Ela é o número de ações erradas, seja lá o que T causar, vezes 10, porque esse foi o custo unitário que atribuímos, mais o número de interrupções vezes quatro, porque

09:45 esse foi o custo unitário que atribuímos. A propósito, uma coisa que eu deveria ter explicado melhor: trabalho com voz, gostamos de linguagem e gostamos de trocadilhos. Então, chamamos tudo isso de heurística de custo do resultado para o usuário. Isso forma a palavra “OUCH”, que é uma expressão de dor. Sim, somos nerds da linguagem. Então, esse tipo de coisa nos diverte. Agora, vamos considerar que a função de custo consiste em minimizar o OUCH. E agora, vamos ver se… vou

10:16 abrir uma ferramenta. Vamos ver se funciona. Com um dos meus assistentes de programação, consegui criar um gráfico interativo no qual plotamos aqueles mil pontos e, à medida que variamos o limiar T, dá para ver que o custo total para o usuário — que é essa função de x vezes y mais a vezes b — realmente muda. Então, no começo, quando dissemos que o sistema estava simplesmente agindo,

10:52 o custo nesses mil pontos era 2.100, ou, dividido por mil, 2,1 pontos de OUCH por turno. Depois, dissemos: “Certo, vamos inserir um comportamento de interrupção” e, meio que no chute, escolhemos 65%. Esse é o limiar que eu quero. Se aumentarmos até 65, sim, fica melhor. Agora são 1.904, ou 1,9 por turno, mas não é o ideal. Acontece que, se de fato pedirmos à IA para resolver o

11:23 problema ao longo dessa curva, o resultado é 43%. Então, vou arrastar agora até 43: esse é, de fato, o ponto ideal de T. Isso minimiza a função de custo. Dá para ver que é o ponto mais baixo deste gráfico aqui embaixo: 1,27. Então, na prática, não mudamos a precisão em nada. O sistema não ficou mais inteligente nesse sentido. Mas, com alguns comportamentos inteligentes do sistema — comportamentos conversacionais, como os chamaríamos —

11:55 e alguma otimização, além de uma função de custo chamada OUCH, produzimos, do ponto de vista do usuário, um assistente mais satisfatório. E isso não é uma conquista trivial. Certo. Agora, deixa eu voltar a isto. [limpa a garganta] Deixa eu ver se consigo fazer isso. Ah, ótimo. Certo, vamos continuar. Vamos continuar adicionando mais um comportamento. Vamos chamá-lo de comportamento de confirmação. Então, havia o comportamento de agir, obviamente, e depois o de interromper,

12:26 e o de confirmar. Confirmar é basicamente o sistema dizer, depois que você fala algo: “Tocar Kiss, do Prince” ou talvez “Tocar Kiss, do Chris Brown”. E o usuário pode confirmar, ou seja, afirmar que está certo, ou corrigir. É um tipo diferente de comportamento e, de novo, é mais ou menos assim que os humanos se comportam. Essa é, obviamente, a inspiração. Agora, se voltarmos ao nosso problema de otimização, temos uma terceira opção, que é confirmar. E isso

12:58 se traduz em dois limiares, dois limiares que dividem a distribuição em três áreas: interromper, confirmar e agir. E agora a pergunta é: onde ficam esses T? E já desistimos de chutar, porque sabemos que isso não funciona. Então, vamos ser muito mais inteligentes, voltar ao conceito de custo do resultado para o usuário e usá-lo para procurar uma otimização nesse gráfico. Então, vamos definir quais são todos os possíveis resultados ruins que T1 e T2

13:32 podem gerar. Ótimo, dá para ver meu cursor. Então, claro, as interrupções continuam sendo ruins. No meio ficam as confirmações. As confirmações são ruins porque atrasam o usuário. Há um resultado de confirmação chamado “confirmar sim”, quando a pessoa simplesmente confirma dizendo “sim”, e outro chamado “não”, quando ela precisa corrigir. E, voltando à nossa fórmula, esses resultados não são igualmente ruins. E, de fato, acho que ninguém

14:06 vai discordar de que, do ponto de vista do usuário, confirmar, simplesmente dizendo “sim”, é obviamente menos doloroso do que dizer “não” e depois ter que repetir o que queria desde o início. Então, atribuí os valores dois e seis. E, de novo, eu disse que era uma heurística. Isso seria aproximadamente o tempo extra que o usuário levaria para chegar à música que quer. Ouvir e depois dizer “sim” leva uns dois segundos. E agora reformulamos a função de custo para esse comportamento acrescentado como esse número

14:40 de resultados ruins do tipo um vezes o custo unitário do tipo ruim, mais resultados ruins do tipo dois vezes o custo unitário do tipo ruim, e assim por diante. E agora tentamos minimizar essa função de custo para o usuário e minimizar o OUCH. Sim, vou continuar com esse trocadilho. Vamos voltar. Este é agora o gráfico interativo, mas com os valores de custo — os custos unitários são 10, 2, 6 e 4 — e vamos simplesmente pedir

15:13 à IA que nos mostre o mapa de calor, já que agora temos duas dimensões. Ele indica que os valores ideais são 41 para T1 e 49 para T2. Se usássemos esses valores, chegaríamos a 1.464. A propósito, qualquer número que eu colocar aqui, digamos que eu ache que uma ação errada custa 20 — é muito irritante e doloroso, e leva bem mais tempo para corrigir quando você ouve uma música errada.

15:44 Isso mudaria todos esses números e o ponto ideal. Então, mais uma vez, a questão é qual é a gravidade relativa desses resultados, além das curvas de distribuição, naturalmente. Vamos voltar aqui. Certo. Vou acelerar um pouco. Vamos voltar aqui. Modo de apresentação. Então, o que mostramos? Com a abordagem super ingênua, o custo é 2,1. Com agir e interromper, 1,9. Depois,

16:19 1,27 e, então, 1,26. Conseguimos uma grande diferença a cada nova camada de sofisticação: acrescentando mais comportamentos, considerando com inteligência o resultado, o custo para o usuário e a otimização. Fizemos uma diferença enorme sem mudar em nada a precisão. Este foi um exemplo super simplificado. Em sistemas reais, obviamente, não haverá um ou dois limiares de decisão offline. Será um decision model aprendido em tempo real. Mas o princípio é o mesmo. E acredito que isso pode ser ampliado para

16:54 todas as interfaces de voz com IA. Obviamente, este é um alto-falante inteligente, mas, em qualquer uma dessas interfaces, você vai encontrar o equivalente. Vamos encontrar as analogias, com algumas diferenças, mas o espírito e, acho, o ganho serão semelhantes. Por exemplo, no espaço dos assistentes de IA para TV, se aplicarmos isso aqui, teremos a mesma coisa quando os usuários expressarem

17:24 intenções. Na TV, por exemplo, “abrir um canal” é um dos pedidos mais comuns, obviamente, em um assistente de voz para TV. Você vai encontrar a mesma coisa, vai usar exatamente a mesma abordagem, mas a diferença talvez esteja na atribuição dos resultados para o usuário, porque a interface e as modalidades são diferentes. Na TV, você tem uma interface multimodal, em que as opções podem ser exibidas. Então, em vez de perguntar por voz “Você quis dizer ABC News Live?”,

17:55 o sistema exibiria opções, e não apenas uma: mostraria “ABC News Live” e outras opções. Essa seria a etapa de confirmação. E, se for visual e você puder usar o controle remoto para selecionar algo, isso será menos incômodo, então você mudaria alguns desses valores. Ou, se abrir o canal tirar você do estado em que está, o custo iria na outra direção: o custo de uma ação errada ficaria bem maior. É o mesmo conceito, mas nestas novas modalidades

18:27 As variáveis podem mudar, os valores podem mudar, os argumentos podem mudar, mas a premissa continua válida. E você pode melhorar a experiência do ponto de vista do usuário, porque, no fim das contas, queremos deixar as pessoas felizes. Você pode deixá-las ainda mais felizes. E, como eu disse na conclusão, isso pode ser aplicado em todas as superfícies. Eu disse logo no começo, só para recapitular, que a voz é ótima quando funciona e ruim quando não funciona. E, à medida que avançamos na IA incorporada, em que esses assistentes de IA

19:01 realizam ações, físicas ou até digitais, como fazer uma ligação ou enviar um e-mail, fica cada vez mais difícil confiar apenas na precisão para melhorar a satisfação do usuário. Acredito que há um segundo botão, um ajuste totalmente diferente, chamado comportamento conversacional mais inteligente diante da incerteza. E, se de fato explorarmos isso, poderemos ajudar bastante esses sistemas de IA a alcançar uma experiência aceitável para o usuário. Caso contrário, acho que isso continuará sendo

19:36 um gargalo. Muitas coisas vão melhorar, mas, se a interface de voz, tal como é vivenciada pelo usuário, não melhorar, ela vai se tornar um ponto de estrangulamento. E, se vocês lembrarem de uma ou duas palavras de toda esta apresentação, que sejam: minimizar o “ai” da experiência. Obrigado. Vou ficar por aqui para responder às perguntas, se vocês tiverem alguma. Muito obrigado. [aplausos]

20:21 [música]

Transcrição original

[00:01] [music] Hi everyone. How’s it going? Hey Patricia, how are you? >> Uh so last presentation of the day, so let’s make it count. Um, all right. Let’s, uh, let me start with a little bit of background on myself. And, um, my background, I’m a voice subject matter expert. I’ve been working

[00:35] in voice AI for a long time across different surfaces, devices, and um, both at Alexa, at at Roku, at my own startups, you know, in the app store. And my perspective is a little different from a lot of other voice AI practitioners. I think it’s a combination of um a deep um voice user interface expertise and intu intuition mixed in with new technical approaches

[01:09] uh that I think can produce really magical experiences. So I think it’s both sides and I think that’s especially true in this new area that we’re in with frontier tech where the human interface is basically being redefined. So let me start with uh I’ll just blast through the first couple of slides then get to the premise. I think everybody knows that voice has incredible potential. There’s the power of voice I think across everywhere. It’s the most natural interface. Humans love talking. And uh the problem is the other half is the

[01:43] pain of voice. So it’s the power and the pain. Voice is errorprone. And I think those errors are going to continue for a while. And I think the cost or consequence of those errors is going to grow, especially as we go fromational AI bots to embodied AI where rather than just giving answers that might be erroneous, we’re going to have AI systems take physical actions or digital actions where, you know, if the robot throws

[02:15] your watch out with the trash, it’s a lot worse than playing the wrong song. So I do think that a new approach is definitely needed and here’s the TLDDR of the premise we’re going to walk through today. Um there are two ways to improve customer or user satisfaction of a voice AI assistant and that is by increasing accuracy which people know about I mean technically accuracy and the other is a different knob that we have that we are not using adequately

[02:48] and I’ll call that a system decision which we will define which is orthogonal which is different from accuracy and I believe This approach which I have used in several different environments and seen some success I think is a promising area that we should consider developing. Um let me walk through this with a simple smart speaker example and we’ll go step by step with this approach but

[03:19] it is a scalable approach that I think uh can apply across different surfaces and devices. So let’s get started. So suppose we all you know are making a smart speaker coincidentally called uh Alexa and Alexa is very simple. It just allows you to you know ask for music and it’ll play a song and of course it will play either the song you wanted or a different song. So it’ll be right or it’ll be wrong. This isn’t that different from what you’ve seen out

[03:51] there. Um now let’s to first talk about accuracy. Accuracy. Let’s say we define it as we you know take a thousand spoken requests. We observe the input and the output. We label it and we look at this. This is the map of a thousand points and 79% of the time 790 dots here were actually the correct song. This is let’s say human annotated 20% 21% wrong song. So that’s the accuracy. Now, like I

[04:22] said, knob one is to spend a lot of time working on improving the accuracy, you know, um, percentage point by percentage point at any layer in the stack. There’s, if it’s a cascaded system, you know, there’s a perhaps a wakeword layer and a speech ASR layer and a NLU layer which might have intent classification, entity extraction, a lot of different layers, VAD, etc. And any of those can contribute to errors. So we spent time we might be able to reduce that 210 to a

[04:52] smaller number that is I think a known area that we’re tackling but I think knob 2 which is what I was talking about is what we’ll go through here which is keeping the accuracy exactly the same. So 79% what could we do in conditions of uncertainty to improve user satisfaction apparent and I I think we can do a lot. So let’s start first with the original system is just acting like I said user says something system plays a song it’s either the right song or the wrong song

[05:24] immediately I think just common sense tells us that we could introduce at least one system behavior to stop or rather to reject the hypothesis and do nothing. So uh there is now one more option to decide the system may decide and say sorry I didn’t get that or sorry could you repeat that? Uh the challenge of course is how how when do we decide to stop and I mean quantitatively. Um here’s one approach to kind of visualizing this because if we don’t

[05:55] we’ll just take probably some swag like some guesstimate and I’ll prove that if we just took a guesstimate we would end up with a worse situation than a more rigorous approach. So let’s just assume I took those thousand data points and like I said they’ve been annotated and we assign a confidence score a single confidence score to the hypothesis that was generated by the system you know between zero and one and let’s say it’s reasonably calibrated. This is a simplification of if it’s a cascaded system there are multiple layers and multiple you know confidence scores but let’s just assume that for now. Whoops.

[06:28] So we’re going to have 790 points 200 that are correct 210 wrong. Each one has a confidence score and we’re going to plot it, you know, plot the distributions. Uh on the x-axis, I’ve just converted from 0ero to one to percentages. And the question is how do we choose a threshold t such that whatever that percentage is um to the left of it meaning if when the system um forms a hypothesis if the confidence score c is less than that t stop and say

[07:01] sorry otherwise play question is how do we choose a t so far everything I’m saying is fairly common sensical but this is where um intuition will fail us we might say something like okay I don’t know let’s do 65%. It seems you know gut feeling like okay it’s kind of confident that’s probably when we should speak. Um now here’s where we start coming out with some sophistication. Any tea we choose is producing bad outcomes. Bad in the in two fields. One

[07:33] is obviously on the left side anytime you stop it’s bad. The user doesn’t want it to stop. He wants to they want to hear their song. The other bad is if you do play a wrong song, of course that’s bad as well. So these are two two kinds of bad outcomes. But here’s the important part. Now I’ve like elaborated on the um tree diagram on the right hand side. The bad outcomes are not equally bad. They’re not the same thing from a user perspective. And obviously let’s

[08:05] let’s think about it. If the wrong song plays, you said play kiss and it starts playing kiss by Chris Brown instead of the one by Prince. That’s going to be um the highest user cost. Now I’m defining user cost from the user’s perspective. First I have to like hear music and realize that is not Prince. Then I have to shout over my Alexa and um you know get it to stop and then I have to re-request. All of that is a lot of effort. that is definitely a worse

[08:37] outcome than the system stopping and saying sorry I didn’t understand that however we should go further and try to quantify that relative badness and there many ways to do it and I think this is an area to be explored for now let’s just consider this a heristic of if that outcome happens how many more seconds additional seconds will it take for the user to get back to success which is to play the song they wanted kiss by Prince and I’m I just put down some numbers here. Let’s say in the case of a bad song, it’s 10 seconds if you add up all

[09:10] the things I got to do. And if it’s a I didn’t understand you, it’s 4 seconds because that’s how long it would take you to respe and and the extra latency. And now here’s where we can start utilizing that. If we go back to our distribution curve on trying to find out where is T. Now we’ve basically turned this into a problem of minimizing a cost function. It’s a user cost function. It is the number of bad acts wherever that whatever the t causes times 10 because that was a unit cost we gave plus the number of stops times four because

[09:45] that’s the the unit cost we gave. By the way, one thing I should have elaborated because I work in voice and we like language and we like puns. So this whole thing is called an outcome user cost heruristic. So that spells the word ouch and that is some expression of pain. Yes, we are you know language nerds. So these kinds of things amuse us. Um so now let’s consider that is the cost function is to minimize the ouch. And now um that let’s see if uh I’m going to

[10:16] bring up a tool. Let’s see if this works. Where I have actually gotten or with one of my coding assistants gotten uh an interactive um graph where we have actually plotted those thousand points and as we vary the threshold t you can see that the total user cost here which is that function of you know x * y + a * b actually changes. So let’s in the very beginning when we said the system was just playing

[10:52] the the cost across those thousand points was 2100 or divided by a,000 is 2.1 ouch points per turn. Then we said okay let’s insert a stop behavior and let’s like wing it and say 65%. That’s when I want the threshold. If we brought this up to 65 yeah that’s better. Now it’s 1904 or 1.9 per turn, but it’s not optimal. As it turns out, if we do actually um ask for the AI to solve the

[11:23] uh the problem across this curve, it turns out 43%. So I’ll drag it now to 43 is in fact the optimal optimal point of t. This minimizes the cost function. You can see it’s the lowest point on this graph down here to 1 27. So effectively we haven’t changed the accuracy at all. The system is not any smarter in that sense. But with some clever system behavior, conversational

[11:55] behavior is what we’d call it and some optimization and a cost function called ouch. Um we have from the user’s perspective produced a more satisfactory assistant. And this is not a trivial you know accomplishment. Okay. Now, let me go back to this. [clears throat] Let me see if I can get this. Oh, great. Okay, let’s continue this. Let’s continue this with by now adding one more behavior. Let’s call it the confirm behavior. So, there was play obviously, then stop,

[12:26] confirm. Confirm is basically the system after you said something saying uh kiss play kiss by Prince or maybe play kiss by Chris Brown. And uh you know the user can either confirm like affirm it or they can correct it. It is a different kind of behavior and again this is kind of how humans behave. Um that’s obviously the inspiration. Now if we go back to our problem of optimization, we have a third obviously um option which is to confirm. And so this would

[12:58] translate to two thresholds um two thresholds which are separating the distribution into three spaces of stop, confirm and uh act. And the question is now where are these T’s? and we have now given up on guesstimating because we know it doesn’t work. So we’re going to be a lot smarter and go back to the concept of user outcome cost and then you know use it go look for some optimization in that graph. So let’s uh define what are the what are

[13:32] all the possible bad outcomes that t1 and t2 um make for. So good you can see my cursor. So uh of course any stops are still bad. Then in the middle are confirmations. Confirmations are bad because they slow the user down. There is a confirmation outcome called confirm yes where they just affirmed it by saying yeah or no where they had to correct it. And going back to our formula these outcomes are not equally bad. And in fact, nobody will, I think,

[14:06] argue here from a user’s perspective. Affirming, just saying yes is obviously less painful than saying no and then having to restate whatever it is that you wanted in the first place. So now we I’ve assigned values of two or six. And again, I said it was a heristic. This would be roughly the amount of time it would take for the extra for the user to get to the song they want. Saying listening and then saying yes is like two seconds. Um and then now uh we restate the cost function for this you know added behavior as this number

[14:40] of you know bad type one times unit cost bad type plus bad type two times unit cost etc. And now we try to minimize this user cost function and minimize the ouch. Yes, I’m going to keep doing that pun. Um let’s go back. So this is now the interactive graph but with um the cost values the unit costs here 10264 and uh you know we’re just going to ask

[15:13] the AI to tell us here’s the heat map because it’s now two dimensions saying that the optimal values are 41 for the the T1 and 49 for the T2 and if we employed that then we would go to 1464. Uh, by the way, whatever numbers I put in here, like let’s say I thought wrong act was 20. It’s really irritating and painful and takes way longer to actually correct it when you hear a wrong song.

[15:44] That would change you know all these numbers uh and the optim optimal point. So again it is about how what is the relative badness of these outcomes also of course the distribution curves naturally. Uh let’s go back here. Okay. So, um I’m gonna speed up a little bit. Uh let’s go back here. Presentation mode. Okay. So, what have we shown that if we did the super naive approach, it’s 2.1 act and stop 1.9 then

[16:19] 1.27 then 1.26. We are able to bring this with every added layer of sophistication, adding more behaviors, being smart about outcome, uh, user cost and optimizing. Um, we have made a tremendous difference without changing the accuracy at all. Um, this was a super simplified example. In real systems, you’re not going to have obviously some offline decision threshold or two. It’s going to be a real time, you know, learned decision model. But the principle is the same. And I believe this is uh scalable across

[16:54] all voice AI surfaces. Obviously this is a smart speaker but if we go across any of these surfaces you will find the equivalence. If we um we will find the analogies with some differences but the spirit and the I think the the gain will be similar. So just for example in the TV AI assistant space if you employ it here it’s going to you’re going to have the same thing when users express

[17:24] intents like on TV it’s you know open a channel that’s one of the most common obviously um requests on a TV voice assistant same thing you’re going to find you’ll have exactly the same approach but the difference will be maybe in the the assignments of the user outcomes because the UI and the modalities are different when you have a TV you have a multimodal interface where choices can be shown. So instead of you know asking did you mean ABC you know uh

[17:55] news live by speech that you will the system would display choices and not just one it show ABC News live this that would be the confirm step and if it’s visual and you can use your remote control to select something it’s less pain so you would change some of these values or if in fact launching the channel would kick you out of your current state then it would go in the other direction than cost of you know a bad act would go much higher. So it’s the same concept but in this new modalities

[18:27] um variables can change, values can change, arguments can change but the premise still holds and you can improve from the user’s perspective because we’re all about you know making humans happy. Um you can make them happier and this as I said in conclusion can be applied across all surfaces. I did say at the very beginning, just to recap for us, that voice is great when it works, bad when it doesn’t. And as we get into embodied AI, where these AI assistants

[19:01] are taking actions, physical or even digital, like making a phone call or sending an email, it is getting more and more difficult just to rely on accuracy to improve user satisfaction. I believe there’s a whole knob the second knob called smarter conversational behavior under uncertainty and um if we actually exploit that we can uh very much help these AI systems reach a acceptable user experience otherwise I think this will continue to

[19:36] be a bottleneck like a lot of things will get better but if the voice interface as experienced by user does not improve it is going to be a a a choke point. And um if you just remember one word or two words from this whole um presentation, it would be to minimize the ouch of the experience. Um so thank you. I’ll stick around for questions if you guys got any. Thanks a lot. [applause]

[20:21] >> [music]