Seu LLM não sabe o preço de nada: o problema do conhecimento congelado em apps de compra

Você abre o chat. Pergunta: "qual o melhor notebook até cinco mil reais hoje?". O modelo responde com três marcas, especificações detalhadas, prós e contras. Tudo redondinho. Tudo plausível.

E tudo, possivelmente, errado.

O notebook que ele recomendou foi descontinuado em fevereiro. O preço subiu oitocentos reais depois de uma promoção de Black Friday que ele nunca viu. O processador "topo de linha" virou geração anterior há dois meses. Mas o texto está bem escrito, então parece verdade.

Esse é o problema do conhecimento congelado. E ele mata, em silêncio, qualquer aplicação séria de compra, recomendação ou comparativo construída ingenuamente em cima de um LLM.

TL;DR

• O que é: modelos de linguagem têm uma data de corte de treino — depois disso, o mundo continua, mas eles não.
• Stack/Modelos: Claude Opus 4.7 / Sonnet 4.6, OpenAI, Gemini — todos sofrem do mesmo problema, em proporções diferentes.
• Custo/Acesso: o problema é grátis. A solução custa engenharia: tool use, RAG, scraping, cache, observabilidade.
• Padrão certo: LLM como motor de raciocínio. Catálogo, preço e estoque vêm de fora, em tempo real.

O modelo é uma foto. O mercado é vídeo ao vivo.

Vamos aos números oficiais. A Anthropic publica isso de forma transparente na página de modelos do Claude:

• Claude Opus 4.7 — reliable knowledge cutoff: janeiro de 2026.
• Claude Sonnet 4.6 — reliable knowledge cutoff: agosto de 2025.
• Claude Haiku 4.5 — reliable knowledge cutoff: fevereiro de 2025.

A própria documentação diferencia reliable knowledge cutoff de training data cutoff: o primeiro é "a data até a qual o conhecimento do modelo é mais extenso e confiável", o segundo é só o range bruto dos dados. E o help center deles é direto: "esses modelos podem não estar cientes de eventos ou informações que ocorreram depois das suas datas de corte".

Hoje é 25 de abril de 2026.

Mesmo no melhor caso — Opus 4.7 — você está três meses atrasado. No Sonnet 4.6, oito meses. Em modelos open source que rodam localmente, frequentemente um ano ou mais.

Para chat sobre conceitos, filosofia, sintaxe de Laravel ou matemática, isso é irrelevante. O Eloquent não muda toda semana.

Para preço de notebook, cotação de dólar, lançamento de iPhone, disponibilidade de estoque, regra do PIX, frete da sua loja parceira, política de devolução do Mercado Livre — irrelevância vira prejuízo.

Plausibilidade não é verdade

Aqui mora a parte traiçoeira. O LLM não te avisa que está chutando. Ele responde com a mesma cadência confiante que usa para te explicar polimorfismo.

A literatura já mediu isso. Estudos de hallucination em e-commerce mostram que recomendações geradas direto por LLM podem errar até 25% nos detalhes do produto. Em consultas sensíveis a tempo — preço, estoque, cotação — modelos sem retrieval alucinam até duas vezes mais do que modelos aumentados com dados externos.

Pior: o erro é confiante e bem escrito. Seu usuário só descobre que foi enganado quando clica no link e o produto custa o triplo. Aí ele não volta mais.

Para um produto de recomendação, isso é game over. Confiança é a métrica primária. Você não está vendendo "uma resposta plausível". Você está vendendo "a resposta certa para a minha próxima compra".

O padrão certo — LLM como motor de raciocínio, dados vêm de fora

A regra mental simples: o LLM raciocina, ele não lembra.

Quando o usuário pergunta "melhor notebook até cinco mil", o seu sistema não pode mandar essa pergunta direto para o modelo. Ele precisa, antes:

1. Entender a intenção. Aqui sim, LLM ajuda — extrai filtros, faixa de preço, tipo de uso.
2. Buscar dados frescos. Catálogo próprio, scraping vigiado, API de marketplace, base interna com preço atualizado nas últimas horas.
3. Montar contexto. Os 5–10 produtos candidatos viram texto estruturado dentro do prompt.
4. Pedir o raciocínio. Aí o LLM compara, justifica e responde com base no que você forneceu.

Esse padrão tem dois nomes que você já ouviu: tool use (o modelo chama funções suas para buscar dado) e RAG (você injeta documentos relevantes no prompt).

A própria doc oficial de tool use do Claude descreve isso de forma direta: "tool use permite que o Claude chame funções que você define... o Claude decide quando chamar uma ferramenta com base no pedido do usuário e na descrição da ferramenta, e retorna uma chamada estruturada que sua aplicação executa".

E a aplicação dessa lógica em e-commerce já é prática consolidada. Estudos de RAG aplicado a varejo descrevem exatamente o cenário: "informação de produto, preço e disponibilidade permanecem atualizados sem retraining caro do modelo". É isso. Não tem mágica.

Pré-requisitos

Para construir essa arquitetura, você vai precisar de:

• [ ] Chave de API de um provedor com tool use bem implementado (Claude, OpenAI ou compatível).
• [ ] Um catálogo de produtos com preço, estoque e timestamp de atualização. Pode ser tabela própria, view materializada ou API externa.
• [ ] Um sistema de retrieval — busca semântica com pgvector e Postgres já resolve 80% dos casos.
• [ ] Um Laravel 11+ com fila para os jobs de atualização de preço.

Mão na massa — esqueleto em Laravel

Vamos ao esqueleto. Vou usar prism-php, que abstrai tool use de vários provedores e é o que tem se firmado no ecossistema Laravel.

Passo 1: definir a tool de busca de produtos

Sem segredo. A tool é uma função PHP com schema declarado:

use Prism\Prism\Tool;

$searchProducts = Tool::as('search_products')
    ->for('Busca produtos no catálogo interno por categoria e faixa de preço. Retorna até 10 candidatos com preço atual.')
    ->withStringParameter('category', 'Categoria do produto. Ex: notebook, smartphone.')
    ->withNumberParameter('max_price', 'Preço máximo em reais.')
    ->withStringParameter('use_case', 'Para que o usuário vai usar. Ex: trabalho, jogos, estudo.')
    ->using(function (string $category, float $max_price, string $use_case): string {
        $products = ProductCatalog::semanticSearch(
            query: $use_case,
            filters: ['category' => $category, 'price_lte' => $max_price],
            limit: 10,
        );

        return $products->map(fn ($p) => [
            'sku' => $p->sku,
            'nome' => $p->name,
            'preco_atual' => $p->price_brl,
            'estoque' => $p->stock,
            'atualizado_em' => $p->updated_at->diffForHumans(),
            'specs' => $p->specs_summary,
        ])->toJson();
    });

Repare em três detalhes que parecem cosméticos e não são:

• O description da tool é o contrato. O modelo decide chamar com base nesse texto. Vago aqui = chamada errada lá.
• atualizado_em retorna no payload. O LLM precisa saber a frescura do dado para poder, no limite, avisar o usuário.
• A função retorna somente o que importa. Não jogue o objeto Eloquent inteiro no prompt — você paga por token.

Passo 2: orquestrar a conversa

use Prism\Prism\Prism;
use Prism\Prism\Enums\Provider;

$response = Prism::text()
    ->using(Provider::Anthropic, 'claude-opus-4-7')
    ->withSystemPrompt(<<<PROMPT
        Você é o assistente de compras da loja X. NUNCA invente preço, estoque
        ou modelo. Para qualquer recomendação, chame search_products primeiro
        e baseie a resposta exclusivamente nos resultados retornados. Se a tool
        não retornar nada relevante, diga que não encontrou — não chute.
    PROMPT)
    ->withTools([$searchProducts])
    ->withMaxSteps(4)
    ->withPrompt('Qual o melhor notebook até 5 mil para programação?')
    ->asText();

O withMaxSteps(4) é o teto do loop agêntico — o modelo pode chamar a tool, ver o resultado, refinar e chamar de novo. Quatro passos é mais que suficiente para uma recomendação. Mais que isso, geralmente, é sinal de prompt mal escrito.

Passo 3: blindar a alucinação que sobra

Mesmo com tool use, o modelo às vezes inventa. Pode citar uma marca que não veio no resultado. Pode confundir o preço de dois produtos.

A linha de defesa final é validação de saída:

$mentioned_skus = extractSkus($response->text);
$valid_skus = $products->pluck('sku');

if ($mentioned_skus->diff($valid_skus)->isNotEmpty()) {
    Log::warning('LLM citou SKU não retornado pela tool', [
        'fantasma' => $mentioned_skus->diff($valid_skus),
    ]);
    // refaz a chamada com prompt mais estrito, ou cai num fallback determinístico
}

Isso não é paranoia. É observabilidade básica de aplicação de IA. Se você não está medindo a taxa de alucinação que escapa para produção, você não tem um produto — tem uma demo.

Onde isso ainda falha

Tool use e RAG não são bala de prata. Onde você ainda se queima:

• Retrieval ruim alucina igual. Se o semanticSearch traz produtos irrelevantes, o LLM vai justificar com confiança um produto errado. Investe em embeddings bons e em reranker. A qualidade da resposta nunca é maior que a qualidade do retrieval.
• Preço cacheado vence promoção. Se a sua sync de preço roda a cada 6h, você vai recomendar um valor que mudou há 5h59. Para produtos de alta volatilidade, sync mais agressivo ou consulta direta na hora da resposta.
• Scraping é frágil. Layout muda, seletor quebra, dado some. Tenha alerta. Tenha fallback. Não monte produto em cima de um seletor CSS de marketplace sem plano B.
• PII no contexto. Se você puxa histórico do usuário para contextualizar, você está mandando dado pessoal para o provedor do modelo. Lê o termo. Mascara o que for sensível. Considere modelos auto-hospedados quando o caso for crítico.

Esse bloco não é detalhe, é o que separa POC de produto.

CTA

A galera que está construindo recomendação séria com LLM não está apenas escrevendo prompt bonito. Está pensando em arquitetura: catálogo, retrieval, tool use, validação, observabilidade, custo por requisição.

É exatamente esse tipo de engenharia que a gente discute no Clã Beer & Code. Se você está colocando IA em produto Laravel e quer trocar figurinha com gente que já passou pelo "produção quebrou às três da manhã porque o scraping voltou HTML diferente", aparece lá.

FAQ

Não basta ligar o web_search do Claude e deixar ele resolver? Resolve para chat genérico. Não resolve para produto. Você quer recomendar do seu catálogo, com seu preço, com seu estoque. Web search devolve qualquer coisa que estiver no Google — incluindo concorrente seu. Tool use customizada é o que dá controle.

Se eu uso RAG, eu posso usar um modelo mais antigo / mais barato? Em geral, sim. A inteligência exigida cai porque você está pedindo para o modelo raciocinar sobre o que você deu, não lembrar do mundo inteiro. Sonnet ou Haiku resolvem boa parte dos fluxos de comparação de produto, e custam menos. Use Opus quando o raciocínio for mesmo complexo (negociação multi-turno, planejamento de compra com múltiplas restrições).

Eu preciso de pgvector ou dá pra começar com busca textual mesmo? Começa com fulltext do Postgres. Mede. Se a precisão de retrieval te incomodar, aí adiciona embedding e rerank. Não otimize antes de ter dor — você vai gastar três semanas montando pipeline de embedding para o usuário sair antes de usar.

E quando o cliente perguntar algo que não está no catálogo? Sua tool deve retornar vazio, e o system prompt deve dizer "se não encontrou, fale que não encontrou". Resposta honesta de "não temos esse produto" vale mais que recomendação inventada. Confiança é caro de construir e barato de perder.

Conclusão

LLM não é banco de dados. Nunca foi. A sensação de que ele "sabe tudo" é um efeito colateral da fluência — e essa fluência, em domínio sensível a tempo, é exatamente o que te machuca.

A próxima geração de produtos com IA não vai ser definida por quem tem o melhor prompt. Vai ser definida por quem montou a melhor arquitetura ao redor do prompt: catálogo fresco, retrieval afiado, tool use disciplinada, validação de saída, observabilidade.

Quem entender isso, constrói. Quem não entender, vai continuar lançando demo bonita que erra preço de notebook na sexta-feira da Black Friday.

E demo bonita não paga boleto.