HeadlinesBriefing favicon HeadlinesBriefing.com

कोडिंग एजेंट्स के लिए इंटेंट कंटीन्युइटी

Towards Data Science •
×

मैंने एक सिस्टम बनाया जो उपयोगकर्ता से यह पूछे बिना कि वे कहाँ से आए, पहले की बातचीत से प्रासंगिक आवश्यकताओं को स्वचालित रूप से खोजता, सत्यापित करता और लागू करता है।

मुख्य सबक: सिर्फ पिछला इतिहास निकालना यह जानने के समान नहीं है कि वास्तव में क्या अभी भी सटीक है। एक बुनियादी खोज सेटअप ने एक कोडिंग एजेंट को आवश्यक आवश्यकताओं का केवल 57% ही पकड़ा। एक सत्यापन परत जोड़ने से यह 100% तक पहुँच गया।

8 कार्यों में से, बेसलाइन ने शून्य सही किया, बुनियादी खोज ने 4 सही किए, और इंटेंट-अवेयर खोज ने सभी 8 सही किए। मैंने यह सब शून्य एम्बेडिंग, शून्य वेक्टर डेटाबेस, और पाइपलाइन में बिल्कुल भी LLM कॉल के बिना किया।

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

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

यह कोई बनाया हुआ परिदृश्य नहीं है। यह वह वास्तविक परीक्षण मामला है जिसका उपयोग मैंने इस लेख के लिए किया। नीचे, मैं आपको दिखाऊँगा कि तीन अलग-अलग तरीके इस सटीक समस्या को कैसे संभालते हैं।