मुख्य मजकूराकडे जा
OpenAI

२७ मे, २०२६

इंजिनिअरिंग

Codex सह स्वतः सुधारणारे कर एजंट तयार करणे

तांत्रिक स्टाफ सदस्यांकडून: Aravind Srinivasan आणि Samay Shamdasani (Thrive Holdings), Arthur Fernandes Araujo आणि John de Wasseige (OpenAI)

लोड होत आहे...

प्रॅक्टिशनर कौशल्य आणि Codex-चालित लूप एकत्र करून Thrive Holdings आणि OpenAI ने Crete लेखापालांसाठी Tax AI कसे सोबत विकसित केले

प्रत्यक्ष वापरातील प्रणाली प्रयोगशाळेत जशा वागतात, त्यापेक्षा उत्पादनात वेगळ्या प्रकारे वागतात आणि तैनातीपूर्वी ज्यांचा अंदाज लावणे कठीण असते अशा प्रकारे त्या बिघडतात. संघांना अनेकदा हे दोष उत्पादन लॉन्च झाल्यानंतर आढळतात, आणि मग ते अनेक आठवडे अपवादात्मक प्रकरणांची तपासणी करण्यात, प्रॉम्प्टमध्ये बदल करण्यात आणि उत्पादनातील अभिप्रायाचे टिकाऊ उत्पादन सुधारणांमध्ये रूपांतर करण्यात घालवतात. ही अभिप्राय लूप मॅन्युअल आणि संथ आहे, आणि जेव्हा एखादा अभियंता ती पुढे नेतो तेव्हाच त्यात सुधारणा होते. परंतु आज, विचारपूर्वक तयार केलेल्या eval पायाभूत सुविधा, प्रॅक्टिशनरशी आणि प्रत्यक्ष जगातील वातावरणाशी थेट संपर्क, आणि Codex च्या अत्याधुनिक एजंटिक क्षमतांमुळे, तुम्ही स्वतःमध्ये सुधारणा करणारे एजंट तयार करू शकता.

या पोस्टमध्ये, आम्ही Codex चा वापर करून या प्रकारचा एजंट कसा तयार केला हे सविस्तरपणे सांगणार आहोत. गेल्या सहा महिन्यांत, OpenAI चे फॉरवर्ड डिप्लॉय केलेले अभियंते आणि संशोधक यांनी Thrive Holdings च्या अभियंत्यांसोबत मिळून, वाढत्या गुंतागुंतीच्या कर विवरणपत्रांची तयारी करण्यास मदत करण्यासाठी Crete(नवीन विंडोमध्ये उघडेल)च्या 30+ अकाउंटिंग फर्म्सच्या नेटवर्कसोबत आणि त्यांच्यासाठी Tax AI तयार करण्यासाठी सहकार्य केले. प्रत्येक त्रुटी शोधून ती दुरुस्त करण्यासाठी अभियंत्यांवर अवलंबून राहण्याऐवजी, Tax AI Codex चा वापर करून उत्पादनातील वापराचे रूपांतर अशा संरचित संकेतांमध्ये करते, जे स्वायत्त सुधारणेला चालना देतात.

Crete चे प्रॅक्टिशनर्स प्रत्येक हंगामात हजारो कर रिटर्न तयार करतात, ज्यासाठी लाखो मूळ दस्तऐवजांवर काम करावे लागते. मध्यम ते मोठ्या गुंतागुंतीच्या फाइलिंगसाठी, केवळ डेटा एंट्रीलाच प्रत्येक रिटर्नमागे आठ तास लागू शकतात, आणि त्यात विस्कळीत डेटा स्रोत, मागील वर्षाचे दस्तऐवज, तसेच मॅन्युअल एक्स्ट्रॅक्शन आणि गणना यांचा समावेश असतो. कर हंगामातील सर्वाधिक व्यस्त काळात कर तयारी हा एक महत्त्वाचा अडथळा असल्याचे त्यांनी आम्हाला दाखवून दिले.

ही समस्या सोडवण्यासाठी, Tax AI ने या कर हंगामात पायलटमध्ये सहभागी झालेल्या Crete फर्म्समधील 7,000 कर रिटर्न्सवर प्रक्रिया केली. ही प्रणाली 1040 आणि 1041 कर रिटर्न तयार करण्यातील वेळखाऊ प्रक्रियेचा मोठा भाग स्वयंचलित करते, पण कार्यक्षमतेतील वाढीपेक्षाही अधिक प्रभावी गोष्ट म्हणजे ही प्रणाली स्वतःच तीन महिन्यांपूर्वी प्रथम तैनात केलेल्या आवृत्तीपेक्षा मोजता येण्याजोगी अधिक चांगली आहे.

मोजता येण्याजोगी स्व-सुधारणा

Tax AI मध्ये, प्रॅक्टिशनर्स क्लायंट-विशिष्ट नोंदींसह स्रोत फाइल्स अपलोड करतात. त्यानंतर Tax AI पुनरावलोकनासाठी तयार कर इंजिन सबमिशन तयार करते. यामुळे प्रॅक्टिशनर्सचा कर तयारीवरील सुमारे एक-तृतीयांश वेळ वाचतो, 97% पर्यंत अचूकतेने रिटर्न्सचा मसुदा तयार होतो, आणि थ्रुपुट सुमारे 50% ने वाढतो, ज्यामुळे त्यांना क्लायंट्ससोबत वेळ घालवण्यासाठी अधिक वाव मिळतो. 

नंतर दुरुस्तीची गरज न पडता Tax AI एखादा रिटर्न किती अचूकपणे पूर्ण करू शकते हे समजून आम्ही ही सुधारणा मोजू शकतो. 75%, 90%, किंवा 100% योग्य फील्ड पूर्णता गाठणाऱ्या रिटर्न्सचा वाटा तपासून आम्ही अचूकता मोजतो. लॉन्च करताना, फक्त एक चतुर्थांश रिटर्न्स 75% योग्य फील्ड पूर्णतेपर्यंत पोहोचले होते, पण सहा आठवड्यांत 86% ने तो टप्पा गाठला. 90% आणि 100% योग्य फील्ड पूर्णतेच्या पातळ्यांवर प्रणालीने आणखी वेगवान वाढ दाखवली. या मर्यादा आम्हाला वेगवेगळ्या रिटर्न्सना अजून किती प्रॅक्टिशनर फॉलो-अपची गरज आहे याचे व्यावहारिक चित्र देतात. 

सुरुवातीला, Tax AI W-2 आणि 1099 सारखी सोपी कामे हाताळत असे. जसा जसा हंगाम पुढे सरकला, तसे ते K-1, शेड्युल्स आणि अधिक कठीण अपवादात्मक प्रकरणांसारख्या अधिक गुंतागुंतीच्या रिटर्न्सकडे वळले. प्रत्येक नवीन क्षमतेमुळे आधीच्या क्षमतेपेक्षा प्रत्येक रिटर्नमागे अधिक वेळेची बचत झाली, कारण त्याने स्वीकारलेली कामे मॅन्युअली अधिक कठीण आणि वेळखाऊ होती. आजही आम्हाला यात सतत प्रगती होताना दिसत आहे.

पुढे, आम्ही तुम्हाला दाखवणार आहोत की आमच्या टीम्सनी तीन महत्त्वाच्या स्तंभांवर अवलंबून राहून टॅक्स Tax AI ला स्व-सुधारित कसे बनवले: 1) तज्ञ प्रॅक्टिशनरचा अभिप्राय, 2) उत्पादन नोंदी (इनपुटपासून अंतिम आउटपुटपर्यंतचा एक संरचित इतिहास), आणि 3) सतत आणि जलद उत्पादन विकासाला सक्षम करण्यासाठी, विशेष evals वर आधारित Codex-चालित पुनरावृत्ती लूप. आम्हाला आशा आहे की आमचा अनुभव अशा क्षेत्रांमधील इतर बिल्डर्ससाठी उपयुक्त ठरेल, जिथे संपूर्ण प्रणालीची आणि त्यातून जाणाऱ्या डेटाची गुणवत्ता निश्चित करण्यासाठी प्रॅक्टिशनरचे कौशल्य महत्त्वाचे असते.

जसजसे Tax AI ने अधिक गुंतागुंतीच्या फाइलिंगमध्ये विस्तार केला, तसतसे कर हंगामादरम्यान 75%, 90% आणि पूर्णपणे भरलेल्या स्कोअर केलेल्या रिटर्नचा वाटा वाढतच गेला.

समस्या

जेव्हा आम्ही कर तयारीच्या अधिक कठीण भागांकडे (K-१, भाड्याच्या मालमत्तेचे वेळापत्रक आणि असे कर फॉर्म जिथे अनेक स्रोत फाइल्समधील मूल्यांची जुळवाजुळव करावी लागत होती) वळलो, तेव्हा हे स्पष्ट झाले की खरे आव्हान हे होते की, उत्पादनातील गुंतागुंतीच्या त्रुटी दृश्यमान, समजण्यायोग्य आणि त्यावर कार्यवाही करण्यायोग्य बनवणे हे उत्पादनाला जमेल का.

उत्पादनाच्या सुरुवातीच्या काळात, बहुतेक दुरुस्ती मॅन्युअली केली जात होती. प्रॅक्टिशनर सिस्टीममधील त्रुटी दुरुस्त करू शकत होते, परंतु उत्पादन संपूर्ण संदर्भ विचारात घेत नव्हते: फाइलिंगपूर्वी बदललेले मूल्य हे खरे एक्स्ट्रॅक्शन चुकले आहे, मॅपिंगची समस्या आहे, उत्पादनासाठीच्या समर्थनाचा अभाव आहे किंवा कार्यप्रवाहातील अपेक्षित गोंधळ आहे, हे दर्शवू शकत होते. अशा प्रकरणांची उकल करण्यासाठी अभियांत्रिकी टीमकडून पाठपुरावा करणे आवश्यक होते. अभियंते कोडिंग एजंट वापरू शकत होते, परंतु सुधारणा लूपमध्ये AI चा अर्थपूर्ण वापर करण्यासाठी सिस्टीमची रचना अजून झालेली नव्हती. नेमके कोणते आव्हान आहे हे ओळखण्यासाठी आमच्याकडे योग्य संकेत नव्हता.

आमचा दृष्टिकोन: तीन भाग असलेला लूप

यामुळे आम्ही प्रणालीची रचना तीन स्तंभांवर आधारित केली:

  1. प्रत्यक्ष काम करणाऱ्यांच्या संपर्कात रहा: उत्पादनाने काय शिकावे, हे प्रत्यक्ष काम करणाऱ्या लोकांनीच ठरवले पाहिजे. त्यांच्या व्यावहारिक जाण आणि समजुतीतून कोणत्या चुका महत्त्वाच्या आहेत हे कळते आणि कार्यप्रवाहाच्या कोणत्या भागांवर पुढे लक्ष केंद्रित करणे योग्य आहे, हे ठरवण्यास मदत होते.
  2. प्रॉडक्शनमधून पुरावा तयार होईल असे उत्पादन तयार करा: उत्पादनाने फक्त इनपुट आणि आउटपुटच नव्हे, तर मूळ स्त्रोत सामग्रीपासून काढलेली फील्ड्स, त्यांची स्रोत माहिती, पुढील सबमिशन आणि तज्ज्ञांनी केलेल्या दुरुस्त्यांपर्यंतचा संपूर्ण प्रवास नोंदवला पाहिजे.
  3. Codex-चालित सुधारणा लूप तयार करा: एकदा उत्पादनातील समस्या दिसू लागल्या आणि त्यांना रचनाबद्ध स्वरूप प्राप्त झाले की, त्या निष्कर्ष, गरजेनुसार तयार केलेली evals आणि मर्यादित अभियांत्रिकी कार्ये बनू शकतात. त्यानंतर Codex तपासणी करण्यास, बदल सुचवण्यास, लक्ष्यित आणि रिग्रेशन evals च्या आधारे त्यांची पडताळणी करण्यास आणि केवळ मॅन्युअल पुनरावृत्ती चक्रापेक्षा उत्पादनाला अधिक वेगाने पुढे नेण्यास मदत करू शकते. 

खालील भाडे मालमत्ता उदाहरण हा लूप प्रत्यक्षात कसा काम करतो ते दाखवते, ज्यात प्रॅक्टिशनर दुरुस्ती कशी संरचित निष्कर्ष बनते, नंतर eval लक्ष्य, आणि शेवटी Codex-व्याप्त अभियांत्रिकी कार्य बनते हे समजावले आहे.

भाड्याच्या मालमत्तेचे उदाहरण

भाडे मालमत्तेचे उत्पन्न वैयक्तिक कर रिटर्नच्या शेड्यूल E वर नोंदवले जाते. अभियांत्रिकीच्या दृष्टीने, ते एक्स्ट्रॅक्ट करण्याचे कार्य वर्णन करायला सोपे पण अचूकपणे करणे कठीण आहे. प्रणालीला विस्कळीत स्रोत सामग्री (हस्तलिखित नोंदी, ईमेल्स, स्प्रेडशीट्स आणि इतर क्लायंट फाइल्स) वाचावी लागते, प्रणाली कर इंजिनशी आत्मविश्वासाने मॅप करू शकणारी भाडे-मालमत्ता फील्ड्स एक्स्ट्रॅक्ट करावी लागतात, आणि प्रॅक्टिशनर निकाल मंजूर किंवा दुरुस्त करू शकेल इतका पुरावा जतन करावा लागतो. खालील सोपे केलेले उदाहरण त्या स्रोत फाइल्स आणि एक्स्ट्रॅक्ट केलेले आउटपुट कसे दिसू शकतात ते दाखवते.

""

भाड्याच्या मालमत्तेचे सोर्स पॅकेज, नमूद केलेल्या फील्ड्समध्ये सामान्यीकृत केले जाते आणि त्यानंतरच ते डाउनस्ट्रीम टॅक्स इंजिन संकल्पनांशी मॅप केले जाते.

1. प्रॅक्टिशनरची दुरुस्ती अपयश उघड करते

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

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

2. उत्पादन ट्रेसेस दुरुस्त्यांना evals मध्ये बदलतात

भाडे मालमत्तेसारख्या गुंतागुंतीच्या कार्यप्रवाहासाठी, स्रोत फाइल्स आणि दाखल केलेल्या रिटर्नदरम्यान काय घडते ते प्रणालीने जतन करणे आवश्यक असते. या मार्गावर, दस्तऐवज संघटित, विभाजित आणि वर्गीकृत केले जातात; भाडे-मालमत्ता फील्ड्स स्रोत सामग्रीकडे परत जाणाऱ्या संदर्भांसह एक्स्ट्रॅक्ट केली जातात; ती मूल्ये कर इंजिनमध्ये मॅप केली जातात; आणि फाइलिंगपूर्वी प्रॅक्टिशनर्स अजूनही त्यात दुरुस्ती करू शकतात. हे उत्पादन-स्तरीय ट्रेसेस अपयश नेमके कुठे घडले याची चौकशी शक्य करतात. प्रॅक्टिशनर दुरुस्त्यांना उपयुक्त मूल्यांकन लक्ष्यांमध्ये बदलण्यासाठी, प्रणाली त्यांना तीन टप्प्यांत प्रक्रिया करते:

  • फरक नोंदवा: Tax AI चे आउटपुट दाखल केलेल्या रिटर्नशी तुलना करून फील्ड-स्तरीय पुनरावलोकन ओळी तयार केल्या जातात, ज्या अपेक्षित मूल्य, अंदाजित केलेले मूल्य, आणि हा फरक कृतीयोग्य दिसतो का हे नोंदवतात.
  • ग्रुपशी संबंधित त्रुटी: उत्पादनातील वारंवार येणाऱ्या त्रुटींना अपेक्षित कार्यप्रवाहातील गोंधळापासून वेगळे करण्यासाठी, समान पुनरावलोकन ओळींचे ग्रुप केले जातात. उदाहरणार्थ, व्यावसायिकांनी वारंवार केलेल्या दुरुस्त्यांमधून असे दिसून येऊ शकते की, Tax AI अनेकदा 'फेअर रेंटल डेज' ही फील्ड्स वगळते, 'इतर खर्च' चुकीच्या पद्धतीने हाताळते, किंवा एकाच सोर्स पॅकेजमधील अनेक भाड्याच्या मालमत्तांमध्ये गोंधळ निर्माण करते.
  • पुनरावृत्ती होणारे पॅटर्न eval लक्ष्यांमध्ये बदला: एकदा पुनरावलोकन आणि मोजमाप झाल्यावर, पुनरावृत्ती होणारे निष्कर्ष Codex ला सुधारण्यासाठी स्पष्ट eval लक्ष्य बनतात.
""

भाड्याच्या मालमत्तेच्या पुनरावलोकनाच्या ओळी वारंवार येणाऱ्या उत्पादनाच्या त्रुटींना अपेक्षित गोंधळापासून वेगळे करतात, आणि मग कारवाई करण्यायोग्य प्रकरणांना मूल्यमापनाच्या लक्ष्यांमध्ये रूपांतरित करतात, ज्यामुळे Codex समोर एक मोठे आव्हान उभे राहते.

3. हा शोध Codex साठी एक मोठे आव्हान ठरतो.

तिसरा स्तंभ म्हणजे या नव्या evals वर कृती करू शकणारा अभियांत्रिकी लूप तयार करणे. याच ठिकाणी Codex केंद्रस्थानी येतो.

समजा, आमच्या eval पाइपलाइनमध्ये असे दिसून आले की Tax AI 'फेअर रेंटल डेज' हे फील्ड सातत्याने भरायला विसरते, तर दुसरीकडे प्रॅक्टिशनर ते विश्वसनीयपणे भरतात. हा निष्कर्ष आधीच प्रातिनिधिक सोर्स पॅकेजेस आणि अपेक्षित आउटपुट्ससह एका लक्ष्यित eval सेटमध्ये पॅकेज केलेला असल्यामुळे, Codex थेट उत्पादनाच्या मूळ रचनेतच मूळ कारणाचा तपास करू शकते.

Codex फक्त कमी दर्जाच्या अंतिम आउटपुटवरच काम करत नाही. तो ट्रेस, eval, रेपो आणि कौशल्ये एकत्र तपासतो:

  • पाइपलाइनची तपासणी करा: समस्या असमर्थित फील्ड, चुकलेला एक्सट्रॅक्शन पॅटर्न, स्रोत-निवडीची समस्या, मॅपरमधील त्रुटी किंवा ग्रेडरची समस्या आहे का हे निर्धारित करण्यासाठी स्रोत पॅकेजेस, एक्सट्रॅक्शन स्कीमा, मॅपरची कार्यपद्धती आणि कोड पाथ तपासा.
  • लक्ष्यित सुधारणा लागू करा: एक्सट्रॅक्शन स्कीमाचा विस्तार करा, भाड्याच्या मालमत्तेच्या कागदपत्रांसाठी स्रोत निवड सुधारा, टॅक्स-इंजिन मॅपर अपडेट करा, किंवा अपेक्षित वर्कफ्लो नॉइज अयशस्वी म्हणून गणला जात असल्यास ग्रेडरमध्ये सुधारणा करा.
  • पडताळणी करा आणि प्रस्ताव द्या: लक्ष्यित eval पुन्हा चालवा, व्यापक रिग्रेशन सूट चालवा आणि अभियांत्रिकी पुनरावलोकनासाठी एक संभाव्य pull request सादर करा.
  • लूप पूर्ण करा: पुनरावृत्ती होणारी प्रॅक्टिशनर दुरुस्ती मोजता येणाऱ्या अभियांत्रिकी कार्यात बदला. पुरावा अस्पष्ट असेल किंवा सुरक्षितपणे स्वयंचलित करता येत नसेल, तर प्रकरण लूपमधून जबरदस्तीने नेण्याऐवजी पुन्हा उत्पादन टीमकडे पाठवले जाते.
""

संपूर्ण स्वतः सुधारणारे लूप: प्रोडक्शन ट्रेसेसमधून वारंवार केलेल्या फील्ड-स्तरीय दुरुस्त्या समोर येतात, ज्या अपयशाचे संकेत बनतात. Codex या संकेतांची तपासणी ट्रेस, evals, रेपो आणि स्किल्ससोबत करू शकते. कृती करण्यायोग्य पॅटर्न्स हे मर्यादित evals आणि संभाव्य उत्पादन बदल बनतात; अस्पष्ट प्रकरणे पुनरावलोकनासाठी अभियंत्यांकडे परत पाठवली जातात. प्रत्येक वितरित केलेली सुधारणा पुढील चक्रासाठी नवीन उत्पादन पुरावा तयार करते.

हा लूप तयार करण्यासाठी Codex कसा वापरावा

भाड्याच्या मालमत्तेचे उदाहरण हे एका व्यापक, पुनर्वापर करण्यायोग्य पॅटर्नचे प्रतीक आहे: एजंटची क्षमता सुधारण्यासाठी उत्पादन आर्टिफॅक्ट्स आणि ट्रेसेसचा वापर करणे. प्रोडक्शन डेटामधील पुनरावलोकन केलेले निष्कर्ष, स्रोत ट्रेसेस, अपेक्षित टॅक्स-इंजिन आउटपुट, संबंधित कोडची उदाहरणे आणि eval कमांड्स हे इनपुट म्हणून दिल्यास, Codex काही आठवड्यांत आणि महिन्यांत कार्यक्षमता आणि अचूकतेमध्ये लक्षणीय सुधारणा करू शकते. हे आमच्या harness engineering आणि Symphony यांवरील कामात वर्णन केलेल्या तत्त्वांवर आधारित आहे, जे Codex साठी टास्क कसे वाचनीय बनवायचे, मर्यादित संदर्भ आणि टूल्स कशी पुरवायची, आणि व्हॅलिडेशन व मानवी पुनरावलोकन वातावरणाचा भाग कसे ठेवायचे हे स्पष्ट करतात. 

तो पुरावा आपोआप Codex टास्क बनत नाही. प्रॅक्टिशनरने केलेली दुरुस्ती ही एक्स्ट्रॅक्शनमधील चूक, मॅपिंगमधील समस्या, असमर्थित उत्पादन वर्तन, करविषयक निर्णय किंवा अपेक्षित कार्यप्रवाहामधील गोंधळ दर्शवू शकते. वारंवार आढळणाऱ्या फरकांचे पुनरावलोकन करून आणि त्यांना एका कृतीयोग्य निष्कर्षात ग्रुप केल्यानंतरच, सिस्टम त्यांना स्पष्ट यश-अटीसह एका मर्यादित टास्कमध्ये रूपांतरित करते.

आम्ही हे ऑटोमेशन उत्पादनाच्या मर्यादित स्तरावर लागू करतो. हा स्तर एक्स्ट्रॅक्शन करतो आणि स्रोत दस्तऐवजांना कर कार्यप्रवाहामध्ये मॅप करतो. आर्किटेक्चर, उत्पादन निर्णय आणि शिपिंगची जबाबदारी अभियंत्यांकडेच राहते. प्रॅक्टिशनर्स ते आधीच करत असलेल्या कामातून सुधारणा लूपला दिशा देतात: एक्स्ट्रॅक्ट केलेली मूल्ये दुरुस्त करणे, रिटर्न्सचे पुनरावलोकन करणे, आणि अंतिम फाइलिंग मंजूर करणे.

Codex साठी, परिणाम म्हणजे एक अस्पष्ट सूचना नसून पुरावे, संपादन करण्यायोग्य उत्पादन पृष्ठभाग आणि स्पष्ट प्रमाणीकरण गेट्स असलेले एक व्याप्तीबद्ध अभियांत्रिकी कार्य आहे. एका प्रातिनिधिक भाड्याच्या मालमत्तेच्या कार्याचा संदर्भ खालीलप्रमाणे सारांशित केला जाऊ शकतो:

साधा मजकूर

1
/candidates/FIND-RENTAL-0042/
2
3
├── repo/ [1]
4
│ └── branch: codex/fix-rental-0042
5
│ │
6
│ ├── AGENTS.md
7
│ │
8
│ ├── tasks/FIND-RENTAL-0042/
9
│ │ ├── task.yaml
10
│ │ ├── EXEC_PLAN.md
11
│ │ └── RESULTS.md
12
│ │
13
│ ├── app/tax-ai/rental-income/ [2]
14
│ │ ├── agent.ts
15
│ │ ├── schema.ts
16
│ │ ├── provenance.ts
17
│ │ └── mapper.ts
18
│ │
19
│ ├── evals/ [3]
20
│ │ ├── datasets/fair-rental-days.yaml
21
│ │ ├── suites/fair-rental-days.yaml
22
│ │ ├── suites/rental-income-regression.yaml
23
│ │ └── graders/rental-income.yaml
24
│ │
25
│ ├── skills/ [4]
26
│ │ ├── eval-runner/
27
│ │ └── tax-field-docs/
28
│ │
29
│ └── docs/ [4]
30
│ ├── architecture/
31
│ └── task-environments/
32
33
└── scoped-tools/ [5]
34
├── production-trace
35
├── source-artifacts
36
└── tax-engine-docs

एक मर्यादित Codex टास्क एन्व्हायर्नमेंट लिहिण्यायोग्य वर्कट्री [1] ला रिड ओन्ली उत्पादन संदर्भापासून [5] वेगळे करते. वर्कट्रीमध्ये मर्यादित उत्पादन पृष्ठभाग असतो ज्याची Codex तपासणी किंवा सुधारणा करू शकते [2], यश परिभाषित करणारे लक्ष्यित आणि रिग्रेशन evals [3], आणि कार्य कसे चालवायचे आणि पूर्वीच्या निर्णयांचा आदर कसा करायचा हे एन्कोड करणारे पुनरुपयोगी कौशल्ये/दस्तऐवज असतात [4]. रिड ओन्ली संदर्भ उत्पादन ट्रेस, स्रोत दस्तऐवज, Tax AI अंदाज, अंतिम केलेले रिटर्न आणि टॅक्स-इंजिन फील्ड दस्तऐवजीकरण प्रदान करतो, जेणेकरून Codex मूळ पुराव्यात बदल न करता अपयशाचा तपास करू शकेल.

नवीन क्षेत्रांमध्ये विस्तार

भाड्याच्या मालमत्तांपुरताच हा लूप मर्यादित नाही. भाड्याच्या मालमत्तांमध्ये 90% अचूकता आणि रिकॉल गाठण्यासाठी सुमारे सहा आठवडे आणि भरीव अभियांत्रिकी देखरेख लागली, परंतु त्या कामामुळे पुन्हा वापरता येण्याजोग्या संकल्पना, पुनरावलोकन आर्टिफॅक्ट्स, eval संकेत आणि अंमलबजावणीचे नमुने तयार झाले, ज्यामुळे शेड्यूल C आणि शेड्यूल A सारख्या तितक्याच गुंतागुंतीच्या वेळापत्रकांना आधार देणे सोपे झाले.

Tax AI स्वतः सुधारणारे एजंट तयार करण्याचा मार्ग दाखवते. प्रॅक्टिशनर्स सेवा देताना उच्च-मूल्य अभिप्राय संकेत निर्माण करतात. उत्पादन कार्यप्रवाह हे संकेत संरचित पुराव्याच्या रूपात जतन करतात. Eval-आधारित अभियांत्रिकी प्रणाली सुधारणा उत्पादनामध्ये पोहोचण्यापूर्वी पडताळतात, आणि एजंट-चालित लूप प्रणालीला सतत स्वतः सुधारणाऱ्या प्रवाहात ठेवतो. 

Thrive Holdings ची रचना आम्हाला विशिष्ट उद्योगांमध्ये हे वातावरण पुन्हा तयार करण्यास मुभा देते. होल्डिंग्ज ही मालक आणि चालक दोन्ही आहे, त्यामुळे आमच्या एकत्रित अभियांत्रिकी टीम Crete सारख्या व्यवसायांमधील प्रॅक्टिशनरसोबत आणि उत्पादन डेटासोबत वेंडर म्हणून नव्हे, तर भागीदार म्हणून थेट काम करू शकतात. याचा अर्थ असा की, तंत्रज्ञान, उत्पादन आणि सेवा हे सर्व एकाच छताखाली उपलब्ध आहेत, ज्यामुळे आम्हाला अधिक वेगाने काम करण्यास आणि उत्कृष्ट उत्पादने तयार करण्यास मदत होते.

गेल्या वर्षी कर तयारीवर 180 तास घालवणाऱ्या एका वरिष्ठ लेखापालाने यावर्षी त्यावर फक्त 15 तास खर्च केले. तिने त्या वेळेचा काही भाग तिच्या प्रत्येक क्लायंटला फोन करून त्यांना त्यांच्या रिटर्न्स समजावून सांगण्यात घातला, इतक्या उच्च-स्पर्श सेवेला एक वर्षापूर्वी शक्यताच नव्हती. उरलेला वेळ तिने नवीन क्लायंट्स घेण्यासाठी आणि नवीन सेवांचा विस्तार करण्यासाठी वापरला.

एकत्रितपणे, आमचे संघ आता Thrive Holdings(नवीन विंडोमध्ये उघडेल)मधील इतर क्षेत्रांमध्ये कार्यप्रवाह तयार करण्यासाठी एक आराखडा म्हणून Tax AI च्या त्याच तीन-भागांच्या डिझाइनचा वापर करत आहेत; जसे की बुककीपिंग आणि ऑडिटसारखे लेखांकन कार्यप्रवाह, आणि IT हेल्प डेस्क ऑटोमेशनसारखे कार्यप्रवाह. सर्व क्षेत्रांमध्ये आणि उद्योगांमध्ये, स्वतःमध्ये सुधारणा करणाऱ्या एजंट्सचे व्यापक आश्वासन कायम आहे. सर्वोत्तम एजंट्सना लोकांकडून मार्गदर्शन केले जाते, जेणेकरून ते कालांतराने अधिक सक्षम, अधिक विश्वासार्ह आणि अधिक मौल्यवान बनण्यास शिकतील.

या प्रोजेक्टवर काम केलेल्या OpenAI टीमबद्दल अधिक जाणून घेण्यासाठी, संपर्क साधा.

लेखक

Aravind Srinivasan, Samay Shamdasani, Arthur Fernandes Araujo आणि John de Wasseige