𝗧𝗿𝘂𝘀𝘁 𝗧𝗵𝗲 𝗛𝗮𝗿𝗻𝗲𝘀𝘀, 𝗡𝗼𝘁 𝗧𝗵𝗲 𝗠𝗼𝗱𝗲𝗹
माझ्या घरच्या हार्डवेअरवर चालणारे स्थानिक (local) 27B कोडिंग मॉडेल म्हणजे एक जुगार आहे. कधीकधी ते वीस मिनिटांत कोड दुरुस्त करते. तर कधीकधी ते चुकीची फाईल एडिट करते किंवा असा टेस्ट केस लिहिते जो काहीही होऊनही पास होतो.
LLMKube च्या Foreman चे उद्दिष्ट एक परिपूर्ण मॉडेल शोधणे हे नाही. तर मॉडेलपेक्षा जास्त तुम्ही ज्या हार्नेसवर (harness) विश्वास ठेवू शकाल, असे एक यंत्रण तयार करणे हे त्याचे उद्दिष्ट आहे.
या वीकेंडला, हार्नेसने स्वतःचे गार्डरेल्स (guardrails) तयार करून स्वतःचीच चाचणी केली. काय घडले ते खालीलप्रमाणे आहे:
• माझ्या स्थानिक कोडरने स्वतःसाठी तीन नवीन गेट्स (gates) तयार केले. • एक गेट अशा त्रुटीसह आले जी त्याला पकडायची होती. रिव्ह्यू प्रक्रियेने ती त्रुटी पकडली. • मशीन काम करत असताना तीन नवीन मानवी योगदानकर्त्यांनी (human contributors) चार स्वच्छ 'पुल रिक्वेस्ट' (pull requests) पाठवल्या. • तेच मॉडेल एका AMD बॉक्सवर आणि Apple Silicon Mac वर चालवले गेले. मॅकने (Mac) कोणालाही न अपेक्षित असा एक राउंड जिंकला. • कोणताही डेटा क्लाउड API कडे गेला नाही.
स्थानिक मॉडेलवरील कोडिंग एजंटची गुणवत्ता बदलत राहते. कितीही 'प्रॉम्प्ट ट्यूनिंग' (prompt tuning) केले तरी एक लहान मॉडेल 'फ्रंटियर मॉडेल' (frontier model) इतके विश्वसनीय बनवता येत नाही.
Foreman मॉडेलला विश्वसनीय बनण्याची विनंती करत नाही. ते मॉडेलला एका पाइपलाइनमध्ये (pipeline) गुंफते:
- कोडर एका क्लोन केलेल्या वर्कस्पेसमध्ये (cloned workspace) काम करतो.
- एक वेगवान गेट gofmt, vet, build, lint, आणि युनिट टेस्ट्स चालवते.
- एक रिव्ह्यूअर समस्येच्या (issue) संदर्भात 'डिफ' (diff) वाचतो.
- कोणताही कोड मंजूर करण्यापूर्वी एक 'क्लीन-रूम' Kubernetes Job संपूर्ण सूट पुन्हा चालवते.
- स्कोप चेक (scope checks) आणि रेपो-मॅप कॉन्टेक्स्ट (repo-map context) सारखी निश्चित नियमन यंत्रणा (deterministic rails) संपूर्ण प्रक्रियेभोवती असते.
मॉडेल हा सिस्टमचा एक अनिश्चित भाग आहे. मॉडेल विश्वसनीय नसले तरीही निकाल विश्वसनीय बनवणे हे सिस्टमचे काम आहे.
खरा प्रश्न "मॉडेल चांगले आहे का" हा नाही. खरा प्रश्न हा आहे की "जेव्हा मॉडेल खराब असते, तेव्हा हार्नेस त्याला पकडतो का."
या वीकेंडला, हार्नेसने दोन मोठे बग्स (bugs) पकडले. दोन्ही 'सेल्फ-कन्फर्मिंग' (self-confirming) टेस्ट्स होत्या. त्या टेस्ट्स पास झाल्या कारण त्या स्वतःच पास होण्यासाठी लिहिल्या गेल्या होत्या. त्यांनी प्रत्यक्षात कोडची चाचणी केली नाही.
मी हे अपयश Foreman कडे सोपवले. मी हार्नेसला ते सुधारण्यासाठी गेट्स तयार करू दिले:
- स्कोप गार्ड (scope guard): ते चुकीच्या सबसिस्टमला स्पर्श करणारा कोणताही बदल नाकारते.
- रिव्ह्यूअर रुब्रिक (reviewer rubric): ते सुनिश्चित करते की टेस्ट्समध्ये प्लेसहोल्डर्सऐवजी (placeholders) वास्तविक प्रोडक्शन व्हॅल्यूजचा वापर केला जावा.
- बाइट चेक (bite check): नवीन टेस्ट जुन्या कोडवर फेल होणे आवश्यक आहे. जर ती दोन्हीवर पास झाली, तर ती खरी टेस्ट नाही.
बाइट चेक स्वतःच्या पहिल्या टेस्टमध्ये फेल झाले. त्याने तयार केलेले गेट दोषपूर्ण होते. परंतु, मर्ज होण्यापूर्वी रिव्ह्यू प्रक्रियेने ती चूक पकडली. हेच डिझाइनचे यश आहे.
स्थानिक पातळीवर इंजिनिअरिंगचे काम करण्यासाठी तुम्हाला एखाद्या प्रचंड मोठ्या 'फ्रंटियर मॉडेल'ची गरज नाही. तुम्हाला अशा हार्नेसची गरज आहे ज्यावर तुमचा विश्वास आहे. ते तयार करा, आणि एक लहान मॉडेल तुमचा उपयुक्त सहकारी बनेल. हे असे एक सिस्टम बनेल जे चुका पकडते, ज्यामुळे तुम्हाला मध्यरात्री कोडची प्रत्येक ओळ वाचण्याची सक्ती होणार नाही.
Optional learning community: https://t.me/GyaanSetuAi