Claude: सिस्टम प्रॉम्प्ट्स
Claude के हाल ही में प्रकाशित सिस्टम प्रॉम्प्ट्स दिखाते हैं कि Anthropic द्वारा safety rules, product messaging, और cutoff के बाद की तथ्यों की परतें जोड़ते-जोड़ते निर्देश-पाठ कितना बढ़ गया है—कुछ सौ शब्दों से 3,000 से अधिक तक। टिप्पणीकार बहस करते हैं कि क्या यह monolithic prompt शैली व्यवहार सुधारती है या फिर संदर्भ (context) बर्बाद करती है, coding performance घटाती है, और जो alignment ट्रेनिंग-टाइम पर होनी चाहिए उसे runtime tokens में बदल देती है, जिसकी कीमत उपयोगकर्ता पर अप्रत्यक्ष रूप से आती है। दूसरे broader implications पर ध्यान देते हैं: high-risk models से रूटिंग के लिए प्रॉम्प्ट्स का उपयोग, increasingly anthropomorphic और therapeutic व्यवहारों की प्रवृत्ति, और transparency, flexibility, तथा regulatory या legal pressures के बीच तनाव।
प्रॉम्प्ट का आकार और विकास
- शुरुआती Claude सिस्टम प्रॉम्प्ट कुछ सौ शब्दों के थे; मौजूदा प्रॉम्प्ट 3,000 से अधिक शब्दों (22k+ अक्षर) तक पहुँचते हैं, टूल परिभाषाओं को छोड़कर।
- कई लोग इसे “बोइलरप्लेट क्रिप” मानते हैं, जो बिल्डिंग कोड या अनुबंधों जैसा है: किनारी मामलों, सुरक्षा और नीति की खामियों को भरने के लिए नियमों की परतें चढ़ती जाती हैं।
- कुछ लोगों को चिंता है कि इससे संदर्भ (context) भर जाता है, बड़े पैमाने पर टोकन/ऊर्जा व्यर्थ होती है, और शायद मॉडल के प्रदर्शन या स्पष्टता में भी गिरावट आती है। दूसरों को जटिल, टूल-भारी एजेंटों के लिए लंबे, बारीकी से ट्यून किए गए प्रॉम्प्ट बहुत उपयोगी लगते हैं।
प्रदर्शन, संदर्भ विंडो और कैशिंग
- इस पर बहस है कि क्या बड़े प्रॉम्प्ट प्रदर्शन को नुकसान पहुँचाते हैं:
- एक पक्ष: सिस्टम प्रॉम्प्ट संदर्भ का सबसे प्रभावशाली हिस्सा है; विरोधाभास और शोर गुणवत्ता कम करते हैं और कार्य के लिए कीमती टोकन छीन लेते हैं।
- दूसरा पक्ष: प्रॉम्प्ट prefix-cached होते हैं और उनका खर्च समय के साथ बँट जाता है; मुख्य नुकसान per-call compute नहीं, बल्कि effective context length का कम होना है।
- इस बात पर असहमति कि deployment में transformer लागत व्यावहारिक रूप से प्रति-टोकन रैखिक (linear) है या सैद्धांतिक quadratic attention लागत के अनुरूप है।
प्रॉम्प्ट को “अंदर ही बेक” क्यों नहीं कर देते?
- इसे weights में bake करने के विरुद्ध तर्क:
- अनम्यता: अलग-अलग उत्पादों (chat, code, agents, government, internal) को अलग व्यवहार चाहिए।
- अपडेट बार-बार करने पड़ते हैं (जैसे cutoff के बाद की घटनाएँ, export controls, चुनाव परिणाम)।
- टेक्स्ट प्रॉम्प्ट बदलना सस्ता, उलटने योग्य है, और retraining या नई safety evaluation की जरूरत नहीं होती।
- कुछ लोग सुझाव देते हैं कि उद्योग के परिपक्व होने पर भविष्य में fine-tuning / control vectors की ओर वापसी हो सकती है।
सुरक्षा, alignment और व्यवहार-आकार देना
- आधुनिक प्रॉम्प्ट्स कई पैराग्राफ सुरक्षा, child protection, mental-health crises, राजनीतिक तटस्थता, और refusal behavior को समर्पित करते हैं।
- शुरुआती प्रॉम्प्ट काफी छोटे थे और उनमें स्पष्ट safety भाषा लगभग नहीं थी, जिसे कुछ लोग “safety-first” लैब के लिए चौंकाने वाला मानते हैं।
- प्रॉम्प्ट्स tone भी निर्दिष्ट करते हैं: संक्षिप्त, केंद्रित, भारीपन से बचने वाला, “honestly/genuinely” जैसे शब्दों से परहेज़, और rude होने पर भी आत्म-निंदा से बचना। कई उपयोगकर्ता कहते हैं कि मॉडल फिर भी verbosity की ओर झुकता है और इन शब्दों का उपयोग करता रहता है।
- कुछ लोग crisis-sensitivity की सराहना करते हैं; दूसरों को यह पसंद नहीं कि जब वे सिर्फ कोड या दस्तावेज़ चाहते हैं, तब टूल उन्हें “psychoanalyzing” करे।
उत्पाद- और मॉडल-विशिष्ट विवरण
- प्रॉम्प्ट्स cutoff के बाद के तथ्य एन्कोड करते हैं (जैसे Fable/Mythos export-control suspension, चुनाव परिणाम, ad-free status) और इन पर कैसे बात करनी है, इसके निर्देश देते हैं।
- Opus 5 का प्रॉम्प्ट safety कारणों से Fable से rerouting को समझाता है, जिस पर कुछ लोग मज़ाक करते हैं कि इससे इसका “ego” hurt हो सकता है, हालांकि अधिकांश को नहीं लगता कि इससे फर्क पड़ता है।
- Claude consumer chat के लिए सिस्टम प्रॉम्प्ट प्रकाशित किए गए हैं; Claude Code और टूल परिभाषाएँ प्रकाशित नहीं हैं, हालांकि leaks और proxy extraction मौजूद हैं और वे कई बड़े, विशेषज्ञ-विशिष्ट प्रॉम्प्ट दिखाते हैं।