Um operador 3PL em Fontana, Califórnia, gastou na primavera passada cerca de $45,000 em um assistente de IA que supostamente responderia «todas as perguntas de SOP no chão de fábrica». A demo foi impecável. O relatório do piloto do fornecedor alardeava 94% de satisfação. Trinta dias após o go-live, o gerente de segurança puxou os logs e descobriu que quase uma em cada quatro respostas continha algo errado — uma altura de empilhamento errada, um limiar de temperatura errado, uma regra de embalagem de cliente errada. O assistente entregava cada uma com total confiança e uma citação perfeitamente formatada.
Esta é a parte que os fornecedores não colocam no deck: um assistente de armazém com recuperação aumentada não falha porque o modelo de linguagem é burro. Falha porque a engenharia em volta nunca foi terminada. Já vi quatro dessas implantações desandarem no último ano, e o padrão de falha é tão consistente que praticamente consigo recitá-lo.
De onde vêm de fato as respostas erradas
O primeiro ponto de falha é a recuperação (retrieval), e responde pela maior parte do dano que já vi. Documentos de armazém — SOPs, manuais de equipamentos, SLAs de clientes — normalmente são picados em pedaços de tamanho fixo, 500 tokens cada, e embutidos num repositório vetorial. Um operador pergunta se as empilhadeiras podem carregar dentro da área de cadeia do frio. O sistema recupera uma política de sala de baterias de três anos atrás, escrita para um galpão de carga externo, e monta uma resposta que soa autorizada e é completamente inaplicável. O pedaço perdeu o contexto; o embedding só entendeu a similaridade superficial.
O segundo ponto de falha é o versionamento de documentos, e é mais traiçoeiro. Documentos de armazém mudam mais rápido do que a TI espera. Um SOP vai de v2 para v3 porque o gerente do cliente disse e alguém colou um formulário novo na parede. O PDF antigo fica na base de conhecimento sem sinalizador de «substituído» e sem filtro de data de vigência. O modelo não sabe qual versão está vigente — apenas monta os fragmentos com maior pontuação. Em Fontana, o assistente uma vez citou «SOP v3.2, Seção 4» para um limite de empilhamento. O armazém nunca tinha produzido um v3.2. O modelo tinha fundido uma seção de v2 com uma de v3 e inventado o número da versão. Alucinações costumam ser construídas a partir de fragmentos recuperados meio verdadeiros, não do nada.
O terceiro ponto de falha é o limite do conhecimento. Trabalhadores fazem perguntas fora da base de conhecimento: mudanças no salário mínimo local, tarifas da agência de temporários ao lado, políticas de RH. Um assistente bem projetado deveria dizer «isso eu não tenho — pergunta ao seu supervisor». Mas um modelo com configuração padrão odeia dizer que não sabe. Ele fabrica, e os números fabricados vêm com casas decimais, o que os faz parecer críveis.
O conjunto golden: 50 a 100 perguntas antes de falar de modelos
Meu conselho aos operadores agora é direto: não comecem pela seleção do modelo. Comecem por um conjunto de avaliação.
A receita é simples. Peçam aos líderes de turno e ao gerente de segurança para cada um listar 20 perguntas do tipo «errar isso machuca alguém»: limites de empilhamento, folgas de corredores, distâncias de segregação de materiais perigosos, limiares de alarme de cadeia do frio, regras de embalagem específicas de cada cliente. Depois puxem três meses de perguntas reais que os funcionários fizeram e peguem as 30 a 50 mais frequentes. Isso dá 50 a 100 itens, cada um pareado com uma «resposta golden» assinada por um operador sênior e por quem detém o compliance — até o número da cláusula e a versão vigente.
O conjunto faz três trabalhos. Primeiro, rode-o antes do go-live; se a precisão de correspondência exata contra as respostas golden estiver abaixo de 85%, não lancem. Segundo, rode-o de novo após cada troca de modelo, mudança de recuperação ou atualização de documentos, para que consertar uma coisa não quebre outra. Terceiro — e este é o que importa — escreva-o no contrato com o fornecedor: precisão de aceitação, taxa de recusa e cobertura de citações, atrelados aos termos de pagamento.
O contrato mais sério que já vi especificava um piloto de 30 dias com pelo menos 50 perguntas por dia, e a aceitação exigia ≥90% de precisão no conjunto golden com taxa de recusa entre 5% e 15%. Reparem no piso das recusas. Um assistente que nunca diz «não sei» é muito mais perigoso do que um que declina de vez em quando. Uma recusa é um sinal de saúde, não uma falha.
Consertem a recuperação antes de culpar o modelo
Quando as respostas saem erradas, a maioria das equipes busca um modelo maior. Na minha experiência, oito em cada dez vezes o problema é a recuperação, e o modelo leva a culpa.
Mudem primeiro a estratégia de fragmentação. Parem de cortar por contagens fixas de tokens. Fragmentem pela estrutura natural do documento: SOPs por seção e cláusula, manuais de equipamentos por procedimento completo de solução de problemas. Uma cláusula cortada ao meio não pode ser salva por um embedding melhor. Na prática, a fragmentação semântica é o ganho de precisão mais barato disponível — quase não custa nada.
Depois adicionem filtragem por metadados. Etiquetem cada documento na ingestão: versão, data de vigência, site aplicável, zona aplicável. Filtrem para a última versão vigente antes do pareamento semântico. Não apaguem as versões antigas — auditorias podem precisar delas — mas marquem-nas como substituídas e excluam-nas da recuperação por padrão. O site de Fontana fez exatamente essa mudança e os números de versão fantasma praticamente desapareceram.
Mais um movimento subestimado: deem às perguntas de alta frequência e alto risco uma via rápida determinística. Alturas de empilhamento, larguras de corredor, limiares de alarme — há talvez duas ou três dúzias dessas. Coloquem-nas em pares de P&R de correspondência exata que contornam completamente a recuperação vetorial. Isso não é trapaça. É tirar as perguntas mais perigosas de um sistema probabilístico e passá-las para um determinístico.
Três regras que forçam o assistente a admitir incerteza
Mesmo com a recuperação consertada, os modelos ainda confabulam de vez em quando. Alucinações não se governam com esperança. Governam-se com três regras duras.
Primeiro, citações obrigatórias. Toda resposta deve nomear seu documento-fonte e sua cláusula, e o link precisa levar ao texto real. Na avaliação, uma resposta sem citação verificável é pontuada como errada, ponto final. Essa única regra força os fornecedores a acertar a recuperação, porque não sobra nada para fabricar.
Segundo, recusar abaixo de um limiar de confiança. Se os documentos recuperados pontuarem abaixo de um corte de relevância, ou se múltiplas fontes se contradisserem, o assistente responde «sem resposta clara na base de conhecimento — escalado para seu líder de turno» e encaminha a pergunta para um humano. Definam o limiar com conservadorismo. No chão do armazém, o custo de uma resposta errada é sempre maior que o custo de resposta nenhuma.
Terceiro, verificações humanas pontuais com calendário. Primeiro mês após o go-live: 20 P&Rs reais aleatórias verificadas por um humano por dia. Segundo mês: 30 por semana. Após três meses estáveis: 10 por semana. Cada erro volta para o pipeline — problema de recuperação, consertar fragmentação e etiquetas; problema de documento, atualizar a base de conhecimento; problema de limite, adicionar uma regra de recusa. Mantenham a trilha de auditoria. Vocês vão querer tê-la quando a segurança perguntar.
Os armazéns que não deveriam construir isso
Agora a parte que irrita os fornecedores. Nem todo armazém deveria construir um assistente de P&R com IA.
Uma operação com menos de 30 pessoas não deveria. Os SOPs cabem numa pasta, os veteranos estão no chão, e gritar uma pergunta do outro lado do corredor é mais rápido e grátis. Um armazém cujos SOPs são uma bagunça também não — documentos errados, vencidos, contraditórios alimentados à IA só produzem confusão confiante em velocidade de máquina. E um site com menos de 20 perguntas por dia não deveria se dar ao trabalho: o labor de manter o conjunto de avaliação, as verificações pontuais e a governança documental vai custar mais do que o tempo de P&R economizado.
O encaixe é real para sites com mais de 100 pessoas, múltiplos turnos e SOPs sensivelmente diferentes por cliente — alta rotatividade, turnos noturnos sem ninguém a quem perguntar, pilhas de requisitos específicos de clientes. Mesmo aí, posicionem com honestidade: é um veterano digital sempre disponível para consultar, não um gerente que julga por vocês.
Antes de assinar qualquer coisa, respondam a uma pergunta: seus operadores sêniores conseguem achar a última versão vigente do SOP sem abrir um laptop? Se não conseguem, a IA também não vai conseguir. Ela só vai dar a resposta errada mais rápido — com uma citação que parece real.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
