आजकल coding agents अपनी कमियों की भरपाई करने में मदद कर सकते हैं, इसलिए अगर आप अपनी ताकतों को स्पष्ट रूप से समझकर उनका सही इस्तेमाल कर सकें, तो मुझे लगता है कि entry barrier कम हो सकता है।
मेरे लिए भी documentation हमेशा एक समस्या रही है, लेकिन जब मैंने उसका कुछ हिस्सा coding agent को सौंप दिया, तो बोझ कम हुआ। और उस documented सामग्री की समीक्षा करते-करते लगता है कि documentation को लेकर मेरी समझ भी विकसित हो रही है।
पढ़ने के लिए धन्यवाद! पहले दस्तावेज़, test cases, validation वगैरह जैसी कई चीज़ें थीं जिन पर लोगों को सीधे ध्यान देना पड़ता था, लेकिन अब काफ़ी बड़े हिस्से AI coding agents के साथ किए जा सकते हैं, इसलिए लगता है कि open source को maintain करने की कठिनाई भी पहले की तुलना में काफ़ी कम हो गई है!
हाँ, अगर सिर्फ clipboard history के हिसाब से देखें तो काफी overlap है। लेकिन Raycast में clipboard के अलावा भी बहुत सारे features हैं, इसलिए मुझे वह थोड़ा ज़्यादा भारी लगा।
मैंने जिन चीज़ों पर ध्यान दिया, वे ये हैं।
सबसे पहले, इसे हल्का रखा है और यह सिर्फ clipboard history को ही manage करता है; अभी इसका size करीब 2MB है।
और saved content को detail view में edit करके वापस रख सकते हैं। कई prompts को review करते समय और पहले से थोड़ा-थोड़ा tweak करते समय यह सुविधाजनक लगा।
Search और folders पर भी ध्यान दिया है। काम करते समय ज़रूरी जानकारी—जो one-time हो या जिसे फिर से ढूँढना झंझट लगे—उसकी समस्या हल करने की कोशिश की है।
Body, tags, title आदि से search करने योग्य बनाया है।
आगे चलकर मैं plugins के जरिए features या layouts को सीधे जोड़ने की सुविधा देना चाहता हूँ, लेकिन यह अभी पूरी तरह concretize नहीं हुआ है।
मुझे Raycast भी एक अच्छा app लगता है, और मैं कोशिश करना चाहता हूँ कि यह personal preference के हिसाब से एक विकल्प बन सके।
ऐसे tools में सबसे मुश्किल काम बनाना नहीं, बल्कि हटाना होता है, इसलिए garden को अलग lifecycle में बाँटना खास तौर पर ध्यान खींचता है.
एजेंट को दिया जाने वाला context पुराना हो जाए तो वह सिर्फ बेकार नहीं होता, बल्कि नुकसानदेह भी हो जाता है. इंसान दस्तावेज़ देखकर अंदाज़ा लगा लेता है कि "यह शायद पुरानी बात है", लेकिन मॉडल के पास वह समझ नहीं होती, इसलिए 3 महीने पहले सही रही किसी invariant condition को वह आज भी वैसा ही सही मानकर इस्तेमाल कर लेता है. कोड हो तो कम-से-कम compile टूट जाता है, लेकिन wiki चुपचाप गलत होती रहती है.
इसीलिए मुझे यह जानने की उत्सुकता है कि क्या पेज पर यह जुड़ता है कि वह किस समय को आधार मानकर लिखा गया है, और किस आधार पर लिखा गया है. इसे Markdown में repository में रखकर Git में review कराने का फैसला मुझे उस लिहाज़ से सही लगता है, लेकिन diff में यह दर्ज होता है कि दस्तावेज़ कब बदला, यह नहीं कि उसकी सामग्री कब तक वैध रही.
1,700 एंट्री के स्तर पर performance की बात practically मायने नहीं रखती; frontend पर सीधे process करें या backend रखें, दोनों ही तुरंत चलेंगे। इसलिए मेरा मानना है कि निर्णय का आधार speed नहीं, बल्कि यह होना चाहिए कि मौजूदा Python logic को दोबारा लिखना है या नहीं।
उस आधार पर Streamlit सबसे उपयुक्त लगता है। matching logic को वैसे ही import करके इस्तेमाल कर सकते हैं, और UI में 5 selectbox व एक result table हो तो काम पूरा हो जाता है, इसलिए frontend code लिखने की ज़रूरत नहीं पड़ती। इसे Streamlit Community Cloud पर deploy करें तो share करने लायक link भी मुफ्त में मिल जाता है, और अगर JSON को runtime पर read करने के लिए रखें तो सिर्फ file बदलने से ही नया data reflect हो जाएगा।
Static HTML का deployment ज़्यादा आसान है, लेकिन उसके बदले Python logic को JS में ले जाना पड़ेगा। अगर score calculation थोड़ा भी complex हुआ, तो वही porting कई दिन खा जाएगी। अगर लक्ष्य इस हफ्ते के भीतर working demo दिखाना है, तो मुझे लगता है वह risk न लेना ही बेहतर है।
एक बात और, Streamlit आखिरकार product से ज़्यादा एक tool जैसा दिखता है। अगर यह internal decision-makers के लिए demo है और उद्देश्य सिर्फ यह verify करना है कि "input देने पर सच में result आता है", तो कोई दिक्कत नहीं; लेकिन अगर यह external customer demo है, तो इस बात को ध्यान में रखना होगा.
ओह... Show GN पोस्ट्स में मैं हमेशा सिर्फ़ 'कुछ बनाया' से आगे बढ़कर ऐसे insights भी साथ में देखना चाहता था, इसलिए ऐसी पोस्ट देखकर काफ़ी उत्साहित हूँ haha
हर मामले के लिए अलग-अलग expert ढूँढकर सिर्फ़ उनके scope का काम सौंपने के बजाय, लोगों की psychology यही होती है कि एक ही व्यक्ति को दे दें और वह अपने-आप सब कुछ अच्छे से संभाल ले।
LLM में भी reward function शायद ऐसा ही बनाया जाएगा कि आप कुछ भी फेंक दें, वह सब स्वीकार कर ले, है ना?
भले ही यह एक सार्वजनिक benchmark हो, इतने specific numbers मैंने पहली बार देखे हैं। धन्यवाद।
159 cases / 76 cases / 3,197 cases का ratio खास तौर पर ध्यान खींचता है। यह तथ्य कि फैसला न हो सकने वाले cases (ID नहीं) भारी संख्या में हैं — आखिरकार इसका मतलब है कि ज़्यादातर duplicates ऐसे हिस्से में हैं जहाँ tracking खुद संभव नहीं है, और इससे फिर पुष्टि हुई कि सिर्फ “audit logs हैं तो ठीक है” सोचकर निश्चिंत नहीं होना चाहिए।
creation (POST) को प्राथमिकता देने की दिशा हमारे design से बिल्कुल मेल खाती है। हमारे hash chain में idempotency key को creation event से पहले जोड़ने की कोशिश का कारण ठीक यही था।
email message ID वाला सुझाव मैं तुरंत लागू करूँगा। internal tool spec में सिर्फ “response में entity ID अनिवार्य” जोड़ देने से audit log की verifiability बदल जाती है। और अगर hash chain में ID को anchor की तरह इस्तेमाल करें, तो duplicate है या नहीं यह calculation से ही verify किया जा सकता है।
क्या आपको पता चल पाया कि 3,197 “ID नहीं” वाले cases किन tool types में ज़्यादा clustered थे? email के अलावा, केवल “success/failure” लौटाने वाले tools कितने हैं, यह जानना चाहूँगा।
मुझे भी ऐसा कुछ बनाने वाले किसी व्यक्ति से मिलकर काफ़ी अच्छा लगा!
मैंने भी बड़े Claude युग के आने से पहले Rust में API भी बनाए, CLI भी बनाए, और इस तरह Rust में काफ़ी समय लगाया था!
मैंने भी काफ़ी हाल में सोचना शुरू किया कि tmux को बदलना चाहिए, इसलिए tmux को पूरी तरह बदले हुए ज़्यादा समय नहीं हुआ है, लेकिन मैंने अपना multiplexer भी बनाया और दूसरे ही दिन से tmux का इस्तेमाल न्यूनतम कर दिया था!
यहाँ सिर्फ़ पूर्णता का मुद्दा नहीं था, बल्कि मुझे लगता है कि अगर मेरे बनाए टूल के बजाय किसी दूसरे टूल पर fallback मौजूद हो, तो वही एक तरह का बच निकलने का रास्ता बन जाता है और शायद इसी वजह से मैं विकास पर उतनी मेहनत नहीं करता था।
और 4 महीने का समय लगने का कारण शायद, जैसा आपने कहा, मेरी पसंद के फीचर्स को इस तरह विस्तारयोग्य बनाना भी रहा होगा कि कई लोग उनका इस्तेमाल कर सकें, और इसे आम लोगों के सामने जारी करने के लिए भी काफ़ी हिम्मत चाहिए थी।
साथ ही, जहाँ orca जैसे प्रोग्रामों को कंपनियों का समर्थन मिलता है, वहीं व्यक्तिगत रूप से चलाए जा रहे प्रोजेक्ट्स की motivation को लेकर मैं उल्टा काफ़ी सकारात्मक सोच रखता हूँ।
बेशक आर्थिक दबाव जितनी बड़ी motivation और कुछ नहीं होती, लेकिन मैंने अपने पूरे workflow को अपने ही टूल्स के हिसाब से सेट कर रखा है, इसलिए अगर मुझे अभी काम करना है तो मुझे इन्हीं टूल्स को बेहतर बनाना ही होगा। इसी वजह से मैं अपने निजी समय को भी जितना हो सके बाँटकर इन टूल्स को सुधारने में निवेश कर रहा हूँ।
बिल्कुल, जिस क्षण मेरी motivation गिर जाएगी, उस क्षण सब खत्म हो सकता है, लेकिन उस स्थिति से बचने के लिए मैंने जानबूझकर अपने workflow को अपने टूल्स के लिए optimize कर रखा है ताकि ऐसी स्थिति न आए!
व्यक्तिगत रूप से मुझे लगता है कि अभी भी competing tools की तुलना में जो कमी है, वह तकनीकी नहीं बल्कि सिर्फ़ marketing की है, इसलिए feedback लेने के लिए इसे सार्वजनिक करना भी काफ़ी बड़ा कदम था।
GPU rendering करने का मकसद Windows support से ज़्यादा, तकनीकी चुनौती और उन प्रोग्रामों के लिए optimization था जो terminal screen को पूरा भर देते हैं।
मैंने काफ़ी समय से Windows को development के लिए इस्तेमाल नहीं किया है, इसलिए उस OS के support के बारे में गहराई से नहीं सोच पाया था, लेकिन अब लगता है कि बुनियाद काफ़ी बन चुकी है, तो शायद एक बार इसे आज़माया जा सकता है।
मेरा लक्ष्य बस इतना है कि मेरे पूरे development काम के लिए सिर्फ़ copad ही काफ़ी हो, और इसी के लिए मैंने plugin system भी बना रखा है!
इसलिए जिन फीचर्स के लिए GUI चाहिए, उन्हें भी मैं जितना हो सके copad में ही implement करने की कोशिश करता हूँ।
रेंडरिंग के तरीके में काफ़ी बड़ा फ़र्क है, लेकिन सच कहें तो end user के नज़रिए से महसूस होने वाला अंतर इतना बड़ा नहीं है, इसलिए इसे विस्तार से बताना थोड़ा संकोचजनक लगता है। जैसा आपने कहा, उत्पादन लागत कम होने के साथ शायद अब वही दौर आ गया है जहाँ जो चीज़ हाथ में सबसे अच्छी बैठे, वही सबसे बेहतर है..!
मैंने अभी तक इसे वास्तविक प्रोडक्शन सर्विस में लागू करके नहीं देखा है। ये सारे आँकड़े public benchmark traces से आए हैं, इसलिए पहले उनकी सीमा बताना सही होगा।
फिर भी, idempotency key डिज़ाइन के लिए एक उपयोगी अवलोकन है।
"दो बार call" बनाम "दो बार execution" को अलग करने के लिए मैंने response में शामिल entity ID की तुलना की। एक ही arguments के साथ दो बार call होने पर अगर response ID अलग हो, तो वास्तव में दो चीज़ें बनीं; और अगर वही हो, तो API ने अपने-आप उसे filter कर दिया।
Toolathlon benchmark के अनुसार state-changing tools के duplicate calls में:
ID अलग थे (वास्तविक duplicate creation): 159 मामले
ID एक ही थे (API ने dedup किया): 76 मामले
ID था ही नहीं, इसलिए निर्णय असंभव: 3,197 मामले
यहाँ एक पैटर्न दिखा। ID अलग वाले 159 मामले सभी creation-type tools थे (document creation, spreadsheet creation, file upload, quiz creation)। दूसरी ओर update-type tools (patch, update, enroll) में ID अलग होने का एक भी मामला नहीं था। वे उसी target को point कर रहे थे, इसलिए नया creation नहीं हुआ।
यानि अगर आप idempotency key जोड़ने वाले हैं, तो creation (POST) वाला हिस्सा प्राथमिकता होना चाहिए। update वाले हिस्से में कई बार पहले से ही स्वाभाविक idempotency दिखी।
और मैंने पहले जो email वाली समस्या बताई थी, वही यहाँ फिर सामने आती है। email sending में response सिर्फ "success" string था, इसलिए ID comparison संभव नहीं था। idempotency key जोड़ने पर भी वह वास्तव में काम किया या नहीं, यह सिर्फ trace से verify करने का तरीका नहीं है। अगर आप internal tool डिज़ाइन कर रहे हैं, तो sending result में message ID लौटाना भर audit log में verification संभव बना देगा। यह आपके बताए hash chain तरीके के साथ भी अच्छी तरह मेल खाएगा।
एक बार फिर सीमा स्पष्ट कर दूँ: ऊपर के सभी आँकड़े benchmark traces से हैं, इसलिए वास्तविक production environment में यही अनुपात होगा, यह ज़रूरी नहीं। अगर कभी आपको traces चलाने का मौका मिले, तो नतीजे कैसे अलग आते हैं यह जानने में दिलचस्पी होगी।
इसलिए सबसे अच्छा तरीका यह है कि closed LLM को जितना हो सके सस्ते में बाज़ार में उपलब्ध कराया जाए। अगर high-performance intelligence तक पहुँच बढ़े, तो स्वाभाविक रूप से open-weight models विकसित करने की प्रेरणा घटेगी, और तकनीकी नेतृत्व भी सामान्य संस्थानों के पास रह सकता है। लेकिन असल में Anthropic तो बाज़ार में सबसे ज़्यादा exclusive provider है, है न?
आजकल coding agents अपनी कमियों की भरपाई करने में मदद कर सकते हैं, इसलिए अगर आप अपनी ताकतों को स्पष्ट रूप से समझकर उनका सही इस्तेमाल कर सकें, तो मुझे लगता है कि entry barrier कम हो सकता है।
मेरे लिए भी documentation हमेशा एक समस्या रही है, लेकिन जब मैंने उसका कुछ हिस्सा coding agent को सौंप दिया, तो बोझ कम हुआ। और उस documented सामग्री की समीक्षा करते-करते लगता है कि documentation को लेकर मेरी समझ भी विकसित हो रही है।
पढ़ने के लिए धन्यवाद! पहले दस्तावेज़, test cases, validation वगैरह जैसी कई चीज़ें थीं जिन पर लोगों को सीधे ध्यान देना पड़ता था, लेकिन अब काफ़ी बड़े हिस्से AI coding agents के साथ किए जा सकते हैं, इसलिए लगता है कि open source को maintain करने की कठिनाई भी पहले की तुलना में काफ़ी कम हो गई है!
@xguru लगता है लिंक गलत है~
हाँ, अगर सिर्फ clipboard history के हिसाब से देखें तो काफी overlap है। लेकिन Raycast में clipboard के अलावा भी बहुत सारे features हैं, इसलिए मुझे वह थोड़ा ज़्यादा भारी लगा।
मैंने जिन चीज़ों पर ध्यान दिया, वे ये हैं।
सबसे पहले, इसे हल्का रखा है और यह सिर्फ clipboard history को ही manage करता है; अभी इसका size करीब 2MB है।
और saved content को detail view में edit करके वापस रख सकते हैं। कई prompts को review करते समय और पहले से थोड़ा-थोड़ा tweak करते समय यह सुविधाजनक लगा।
Search और folders पर भी ध्यान दिया है। काम करते समय ज़रूरी जानकारी—जो one-time हो या जिसे फिर से ढूँढना झंझट लगे—उसकी समस्या हल करने की कोशिश की है।
Body, tags, title आदि से search करने योग्य बनाया है।
आगे चलकर मैं plugins के जरिए features या layouts को सीधे जोड़ने की सुविधा देना चाहता हूँ, लेकिन यह अभी पूरी तरह concretize नहीं हुआ है।
मुझे Raycast भी एक अच्छा app लगता है, और मैं कोशिश करना चाहता हूँ कि यह personal preference के हिसाब से एक विकल्प बन सके।
आपकी राय के लिए धन्यवाद।
ऐसे tools में सबसे मुश्किल काम बनाना नहीं, बल्कि हटाना होता है, इसलिए
gardenको अलग lifecycle में बाँटना खास तौर पर ध्यान खींचता है.एजेंट को दिया जाने वाला context पुराना हो जाए तो वह सिर्फ बेकार नहीं होता, बल्कि नुकसानदेह भी हो जाता है. इंसान दस्तावेज़ देखकर अंदाज़ा लगा लेता है कि "यह शायद पुरानी बात है", लेकिन मॉडल के पास वह समझ नहीं होती, इसलिए 3 महीने पहले सही रही किसी invariant condition को वह आज भी वैसा ही सही मानकर इस्तेमाल कर लेता है. कोड हो तो कम-से-कम compile टूट जाता है, लेकिन wiki चुपचाप गलत होती रहती है.
इसीलिए मुझे यह जानने की उत्सुकता है कि क्या पेज पर यह जुड़ता है कि वह किस समय को आधार मानकर लिखा गया है, और किस आधार पर लिखा गया है. इसे Markdown में repository में रखकर Git में review कराने का फैसला मुझे उस लिहाज़ से सही लगता है, लेकिन diff में यह दर्ज होता है कि दस्तावेज़ कब बदला, यह नहीं कि उसकी सामग्री कब तक वैध रही.
1,700 एंट्री के स्तर पर performance की बात practically मायने नहीं रखती; frontend पर सीधे process करें या backend रखें, दोनों ही तुरंत चलेंगे। इसलिए मेरा मानना है कि निर्णय का आधार speed नहीं, बल्कि यह होना चाहिए कि मौजूदा Python logic को दोबारा लिखना है या नहीं।
उस आधार पर Streamlit सबसे उपयुक्त लगता है। matching logic को वैसे ही import करके इस्तेमाल कर सकते हैं, और UI में 5
selectboxव एक result table हो तो काम पूरा हो जाता है, इसलिए frontend code लिखने की ज़रूरत नहीं पड़ती। इसे Streamlit Community Cloud पर deploy करें तो share करने लायक link भी मुफ्त में मिल जाता है, और अगर JSON को runtime पर read करने के लिए रखें तो सिर्फ file बदलने से ही नया data reflect हो जाएगा।Static HTML का deployment ज़्यादा आसान है, लेकिन उसके बदले Python logic को JS में ले जाना पड़ेगा। अगर score calculation थोड़ा भी complex हुआ, तो वही porting कई दिन खा जाएगी। अगर लक्ष्य इस हफ्ते के भीतर working demo दिखाना है, तो मुझे लगता है वह risk न लेना ही बेहतर है।
एक बात और, Streamlit आखिरकार product से ज़्यादा एक tool जैसा दिखता है। अगर यह internal decision-makers के लिए demo है और उद्देश्य सिर्फ यह verify करना है कि "input देने पर सच में result आता है", तो कोई दिक्कत नहीं; लेकिन अगर यह external customer demo है, तो इस बात को ध्यान में रखना होगा.
लगता है कि इसमें Raycast के लगभग सभी फीचर्स सपोर्ट हैं, तो क्या बता सकते हैं कि फर्क किस बात में है?
ओह... Show GN पोस्ट्स में मैं हमेशा सिर्फ़ 'कुछ बनाया' से आगे बढ़कर ऐसे insights भी साथ में देखना चाहता था, इसलिए ऐसी पोस्ट देखकर काफ़ी उत्साहित हूँ haha
हर मामले के लिए अलग-अलग expert ढूँढकर सिर्फ़ उनके scope का काम सौंपने के बजाय, लोगों की psychology यही होती है कि एक ही व्यक्ति को दे दें और वह अपने-आप सब कुछ अच्छे से संभाल ले।
LLM में भी reward function शायद ऐसा ही बनाया जाएगा कि आप कुछ भी फेंक दें, वह सब स्वीकार कर ले, है ना?
भले ही यह एक सार्वजनिक benchmark हो, इतने specific numbers मैंने पहली बार देखे हैं। धन्यवाद।
159 cases / 76 cases / 3,197 cases का ratio खास तौर पर ध्यान खींचता है। यह तथ्य कि फैसला न हो सकने वाले cases (ID नहीं) भारी संख्या में हैं — आखिरकार इसका मतलब है कि ज़्यादातर duplicates ऐसे हिस्से में हैं जहाँ tracking खुद संभव नहीं है, और इससे फिर पुष्टि हुई कि सिर्फ “audit logs हैं तो ठीक है” सोचकर निश्चिंत नहीं होना चाहिए।
creation (POST) को प्राथमिकता देने की दिशा हमारे design से बिल्कुल मेल खाती है। हमारे hash chain में idempotency key को creation event से पहले जोड़ने की कोशिश का कारण ठीक यही था।
email message ID वाला सुझाव मैं तुरंत लागू करूँगा। internal tool spec में सिर्फ “response में entity ID अनिवार्य” जोड़ देने से audit log की verifiability बदल जाती है। और अगर hash chain में ID को anchor की तरह इस्तेमाल करें, तो duplicate है या नहीं यह calculation से ही verify किया जा सकता है।
क्या आपको पता चल पाया कि 3,197 “ID नहीं” वाले cases किन tool types में ज़्यादा clustered थे? email के अलावा, केवल “success/failure” लौटाने वाले tools कितने हैं, यह जानना चाहूँगा।
फ़िलहाल optimization चल रहा है, इसलिए अगर यह इस हफ्ते के भीतर पूरा हो गया तो आप इसे और साफ़-सुथरे तरीके से देख पाएँगे :)
आपने तो पहले ही Korean language switch feature जोड़ दिया है :)
सच में बहुत धन्यवाद
मुझे भी ऐसा कुछ बनाने वाले किसी व्यक्ति से मिलकर काफ़ी अच्छा लगा!
मैंने भी बड़े Claude युग के आने से पहले Rust में API भी बनाए, CLI भी बनाए, और इस तरह Rust में काफ़ी समय लगाया था!
मैंने भी काफ़ी हाल में सोचना शुरू किया कि tmux को बदलना चाहिए, इसलिए tmux को पूरी तरह बदले हुए ज़्यादा समय नहीं हुआ है, लेकिन मैंने अपना multiplexer भी बनाया और दूसरे ही दिन से tmux का इस्तेमाल न्यूनतम कर दिया था!
यहाँ सिर्फ़ पूर्णता का मुद्दा नहीं था, बल्कि मुझे लगता है कि अगर मेरे बनाए टूल के बजाय किसी दूसरे टूल पर fallback मौजूद हो, तो वही एक तरह का बच निकलने का रास्ता बन जाता है और शायद इसी वजह से मैं विकास पर उतनी मेहनत नहीं करता था।
और 4 महीने का समय लगने का कारण शायद, जैसा आपने कहा, मेरी पसंद के फीचर्स को इस तरह विस्तारयोग्य बनाना भी रहा होगा कि कई लोग उनका इस्तेमाल कर सकें, और इसे आम लोगों के सामने जारी करने के लिए भी काफ़ी हिम्मत चाहिए थी।
साथ ही, जहाँ orca जैसे प्रोग्रामों को कंपनियों का समर्थन मिलता है, वहीं व्यक्तिगत रूप से चलाए जा रहे प्रोजेक्ट्स की motivation को लेकर मैं उल्टा काफ़ी सकारात्मक सोच रखता हूँ।
बेशक आर्थिक दबाव जितनी बड़ी motivation और कुछ नहीं होती, लेकिन मैंने अपने पूरे workflow को अपने ही टूल्स के हिसाब से सेट कर रखा है, इसलिए अगर मुझे अभी काम करना है तो मुझे इन्हीं टूल्स को बेहतर बनाना ही होगा। इसी वजह से मैं अपने निजी समय को भी जितना हो सके बाँटकर इन टूल्स को सुधारने में निवेश कर रहा हूँ।
बिल्कुल, जिस क्षण मेरी motivation गिर जाएगी, उस क्षण सब खत्म हो सकता है, लेकिन उस स्थिति से बचने के लिए मैंने जानबूझकर अपने workflow को अपने टूल्स के लिए optimize कर रखा है ताकि ऐसी स्थिति न आए!
व्यक्तिगत रूप से मुझे लगता है कि अभी भी competing tools की तुलना में जो कमी है, वह तकनीकी नहीं बल्कि सिर्फ़ marketing की है, इसलिए feedback लेने के लिए इसे सार्वजनिक करना भी काफ़ी बड़ा कदम था।
GPU rendering करने का मकसद Windows support से ज़्यादा, तकनीकी चुनौती और उन प्रोग्रामों के लिए optimization था जो terminal screen को पूरा भर देते हैं।
मैंने काफ़ी समय से Windows को development के लिए इस्तेमाल नहीं किया है, इसलिए उस OS के support के बारे में गहराई से नहीं सोच पाया था, लेकिन अब लगता है कि बुनियाद काफ़ी बन चुकी है, तो शायद एक बार इसे आज़माया जा सकता है।
मेरा लक्ष्य बस इतना है कि मेरे पूरे development काम के लिए सिर्फ़ copad ही काफ़ी हो, और इसी के लिए मैंने plugin system भी बना रखा है!
इसलिए जिन फीचर्स के लिए GUI चाहिए, उन्हें भी मैं जितना हो सके copad में ही implement करने की कोशिश करता हूँ।
रेंडरिंग के तरीके में काफ़ी बड़ा फ़र्क है, लेकिन सच कहें तो end user के नज़रिए से महसूस होने वाला अंतर इतना बड़ा नहीं है, इसलिए इसे विस्तार से बताना थोड़ा संकोचजनक लगता है। जैसा आपने कहा, उत्पादन लागत कम होने के साथ शायद अब वही दौर आ गया है जहाँ जो चीज़ हाथ में सबसे अच्छी बैठे, वही सबसे बेहतर है..!
इन-हाउस काउंसलिंग रिकॉर्ड HR के अनुशासनात्मक फ़ोल्डर में जमा करने वाला Samsung वाकई एक वैश्विक अग्रणी कंपनी है
मैंने अभी तक इसे वास्तविक प्रोडक्शन सर्विस में लागू करके नहीं देखा है। ये सारे आँकड़े public benchmark traces से आए हैं, इसलिए पहले उनकी सीमा बताना सही होगा।
फिर भी,
idempotency keyडिज़ाइन के लिए एक उपयोगी अवलोकन है।"दो बार call"बनाम"दो बार execution"को अलग करने के लिए मैंने response में शामिल entity ID की तुलना की। एक ही arguments के साथ दो बार call होने पर अगर response ID अलग हो, तो वास्तव में दो चीज़ें बनीं; और अगर वही हो, तो API ने अपने-आप उसे filter कर दिया।Toolathlon benchmark के अनुसार state-changing tools के duplicate calls में:
ID अलग थे (वास्तविक duplicate creation): 159 मामले
ID एक ही थे (API ने dedup किया): 76 मामले
ID था ही नहीं, इसलिए निर्णय असंभव: 3,197 मामले
यहाँ एक पैटर्न दिखा। ID अलग वाले 159 मामले सभी creation-type tools थे (document creation, spreadsheet creation, file upload, quiz creation)। दूसरी ओर update-type tools (
patch,update,enroll) में ID अलग होने का एक भी मामला नहीं था। वे उसी target को point कर रहे थे, इसलिए नया creation नहीं हुआ।यानि अगर आप
idempotency keyजोड़ने वाले हैं, तो creation (POST) वाला हिस्सा प्राथमिकता होना चाहिए। update वाले हिस्से में कई बार पहले से ही स्वाभाविक idempotency दिखी।और मैंने पहले जो email वाली समस्या बताई थी, वही यहाँ फिर सामने आती है। email sending में response सिर्फ
"success"string था, इसलिए ID comparison संभव नहीं था।idempotency keyजोड़ने पर भी वह वास्तव में काम किया या नहीं, यह सिर्फ trace से verify करने का तरीका नहीं है। अगर आप internal tool डिज़ाइन कर रहे हैं, तो sending result मेंmessage IDलौटाना भर audit log में verification संभव बना देगा। यह आपके बताएhash chainतरीके के साथ भी अच्छी तरह मेल खाएगा।एक बार फिर सीमा स्पष्ट कर दूँ: ऊपर के सभी आँकड़े benchmark traces से हैं, इसलिए वास्तविक production environment में यही अनुपात होगा, यह ज़रूरी नहीं। अगर कभी आपको traces चलाने का मौका मिले, तो नतीजे कैसे अलग आते हैं यह जानने में दिलचस्पी होगी।
यह स्क्रीनशॉट रखने वाली एक टोकरी जैसा है।
मिलते-जुलते JIT compilation approach वाला numba तो है, लेकिन इसका coverage ज़्यादा बड़ा लगता है।
अगर वे
gps oss 120bजैसी कोई चीज़ जारी कर दें, तो कम से कम बात कुछ हद तक भरोसेमंद लगेगी, लेकिन पता नहीं।इसलिए सबसे अच्छा तरीका यह है कि closed LLM को जितना हो सके सस्ते में बाज़ार में उपलब्ध कराया जाए। अगर high-performance intelligence तक पहुँच बढ़े, तो स्वाभाविक रूप से open-weight models विकसित करने की प्रेरणा घटेगी, और तकनीकी नेतृत्व भी सामान्य संस्थानों के पास रह सकता है। लेकिन असल में Anthropic तो बाज़ार में सबसे ज़्यादा exclusive provider है, है न?