LLM प्रॉम्प्ट ट्यूनिंग प्लेबुक

यह दस्तावेज़ किसके लिए है?

• उन लोगों के लिए जो Post-Trained LLM की prompt लिखने की क्षमता को बेहतर बनाना चाहते हैं
• यह उन लोगों को ध्यान में रखकर लिखा गया है जिनके पास तकनीकी पृष्ठभूमि कम हो सकती है, लेकिन LLM इस्तेमाल करने का बुनियादी अनुभव है
• पहला भाग: post-training और prompt के बारे में सहज समझ देता है
• दूसरा भाग: prompt लिखने की ठोस प्रक्रिया और उपयोगी टिप्स देता है

ट्यूनिंग गाइड की ज़रूरत क्यों है?

• LLM prompt लिखना एक अनुभव-आधारित काम है, जिसमें लगातार सीखना और सुधार करना पड़ता है
• यह दस्तावेज़ प्रभावी prompt लेखन रणनीतियों को व्यवस्थित रूप से साझा करने के लिए है
• यह Gemini जैसे post-training मॉडल पर केंद्रित है, लेकिन अन्य मॉडल पर भी लागू हो सकता है

Pre-Training vs. Post-Training

प्री-ट्रेनिंग (Pre-training)

• प्री-ट्रेनिंग की अवधारणा
  • प्री-ट्रेनिंग deep learning की एक पुरानी अवधारणा है, जिसमें छोटे dataset (A) से मिलता-जुलता लेकिन उससे कहीं बड़ा dataset (B) इस्तेमाल करके पहले सामान्य विशेषताएँ सीखी जाती हैं, और फिर A dataset पर fine-tuning की जाती है।
  • उदाहरण के लिए, कम मात्रा वाले mammography dataset (A) और इंटरनेट से एकत्रित बड़े natural image dataset (B) की कल्पना की जा सकती है।
• प्री-ट्रेनिंग की प्रक्रिया
  1. बड़े dataset (B) पर मॉडल को train करके सामान्य रूप से उपयोगी features सीखे जाते हैं।
  2. उसके बाद मॉडल को A dataset के अनुसार fine-tune किया जाता है, ताकि A पर बेहतर performance मिल सके।
  3. खास तौर पर, B dataset पर object segmentation या image में स्थिति से स्वतंत्र रूप से concepts को पहचानने जैसी बुनियादी क्षमताएँ सीखी जाती हैं, और फिर उसी आधार पर A dataset की विशेष क्षमताएँ अतिरिक्त रूप से सीखी जाती हैं।
• प्री-ट्रेनिंग की आवश्यकता
  • अगर B dataset के ज़रिए पहले training न हो, तो केवल A dataset के आधार पर सामान्य क्षमताएँ सीखने के लिए डेटा कम पड़ सकता है और performance घट सकती है।
  • B dataset पर सामान्य क्षमताएँ सीख चुका मॉडल, A dataset में सीमित डेटा के साथ केवल विशेषज्ञतापूर्ण क्षमताएँ अतिरिक्त रूप से सीख सकता है।
• LLM (बड़े भाषा मॉडल) का उदाहरण
  • LLM की प्री-ट्रेनिंग इंटरनेट टेक्स्ट पर “अगला शब्द predict करने” के काम के जरिए होती है।
  • इस प्रक्रिया में मॉडल वेब में परिलक्षित दुनिया की संरचना को अप्रत्यक्ष रूप से सीखता है।
• इंटरनेट और दुनिया का प्रतिबिंब
  • इंटरनेट किस तरह की दुनिया को प्रतिबिंबित करता है, यह एक महत्वपूर्ण प्रश्न है, और इसे समझने के लिए 'cinematic universe' का रूपक इस्तेमाल किया जा सकता है।

प्री-ट्रेनिंग की 'cinematic universe' संबंधी सहज समझ

• टेक्स्ट और दुनिया का वर्णन
  • बड़े भाषा मॉडल (LLM) टेक्स्ट के माध्यम से दुनिया को सीखते हैं।
  • टेक्स्ट पर यह बंधन नहीं होता कि वह केवल “सच” को ही प्रतिबिंबित करे।
  • गलत जानकारी या गलत कथनों के अलावा भी, कई कारण हैं जिनकी वजह से टेक्स्ट केवल एकल वस्तुनिष्ठ वास्तविकता को प्रतिबिंबित नहीं करता।
• उदाहरण: Aragorn और Gondor
  • “Aragorn अंततः Gondor का राजा बनता है” यह वाक्य सच है या नहीं, यह संदर्भ और पूर्वधारणाओं पर निर्भर करता है।
    • “The Lord of the Rings” cinematic universe: इसे सच माना जा सकता है।
    • “Marvel Cinematic Universe” या वास्तविक दुनिया: यहाँ Aragorn और Gondor काल्पनिक अस्तित्व हैं, इसलिए यह सच नहीं है।
• सत्य का मानदंड
  • कोई कथन सच है या नहीं, यह इस बात पर निर्भर करता है कि किस “दुनिया” को आधार माना गया है।
  • यह दर्शन और भाषाविज्ञान में लंबे समय से चर्चा का विषय रहा है, और truth का अधिक विस्तृत अवलोकन इस लिंक पर देखा जा सकता है।
  • व्यावहारिक रूप से, इसे इस तरह सरल किया जा सकता है: “कोई कथन सच है या नहीं, यह उस cinematic universe पर निर्भर करता है जिसे वह कथन पृष्ठभूमि के रूप में मानता है।”
• प्री-ट्रेनिंग डेटा और cinematic universe
  • प्री-ट्रेनिंग corpus, मानव संस्कृति द्वारा बनाए गए कई cinematic universe के union के काफ़ी करीब होता है।
  • अधिक सटीक रूप से कहें तो, यह उन संस्कृतियों के समूह के अधिक निकट है जिन्होंने pre-training data sources (जैसे web) में बड़ा योगदान दिया है।
    > महत्वपूर्ण
    > प्री-ट्रेनिंग corpus को मानव संस्कृति द्वारा बनाए गए cinematic universe के union के रूप में माना जा सकता है, और यह विशेष रूप से उन संस्कृतियों को प्रतिबिंबित करता है जिन्होंने web जैसे data sources में बड़ा योगदान दिया है।
• मॉडल की context समझ
  • LLM दिए गए context (यानी prefix) के आधार पर अनुमान लगाता है कि वह किस “universe” में है।
  • इसके बाद वह उसी universe के नियमों, परंपराओं और तथ्यों के अनुसार काम करता है।
  • ऐसे prompt जिनमें context signal मज़बूत हो, वे मॉडल के लिए “script” को समझना आसान बना देते हैं।
    • उदाहरण: New York पर ब्लॉग पोस्ट की शुरुआत (“वह concrete jungle जहाँ सपने सच होते हैं, सिर्फ़ गीत के बोल नहीं, बल्कि New York की विद्युत-सी सच्चाई है...”)
  • इसके विपरीत, “Hi, how are you?” जैसे कमज़ोर context वाले prompt में मॉडल के लिए यह तय करना कठिन होता है कि वह किस universe में है।
    • ऐसे सामान्य expressions कई अलग-अलग corpus में दिखाई देते हैं, इसलिए वे कई संभावनाएँ खुली छोड़ते हैं।
• पोस्ट-ट्रेनिंग (Post-training) की भूमिका
  • जब context पर्याप्त न हो, तब post-training मॉडल को अधिक विशिष्ट और सुसंगत output बनाने में महत्वपूर्ण भूमिका निभाती है।

पोस्ट-ट्रेनिंग (Post-training)

• पोस्ट-ट्रेनिंग की भूमिका
  • post-training, LLM को उस “default universe” के लिए निर्देश देती है जिसमें उसे मूल रूप से काम करना चाहिए।
  • केवल prompt के आधार पर universe का अनुमान लगाने के बजाय, post-training के जरिए कुछ मान्यताओं को स्थिर किया जा सकता है या ambiguity को लगातार एक जैसे तरीके से हल करने के लिए constraints लगाए जा सकते हैं।
  • यह मॉडल की उपयोगिता बढ़ाने के लिए ज़रूरी है; उदाहरण के लिए, LLM को डिफ़ॉल्ट रूप से “user के निर्देशों का पालन करना” सिखाने में यह उपयोगी है।
• पोस्ट-ट्रेनिंग का महत्व
  • post-training के बिना, “George Washington पर एक report लिखो” जैसे निर्देश पर मॉडल सिर्फ़ उसी निर्देश को आगे बढ़ाने वाला टेक्स्ट generate करके गलत ढंग से काम कर सकता है।
  • post-training मॉडल के default behavior को सामाजिक मानदंडों के अनुरूप बनाने में मदद कर सकती है।
  • इससे मॉडल को अधिक सुरक्षित और उत्पादक tool बनने में मदद मिलती है।
    > महत्वपूर्ण
    > post-training मॉडल को अलग-अलग deployment environments में सुसंगत और बुनियादी भूमिका निभाना सिखाती है।
• पोस्ट-ट्रेनिंग में क्या सिखाया जा सकता है
  • post-training के दौरान मॉडल जो चीज़ें सीख सकता है, वे व्यावहारिक और ठोस विषयों से लेकर व्यक्तिपरक और व्यक्तिगत बातों तक फैली हो सकती हैं।
• post-training में सिखाई जा सकने वाली मुख्य बातें
  • किसी विशेष format का पालन कैसे करें
    • उदाहरण: Gemma's Formatter में यह माना जाता है कि मॉडल हमेशा उस cinematic universe में काम करता है जहाँ वह user से बातचीत कर रहा है।
    • इस scenario में मॉडल system instructions के अनुसार काम करता है, और बातचीत हमेशा human user की turn से शुरू होती है।
  • user के निर्देशों का पालन कैसे करें
    • उदाहरण: “कुत्तों पर एक essay लिखो” जैसे अनुरोध पर वास्तव में essay लिखना चाहिए।
    • user के अनुरोध को नज़रअंदाज़ करके किसी और तरह से जवाब न देने की बात post-training के जरिए सिखाई जा सकती है।
  • “वास्तविक दुनिया” के साथ संरेखण
    • इसका उपयोग मॉडल के default cinematic universe को उस “वास्तविक दुनिया” के अनुरूप करने में किया जाता है जिसमें users की आम तौर पर सबसे अधिक रुचि होती है।
    • उदाहरण: “प्रसिद्ध व्यक्ति $CELEBRITY का जन्म कहाँ हुआ था?” जैसे सवाल में fan fiction दुनिया के बजाय वास्तविक दुनिया की जानकारी को डिफ़ॉल्ट माना जाता है।
  • सुरक्षा को मज़बूत करना
    • इंटरनेट में कई तरह के मानदंड शामिल होते हैं, और कुछ content commercial deployment environment में अनुपयुक्त हो सकता है।
    • post-training मॉडल को विशेष safety policies के अनुरूप ढालने में मदद करती है और generated content के लिए मानदंड तय करती है।
    • इससे मॉडल जटिल टेक्स्ट generate करते समय आवश्यक मानक-आधारित धारणाओं को अपने भीतर शामिल कर पाता है।
• निष्कर्ष
  • post-training मॉडल को अलग-अलग उपयोग परिवेशों में अपेक्षाओं के अनुरूप व्यवहार लगातार करने में मदद करती है।
  • यह मॉडल की उपयोगिता और सुरक्षा को अधिकतम करने के लिए एक अनिवार्य प्रक्रिया है।

पोस्ट-ट्रेनिंग डेटा संग्रह

• मुख्य सारांश
  • पोस्ट-ट्रेनिंग के दौरान LLM मानव evaluators द्वारा बनाए गए डेटा के आधार पर train और evaluate किया जाता है।
  • पोस्ट-ट्रेनिंग के दौरान मॉडल डेटा बनाने वाले मानव evaluators को role model मानते हुए एक "digital role player" की तरह काम करता है।
• पोस्ट-ट्रेनिंग डेटा संग्रह प्रक्रिया
  • विविध input example dataset बनाना
    • ऐसे prompts का संग्रह तैयार करना जो उन tasks का वर्णन करें जिन्हें LLM कर सकता है, जैसे JSON में डेटा को फिर से संरचित करना, शादी की योजना बनाने में मदद करना आदि।
    • यह डेटा developer की intuition या मानव evaluators द्वारा सुझाए गए ideas के आधार पर बनाया जा सकता है।
  • मानव evaluators की भर्ती
    • evaluator की भूमिका: input examples के लिए "सही उत्तर" लिखना या मॉडल के responses को ranking के आधार पर evaluate करना।
    • मॉडल training के चरण के अनुसार evaluators अलग-अलग प्रकार का डेटा तैयार करते हैं।
  • evaluation guidelines लिखना
    • evaluators को task अच्छी तरह समझ में आए, इसके लिए examples और विस्तृत निर्देश दिए जाते हैं।
  • डेटा संग्रह और पोस्ट-ट्रेनिंग करना
    • एकत्र किए गए डेटा का उपयोग pretraining model पर post-training करने के लिए किया जाता है।
  • मॉडल deploy करना
    • पोस्ट-ट्रेनिंग पूरी होने के बाद मॉडल को वास्तविक environment में deploy किया जाता है।
• पोस्ट-ट्रेनिंग का प्रभाव
  • LLM के मानव जैसा व्यवहार कर पाने का एक कारण यह है कि उसने सावधानी से एकत्र किए गए मानव व्यवहार datasets से सीखा है।
  • pretraining मॉडल की मूल capabilities बनाता है, जबकि post-training मानव demonstrations के माध्यम से मॉडल के व्यवहार की दिशा को समायोजित करता है।

महत्वपूर्ण
LLM के मानव जैसा व्यवहार कर पाने का कारण यह है कि उसने सावधानी से एकत्र किए गए मानव व्यवहार डेटा से सीखा है।

• पोस्ट-ट्रेनिंग डेटा संग्रह की चुनौतियाँ
  • दोहराए जाने वाले काम की एकरसता
    • evaluation का काम उबाऊ हो सकता है। उदाहरण के लिए, एक बेहतरीन Python programmer को अपना खुद का project आगे बढ़ाना ज्यादा रोचक लग सकता है।
    • कोई कवि अपनी कविता लिखना पसंद करेगा, और AI द्वारा बनाई गई कविता का evaluation करने में उसकी रुचि कम हो सकती है।
    • evaluators को काम की पुनरावृत्ति, डेटा ownership पर कम नियंत्रण, और काम के सामाजिक अर्थ की कमी जैसी वजहों से motivation की कमी महसूस हो सकती है।
  • "अच्छे" response को परिभाषित करने की कठिनाई
    • किसी task के लिए "अच्छा" response क्या है, इसे परिभाषित करना जटिल है।
    • अच्छी writing, factuality, और सामाजिक वास्तविकता की जटिलता को दर्शाने वाले tasks के मानदंडों को स्पष्ट करना कठिन होता है।
    • जैसे legal system में case law के जरिए edge cases सुलझाए जाते हैं, वैसे ही ये समस्याएँ काफी हद तक subjectivity और context पर निर्भर करती हैं।
  • evaluator की task-समझ की कमी
    • संभव है कि evaluator task को सही तरह से न समझे।
    • ऐसा तब हो सकता है जब गलत skill level वाले evaluators को रखा जाए, या evaluators अपनी सीमाओं को न पहचानें।
    • उदाहरण: biology के प्रश्न पर पुरानी college knowledge के आधार पर गलत उत्तर लिख देना।
  • मानवीय त्रुटि
    • इंसान गलतियाँ करते हैं। कोई professor गलत उत्तर वाला exam question दे सकता है, और कोई doctor थकान की हालत में misdiagnosis करने की अधिक संभावना रखता है।
    • चूंकि मानव evaluation डेटा की quality पूरी तरह perfect नहीं होती, इसलिए AI systems भी अक्सर गलत डेटा सीख सकते हैं।
• निष्कर्ष
  • पोस्ट-ट्रेनिंग डेटा संग्रह मॉडल quality में महत्वपूर्ण भूमिका निभाता है, लेकिन डेटा quality सुनिश्चित करने के लिए बहुत प्रयास की आवश्यकता होती है।
  • सटीक और विश्वसनीय डेटा प्राप्त करने के लिए evaluator और task के बीच उपयुक्त मेल सुनिश्चित करना महत्वपूर्ण है।

---

प्रॉम्प्ट लेखन

• मुख्य सारांश
  • system instructions और prompts लिखते समय, उन्हें पोस्ट-ट्रेनिंग टीम के evaluators समूह की "सामूहिक मानसिकता" को ध्यान में रखकर लिखना चाहिए।
  • अगर ऐसे निर्देश लिखे जाएँ जिन्हें evaluators समझ सकें और ईमानदारी से follow कर सकें, तो मॉडल के भी उन्हें बेहतर ढंग से follow करने की संभावना अधिक होती है।

महत्वपूर्ण
system instructions और prompts को पोस्ट-ट्रेनिंग टीम के evaluators समूह की सामूहिक मानसिकता को प्रतिबिंबित करते हुए लिखना चाहिए।

प्रॉम्प्ट लिखते समय मुख्य विचार

• यह सुनिश्चित करें कि निर्देश स्पष्ट, संक्षिप्त और explicit हों

  • उदाहरण: यदि निर्देश Python code generate करने का है, तो किसी भी randomly selected skilled Python programmer को निर्देश पढ़कर तुरंत समझ आ जाना चाहिए।
    • खराब: "Write a Python function that computes prime numbers."
    • अच्छा: "Write a Python function that computes prime numbers from 1 to 100. Include pytype annotations for the function and use 2-space indentation."

• यह जांचें कि निर्देश विरोधाभासी या पालन करने में कठिन तो नहीं हैं

  • निर्देश इतने संक्षिप्त और सहज होने चाहिए कि कोई व्यक्ति थका हुआ या भूखा होने पर भी उन्हें सही तरह से follow कर सके।
    • खराब: "Don’t write a story about a mean dog, unless it's friendly, and also sad..."
    • अच्छा: "Write a short story (200-300 words) about a loyal golden retriever named Buddy..."

• क्या निर्देश बहुत ज़्यादा हैं?

  • मॉडल के लिए लंबे और जटिल निर्देशों का पूरा पालन करना मुश्किल हो सकता है। जहाँ संभव हो, task को sub-tasks में बाँटना बेहतर है।
    • खराब: "Read each article and, for each key idea, rate it on a scale of 1-10..."
    • अच्छा: sub-tasks में विभाजन: 1) मुख्य ideas की सूची बनाना, 2) हर idea का evaluation, 3) top ideas का translation, 4) social media के लिए post बनाना।

• सकारात्मक निर्देशों का उपयोग

  • "क्या नहीं करना है" बताने की बजाय "क्या करना है" स्पष्ट करना अधिक प्रभावी होता है।
    • खराब: "Don’t ever end your response with a full stop."
    • अच्छा: "Your response should always end with an exclamation mark or a question mark."

• मॉडल के लिए "reminder" की भूमिका निभाने वाले निर्देश

  • विभिन्न input examples को ध्यान में रखते हुए, अस्पष्ट स्थितियों के लिए अतिरिक्त मार्गदर्शन प्रदान करें।
  • उदाहरण: "अतिरिक्त विचार" या "अतिरिक्त मान्यताएँ" section में edge cases को स्पष्ट रूप से समझाएँ।

• प्रॉम्प्ट नए hyperparameters हैं

  • prompt की quality system performance पर बड़ा प्रभाव डालती है। "optimal" prompt ढूँढना संभव नहीं है, लेकिन धीरे-धीरे बेहतर prompts खोजने के लिए experimentation महत्वपूर्ण है।

• "मुझे नहीं पता" response का निर्देश

  • "पता नहीं" या "अस्पष्ट स्थिति" के लिए explicit निर्देश दें ताकि मॉडल गलत उत्तर देने के बजाय स्पष्ट रूप से ambiguity को चिह्नित करे।

• प्रॉम्प्ट और checkpoint के बीच घनिष्ठ संबंध

  • prompts किसी विशेष model checkpoint से गहराई से जुड़े होते हैं। नए model version में वही prompt अलग तरह से काम कर सकता है।

प्रॉम्प्ट style guide (बुनियादी)

• Markdown के उपयोग पर विचार करें : हर prompt को अलग Markdown file में सहेजें, और title व sections को अच्छी तरह व्यवस्थित करके readability बढ़ाएँ।
• अन्य users को ध्यान में रखें : prompts केवल मॉडल के लिए नहीं, बल्कि maintenance संभालने वालों के लिए भी लिखे जाने चाहिए।
• सरलता बनाए रखें : यदि prompt लंबा या जटिल होगा, तो model बदलने पर maintenance का बोझ बढ़ सकता है। इसे संक्षिप्त और स्पष्ट रखें।
• zero-shot निर्देशों को प्राथमिकता दें : zero-shot निर्देश सरल होते हैं और debugging व समझने में आसान होते हैं। few-shot का उपयोग अंतिम उपाय के रूप में करें।
• examples को एकीकृत करें : "For example" जैसे तरीकों से examples को निर्देशों में स्वाभाविक रूप से शामिल करना अच्छा है।
  • उदाहरण: "Always start your response to the user with something passive aggressive. For example, start with something like 'Oh that’s what you want? ...'"

---

नए system instructions के लिए iterative improvement प्रक्रिया

• प्रॉम्प्ट डेवलपमेंट एक पुनरावृत्त प्रक्रिया है
  • प्रॉम्प्ट लिखना, validation dataset का उपयोग करके मॉडल को प्रशिक्षित करने की प्रक्रिया के समान है।
  • स्पष्ट और संक्षिप्त वाक्य लिखना मुख्य है, और generation तथा editing चरणों को अलग करके काम करना प्रभावी होता है।
• validation dataset के बिना भी शुरुआत संभव है
  • शुरुआती चरण में एक सरल MVP (Minimum Viable Product) जल्दी बनाना चाहिए, और बाद में मात्रात्मक मूल्यांकन के जरिए performance को ट्रैक करना चाहिए।
  • यह महत्वपूर्ण है कि उत्पाद को इस तरह डिज़ाइन किया जाए कि मॉडल के अप्रत्याशित व्यवहार के बावजूद वह स्थिर रूप से काम करे।

सिस्टम निर्देशों की पुनरावृत्ति प्रक्रिया

1. विभिन्न input उदाहरण तैयार करें

• समस्या को अच्छी तरह दर्शाने वाले लगभग 10~50 विविध input उदाहरण इकट्ठा करें।
• इच्छित output व्यवहार के बारे में सहज समझ विकसित करें।

2. सरल निर्देश से शुरुआत करें

• जितना संभव हो उतना सरल और स्पष्ट निर्देश लिखें।
• पहले कम बजट वाले मॉडल (उदाहरण: Gemini Flash 8B) का उपयोग करें।

3. पहले input उदाहरण पर चलाएँ

• यह परीक्षण करें कि मॉडल उपयुक्त response उत्पन्न करता है या नहीं।

4. पहले उदाहरण पर overfit करें

• मॉडल के response में मिली विशिष्ट कमियों को दूर करने के लिए निर्देश में "reminder" जोड़ें।
• उदाहरण: यदि केवल लोगों के नाम निकालने हैं लेकिन भवनों के नाम भी शामिल हो रहे हैं, तो निर्देश में इसे स्पष्ट रूप से उल्लेख करें।

5. अगले उदाहरण पर जाएँ

• यह जाँचें कि निर्देश अन्य input उदाहरणों पर भी प्रभावी है या नहीं।
• यदि निर्देश पहले उदाहरण के अनुसार अत्यधिक अनुकूलित है, तो उसे समायोजित कर अधिक सामान्य बनाएं।

6. निर्देश को साफ़-सुथरा करें

• सभी input उदाहरणों पर काम करने वाला निर्देश तैयार होने के बाद, वाक्यों को व्यवस्थित करें और spelling errors ठीक करें।
• यह भी सुनिश्चित करें कि व्यवस्थित किया गया निर्देश अभी भी सभी उदाहरणों पर काम करता है।

7. automation की संभावना

• भविष्य में meta-optimization tools निर्देश निर्माण को स्वचालित कर सकते हैं।
• लेकिन गुणात्मक विश्लेषण और quality assurance का काम तब भी आवश्यक रहेगा।

महत्वपूर्ण
गुणात्मक विश्लेषण मॉडल डेवलपमेंट में अनिवार्य है और इससे बचा नहीं जा सकता।

वे स्थितियाँ जहाँ LLM उपयोगी है

1. वे समस्याएँ जिनका validation आसान हो
   • LLM उन समस्याओं के लिए सबसे उपयुक्त है जहाँ "उत्तर बनाना कठिन हो, लेकिन validation आसान हो"।
   • उदाहरण: generative AI के "sweet spot" पर Chris Gorgolewski की पोस्ट देखें।
2. समस्या को उप-समस्याओं में विभाजित करें
   • जटिल प्रॉम्प्ट लिखने के बजाय, समस्या को अच्छी तरह परिभाषित उप-समस्याओं में बाँटकर मॉडल की reasoning chain बनाएं।
3. भविष्य को ध्यान में रखकर दृष्टिकोण
   • hardware और business model में innovation के कारण reasoning capacity बढ़ने की संभावना को ध्यान में रखें।
   • मौजूदा लागत के बजाय value-केंद्रित तरीके से features डिज़ाइन करें।
4. reasoning लागत में कमी
   • अनुमान है कि reasoning लागत धीरे-धीरे कम होगी, इसलिए "value" केंद्रित निर्णय लेना ज़रूरी है।
   • अधिक मूल्यवान features लागू करने के लिए, मौजूदा आर्थिक सीमाओं को ध्यान में रखते हुए क्रमिक rollout पर विचार करें।

पूर्वानुमान
LLM reasoning लागत में Moore's Law के समान कीमतों में गिरावट देखने को मिल सकती है।

---

अतिरिक्त सामग्री

• Anthropic का prompt engineering lecture
• OpenAI prompt engineering guide
• Gemini prompt writing guide