मुख्य सामग्री पर जाएँ
Zubnet AIसीखेंWiki › Context Engineering
AI उपयोग

Context Engineering

Model अपनी context window में जो कुछ देखता है — system prompt, retrieved documents, tool outputs, memory और conversation history — उसे design, assemble तथा maintain करने की practice, ताकि वह अपना काम reliably कर सके। Term 2025 में prompt engineering के successor के रूप में उभरा, single instruction hand-tune करने से model के आसपास पूरे information environment को engineer करने की shift को reflect करते हुए।

यह क्यों मायने रखता है

Model केवल सामने की चीज़ पर reason कर सकता है, इसलिए context की quality अक्सर model स्वयं से अधिक मायने रखती है: bloated, contradictory context वाला frontier model clean, well-curated context वाले smaller model से underperform करेगा। Production systems, खासकर agents तथा RAG pipelines, में अधिकतर failures raw model capability के बजाय context problems — missing information, stale data, contradictions और drowned signal — तक trace होते हैं।

गहन अध्ययन

Context engineering कॉन्टेक्स्ट विंडो को budget, lifecycle तथा known failure modes वाले managed resource की तरह लेती है। Typical LLM call कई sources से context assemble करती है: behavior define करने वाला सिस्टम प्रॉम्प्ट, few-shot examples, retrieval से आए documents, tool definitions तथा उनके results, long-term memory और running conversation history। Discipline तय करती है कि window में क्या जगह पाता है, किस format तथा order में, कब refresh या compress हो और irrelevant या wrong information बाहर कैसे रहे। जहाँ prompt engineering पूछती है instruction कैसे phrase करें, context engineering पूछती है instruction आने तक model को क्या पता होना चाहिए।

Context Budget

Context windows few thousand tokens से hundreds of thousands तथा आगे बढ़ी हैं, लेकिन space कभी free नहीं। हर extra token हर call में latency तथा cost जोड़ता है और अटेंशन gracefully scale नहीं करती: long-context models पर research दिखाती है कि long prompt के बीच buried information beginning या end की information से कम reliably इस्तेमाल होती है, pattern जिसे "lost in the middle" कहते हैं। इसलिए practical context engineering budgeting है। Teams old conversation turns को running summaries में compress, verbose tool outputs को केवल important fields तक trim, repeated boilerplate deduplicate करती और reference material prompt से retrieval में move करती हैं ताकि relevant होने पर ही fetch हो। Goal smallest context है जिसमें current step के लिए model की जरूरत की हर चीज़ हो।

Runtime पर Context Assemble करना

Modern applications context हाथ से लिखने के बजाय dynamically build करती हैं। RAG pipeline user के question से relevant documents retrieve करके call time पर inject करती है; मेमोरी system sessions के पार user के durable facts carry करता है; टूल यूज़ और MCP जैसे protocols model को mid-conversation live data pull करने देते हैं, हर result next step के context में append होकर। एजेंट loops इसे सबसे आगे ले जाते हैं: हर observation, action तथा intermediate result context में आता है, इसलिए context agent की working state बनता है, short-term memory और plan एक साथ। इसी कारण context engineering agent design में इतनी strongly दिखती है — fifty-step run में क्या persist, summarize या drop हो यह तय करना अक्सर on-task रहने वाले agent और drift करने वाले agent के बीच difference है।

Bigger Window Fix नहीं है

एक आम गलतफ़हमी है कि million-token context windows context engineering unnecessary बनाती हैं — बस सब dump करें और model को sort करने दें। व्यवहार में long context अपने failure modes लाता है। Context rot window भरने पर performance की gradual degradation describe करता है: बहुत long context के लिए advertised models में भी input length बढ़ने पर retrieval-style questions की accuracy गिरती है। Context poisoning अधिक nasty है: हैलूसिनेशन claim, stale fact या injected instruction एक बार context में आए तो model उसे ground truth मानकर build करता है, और अपने outputs context में वापस लिखने वाले agents early mistake को हर later step में amplify कर सकते हैं। Related failure modes context distraction हैं, जहाँ irrelevant material model को task से खींचता है, और context clash, जहाँ window की contradictory information hedging या arbitrary choices बनाती है। Inputs curate करना, वापस written चीज़ validate करना, Prompt Injection से defend करना और periodically context reset करना standard countermeasures हैं।

Prompt Engineering से Context Engineering तक

Older discipline प्रॉम्प्ट इंजीनियरिंग phrasing पर focus करती थी: instruction wording, few-shot example selection और role prompts। उसने mostly blank window में single prompt लिखते human को assume किया। Applications के pipelines तथा agents बनने पर bottleneck move हुआ — कठिन हिस्सा instructions, data, tools तथा history से shared window में information flow manage करना बना, जिसमें अधिकतर software द्वारा assemble है, user द्वारा typed नहीं। Term context engineering practitioners में इसी shift का नाम देने के लिए 2025 में popular हुआ और इसलिए टिका क्योंकि उसने वही describe किया जो teams पहले कर रही थीं। Prompt craft अब भी मायने रखता है और in-context learning वह mechanism है जिस पर सब चलता है, लेकिन phrasing अब broader engineering surface का एक component है जो retrieval quality, memory design, tool output formatting तथा context lifecycle management भी cover करता है।

← सभी शब्द
ESC