Codex के साथ स्व-सुधार करने वाले टैक्स एजेंट बनाना

कैसे Thrive Holdings और OpenAI ने प्रैक्टिशनर विशेषज्ञता को Codex-संचालित लूप के साथ जोड़कर Crete अकाउंटेंट्स के लिए Tax AI का सह-विकास किया

वास्तविक दुनिया की प्रणालियाँ प्रोडक्शन में लैब की तुलना में अलग तरह से व्यवहार करती हैं, और ऐसे तरीकों से टूटती हैं जिनका परिनियोजन से पहले अनुमान लगाना कठिन होता है. टीमें अक्सर इन विफलताओं को लॉन्च के बाद खोजती हैं, फिर edge cases की जाँच करने, prompts समायोजित करने, और प्रोडक्शन फ़ीडबैक को टिकाऊ प्रोडक्ट सुधारों में बदलने में हफ्ते बिताती हैं. फ़ीडबैक लूप मैनुअल और धीमा होता है, और तभी सुधरता है जब कोई इंजीनियर उसे आगे बढ़ाता है. लेकिन आज, सोच-समझकर डिज़ाइन किए गए eval infrastructure, प्रैक्टिशनरों और वास्तविक दुनिया के वातावरणों तक सीधी पहुँच, और Codex की अग्रणी एजेंटिक क्षमताओं के साथ, आप ऐसे एजेंट बना सकते हैं जो स्वयं-सुधार करें.

इस पोस्ट में, हम बताएँगे कि हमने इस प्रकार का एजेंट बनाने के लिए Codex का उपयोग कैसे किया. पिछले छह महीनों में, OpenAI के forward deployed engineers और researchers ने 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-2s और 1099s जैसे सरल काम संभाले. जैसे-जैसे सीज़न आगे बढ़ा, यह K-1s, schedules और अधिक कठिन edge cases वाले अधिक जटिल रिटर्न्स तक पहुँचा. हर नई क्षमता ने पिछले की तुलना में प्रति रिटर्न अधिक समय बचाया क्योंकि जिन कार्यों को उसने संभाला वे मैनुअल रूप से करने में अधिक कठिन और समय लेने वाले थे. हम आज भी लगातार प्रगति देख रहे हैं.

अब हम बताएँगे कि हमारी टीमों ने Tax AI को स्व-सुधार करने वाला बनाने के लिए तीन महत्वपूर्ण स्तंभों पर आधारित सह-इंजीनियरिंग कैसे की: 1) विशेषज्ञ प्रैक्टिशनर फ़ीडबैक, 2) प्रोडक्शन ट्रेसेज़ (इनपुट से अंतिम आउटपुट तक का संरचित इतिहास), और 3) निरंतर, तेज़ प्रोडक्ट विकास सक्षम करने के लिए अनुकूलित evals पर आधारित Codex-संचालित iteration loop. हमें उम्मीद है कि हमारा अनुभव उन अन्य निर्माताओं के लिए उपयोगी होगा जहाँ प्रैक्टिशनर विशेषज्ञता व्यापक सिस्टम और उसमें चलने वाले डेटा की गुणवत्ता को आकार देने की कुंजी है.

जब हम टैक्स तैयारी के कठिन हिस्सों (K-1s, रेंटल रियल एस्टेट schedules, और ऐसे टैक्स फ़ॉर्म जहाँ मानों को कई स्रोत फ़ाइलों में मिलान करना पड़ता था) में आगे बढ़े, तो यह स्पष्ट हो गया कि असली चुनौती यह थी कि क्या प्रोडक्ट जटिल प्रोडक्शन विफलताओं को दृश्य, समझने योग्य और क्रियाशील बना सकता है.

प्रोडक्ट के शुरुआती दिनों में, अधिकांश सुधार मैनुअल था. प्रैक्टिशनर सिस्टम त्रुटियों को सुधार सकते थे, लेकिन प्रोडक्ट पूरा संदर्भ कैप्चर नहीं करता था: फाइलिंग से पहले बदला गया मान वास्तविक निष्कर्षण चूक, मैपिंग समस्या, प्रोडक्ट समर्थन की कमी, या अपेक्षित वर्कफ़्लो शोर को दर्शा सकता था. इन मामलों को अलग करना अब भी इंजीनियरिंग टीम के फॉलो-अप की माँग करता था. इंजीनियर coding agents का उपयोग कर सकते थे, लेकिन सिस्टम अभी इस तरह डिज़ाइन नहीं था कि सुधार लूप के भीतर AI का सार्थक उपयोग कर सके. हमारे पास सही चढ़ाई चुनने का संकेत नहीं था.

इससे हमने सिस्टम को तीन स्तंभों के आसपास डिज़ाइन किया:

1. प्रैक्टिशनरों के करीब रहें: काम करने वाले लोगों को यह दिशा देनी चाहिए कि प्रोडक्ट क्या सीखे. उनकी अंतर्दृष्टि और समझ बताती है कि कौन-सी त्रुटियाँ महत्वपूर्ण हैं और यह तय करने में मदद करती है कि वर्कफ़्लो के किन हिस्सों पर अगला ध्यान देना उचित होगा.
2. प्रोडक्ट को इस तरह बनाएँ कि प्रोडक्शन साक्ष्य बनाए: प्रोडक्ट को केवल इनपुट और आउटपुट से अधिक कैप्चर करना होगा; उसे स्रोत सामग्री से निकाले गए फ़ील्ड्स और provenance, फिर डाउनस्ट्रीम सबमिशन और विशेषज्ञ सुधार तक का पूरा मार्ग कैप्चर करना होगा.
3. Codex-संचालित सुधार लूप बनाएँ: एक बार प्रोडक्शन समस्याएँ दृश्य और संरचित हो जाएँ, तो वे निष्कर्ष, अनुकूलित evals और सीमित इंजीनियरिंग कार्य बन सकती हैं. फिर Codex जाँच करने, बदलाव प्रस्तावित करने, उन्हें लक्षित और regression evals के विरुद्ध सत्यापित करने, और प्रोडक्ट को पूरी तरह मैनुअल iteration cycle की तुलना में तेज़ी से आगे बढ़ाने में मदद कर सकता है. 

नीचे दिया गया रेंटल प्रॉपर्टीज़ उदाहरण दिखाता है कि यह लूप व्यवहार में कैसे काम करता है, और आपको यह समझाता है कि प्रैक्टिशनर का सुधार कैसे एक संरचित निष्कर्ष, फिर eval लक्ष्य, और अंततः Codex-सीमित इंजीनियरिंग कार्य बनता है.

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

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

क्योंकि हम इन सुधारों को विस्तार से देख सकते थे, हमने समीक्षा प्रक्रिया को विफलता के बाद के अंतिम चरण से बदलकर एक सतत सीखने के चक्र में बदल दिया. हमने वर्कफ़्लो को इस तरह डिज़ाइन किया कि वह विशेषज्ञ कार्रवाइयों को संरचित डेटा के रूप में कैप्चर करे. अब, हर हस्तक्षेप प्रोडक्ट के सुधार लूप को यह दर्ज करके पोषित करता है कि Tax AI ने क्या प्रस्तावित किया, प्रैक्टिशनर ने क्या बदला, और अंततः दाखिल रिटर्न में क्या गया.

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

• अंतर को कैप्चर करें: Tax AI के आउटपुट की तुलना दाखिल रिटर्न से की जाती है ताकि फ़ील्ड-स्तरीय समीक्षा पंक्तियाँ बनें, जो अपेक्षित मान, अनुमानित मान, और क्या अंतर क्रियाशील दिखता है, इसे कैप्चर करती हैं.
• संबंधित विफलताओं को समूहित करें: समान समीक्षा पंक्तियों को समूहित किया जाता है ताकि बार-बार होने वाली प्रोडक्ट विफलताओं को अपेक्षित वर्कफ़्लो शोर से अलग किया जा सके. उदाहरण के लिए, बार-बार होने वाले प्रैक्टिशनर सुधार दिखा सकते हैं कि Tax AI अक्सर “fair rental days” फ़ील्ड्स को छोड़ देता है, “other expenses” को गलत संभालता है, या एक ही स्रोत पैकेज में कई रेंटल प्रॉपर्टीज़ को गड़बड़ा देता है.
• बार-बार दिखने वाले पैटर्न को eval लक्ष्यों में बदलें: समीक्षा और मापन के बाद, दोहराए गए निष्कर्ष Codex के सुधार के लिए स्पष्ट eval लक्ष्य बन जाते हैं.

तीसरा स्तंभ ऐसा इंजीनियरिंग लूप बनाना है जो इन नए evals पर कार्रवाई कर सके. यहीं Codex केंद्रीय बन जाता है.

मान लीजिए हमारी eval पाइपलाइन संकेत देती है कि Tax AI लगातार "fair rental days" फ़ील्ड को छोड़ देता है, जबकि प्रैक्टिशनर उसे भरोसेमंद रूप से भर देते हैं. क्योंकि इस निष्कर्ष को पहले ही प्रतिनिधि स्रोत पैकेजों और अपेक्षित आउटपुट के साथ एक लक्षित eval सेट में पैक किया जा चुका है, Codex प्रोडक्ट स्कैफ़ोल्ड के भीतर सीधे मूल कारण की जाँच कर सकता है.

Codex केवल एक कमज़ोर अंतिम आउटपुट के साथ काम नहीं कर रहा होता. यह trace, eval, repo और skills को साथ में देखता है:

• पाइपलाइन की जाँच करें: स्रोत पैकेजों, extraction schemas, mapper व्यवहार और code paths की जाँच करें ताकि यह तय किया जा सके कि समस्या असमर्थित फ़ील्ड, छूटा हुआ extraction pattern, source-selection समस्या, mapper gap, या grader issue है.
• लक्षित सुधार लागू करें: extraction schema का विस्तार करें, रेंटल-प्रॉपर्टी दस्तावेज़ों के लिए source selection बेहतर करें, tax-engine mapper अपडेट करें, या अगर अपेक्षित workflow noise को विफलता माना जा रहा है तो grader को परिष्कृत करें.
• सत्यापित करें और प्रस्ताव रखें: लक्षित eval फिर चलाएँ, व्यापक regression suites चलाएँ, और इंजीनियरिंग समीक्षा के लिए एक संभावित पुल रिक्वेस्ट प्रस्तुत करें.
• लूप बंद करें: बार-बार होने वाले प्रैक्टिशनर सुधार को एक मापनीय इंजीनियरिंग कार्य में बदलें. यदि साक्ष्य अस्पष्ट हो या सुरक्षित रूप से स्वचालित न किया जा सके, तो मामले को लूप से जबरन गुज़ारने के बजाय वापस प्रोडक्ट टीम के पास भेज दिया जाता है.

रेंटल प्रॉपर्टी का उदाहरण एक व्यापक पुन: प्रयोज्य पैटर्न का प्रतीक है: किसी एजेंट की क्षमताओं को बेहतर बनाने के लिए प्रोडक्शन आर्टिफैक्ट्स और ट्रेसेज़ का उपयोग करना. प्रोडक्शन डेटा से समीक्षा किए गए निष्कर्ष, स्रोत ट्रेसेज़, अपेक्षित tax-engine output, प्रासंगिक code examples और eval commands को इनपुट के एक सेट के रूप में देने पर, Codex हफ्तों और महीनों में प्रदर्शन और सटीकता में ठोस सुधार कर सकता है. यह harness engineering और Symphony पर हमारे काम में वर्णित सिद्धांतों पर आधारित है, जो बताते हैं कि कार्यों को Codex के लिए कैसे स्पष्ट बनाया जाए, सीमित संदर्भ और टूल्स कैसे दिए जाएँ, और सत्यापन व मानव समीक्षा को वातावरण का हिस्सा कैसे बनाए रखा जाए. 

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

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

Codex के लिए, परिणाम कोई अस्पष्ट अलर्ट नहीं बल्कि साक्ष्य, संपादन योग्य प्रोडक्ट सतहों और स्पष्ट सत्यापन गेट्स वाला एक सीमित इंजीनियरिंग कार्य है. एक प्रतिनिधि रेंटल प्रॉपर्टी कार्य के संदर्भ को इस प्रकार संक्षेपित किया जा सकता है:

यही लूप रेंटल प्रॉपर्टीज़ से आगे भी लागू होता है. रेंटल प्रॉपर्टीज़ को 90% precision और recall तक पहुँचने में लगभग छह सप्ताह और पर्याप्त इंजीनियरिंग निगरानी लगी, लेकिन उस काम ने पुन: प्रयोज्य abstractions, review artifacts, eval conventions और implementation patterns तैयार किए, जिनसे Schedule C और Schedule A जैसे समान रूप से जटिल schedules का समर्थन करना आसान हुआ.

Tax AI स्व-सुधार करने वाले एजेंट बनाने का एक रास्ता दिखाता है. प्रैक्टिशनर सेवा प्रदान करके उच्च-मूल्य प्रतिक्रिया संकेत उत्पन्न करते हैं. प्रोडक्ट वर्कफ़्लो उन संकेतों को संरचित साक्ष्य के रूप में संरक्षित रखते हैं. Eval-समर्थित इंजीनियरिंग सिस्टम सुधारों को प्रोडक्शन तक पहुँचने से पहले सत्यापित करते हैं, और एजेंट-संचालित लूप सिस्टम को सतत स्व-सुधार प्रवाह में बनाए रखता है. 

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

एक वरिष्ठ अकाउंटेंट, जिसने पिछले साल टैक्स तैयारी पर 180 घंटे लगाए थे, ने इस साल उस पर केवल 15 घंटे लगाए. उसने उस समय का एक हिस्सा अपने हर क्लाइंट को फ़ोन करने और उनके रिटर्न्स को उनके साथ समझाने में लगाया, इतनी उच्च-स्पर्श सेवा का स्तर जो एक साल पहले संभव नहीं था. बाकी समय का उपयोग उसने नए क्लाइंट लेने और नई सेवा पेशकशों तक विस्तार करने में किया.

अब हमारी टीमें Tax AI के इसी तीन-भागीय डिज़ाइन को Thrive Holdings⁠(एक नई विंडो में खुलेगा) में अन्य डोमेनों के वर्कफ़्लो बनाने के ब्लूप्रिंट के रूप में उपयोग कर रही हैं; जैसे बहीखाता और ऑडिट जैसे अकाउंटिंग वर्कफ़्लो, और IT help desk automation जैसे परिचालन वर्कफ़्लो. डोमेनों और उद्योगों में, स्व-सुधार करने वाले एजेंटों का व्यापक वादा कायम है. सबसे अच्छे एजेंट लोगों द्वारा निर्देशित होते हैं ताकि वे समय के साथ अधिक सक्षम, अधिक विश्वसनीय और अधिक मूल्यवान बनना सीखें.

इस प्रोजेक्ट पर काम करने वाली OpenAI टीम के बारे में अधिक जानने के लिए, संपर्क करें.