LLMs no varejo: o “muro” do contexto e como evitar

A maioria dos projetos com LLMs (Large Language Models) no varejo começa com euforia e termina com uma frase desconfortável: “Ele escreve lindo… mas não resolve o meu problema real.” Em dezembro, com picos de atendimento, devoluções e rupturas pós-Black Friday/Natal, essa frustração aparece mais rápido — porque o cliente não espera, e o time de operações também não.

O motivo raramente é “modelo fraco”. O motivo é mais simples (e mais duro): o LLM está isolado do seu negócio. Ele não vê seus pedidos, não lê suas políticas internas atualizadas, não entende o status do estoque em tempo real e, quando falta informação, inventa com confiança.

O caminho prático para sair desse beco não é trocar de modelo toda semana. É fazer engenharia de contexto: construir a arquitetura que conecta o LLM a dados, ferramentas e memória, com higiene e governança. E sim — isso é exatamente o que diferencia uma demo simpática de um sistema que aguenta o tranco no e-commerce.

O “muro” que todo projeto com LLM encontra: a janela de contexto

A janela de contexto é a memória de trabalho do LLM. Tudo o que você envia (perguntas, histórico, trechos de documentos, respostas de APIs) precisa caber ali. Quando lota, algo sai. E, com frequência, sai o que era crucial.

No varejo, o efeito colateral é imediato. Um assistente pode:

• esquecer o CPF/ID do pedido no meio do atendimento;
• confundir política de troca “Natal” com política “padrão”;
• misturar regras de frete por região;
• responder com base em informações antigas quando há uma atualização no mesmo dia.

E aqui vai um ponto que muita equipe aprende na marra: aumentar a janela de contexto não resolve tudo. Contextos enormes podem aumentar confusão, contradições internas e alucinações, porque o modelo se distrai, “enterra” instruções importantes e perde o fio.

Frase para colar na parede do squad: contexto demais não é memória; é ruído.

Engenharia de contexto no e-commerce: o que funciona fora da demo

Engenharia de contexto é o conjunto de decisões que garante que o LLM veja a informação certa, no momento certo, do jeito certo. Em vez de tentar “convencer” o modelo com prompts cada vez mais longos, você cria pontes para o mundo real.

No contexto da nossa série IA no Comércio Varejista e E-commerce, isso significa ligar o assistente a:

• catálogo e preços (com regras de promoção por canal);
• pedidos e logística (status, transportadora, tracking, SLA);
• estoque (lojas, CD, estoque disponível x reservado);
• políticas (trocas/devoluções, antifraude, LGPD);
• base de conhecimento (FAQ, scripts, manuais internos);
• ferramentas de ação (abrir chamado, emitir segunda via, acionar estorno).

O resultado esperado não é “responder bonito”. É responder com lastro — e agir quando necessário.

O erro clássico: “retrieve → generate” como receita única

RAG (Retrieval Augmented Generation) é útil, mas o pipeline fixo “buscar documentos e responder” quebra quando o cenário exige julgamento:

• o cliente traz informações incompletas;
• há exceções de política por período (como dezembro);
• o pedido tem múltiplas entregas;
• o mesmo termo tem significados diferentes (“troca” pode ser devolução, substituição, garantia).

Projetos maduros deixam de ser uma esteira linear e viram um sistema dinâmico, com decisões a cada etapa.

Agentes: o maestro que organiza dados, ferramentas e decisões

Agentes são a camada de orquestração. Em vez de seguir um roteiro rígido, um agente decide o próximo passo com base no que já sabe e no que ainda precisa descobrir.

Na prática, um agente bem desenhado faz quatro coisas que mudam o jogo no varejo:

1. Decide o fluxo de informação: “Preciso do ID do pedido antes de consultar o status.”
2. Mantém estado: guarda variáveis do atendimento (pedido, canal, prazo prometido, motivo de contato).
3. Se adapta quando algo falha: se o tracking não responde, tenta outra fonte ou abre exceção.
4. Usa ferramentas: consulta ERP/WMS/OMS, aciona antifraude, cria ticket no helpdesk.

Isso aproxima a IA do que a operação realmente precisa: resolver.

Higiene de contexto: a diferença entre um agente útil e um agente “confuso”

Em picos de atendimento, a pior coisa é um assistente que “viaja” porque acumulou ruído. Higiene de contexto é manter o espaço mental do agente limpo:

• remover histórico irrelevante;
• resumir conversas longas em bullets;
• priorizar instruções e políticas vigentes;
• detectar contradições (“a política A diz X, mas a política B diz Y”).

Falhas comuns em contextos grandes aparecem com força no e-commerce:

• envenenamento de contexto: um dado errado do cliente domina o restante;
• distração: o modelo foca no detalhe errado (ex.: cor do produto, quando o tema é estorno);
• confusão: mistura dois pedidos parecidos;
• choque de contexto: documentos internos com versões diferentes.

Minha opinião: se você não planejou higiene de contexto desde o começo, você não tem um “agente”. Você tem um chatbot acumulando conversa.

Consulta (query) bem feita: a base de um RAG que não passa vergonha

Se o sistema não entendeu a pergunta, todo o resto cai. No varejo, o cliente raramente descreve o problema “no formato ideal”. Ele manda áudio, cola um print, usa apelidos de produto, mistura assuntos.

A solução é aumentação de consulta (query augmentation) — o processo de preparar a pergunta para cada etapa do pipeline.

Reescrita de consulta: entender o que o cliente quis dizer

Reescrever a query troca “texto humano confuso” por “consulta operacional clara”. Exemplo realista:

• Entrada do cliente: “meu pedido tá parado e ngm resolve, comprei semana passada”
• Query reescrita (para busca): “status do pedido + atraso na entrega + data de compra + canal”

Isso melhora a recuperação de documentos e reduz respostas genéricas.

Expansão de consulta: cobrir sinônimos e variações

No e-commerce, “estorno” vira “cancelamento”, “reembolso”, “dinheiro de volta”. Expansão de query cria variações controladas para encontrar a política certa e o procedimento correto.

O cuidado aqui é não deixar a busca “derivar” e puxar documentos que parecem relacionados, mas não são (por exemplo, estorno de cartão vs estorno de PIX).

Decomposição: quebrar perguntas grandes em tarefas menores

Quando o cliente pergunta “cadê meu pedido e como faço pra trocar se chegar errado?”, isso são duas coisas:

1. consultar status/logística;
2. aplicar política de troca/devolução para o tipo de erro.

A decomposição evita respostas misturadas e permite uma síntese final mais precisa.

Retrieval no varejo: chunking é a sua decisão mais importante

Um LLM só é “inteligente” com a informação que você coloca na frente dele. Só que você não pode jogar 200 páginas de política e esperar milagre. É por isso que chunking (dividir documentos em partes buscáveis) manda no resultado.

Regra prática para o varejo: chunk bom é pequeno o suficiente para ser preciso e grande o suficiente para fazer sentido.

Técnicas que normalmente funcionam bem:

• chunking recursivo (por seção → parágrafo → sentença) para FAQs e políticas;
• chunking baseado em documento para conteúdo em Markdown/HTML (manuais internos);
• chunking hierárquico quando você precisa de visão geral + detalhes (ex.: política “Natal” com exceções por categoria).

Um exemplo de falha típica: chunk grande demais mistura “prazo de devolução” com “condições de produto lacrado” e “taxas de frete reverso”. Resultado: o modelo responde um Frankenstein.

Memória e ferramentas: como a IA vira operação (não só atendimento)

Memória dá continuidade. Ferramentas dão capacidade de executar.

Memória em camadas (o modelo que não enlouquece)

Pense assim:

• memória curta (dentro do contexto): o que está acontecendo agora no atendimento;
• memória longa (fora do contexto): preferências do cliente, histórico de contatos, políticas e procedimentos, base de conhecimento.

O truque é offloading: guardar fora o que não precisa ficar “na mesa” o tempo todo e trazer de volta só quando necessário.

No varejo, isso permite algo valioso: personalização sem confusão. O agente lembra que aquele cliente prefere retirada em loja, mas não carrega o histórico inteiro em cada resposta.

Ferramentas: onde o ROI aparece

Sem ferramentas, o LLM só conversa. Com ferramentas, ele resolve:

• consulta OMS: status do pedido e eventos de logística;
• consulta WMS/estoque: disponibilidade real e previsão de reposição;
• helpdesk: abrir/atualizar ticket com categoria certa;
• financeiro: iniciar fluxo de estorno com validações;
• antifraude: checar bloqueios e orientar com segurança.

Aqui entra uma disciplina subestimada: descrever ferramentas como contrato. Inputs, outputs, limites e quando usar. Quanto mais claro, menos o agente erra.

Checklist de implementação (para sair da teoria)

Se você está desenhando um assistente de atendimento, um copilot de compras ou um analista virtual de demanda, eu começaria por este checklist:

1. Defina tarefas que exigem dados reais (ex.: “onde está meu pedido?”, “posso trocar?”) e não apenas respostas genéricas.
2. Mapeie fontes oficiais: política vigente, OMS/WMS/ERP, catálogo, CRM.
3. Projete query augmentation (reescrita + expansão + decomposição) antes de mexer em prompt.
4. Escolha chunking por tipo de documento (não use um único padrão para tudo).
5. Implemente higiene de contexto: sumarização, poda, validação de relevância.
6. Adicione ferramentas com guardrails: validações, permissões, logs e trilha de auditoria.
7. Meça qualidade com números: taxa de resolução, tempo médio de atendimento, taxa de escalonamento, satisfação pós-contato.

Métrica que eu gosto: “resolução com evidência” — respostas que citam (internamente) a política certa ou o evento de pedido correto.

O que o varejo faz bem (e por que isso também vale para indústria)

O varejo opera conectado a sistemas e eventos em tempo real — pedidos mudam, estoque oscila, preços expiram. É por isso que IA funciona no varejo quando ela é integrada ao “chão de loja digital”.

A mesma lógica aparece na indústria e manufatura (tema maior da campanha): soluções como manutenção preditiva e fábricas inteligentes dão certo porque não ficam isoladas. Elas se alimentam de sensores, MES/SCADA, históricos e regras operacionais. LLM isolado vira um “palpiteiro”; IA conectada vira um componente do processo.

Se a sua IA no e-commerce ainda está no modo “chat bonito”, o próximo passo é arquitetura: engenharia de contexto + agentes + ferramentas + governança.

Deixo uma provocação para fechar: se amanhã seu tráfego dobrar e seu catálogo mudar, seu assistente continua certo — ou só continua falante?