GPT‑6.1 Sol सह Asana चा मॉडेल खर्च 76 पट कमी

Codex मधील GPT‑6 Astra वापरून प्रयोग करत Asana ने GPT‑6.1 Sol वरील ब्राउझर एजंटची कार्यप्रक्रिया सुधारली. त्यामुळे खर्च 76 पट कमी झाला आणि वेग 5 पट वाढला.

Asana ने अधिग्रहित केलेल्या⁠(नवीन विंडोमध्ये उघडेल) StackAI⁠(नवीन विंडोमध्ये उघडेल) या मंचाद्वारे ग्राहकांना विविध व्यावसायिक अनुप्रयोगांतील कामे स्वयंचलित करता येतात. StackAI वापरून ग्राहक कोड न लिहिता संकेतस्थळांवर फिरणाऱ्या, अर्ज भरणाऱ्या आणि माहिती गोळा करणाऱ्या कार्यप्रक्रिया तयार करू शकतात. Asana च्या व्यापक वापरामुळे या कार्यप्रक्रियांतील लहान त्रुटींचाही एकत्रित परिणाम मोठा होतो.

Asana मधील StackAI चे मुख्य तंत्रज्ञान अधिकारी डॉ. फ्रँक हिडाल्गो यांनी ब्राउझर एजंटचा वेग वाढवण्याचे आणि खर्च कमी करण्याचे ठरवले. त्यांनी Codex मधील GPT‑6 Astra ला एजंटची तपासणी, सुधारणांच्या चाचण्या आणि निष्कर्षांची तुलना करण्यास सांगितले. त्यांच्या अंदाजानुसार स्वतः केल्यास एक ते दोन महिने लागले असते, ते काम सुमारे आठवड्यात झाले.

Asana च्या 144 फेऱ्यांच्या अभ्यासात⁠(नवीन विंडोमध्ये उघडेल) GPT‑6.1 Sol आणि इथे मॉडेल A, B व C म्हटलेल्या इतर तीन अत्याधुनिक मॉडेलच्या चाचण्या झाल्या. GPT‑6.1 Sol वरील सुधारित कार्यप्रक्रियेत प्रत्येक फेरीला सरासरी अंदाजित मॉडेल खर्च $0.47 आणि सुमारे चार मिनिटे लागली. मॉडेल B वरील मूळ सेवा संरचनेपेक्षा खर्च 76 पट कमी आणि वेग 5 पट अधिक होता.

वेगाने काम सुरू करण्यासाठी हिडाल्गो यांनी Codex मधील GPT‑6 Astra ला संपूर्ण कोडची रचना तपासायला आणि एजंट मॉडेलसाठी प्रत्येक विनंती कशी तयार करतो ते समजावून सांगायला लावले. GPT‑6 Astra ला आढळले की एजंट ठरावीक सूचना आणि साधनांच्या व्याख्या कॅशमध्ये ठेवत होता, पण गोळा केलेल्या पृष्ठांवरील मजकुराचा आणि स्क्रीनशॉटचा वाढता इतिहास ठेवत नव्हता. त्यामुळे प्रत्येक विनंतीसोबत हा इतिहास पुन्हा पूर्ण दराने पाठवला जात होता.

एजंट जवळपास प्रत्येक टप्प्यावर जुने स्क्रीनशॉट काढत होता आणि मजकूर कमी करत होता. प्रत्येक संपादनाने इतिहास बदलत असल्याने तो केवळ कॅशमध्ये ठेवल्याने फायदा झाला नसता. शिवाय, माहिती गमावल्यामुळे एजंटला आधी वाचलेल्या पृष्ठांवर पुन्हा जावे लागू शकले असते.

हिडाल्गो यांनी GPT‑6 Astra ने सुचवलेले उपाय तपासले आणि चाचणीसाठी तीन निवडले:

• एजंटचा ब्राउझिंग इतिहासही कॅशमध्ये ठेवणे

• साठवून ठेवता येणाऱ्या मजकुराचे प्रमाण वाढवणे

• प्रत्येक टप्प्यावर स्क्रीनशॉट काढण्याऐवजी ते गटाने काढणे

कोणते चल महत्त्वाचे आहेत हे ठरवण्यासाठी GPT‑6 Astra ने सुरुवातीला झटपट चाचण्या केल्या. कोडची रचना नियंत्रित प्रयोगांसाठी केलेली नव्हती. म्हणून त्याने कोडची पुनर्रचना केली, जेणेकरून एकाच दर्शनी भागावर आणि अंतर्गत प्रणालीवर वेगवेगळ्या सेटिंग्जसह अनेक कार्यप्रक्रिया समांतर चालू शकतील.

Astra ने संपूर्ण अभ्यास केला: इतिहासासाठी 120,000 आणि 480,000 अक्षरांच्या मर्यादा आणि कॅश व स्क्रीनशॉटसाठी सहा धोरणे. चारही मॉडेलवर प्रत्येकाची तीनदा चाचणी झाली (खालील तक्ता पाहा). सर्वोत्तम कामगिरी करणाऱ्या धोरणात 20 स्क्रीनशॉट साठल्यावर सर्वांत अलीकडचा एकच ठेवून बाकीचे काढले जात होते. यामुळे स्क्रीनशॉट काढण्याच्या दोन कृतींमधील काळात आधीचा इतिहास अधिक वेळ अपरिवर्तित राहत होता. इतिहासाची वाढीव मर्यादा आणि हे धोरण एकत्र वापरून सुधारित कार्यप्रक्रिया तयार झाली. प्रत्येक संरचनेत एकच काम केले गेले: सार्वजनिक नमुना सूचीतील 32 पुस्तकांपैकी प्रत्येकासाठी सहा माहितीघटक गोळा करणे. Asana चे काही ग्राहक StackAI मध्ये करतात, त्याच प्रकारचे हे काम होते.

GPT‑6 Astra ने कार्यप्रक्रिया चालवल्या आणि विनंत्या, वापराच्या नोंदी व निष्पत्ती तपासल्या. मॉडेलच्या स्वतंत्र सत्रांत कामाचा आढावा घेतला गेला. प्रत्येक सत्रातील विनंत्या, डेटाचा मागोवा आणि निष्कर्ष Asana च्या सॉफ्टवेअर वितरण मंचावर, Command⁠(नवीन विंडोमध्ये उघडेल) मध्ये नोंदवले गेले. त्यामुळे संघाला नंतर संपूर्ण अभ्यासाचा आढावा घेता आला. Command मधील निष्कर्षांवरून कामाच्या नोंदी, त्यानंतर कोडमधील बदल समाविष्ट करण्याच्या विनंत्या तयार झाल्या आणि बदल प्रत्यक्ष सेवेत लागू झाले.

सुधारणेमुळे मॉडेल B चा प्रत्येक फेरीचा अंदाजित खर्च किमान $36.21 वरून $1.24 झाला, म्हणजे 29 पट कमी झाला. काही मूळ फेऱ्या पूर्ण होण्याआधीच टप्प्यांची मर्यादा गाठत होत्या. GPT‑6.1 Sol वरील सुधारित कार्यप्रक्रियेचा खर्च आणखी 2.6 पट कमी, म्हणजे $0.47 होता. सुधारित कार्यप्रक्रियेतील प्रत्येक फेरीत काम पूर्ण झाले आणि योग्य उत्तर मिळाले.

केवळ GPT‑6.1 Sol वर, इतिहासाच्या वाढीव मर्यादेसह नव्या कॅश आणि स्क्रीनशॉट धोरणामुळे प्रत्येक फेरीचा खर्च $1.97 वरून $0.47 झाला, म्हणजे 4 पट कमी झाला. प्रत्येक विनंतीचा खर्च सुमारे 3 पट कमी झाला. कारण 89% इनपुट कॅशमधून आले आणि त्याचा दर कॅशबाहेरील इनपुटच्या दराच्या 5% होता. फेऱ्यांचा वेगही वाढला: मॉडेल B च्या मूळ संरचनेत किमान 22.5 मिनिटे लागत होती, तर GPT‑6.1 Sol वरील सुधारित कार्यप्रक्रियेत साधारण चार मिनिटे लागली.

एजंट उत्तर देतो की नाही, यावरही इतिहासाच्या व्यवस्थापनाचा कसा परिणाम होतो हे तपासणीत दिसले. GPT‑6.1 Sol ला ब्राउझिंग इतिहास ठेवण्यासाठी अधिक जागा दिल्याने उत्तर मिळालेल्या फेऱ्यांची संख्या वाढली. कमी मर्यादेत 18 पैकी तीन फेऱ्यांत उत्तर मिळाले होते; वाढीव मर्यादेत सर्व 18 फेऱ्यांत योग्य उत्तर मिळाले. हिडाल्गो यांच्या मते, परिचालन खर्च परवडणारा ठेवून ग्राहकांना अधिक वेगवान आणि सक्षम मॉडेल उपलब्ध करून देण्यात याचे व्यावसायिक मूल्य आहे.

Asana ने StackAI मध्ये ब्राउझरद्वारे पृष्ठांवर फिरण्याच्या पद्धतीतील बदल लागू केले आहेत. असे प्रयोग पुन्हा करणे सोपे व्हावे यासाठी साधनेही विकसित केली जात आहेत. पुढे या चाचण्या मंचाच्या मूल्यमापनात समाविष्ट करण्याचा संघाचा विचार आहे. त्यामुळे ग्राहक आणि अंतर्गत संघांना एजंटची संरचना ठरवताना खर्च, लागणारा वेळ आणि उत्तराचा दर्जा यांची तुलना करता येईल.

Asana आता उत्पादनातील वैशिष्ट्ये उपलब्ध करण्यापूर्वी तपासण्यासाठी Codex मधील GPT‑6 Astra वापरत आहे. Astra मंचावर फिरते, वेगवेगळे इनपुट वापरून पाहते आणि मानवी गुणवत्ता तपासकांसाठी त्रुटी नोंदवते. हिडाल्गो यांच्या मते, अनेक क्लाउड एजंट सत्रांनी समांतरपणे वैशिष्ट्ये तपासणे हा नव्या सॉफ्टवेअर विकास जीवनचक्राचा पाया आहे.

संपूर्ण अभ्यास Asana⁠(नवीन विंडोमध्ये उघडेल) आणि StackAI⁠(नवीन विंडोमध्ये उघडेल) यांच्या ब्लॉगवर उपलब्ध आहे.