Redação de textos para e-commerce e respostas de atendimento ao cliente com glm-5.3

Equipes de e-commerce precisam de um fluxo constante de textos curtos e estruturados: títulos de produtos, listas de tópicos, respostas sobre guias de tamanhos, respostas sobre políticas de devolução, respostas a avaliações. Isso é um problema de texto, não de imagem — e é necessário deixar claro desde já: o glm-5.3 não ajuda em nada na metade "geração de imagens de produtos" do pipeline de conteúdo de e-commerce.

O glm-5.3 é oferecido via API hiapi, é um modelo puramente textual, acessível pelo endpoint Chat Completions compatível com OpenAI. Ele não tem entrada ou saída de imagem — se você veio para fotografia de produtos com IA, consulte o guia de fluxo de trabalho de e-commerce do GPT Image 2. O que o glm-5.3 faz bem é transformar tabelas de especificações brutas ou mensagens de clientes em textos limpos e em conformidade com políticas, e cada resposta exibe o reasoning_content, para que você veja como ele chegou à resposta.

Este guia cobre dois casos reais de e-commerce — redação de textos de produtos e respostas de atendimento ao cliente — com chamadas de API reais, uso real de tokens e custo real por requisição.

O que exatamente é o glm-5.3: um modelo textual que sempre raciocina

O glm-5.3 não oferece níveis opcionais de raciocínio. Toda resposta inclui um campo reasoning_content ao lado do content final, e não há parâmetro reasoning_effort para aumentar ou diminuir — de acordo com a documentação do modelo, "intensidade de raciocínio opcional" explicitamente não faz parte do contrato público. Ele suporta stream, response_format (modo JSON) e tools/tool_choice no estilo OpenAI para chamadas de função, mas a profundidade do raciocínio é decidida pelo modelo, não por você.

Isso importa para o orçamento: nos testes deste guia, uma requisição simples de redação de texto consumiu mais tokens de raciocínio do que uma resposta de atendimento ao cliente que realmente precisava aplicar a política de devolução. Você não pode prever o custo com base na complexidade da tarefa como faria com modelos de níveis — veja os detalhes abaixo.

Caso de uso 1: redigir textos de produtos a partir de tabelas de especificações

Uma tarefa típica de catálogo: transformar tópicos brutos de especificações em um título mais uma lista de tópicos formatada, sem inventar funcionalidades que não estejam nas especificações.

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.3",
    "messages": [
      {
        "role": "system",
        "content": "You write e-commerce product listings. Output a title under 70 characters and 4 bullet points in ALL-CAPS-LEAD style. Do not claim features not in the spec."
      },
      {
        "role": "user",
        "content": "Product: insulated stainless steel water bottle. Capacity: 32oz. Keeps cold 24 hours, hot 12 hours. Leak-proof lid. BPA-free. Available in 6 colors."
      }
    ]
  }'

Conteúdo da resposta:

Título: Garrafa térmica de aço inoxidável 32oz – Mantém gelado por 24h, quente por 12h

Lista de tópicos:

• Isolamento em aço inoxidável: mantém gelado por até 24 horas e quente por até 12 horas.
• Capacidade de 32 onças: capacidade generosa de 32 onças, mantém você hidratado o dia todo.
• Tampa à prova de vazamentos: design de tampa segura que evita vazamentos em movimento.
• Sem BPA, 6 cores: feita com materiais livres de BPA, disponível em 6 opções de cores.

A descrição do produto segue estritamente as especificações — nenhuma afirmação inventada sobre tecnologia de isolamento ou certificações não fornecidas. Uso real desta chamada: 89 tokens de prompt, 1.146 tokens de conclusão (dos quais 1.018 são reasoning_content), custo total $0.0180.

O número de tokens de raciocínio é o ponto surpreendente. Esta é uma tarefa de reformatação sem lógica de política a aplicar, e mesmo assim o modelo gastou mais de mil tokens pensando em contagem de caracteres e opções de redação antes de escrever os quatro tópicos.

Caso de uso 2: respostas de atendimento ao cliente

Questões de atendimento ao cliente exigem raciocínio real sobre políticas, não apenas reformatação — o modelo precisa aplicar as regras corretamente, em vez de fazer correspondência de padrões com palavras-chave.

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "glm-5.3",
    "messages": [
      {
        "role": "system",
        "content": "You are a support agent. Return policy: returns accepted within 30 days if unused and in original packaging. Customer pays return shipping unless the item arrived damaged or wrong. Refunds post 5-7 business days after warehouse receives the item."
      },
      {
        "role": "user",
        "content": "I ordered the wrong size 10 days ago, item is unopened. Can I return it, and who pays shipping?"
      }
    ]
  }'

Resposta:

Sim, você pode devolver! Aqui está como o seu caso se encaixa na nossa política:

• Elegibilidade: você ainda está dentro do prazo de 30 dias (10 dias se passaram) e o item não foi aberto, portanto atende ao requisito de não usado/embalagem original.
• Frete de devolução: como o item foi enviado conforme o pedido (o tamanho errado é um problema de quem fez o pedido, não de cumprimento), o frete de devolução é por sua conta. Só cobrimos o frete de devolução se o item chegou danificado ou se enviamos o produto errado.
• Prazo de reembolso: após o nosso armazém receber o item, seu reembolso será processado em 5 a 7 dias úteis.

Se quiser, posso ajudar você a iniciar o processo de devolução — basta me informar o número do pedido!

O modelo distinguiu corretamente entre "o cliente escolheu o tamanho errado" e "enviamos o produto errado" — uma distinção que determina quem paga o frete — em vez de apenas corresponder à palavra "devolução". Isso é aplicação real de política, e esse tipo de rascunho de resposta é exatamente o que um atendente humano pode aprovar em segundos, sem digitar do zero.

Uso real desta chamada: 87 tokens de prompt, 358 tokens de conclusão (dos quais 200 são reasoning_content), custo total $0.0059 — cerca de um terço da chamada de redação de texto acima, embora tenha feito um trabalho que realmente exige aplicação de regras.

Considerações de custo para execução em escala

O glm-5.3 no hiapi custa $4,40 por milhão de tokens de entrada e $15,40 por milhão de tokens de saída — a saída inclui a resposta visível e o reasoning_content oculto, então sua fatura depende de quanto o modelo decide pensar, não de quão complexa a tarefa parece externamente. Nas duas chamadas acima, a tarefa "simples" de redação custou cerca de 3 vezes mais que a tarefa "difícil" de atendimento, puramente devido à variação nos tokens de raciocínio.

Se você for executar por volume de catálogo ou de tickets, há duas proteções práticas:

• Defina max_tokens como um limite rígido para o orçamento de raciocínio + conclusão por chamada, para que, mesmo que o modelo decida raciocinar por muito tempo, uma única requisição não saia do controle em termos de custo.
• Deixe tarefas determinísticas de baixo risco para outros modelos, se um custo previsível por chamada for mais importante que a qualidade da saída — modelos com níveis opcionais de raciocínio (como kimi-k3, que oferece low/high/max) oferecem um botão de ajuste de custo que o glm-5.3 não tem.

O glm-5.3 vale essa imprevisibilidade exatamente no caso de uso de respostas de atendimento acima: nessas tarefas, o custo de errar a lógica da política é muito maior do que gastar alguns centavos a mais em tokens de raciocínio.

Começando

As duas chamadas acima usam a mesma página do modelo glm-5.3 e o endpoint Chat Completions — substitua o prompt do sistema de acordo com a sua tarefa e você terá um pipeline funcional de redação de textos ou de respostas de atendimento ao cliente. Para a configuração básica (chave de API, primeira requisição curl, exemplo em Python), consulte o guia da API glm-5.3. Antes de executar em escala, confira os preços atuais, pois o custo de saída é a variável mais difícil de prever aqui.