कोडिंग एजेंट्स के लिए बड़े सॉफ्टवेयर कार्यों को पूरा करना क्यों चुनौतीपूर्ण है

अपने द्वारा लिखे गए पूर्णता मानक पर खरे उतरने के लिए बाध्य, एजेंटों ने जटिल प्रोग्रामों को लगभग समानता तक पुनर्निर्मित किया।

(मूल रूप से Factory ब्लॉग पर प्रकाशित)

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

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

उस माप के बिना, एक एजेंट काम करते हुए टुकड़ों में अपना निर्माण करता है। वह कार्य को विघटित करता है, प्रत्येक टुकड़े को उस संदर्भ में मान्य करता है जिसने उसे उत्पन्न किया, और अंततः निर्णय लेता है कि वह समाप्त हो गया है। हर स्थानीय निर्णय उचित हो सकता है जबकि समग्र के कुछ हिस्से अमापे रह जाते हैं।

मनुष्य वर्तमान में एजेंट की निगरानी करके लूप को बंद करते हैं: समग्र परिणाम को धारण करना और एजेंट को वापस उसकी ओर निर्देशित करना।

हम जानना चाहते थे कि क्या मॉडल अपने आप लूप को बंद कर सकता है।

gdal, शुरू से

इसका परीक्षण करने के लिए, हमने 24 चयनित ProgramBench कार्यों और तीन मॉडलों पर एकल-एजेंट और बहु-भूमिका रन की तुलना की। gdal को लें। हमने Droid से इसे दो तरीकों से शुरू से फिर से बनाने के लिए कहा। दोनों रनों में, Droid बिना किसी सीमा के संदर्भ प्रोग्राम को निष्पादित कर सकता था, लेकिन उसके स्रोत, परीक्षण या इंटरनेट तक नहीं पहुंच सकता था।

gdal

- C/C++ · ~2M लाइनें अपस्ट्रीम · ~600K CLI के माध्यम से पहुंच योग्य

gdal GDAL प्रोजेक्ट का कमांड-लाइन टूल है, जो भू-स्थानिक डेटा प्रोसेसिंग का वर्कहॉर्स है, और दर्जनों उप-कमांडों के पीछे दशकों की कार्यक्षमता रखता है। 1998 से विकास में होने के कारण, GDAL दुनिया के अधिकांश मैपिंग सॉफ्टवेयर - QGIS, ArcGIS, PostGIS - के नीचे बैठता है और उपग्रह इमेजरी से लेकर नेविगेशन चार्ट तक, दो सौ से अधिक रास्टर और वेक्टर प्रारूपों को पढ़ता है।

एक एकल एजेंट के रूप में, Droid ने अपने काम को लागू किया, स्वयं जांचा, और स्वयं निर्णय लिया कि वह कब समाप्त हुआ। इसने 17,000 लाइनें C++ लिखीं और प्रोग्राम के 36 प्रतिशत व्यवहार को पुन: प्रस्तुत किया। कोड ठोस था और सामान्य पथ काम करते थे, लेकिन प्रोग्राम का अधिकांश भाग अभी भी गायब था। इसका समय या बजट खत्म नहीं हुआ। यह रुक गया क्योंकि, अपने स्वयं के आकलन से, यह समाप्त हो गया था।

फिर हमने Droid को अलग-अलग भूमिकाओं वाली एक प्रणाली में व्यवस्थित किया। किसी भी कार्यान्वयन से पहले, एक भूमिका ने पूर्णता का एक निष्पादन योग्य मानक बनाया - पुन: कार्यान्वयन को क्या करना चाहिए और कौन से साक्ष्य इसे साबित करेंगे, इसका अपना विवरण - और फिर कार्यान्वयन को उस मानक पर रखा गया। यह रन बढ़कर 115,000 लाइनों तक पहुंच गया और 90 प्रतिशत व्यवहारिक समानता तक पहुंच गया।

सिस्टम रन ने जो उत्पादन किया वह अपना स्वयं का प्रोग्राम है: यह आकार या रूप में मूल से मिलता-जुलता नहीं है - GDAL कोडबेस का एक अंश, अपने तरीके से व्यवस्थित।

यह कोई असाधारण मामला नहीं था। 24 कार्यों में, उसी प्रणाली ने अपने 7-Zip पुनर्निर्माण को 54 प्रतिशत समानता से 95 प्रतिशत तक और अपने DuckDB पुनर्निर्माण को 34 से 80 प्रतिशत तक पहुंचाया। कई पुनर्निर्माण 90 के ऊपरी दशक तक पहुंच गए।

प्रति कार्य एक पंक्ति। रिंग एकल-एजेंट सीमा है: कार्य पर किसी भी एकल एजेंट ने जो सर्वश्रेष्ठ हासिल किया है, प्रत्येक सार्वजनिक लीडरबोर्ड प्रविष्टि और हमारे अपने सिंगल्स - प्रत्येक रिंग डैश की गई है क्योंकि इन 24 कार्यों पर हमारे अपने सिंगल्स उन सभी को धारण करते हैं। डॉट सिस्टम सीमा है, जो उस मॉडल द्वारा रंगीन है जो इसे धारण करता है, और संख्या वह है जो लूप को बंद करने से जुड़ी।

अंतर्निहित मॉडल नहीं बदला। लेकिन जब अपने स्वयं के पूर्णता मानक पर रखा गया, तो इसने प्रत्येक प्रोग्राम के अधिक व्यवहार को पुन: प्रस्तुत किया।

एक ही एजेंट जल्दी क्यों रुक जाता है

कोडिंग एजेंट आमतौर पर चलते-चलते अपने काम को मान्य करते हैं। वे एक टुकड़ा लागू करते हैं, कुछ जांच लिखते या चलाते हैं, आउटपुट का निरीक्षण करते हैं, और जारी रखने का निर्णय लेते हैं। एक छोटे बदलाव के लिए, यह अच्छी तरह से काम करता है: कार्य, कार्यान्वयन और साक्ष्य एक दृश्य में फिट होते हैं।

बड़े कार्यों को सुविधाओं, उप-प्रणालियों और काम के क्रमिक दौरों में विघटित करना होता है। जैसे-जैसे एजेंट प्रत्येक टुकड़े तक पहुंचता है, वह यह भी तय करता है कि कौन से साक्ष्य मायने रखेंगे और क्या वे साक्ष्य पर्याप्त हैं। ये जांच उस काम के दायरे को विरासत में लेती हैं जिसने उन्हें उत्पन्न किया। वे वह सब कुछ स्थापित कर सकते हैं जो एजेंट ने बनाने के बारे में सोचा, लेकिन उन सुविधाओं, अंतःक्रियाओं या बाधाओं को बाहर कर देते हैं जिनका उसने कभी प्रतिनिधित्व नहीं किया।

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

काम से पहले सत्यापन को परिभाषित करें

एक संपूर्ण परिणाम स्थापित करने के लिए आवश्यकताओं की एक सूची से अधिक की आवश्यकता होती है। सिस्टम को एक सूची की आवश्यकता है कि क्या स्थापित किया जाना चाहिए, प्रत्येक भाग को स्थापित करने की प्रक्रियाएं, और वर्तमान साक्ष्य कि वे प्रक्रियाएं भेजे जा रहे आर्टिफैक्ट के विरुद्ध पास होती हैं।

वह मानक आवश्यकताओं और प्रासंगिक सत्य स्रोतों से प्राप्त किया जाना चाहिए, इससे पहले कि कार्यान्वयन कार्य को व्यक्तिगत कार्य वस्तुओं में संकीर्ण कर दे। इसे जमे रहने की आवश्यकता नहीं है। जैसे-जैसे सिस्टम सीखता है, जांचों को जोड़ा, बदला या परिष्कृत किया जा सकता है। लेकिन पूर्णता का मानक चुपचाप उस चीज़ के आसपास नहीं ढहना चाहिए जो पहले ही बनाई जा चुकी है।

मनुष्यों द्वारा ऐसा शायद ही कभी क्यों किया जाता है

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

जो असामान्य है वह प्रत्येक परियोजना के लिए एक व्यापक मानक प्राप्त करना और बनाए रखना है। एक अनुरूपता सूट अपनी लागत को कई कार्यान्वयनों में फैला सकता है; एक उत्पाद टीम प्रत्येक एप्लिकेशन, पुनर्लेखन या माइग्रेशन के लिए उस लागत को फिर से वहन करती है। इसलिए अधिकांश टीमें वृद्धिशील रूप से मान्य करती हैं और संपूर्ण को संरक्षित करने के लिए समीक्षा, उत्पाद प्रतिक्रिया और शामिल लोगों की निरंतरता पर निर्भर करती हैं।

एजेंट इस व्यापार-बंद के दोनों पक्षों को बदल देते हैं। वे मनुष्यों द्वारा निरीक्षण करने की तुलना में तेजी से काम का उत्पादन कर सकते हैं, जिससे अनौपचारिक पर्यवेक्षण अड़चन बन जाता है। लेकिन उसी क्षमता को मानक पर ही लागू किया जा सकता है: परिणाम की सूची बनाना, जांच का निर्माण करना, और आर्टिफैक्ट बदलने पर उन्हें फिर से चलाना।

ProgramBench एक मांग वाले सीमा मामले का प्रतिनिधित्व करता है: संदर्भ प्रोग्राम उपलब्ध है, लेकिन मॉडल को व्यवहार स्थान और इसे मापने के तरीके दोनों की खोज करनी होगी।

ProgramBench

ProgramBench एक क्लीनरूम सॉफ्टवेयर-इंजीनियरिंग बेंचमार्क है। प्रत्येक कार्य एक संदर्भ प्रोग्राम, फिक्स्चर और आंशिक दस्तावेज प्रदान करता है। संदर्भ एक ब्लैक-बॉक्स ओरेकल है: इसे चलाया जा सकता है, लेकिन कभी पढ़ा, डीकंपाइल या ट्रेस नहीं किया जा सकता।

लक्ष्य संदर्भ प्रोग्राम के देखने योग्य व्यवहार को शुरू से पुन: प्रस्तुत करना है। प्रत्येक कार्य को व्यवहारिक जांच के एक छिपे हुए सूट के विरुद्ध ग्रेड और स्कोर किया जाता है।

ब्लैक-बॉक्स कार्यान्वयन की पूर्णता को मापना कठिन है। किसी एकल व्यवहार को संदर्भ को उम्मीदवार के विरुद्ध चलाकर आसानी से सत्यापित किया जा सकता है, लेकिन संपूर्ण को नहीं। शिप किया गया दस्तावेज इंटरफेस के एक हिस्से को कवर करता है; प्रोग्राम के शेष व्यवहार की खोज करनी होती है।

यह तीन प्रश्न छोड़ता है:

1. क्या एक फ्रंटियर मॉडल एक बड़े, अज्ञात प्रोग्राम के लिए पूर्णता का अपना स्वयं का माप बना सकता है?
2. क्या वह माप एक लंबे कार्यान्वयन के दौरान उपयोगी रह सकता है?
3. क्या उसका उत्तर देने से एक बेहतर आर्टिफैक्ट तैयार होता है?

कार्य चयन

हमने वर्तमान शीर्ष लीडरबोर्ड स्कोर के आधार पर बेंचमार्क के 24 सबसे कठिन कार्यों का चयन किया।

प्रत्येक बिंदु ProgramBench के 200 कार्यों में से एक है, जो किसी भी सार्वजनिक लीडरबोर्ड प्रविष्टि ने उस पर प्राप्त किए गए सर्वश्रेष्ठ स्कोर पर रखा गया है। स्याही के बिंदु 24 चयनित कार्य हैं; किसी भी बिंदु पर होवर करें उसका नाम देखने के लिए।

सेट को हाथ से चुना गया था, जो निम्न सर्वश्रेष्ठ-सार्वजनिक स्कोर की ओर भारित था। कुछ हार्ड-एंड उम्मीदवारों (php-src, pueue, ditaa, quickjs, chroma, miller) को स्क्रीनिंग के दौरान लगातार सुरक्षा ब्लॉक, एकल-एजेंट संतृप्ति, या एक अप्रलेखित पर्यावरण चर द्वारा गेट किए गए स्कोर के लिए हटा दिया गया था।

प्रयोगात्मक डिजाइन

प्रत्येक चयनित कार्य और मॉडल पैनल के लिए, हमने दो स्थितियों में से प्रत्येक में एक अभियान चलाया। सिस्टम स्थिति ने कार्यान्वयनकर्ता के सामान्य विकास लूप को बदले बिना पूर्णता का एक स्वतंत्र माप जोड़ा।

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

एक बार लॉन्च होने के बाद, प्रत्येक अभियान मानव हस्तक्षेप के बिना चला। अभियान कम्प्यूट-मैच नहीं थे; प्रत्येक तब तक जारी रहा जब तक एकल एजेंट या सिस्टम ऑर्केस्ट्रेटर ने शिप करने का निर्णय नहीं लिया।

प्रत्येक कोशिका एक अभियान का प्रतिनिधित्व करती है, बार-बार चलाने का औसत नहीं। एक अभियान समाप्त होने के बाद, इसके अंतिम उम्मीदवार को आधिकारिक pb-1.2.0 मीट्रिक का उपयोग करके एक बार ग्रेड किया गया था।

सिस्टम ने लूप कैसे बंद किया

उपकरण

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

हमारे सिस्टम में, वह नमूना एक उपकरण है। कार्यान्वयन शुरू होने से पहले, एक वैलिडेटर संदर्भ प्रोग्राम का सर्वेक्षण करता है और मैप करता है कि उसका व्यवहार कहाँ रहता है। फिर यह मामलों का एक भारित निकाय और उम्मीदवार के आउटपुट का न्याय करने के लिए आवश्यक तुलना नियम बनाता है। हमने उपकरण के लिए केवल रूपरेखा में पूछा। इसके अंदर सब कुछ - कौन से व्यवहार मायने रखते हैं, उन्हें कैसे भारित किया जाता है, साक्ष्य क्या माना जाता है - वैलिडेटर तय करता है।

gdal के लिए वैलिडेटर द्वारा बनाए गए उपकरण के दो मामले:

प्रत्येक मामला आह्वान का वर्णन करता है; ग्रेडिंग नीति बताती है कि परिणाम का न्याय कैसे करें:

वैलिडेटर ने ऐसे सैकड़ों मामले लिखे, और उन सभी में ठीक दो छूटों को लाइसेंस दिया - डीबग ट्रेस में एक मास्क किया गया हीप पता, एक फ़ाइल हेडर में एम्बेडेड एक तिथि - प्रत्येक के साथ रिकॉर्ड किए गए साक्ष्य कि संदर्भ वहां स्थिर बाइट्स का उत्पादन नहीं कर सकता है।

बाहरी लूप

सिस्टम में तीन भूमिकाएं होती हैं: ऑर्केस्ट्रेटर, कार्यान्वयनकर्ता और वैलिडेटर। ऑर्केस्ट्रेटर कार्यान्वयनकर्ता को, जो उम्मीदवार प्रोग्राम बनाता है, और वैलिडेटर को, जो इसे अपने उपकरण के विरुद्ध मापता है, दोनों को कार्य सौंपता है।

वैलिडेटर पहले उपकरण बनाता है। एक बार कार्यान्वयन शुरू होने के बाद, लूप इस प्रकार जाता है:

1. ऑर्केस्ट्रेटर चुनता है कि क्या मापा जाना चाहिए।
2. वैलिडेटर वर्तमान उम्मीदवार का परीक्षण करता है और विफलताओं की व्याख्या करता है।
3. ऑर्केस्ट्रेटर तय करता है कि कौन से निष्कर्ष वास्तविक हैं और आगे क्या काम होना चाहिए।
4. कार्यान्वयनकर्ता संदर्भ की जांच करता है और उम्मीदवार को आगे बढ़ाता है।

जब उपकरण क्रमिक उम्मीदवारों के बीच सार्थक अंतर प्रकट करना बंद कर देता है, तो ऑर्केस्ट्रेटर वैलिडेटर से कमजोर क्षेत्र का विस्तार करने या संदर्भ के विरुद्ध लक्षित अंतर परीक्षण शुरू करने के लिए कह सकता है।

दोनों भूमिकाएं समान तर्क स्तर पर एक ही मॉडल हैं, और दोनों संदर्भ प्रोग्राम रखते हैं, इसलिए उपकरण को मापने वाले पक्ष पर रखने से कोई जानकारी खर्च नहीं होती - केवल एक शॉर्टकट। उम्मीदवार और निष्कर्ष दीवार पार करते हैं; उपकरण नहीं करता। ग्रेडिंग एक बार, लूप के बाहर होती है, और इस पोस्ट में प्रत्येक स्कोर का स्रोत है।

दीवार

ProgramBench में, मानक को एक अतिरिक्त सीमा की आवश्यकता थी क्योंकि इसके मामले एक बहुत बड़े व्यवहार स्थान का केवल एक नमूना थे।

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

वैलिडेटर वर्तमान उम्मीदवार के विरुद्ध उपकरण चलाता है और विफलताओं को मूल कारण से समूहित करता है। ऑर्केस्ट्रेटर उन निष्कर्षों की समीक्षा करता है, शोर या अमान्य मापों को अस्वीकार करता है, और शेष समस्याओं को लापता सुविधाओं, उप-प्रणालियों या व्यवहार के स्तर पर एक निर्देश में बदल देता है। कार्यान्वयनकर्ता निर्देश प्राप्त करता है, स्वतंत्र रूप से संदर्भ की जांच करता है, और उम्मीदवार को बदलने का निर्णय लेता है।

यहाँ gdal रन से एक निर्देश का हिस्सा है:

निर्देश कार्यान्वयनकर्ता को बताता है कि उम्मीदवार कहाँ कमजोर है, बिना नमूना दिए।

परिणाम

हमने तीन फ्रंटियर मॉडलों - Fable 5, Kimi K3, और GPT 5.6 Sol - के साथ प्रयोग चलाया।

यहां प्रत्येक स्कोर बेंचमार्क के छिपे हुए सूट से आता है - उसी व्यवहार स्थान का एक नमूना जो किसी भी भूमिका ने कभी नहीं देखा। लाभ सिस्टम द्वारा बनाए गए उपकरण से एक स्वतंत्र माप में स्थानांतरित हो गए।

प्रत्येक पैनल एक मॉडल है, जो समान 24 कार्यों पर दो बार चलाया गया: बाईं ओर एक एकल एजेंट के रूप में, दाईं ओर पूर्ण सिस्टम के रूप में। प्रत्येक पंक्ति एक कार्य है, जो बेंचमार्क के छिपे हुए सूट से अपने आधिकारिक स्कोर पर रखा गया है। जो पंक्तियां गिरती हैं उन्हें डैश किया जाता है। मुट्ठी भर कोशिकाओं का कोई स्कोर नहीं है, एक परीक्षण मूल्यांकन के दौरान लटका हुआ है, इसलिए ग्रेडिंग कभी पूरी नहीं हुई। इन्हें पैनल के तल पर रखा गया है। बाईं ओर की रेल कार्यों को कठिनाई के अनुसार फ़िल्टर करती है, प्रति कार्य सर्वश्रेष्ठ सार्वजनिक स्कोर, उसी 0-100 पैमाने पर।

सिस्टम रन कहीं अधिक लंबे और अधिक महंगे थे; gdal के लिए, क्रेडिट का 14 गुना और दीवार समय का 13 गुना। लेकिन बजट वह नहीं था जिसने स्थितियों को अलग किया। प्रत्येक एकल-एजेंट अभियान समाप्त हुआ क्योंकि एजेंट ने इसे समाप्त करने का निर्णय लिया। अतिरिक्त कंप्यूट एक ऐसे एजेंट की मदद नहीं करता जो इसे खर्च नहीं करेगा। हमारे दृष्टिकोण ने जो बदला वह पूर्णता का निर्णय था; कंप्यूट उस निर्णय का अनुसरण करता था।

प्रत्येक कार्य, प्रत्येक मॉडल, प्रत्येक रसीद - सभी 144 कोशिकाओं के लिए स्कोर, व्यय, समयरेखा और आर्टिफैक्ट पूर्ण पोस्ट में इंटरैक्टिव एक्सप्लोरर में हैं:

प्रत्येक रन का अन्वेषण करें .

विधि नोट्स

• तर्क स्तर। Fable xhigh पर, Kimi high पर, Sol max पर चला, जो एकल एजेंट और सिस्टम में सभी तीन भूमिकाओं पर समान रूप से लागू किया गया।
• प्रति कोशिका एक रन। यहां प्रत्येक संख्या एक एकल रन है। इसे औसत करने के लिए कुछ भी दोहराया नहीं गया, इसलिए कोई भी कोशिका भिन्नता अनुमान नहीं रखती है, और इनमें से किसी भी आंकड़े को माध्य के रूप में नहीं पढ़ा जाना चाहिए।
• मुख्य रन। प्रारंभिक खंड में gdal, 7-Zip, और DuckDB संख्याएं Fable 5 रन हैं।
• पैमाना। GDAL अपस्ट्रीम लगभग दो मिलियन लाइनें C/C++ है (बंडल तृतीय-पक्ष पुस्तकालयों को हटाने के बाद 1.9 मिलियन)। कार्य में कॉन्फ़िगर किए गए अनुसार gdal CLI के माध्यम से पहुंच योग्य सबसेट - ग्यारह ड्राइवर, कोई GEOS नहीं - लगभग 600 हजार है। पुनर्निर्माण ने 115 हजार लाइनों में उस सतह के मापा व्यवहार के 90 प्रतिशत का मिलान किया।
• Opus विकल्प। Fable पैनल में छह कोशिकाएं Opus रन हैं जो Fable रनों के स्थान पर हैं जो सुरक्षा-अवरुद्ध थे, या तो एकल-एजेंट या सिस्टम रन में: bedtools2, gromacs, pandoc, samtools, sox और tree-sitter।
• कवरेज। 144 में से 141 कोशिकाओं को ग्रेड किया गया है। शेष तीन सिस्टम रन - Sol पर gdal और gromacs, Kimi पर samtools - बाधित हो गए थे और प्रकाशन से पहले पुनः नहीं चलाए गए; वे कोई स्कोर नहीं रखते।
• ग्रेडिंग। प्रत्येक स्कोर छिपे हुए सूट से आधिकारिक मीट्रिक है, जो pb-1.2.0 पर पिन किया गया है और एकल-एजेंट और सिस्टम आर्टिफैक्ट के लिए समान रूप से गणना की गई है।

निष्कर्ष

एकल एजेंट में कौशल की कमी नहीं थी। इसमें पूर्णता के मानक की कमी थी। एक स्वतंत्र मानक, जो उसी मॉडल द्वारा लिखा गया था, ने कार्यान्वयन को संदर्भ के साथ व्यवहारिक समानता के बहुत करीब ला दिया।

ProgramBench ने उस मानक को एक विशेष आकार दिया: एक ब्लैक-बॉक्स संदर्भ से पुनर्प्राप्त एक सूची और भारित नमूना।

अन्य कार्य अपना मानक विभिन्न स्रोतों से लेते हैं। एक उत्पाद कार्य उपयोगकर्ता-अनुमोदित प्रवाह और डिज़ाइन पर आकर्षित हो सकता है; एक माइग्रेशन, प्रतिस्थापित की जा रही प्रणाली पर।

वास्तविक सॉफ्टवेयर कार्य के लिए जो सामान्यीकृत होता है वह पूर्णता के एक बाहरी, निष्पादन योग्य मानक की आवश्यकता है - जो परिणाम से प्राप्त होता है, कार्यान्वयन से पहले ध्यान को संकीर्ण करता है, और तब तक वर्तमान रखा जाता है जब तक काम उस पर खरा नहीं उतरता।

हम इस संरचना को Missions की अगली पीढ़ी में बना रहे हैं। प्रतीक्षा सूची में शामिल होने के लिए हमसे संपर्क करें।