हमारी AI कंटेंट पाइपलाइन GPT-6 Sol पर चलती है — और अब पहले से कम इमेज बनाती है

अपडेट: 24 सितंबर, 2026: इस पोस्ट में मूल रूप से GPT-5.6 पर चलने वाली पाइपलाइन का वर्णन था। अब यह GPT-6 Sol पर चलती है और अनुवाद GPT-6 Luna पर होता है; नीचे दिए गए मॉडल के नाम और कोड इसी के अनुसार अपडेट किए गए हैं।

Green Yoga Inc की पाइपलाइन में कंटेंट बनाने वाला हर प्रॉम्प्ट अब GPT-6 Sol को लक्षित करता है। हर फ़ाइल में यह एक पंक्ति का बदलाव है। लिखने लायक बात यह है कि इमेज जनरेशन के साथ क्या हुआ—हमने इसे पाइपलाइन से पूरी तरह हटा दिया।

मॉडल का चयन वास्तव में कहाँ होता है

प्रॉम्प्ट ai-prompts/ में हेडर वाले साधारण टेक्स्ट फ़ाइलों के रूप में रहते हैं, Lambda सोर्स में स्ट्रिंग लिटरल के रूप में नहीं। आज इनकी संख्या 23 है, साथ ही एक बार के इमेज बैच के लिए एक JSON मैनिफ़ेस्ट भी है। इनमें से 16 में MODEL: gpt-6-sol है।

बाकी में जान-बूझकर ऐसा नहीं है:

21-content-translation.txt gpt-6-luna पर चलता है, जो GPT-6 का छोटा मॉडल है। यह साइट का आठ भाषाओं में अनुवाद करता है, और यह एकमात्र ऐसा काम है जहाँ गुणवत्ता में आख़िरी थोड़ा-सा सुधार हासिल करने से ज़्यादा अहम काम की मात्रा है।
Lambda जिन तीन gptimage-* प्रॉम्प्ट फ़ाइलों को अब भी पढ़ता है, उनमें MODEL: हेडर नहीं है, क्योंकि Lambda में अब कोई भी चीज़ उन्हें OpenAI को नहीं भेजती। इस बारे में आगे और बताएँगे।
बाकी तीन में से दो संदर्भ के अंश हैं, जिन्हें दूसरे प्रॉम्प्ट में जोड़ा जाता है; और एक इमेज-टू-वीडियो प्रॉम्प्ट है, जो किसी दूसरे प्रोवाइडर को लक्षित करता है।

दोनों Lambda — ai-content-engine और yoga-script — हेडर में दिए गए मान को 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;
}

कोई भी पुराना ID — gpt-5 से gpt-5.6 तक, और पुराना gpt-image-1.5 — बदलकर gpt-6-sol हो जाता है। छह महीने से किसी ने जिस प्रॉम्प्ट फ़ाइल को छुआ तक न हो, वह किसी बंद हो चुके मॉडल को नहीं बुला सकती; उसकी जगह चुपचाप मौजूदा मॉडल इस्तेमाल होता है। gpt-4o और gpt-4o-mini बिना बदलाव के आगे जाते हैं, क्योंकि कोड का एक रास्ता जान-बूझकर gpt-4o पर निर्भर है।

दोनों Lambda, Chat Completions से बात करते हैं

टेक्स्ट जनरेशन के लिए दोनों Lambda POST /v1/chat/completions का इस्तेमाल करते हैं। अगर आपने हमारी अप्रैल वाली पोस्ट पढ़ी है, तो यह उससे उलट बदलाव है: हमने Responses API को मानक बना लिया था। फिर हम वापस आ गए। इन दोनों फ़ंक्शन के वास्तविक काम के लिए Chat Completions एक सीधा-सादा और अच्छी तरह समझा हुआ इंटरफ़ेस है: सिस्टम प्रॉम्प्ट और यूज़र प्रॉम्प्ट लेना और गद्य लौटाना।

POST /v1/responses को अब सिर्फ़ वे डेवलपर स्क्रिप्ट बुलाती हैं जिन्हें वर्कस्टेशन से हाथ से चलाया जाता है। scripts/generate-pose-images.mjs, 1024x1024 पर gpt-6-sol के image_generation टूल का इस्तेमाल करता है, और एक बार के दो इमेज स्क्रिप्ट 1536x1024 पर यही करते हैं। ये लोकल बैच जॉब हैं, ब्राउज़र ट्रैफ़िक नहीं, और जान-बूझकर सीधे OpenAI को कॉल करते हैं।

Yoga Sequence Builder अपने समय का बजट ख़ुद तय करता है

Yoga Sequence Builder, GPT-6 Sol पर 05-yoga-script-generator.txt के ज़रिए yoga-script Lambda से शिक्षण स्क्रिप्ट बनाता है। स्क्रिप्ट जनरेशन धीमा और बदलता रहने वाला काम है, इसलिए Lambda का ज़्यादातर लॉजिक प्रॉम्प्टिंग के बजाय हिसाब-किताब पर खर्च होता है:

एक प्राथमिक प्रयास की अधिकतम सीमा सात मिनट है, ताकि एक धीमी कॉल पूरा इनवोकेशन न खा जाए
जवाब को क्रमबद्ध करके लौटाने के लिए अंत में 25 सेकंड रखे जाते हैं
gpt-4o पर फ़ॉलबैक मौजूद है, लेकिन यह तभी चलता है जब कम-से-कम दो मिनट का समय बचा हो

आख़िरी नियम सबसे अहम है। अगर प्राथमिक प्रयास देर से विफल हो जाए और पर्याप्त समय न बचे, तो Lambda फ़ॉलबैक शुरू करने से मना कर देता है और इसके बजाय स्पष्ट त्रुटि लौटाता है — Skipping gpt-4o fallback: insufficient Lambda time remaining। जिस कॉल को आप पूरा नहीं कर सकते, उसे शुरू करने से एक साफ़ त्रुटि टाइमआउट में बदल जाती है, जिसे डीबग करना निश्चित रूप से ज़्यादा मुश्किल है।

हमने इमेज अपने-आप बनाना बंद कर दिया

अप्रैल के बाद यह असली बदलाव है।

ai-content-engine में generateImage() अब एक no-op stub है। यह अपने आर्ग्युमेंट लेता है, उन्हें अनदेखा करता है और फ़ॉलबैक कवर लौटाता है:

/** 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;
}

इसकी जगह किसी दूसरे मॉडल ने नहीं ली। इसकी जगह एक इंसान ने ली है। generateOrReuseImage() इमेज प्रॉम्प्ट को खाली S3 key के साथ DynamoDB में लिखता है और फ़ॉलबैक लौटाता है; स्वीकृति वाला ईमेल वह प्रॉम्प्ट किसी इंसान तक पहुँचाता है। जब इमेज अटैच करके जवाब आता है, तो एक अलग media-receiver Lambda असली एसेट जोड़ता है।

प्रॉम्प्ट को एक ही ब्लॉब के बजाय तीन अलग फ़ील्ड — clipL, t5xxl, और negative — में रखा जाता है, क्योंकि इसे रेंडर करने वाला आम तौर पर OpenAI का इस्तेमाल नहीं कर रहा होता। ये diffusion मॉडल के प्रॉम्प्ट स्लॉट हैं; इन्हें अलग रखने से ऑपरेटर जुड़े हुए स्ट्रिंग को अलग-अलग करने के बजाय हर फ़ील्ड को सही बॉक्स में पेस्ट कर सकता है।

धीमी पाइपलाइन ही सही पाइपलाइन क्यों है

अपने-आप कवर बनाना वह फ़ीचर था जिससे साइट पर कोई शर्मिंदगी वाली चीज़ सबसे आसानी से प्रकाशित हो सकती थी, बिना किसी के पहले उसे देखे। टेक्स्ट पहले से ही स्वीकृति वाले ईमेल से गुज़रता है। इमेज ऐसा नहीं करती थीं — वे बिना निगरानी के एक ही चरण में बनाई, अपलोड और प्रकाशित हो जाती थीं।

इसे हटाने से प्रकाशन धीमा ज़रूर हुआ। लेकिन इसका मतलब यह भी है कि इस साइट की हर इमेज प्रकाशित होने से पहले किसी इंसान ने देखी है—और असल में हमें यही चाहिए था। मॉडल बेहतर हुआ, और हमने उसे बिना निगरानी करने के लिए कम काम दिया। इन दोनों बातों में कोई विरोधाभास नहीं है।

प्रॉम्प्ट ai-prompts/ में हैं; Lambda lambda/ai-content-engine और lambda/yoga-script में हैं। अगर आप अपनी AI कंटेंट पाइपलाइन के लिए स्वीकृति प्रक्रिया तैयार करने में मदद चाहते हैं, तो हमसे संपर्क करें.