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

आप किसी इमेज जनरेशन टूल को एक लेआउट रेफ़रेंस, एक स्टाइल रेफ़रेंस और विषय की तस्वीर देते हैं। अनुरोध सफल हो जाता है, लेकिन आउटपुट सामान्य स्टॉक आर्ट जैसा दिखता है: विषय अपनी जगह से खिसक जाता है, हेडलाइन के लिए छोड़ी गई खाली जगह गायब हो जाती है और कई विज़ुअल स्टाइल एक अस्पष्ट “AI लुक” में मिल जाते हैं। इसका समाधान और लंबा प्रॉम्प्ट जोड़ना नहीं है। पहले हर रेफ़रेंस को एक स्पष्ट काम दें, फिर आउटपुट को इच्छित कंपोज़िशन के विरुद्ध बिंदु-दर-बिंदु जाँचें।
एक सार्वजनिक रिपोर्ट में एक एजेंट ने कई स्टाइल रेफ़रेंस को एक ही सपाट पैरामीटर में जोड़ दिया था। मॉडल ने इनपुट का औसत-जैसा मिश्रण बनाया और बिना API त्रुटि के सामान्य टेक्सचर लौटा दिए। यह अकेली रिपोर्ट किसी सार्वभौमिक मॉडल व्यवहार को सिद्ध नहीं करती, लेकिन एक अहम फर्क दिखाती है: तकनीकी रूप से सफल अनुरोध, सफल विज़ुअल कार्य के बराबर नहीं होता।
मुख्य नियम: एक इमेज कंपोज़िशन नियंत्रित करे, दूसरी दिखावट
सबसे उपयोगी बदलाव यह है कि सभी इमेज को समान महत्व वाली, बिना भूमिका की रेफ़रेंस सूची न माना जाए। कम से कम इन तीन भूमिकाओं को अलग करें:
| रेफ़रेंस की भूमिका | इसे क्या नियंत्रित करना चाहिए | इसे क्या नियंत्रित नहीं करना चाहिए |
|---|---|---|
| लेआउट रेफ़रेंस | विषयों की संख्या, स्थान, आपसी आकार, कैमरा, क्रॉप और नेगेटिव स्पेस | रंग-पैलेट, सामग्री, ब्रशवर्क या लाइटिंग स्टाइल |
| विषय रेफ़रेंस | व्यक्ति या वस्तु की पहचान, आकार और विशिष्ट विशेषताएँ | पूरी कंपोज़िशन या असंबंधित बैकग्राउंड ऑब्जेक्ट |
| स्टाइल रेफ़रेंस | पैलेट, टेक्सचर, लाइन क्वालिटी, ग्रेन, लाइटिंग और रेंडरिंग भाषा | उस इमेज के ऑब्जेक्ट, टेक्स्ट या कंपोज़िशन |
यदि काम में केवल लेआउट और स्टाइल चाहिए, तो केवल वही दो इमेज दें। अधिक रेफ़रेंस अपने-आप अधिक नियंत्रण नहीं देते; वे ऐसे प्रतिस्पर्धी संकेत जोड़ सकते हैं जिन्हें सिस्टम को आपस में मिलाना पड़ता है।
सपाट रेफ़रेंस सूची अक्सर सामान्य समझौता क्यों बनाती है
सपाट सूची केवल इतना कहती है कि “ये सभी इमेज महत्वपूर्ण हैं”, लेकिन यह नहीं बताती कि कौन-सी इमेज किस कारण महत्वपूर्ण है। मॉडल या बीच का एजेंट संबंध का अनुमान लगाता है। वह एक इमेज से रंग, दूसरी से टेक्सचर और तीसरी से कोई अवांछित ऑब्जेक्ट उठा सकता है, फिर एक देखने में संभव लेकिन लक्ष्य से भटका हुआ समझौता बना देता है।
ऐसी विफलता में कोई संरचनात्मक त्रुटि आना आवश्यक नहीं है। प्रमाणीकरण, अपलोड, अनुरोध सिंटैक्स और रिस्पॉन्स पार्सिंग सब सही चल सकते हैं। इसलिए HTTP सफलता या “generation completed” संदेश विज़ुअल स्वीकृति नहीं हो सकता। जनरेशन के बाद कंपोज़िशन जाँच अनिवार्य रखें।
चरण 1: हर रेफ़रेंस के लिए भूमिका अनुबंध लिखें
लंबा प्रॉम्प्ट लिखने से पहले हर इमेज के लिए चार प्रश्नों का उत्तर दें:
- क्या हर हाल में बचा रहना चाहिए? उदाहरण: विषय नीचे-बाएँ रहे, ऊपर हेडलाइन के लिए खुला हो और कैमरा एंगल नीचे से हो।
- क्या अनदेखा करना है? उदाहरण: स्टाइल रेफ़रेंस में व्यक्ति की पहचान, ब्रांड टेक्स्ट और बैकग्राउंड आर्किटेक्चर न लें।
- नियम कितना कठोर है? क्या कंपोज़िशन अनिवार्य है और रंग केवल पसंद, या इसका उल्टा?
- टकराव में किसकी जीत होगी? उदाहरण: ऑब्जेक्ट की स्थिति के लिए लेआउट रेफ़रेंस, स्टाइल इमेज से निकले संकेत पर प्राथमिकता रखेगा।
एक उपयोगी भूमिका अनुबंध ऐसा हो सकता है:
| फ़ाइल | भूमिका | सुरक्षित रखें | अनदेखा करें | टकराव का नियम |
|---|---|---|---|---|
layout.png | लेआउट | दो विषय, बड़ा-छोटा संबंध, दाएँ खाली जगह, ऊपर से दृश्य | रंग और सामग्री | सभी स्थानिक संबंधों में इसकी प्राथमिकता |
subject.png | विषय | सिलुएट और विशिष्ट विवरण | मूल बैकग्राउंड और कैमरा | लेआउट में विषय बदलें, उसकी जगह नहीं |
style.png | स्टाइल | गर्म ग्रे पैलेट, पेपर ग्रेन, मुलायम छाया | इमेज के लोग और टेक्स्ट | केवल दिखावट लें, सामग्री नहीं |
यह “रेफ़रेंस 1, 2, 3” से बेहतर है, क्योंकि इसमें वांछित संकेत और निषिद्ध ट्रांसफ़र दोनों स्पष्ट हैं।
चरण 2: सपाट सूची को पदानुक्रमित अनुरोध में बदलें
अलग-अलग टूल में वास्तविक API फ़ील्ड अलग होते हैं। नीचे का उदाहरण केवल एक वैचारिक अनुरोध संरचना है, किसी विक्रेता का वास्तविक API अनुबंध नहीं। इसका उपयोग यह जाँचने के लिए करें कि एजेंट अंतिम अनुरोध तक भूमिका की जानकारी बचाए रखता है या नहीं:
references:
- id: layout
source: layout.png
role: composition
preserve: [subject_count, position, scale, camera, negative_space]
- id: subject
source: subject.png
role: identity
preserve: [shape, distinctive_details]
- id: style
source: style.png
role: appearance
preserve: [palette, texture, line_quality, lighting]
exclude: [objects, text, composition]
priority:
- layout
- subject
- style
acceptance_reference: layout.png
मुख्य सवाल यह नहीं है कि आपके API में यही फ़ील्ड नाम हैं या नहीं। सवाल यह है कि पूरी श्रृंखला में यही अर्थ बचा रहता है या नहीं। एजेंट द्वारा भेजे गए अंतिम अनुरोध को देखें: क्या इमेज ऐरे एक जुड़े हुए स्ट्रिंग में बदल गया, क्या भूमिका विवरण सामान्य गद्य में मिल गया, या रीट्राई और बैच प्रोसेसिंग से फ़ाइल क्रम बदल गया?
यदि लक्ष्य API अलग रेफ़रेंस प्रकार, वेट या एडिट मास्क का दस्तावेज़ित समर्थन देता है, तो भूमिका अनुबंध को उसी स्कीमा से मैप करें। यदि ऐसा समर्थन नहीं है, तो काल्पनिक पैरामीटर न बनाएँ। इसके बजाय चरणबद्ध वर्कफ़्लो अपनाएँ।
चरण 3: जब टूल भूमिकाएँ व्यक्त न कर सके, दो चरणों में काम करें
यदि इंटरफ़ेस केवल एक बिना भेद वाली इमेज सूची स्वीकार करता है, तो पहले कंपोज़िशन लॉक करें और बाद में स्टाइल लगाएँ। यह सभी संकेत एक ही अनुरोध में डालने की तुलना में आसानी से जाँचा जा सकता है।
चरण A: कंपोज़िशन और विषय स्थापित करें
लेआउट रेफ़रेंस दें और केवल आवश्यकता होने पर विषय रेफ़रेंस जोड़ें। विषयों की संख्या, स्थान, कैमरा, क्रॉप और खाली जगह साफ लिखें। सामग्री, टेक्सचर और रेंडरिंग भाषा इस चरण से बाहर रखें। लक्ष्य है संरचनात्मक रूप से सही इमेज, भले वह अभी साधारण दिखे।
चरण B: दृश्य संरचना बदले बिना दिखावट लागू करें
चरण A के आउटपुट को नया बेस बनाएँ और स्टाइल रेफ़रेंस से एडिट या री-ड्रॉ करें। स्पष्ट लिखें कि विषयों की स्थिति, सीमाएँ, कैमरा, क्रॉप और नेगेटिव स्पेस स्थिर रहेंगे; केवल पैलेट, टेक्सचर, लाइन क्वालिटी और लाइटिंग बदल सकती है।
यदि मास्क उपलब्ध है, तो केवल वही क्षेत्र खोलें जिन्हें संपादित करना है। एडिट मोड न होने पर चरण A की इमेज को प्राथमिक रेफ़रेंस और स्टाइल इमेज को द्वितीयक रखें। स्पष्ट वेट उपलब्ध हैं या नहीं, यह मौजूदा टूल दस्तावेज़ पर निर्भर है।
चरण 4: संकेत कहाँ खो रहा है, यह जानने के लिए चार नियंत्रित टेस्ट चलाएँ
एक जटिल अनुरोध को बार-बार बदलते न रहें। प्रॉम्प्ट, आयाम और अन्य नियंत्रित सेटिंग को स्थिर रखते हुए चार वेरिएंट बनाएँ:
| टेस्ट | इनपुट | क्या जाँचें |
|---|---|---|
| A | केवल लेआउट रेफ़रेंस | क्या विषयों की संख्या, स्थान, कैमरा, क्रॉप और खाली जगह बचती है? |
| B | केवल स्टाइल रेफ़रेंस | वास्तव में कौन-से रंग, टेक्सचर, लाइन और लाइटिंग गुण ट्रांसफ़र होते हैं? |
| C | लेआउट और स्टाइल सपाट सूची में | क्या आउटपुट समझौता बनाता, स्टाइल औसत करता या अवांछित सामग्री लाता है? |
| D | स्पष्ट भूमिका और प्राथमिकता के साथ दोनों | क्या प्रत्येक लक्ष्य टेस्ट C से अधिक करीब है? |
यह किसी मॉडल के “अच्छा” या “खराब” होने का परीक्षण नहीं है। इससे पता चलता है कि टूटन अकेली इमेज की व्याख्या में है, कई इमेज को मिलाने में है या एजेंट की पैरामीटर हैंडलिंग में। यदि A और B सही हैं, C भटकता है और D सुधरता है, तो भूमिका की अस्पष्टता एक मजबूत संदेह है। यदि D और C समान हैं, तो अंतिम पेलोड देखें या चरणबद्ध विधि अपनाएँ।
यदि टूल seed का समर्थन करता है, तो सभी वेरिएंट में वही seed रखें ताकि यादृच्छिक अंतर कम हों। यदि seed नहीं है, तो तुलना को निर्धारक न मानें; हर वेरिएंट के कई नमूने बनाएँ और बार-बार आने वाली संरचनात्मक विफलताएँ देखें।
चरण 5: “अच्छा दिखता है” पर नहीं, लक्ष्य कंपोज़िशन पर स्वीकृति दें
खतरनाक आउटपुट हमेशा बदसूरत नहीं होता। वह इतना पॉलिश्ड हो सकता है कि जल्दी की समीक्षा में पास हो जाए, जबकि वास्तविक टेम्पलेट से चूक गया हो। स्टाइल पर राय देने से पहले कठोर कंपोज़िशन नियम जाँचें।
कठोर नियम: इनमें से कोई भी गलत हो तो उम्मीदवार अस्वीकार करें
- विषयों की संख्या सही है।
- स्थान और आपसी आकार लेआउट से मेल खाते हैं।
- कैमरा दिशा, क्रॉप और दृष्टिकोण सही हैं।
- टेक्स्ट के लिए आरक्षित जगह या नेगेटिव स्पेस मौजूद है।
- स्टाइल रेफ़रेंस के ऑब्जेक्ट, लोग या टेक्स्ट आउटपुट में नहीं आए हैं।
- विषय की विशिष्ट विशेषताएँ पहचानने योग्य हैं।
नरम नियम: बचे हुए उम्मीदवारों की रैंकिंग में उपयोग करें
- पैलेट लक्ष्य के करीब है।
- टेक्सचर और ग्रेन जानबूझकर बनाए हुए लगते हैं, धुँधले नहीं।
- लाइन, किनारे और छाया अपेक्षित दृश्य भाषा से मेल खाते हैं।
- परिणाम कई स्टाइल के औसत के बजाय एकसार महसूस होता है।
लेआउट रेफ़रेंस और हर उम्मीदवार को साथ रखकर प्रत्येक कठोर नियम के सामने पास या फ़ेल लिखें। केवल अंतिम इमेज न बचाएँ; अनुरोध संस्करण, रेफ़रेंस क्रम और एजेंट का वास्तविक अंतिम पेलोड भी रखें। इससे अगला ड्रिफ्ट दोहराने और सुधारने योग्य बनता है।
सामान्य लक्षणों को सही क्रम में जाँचें
| लक्षण | पहले क्या देखें | पसंदीदा प्रतिक्रिया |
|---|---|---|
| स्टाइल मजबूत, कंपोज़िशन बदल गया | क्या स्टाइल इमेज को समान प्राथमिक रेफ़रेंस माना गया? | लेआउट प्राथमिकता बढ़ाएँ या दो चरण अपनाएँ |
| कंपोज़िशन सही, स्टाइल कमजोर | क्या प्रॉम्प्ट में केवल अमूर्त मूड शब्द हैं? | दिखने योग्य रंग, सामग्री, लाइन और लाइटिंग गुण लिखें |
| कई स्टाइल सामान्य लुक में मिल गए | क्या विरोधी स्टाइल इमेज साथ दी गई हैं? | एक प्रमुख स्टाइल चुनें; बाकी से केवल एक खास गुण लें |
| स्टाइल इमेज का विषय आउटपुट में आ गया | क्या केवल दिखावट ट्रांसफ़र करने की सीमा लिखी थी? | उसके ऑब्जेक्ट, टेक्स्ट और कंपोज़िशन को स्पष्ट रूप से निष्कासित करें |
| प्रॉम्प्ट बदलने पर असर नहीं | क्या एजेंट ने नए पैरामीटर वास्तव में भेजे? | ऊपर के फ़ॉर्म नहीं, अंतिम पेलोड की तुलना करें |
| API सफल, आउटपुट लगातार भटकता है | क्या सफलता स्थिति को विज़ुअल स्वीकृति माना जा रहा है? | कठोर कंपोज़िशन गेट और नियंत्रित तुलना जोड़ें |
दोबारा उपयोग करने योग्य न्यूनतम वर्कफ़्लो
- केवल वही रेफ़रेंस चुनें जो काम पूरा करने के लिए आवश्यक हैं।
- हर इमेज को एक प्राथमिक भूमिका दें, साथ में preserve, ignore और conflict नियम लिखें।
- अंतिम एजेंट अनुरोध जाँचें कि ऐरे, क्रम और भूमिका जानकारी सपाट नहीं हुई।
- सपाट और भूमिका-आधारित वेरिएंट से पहले केवल-लेआउट और केवल-स्टाइल बेसलाइन चलाएँ।
- स्टाइल तुलना से पहले कठोर कंपोज़िशन नियमों पर उम्मीदवार अस्वीकार करें।
- उम्मीदवार, रेफ़रेंस, अनुरोध संस्करण और स्वीकृति परिणाम साथ रखें।
- इंटरफ़ेस भूमिकाएँ व्यक्त न कर सके तो पहले कंपोज़िशन, फिर स्टाइल वाला वर्कफ़्लो अपनाएँ।
लक्ष्य लंबा प्रॉम्प्ट नहीं है। लक्ष्य ऐसा वर्कफ़्लो है जिसमें हर विज़ुअल संकेत का एक मालिक हो। जब आप बता सकें कि “यह गुण कौन-सी इमेज नियंत्रित करती है, टकराव में कौन-सा नियम जीतेगा और पास होने की शर्त क्या है,” तब कई रेफ़रेंस एक ऐसी अस्पष्ट इमेज-ढेरी नहीं रहते जिसकी व्याख्या मॉडल को अकेले करनी पड़े।