IT18 agosto 2026

La nostra pipeline di contenuti AI gira su GPT-5.6 — e genera meno immagini di prima

Di Andrea Borghi
La nostra pipeline di contenuti AI gira su GPT-5.6 — e genera meno immagini di prima

La nostra pipeline di contenuti AI gira su GPT-5.6 — e genera meno immagini di prima

Ogni prompt di testo nella pipeline di contenuti di Green Yoga Inc ora punta a GPT-5.6. Quella parte è una modifica di una riga per file. La parte che vale la pena raccontare è ciò che è successo alla generazione delle immagini, che abbiamo rimosso del tutto dalla pipeline.

Dove viene effettivamente scelto il modello

I prompt vivono in ai-prompts/ come semplici file di testo con un header, mai come stringhe letterali nel sorgente di Lambda. Oggi sono 19, più un manifest JSON per batch di immagini una tantum. Quindici riportano MODEL: gpt-5.6.

Due non lo fanno, di proposito:

  • 21-content-translation.txt resta su gpt-5.4-mini. Traduce il sito in otto lingue, ed è il carico di lavoro in cui il volume conta più dell’ultimo incremento di qualità. Una nuova traduzione completa di tutto costa circa dieci centesimi.
  • I tre file di prompt gptimage-* non riportano affatto un header MODEL:, perché niente in Lambda li invia più a OpenAI. Più sotto spieghiamo meglio.

Entrambe le Lambda — ai-content-engine e yoga-script — risolvono ciò che dice l’header tramite 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;
}

Qualsiasi id legacy — da gpt-5 a gpt-5.5, e il vecchio gpt-image-1.5 — converge su gpt-5.6. Un file prompt che nessuno ha toccato da sei mesi non può chiamare un endpoint deprecato; ottiene in silenzio il modello di punta attuale. gpt-4o e gpt-4o-mini passano invariati, perché un flusso di codice ha ancora bisogno deliberatamente di gpt-4o.

Entrambe le Lambda parlano con Chat Completions

La generazione di testo va a POST /v1/chat/completions da entrambe le Lambda. Se avete letto il nostro post di aprile, si tratta di una inversione: eravamo passati in modo consolidato alle Responses API. Siamo tornati indietro. Chat Completions è l’interfaccia semplice e ben compresa per ciò che queste due funzioni fanno davvero: prendere un system prompt e un user prompt e restituire prosa.

L’unica cosa che continua a chiamare POST /v1/responses è scripts/generate-pose-images.mjs, uno script per sviluppatori eseguito a mano da una workstation. Usa lo strumento image_generation su gpt-5.6 a 1024x1024. È un job batch locale, non traffico browser, e chiama OpenAI direttamente di proposito.

Il Yoga Sequence Builder gestisce da solo il proprio tempo

Lo Yoga Sequence Builder genera script didattici tramite la Lambda yoga-script, guidata da 05-yoga-script-generator.txt su GPT-5.6. La generazione degli script è lenta e variabile, quindi la Lambda dedica gran parte della logica all’aritmetica più che al prompting:

  • un singolo tentativo principale è limitato a sette minuti, così una chiamata lenta non può consumare l’intera invocazione
  • 25 secondi sono riservati alla fine per serializzare e restituire una risposta
  • esiste un fallback gpt-4o, ma parte solo se restano almeno due minuti di margine

Questa ultima regola è quella che conta. Se il tentativo principale fallisce tardi e non c’è abbastanza tempo residuo, la Lambda rifiuta di avviare il fallback e restituisce invece un errore esplicito — Skipping gpt-4o fallback: insufficient Lambda time remaining. Avviare una chiamata che non puoi finire trasforma solo un errore chiaro in un timeout, che è decisamente peggiore da debuggare.

Abbiamo smesso di generare immagini automaticamente

Questa è la vera novità da aprile.

generateImage() in ai-content-engine è ora uno stub no-op. Riceve i suoi argomenti, li ignora e restituisce la cover di 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;
}

Ciò che l’ha sostituita non è un altro modello. È una persona. generateOrReuseImage() scrive il prompt dell’immagine in DynamoDB con una chiave S3 vuota e restituisce il fallback, e l’email di approvazione porta quel prompt a un essere umano. Quando arriva la risposta con un’immagine allegata, una Lambda separata media-receiver inserisce l’asset reale.

Il prompt viene salvato come tre campi separati — clipL, t5xxl e negative — invece di un unico blob, perché chi lo renderizza in genere non usa OpenAI. Questi sono slot di prompt per modelli diffusion, e tenerli separati significa che l’operatore può incollarli ciascuno nel box giusto invece di dover districare una stringa concatenata.

Perché una pipeline più lenta è la pipeline giusta

La generazione automatica delle cover era la funzionalità più incline a mettere qualcosa di imbarazzante sul sito senza che nessuno lo vedesse prima. Il testo passa già attraverso un’email di approvazione. Le immagini no — venivano generate, caricate e pubblicate in un solo passaggio non presidiato.

Toglierla ha reso la pubblicazione più lenta. Significa anche che ogni immagine su questo sito è stata guardata da una persona prima di andare online, che è la proprietà che volevamo davvero. Il modello è migliorato e noi gli abbiamo fatto fare meno lavoro senza supervisione. Le due cose non sono in conflitto.

I prompt sono in ai-prompts/; le Lambda sono in lambda/ai-content-engine e lambda/yoga-script. Se vuoi aiuto a progettare un flusso di approvazione per la tua pipeline di contenuti AI, contattaci.

← Torna al Blog