कोई भी एजेंट अपना होमवर्क खुद नहीं जांचता

आप Claude से अपने कोड की समीक्षा करने के लिए कहते हैं। वह कहता है कि कोड साफ-सुथरा दिख रहा है। ज़ाहिर है, वह ऐसा ही कहेगा। उसने वह कोड पाँच मिनट पहले ही लिखा था। आपने लेखक से ही अपने पेपर को ग्रेड करने के लिए कहा। उसने खुद को 'A' ग्रेड दे दिया।

AI कोड समीक्षाएं काम करती हैं। वे तब विफल हो जाती हैं जब आप लेखक से ही अपने काम की समीक्षा करने के लिए कहते हैं। गुणवत्ता एक ऐसे आर्किटेक्चर से आती है जहाँ कोई भी भूमिका स्वयं की जाँच नहीं करती है।

2024 के शोध से 'सेल्फ-प्रेफरेंस बायस' (self-preference bias) का पता चलता है। एक मॉडल अपने स्वयं के आउटपुट को समान गुणवत्ता वाले अन्य आउटपुट की तुलना में अधिक रेटिंग देता है। मॉडल अपनी स्वयं की शैली को पहचानता है और उसे प्राथमिकता देता है।

"लिखें, फिर जो लिखा है उसकी समीक्षा करें" वाला लूप टूटा हुआ है। आपको समीक्षा नहीं मिलती, बल्कि औचित्य (justification) मिलता है। एजेंट पहले ही तय कर चुका है कि कोड अच्छा था। दोबारा पूछने से केवल उसी निर्णय की पुष्टि होती है।

बेहतर एजेंट वर्कफ़्लो बनाने के लिए इन नियमों का पालन करें:

• समीक्षक कभी भी लेखक नहीं होना चाहिए। शैली की पहचान को तोड़ने के लिए समीक्षक के लिए एक अलग मॉडल फैमिली का उपयोग करें।
• एक साफ कॉन्टेक्स्ट (context) का उपयोग करें। समीक्षक को मूल कार्यान्वयन प्रॉम्प्ट (implementation prompt) या लेखक द्वारा निर्धारित बाधाएं (constraints) नहीं देखनी चाहिए।
• पहचान हटा दें। समीक्षक को यह न बताएं कि कोड किसने लिखा है। लेखक की पहचान पूर्वाग्रह (bias) को जन्म देती है।
• ओवर-फ्लैगिंग (over-flagging) से बचें। AI समीक्षक अक्सर उपयोगी दिखने के लिए समस्याओं को गढ़ लेते हैं। इससे आप उनकी बात सुनना बंद कर देते हैं।

गलत चेतावनियों को रोकने के लिए 'रसीद नियम' (receipt rule) का उपयोग करें। आपके देखने से पहले हर निष्कर्ष (finding) में प्रमाण शामिल होना चाहिए।

यदि कोई समीक्षक SQL injection जोखिम का दावा करता है, तो उन्हें निम्नलिखित प्रदान करना चाहिए:

• यूजर इनपुट का एक grep।
• क्वेरी फ्लो का एक trace।

यदि मान (value) एक कांस्टेंट (constant) है, तो उस निष्कर्ष को छोड़ दें। यदि यह एक HTTP request से आता है, तो इसे रखें। निर्णय से पहले प्रमाण आना चाहिए।

महत्वपूर्ण निष्कर्षों के लिए, संशयवादियों (skeptics) के एक पैनल का उपयोग करें। उनका काम बग की पुष्टि करना नहीं है। उनका काम उसे गलत साबित करना है। उन्हें यह साबित करने की कोशिश करनी चाहिए कि निष्कर्ष बग क्यों नहीं है। यदि बहुमत उस निष्कर्ष को खारिज नहीं कर पाता है, तभी वह पास होता है।

सत्य विरोधाभास से आता है, आत्म-घोषणा से नहीं।

एक ऐसा सिस्टम बनाएं जहाँ भूमिकाएं कभी आपस में न मिलें:

• लेखक कोड लिखता है।
• टेस्टर केवल स्पेसिफिकेशन (spec) से टेस्ट लिखता है।
• समीक्षक ने कोड नहीं लिखा है।
• किसी भी इंसान या LLM के देखने से पहले लिंटिंग (linting) और टेस्ट जैसे वस्तुनिष्ठ गेट्स (objective gates) पास होने चाहिए।

एक सुधारक जो खुद को ही सुधारता है, वह कुछ भी नहीं सुधारता। AI समीक्षा की गुणवत्ता इस बात पर निर्भर करती है कि आप उसे खुद का मूल्यांकन करने से कितनी बार रोकते हैं।

Source: https://dev.to/ohugonnot/no-agent-grades-its-own-homework-8lb

Optional learning community: https://t.me/GyaanSetuAi