Eval-Driven Agent Development: मी प्रॉम्प्ट्स केवळ अंदाजावर (vibes) ट्यून करणे कसे थांबवले

मी एक प्रॉम्प्ट बदलला. पुढची रन अधिक चांगली दिसली. त्या बदलामुळे मदत झाली की मी नशिबवान होतो?

बराच काळ, माझे उत्तर "मला असे वाटते" असे असायचे. मी एखादी कमांड बदलून (tweak), पाइपलाइन चालवायचो, ती यशस्वी होताना पाहायचो आणि मग ती शिप (ship) करायचो. हे 'व्हायब्स-आधारित' (vibes-based) इंजिनिअरिंग आहे. एजंट्स बनवणारे जवळजवळ प्रत्येकजण असेच करतो कारण दुसरा पर्याय कठीण वाटतो.

पण कोडिंग एजंट्स हे नॉन-डिटरमिनिस्टिक (non-deterministic) असतात. तुम्ही एकच टास्क दोनदा चालवू शकता आणि तुम्हाला दोन वेगळे रिझल्ट्स मिळू शकतात. एक चांगली रन तुम्हाला काहीही सांगू शकत नाही. तुमचा बदल खरोखर काम करून गेला की केवळ नशिबाने गोष्टी चांगल्या झाल्या, हे तुम्ही सांगू शकत नाही.

मी मशीन लर्निंगच्या शिस्तीचा वापर करून हे सोडवले. मी माझ्या संपूर्ण सिस्टमला कव्हर करण्यासाठी एक इव्हॅल्युएशन फ्रेमवर्क (evaluation framework) तयार केले.

हे फ्रेमवर्क कसे काम करते ते खालीलप्रमाणे आहे:

• Target: एक स्थिर (frozen) कोडबेस. स्कोअरची तुलना करता यावी म्हणून तो तसाच ठेवला जातो. • Task: प्रॉम्प्ट आणि ऑरेकलसह (oracle) एक विशिष्ट बेंचमार्क आयटम. • Oracle: एक डिटरमिनिस्टिक चेक. हे असे शेल कमांड्स आहेत जे पास होणे आवश्यक आहे. • Variant: तुम्ही टेस्ट करत असलेला विशिष्ट बदल, जसे की नवीन प्लॅनर. • Trial: एक सिंगल रन. रँडमनेस (randomness) विचारात घेण्यासाठी मी प्रत्येक टास्क अनेक वेळा चालवतो.

विविध प्रकारच्या त्रुटी (failures) पकडण्यासाठी मी दोन प्रकारचे स्कोअरिंग वापरतो:

  • Code Graders (Deterministic): हे टेस्ट पास रेट, खर्च, वेळ आणि फाईलमधील बदल तपासतात.
  • LLM Judge (Probabilistic): एक वेगळे, फिक्स्ड मॉडेल स्पेसिफिकेशनची गुणवत्ता आणि अंमलबजावणीची अचूकता (implementation fidelity) तपासते.

कोड ग्रेडर्स तुम्हाला कोड चालतो की नाही हे सांगतात. जज तुम्हाला कोड चांगला आहे की नाही हे सांगतो. तुम्हाला या दोन्हीची गरज आहे.

मी सरासरी (averages) वापरणे देखील थांबवले. 'मीन' (means) एजंट्सबद्दल खोटे बोलतात. जर एखादा टास्क ३ पैकी २ वेळा यशस्वी झाला, तर तो ठीक वाटतो. पण तो विश्वसनीय (reliable) नसतो. त्याऐवजी, मी दोन मेट्रिक्स वापरतो:

  • pass@k: एजंट किमान एकदा यशस्वी झाला का? (क्षमता/Capability)
  • pass^k: एजंट प्रत्येक वेळी यशस्वी झाला का? (विश्वसनीयता/Reliability)

pass^k मध्ये झालेली वाढ ही खरी जीत आहे. याचा अर्थ तुम्ही एजंटला केवळ नशिबवान न बनवता, सुसंगत (consistent) बनवले आहे.

सिस्टम तीक्ष्ण ठेवण्यासाठी, मी खोलवर समज आवश्यक असलेले कठीण टास्क जोडतो. जेव्हा एखादा एजंट खऱ्या बगवर (bug) अपयशी ठरतो, तेव्हा मी त्या अपयशाला कायमस्वरूपी टास्कमध्ये रूपांतरित करतो. यामुळे एक 'क्लोज्ड लूप' (closed loop) तयार होतो. एजंट जसा सुधारतो, तसा बेंचमार्क अधिक कठीण होत जातो.

ही इन्फ्रास्ट्रक्चर तयार करणे खूप कष्टाचे आहे, पण मी तयार केलेली ही सर्वात प्रभावी (highest leverage) गोष्ट आहे. यामुळे "मला वाटते हे अधिक चांगले आहे" चे रूपांतर "हे कमी खर्चात २०% अधिक विश्वसनीय आहे" मध्ये झाले.

कोडिंग एजंट्सचे डेमो देणे सोपे आहे पण त्यांच्यावर विश्वास ठेवणे कठीण आहे. जर तुम्हाला केवळ डेमोच्या पलीकडे जायचे असेल, तर तुम्हाला मोजमाप (measure) करण्याचा निर्णय घ्यावा लागेल.

Source: https://dev.to/rickjms/eval-driven-agent-development-how-i-stopped-tuning-prompts-on-vibes-1189

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