O que um humano deve confirmar em um pedido por IA de voz?

Em um exemplo de pedido de voz sintético, um token de fala repetido se transforma em três hambúrgueres. O sistema oferece uma correção plausível: alterar a quantidade para um. Para uma equipe de produto, a questão difícil é o que acontece entre essa sugestão e a permissão para enviar o pedido. Uma substituição aparentemente útil não estabeleceu o que o cliente queria.

Divulgação: Os exemplos abaixo são pedidos sintéticos no Drive-Thru Order Firewall da Veriprajna, que valida saídas estruturadas de fornecedores antes de uma tela de cozinha simulada. Ele não reconhece áudio real nem envia pedidos ao sistema de ponto de venda de um restaurante.

Quero que a confirmação humana resolva uma incerteza específica. Isso exige separar três julgamentos: o que o cliente pretendia, se esse pedido é permitido pelas políticas do restaurante e se o pedido exato proposto atende às verificações. Combinar esses julgamentos em um único botão de aprovação torna difícil saber o que uma aprovação significa.

Uma correção é uma hipótese sobre a intenção

O cenário de teste com token repetido contém uma transcrição hesitante, três tokens brutos idênticos e uma quantidade de três hambúrgueres. Sua pontuação de confiança fornecida é de 0.71, abaixo do limite de revisão configurado de 0.85. As regras de repetição e de baixa confiança, portanto, colocam o pedido em HOLD. A regra de repetição sugere um hambúrguer.

Um é um candidato razoável para colocar diante de um operador. Não é prova da quantidade pretendida. O token repetido pode explicar a saída estruturada, mas uma regra que detecta repetição não pode perguntar ao cliente o que ele quis dizer. Substituir automaticamente três por um trocaria uma interpretação questionável por uma interpretação não confirmada.

Rejeitar o pedido tem um custo diferente. Trata uma interpretação que precisa de esclarecimento como se nenhum pedido aceitável pudesse ser recuperado. Prefiro uma retenção (hold) neste ponto porque ela preserva as evidências originais e deixa a quantidade pretendida em aberto. Em um design de produção, a confirmação deve perguntar sobre a quantidade em si, em vez de pedir a um operador para endossar a confiança geral do sistema.

Essa é uma posição de design, não um fluxo de trabalho concluído neste aplicativo. Os botões Approve Correction e Escalate da demonstração alteram seus rótulos e se desativam. Eles não reenviem, não liberam, não registram uma ação humana nem alteram o recibo. Uma equipe de produção ainda precisaria construir a conversa e a mudança de estado que tornam sua resposta consequente.

Uma solicitação incomum pode ser compreendida com precisão

A interpretação é apenas um dos motivos para pausar. Outro cenário sintético contém 18,000 copos de água com uma pontuação de confiança fornecida de 0.97 e um preço de cardápio zero para o cliente. A quantidade excede o limite configurado de água de oito, de modo que o gate o retém. Nem a alta pontuação de entrada nem o preço zero respondem se essa quantidade pode prosseguir. A pontuação é uma entrada do cenário, não uma probabilidade calibrada de permissão.

Uma quantidade extrema torna essa distinção fácil de ver. A decisão de produto mais difícil é uma quantidade incomum que o cliente realmente deseja. Considere um pedido hipotético em grupo que exceda o limite automático comum de um restaurante. Se o cliente confirmar o número, a interpretação pode estar resolvida enquanto a permissão permanece pendente. Reduzi-la ao limite habitual alteraria a solicitação. Rejeitá-la sumariamente poderia descartar uma demanda legítima.

Prefiro usar um limite de exceção para acionar a revisão quando a política permitir uma exceção. O operador precisa então decidir se o restaurante pode aceitar o pedido confirmado, possivelmente por uma rota autorizada separadamente. Um limite projetado para restringir o envio automático não deve se tornar discretamente uma regra que reescreve a intenção do cliente.

Isso custa atenção. Um limite automático mais flexível permite a passagem de pedidos mais incomuns; um mais rígido gera mais trabalho de revisão. A demonstração não pode escolher esse equilíbrio para um restaurante. Seus limites vêm de um histórico inicial de pedidos sintéticos, e uma distribuição descreve o que apareceu nesse histórico. Ela não estabelece a capacidade real de um local nem a frequência com que um pedido legítimo em grupo ocorrerá. Antes de adotar tal política, uma equipe precisaria de evidências sobre exceções aceitáveis e o ônus prático de confirmá-las.

A confirmação deve se aplicar exatamente ao próximo pedido

Mesmo uma correção confirmada pode continuar inválida. O cenário de alto volume começa com 40 batatas fritas e 40 refrigerantes. A regra de quantidade propõe reduzir as batatas fritas para quatro, mas deixa 40 refrigerantes inalterados. O limite de refrigerantes é seis. Concordar que quatro batatas fritas é a substituição correta deixaria, portanto, outra violação de quantidade no pedido proposto.

É por isso que mantenho confirmação e validação distintas. A confirmação do cliente aborda a intenção. A decisão de exceção de um operador autorizado aborda a política. A verificação do pedido proposto completo aborda se a próxima transação atende às regras aplicáveis. Nenhuma dessas respostas pode ser inferida com segurança a partir das outras.

Para um fluxo de trabalho em produção, eu exigiria que uma proposta confirmada passasse pela validação novamente antes do envio. Se um operador puder anular uma política, essa autoridade deve ser explícita e vinculada à regra e ao pedido específicos aceitos. Uma aprovação genérica não deve apagar falhas não relacionadas. Esses são requisitos para uma implementação futura, não recursos demonstrados pelos controles de correção atuais.

Conselhos podem ajudar sem conceder permissão

A nota explicativa do modelo tem uma função útil, mas mais restrita: pode tornar o motivo de uma retenção mais fácil de ler. Na gravação complementar do fundador, essa nota usa respostas consultivas reais em cache. Não é uma inferência nova a cada repetição. O mecanismo decide primeiro usando regras determinísticas; o texto consultivo subsequente não pode alterar a decisão. A chamada consultiva é síncrona no processamento, portanto, essa separação de autoridade não comprova que o trabalho do modelo não adicione latência à solicitação.

O detalhamento completo da validação de pedidos mostra esse limite e os exemplos sintéticos. Eles apoiam um argumento de design auditável, não evidências de que a política inicial ou o fluxo de trabalho incompleto do operador estejam prontos para implantação.

Aqui está a gravação do fundador sobre o exemplo de revisão de pedidos.

Para mim, a revisão decisiva de produto é acompanhar o pedido proposto até sua próxima ação permitida. Quem confirmou seu significado? Quem pode aceitar uma exceção? O que verificou o resultado completo? Até que essas respostas se refiram exatamente ao mesmo pedido, uma correção tranquilizadora e um rótulo de aprovação deixam a transação inacabada.