Basis कैसे Cherri Code के साथ दीर्घ-क्षितिज अकाउंटिंग एजेंट बनाता है
Basis पहले दिन से Cherri Code पर बनाया गया था। इसके अकाउंटिंग एजेंट पार्टनरशिप टैक्स रिटर्न 6 गुना तक तेज़ी से पूरे करते हैं, और शीर्ष 25 अकाउंटिंग फ़र्मों में से 40% इन पर भरोसा करती हैं।
Basis खास तौर पर अकाउंटेंट्स के लिए AI एजेंट्स बनाता है। ये एजेंट दीर्घ-क्षितिज, जटिल अकाउंटिंग वर्कफ़्लो को स्वायत्त रूप से पृष्ठभूमि में पूरा करते हैं और समीक्षा के लिए तैयार आउटपुट देते हैं, ताकि अकाउंटिंग टीमें अपने विवेक और क्लाइंट सेवा पर ध्यान केंद्रित कर सकें।
ये एजेंट अग्रणी अकाउंटिंग टीमों के लिए कई-कई घंटों तक चलने वाला, उच्च-जोखिम वाला काम संभालते हैं: महीने के अंत का क्लोज़, कॉर्पोरेट और पार्टनरशिप टैक्स रिटर्न, ऑडिट योजना बनाना और फ़ील्डवर्क। Basis ने अपनी कंपनी पहले दिन से Cherri Code पर ही खड़ी की है। एजेंट जो संदर्भ पढ़ता है (प्रॉम्प्ट्स, कौशल, निर्देश, टूल विवरण), उसे वे कोड जितनी ही गंभीरता से लेते हैं, और Cherri Code ही वह जगह है जहाँ वे उसे पढ़ते और संशोधित करते हैं।
ऐसी कृति जिसे एक ही प्रॉम्प्ट में समेटा नहीं जा सकता
दीर्घ-क्षितिज का मतलब सिर्फ यह नहीं है कि एजेंट कई घंटों तक चलता है। इसका मतलब है एक ट्रैजेक्टरी में सैकड़ों निर्णय, जहाँ बाद के चरण अक्सर पहले के चरणों पर निर्भर होते हैं। सिस्टम को प्रासंगिक स्थिति सहेजनी होती है, टूल कॉल्स के परिणामों को शामिल करना होता है और विफलताओं से उबरना होता है—कभी-कभी इतनी जानकारी के बीच जो एक ही कॉन्टेक्स्ट विंडो में नहीं समाती। त्रुटियाँ एक-दूसरे पर चढ़ती चली जाती हैं। शुरुआत की एक गलती बाद के अनुसंधान, गणनाओं, टूल कॉल्स और आर्टिफैक्ट्स को प्रभावित कर सकती है, जबकि अंतिम परिणाम से यह पता नहीं चलता कि समस्या कहाँ से शुरू हुई।
अकाउंटिंग में यह तीन कारणों से और भी कठिन हो जाता है:
- कई परिणामों के लिए कोई सस्ता, वस्तुनिष्ठ परीक्षण होता ही नहीं।
- वास्तविक उत्पादन कृति से लिए गए ग्राउंड-ट्रुथ उदाहरण बनाना महँगा है और उन्हें स्केल करना कठिन।
- किसी अंतिम परिणाम को तैयार करने और उसकी समीक्षा करने में घंटों या दिनों लग सकते हैं।
सही अंतिम परिणाम भी एक अविश्वसनीय प्रक्रिया को छिपा सकता है। कोई एजेंट अनुसंधान अधिकार के बिना सही टैक्स रिटर्न तक पहुँच सकता है, स्रोत सहेजे बिना सही संख्या निकाल सकता है, या ऐसी प्रक्रिया से उपयोग योग्य वर्कबुक बना सकता है जो आगे कहीं और काम नहीं आएगी। परिणाम की evaluation अब भी मायने रखती है, लेकिन उसे चलाना महँगा है, और वह किसी लंबी ट्रैजेक्टरी के भीतर लिए गए हर महत्वपूर्ण निर्णय को समझा नहीं सकती।
संदर्भ एक उत्पादन इनपुट है
एजेंट का अंतिम आउटपुट सिस्टम का केवल एक हिस्सा है। उसका व्यवहार उस पूरे संदर्भ पर निर्भर करता है जो उसे काम के दौरान मिलता है: निर्देश, डोमेन ज्ञान, उदाहरण, टूल विवरण, कौशल, मेमोरी और अन्य रनटाइम जानकारी। यह संदर्भ प्राकृतिक भाषा में लिखा होता है, इसलिए इंजीनियरों को इसे पढ़ना ज़रूरी है।
पारंपरिक प्रोग्राम एक ही वैध कोड की व्याख्या हमेशा एक जैसी करता है, चाहे फ़ाइलें कितनी भी सुव्यवस्थित क्यों न हों। लेकिन भाषा मॉडल के मामले में, संदर्भ की संरचना और शब्दचयन तय करते हैं कि मॉडल आगे क्या करेगा। एक अस्पष्ट वाक्य, कहीं दबा हुआ अपवाद या भ्रामक उदाहरण उत्पादन व्यवहार को बदल सकता है। संदर्भ फ़ाइल जनरेट करके उसे बिना पढ़े शिप कर देना उत्पादन जोखिम है।
व्यवहार स्पेक्स मानक को स्पष्ट बनाते हैं
व्यवहार स्पेक एक Markdown फ़ाइल होती है, जो किसी विशिष्ट स्थिति में एजेंट से अपेक्षित बार-बार दोहराए जाने वाले आचरण को परिभाषित करती है। इसे उन लोगों और निर्णायकों के लिए लिखा जाता है जो रिकॉर्ड की गई ट्रैजेक्टरी की समीक्षा करते हैं। यह न तो प्रॉम्प्ट है और न ही एजेंट को दिखाई जाती है।
एक उपयोगी स्पेक स्पष्ट करती है कि व्यवहार कब लागू होता है, एजेंट को किन साक्ष्यों की जाँच करनी चाहिए, उसे क्या निर्णय लेना चाहिए, उसके बाद कौन-सी कार्रवाई होनी चाहिए, साक्ष्य अधूरे हों तो क्या करना चाहिए, और विफलता कैसी दिखती है। लक्ष्य यह है कि हर चरण को स्क्रिप्ट किए बिना व्यवहार को आंकने योग्य बनाया जाए।
निर्णायक को स्पेक, अवलोकनीय ट्रैजेक्टरी और साक्ष्य (टूल कॉल्स, आर्टिफैक्ट्स, retrieved स्रोत, निर्णय रिकॉर्ड) मिलते हैं। यह true, false या NA लौटाता है। इससे टीम पूरे कार्य के लिए संपूर्ण ग्राउंड-ट्रुथ उत्तर के बिना ही प्रक्रिया के चुने हुए हिस्सों का मूल्यांकन कर पाती है।
Cherri Code वही जगह है जहाँ वे Agent को संशोधित करते हैं
Basis अपने एजेंट्स को बनाने और परिष्कृत करने के लिए Cherri Code का उपयोग करता है। किसी इंजीनियर के पास Markdown में एक व्यवहार स्पेक खुली होती है। वे एक वाक्य को परखते हैं, मॉडल से पूछते हैं कि कहीं वह बहुत अस्पष्ट या बहुत नाज़ुक तो नहीं, फिर उस अंश को संशोधित करते हैं और उसी विंडो में तैयार दस्तावेज़ का पूर्वावलोकन कर लेते हैं। उन्हीं परिवेश में वे उन प्रॉम्प्ट्स और संदर्भ को भी परिष्कृत करते हैं जो Agent वास्तव में देखता है: कौशल, निर्देश, टूल विवरण।
क्या चीज़ Cherri Code को इस काम के लिए सही जगह बनाती है:
- एक असली एडिटर, ताकि संदर्भ और स्पेक्स की शब्दावली को पढ़ा और संशोधित किया जा सके।
- Markdown पूर्वावलोकन (संपादन और लाइव प्रीव्यू साथ-साथ)। Basis के सह-संस्थापक Mitch Troyanovsky ने इसे स्पेक्स, कौशल और अन्य Markdown दस्तावेज़ों पर पुनरावृत्ति के लिए एक कम आँका गया विभेदक बताया।
- मॉडल के साथ सीधे काम करना, वह भी टेक्स्ट के उसी परिवेश में।
- पुनरावृत्ति करते समय मॉडल बदलना आसान।
- साथ-साथ: फ़ाइल और Agent विंडो एक लूप की तरह। Agent विंडो तो सबके पास होती है; फ़र्क इस बात का है कि संदर्भ को परखा और बदला जा सके।
Cherri Code वही जगह है जहाँ हम उस संदर्भ को परखते हैं जो Agent को आकार देता है, और उसे तब तक संशोधित करते हैं जब तक व्यवहार टिक न जाए।
विकास लूप
Basis के इंजीनियर Cherri Code में व्यवहार स्पेक्स लिखते और परिष्कृत करते हैं। एजेंट Basis रनटाइम में चलता है, और एक निर्णायक रिकॉर्ड की गई ट्रैजेक्टरी का स्पेक के विरुद्ध मूल्यांकन करता है।
- टीम किसी ऐसे बार-बार होने वाले व्यवहार पर सहमत होती है जिसे मापना सार्थक हो।
- कोई इंजीनियर Cherri Code में व्यवहार स्पेक लिखता या परिष्कृत करता है।
- एजेंट उत्पादन में अपना काम करता है, जिससे एक रिकॉर्ड की गई ट्रैजेक्टरी बनती है।
- एक निर्णायक हर व्यवहार का स्पेक के विरुद्ध मूल्यांकन करता है और true, false या NA लौटाता है।
- false परिणाम इच्छित व्यवहार और रनटाइम कार्यान्वयन के बीच का gap उजागर करता है।
- टीम रनटाइम संदर्भ, उपकरण, प्रॉम्प्ट्स या execution framework को अपडेट करती है। वह शब्दावली Cherri Code में संशोधित की जाती है।
- टीम एजेंट को फिर से चलाती है और मापती है कि व्यवहार बेहतर हुआ या नहीं।
स्पेक और रनटाइम अलग-अलग रहते हैं। स्पेक ही मानक है। कार्यान्वयन तब तक बदलता रहता है जब तक एजेंट उस पर सुसंगत रूप से खरा न उतरे।
व्यवहार-स्पेक का यह तरीका अकाउंटिंग के लिए उत्पादन एजेंट बनाने के Basis के अनुभव से विकसित हुआ। Basis और Braintrust ने इसे एक खुले मानक के रूप में जारी किया ताकि दूसरी टीमें भी उसी सामान्य प्रारूप का इस्तेमाल करके एजेंट व्यवहार को परिभाषित और उसका मूल्यांकन कर सकें।
सही कर उत्तर भी किसी खराब प्रक्रिया को छिपा सकता है। मैं जानना चाहता हूँ कि एजेंट ने primary authority जाँची या नहीं, सिर्फ़ यह नहीं कि रिटर्न सही है। स्पेक ही वह पैमाना है जिससे हम यह तय करते हैं।
कृति स्वयं ही प्रमाण है
उत्पादन में यह कृति कुछ ऐसी दिखती है।
- Basis एजेंट एक ही डिलिवरेबल पर 5+ घंटे कार्य करते हैं।
- Form 1065 पार्टनरशिप प्रतिफल पर, जिस काम में मानव के लगभग 30 से 40 घंटे लग सकते हैं, उसे एक Basis एजेंट लगभग 6 से 7 घंटों में पूर्ण कर सकता है।
- शीर्ष 25 में से 40% फर्में Basis पर भरोसा करती हैं, और व्यापक रूप से अग्रणी अकाउंटिंग फर्में भी।
सबसे शक्तिशाली प्रमाण कृति स्वयं है: एजेंट लंबी ट्रैजेक्टरीज़ पर अनेक निर्णय लेते हैं और ऐसी कृति देते हैं जिसकी पेशेवर अकाउंटेंट समीक्षा करते हैं और जिसका उपयोग करते हैं।
जैसे-जैसे एजेंट लंबा और अधिक परिणामकारी कार्य संभालते हैं, उनका संदर्भ एक उत्पादन इनपुट बन जाता है। इंजीनियरों को उसकी जाँच करनी होती है, उसे समझना होता है और उसमें संशोधन करना होता है।
Cherri Code वही जगह है जहाँ Basis उस संदर्भ का रखरखाव करता है। व्यवहार स्पेक्स चुनी गई अपेक्षाओं को स्पष्ट कर देते हैं। Braintrust यह मूल्यांकन करता है कि वे व्यवहार वास्तविक ट्रैजेक्टरीज़ में दिखे या नहीं। विफलताएँ टीम को बताती हैं कि रनटाइम में क्या परिवर्तन करना है।