A conclusão, logo de cara: as consultas de estoque em linguagem natural funcionam hoje — mas só dentro de uma faixa estreita: um vocabulário controlado mais uma etapa de confirmação. Esperar que o sistema entenda qualquer coisa que você diga de improviso, sempre? Teste primeiro no seu próprio armazém. A maioria das operações que já vi ainda não chegou lá.

Vi esse fracasso exato três vezes. A primeira foi numa 3PL no leste da China, no outono de 2025. Queriam que os supervisores de chão simplesmente "perguntassem" os números de estoque: um supervisor falava num tablet "Quanto estoque disponível temos de produtos 3C na Zona A?" e o sistema respondia na hora. Suave como seda. Na terceira semana, explodiu: prepararam uma remessa promocional com base no número que o sistema deu, faltaram dois pallets e tiveram que correr com transporte expresso. Um único frete rodoviário expresso apagou três meses de economia de mão de obra. A autópsia encontrou dois problemas fatais. Primeiro, não existia nenhuma categoria "produtos 3C" no WMS deles — o modelo a havia alucinado como "eletrônicos de consumo", incluindo capinhas de celular e cabos enquanto deixava de fora metade dos acessórios 3C de verdade. Segundo, o "Modelo A" existia como dois SKUs (variantes vermelha e azul), e o sistema só tinha consultado um. Ele não fazia ideia de que o "Modelo A" era, na gíria daquele armazém, uma família de dois.

Na segunda vez, um armazém de e-commerce acertou. Três frases explicam o porquê: o vocabulário foi definido por pessoas, não adivinhado pelo modelo; cada resposta primeiro dizia "é isso que entendi" e esperava um toque para confirmar; cada número trazia sua fonte. Eles colocaram na lista de permissões as dimensões que podiam ser perguntadas — armazém, zona, categoria, SKU, lote, status de estoque — seis dimensões, com um mapa de sinônimos mantido por pessoas para cada uma. "Produtos 3C" não está na lista? O sistema perguntava de volta: "produtos 3C não é uma categoria pesquisável. Você quis dizer acessórios digitais ou eletrônicos de consumo?" O operador tocava uma vez. Dez segundos. Essa etapa de confirmação parece desajeitada. É o fusível que protege a precisão.

A terceira vez foi mais complicada: um armazém de cosméticos no ano passado, onde cada nome de SKU era um tom — "rosa cereja", "rosa pêssego", "rosa pasta de feijão". O modelo decidiu que os três se pareciam e os fundiu como sinônimos, então perguntar "quanto rosa ainda temos" devolvia o estoque dos três SKUs somado num único número. A contagem cíclica não batia, e a equipe do armazém acabou aos berros com o pessoal de operações de e-commerce. Lição: tons, especificações, versões — coisas que parecem sinônimos, mas jamais podem ser fundidas — precisam de uma bandeira explícita de "não fundir" na tabela de mapeamento. Uma tabela de sinônimos não é caso de "quanto maior, melhor"; uma entrada errada dói mais que uma entrada faltante.

Como a primeira 3PL se recuperou? Três passos. Primeiro, mataram as perguntas de formato livre e mudaram para "escolha as dimensões, depois pergunte", colocando tudo o que é perguntável dentro de uma jaula. Segundo, sentaram dois supervisores veteranos por duas semanas e construíram o mapa de sinônimos até mais de 200 entradas. Os supervisores resmungaram no início, depois descobriram que era três vezes mais rápido que folhear livros de registro, e começaram a usar por conta própria. Terceiro, cada resposta foi obrigada a trazer sua fonte e seu carimbo de tempo. Dois meses depois, as respostas erradas basicamente sumiram — e reparem: o modelo não ficou mais inteligente. A jaula ficou mais apertada.

Por que digo que o gargalo não é o modelo? Aqui está o pipeline, quatro passos, e eu tropecei em cada um deles.

Como as consultas de estoque em linguagem natural realmente funcionam: quatro passos, quatro armadilhas

  1. Reconhecimento de intenção: traduzir "quanto resta" em "consultar estoque disponível". É o que o modelo faz melhor. A menor das suas preocupações.
  2. Mapeamento de entidades: mapear a "Zona A" e os "produtos 3C" para dados mestres reais do WMS. Esta é a zona de desastre. Um produto com três nomes, metade dos seus campos de categoria em branco, códigos de zona antigos e novos misturados — a tabela de mapeamento morre aqui. Uma regra: um modelo só consegue mapear coisas que existem e são únicas. O que não está nos seus dados mestres, ele adivinha. Adivinhações dão errado.
  3. Chamada à API do WMS: transformar o mapeamento numa consulta real contra a API. Isso exige uma API de consulta limpa e somente leitura. Muitos endpoints de consulta de WMS legados foram feitos para relatórios legíveis por pessoas; suas definições de campo não batem com o razão de estoque, então dois números discordam e o operador tem que escolher um.
  4. Validação do resultado: checar a resposta antes de mostrá-la. O armazém de e-commerce que acertou adicionou aqui uma regra dura: cada resposta precisa trazer sua procedência — "Fonte: razão de estoque disponível da Zona A. Filtros: zona = A E categoria = acessórios digitais. Atualizado há 10 minutos." Sem procedência, sem exibição.

Painel de estoque do armazém no chão de fábrica

Checklist pré-piloto para consultas de estoque em linguagem natural

  1. Dados mestres primeiro, três barreiras: deduplicar SKUs, preencher os campos de categoria, unificar os códigos de zona. Pule essas e todo o resto é teatro.
  2. Coloque na lista de permissões as dimensões perguntáveis: comece com três a cinco. Não abra tudo no primeiro dia.
  3. Construa o mapa de sinônimos à mão: sente-se com um supervisor de chão e mapeie cada gíria para um código de sistema, uma a uma. Um dia de trabalho. Vale a pena.
  4. Confirmação é obrigatória: o sistema diz "é isso que entendi" e o usuário confirma antes de o número aparecer. Se isso parecer fricção demais, não lance o recurso.
  5. Somente leitura primeiro: o piloto só consulta. Nunca escreve. Deixar o modelo ajustar saldos ou mudar status de estoque? Vi esse fracasso três vezes. Não quero uma quarta.
  6. Instrumente tudo: registre cada pergunta, a interpretação do sistema, se o usuário a corrigiu e qual foi a correção. Em três meses, esse log é a mina de ouro para melhorar sua tabela de mapeamento.
  7. Defina o plano B da "resposta errada": quando uma consulta dá errado, qual é o processo de correção e quem é o responsável? Acerte as coisas feias antes do go-live, não depois.

Aqui está a parte contraintuitiva: me perguntam "Isso pode chegar a 99% de precisão?" Minha resposta: pergunta errada. O teto da precisão não é definido pelo modelo. É definido pelo quanto seus dados mestres estão limpos. Com dados mestres bagunçados, o modelo é um estagiário que inventa respostas confiantes; com dados mestres limpos, é um veterano que conta rápido. Limpe primeiro os dados mestres, depois falamos de linguagem natural. Isso é um problema de sequenciamento, não de tecnologia.

Voltando à pergunta original: a precisão da consulta de estoque em linguagem natural é boa o suficiente? Não depende do modelo. Depende de três coisas: se seu vocabulário está definido, se a confirmação está implementada e se seus dados mestres estão limpos. As três no lugar — vá em frente. Falta uma — faça a lição de casa primeiro.

Por Lin Xiao, consultor de implementação de WMS

Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.