O nosso pipeline de conteúdos de IA funciona com GPT-6 Sol — e gera menos imagens do que antes

Atualizado a 24 de setembro de 2026: esta publicação descrevia originalmente o pipeline com GPT-5.6. Agora funciona com GPT-6 Sol, com as traduções feitas com GPT-6 Luna, e os nomes dos modelos e o código abaixo refletem essa alteração.

Todos os prompts de geração de conteúdos no pipeline da Green Yoga Inc usam agora GPT-6 Sol. Essa parte implica uma alteração de uma linha por ficheiro. O que vale a pena contar é o que aconteceu à geração de imagens, que removemos completamente do pipeline.

Onde o modelo é realmente escolhido

Os prompts estão em ai-prompts/ como ficheiros de texto simples com um cabeçalho, nunca como literais de string no código-fonte do Lambda. Atualmente, são 23, mais um manifesto JSON para lotes de imagens pontuais. Dezasseis incluem MODEL: gpt-6-sol.

Os restantes não incluem, intencionalmente:

• 21-content-translation.txt funciona com gpt-6-luna, o modelo GPT-6 mais pequeno. Traduz o site para oito idiomas e é a única tarefa em que o volume é mais importante do que o último incremento de qualidade.
• Os três ficheiros de prompt gptimage-* que o Lambda ainda lê não têm cabeçalho MODEL:, porque nada no Lambda os envia já para a OpenAI. Mais sobre isso abaixo.
• Os três restantes são dois fragmentos de contexto inseridos noutros prompts e um prompt de conversão de imagem em vídeo que usa outro fornecedor.

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

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

Qualquer ID antigo — de gpt-5 a gpt-5.6, bem como o antigo gpt-image-1.5 — passa a gpt-6-sol. Um ficheiro de prompt que ninguém alterou há seis meses não pode chamar um modelo descontinuado; recebe silenciosamente o modelo atual. gpt-4o e gpt-4o-mini são mantidos sem alterações, porque ainda há um percurso de código que precisa deliberadamente de gpt-4o.

Ambos os Lambdas usam Chat Completions

A geração de texto é feita através de POST /v1/chat/completions por ambos os Lambdas. Se leu a nossa publicação de abril, isto representa uma inversão: tínhamos consolidado a utilização da API Responses. Voltámos atrás. Chat Completions é a opção simples e bem conhecida para aquilo que estas duas funções realmente fazem: recebem um prompt de sistema e um prompt de utilizador e devolvem texto.

As únicas chamadas restantes a POST /v1/responses são feitas por scripts de desenvolvimento executados manualmente numa estação de trabalho. scripts/generate-pose-images.mjs usa a ferramenta image_generation com gpt-6-sol a 1024x1024, e dois scripts pontuais de imagens fazem o mesmo a 1536x1024. São tarefas locais em lote, não tráfego do browser, e chamam diretamente a OpenAI de propósito.

O Yoga Sequence Builder gere o seu próprio tempo

O Yoga Sequence Builder gera guiões de ensino através do Lambda yoga-script, com base em 05-yoga-script-generator.txt e GPT-6 Sol. A geração dos guiões é lenta e variável, por isso o Lambda dedica a maior parte da sua lógica a cálculos, em vez de a prompts:

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

Esta última regra é a mais importante. Se a tentativa principal falhar já perto do fim e não houver tempo suficiente, o Lambda recusa-se a iniciar a alternativa e devolve um erro explícito — Skipping gpt-4o fallback: insufficient Lambda time remaining. Iniciar uma chamada que não é possível concluir apenas transforma um erro claro num tempo limite excedido, o que é muito mais difícil de depurar.

Deixámos de gerar imagens automaticamente

Esta é a verdadeira mudança desde abril.

generateImage() em ai-content-engine é agora um stub sem operação. Recebe os argumentos, ignora-os e devolve a imagem de capa alternativa:

/** 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 foi outro modelo. Foi uma pessoa. generateOrReuseImage() grava o prompt da imagem no DynamoDB com uma chave S3 vazia e devolve a imagem de capa alternativa; o e-mail de aprovação envia esse prompt a uma pessoa. Quando a resposta chega com uma imagem em anexo, um Lambda media-receiver separado preenche o recurso final.

O prompt é guardado em três campos separados — clipL, t5xxl e negative — em vez de num único bloco, porque quem o processa geralmente não usa a OpenAI. Esses campos são espaços para prompts de modelos de difusão e, ao mantê-los separados, o operador pode colar cada um na caixa certa sem ter de desfazer uma string concatenada.

Porque é que um pipeline mais lento é o pipeline certo

A geração automática de imagens de capa era a funcionalidade com maior probabilidade de publicar algo embaraçoso no site sem que ninguém o visse primeiro. O texto já passa por um e-mail de aprovação. As imagens não — eram geradas, carregadas e publicadas num único processo sem supervisão.

A sua remoção tornou a publicação mais lenta. Também significa que todas as imagens deste site foram vistas por uma pessoa antes de serem publicadas, que era precisamente o que pretendíamos. O modelo melhorou e atribuímos-lhe menos tarefas sem supervisão. Não há contradição entre estas duas coisas.

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