IT18 de agosto de 2026

O nosso pipeline de Conteúdo de IA funciona em GPT-5.6 — e gera menos imagens do que antes

Por Andrea Borghi
O nosso pipeline de Conteúdo de IA funciona em GPT-5.6 — e gera menos imagens do que antes

O nosso pipeline de Conteúdo de IA funciona em GPT-5.6 — e gera menos imagens do que antes

Cada prompt de texto no pipeline de conteúdo da Green Yoga Inc agora aponta para GPT-5.6. Essa parte é uma alteração de uma linha por ficheiro. A parte que merece ser explicada é o que aconteceu à geração de imagens, que removemos do pipeline por completo.

Onde o modelo é realmente escolhido

Os prompts vivem em ai-prompts/ como ficheiros de texto simples com um cabeçalho, nunca como literais de string no código-fonte do Lambda. Existem 19 hoje, mais um manifesto JSON para lotes pontuais de imagens. Quinze têm MODEL: gpt-5.6.

Dois não têm, propositadamente:

  • 21-content-translation.txt continua em gpt-5.4-mini. Traduz o site para oito idiomas, e é a única carga de trabalho em que o volume importa mais do que o último incremento de qualidade. Uma re-tradução completa de tudo custa cerca de dez cêntimos.
  • Os três ficheiros de prompt gptimage-* não têm qualquer cabeçalho MODEL:, porque nada no Lambda os envia para a OpenAI já. Mais sobre isso abaixo.

Ambos os Lambdas — ai-content-engine e yoga-script — resolvem o que quer que o cabeçalho indique através de normalizeModel():

function normalizeModel(raw?: string): string {
  if (!raw) return "gpt-5.6";
  // Legacy GPT-5.x ids -> current flagship
  if (m === "gpt-5" || m === "gpt-5.1" || ... || m === "gpt-5.5" || m === "gpt-image-1.5") {
    return "gpt-5.6";
  }
  if (m === "gpt-4o" || m === "gpt4o") return "gpt-4o";
  return m;
}

Qualquer id legado — gpt-5 até gpt-5.5, e o antigo gpt-image-1.5 — é convertido para gpt-5.6. Um ficheiro de prompt que ninguém tocou em seis meses não pode chamar um endpoint descontinuado; em silêncio, passa a usar o modelo principal atual. gpt-4o e gpt-4o-mini passam sem alterações, porque um caminho de código ainda precisa deliberadamente de gpt-4o.

Ambos os Lambdas falam com Chat Completions

A geração de texto vai para POST /v1/chat/completions a partir de ambos os Lambdas. Se ler o nosso artigo de abril, isso é uma inversão: tínhamos consolidado na API Responses. Voltámos atrás. Chat Completions é a superfície simples e bem compreendida para aquilo que estas duas funções realmente fazem, que é pegar num prompt de sistema e num prompt de utilizador e devolver texto.

A única coisa que ainda chama POST /v1/responses é scripts/generate-pose-images.mjs, um script de programador executado manualmente a partir de uma workstation. Usa a ferramenta image_generation no gpt-5.6 a 1024x1024. É um trabalho por lotes local, não tráfego de browser, e chama a OpenAI de propósito.

O Yoga Sequence Builder gere o seu próprio tempo

O Yoga Sequence Builder gera scripts de ensino através do Lambda yoga-script, orientado por 05-yoga-script-generator.txt em GPT-5.6. A geração de scripts é lenta e variável, por isso o Lambda gasta a maior parte da sua lógica em aritmética em vez de prompting:

  • uma única tentativa principal tem um limite de sete minutos, para que uma chamada lenta não consuma toda a invocação
  • 25 segundos são reservados no fim para serializar e devolver uma resposta
  • existe um fallback gpt-4o, mas só é executado se restarem pelo menos dois minutos de margem

Essa última regra é a que importa. Se a tentativa principal falhar já perto do fim e não houver tempo suficiente, o Lambda recusa-se a iniciar o fallback e devolve antes um erro explícito — Skipping gpt-4o fallback: insufficient Lambda time remaining. Iniciar uma chamada que não se consegue terminar só transforma um erro claro num timeout, o que é muito pior de depurar.

Deixámos de gerar imagens automaticamente

Esta é a verdadeira mudança desde abril.

generateImage() em ai-content-engine é agora um stub no-op. Recebe os seus argumentos, ignora-os e devolve a imagem de capa de fallback:

/** Kept as a no-op stub for callers that still reference it directly. */
async function generateImage(imagePrompt: string, s3Key: string): Promise<string> {
  void imagePrompt;
  void s3Key;
  return FALLBACK_COVER_IMAGE;
}

O que o substituiu não é outro modelo. É uma pessoa. generateOrReuseImage() escreve o prompt da imagem no DynamoDB com uma chave S3 vazia e devolve o fallback, e o email de aprovação leva esse prompt para um humano. Quando a resposta chega com uma imagem em anexo, um Lambda separado media-receiver preenche o ativo real.

O prompt é armazenado como três campos separados — clipL, t5xxl e negative — em vez de um único bloco, porque quem o renderiza geralmente não está a usar a OpenAI. Esses são espaços de prompt para modelos de difusão, e mantê-los separados significa que o operador pode colar cada um na caixa certa em vez de desembaraçar uma string concatenada.

Porque é que um pipeline mais lento é o pipeline certo

A geração automática de capas era a funcionalidade com maior probabilidade de colocar algo embaraçoso no site sem ninguém o ver primeiro. O texto já passa por um email de aprovação. As imagens não passavam — eram geradas, carregadas e publicadas num único passo sem supervisão.

Remover isso tornou a publicação mais lenta, sim. Também significa que cada imagem neste site foi vista por uma pessoa antes de ser publicada, que é a propriedade que realmente queríamos. O modelo melhorou e demos-lhe menos para fazer sem supervisão. Essas coisas não entram em conflito.

Os prompts estão em ai-prompts/; os Lambdas estão em lambda/ai-content-engine e lambda/yoga-script. Se quiser ajuda a desenhar um fluxo de aprovação para o seu próprio pipeline de conteúdo de IA, entre em contacto.

← Voltar ao Blog