- चर्चा अब "prompt engineering" से आगे बढ़कर "context engineering" की ओर शिफ्ट हो रही है
- Context सिर्फ एक prompt sentence नहीं है, बल्कि वह सारी जानकारी है जिसे LLM जवाब बनाने से पहले देख सकता है — जैसे निर्देश, conversation history, long-term memory, external information, available tools आदि
- अब एजेंट की सफलता और विफलता model performance से ज्यादा context की quality पर निर्भर है
- उन्नत agent यूज़र के calendar, पुराने emails, contacts जैसी अलग-अलग contextual जानकारी को जोड़कर वास्तविक समस्या-समाधान के ज्यादा करीब जवाब बना सकते हैं
- Context engineering एक situation-specific dynamic system design है, जिसमें सही जानकारी और tools को सही समय पर LLM तक पहुँचाया जाता है
Context Engineering क्या है
- हाल के समय में AI क्षेत्र में "context engineering" शब्द तेज़ी से फैल रहा है
- जहाँ पारंपरिक "prompt engineering" एक single question या command के design पर केंद्रित था, वहीं context engineering उससे कहीं अधिक व्यापक और शक्तिशाली approach है
- Tobi Lutke इसे "LLM को किसी task को भरोसेमंद तरीके से हल करने के लिए पूरा context देने की कला" के रूप में परिभाषित करते हैं
Context के मुख्य तत्व
- किसी agent system के सफलतापूर्वक काम करने का सवाल काफी हद तक इस बात पर निर्भर करता है कि working memory में कौन-सी जानकारी शामिल होगी
- ज्यादातर agent failures model की समस्या नहीं, बल्कि उपयुक्त context की कमी के कारण होते हैं
Context के घटक तत्व
- System prompt/निर्देश: model के व्यवहार को परिभाषित करने वाले मूल निर्देश, उदाहरण और नियम
- User prompt: यूज़र का तत्काल अनुरोध या सवाल
- State/conversation history: अब तक की बातचीत का प्रवाह और contextual जानकारी
- Long-term memory: कई चरणों में हुई पुरानी बातचीत, यूज़र preferences, पिछले projects के summaries, और वह जानकारी जिसे model को लंबे समय तक याद रखने के लिए सिखाया गया है
- RAG (retrieval-augmented generation): external documents, database, API आदि से लाई गई ताज़ा और प्रासंगिक जानकारी
- Available tools: वे functions या built-in tools जिन्हें model call कर सकता है (उदाहरण:
check_inventory, send_email)
- Structured output: वह response format जिसका model को पालन करना है (उदाहरण:
JSON)
Context क्यों महत्वपूर्ण है
- व्यवहारिक रूप से effective AI agents बनाने का असली कारक जटिल code या model quality नहीं, बल्कि आप कितना उपयुक्त context देते हैं यह है
- साधारण "demo" agent सिर्फ यूज़र के अनुरोध को लेकर basic response देता है, जबकि "magic-like" agent समृद्ध context को ध्यान में रखकर कहीं अधिक उपयोगी और मानवीय जवाब पैदा करता है
- तुलना
- Low-quality (demo) agent: सिर्फ साधारण अनुरोध देखकर घिसे-पिटे जवाब देता है। उदाहरण) "क्या आप कल free हैं?" वाले mail पर "हाँ, मैं कल उपलब्ध हूँ। कौन-सा समय ठीक रहेगा?" जैसा यांत्रिक जवाब
- High-quality (magic-like) agent: अपना calendar, पुराने email history, सामने वाले की identity, और ज़रूरी tool-calling options तक का उपयोग करके स्वाभाविक और situation-specific जवाब बना सकता है। उदाहरण) "कल मेरा schedule पूरी तरह भरा है, लेकिन गुरुवार सुबह खाली है, इसलिए मैंने calendar invite भेज दिया है। यदि यह ठीक हो तो बताइए"
- इस तरह सफलता का कारण algorithm या model नहीं, बल्कि task के हिसाब से सही context उपलब्ध कराना है
- अधिकतर AI agent failures, model की वजह से नहीं बल्कि context design की विफलता का परिणाम हैं
Prompt engineering से context engineering तक का विकास
- जहाँ prompt engineering एक लाइन की text instruction को optimize करने पर केंद्रित है, वहीं context engineering इससे कहीं बड़ा दायरा कवर करता है — जानकारी, tools और structural design सहित
- Context engineering वह "विशेषज्ञ क्षमता" है जिसमें ज़रूरी जानकारी और tools को सही format और सही timing पर इस तरह system के माध्यम से उपलब्ध कराया जाए कि LLM task पूरा कर सके
Context engineering की विशेषताएँ
- पूरे system का design: context कोई साधारण prompt template नहीं, बल्कि LLM call से पहले काम करने वाले पूरे system का output है
- Dynamic generation: task के अनुसार calendar/email/web search जैसी विभिन्न जानकारियों को real time में चुनना और process करना
- सही समय पर सही जानकारी और tools देना: "Garbage In, Garbage Out" सिद्धांत के अनुसार model तक न अनावश्यक और न ही अधूरी जानकारी पहुँचे, यह महत्वपूर्ण है
- Format की स्पष्टता महत्वपूर्ण है: जानकारी को बिखरे हुए रूप में डालने के बजाय उसका summary और structure होना चाहिए, और tools के इस्तेमाल का तरीका भी साफ़ बताया जाना चाहिए
निष्कर्ष
- मज़बूत और भरोसेमंद AI agents के विकास का सार किसी "magic prompt" या नवीनतम model में नहीं, बल्कि context engineering (यानी context का design और delivery) में है
- यह सिर्फ तकनीकी समस्या नहीं है; इसके लिए business requirements और उद्देश्यों के अनुरूप information, tools, structured outputs आदि को परिभाषित करने वाली व्यापक system design क्षमता चाहिए
- LLM को task पूरा करने योग्य बनाने के लिए सही समय पर, सही जानकारी, सही format में देना ही सबसे महत्वपूर्ण है
संदर्भ सामग्री
2 टिप्पणियां
लगता है बस नाम ही बदला गया है।
Hacker News राय
मैंने हाल ही में इस विषय पर एक ब्लॉग पोस्ट लिखी थी, देखें मेरी पोस्ट - Context Engineering
मुझे लगता है कि Drew Breunig की पोस्ट्स इस विषय को वाकई शानदार ढंग से कवर करती हैं
टाइमिंग संयोग से उस दौर में थी जब “context engineering” वाला meme चल रहा था, लेकिन असल में यह काम उस meme से असंबंधित था
How Long Contexts Fail - लंबे context क्यों फेल होते हैं पोस्ट में बताया गया है कि लंबे context कैसे समस्याएँ पैदा करते हैं, और तथाकथित “context rot” कैसे होता है
How to Fix Your Context - अपने context को कैसे ठीक करें पोस्ट में Tool Loadout, Context Quarantine, Context Pruning, Context Summarization, Context Offloading जैसी कई techniques को नाम देकर समाधान सुझाए गए हैं
मुझे लगता है Drew Breunig की पोस्ट ज़रूर पढ़ने लायक है
यह सिर्फ अपना agent बनाने के लिए नहीं, बल्कि आज agent coding का इस्तेमाल करते समय भी बहुत महत्वपूर्ण है
ये सीमाएँ और व्यवहार अभी कुछ समय तक बने रहने वाले हैं
यह देखने की उत्सुकता है कि context engineer को automate करने वाला Logic Core सबसे पहले कौन विकसित करेगा
मुझे यह भी एक “एक महीने की skill” लगती है
आखिरकार यह भी बाकी कई trends की तरह जल्द गायब हो जाएगी
इन मुद्दों को LLM research समुदाय में मौजूदा LLMs का परिणाम माना जाता है
पहले से ही इस पर research चल रही है कि लाखों tools एक साथ कैसे इस्तेमाल किए जाएँ और stable long context कैसे रखा जाए
आगे चलकर, दूसरे providers से कनेक्शन की ज़रूरत वाले विशेष cases को छोड़ दें, तो ज्यादातर स्थितियों में एक ही agent काफ़ी होगा
जो लोग मौजूदा LLMs के आधार पर future agent systems डिज़ाइन कर रहे हैं, उनका हाल शायद LangChain जैसा होगा
जैसे GPT-3 के लिए बना LangChain, GPT-3.5 आते ही तुरंत पुराना लगने लगा था
जिसने भी LLM इस्तेमाल किया है या जानता है कि LLM कैसे काम करते हैं, उसके लिए यह बात काफ़ी स्पष्ट है
prompt engineering जैसी “skill” भी लंबे समय तक टिकने वाली केंद्रीय चीज़ नहीं हो सकती थी, यह लगभग तय था
मूल रूप से बात यह है कि LLM को input (context) और action (output) देना होता है, और इसके लिए काफ़ी pipeline work चाहिए
मैं इस निष्कर्ष से सहमत हूँ कि “शक्तिशाली और भरोसेमंद AI agents बनाना magic prompt या model updates ढूँढने से दूर जा रहा है”
“सही जानकारी और tools को सही format और सही timing पर देने वाली context engineering” पर ज़्यादा ध्यान देना चाहिए, यह बात सही है
लेकिन अगर वह “सही format” और “सही समय” मूल रूप से परिभाषित ही नहीं हैं, तो क्या हम अब भी किसी “magic solution” के पीछे नहीं भाग रहे?
अगर “सही जानकारी” का मतलब “ऐसी जानकारी जिससे LLM पर्याप्त सटीक उत्तर दे सके” है, तो मुझे इसमें prompt engineering से कोई मूलभूत अंतर नहीं दिखता
ऐसे non-deterministic machines के साथ आखिरकार “prompt आज़माओ और नतीजा देखो” वाले approach के अलावा बहुत भरोसेमंद heuristics नहीं होते
आख़िर में यह अंतहीन जादुई सोच ही है
अभी “prompt engineering” का नाम बदलकर “context engineering” कर दें, तब भी बात यही है कि अनिश्चित space में कुछ असरदार चीज़ ढूँढने के लिए लगातार इधर-उधर छेड़छाड़ करना
मूल रूप से यह overfitting है
prompt engineering आखिरकार वही है
समस्या यह है कि “सही format, सही समय” मूल रूप से परिभाषित नहीं हैं
असल में “AI को अच्छे से कैसे इस्तेमाल करें” वाली ज़्यादातर सलाह यहीं से शुरू होती है
अंत में यह ढोल पीटकर कोई तांत्रिक अनुष्ठान करने जैसा लगता है
नवीनतम सैद्धांतिक framework इस प्रक्रिया को दो चरणों में बाँटते हैं: exploratory और discovery
exploratory चरण को किसी airborne material dispersal device की तरह समझें
आसानी से पहचाने जा सकने वाले marker materials को, जो अक्सर मल की उपमा से समझाए जाते हैं, तेज़ी से डाला जाता है
discovery चरण को उनके diffusion pattern के analysis के रूप में समझा जा सकता है
इन दोनों चरणों का सार यह है: “बस करके देखते हैं”, फिर “नतीजा जाँचते हैं”
अब जब सबको समझ आ गया है कि “prompt engineering” कोई बड़ी skill नहीं है, तो AI industry में goalposts लगातार खिसकते हुए लगते हैं
नई skill आख़िरकार “programming” ही है
यानी वही पुरानी skill
इन चीज़ों को समझने के लिए खुद programs लिखने पड़ते हैं
LLM training, inference execution और behavior analysis करने वाले programs लिखते-लिखते समझ गहरी होती जाती है
शुरुआत में मेरे पास theory और expected outcomes थे, लेकिन कई तरीकों से LLMs को train करने के बाद मुझे बिल्कुल अलग नतीजे और यक़ीन मिले
असल फर्क tools को implement करने की प्रक्रिया से आता है
मेरे पास भी सिर्फ मध्यम स्तर का machine learning programming अनुभव है, लेकिन मुझे लगता है कि खुद एक मध्यम स्तर का compiler बनाना ही complex systems में अच्छे परिणाम पाने की कुंजी है
आपको क्या लगता है, Karpathy को यह सब कैसे समझ आया?
जवाब Karpathy के ब्लॉग में है
यह वैसा ही है जैसे compiler को समझने के लिए खुद compiler लिखने की सलाह देना
तकनीकी रूप से सही है, लेकिन ज़्यादातर लोग इतनी गहराई में नहीं जाना चाहते
यह चर्चा धीरे-धीरे WoW जैसे गेम forums जैसी लगने लगी है, जहाँ gamers strategies पर प्रयोग करते हैं और अजीब सामूहिक jargon में आपस में बहस करते हैं
तथाकथित strategies लगभग पूरी तरह trial and error से मिलती हैं, और उन पर उसी group के अंदरूनी लोगों की भाषा में बात होती है
programming भी धीरे-धीरे gamification के युग के हिसाब से ढल रही है
power users नकली strategies को beginners या बहुत ज़्यादा gamer मानसिकता वाले executives को बेच रहे हैं
सच कहें तो पिछली enterprise software waves में भी ऐसा कई बार हो चुका है
इस बार फ़र्क बस इतना है कि यह ‘power-user driven trend’ अब developers, यानी builders, के influence/control/workflow वाले क्षेत्र में भी गहराई तक घुस आया है
आज developers जो महसूस कर रहे हैं, वह शायद वैसा ही है जैसा पहले QA, SRE, CS roles वाले लोग महसूस करते थे, जब उनसे कहा जाता था “यही नया standard है!” और उन पर tooling या practices थोपी जाती थीं
निष्कर्ष:
“शक्तिशाली और भरोसेमंद AI agents बनाना magic prompts या model updates का मामला नहीं है, बल्कि business use case के लिए सही जानकारी और tools को सही format और सही समय पर देने वाली context engineering ज़्यादा महत्वपूर्ण है”
असल में यही सिद्धांत इंसानों पर भी लागू होता है
सही समय पर सही जानकारी मिले तो इंसान भी समस्याएँ बेहतर हल करते हैं
मुझे machine learning और इंसानों के बीच इस तरह की सतही तुलना का trend पसंद नहीं है
इसमें न कोई खास insight होती है, न ही यह ज़्यादा सही बैठता है
अंततः मामला environment के भीतर प्रभावी ढंग से सही goal button ढूँढकर दबाने का है
यह पारंपरिक software engineering से बहुत अलग नहीं है
बस नतीजे थोड़े अधिक non-deterministic हैं
मैं हमेशा UX और product लोगों से लगातार mockups, requirements, acceptance criteria, sample inputs/outputs, और यह feature क्यों महत्वपूर्ण है जैसी चीज़ें माँगता रहता हूँ
जब तक हम दिमाग scan करके उससे इच्छाएँ निकाल नहीं सकते, तब तक व्यवहारिक रूप से यह ज़रूरी है कि कोई अपनी चाहत को ठीक से समझाए
यह ऐसी चीज़ नहीं है जिसे सिर्फ ‘gut feel’ पर छोड़ा जा सके
ज़्यादा context नहीं, बेहतर context मायने रखता है
(एक प्रतिनिधि उदाहरण: X-Y problem)
नवीनतम LLMs को बहुत शानदार context देने पर भी वे अब भी फेल हो जाते हैं
हमारी कंपनी इस हिस्से की दो साल से भी ज़्यादा समय से गहराई से जाँच कर रही है
यह देखकर हैरानी होती है कि लोग “context ही जवाब है” वाली सोच पर कितना अंधविश्वास रखते हैं
एक बिंदु के बाद मुझे लगता है कि AI के बिना सीधे काम करना ज़्यादा तेज़ है
कम से कम उससे कोई उपयोगी सबक तो मिलता है; LLM context बनाने में घंटों खर्च करने से बेहतर
यह जानने में दिलचस्पी है कि पर्याप्त context देने के बावजूद LLM कहाँ फेल होता है
अगर कोई ठोस उदाहरण साझा करे तो अच्छा होगा
magic prompt ढूँढना कभी वास्तव में “prompt engineering” था ही नहीं
मूल रूप से बात हमेशा “context engineering” की ही थी
कई self-proclaimed AI experts ने इसे prompt engineering कहकर बेचा, लेकिन सच में वे इसकी प्रकृति ठीक से समझते ही नहीं थे
RAG (retrieval-augmented generation) इस साल अचानक पैदा हुआ कोई concept नहीं है
embeddings, vector DB, graph DB जैसी जटिल जानकारी को wrap करने वाले tools भी धीरे-धीरे mainstream हो रहे हैं
बड़े platforms भी इससे जुड़े tools को बेहतर बनाकर बड़ा ecosystem दे रहे हैं
ऐसा लगता है कि हर बार वही मुद्दे होते हैं, बस नए concepts गढ़कर नाम बदल दिए जाते हैं
अंत में यह अलाव के सामने ढोल पीटते हुए मंत्र पढ़ने वाले shaman ritual की पुनरावृत्ति जैसा ही लगता है
जैसे किसी दानव को बुलाना हो, और उम्मीद करनी पड़े कि सही शब्दों में सही मंत्र बोलने पर वह तुम्हारी बात माने
मेरे भीतर का engineer, जो reliability, repeatability और strong test coverage चाहता है, और आज की अनियंत्रित complexity के बीच लगातार टकराव रहता है
जो लोग ऐसे systems के साथ बड़े पैमाने पर demos करते हैं, उनका मैं सच में सम्मान करता हूँ
इससे मुझे security vulnerability research demos के पुराने दिन याद आते हैं
चाहे कितनी भी तैयारी कर लो, मौके पर नतीजा कभी भी बिगड़ सकता है, और presentation के दौरान पसीना छूट जाता था
यह नज़रिया मेरे अनुभव से बहुत मेल खाता है
जब मैं LLM में context डालता हूँ, तो अक्सर अपने आप से पूछता हूँ: “क्या सिर्फ इस जानकारी के आधार पर कोई इंसान यह हल कर सकता है?”
पहले जब हम text2SQL product बना रहे थे, तब model फेल होने पर असली data analyst भी कहते थे, “अरे, वह table पुरानी है। अब यह table इस्तेमाल करो।”
आख़िरकार बात यह है कि अगर LLM के पास ‘मानव analyst’ के लिए ज़रूरी context नहीं है, तो वह गलतियाँ करेगा
अगर इस विषय में कुछ छूटा है, तो वह है “evaluations”
आज भी यह देखकर हैरानी होती है कि AI projects में evaluation या तो होता ही नहीं, या बहुत ढीले ढंग से किया जाता है
evaluation पारंपरिक engineering के tests से भी ज़्यादा महत्वपूर्ण है
evaluation set बहुत बड़ा होना ज़रूरी नहीं; बस problem domain को ठीक से cover करना चाहिए
इसके बिना सब सिर्फ “अनुमान” है
और हाँ, मैं अपने आप से यह सवाल भी बार-बार पूछता हूँ कि “क्या कोई इंसान यह जानकारी पाकर इसे हल कर सकता है?”
कई बार मैंने ऐसी समस्याएँ LLM से हल होने की उम्मीद की, जिन्हें इंसान भी हल नहीं कर पाते
पारंपरिक computer programming का नियम
“अगर आप programmers को English में code लिखने देने की कोशिश करेंगे, तो जल्दी ही पता चल जाएगा कि programmers English में भी ठीक से नहीं लिख पाते”
यह थोड़ा मज़ाक है, लेकिन इसमें कुछ सच्चाई है
ज़्यादातर natural language उतनी स्पष्ट नहीं होती
अगर आप English में बहुत सटीक तरीके से अपनी बात कह सकते हैं, तो शायद आप उसे सीधे किसी machine-readable भाषा में भी लिख सकते थे
अगर आप yes/no सवाल पूछें,
तो 50% संभावना है कि जवाब झूठा होगा
उसमें ऐसा गुण है
मैं अक्सर model से कहता हूँ कि वास्तविक काम शुरू करने से पहले पहले ऐसे सवाल पूछे
उदाहरण के लिए, अगर कोई अस्पष्टता हो तो सवाल पूछो, और मौजूदा code patterns के उदाहरण माँगो
ताकि पहले से इस्तेमाल हो रहे templates को उदाहरण की तरह लिया जा सके
data scientist की cosplay करने वाले लोग evaluations नहीं चाहते
इसलिए वास्तविक revenue-generating products को छोड़कर लगभग कहीं evaluation नहीं होता
क्योंकि अगर कोई कह दे कि “बादशाह नंगा है”, तो उससे पैसा नहीं बनता
लेकिन जहाँ असली व्यावहारिक काम होता है, वहाँ evaluation अनिवार्य रूप से शामिल किया जाता है