एप्लाइड AI इंजीनियर कैसे बनें

मैंने यह गाइड उस रूप में लिखा है जैसा मैं चाहता था कि एप्लाइड AI इंजीनियरिंग में संक्रमण करने से पहले मेरे पास होता।

यह भूमिका मोटे तौर पर पारंपरिक सॉफ्टवेयर इंजीनियरिंग से ओवरलैप होती है, लेकिन इसमें कुछ महत्वपूर्ण अवधारणाएँ जुड़ जाती हैं जिन्हें अधिकांश सॉफ्टवेयर इंजीनियरों को संक्रमण के दौरान सीखना होता है। मेरा सुझाव है कि आप इसे उन मुख्य विषयों की रूपरेखा के रूप में उपयोग करें जिन्हें आपको समझने की आवश्यकता है, और फिर जब आप गहराई में जाना चाहें तो पूरे लेख में दिए गए लिंक किए गए संसाधनों का अनुसरण करें।

अंत तक, आपको इस बात की अधिक स्पष्ट समझ हो जानी चाहिए कि एप्लाइड AI इंजीनियरिंग क्या है, नौकरी में वास्तव में क्या आवश्यक है, और यह पारंपरिक सॉफ्टवेयर इंजीनियरिंग से कैसे आगे बढ़कर है।

यदि आप एक बहुत प्रतिभाशाली इंजीनियरिंग टीम के साथ एप्लाइड AI की सबसे दिलचस्प समस्याओं पर काम करने में रुचि रखते हैं, तो हम हमेशा भर्ती कर रहे हैं। हमारी वेबसाइट varickagents.com पर आवेदन करें या किसी उम्मीदवार को रेफर करें और $20k का रेफरल बोनस पाएं।

यह कहने के बाद, एप्लाइड AI इंजीनियरिंग को समझने का सबसे अच्छा तरीका यह है कि आप सॉफ्टवेयर बनाने के बारे में अपनी सोच में बदलाव से शुरुआत करें।

सॉफ्टवेयर इंजीनियरिंग बनाम AI इंजीनियरिंग

SWE और AI इंजीनियर होने के बीच सबसे बड़ा अंतर यह है कि पारंपरिक सॉफ्टवेयर इंजीनियरिंग आपको नियतात्मक (deterministic) रूप से सोचने के लिए प्रशिक्षित करती है, जबकि एप्लाइड AI आपको संभाव्य (probabilistic) रूप से सोचने के लिए मजबूर करता है।

सामान्य सॉफ्टवेयर में, आप लॉजिक लिखते हैं, उसे चलाते हैं, और जब कुछ टूटता है तो आप आमतौर पर उसका पता लगा सकते हैं – एक संरचित इनपुट नियतात्मक रूप से एक संरचित आउटपुट देता है।

एप्लाइड AI ऐसे काम नहीं करता। आप बुद्धिमत्ता के लिए एक गैर-नियतात्मक (non-deterministic) API कॉल के आसपास निर्माण कर रहे हैं, जिसका मतलब है कि एक ही इनपुट हर बार अलग वापस आ सकता है। इस वजह से, काम सिर्फ सॉफ्टवेयर बनाना नहीं रह जाता, बल्कि यह मापना हो जाता है कि क्या सिस्टम वास्तव में उस तरह से व्यवहार कर रहा है जैसा उसे करना चाहिए।

हम ऐसा इवैल (evals) के माध्यम से करते हैं, इसलिए मैं यह समझाऊंगा कि एक इवैलुएशन सूट कैसे बनाया जाए जो यह सुनिश्चित करे कि आपके द्वारा विकसित एजेंट गलतियाँ न करे। मैंने सीखा है कि हम जो काम करते हैं उसकी गैर-नियतात्मक प्रकृति को देखते हुए, यह एक एप्लाइड AI डेवलपर के सबसे महत्वपूर्ण कौशलों में से एक है।

लेख का अगला भाग AI एजेंट के प्रत्येक भाग को विकसित करने को कवर करता है (मॉडल को छोड़कर, निश्चित रूप से), क्योंकि आप एक मॉडल के लिए API कॉल कर सकते हैं लेकिन बाकी सब कुछ आपको स्वयं बनाना होता है। इसे हार्नेस इंजीनियरिंग (harness engineering) कहा जाता है।

और अंत में, मैं कवर करूंगा कि प्रोडक्शन में एक एजेंट से कई एजेंटों तक कैसे जाएं – और यह एक वितरित सिस्टम (distributed systems) की समस्या क्यों है। यदि आप इस लेख के अंत तक पहुँच सकते हैं, तो कोई कारण नहीं है कि आप एप्लाइड AI इंजीनियर बनने के लिए संक्रमण नहीं कर सकते।

इवैल (Evals)

एक एप्लाइड AI इंजीनियर इवैल का उपयोग करके अनिश्चितता को मापा आत्मविश्वास में बदल देता है। पारंपरिक सॉफ्टवेयर विकास में, आप सिस्टम पर भरोसा करते हैं क्योंकि आपने लॉजिक लिखा और कोड का परीक्षण किया। एप्लाइड AI में, आप उस तरह से सिस्टम पर भरोसा नहीं कर सकते क्योंकि मॉडल अलग-अलग रन में अलग व्यवहार कर सकता है। इसलिए AI इंजीनियर को एजेंट के चारों ओर एक मापन परत (measurement layer) बनानी होती है।

एक इवैल एक एजेंट को एक कार्य देने, उसे चलाने देने, और उसने जो किया उसे ग्रेड करने की प्रक्रिया है। लक्ष्य दो चीजें साबित करना है: एजेंट ने काम सही ढंग से पूरा किया, और एजेंट उसे दी गई सीमाओं के भीतर रहा।

पहला कदम परिणाम को ग्रेड करना है। यह इवैल प्रक्रिया का सबसे आसान कदम है। एक इनवॉइस एजेंट के लिए, जिन पर मैं आमतौर पर काम करता हूँ, इसका मतलब है यह सुनिश्चित करना कि इनवॉइस सही जगह पर पहुँचे, या डुप्लिकेट को फ्लैग किया जाए। आप बस अंतिम परिणाम की तुलना उससे कर रहे हैं जो होना चाहिए था।

दूसरा कदम ट्रैजेक्टरी (trajectory) को ग्रेड करना है। यह वह रास्ता है जो एजेंट ने उस परिणाम तक पहुँचने के लिए अपनाया: उसने कौन से टूल कॉल किए, उसने कौन से फ़ील्ड को छुआ, उसने कौन से आर्गुमेंट पास किए, और रास्ते में उसने कौन सी कार्रवाइयाँ करने का प्रयास किया। यह मायने रखता है क्योंकि एक एजेंट सही अंतिम उत्तर तक पहुँच सकता है जबकि प्रक्रिया में कुछ खतरनाक भी कर सकता है। यह एक इनवॉइस को सही ढंग से वर्गीकृत कर सकता है जबकि बैंक विवरण भी बदल सकता है या अनुमोदन से पहले भुगतान भेज सकता है।

ट्रैजेक्टरी स्वयं सिर्फ एक लॉग है: एजेंट द्वारा कॉल किए गए प्रत्येक टूल और उसके द्वारा पास किए गए आर्गुमेंट की एक क्रमबद्ध सूची – इसे ग्रेड करने का मतलब सिर्फ उस लॉग के खिलाफ चेक लिखना है।

कुछ चेक नियतात्मक होते हैं – यह सुनिश्चित करना कि send_payment कभी भी अनुमोदन कॉल से पहले न आए, यह जाँचना कि केवल वही फ़ील्ड लिखे गए जिन्हें लिखने की अनुमति एजेंट को थी। अन्य निर्णय कॉल होते हैं – क्या एस्केलेशन उचित था, क्या तर्क ने कार्रवाई को उचित ठहराया। वे एक रूब्रिक के साथ दूसरे मॉडल के पास जाते हैं।

पालन करने का सामान्य सिद्धांत यह है कि नियतात्मक चेक आमतौर पर सुरक्षा उल्लंघनों को पकड़ते हैं, जबकि जज मॉडल गुणवत्ता को स्कोर करता है।

परिणाम प्रति परीक्षण मामले में दो ग्रेड होते हैं: क्या एजेंट को सही उत्तर मिला, और क्या वह वहाँ पहुँचने के दौरान सही व्यवहार कर रहा था। इन्हें अलग-अलग रिपोर्ट करने की आवश्यकता है, क्योंकि एक एजेंट जो 95% समय इनवॉइस को सही ढंग से वर्गीकृत करता है लेकिन 4% रन में एक निषिद्ध फ़ील्ड को छूता है, वह मिश्रित स्कोर पर बहुत अच्छा दिखता है लेकिन प्रोडक्शन में बड़ी व्यावसायिक जटिलताओं का कारण बनता है।

यह लेख इवैल और कवर किए गए अन्य सभी विषयों के परिचय के रूप में कार्य करता है, इसलिए मैंने आपको गहराई में जाने में मदद करने के लिए अन्य संसाधनों को लिंक किया है। कुछ जिन्होंने मुझे प्रभावी इवैल बनाने का तरीका समझने में मदद की है:

• Anthropic का इवैल कोर्स
• Lenny का इवैल के लिए संपूर्ण गाइड
• Hamel का इवैल पर FAQ

मैं प्रत्येक से गुज़रने की सलाह दूंगा, लेकिन इवैल कोर्स (जो थोड़ा अधिक व्यावहारिक है) से पहले Lenny और Hamel से शुरुआत करें।

लेकिन एक इवैल को परीक्षण के लिए अभी भी एक एजेंट की आवश्यकता होती है, और मॉडल के आसपास की हर चीज़ आपको बनानी होती है। उस आसपास के सिस्टम को हार्नेस कहा जाता है – अगला भाग बताता है कि हार्नेस इंजीनियरिंग प्रक्रिया के प्रत्येक भाग के बारे में कैसे सोचा जाए, टूल कॉलिंग से लेकर कॉन्टेक्स्ट विंडो ऑप्टिमाइज़ेशन तक।

हार्नेस इंजीनियरिंग (Harness Engineering)

एक मॉडल अपने आप में कोई एजेंट नहीं है। एक मॉडल तर्क कर सकता है, वर्गीकृत कर सकता है, लिख सकता है और निर्णय ले सकता है, लेकिन वह अपने आप किसी कंपनी के अंदर काम नहीं कर सकता। वह कह सकता है कि क्या कार्रवाई होनी चाहिए, लेकिन वह उस कार्रवाई को सुरक्षित रूप से नहीं ले सकता जब तक कि आप उसके चारों ओर सिस्टम न बनाएं – और वह सिस्टम हार्नेस है।

हार्नेस मॉडल के आसपास की हर चीज़ है जो एक API कॉल को एक काम करने वाले एजेंट में बदल देती है: वे टूल जिनका वह उपयोग कर सकता है, वह कॉन्टेक्स्ट जो वह देखता है, वह स्थिति (state) जिसे वह याद रखता है, वह गार्डरेल जो उसे सीमित करते हैं, और वह लूप जो उसे तब तक काम करते रहने देता है जब तक कार्य पूरा न हो जाए।

हार्नेस का पहला भाग टूल निष्पादन (tool execution) है।

मॉडल केवल टेक्स्ट पढ़ते और लिखते हैं, इसलिए जब कोई मॉडल कुछ करने का निर्णय लेता है, तो वह वास्तव में उसे निष्पादित नहीं करता। वह एक रिकॉर्ड को अपडेट करने, या ईमेल भेजने, या डेटाबेस खोजने के लिए एक संरचित अनुरोध (एक JSON स्ट्रिंग) उत्सर्जित करता है।

हार्नेस उस अनुरोध को प्राप्त करता है, उसे मान्य करता है, वास्तविक ऑपरेशन चलाता है, और परिणाम को टेक्स्ट के रूप में मॉडल को वापस भेजता है।

दूसरा भाग कॉन्टेक्स्ट प्रबंधन (context management) है। प्रत्येक निर्देश, टूल मेनू, टूल परिणाम और पिछला संदेश मॉडल की कॉन्टेक्स्ट विंडो में जगह लेता है। हार्नेस को यह तय करना होता है कि मॉडल को अभी क्या देखने की आवश्यकता है, क्या संक्षेपित किया जाना चाहिए, और क्या हटाया जाना चाहिए। इसके बिना, एजेंट अप्रासंगिक इतिहास में खो जाते हैं।

मैं एक अधिक व्यापक लेख लिखूंगा जो हार्नेस विकास प्रक्रिया के प्रत्येक भाग में गहराई से जाता है, लेकिन अभी के लिए, मैं Arize के एक इंजीनियर द्वारा दिए गए इस टॉक को सुनने की सलाह दूंगा, जो एजेंटों के लिए सतत शिक्षण प्लेटफॉर्म है, जो कॉन्टेक्स्ट प्रबंधन पर उनकी विचार प्रक्रिया में गहराई से जाता है।

अपने एजेंटों पर व्यवहार में प्रभावी कॉन्टेक्स्ट प्रबंधन लागू करने के बारे में अधिक जानने के लिए, इन ब्लॉग को पढ़ें:

• OpenAI का कॉन्टेक्स्ट प्रबंधन लेख
• कॉन्टेक्स्ट प्रबंधन के लिए एक व्यावहारिक गाइड
• Anthropic का कॉन्टेक्स्ट इंजीनियरिंग गाइड

हार्नेस इंजीनियरिंग में तीसरा भाग स्थिति और स्मृति (state and memory) है। मॉडल कॉलों के बीच स्टेटलेस होते हैं, इसलिए एजेंट को जो कुछ भी याद रखने की आवश्यकता है, उसे मॉडल के बाहर रहना होता है (आमतौर पर डेटाबेस, फ़ाइल स्टोर या टास्क रिकॉर्ड में)। कॉन्टेक्स्ट वह है जिसे मॉडल अभी देख रहा है। स्थिति वह सब कुछ है जो एजेंट जानता है लेकिन वर्तमान में नहीं देख रहा है।

चौथा भाग गार्डरेल (guardrails) है। चूंकि मॉडल गलत कार्रवाई को उतने ही आत्मविश्वास के साथ अनुरोध कर सकता है जितना सही कार्रवाई को, हार्नेस को अनुमतियाँ जाँचनी होती हैं, इनपुट को मान्य करना होता है, असुरक्षित कार्रवाइयों को ब्लॉक करना होता है, और उच्च जोखिम वाले कदमों को मनुष्यों के पास रूट करना होता है।

अंत में, यह सब एजेंट लूप में एक साथ बंध जाता है: कॉन्टेक्स्ट बनाएं, मॉडल को कॉल करें, उसकी प्रतिक्रिया का निरीक्षण करें, यदि अनुमति हो तो टूल निष्पादित करें, परिणाम संग्रहीत करें, कॉन्टेक्स्ट अपडेट करें, और तब तक दोहराएं जब तक कार्य पूरा न हो जाए।

हार्नेस इंजीनियरिंग ही वह अधिकांश काम है जो आप एक एप्लाइड AI इंजीनियर के रूप में करेंगे, इसलिए इस भाग के साथ अपना समय लें। एक एप्लाइड AI इंजीनियर के रूप में, आपका पूरा काम ऑपरेटिंग वातावरण बनाना है जो एक संभाव्य सिस्टम को नियतात्मक सॉफ्टवेयर के अंदर काम करने देता है।

लेकिन प्रोडक्शन आमतौर पर एक एजेंट पर नहीं रुकता।

जैसे-जैसे वर्कफ़्लो बड़ा होता है, स्वाभाविक प्रवृत्ति काम को विभाजित करने की होती है। लेकिन एक बार जब आप दूसरा एजेंट जोड़ते हैं, तो सिस्टम डिज़ाइन बदल जाता है।

एक एजेंट के साथ, अधिकांश जटिलता एक लूप के अंदर रहती है। कई एजेंटों के साथ, अब आपके पास एक ही वातावरण पर काम करने वाले कई लूप हैं। प्रत्येक एजेंट उस स्थिति को पढ़ सकता है जिसे किसी दूसरे एजेंट ने अभी बदला है, उस मेमोरी में लिख सकता है जिस पर दूसरा एजेंट निर्भर है, या एक ऐसे टूल को कॉल कर सकता है जिसका परिणाम पूरे वर्कफ़्लो को प्रभावित करता है।

उस बिंदु पर, कठिन हिस्सा अब केवल प्रॉम्प्टिंग, इवैल या हार्नेस डिज़ाइन नहीं रह जाता। यह एक वितरित सिस्टम समस्या बन जाता है: किसके पास कौन सी स्थिति है, कौन मेमोरी में लिख सकता है, कौन से टूल को रीट्राई करना सुरक्षित है, और क्या होता है जब दो उचित एजेंट गलत क्रम में कार्रवाई करते हैं।

मल्टी-एजेंट डिप्लॉयमेंट एक वितरित सिस्टम समस्या है

जब पहला एजेंट काम करता है और वर्कफ़्लो बड़ा हो जाता है, तो एक नए एप्लाइड AI इंजीनियर में स्वाभाविक रूप से काम को भूमिकाओं में विभाजित करने की प्रवृत्ति होती है: एक एजेंट शोध करता है, एक योजना बनाता है, एक निष्पादित करता है, एक समीक्षा करता है।

लेकिन दूसरा एजेंट डिज़ाइन की इकाई को एजेंट से सिस्टम में बदल देता है। कई लूप अब एक ही वातावरण में कार्य करते हैं – एक एजेंट ग्राहक की स्थिति को अपडेट कर सकता है जबकि दूसरा पुरानी स्थिति के खिलाफ मिड-प्लान लिख रहा है। दोनों ने उचित निर्णय लिए, लेकिन सिस्टम ने उन निर्णयों को गलत क्रम में परस्पर क्रिया करने दिया।

यह एक वितरित सिस्टम समस्या है। अच्छी खबर यह है कि वितरित सिस्टम इंजीनियरों ने दशकों पहले इन विफलताओं को हल कर दिया था। आपका काम उन्हें उन लूपों पर लागू करना है जिनमें संयोग से एक LLM होता है। नीचे वितरित सिस्टम से उन समाधानों की एक सूची दी गई है जो AI इंजीनियरिंग पर लागू होते हैं:

एकल-लेखक सिद्धांत (Single-writer principle)। स्थिति के प्रत्येक महत्वपूर्ण टुकड़े में ठीक एक एजेंट होता है जो उसमें लिख सकता है – अन्य एजेंट उससे पढ़ते हैं या परिवर्तन अनुरोध सबमिट करते हैं। इसे टूल स्तर पर लागू करें: यदि निष्पादन एजेंट एकमात्र है जो CRM में लिख सकता है, तो शोध एजेंट CRM को दूषित नहीं कर सकता, चाहे वह कितना भी खराब तर्क क्यों न करे।

आइडेम्पोटेंसी कुंजियाँ (Idempotency keys)। जब कुछ विफल होता है या टाइमआउट होता है तो एजेंट टूल कॉल को रीट्राई करते हैं, लेकिन रीट्राई खतरनाक हो सकते हैं जब टूल वास्तविक दुनिया में कुछ बदलता है। आप नहीं चाहते कि कोई एजेंट एक ही भुगतान दो बार भेजे सिर्फ इसलिए कि पहला अनुरोध विफल दिख रहा था। इसका समाधान प्रत्येक म्यूटेटिंग टूल कॉल के साथ एक अद्वितीय कुंजी संलग्न करना है – जिसका अर्थ है कोई भी कार्रवाई जो किसी बाहरी सिस्टम में डेटा बदलती है। यदि टूल वही कुंजी फिर से देखता है, तो उसे कार्रवाई को दूसरी बार चलाने के बजाय मूल परिणाम वापस करना चाहिए। Stripe का API इस तरह काम करता है – और यह भुगतान, ईमेल आदि से निपटने के दौरान एजेंट विकास पर लागू होता है।

लेखन पर पूर्व शर्तें (Preconditions on writes)। एजेंट अक्सर दुनिया के पुराने दृश्य पर कार्य करते हैं। एजेंट द्वारा अपनी योजना बनाने और किसी बाहरी सिस्टम को अपडेट करने का प्रयास करने के बीच कुछ बदल सकता है। पुराने लेखन को रोकने के लिए, म्यूटेटिंग टूल को परिवर्तन करने से पहले एक शर्त की आवश्यकता होनी चाहिए। उदाहरण के लिए: "स्थिति को 'अनुमोदित' पर सेट करें केवल तभी जब वह अभी भी 'लंबित' हो।" यदि स्थिति पहले ही बदल चुकी है, तो टूल को नई स्थिति को चुपचाप ओवरराइट करने के बजाय स्पष्ट रूप से विफल होना चाहिए।

स्पष्ट हैंड-ऑफ (Explicit hand-offs)। कार्य को एक परिभाषित स्कीमा वाले संदेशों के रूप में पास करें, जो एक ऑर्केस्ट्रेटर द्वारा अनुक्रमित हो। एक एजेंट को अपना कार्य प्राप्त करना चाहिए, उसे खोजना नहीं चाहिए।

TLDR

यह लेख उन सबसे महत्वपूर्ण विषयों का एक सिंहावलोकन है जो मैंने एक एप्लाइड AI इंजीनियर के रूप में सीखे हैं: इवैल, हार्नेस इंजीनियरिंग और मल्टी-एजेंट सिस्टम डिज़ाइन।

यदि आप कुछ भी लेकर जाते हैं, तो इसे लें – मॉडल बुद्धिमत्ता प्रदान करता है, लेकिन वह सब कुछ जो इसे विश्वसनीय बनाता है (मापन परत, ऑपरेटिंग वातावरण, समन्वय नियम) आपके द्वारा इंजीनियर किया जाता है। इन्हें समझें और सॉफ्टवेयर इंजीनियरिंग से संक्रमण आपके पास पहले से मौजूद कौशल का विस्तार बन जाता है।

यदि आप इस तरह के काम में रुचि रखते हैं और एक बहुत प्रतिभाशाली इंजीनियरिंग टीम के साथ एप्लाइड AI की सबसे दिलचस्प समस्याओं से निपटना चाहते हैं, तो हम हमेशा भर्ती कर रहे हैं। हमारी वेबसाइट varickagents.com पर आवेदन करें, और हम आपको जल्द से जल्द शुरू करा सकते हैं। दूसरी ओर, यदि आप एक सफल उम्मीदवार को रेफर करते हैं, तो हम आपको $20K का रेफरल बोनस देंगे।