लूप इंजीनियरिंग के साथ सेल्फ-इम्प्रूविंग AI एजेंट्स कैसे बनाएं

अधिकांश AI एजेंट इसलिए विफल नहीं होते क्योंकि मॉडल कमज़ोर है।

वे इसलिए विफल होते हैं क्योंकि मॉडल के आस-पास का सिस्टम कमज़ोर है।

एक प्रॉम्प्ट अस्पष्ट है।

एक टूल कॉल टूट जाती है।

एजेंट गलत चीज़ को दोबारा आज़माता है।

वह दो कदम पहले जो सीखा था, उसे भूल जाता है।

वह वही बुरा काम दोहराता है।

वह बहुत जल्दी सफलता घोषित कर देता है।

और किसी ने वह फीडबैक लूप नहीं बनाया जो गलती को पकड़ लेता।

यही असली समस्या है।

अगर आप ऐसे AI एजेंट बनाना चाहते हैं जो वास्तव में समय के साथ बेहतर हों, तो आपको सिर्फ़ बेहतर प्रॉम्प्ट, ज़्यादा टूल या ज़्यादा स्वायत्तता की ज़रूरत नहीं है।

आपको लूप इंजीनियरिंग की ज़रूरत है।

लूप इंजीनियरिंग यह डिज़ाइन करने का अनुशासन है कि एक एजेंट कैसे:

• देखता है कि क्या हुआ
• मूल्यांकन करता है कि क्या यह काम कर गया
• अपने अगले कदम को अपडेट करता है
• उपयोगी फीडबैक संग्रहीत करता है
• बुद्धिमानी से पुनः प्रयास या एस्केलेट करता है
• सिर्फ़ व्यस्त होने के बजाय बेहतर होता है

यह बदलाव मायने रखता है।

क्योंकि उपयोगी AI एजेंटों की अगली पीढ़ी को इस बात से परिभाषित नहीं किया जाएगा कि वे एक डेमो रन में कितने प्रभावशाली दिखते हैं।

उन्हें इस बात से परिभाषित किया जाएगा कि क्या वे:

• गलतियों से उबर सकते हैं
• बार-बार होने वाली विफलताओं से सीख सकते हैं
• हर बार मानवीय निगरानी के बिना गुणवत्ता में सुधार कर सकते हैं
• प्रोडक्शन में सीमित, मापने योग्य और विश्वसनीय रह सकते हैं

यही इस लेख का विषय है।

क्या आप इस तरह के और अधिक व्यावहारिक AI सिस्टम चाहते हैं? ByteBuilders Claude, AI वर्कफ़्लो, प्रॉम्प्ट, ऑटोमेशन और वास्तविक दुनिया के इंजीनियरिंग सिस्टम पर छोटे, उपयोगी विश्लेषण साझा करता है।

यहाँ सब्सक्राइब करें:

https://bytebuilders.beehiiv.com/subscribe

अगर आप लूप इंजीनियरिंग को समझते हैं, तो आप नाज़ुक एजेंट बनाना बंद कर देते हैं जो केवल तब काम करते हैं जब सब कुछ सही हो।

आप ऐसे सिस्टम बनाना शुरू करते हैं जो इसलिए बेहतर होते हैं क्योंकि वे सीखने के लिए डिज़ाइन किए गए थे।

पहले, "स्व-सुधार" का वास्तव में क्या अर्थ है

बहुत से लोग "स्व-सुधार करने वाला एजेंट" सुनते हैं और एक ऐसे सिस्टम की कल्पना करते हैं जो जादुई रूप से खुद को फिर से प्रशिक्षित करता है या किसी स्वायत्त और रहस्यमयी चीज़ में विकसित हो जाता है।

यह उपयोगी परिभाषा नहीं है।

एक स्व-सुधार करने वाला एजेंट आमतौर पर बहुत सरल होता है।

यह एक ऐसा एजेंट है जो अगले प्रयास पर बेहतर निर्णय लेने के लिए पिछले प्रयासों के संकेतों का उपयोग कर सकता है।

यह इसके माध्यम से हो सकता है:

• बेहतर संदर्भ के साथ पुनः प्रयास
• मूल्यांकन-आधारित संशोधन
• पिछली विफलताओं की स्मृति
• टूल-उपयोग सुधार
• आउटपुट स्कोरिंग
• मानवीय फीडबैक लूप
• नियम अपडेट
• संग्रहीत सफल पैटर्न

दूसरे शब्दों में:

स्व-सुधार आमतौर पर मॉडल का विकास नहीं है। यह लूप का विकास है।

बेस मॉडल वही रह सकता है।

जो सुधरता है वह मॉडल के आस-पास सिस्टम का व्यवहार है।

यह एक अधिक व्यावहारिक और इंजीनियरिंग-अनुकूल ढाँचा है।

अधिकांश एजेंट अपने आप क्यों नहीं सुधरते

आश्चर्यजनक रूप से बड़ी संख्या में एजेंट वास्तव में सुधार के लिए डिज़ाइन नहीं किए गए हैं।

वे जारी रखने के लिए डिज़ाइन किए गए हैं।

यह एक ही बात नहीं है।

आज कई एजेंट सिस्टम मूल रूप से इस प्रकार हैं:

1. कार्य पढ़ें
2. सोचें
3. टूल कॉल करें
4. रुकने तक जारी रखें

समस्या यह है कि इस संरचना में अक्सर कमी होती है:

• स्पष्ट सफलता मानदंड
• विफलता वर्गीकरण
• स्थिति-जागरूक पुनः प्रयास
• जो पहले ही विफल हो चुका है उसकी स्मृति
• प्रयासों के बीच तुलना
• आउटपुट मूल्यांकन
• एस्केलेशन नियम

इसलिए एजेंट में सुधार नहीं होता।

वह बस लूप करता है।

यही कच्चे पुनरावृत्ति और बुद्धिमान पुनरावृत्ति के बीच का अंतर है।

लूप इंजीनियरिंग ही वह चीज़ है जो यह अंतर पैदा करती है।

लूप इंजीनियरिंग ही वास्तविक आर्किटेक्चर परत है

लूप इंजीनियरिंग को समझने का सबसे आसान तरीका यह है:

प्रॉम्प्टिंग मॉडल को बताती है कि क्या करना है।

लूप इंजीनियरिंग सिस्टम को बताती है कि प्रयास करने के बाद कैसे व्यवहार करना है।

इसमें इस तरह के प्रश्न शामिल हैं:

• एक असफल टूल कॉल के बाद एजेंट को क्या करना चाहिए?
• उसे कब पुनः प्रयास करना चाहिए बनाम रणनीति बदलनी चाहिए?
• कितने प्रयासों की अनुमति है?
• मेमोरी में क्या संग्रहीत किया जाना चाहिए?
• स्वचालित रूप से क्या मूल्यांकन किया जाना चाहिए?
• मानव को कब संभालना चाहिए?
• सुधार क्या माना जाता है?

यही कारण है कि लूप इंजीनियरिंग सिर्फ़ प्रॉम्प्ट वार्तालाप का हिस्सा नहीं है, बल्कि आर्किटेक्चर वार्तालाप का भी हिस्सा है।

स्व-सुधार करने वाले एजेंटों के पीछे मुख्य लूप

अधिकांश उपयोगी स्व-सुधार करने वाले एजेंट एक दोहराई जाने वाली संरचना का अनुसरण करते हैं जो कुछ इस तरह दिखती है

1लक्ष्य
2  ↓
3योजना
4  ↓
5कार्य
6  ↓
7परिणाम देखें
8  ↓
9गुणवत्ता का मूल्यांकन करें
10  ↓
11संकेत संग्रहीत करें
12  ↓
13पुनः प्रयास / संशोधित / एस्केलेट / अंतिम रूप दें

यही नींव है।

सिस्टम में सुधार तब होता है जब लूप के प्रत्येक पास से अगला निर्णय उपयोगी तरीके से बदलता है।

हर एजेंट को एक जटिल संस्करण की आवश्यकता नहीं है।

लेकिन हर विश्वसनीय एजेंट को इसका कुछ संस्करण चाहिए।

एक सामान्य एजेंट और लूप-इंजीनियर्ड एजेंट के बीच अंतर

आयाम

सामान्य एजेंट

लूप-इंजीनियर्ड एजेंट

कार्य प्रबंधन

कार्य को एक बार आज़माता है या आँख बंद करके जारी रखता है

सीमित चक्रों के माध्यम से काम करता है

त्रुटि प्रतिक्रिया

बेतरतीब ढंग से पुनः प्रयास करता है या कठोरता से विफल होता है

वर्गीकृत विफलता के आधार पर पुनः प्रयास करता है

स्मृति

बहुत कम या कोई उपयोगी स्थिति नहीं

कार्रवाई योग्य संदर्भ संग्रहीत करता है

मूल्यांकन

मानता है कि पूर्णता का अर्थ सफलता है

मानदंडों के विरुद्ध आउटपुट की जाँच करता है

सुधार

आकस्मिक

डिज़ाइन किया गया

मानवीय भूमिका

केवल आपातकालीन बैकअप

जानबूझकर एस्केलेशन बिंदु

विश्वसनीयता

असंगत

समय के साथ उत्तरोत्तर मजबूत

यही बदलाव है।

लूप-इंजीनियर्ड एजेंट जरूरी नहीं कि मॉडल स्तर पर "अधिक स्मार्ट" हो।

वह बस एक बेहतर सिस्टम के अंदर काम कर रहा है।

स्व-सुधार करने वाले एजेंटों के पाँच निर्माण खंड

यदि आप चाहते हैं कि कोई एजेंट सुधरे, तो आपको संरचना वाले एक लूप की आवश्यकता है।

ये पाँच निर्माण खंड सबसे अधिक मायने रखते हैं।

1. स्पष्ट सफलता मानदंड

यदि सिस्टम नहीं जानता कि "अच्छा" कैसा दिखता है, तो वह उसकी ओर सुधार नहीं कर सकता।

सफलता मानदंड हो सकते हैं:

• सटीक आउटपुट प्रारूप
• शुद्धता सीमा
• आधारभूत उत्तर आवश्यकता
• टूल पूर्णता संकेत
• परीक्षण परिणाम पास करना
• मानवीय अनुमोदन
• कार्य-विशिष्ट स्कोर

इसके बिना, एजेंट के पास अनुकूलन के लिए कोई स्थिर चीज़ नहीं है।

1. मूल्यांकन परत

मूल्यांकन परत वह है जो एजेंट को बताती है कि उसका प्रयास काम कर गया या नहीं।

यह हो सकता है:

• नियम-आधारित जाँच
• स्कीमा सत्यापन
• यूनिट परीक्षण
• LLM-एज़-जज स्कोरिंग
• पुनर्प्राप्ति आधारभूत जाँच
• व्यावसायिक तर्क सत्यापन
• मानवीय समीक्षा

यह "इसने एक उत्तर दिया" और "इसने एक उपयोगी उत्तर दिया" के बीच का अंतर है।

1. फीडबैक मेमोरी

स्व-सुधार के लिए स्मृति की आवश्यकता होती है, लेकिन सिर्फ़ कच्चा इतिहास नहीं।

एजेंट को उपयोग करने योग्य स्मृति की आवश्यकता है।

अच्छी फीडबैक मेमोरी में इस तरह की चीज़ें शामिल हैं:

• अंतिम विफलता का कारण
• पिछला टूल त्रुटि
• सबसे अच्छा ज्ञात सफल पथ
• बचने के लिए ज्ञात खराब रणनीति
• उपयोगकर्ता वरीयता या सुधार
• पिछले प्रयासों का संक्षिप्त सारांश

सभी संदर्भ बने रहने चाहिए, यह ज़रूरी नहीं है।

केवल वही संदर्भ जो अगले निर्णय में मदद करता है।

1. रणनीति संशोधन

मूल्यांकन के बाद, एजेंट को यह तय करना होगा कि क्या बदलना है।

इसमें शामिल हो सकता है:

• एक नया टूल आज़माना
• कार्य को संकीर्ण करना
• एक स्पष्ट प्रश्न पूछना
• अधिक जानकारी प्राप्त करना
• कार्रवाई से स्पष्टीकरण पर स्विच करना
• किसी मानव को एस्केलेट करना

यह वह जगह है जहाँ सिस्टम वास्तव में अनुकूली बन जाता है।

1. सीमाएँ और रोक शर्तें

एक स्व-सुधार करने वाले एजेंट को अभी भी नियंत्रण की आवश्यकता है।

अन्यथा आपको सुधार नहीं मिलता।

आपको अराजकता मिलती है।

इसके लिए सीमाएँ निर्धारित करें:

• पुनः प्रयास
• लागत
• विलंबता
• विनाशकारी कार्य
• मानवीय अनुमोदन सीमाएँ
• कार्य परित्याग नियम

एक सीमित लूप एक अप्रतिबंधित लूप की तुलना में अधिक मूल्यवान है।

व्यवहार में लूप इंजीनियरिंग कैसी दिखती है

यहाँ एक सरल पैटर्न है जो कई एजेंटों के लिए अच्छा काम करता है।

लूप 1: प्रयास

एजेंट वर्तमान संदर्भ के साथ कार्य करने का प्रयास करता है।

लूप 2: मूल्यांकन

एक जाँच चलती है।

उदाहरण:

• क्या स्कीमा मान्य हुई?
• क्या कोड परीक्षण पास कर गया?
• क्या उत्तर ने आवश्यक स्रोत का हवाला दिया?
• क्या टूल ने सही फ़ील्ड लौटाए?

लूप 3: निदान

यदि यह विफल हुआ, तो कारण वर्गीकृत करें।

उदाहरण:

• लापता संदर्भ
• खराब टूल तर्क
• पुनर्प्राप्ति विफलता
• भ्रामक धारणा
• अधूरा आउटपुट
• नीति विरोध

लूप 4: अनुकूलन

अगला प्रयास बदलें।

उदाहरण:

• अधिक संदर्भ प्राप्त करें
• कार्य को अधिक संकीर्ण रूप से फिर से लिखें
• एक अलग टूल आज़माएँ
• सत्यापन नियम जोड़ें
• लापता विवरण के लिए उपयोगकर्ता से पूछें

लूप 5: उपयोगी संकेत संग्रहीत करें

केवल वही सहेजें जो भविष्य के रन में मदद करता है।

फिर दोहराएँ।

यही परिचालन शब्दों में लूप इंजीनियरिंग है।

लूप-इंजीनियर्ड एजेंटों के लिए एक व्यावहारिक आरेख

1उपयोगकर्ता लक्ष्य
2   ↓
3कार्य दुभाषिया
4   ↓
5योजनाकार
6   ↓
7टूल / कार्रवाई परत
8   ↓
9परिणाम
10   ↓
11मूल्यांकक
12   ├── पास → अंतिम रूप दें
13   ├── विफल: लापता संदर्भ → और अधिक प्राप्त करें
14   ├── विफल: खराब टूल उपयोग → कार्रवाई संशोधित करें
15   ├── विफल: कम आत्मविश्वास → एस्केलेट करें
16   └── विफल: पुनर्प्राप्ति योग्य → मेमोरी के साथ पुनः प्रयास करें

यह वह जगह है जहाँ एजेंट की गुणवत्ता आकस्मिक के बजाय व्यवस्थित हो जाती है।

स्व-सुधार संकेत कहाँ से आने चाहिए

यह सबसे महत्वपूर्ण डिज़ाइन प्रश्नों में से एक है।

यदि आप लूप में गलत संकेत डालते हैं, तो एजेंट गलत दिशा में अनुकूलन कर सकता है।

सुधार संकेतों के मजबूत स्रोतों में शामिल हैं:

नियतात्मक संकेत

• परीक्षण पास या विफल होते हैं
• स्कीमा मान्य या विफल होती है
• API स्थिति सफलता या त्रुटि है
• आउटपुट में आवश्यक फ़ील्ड हैं या नहीं
• नीति नियम संतुष्ट या उल्लंघन है

वर्कफ़्लो संकेत

• पुनः प्रयास गणना
• टूल विलंबता
• वह कदम जहाँ विफलता हुई
• आत्मविश्वास सीमा पार हो गई
• एस्केलेशन आवृत्ति

मानवीय संकेत

• अंगूठा ऊपर / अंगूठा नीचे
• सही किया गया आउटपुट
• स्वीकृत बनाम अस्वीकृत ड्राफ्ट
• मैन्युअल ओवरराइड पैटर्न
• समीक्षक नोट्स

तुलनात्मक संकेत

• संस्करण A बनाम संस्करण B आउटपुट गुणवत्ता
• पुनर्प्राप्ति संस्करण तुलना
• टूल पथ तुलना
• बार-बार चलाने पर स्कोर में सुधार

सबसे अच्छे स्व-सुधार करने वाले एजेंट आमतौर पर इनमें से कम से कम दो श्रेणियों को जोड़ते हैं।

सबसे अच्छे लूप वर्कफ़्लो में सुधार करते हैं, सिर्फ़ प्रतिक्रिया में नहीं

यह वह जगह है जहाँ डिज़ाइन अधिक परिपक्व हो जाता है।

एक कमज़ोर कार्यान्वयन केवल टेक्स्ट को पुनर्जीवित करने के लिए लूप का उपयोग करता है।

एक मजबूत कार्यान्वयन पूरे वर्कफ़्लो को बेहतर बनाने के लिए लूप का उपयोग करता है।

इसका मतलब है कि एजेंट इसे बदलकर सुधार कर सकता है:

• वह क्या प्राप्त करता है
• वह किन टूल का उपयोग करता है
• चरणों का क्रम
• वह क्या याद रखता है
• वह क्या अनदेखा करता है
• क्या वह पहले स्पष्टीकरण माँगता है
• क्या वह जल्दी रुकता है

यह "उत्तर को फिर से लिखने" की तुलना में कहीं अधिक शक्तिशाली है।

सिस्टम प्रक्रिया स्तर पर स्व-सुधार करने वाला बन जाता है।

प्रॉम्प्ट पैटर्न जो स्व-सुधार का समर्थन करते हैं

प्रॉम्प्टिंग अभी भी मायने रखती है।

बस इसे लूप का समर्थन करने की आवश्यकता है।

यहाँ उपयोगी प्रॉम्प्ट पैटर्न दिए गए हैं।

प्रॉम्प्ट 1: मूल्यांकन-जागरूक कार्रवाई प्रॉम्प्ट

1आप एक सीमित वर्कफ़्लो के अंदर एक कार्य निष्पादित कर रहे हैं।
2आपका लक्ष्य केवल उत्तर देना नहीं है, बल्कि एक ऐसा उत्तर देना है जो मूल्यांकन में पास होगा।
3यदि जानकारी गायब है, तो उसे माँगें या प्राप्त करें।
4यदि परिणाम अनिश्चित है, तो आत्मविश्वास से अंतिम रूप न दें।
5यदि पिछला प्रयास विफल रहा, तो जब तक संदर्भ न बदल जाए, उसी रणनीति को दोहराने से बचें।

प्रॉम्प्ट 2: विफलता-निदान प्रॉम्प्ट

1पिछला प्रयास विफल रहा।
2संभावित विफलता कारण को इन श्रेणियों में से एक में वर्गीकृत करें:
3- लापता संदर्भ
4- टूल का दुरुपयोग
5- खराब धारणा
6- अधूरा आउटपुट
7- फ़ॉर्मेटिंग या स्कीमा विफलता
8- नीति विरोध
9फिर सबसे छोटा अगला परिवर्तन प्रस्तावित करें जो सफलता की संभावना में सुधार करता है।

प्रॉम्प्ट 3: संशोधन प्रॉम्प्ट

1नीचे दिए गए मूल्यांकक फीडबैक का उपयोग करके अगले प्रयास को संशोधित करें।
2यदि यह पहले ही विफल हो चुका है तो उसी तर्क पथ को न दोहराएँ।
3एक संकीर्ण, अधिक आधारभूत समाधान पसंद करें।
4यदि आवश्यक हो, तो उत्तर देने से पहले अधिक संदर्भ प्राप्त करें।

प्रॉम्प्ट 4: मेमोरी सारांश प्रॉम्प्ट

1पिछले प्रयास को अगले रन के लिए एक छोटे मेमोरी ब्लॉक में सारांशित करें।
2केवल शामिल करें:
3- क्या विफल रहा
4- क्या काम कर गया
5- क्या टाला जाना चाहिए
6- आगे क्या आज़माया जाना चाहिए
7इसे 120 शब्दों से कम रखें।

ये जादुई प्रॉम्प्ट नहीं हैं।

ये लूप व्यवहार को सुदृढ़ करने के लिए डिज़ाइन किए गए प्रॉम्प्ट हैं।

एक सरल पायथन-शैली लूप आर्किटेक्चर

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

1MAX_ATTEMPTS = 4
2
3memory = []
4
5for attempt in range(MAX_ATTEMPTS):
6    context = build_context(task=task, memory=memory)
7    plan = agent.plan(context)
8    result = agent.act(plan)
9
10    evaluation = evaluator.check(task=task, result=result)
11
12    if evaluation.passed:
13        return {
14            "status": "success",
15            "result": result,
16            "attempt": attempt + 1,
17        }
18
19    failure_summary = agent.summarize_failure(
20        result=result,
21        evaluation=evaluation,
22    )
23
24    memory.append({
25        "attempt": attempt + 1,
26        "failure": failure_summary,
27        "suggested_fix": evaluation.next_step,
28    })
29
30    if evaluation.requires_human:
31        return {
32            "status": "escalated",
33            "reason": evaluation.reason,
34            "attempt": attempt + 1,
35            "memory": memory,
36        }
37
38return {
39    "status": "failed",
40    "reason": "max_attempts_reached",
41    "memory": memory,
42}

यह जानबूझकर सरल है।

महत्वपूर्ण बिंदु कोड ही नहीं है।

यह संरचना है:

• प्रयास
• मूल्यांकन
• संकेत संग्रहीत करें
• अनुकूलन
• पुनः प्रयास या एस्केलेट

यही वह पैटर्न है जिसे आत्मसात करना है।

लूप इंजीनियरिंग सबसे अधिक कहाँ मायने रखती है

यह दृष्टिकोण विशेष रूप से उन वर्कफ़्लो में मूल्यवान है जहाँ पहले प्रयास में सफलता की गारंटी नहीं है।

कोडिंग एजेंट

लूप के लिए एकदम सही क्योंकि सिस्टम यह कर सकता है:

• परीक्षण चलाएँ
• विफलताओं का निरीक्षण करें
• कोड संशोधित करें
• आउटपुट की तुलना करें
• केवल तभी रुकें जब सत्यापन पास हो जाए

सहायता एजेंट

उपयोगी क्योंकि सिस्टम यह कर सकता है:

• नीति संदर्भ प्राप्त करें
• प्रतिक्रिया का मसौदा तैयार करें
• आधारभूतता की जाँच करें
• यदि जोखिम अधिक है तो अनुमोदन माँगें

अनुसंधान एजेंट

सहायक क्योंकि सिस्टम यह कर सकता है:

• कई स्रोत एकत्र करें
• अंतराल की पहचान करें
• फिर से खोजें
• केवल तभी संश्लेषित करें जब साक्ष्य पर्याप्त हो

दस्तावेज़ निष्कर्षण एजेंट

उपयोगी क्योंकि सिस्टम यह कर सकता है:

• फ़ाइलों को पार्स करें
• स्कीमा मान्य करें
• अस्पष्ट फ़ील्ड को पुनः आज़माएँ
• कम आत्मविश्वास वाले मामलों को एस्केलेट करें

परिचालन वर्कफ़्लो एजेंट

मूल्यवान क्योंकि सिस्टम यह कर सकता है:

• API कॉल करें
• परिणाम जाँचें
• आंशिक विफलता से उबरें
• अपवादों को मनुष्यों को रूट करें

इन सभी मामलों में, लूप की गुणवत्ता एक-शॉट जनरेशन गुणवत्ता से अधिक मायने रखती है।

लूप इंजीनियरिंग में सामान्य गलतियाँ

गलती 1: पुनः प्रयास को सुधार मानना

अधिक प्रयासों का स्वचालित रूप से बेहतर सीखना मतलब नहीं है।

यदि सिस्टम वही व्यवहार दोहराता है, तो वह सुधार नहीं कर रहा है।

वह बस लूप कर रहा है।

गलती 2: बहुत अधिक मेमोरी संग्रहीत करना

सभी पिछला संदर्भ मदद नहीं करता।

बहुत अधिक मेमोरी अगले प्रयास को दूषित कर सकती है।

संकुचित, कार्रवाई योग्य सबक संग्रहीत करें—कच्चे ट्रांसक्रिप्ट के ढेर नहीं।

गलती 3: मूल्यांकन छोड़ना

जाँच के बिना, एजेंट यह नहीं जान सकता कि क्या वह बेहतर हुआ है।

यह सबसे आम संरचनात्मक विफलता है।

गलती 4: कोई रोक शर्त नहीं

एक अप्रतिबंधित एजेंट उन्नत नहीं है।

यह महँगा है।

गलती 5: मानवीय फीडबैक को अनदेखा करना

यदि मनुष्य एक ही चीज़ को सही करते रहते हैं और लूप उस संकेत का कभी उपयोग नहीं करता है, तो सिस्टम वास्तव में सुधार नहीं कर रहा है।

गलती 6: हर कार्य के लिए एक विशाल लूप का उपयोग करना

अलग-अलग कार्यों को अलग-अलग लूप की आवश्यकता होती है।

एक सहायता एजेंट और एक कोडिंग एजेंट को समान पुनः प्रयास तर्क या मूल्यांकन नियम साझा नहीं करने चाहिए।

व्यावहारिक निर्माण अनुक्रम जो मैं सुझाता हूँ

यदि आप शुरुआत से निर्माण कर रहे हैं, तो इस क्रम का उपयोग करें।

चरण 1: सफलता को स्पष्ट रूप से परिभाषित करें

एक अच्छा परिणाम कैसा दिखता है?

चरण 2: विफलता श्रेणियों को परिभाषित करें

यह एजेंट आमतौर पर क्यों विफल होता है?

चरण 3: पहले मूल्यांकक बनाएँ

सिस्टम को कैसे पता चलेगा कि वह सफल हुआ या विफल?

चरण 4: मेमोरी नियम डिज़ाइन करें

प्रयासों के बीच क्या बना रहना चाहिए?

चरण 5: पुनः प्रयास रणनीति परिभाषित करें

पहले प्रयास और दूसरे प्रयास के बीच क्या बदलता है?

चरण 6: एस्केलेशन तर्क जोड़ें

मानव को कब हस्तक्षेप करना चाहिए?

चरण 7: सब कुछ महत्वपूर्ण लॉग करें

आप जो नहीं देखते, उसमें सुधार नहीं कर सकते।

चरण 8: लूप के काम करने के बाद ही अनुकूलन करें

मुख्य चक्र के स्थिर होने से पहले सिस्टम को जटिल न बनाएँ।

यह क्रम टीमों को प्रचार के बजाय व्यवहार पर ध्यान केंद्रित रखता है।

एजेंट को "स्व-सुधार" कहने से पहले एक सरल जाँच सूची

इसे वास्तविकता की जाँच के रूप में उपयोग करें।

• क्या एजेंट जानता है कि सफलता कैसी दिखती है?
• क्या वह प्रत्येक प्रयास का मूल्यांकन करता है?
• क्या वह विफलता से उपयोगी सबक संग्रहीत करता है?
• क्या वह फीडबैक के आधार पर रणनीति बदलता है?
• क्या वह आँख बंद करके उसी विफल पथ को दोहराने से बचता है?
• क्या वह जानता है कि कब रुकना है?
• क्या वह जानता है कि कब किसी मानव को एस्केलेट करना है?
• क्या आप माप सकते हैं कि क्या वह वास्तव में बेहतर हो रहा है?

यदि इनमें से अधिकांश गायब हैं, तो सिस्टम शायद स्व-सुधार नहीं कर रहा है।

यह सिर्फ़ पुनरावृत्तीय है।

अंतिम विचार

AI एजेंटों का भविष्य सिर्फ़ बेहतर प्रॉम्प्ट, अधिक टूल या लंबी श्रृंखला नहीं है।

यह बेहतर लूप है।

लूप इंजीनियरिंग यही संभव बनाती है।

यह एक एजेंट को एक-शॉट जनरेटर से एक ऐसे सिस्टम में बदल देती है जो यह कर सकता है:

• निरीक्षण
• मूल्यांकन
• अनुकूलन
• याद रखना
• बुद्धिमानी से पुनः प्रयास करना
• वास्तविक परिस्थितियों में सुधार करना

प्रोडक्शन AI में स्व-सुधार वास्तव में ऐसा ही दिखता है।

रहस्य नहीं।

जादू नहीं।

सिर्फ़ बेहतर सिस्टम डिज़ाइन।

यदि आप मजबूत एजेंट चाहते हैं, तो बस यह न पूछें कि उन्हें कैसे कार्य करना है।

पूछें कि उन्हें आगे जो हुआ उससे कैसे सीखना है।

यहीं असली लाभ है।