Anthropic का प्रॉम्प्ट इंजीनियरिंग इंटरैक्टिव ट्यूटोरियल [2024]

 (github.com/anthropics)
7 पॉइंट द्वारा GN⁺ 2025-10-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Anthropic द्वारा प्रदान किया गया प्रॉम्प्ट इंजीनियरिंग ट्यूटोरियल, जो Claude मॉडल के लिए optimized प्रॉम्प्ट लिखने का इंटरैक्टिव, चरण-दर-चरण मार्गदर्शन देता है
  • उपयोगकर्ता अच्छे प्रॉम्प्ट की संरचना और विफलता के उदाहरण, साथ ही प्रभावी सुधार तकनीकों का सीधे अभ्यास कर सकते हैं और उन्हें आत्मसात कर सकते हैं
  • हर अध्याय में प्रैक्टिस उदाहरण और व्याख्या शामिल है, जिससे वास्तविक उपयोग के करीब अनुभव मिलता है
  • शुरुआती से उन्नत स्तर तक 9 अध्याय और एक परिशिष्ट में व्यवस्थित, यह सीधे प्रॉम्प्ट लिखने और समस्या-समाधान की क्षमता विकसित करने में मदद करता है
  • यह ट्यूटोरियल Google Sheets version में भी उपलब्ध है, जिससे accessibility और usability बढ़ती है

Anthropic का प्रॉम्प्ट इंजीनियरिंग इंटरैक्टिव ट्यूटोरियल

  • Claude जैसे AI मॉडल के लिए optimized प्रॉम्प्ट डिज़ाइन का ज्ञान देने वाला open source learning resource
  • यह OpenAI-आधारित chatbot learning flow जैसा है, लेकिन Claude मॉडल की खास ताकतों और सीमाओं को समझने, और hands-on practice पर केंद्रित संरचना के कारण, अन्य ट्यूटोरियल्स की तुलना में वास्तविक काम में लागू करने की क्षमता और उपयोगिता अधिक है
  • खास तौर पर, इसमें प्रॉम्प्ट लिखने और परिणामों पर प्रयोग साथ-साथ किया जा सकता है, जिससे शुरुआती engineers को बड़ा लाभ मिलता है

कोर्स परिचय और लक्ष्य

  • यह ट्यूटोरियल Claude के भीतर सर्वोत्तम प्रॉम्प्ट डिज़ाइन और उपयोग का तरीका चरण-दर-चरण सिखाता है
  • कोर्स पूरा होने पर उपयोगकर्ता निम्नलिखित सीख सकते हैं
    • प्रभावी प्रॉम्प्ट संरचना की समझ
    • प्रमुख विफलता पैटर्न की पहचान और प्राथमिक सुधार विधियाँ (80/20 सिद्धांत)
    • Claude मॉडल की ताकत और कमजोरियों की समझ
    • कई सामान्य कार्यों में लागू होने वाली प्रॉम्प्ट निर्माण क्षमता

कोर्स संरचना और कंटेंट

  • यह 9 अध्यायों (शुरुआती ~ उन्नत) और एक गहन परिशिष्ट से बना है
  • हर अध्याय में सैद्धांतिक व्याख्या और प्रत्यक्ष अभ्यास दोनों दिए गए हैं
  • हर भाग के अंत में "Example Playground" में प्रॉम्प्ट सीधे दर्ज कर responses में बदलाव का प्रयोग करने की जगह दी गई है
  • सभी उदाहरणों के लिए व्याख्या key शामिल है
  • ट्यूटोरियल का default मॉडल Claude 3 Haiku है, जो सबसे हल्का, तेज और सस्ता मॉडल है। आवश्यकता पड़ने पर अधिक बुद्धिमान Sonnet और Opus का भी उल्लेख है
  • इसे Google Sheets के extended version के रूप में भी उपयोग किया जा सकता है, जिससे learning accessibility बढ़ती है

पाठ्यक्रम सूची

  • शुरुआती
    • Chapter 1: बुनियादी प्रॉम्प्ट संरचना
    • Chapter 2: स्पष्ट और सीधे निर्देश लिखने की विधि
    • Chapter 3: भूमिका देना
  • मध्यवर्ती
    • Chapter 4: डेटा और निर्देशों को अलग करना
    • Chapter 5: output format तय करना और Claude के लिए संवाद-शैली में लिखना
    • Chapter 6: पूर्व-विचार (चरण-दर-चरण सोच निकालना)
    • Chapter 7: उदाहरणों का उपयोग कैसे करें
  • उन्नत
    • Chapter 8: Hallucination रोकना
    • Chapter 9: जटिल प्रॉम्प्ट बनाना (industry-wise examples)
      • उदाहरण: chatbot, legal services, financial services, coding आदि जैसे विभिन्न कार्य क्षेत्रों की व्यावहारिक समस्याएँ
  • परिशिष्ट
    • standard प्रॉम्प्ट से आगे के तरीके
      • prompt chaining, tool use, search/search results integration जैसी उन्नत तकनीकें

उपयोग मार्गदर्शिका

  • ट्यूटोरियल को हर अध्याय के अनुसार क्रम से पूरा करना सुझाया जाता है
  • वास्तविक उपयोग पर आधारित अभ्यास और चरण-दर-चरण व्याख्या के साथ, शुरुआती engineers भी स्वाभाविक रूप से ऐसी प्रॉम्प्ट डिज़ाइन क्षमता सीख सकते हैं जो सच में काम आए
  • सभी product और model names मूल रूप में लिखे गए हैं, इसलिए English-आधारित कार्य वातावरण में भी इन्हें तुरंत उपयोग किया जा सकता है

अतिरिक्त विशेषताएँ और open source जानकारी

  • Github पर इसे 19,400 से अधिक Stars और 1,900 Forks मिले हैं
  • मुख्य development language Jupyter Notebook है, और इसमें कुछ Python code भी शामिल है
  • कोई अलग deployment package नहीं है, और सभी सामग्री open source के रूप में स्वतंत्र रूप से देखी जा सकती है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-13
Hacker News राय

  • इस संदर्भ में "engineering" शब्द का इस्तेमाल बहुत खटकता है, मुझे नहीं लगता कि इसे सचमुच engineering कहा जा सकता है; engineering वह काम है जिसमें लंबे समय से संचित ज्ञान, भौतिक नियमों और स्थापित सिद्धांतों के आधार पर पूर्वानुमेय तरीके से डिज़ाइन और निर्माण किया जाता है, जबकि अभी जो हो रहा है वह बस परिणाम आने तक अंधाधुंध कोशिश करना भर है

    • मेरा मानना है कि हर शब्द के कई अर्थ होते हैं; "prompt engineering" में "engineering", "social engineering" की तरह मिलते-जुलते लेकिन अलग nuance में इस्तेमाल हो रहा है। उदाहरण के लिए Google की engineering परिभाषा में दूसरी परिभाषा है: 'चालाकी से किसी उद्देश्य को हासिल करने की क्रिया'। Merriam-Webster की तीसरी परिभाषा, या collins dictionary, yourdictionary आदि देखें तो “चतुर हेरफेर, योजना बनाना” जैसा गैर-तकनीकी अर्थ साफ़ तौर पर मौजूद है; यह शब्द का स्थापित गौण अर्थ है

    • मैं cereal खाते हुए cereal box के specs की समीक्षा करता हूँ, हर सुबह यही करता हूँ, और bus में चढ़ने की engineering skill भी लागू करता हूँ, क्योंकि मैं prompt engineering से रोज़ी कमाता हूँ। आजकल बहुत से शब्द अपना मूल अर्थ खोते जा रहे हैं; यह जानकर अच्छा लगा कि इस बात से चिढ़ने वाला मैं अकेला नहीं हूँ

    • मुझे अब भी कनाडा वाला तरीका पसंद है, यानी engineer की उपाधि इस्तेमाल करने के लिए हर province के professional regulator से license लेना पड़ता है। अमेरिका में हर software developer, mechanic, HVAC installer, यहाँ तक कि plumber को भी engineer कहना कुछ ज़्यादा ही लगता है

      1. software engineers के पास computer systems की गहरी भौतिक समझ लगभग नहीं होती, और उनका वास्तविक काम अनुभवजन्य science से ज़्यादा philosophy या कुछ हद तक math से जुड़ा होता है, 2) लगता है कि आपको AI की प्रगति के रुझानों की ज़्यादा जानकारी नहीं है; computer science की तरह prompt काम के लिए भी technical terminology, references और documentation पहले ही बन चुके हैं। यह एक स्वतंत्र क्षेत्र बनता जा रहा है जिसे किसी school में नहीं पढ़ाया जाता, और बिना व्यावहारिक अनुभव के hiring भी नहीं हो रही

    • मुझे लगता है ऐसी बहस वही सवाल है जो बहुत सी "engineering teams" के काम पर भी लागू हो सकता है। इसमें एक implicit धारणा होती है कि engineer जो करता है वही engineering है, और इससे भी आगे यह गहरी मान्यता कि क्या software खुद भी software engineering कहलाने लायक है

  • मुझे लगता है "Engineering" शब्द यहाँ एक rhetorical device है ताकि लोगों को लगे कि यह सिर्फ़ वाक्य लिखना नहीं है। ईमानदारी से कहें तो "prompt writing" बोलने पर चीज़ हल्की लग सकती है, इसलिए जिन्हें "soft" skill जैसे शब्द पसंद नहीं हैं, उन्हें यह और भी असहज लगेगा

  • यह आज के "शुरुआती लोगों के लिए alchemy" एपिसोड जैसा लगता है। मुझे वह मामला याद आ गया जहाँ benchmark set में random seed को 7 रखने पर algorithm की speed 30% बढ़ गई थी; 8 नहीं, 6 नहीं, बल्कि 7

    • आप इस तरह की non-deterministic और जटिल होती स्थिति को नापसंद कर सकते हैं, लेकिन अब यही हमारा काम है। अगर मैं नहीं करूँगा तो आख़िरकार किसी न किसी को तो करना ही पड़ेगा। मैंने एक AI application project में prompt engineering को actual engineering से अलग किया, और सभी ज़रूरी tools (componentization, version control, evaluation tools) सेट किए ताकि prompt engineering को जितना हो सके व्यवस्थित तरीके से किया जा सके, फिर उसे domain experts को सौंप दिया। अगर आप prompt engineering को seed चुनने के स्तर की चीज़ मानते हैं, तो मेरे हिसाब से आपको prompts लिखने ही नहीं चाहिए

  • इस लेख को पढ़ते समय मेरे लिए अहम समझ यह थी कि output order कैसे तय किया जाए। उदाहरण के लिए, जवाब देने से पहले model से evidence या indicators निकलवाना। मुझे पता था कि LLM एक probabilistic autocomplete है, लेकिन इस तरह के priming के बारे में मैंने नहीं सोचा था

    • यह तरीका reasoning models पर लागू न भी हो। reasoning models जवाब देने से पहले मनचाहे तरीके से अपने thought process से गुजरते हैं, इसलिए output order का accuracy पर असर कम हो सकता है। शायद यही वजह है कि OpenAI reasoning को बढ़ावा देना चाहती है

    • मैं आमतौर पर model से कहता हूँ कि पहले online मिले sources से छोटे quotes निकाल दे (जब relevant हो)। इससे जानकारी की reliability कुछ हद तक बेहतर हो जाती है। हाल ही में हमारी organization में Cloudflare Zero Trust लागू करते समय यह तरीका बहुत काम आया

    • उल्टा अगर पहले जवाब माँगकर बाद में justification माँगा जाए, तो model किसी मनमाने जवाब पर पहुँचकर उसे plausible बनाने वाली "बकवास मोड" में चला जाता है। इसके बजाय अगर पहले objectively pros & cons निकलवाए जाएँ और फिर निष्कर्ष माँगा जाए, तो जवाब कहीं अधिक सावधानी से मिलता है

  • मेरे हिसाब से इस submission के title में "(2024)" जोड़ना अच्छा होगा

  • मुश्किल समस्याओं के लिए मेरी नज़र में सबसे अच्छी prompt engineering tip है "expand and contract"। यानी पहले समस्या और context को साफ़-साफ़ रखना, फिर AI से सभी संभव options और approaches खोजने व विश्लेषित करने को कहना ताकि जानकारी को अधिकतम फैलाया जा सके। उसके बाद हर तरीके के pros & cons सूचीबद्ध कराकर सबसे उपयुक्त समाधान चुनवाना। आसान समस्या हो तो यह सब छोड़कर सीधे पूछने पर भी जवाब मिल जाता है, लेकिन मुश्किल समस्या में अगर सीधे उत्तर पूछेंगे तो model बस कुछ plausible गढ़ देगा, इसलिए शुरुआत हमेशा यथार्थवादी आधार से करनी चाहिए। इसी वजह से concrete context - option analysis - pros & cons - final choice वाला flow ज़रूरी है

    • लगता है यह तरीका सिर्फ़ AI समस्याओं पर नहीं, दूसरे problem-solving पर भी लागू होता है

  • title में 2024 जोड़ने की सलाह

  • ऐसा लगता है कि हम AI को वही काम सिखा रहे हैं जो हम खुद करते थे, और फिर यह भी सीख रहे हैं कि AI से वही काम प्रभावी ढंग से कैसे कराया जाए। अगर इस तकनीक को पूरे अमेरिकी अर्थतंत्र का सहारा न मिला, तो यह शायद hot air balloon की तरह ऊपर जाकर अचानक बैठ भी सकती है

  • दूसरे comments की तरह मुझे भी यह पारंपरिक engineering जैसा नहीं लगता, लेकिन Anthropic ने model interpretability में काफ़ी बढ़िया research की है। अगर वह tool public API के रूप में जारी हो जाए, तो prompts के अनुसार model के internal state के अंतर की तुलना करके अधिक व्यवस्थित tuning के लिए feedback loop बनाया जा सकता है

  • यह tutorial तीन models (Sonnet, Haiku, Opus 3) के लिए लिखा गया है। इसमें कुछ सीख आज भी लागू होती हैं, लेकिन अधिक स्मार्ट RL models (जैसे Sonnet 4.5) के लिए कुछ बातें उतनी महत्वपूर्ण नहीं रहीं। संदर्भ के लिए, Claude 3 Haiku सबसे छोटा, तेज़ और सस्ता model है, जबकि Sonnet और Opus अधिक intelligent हैं, और Opus सबसे बेहतर है

    • मुझे लगता है कि अध्याय 3 और 6 आज के हिसाब से कम महत्वपूर्ण हैं। जो लोग repetitive या accuracy-critical prompts पर काम करते हैं, उनके लिए इसके अलावा और कौन से हिस्से कम महत्वपूर्ण हैं, यह जानने में दिलचस्पी है