मुख्य कंटेंट तक स्किप करें

मॉडलों के बीच प्रॉम्प्ट पोर्ट करना

मध्यम

आपके पास एक प्रॉम्प्ट है जो एक मॉडल पर बहुत बढ़िया काम करता है। अब आपको इसकी ज़रूरत किसी दूसरे पर है — कोई क्लाइंट GPT में रहता है, कोई लागत लक्ष्य आपको किसी ओपन मॉडल की ओर धकेलता है, या आप Claude का Gemini के ख़िलाफ़ A/B-टेस्टिंग कर रहे हैं। अच्छी ख़बर, जो हर प्रोवाइडर के अपने डॉक्स में दोहराई जाती है: एक अच्छे प्रॉम्प्ट की बुनियाद सार्वभौमिक होती है। जो बदलता है वह सतही परंपराओं की एक पतली परत है। यह पेज इन दोनों को अलग करता है ताकि आप किसी प्रॉम्प्ट को दोबारा लिखे बिना ले जा सकें, और आपको एक दोहराने योग्य माइग्रेशन वर्कफ़्लो के साथ एक पोर्टेबल टेम्पलेट देता है।

What you'll learn
  • जानें कि प्रॉम्प्ट के कौन-से हिस्से Claude, GPT, Gemini और ओपन मॉडलों के बीच साफ़-सुथरे ढंग से ट्रांसफर होते हैं
  • जानें कि किन हिस्सों को हर मॉडल के लिए समायोजन की ज़रूरत होती है — और क्यों
  • आज़माइश-और-भूल की दोबारा लिखाई के बजाय एक दोहराने योग्य माइग्रेशन वर्कफ़्लो चलाएँ
  • एक पोर्टेबल, मॉडल-निष्पक्ष प्रॉम्प्ट टेम्पलेट रखें जिसे आप हर लक्ष्य के लिए विशेष बना सकें

मानसिक मॉडल: संरचना ट्रांसफर होती है, परंपराएँ नहीं​

किसी भी प्रॉम्प्ट को दो परतों के रूप में सोचें:

  • तर्क परत (reasoning layer) — आप क्या पूछ रहे हैं, आप जो संदर्भ देते हैं, उदाहरण, और जो आउटपुट आप चाहते हैं। यह संप्रेषण के बारे में है, और यह मॉडलों के बीच लगभग अपरिवर्तित ट्रांसफर होती है।
  • परंपरा परत (convention layer) — यह विशेष मॉडल उस संप्रेषण को कैसे पैक करना चाहता है: सिस्टम प्रॉम्प्ट कहाँ जाता है और उसका कितनी सख़्ती से पालन होता है, वह XML को पसंद करता है या Markdown को, सटीक tool-call स्कीमा, इसकी डिफ़ॉल्ट बातूनीपन और रिफ़्यूज़ल मुद्रा, कौन-से जनरेशन पैरामीटर मौजूद हैं।

किसी प्रॉम्प्ट को पोर्ट करना लगभग कभी तर्क परत को दोबारा लिखना नहीं होता। यह परंपरा परत का पुनः-फ़िट है। इस भेद को सही समझ लें और माइग्रेशन रहस्यमय के बजाय यांत्रिक हो जाता है। (पहले किसी लक्ष्य को प्रोवाइडर-निष्पक्ष तरीक़े से चुनने के लिए, देखें मॉडल चुनना।)

क्या साफ़-सुथरे ढंग से ट्रांसफर होता है​

ये Claude, GPT, Gemini, और प्रमुख ओपन मॉडलों — सभी पर समान रूप से क़ायम रहते हैं — हर प्रोवाइडर के अपने best-practices डॉक्स स्वतंत्र रूप से इनकी सिफ़ारिश करते हैं:

  • एक स्पष्ट भूमिका + कार्य + स्पष्ट निर्देश। "आप X हैं। आपका काम Y है। इन नियमों का पालन करें।" हर प्रोवाइडर एक persona/role निर्माण का दस्तावेज़ीकरण करता है और अस्पष्ट के बजाय विशिष्ट, स्पष्ट निर्देशों को पुरस्कृत करता है।
  • ठोस उदाहरण (few-shot)। 2–5 इनपुट→आउटपुट जोड़े दिखाना किसी पैटर्न को उसका वर्णन करने की तुलना में अधिक विश्वसनीय ढंग से सिखाता है। तीनों प्रमुख प्रोवाइडर स्पष्ट रूप से few-shot उदाहरणों की सिफ़ारिश करते हैं; Gemini के डॉक्स तो यहाँ तक कहते हैं कि आप उन्हें लगभग हमेशा शामिल करें।
  • एक निर्दिष्ट आउटपुट फ़ॉर्मेट। "X, Y, Z कॉलम वाली एक Markdown टेबल लौटाएँ" या "केवल JSON, कोई गद्य नहीं" हर जगह काम करता है। निर्देश ट्रांसफर होता है, भले ही strict-mode तंत्र भिन्न हो (नीचे बताया गया है)।
  • Chain-of-thought / "जवाब देने से पहले तर्क करें।" कठिन कार्यों पर चरण-दर-चरण तर्क माँगना मॉडलों के बीच परिणाम सुधारता है। एक चेतावनी जो वाक़ई मॉडल-अनुसार है: समर्पित reasoning/thinking मॉडल अक्सर यह आंतरिक रूप से करते हैं, इसलिए स्पष्ट "step by step सोचें" बेमानी या यहाँ तक कि प्रतिकूल भी हो सकता है — समायोजन सूची देखें।
  • Grounding / RAG। "केवल नीचे दिए संदर्भ का उपयोग करें; अगर जवाब वहाँ नहीं है, तो कहें कि आप नहीं जानते।" पुनर्प्राप्त संदर्भ देने और मॉडल को उस तक सीमित रखने का अनुशासन सार्वभौमिक है — हर प्रोवाइडर RAG-शैली grounding को hallucination कम करने के तरीक़े के रूप में दस्तावेज़ित करता है।
  • लंबा संदर्भ पहले, प्रश्न आख़िर में रखना। दस्तावेज़ों/डेटा से शुरू करें, निर्देश पर ख़त्म करें। यह क्रम मॉडलों के बीच मदद करता है और Gemini के मार्गदर्शन में स्पष्ट रूप से इसका उल्लेख है।

अगर आपने प्रॉम्प्टिंग की बुनियाद को आत्मसात कर लिया है, तो आप पहले से ही पोर्टेबल 80% के मालिक हैं।

हर मॉडल के लिए किसे समायोजित करने की ज़रूरत है​

यह परंपरा परत है — वह हिस्सा जो सचमुच भिन्न होता है। जब आप ले जाएँ तो इन्हें पुनः-फ़िट करें:

पहलूमॉडलों के बीच क्या बदलता हैक्या करें
सिस्टम-प्रॉम्प्ट हैंडलिंग और वेटहर मॉडल में एक system/developer संदेश होता है, लेकिन यह उपयोगकर्ता टर्न को कितनी सख़्ती से ओवरराइड करता है यह भिन्न होता है। कुछ एक समर्पित developer/system भूमिका को उपयोगकर्ता निर्देशों से ऊपर वेट देते हैं; अन्य रेखा को धुंधला करते हैं।यह न मानें कि आपके सिस्टम प्रॉम्प्ट का उतनी ही ताक़त से पालन होता है। दोबारा जाँचें कि बाधाएँ वाक़ई क़ायम रहती हैं; अगर वे फिसलती हैं तो महत्वपूर्ण नियमों को ऊपर बढ़ाएँ।
XML बनाम Markdown बनाम डिलिमिटरClaude निर्देश/संदर्भ/उदाहरणों को अलग करने के लिए XML टैग विशेष रूप से अच्छी तरह पार्स करता है; GPT और Gemini XML स्वीकार करते हैं पर Markdown हेडिंग और डिलिमिटर पर भी झुकते हैं।कुछ स्पष्ट संरचना रखें; उसका स्वाद लक्ष्य की पसंद के अनुसार बदलें। अपने प्रॉम्प्ट के फ़ॉर्मेट को वांछित आउटपुट से मिलाना आउटपुट शैली को भी प्रभावित करता है।
Tool / function-calling JSON आकारलूप (टूल घोषित करें → मॉडल कॉल का अनुरोध करता है → आप निष्पादित करते हैं → परिणाम लौटाते हैं) हर जगह एक जैसा है; वायर फ़ॉर्मेट एक जैसा नहीं है — फ़ील्ड नाम, कॉल/परिणाम संदेश सूची में कैसे बैठते हैं, और strict-mode विकल्प भिन्न होते हैं।कभी कच्चे tool JSON को प्रोवाइडरों के बीच कॉपी न करें। लक्ष्य स्कीमा में पुनः-मैप करें। देखें टूल यूज़।
डिफ़ॉल्ट वर्बोसिटीनए मॉडल डिफ़ॉल्ट रूप से संक्षिप्त होने की ओर झुकते हैं और उम्मीद करते हैं कि आप विवरण माँगें; पुराने अधिक बातूनी थे।अगर आपने कोई प्रॉम्प्ट पोर्ट किया और जवाब छोटे/लंबे हो गए, तो प्रॉम्प्ट को दोष देने के बजाय वर्बोसिटी स्पष्ट रूप से सेट करें।
रिफ़्यूज़ल / सुरक्षा मुद्राहर मॉडल की सीमावर्ती अनुरोधों को अस्वीकार करने या हिचकिचाने की अपनी सीमा होती है, और इन्हें हर रिलीज़ पर फिर से ट्यून किया जाता है।पोर्ट करने के बाद एज केसों को दोबारा जाँचें। एक प्रॉम्प्ट जिसने एक मॉडल पर कभी रिफ़्यूज़ल ट्रिगर नहीं किया, उसे दूसरे पर फिर से ढालने की ज़रूरत पड़ सकती है।
जवाब को Prefill करनाकिसी फ़ॉर्मेट को मजबूर करने के लिए असिस्टेंट के मुँह में शब्द डालना एक क्लासिक Claude-युग का लीवर है — पर नए Claude मॉडल (4.6+) एक prefilled अंतिम असिस्टेंट टर्न को अस्वीकार करते हैं, और अन्यत्र समर्थन पूरी तरह भिन्न होता है।prefill को एक सीधे निर्देश ("बिना प्रस्तावना के जवाब दें"), एक आउटपुट स्कीमा, या tool calling से बदलें।
Stop sequences और max tokensसभी एक लंबाई सीमा उजागर करते हैं और अधिकांश stop sequences उजागर करते हैं, पर पैरामीटर नाम, डिफ़ॉल्ट, और सीमाएँ भिन्न होती हैं — और कुछ thinking-budget नॉब को effort/max_tokens के पक्ष में हटाया जा रहा है।लक्ष्य पर पैरामीटर नाम और सीमाएँ दोबारा जाँचें; यह न मानें कि आपके पुराने मान पोर्ट होते हैं।

एक माइग्रेशन वर्कफ़्लो​

पोर्टिंग को एक छोटे, अनुशासित लूप के रूप में लें, न कि अनुमान-और-जाँच की दोबारा लिखाई के रूप में।

Guided walkthrough1 of 6
  1. अपने मौजूदा प्रॉम्प्ट को पढ़ें और मानसिक रूप से बाँटें: तर्क परत (भूमिका, कार्य, संदर्भ, उदाहरण, आउटपुट स्पेक) बनाम परंपरा परत (XML/Markdown विकल्प, prefill, tool JSON, पैरामीटर)। आप पहली को रखेंगे और दूसरी को पुनः-फ़िट करेंगे।

:::tip शुरू से दोबारा न लिखें अगर आप ख़ुद को भूमिका, कार्य, या उदाहरण दोबारा बनाते हुए पाते हैं, तो रुकें — वह पोर्टेबल परत है। एक साफ़ पोर्ट पैकेजिंग बदलता है, अर्थ नहीं। :::

एक पोर्टेबल प्रॉम्प्ट टेम्पलेट​

अपने प्रॉम्प्ट को एक मॉडल-निष्पक्ष आकार में लिखें, फिर हर लक्ष्य के लिए केवल परंपरा परत को विशेष बनाएँ। यह कोर हल्की, सार्वभौमिक रूप से समझी जाने वाली संरचना का उपयोग करता है (यह Markdown के रूप में साफ़-सुथरा पढ़ा जाता है, और टैग Claude के लिए आसानी से XML में बदल जाते हैं):

मॉडल-निष्पक्ष प्रॉम्प्ट कोर — हर लक्ष्य के लिए परंपरा परत को विशेष बनाएँ

# ROLE
You are {role}.

# TASK
{One clear sentence describing the single goal.}

# RULES
- Use ONLY the information in CONTEXT below. If the answer is not there, say "I don't know" — do not guess.
- Be concise. Respond directly, with no preamble like "Here is..." or "Based on...".
- {Any other hard constraints.}

# OUTPUT FORMAT
{Exact format — e.g. "A Markdown table with columns Name, Value, Source." or "JSON only matching this schema: {...}".}

# EXAMPLES
Input: {example input 1}
Output: {ideal output 1}

Input: {example input 2}
Output: {ideal output 2}

# CONTEXT
{Retrieved documents / data go here — long content first.}

# REQUEST
{The actual user question, last.}

ऊपर लगाने के लिए प्रति-लक्ष्य समायोजन:

  • Claude — सेक्शन मार्करों को XML टैग में ले जाएँ (<role>, <rules>, <context>, <request>); यह उन्हें विशेष रूप से साफ़-सुथरे ढंग से पार्स करता है। मौजूदा मॉडलों पर prefilled असिस्टेंट टर्न का उपयोग न करें; इसके बजाय "no preamble" नियम या किसी tool/स्कीमा पर भरोसा करें।
  • GPT — RULES को system/developer संदेश में रखें ताकि वे अधिक वेट लें; Markdown हेडिंग ठीक हैं; स्कीमा को केवल गद्य में वर्णित करने के बजाय structured-output/strict JSON मोड का उपयोग करें।
  • Gemini — ROLE + RULES + OUTPUT FORMAT को system-instruction फ़ील्ड के ज़रिए पास करें, प्रॉम्प्ट को सीधा रखें (नया Gemini वर्बोज़ प्रॉम्प्ट की अति-व्याख्या कर सकता है), और CONTEXT को पहले और REQUEST को आख़िर में रखें।
  • ओपन मॉडल (Llama/Mistral/Qwen, आदि) — मॉडल के प्रकाशित chat template का ठीक-ठीक पालन करें, और स्पष्ट few-shot उदाहरणों तथा फ़ॉर्मेट बाधाओं पर अधिक ज़ोर दें, क्योंकि निर्देश-पालन आमतौर पर फ़्रंटियर क्लोज़्ड मॉडलों की तुलना में कम मज़बूत होता है।

त्वरित जाँच​

ख़ुद को परखें

0/3
  1. आप एक कार्यशील Claude प्रॉम्प्ट को GPT पर ले जा रहे हैं। किस हिस्से को आपको अनिवार्य रूप से अपरिवर्तित रखने की उम्मीद करनी चाहिए?
  2. आपका पोर्ट किया गया प्रॉम्प्ट अचानक नए मॉडल पर बहुत छोटे जवाब देता है। सबसे संभावित कारण?
  3. प्रोवाइडरों के बीच पोर्ट करते समय tool/function calling के बारे में क्या सच है?
पोर्टिंग चीट-शीट
कार्ड पलटने के लिए Enter या Space दबाएँ। कार्ड बदलने के लिए बाएँ और दाएँ तीर कुंजियों का उपयोग करें।शब्द दिखाया गया।
1 / 6
Key takeaways
  • एक प्रॉम्प्ट एक तर्क परत (ट्रांसफर होती है) प्लस एक परंपरा परत (हर मॉडल के लिए पुनः-फ़िट) है — दूसरी को पोर्ट करें, पहली को रखें।
  • स्पष्ट भूमिका/कार्य/निर्देश, few-shot उदाहरण, आउटपुट-फ़ॉर्मेट स्पेक, chain-of-thought, और RAG grounding Claude, GPT, Gemini और ओपन मॉडलों के बीच ट्रांसफर होते हैं।
  • सिस्टम-प्रॉम्प्ट वेट, XML बनाम Markdown संरचना, tool-call JSON, डिफ़ॉल्ट वर्बोसिटी, रिफ़्यूज़ल मुद्रा, prefill, और लंबाई पैरामीटर को हर लक्ष्य के लिए समायोजित करें।
  • वास्तविक इनपुट पर पहले/बाद में एक छोटा eval सेट चलाएँ; तर्क को छूने से पहले परंपराएँ ठीक करें।
  • एक मॉडल-निष्पक्ष टेम्पलेट प्लस प्रति-लक्ष्य समायोजन वर्ज़न कंट्रोल में रखें ताकि स्विच करना सस्ता हो।
  • विशिष्ट व्यवहार हर रिलीज़ पर बदलते हैं — पैरामीटर और सीमाएँ हर प्रोवाइडर के मौजूदा डॉक्स पर सत्यापित करें, कभी स्मृति से नहीं।

स्रोत और आगे पढ़ने के लिए​

आगे​