> लगता है कि यह नेतृत्व करने के लिए बिल्कुल उपयुक्त होगा, लेकिन उसने ऐसी अतिरिक्त भूमिका स्वीकार करने से इनकार कर दिया।
> जब लेखक विकास के लिए नई चुनौती का प्रस्ताव करता है ...
एक इंजीनियर के नज़रिए से देखें, तो क्या जिस काम में हम अच्छे हैं उसे और बेहतर करना ही विकास नहीं है?
किसी भी किताब या लेख में देखें तो
तीसरे बिंदु के बारे में हमेशा ऐसा ही लिखा होता है,
लेकिन वास्तव में
यह क्यों पूछ रहा है
अब जाकर इसका ज़िक्र क्यों कर रहा है
क्या यह भी पूछने वाली बात है
ऐसी 3-स्टेप कॉम्बो की वजह से आपको कमज़ोर पार्टनर समझे जाने की संभावना रहती है
नाम का एक Computer-use Agent बना रहा हूँ, और ज़्यादातर बातों से सहमत हूँ.
इस लेख में व्यावहारिक टिप्स से ज़्यादा बस एक बड़ा overview दिया गया है, इसलिए अगर LLM based agentic/agent डेवलप करते समय कुछ और टिप्स जोड़ूँ, तो आखिरकार LLM transformer (यानी probabilistic based inference; मौजूदा token/state के आधार पर अगले token को संदर्भ/semantic रूप से सच में “समझकर” अगला शब्द बोलने के बजाय probability के आधार पर output देने वाला) पर आधारित होता है. इसलिए चाहे sys prompt कितना भी अच्छा लिख दें, कई बार वह मनचाहा जवाब नहीं देता (जैसे JSON output में जवाब देने को कहें, लेकिन कभी-कभी } छोड़ दे वगैरह). इसलिए regex based कई fallback fn जोड़ना हमेशा ज़रूरी है.
और अगर structured output देने वाला sys prompt लिखते हैं, तो आम तौर पर non reasoning model इस्तेमाल करें. Context जितना लंबा होता है, hallucination उतनी ज़्यादा होती है, इसलिए कई बार एक sys prompt लंबा करने के बजाय कई sys prompt बनाकर chaining करना बेहतर होता है.
अगर आप service डेवलप कर रहे हैं, तो कई तरह की errors आ सकती हैं, इसलिए service architecture को modular और fault tolerant बनाकर डिज़ाइन करना सबसे अहम है (जैसे supervisor agent को async रखना और बाकी agents को sync). खासकर ऐसे agentic/agents में, जहाँ unexpected output बहुत बार आता है.
इसलिए शुरू से ही code लिखते समय SRP को मानते हुए declarative तरीके से लिखना अच्छा है. मेरा कहना है कि functional approach बेहतर है (= side effect नहीं होता, और flow intuitive रहता है).
और LLM को API के जरिए इस्तेमाल कर रहे हैं या खुद model serving करेंगे, इस पर भी फर्क पड़ता है. लेकिन अगर आप खुद SLM या LLM serve करने वाले हैं, तो backend host करने वाले उसी server पर model serving मत रखिए. IO bound task और CPU bound tasks (यानी GPU required, matrix multiplication जैसी चीज़ों वाले tasks) को अलग-अलग servers पर रखना fault tolerant होने के लिहाज़ से बेहतर है (जैसे runpod पर cpu bound task host करना).
इसके अलावा भी कई development tips हैं, लेकिन जवाब बहुत लंबा हो जाएगा इसलिए अभी यहीं तक लिखता हूँ.
कोरियाई अनुवाद में पहले ही बेहूदा ऑटो-ट्रांसलेशन गंदे तरीके से ठूंस दिया था, और अब तो यह और भी विकसित हो गया है। ऑटो-ट्रांसलेशन भी नहीं रोक पाए, तो अब इस बेहूदा AI को गंदे तरीके से ठूंसना भी पूरा झेलेंगे!
मुझे AI फीचर्स, खासकर वे सेवाएँ जो बैकग्राउंड में इंतज़ार करती रहती हैं और कहती हैं कि वे मदद करेंगी, बिल्कुल पसंद नहीं हैं।
अगर वे remote पर चलती हैं तो मेरी जानकारी साझा होने की समस्या है, और अगर वे local पर चलती हैं तो वे मेरे कंप्यूटर के resources (CPU, memory, battery, ...) खर्च करती हैं।
यही तो है lol
यह कुछ ऐसा है जैसे कार और मैराथन की तुलना करना..
हाहाहा "फ़ीचर होना चाहिए"
मैं आपसे पूरी तरह सहमत हूँ!
हाहाहाहा
शायद इसे hallucination-driven development कहना चाहिए...;;
> लगता है कि यह नेतृत्व करने के लिए बिल्कुल उपयुक्त होगा, लेकिन उसने ऐसी अतिरिक्त भूमिका स्वीकार करने से इनकार कर दिया।
> जब लेखक विकास के लिए नई चुनौती का प्रस्ताव करता है ...
एक इंजीनियर के नज़रिए से देखें, तो क्या जिस काम में हम अच्छे हैं उसे और बेहतर करना ही विकास नहीं है?
आपके अच्छे शब्दों के लिए धन्यवाद!!
शायद वे इस बारे में सोच रहे होंगे कि बढ़ती ज़िम्मेदारियों और काम के मुकाबले वेतन स्तर और待遇 में कोई बढ़ोतरी नहीं हो रही है।
यह बहुत संभव है
बेशक, अगर लीडर अच्छा हो तो वह ध्यान से सुनेगा
और समस्या को सही तरीके से हल कर देगा
किसी भी किताब या लेख में देखें तो
तीसरे बिंदु के बारे में हमेशा ऐसा ही लिखा होता है,
लेकिन वास्तव में
यह क्यों पूछ रहा है
अब जाकर इसका ज़िक्र क्यों कर रहा है
क्या यह भी पूछने वाली बात है
ऐसी 3-स्टेप कॉम्बो की वजह से आपको कमज़ोर पार्टनर समझे जाने की संभावना रहती है
मैं भी अभी
UseDesktophttps://youtu.be/aBkbsvMxP_A?si=uaugxKQEu4ZEz7jq
usedesktop.com
नाम का एक Computer-use Agent बना रहा हूँ, और ज़्यादातर बातों से सहमत हूँ.
इस लेख में व्यावहारिक टिप्स से ज़्यादा बस एक बड़ा overview दिया गया है, इसलिए अगर LLM based agentic/agent डेवलप करते समय कुछ और टिप्स जोड़ूँ, तो आखिरकार LLM transformer (यानी probabilistic based inference; मौजूदा token/state के आधार पर अगले token को संदर्भ/semantic रूप से सच में “समझकर” अगला शब्द बोलने के बजाय probability के आधार पर output देने वाला) पर आधारित होता है. इसलिए चाहे sys prompt कितना भी अच्छा लिख दें, कई बार वह मनचाहा जवाब नहीं देता (जैसे JSON output में जवाब देने को कहें, लेकिन कभी-कभी
}छोड़ दे वगैरह). इसलिए regex based कई fallback fn जोड़ना हमेशा ज़रूरी है.और अगर structured output देने वाला sys prompt लिखते हैं, तो आम तौर पर non reasoning model इस्तेमाल करें. Context जितना लंबा होता है, hallucination उतनी ज़्यादा होती है, इसलिए कई बार एक sys prompt लंबा करने के बजाय कई sys prompt बनाकर chaining करना बेहतर होता है.
अगर आप service डेवलप कर रहे हैं, तो कई तरह की errors आ सकती हैं, इसलिए service architecture को modular और fault tolerant बनाकर डिज़ाइन करना सबसे अहम है (जैसे supervisor agent को async रखना और बाकी agents को sync). खासकर ऐसे agentic/agents में, जहाँ unexpected output बहुत बार आता है. इसलिए शुरू से ही code लिखते समय SRP को मानते हुए declarative तरीके से लिखना अच्छा है. मेरा कहना है कि functional approach बेहतर है (= side effect नहीं होता, और flow intuitive रहता है).
और LLM को API के जरिए इस्तेमाल कर रहे हैं या खुद model serving करेंगे, इस पर भी फर्क पड़ता है. लेकिन अगर आप खुद SLM या LLM serve करने वाले हैं, तो backend host करने वाले उसी server पर model serving मत रखिए. IO bound task और CPU bound tasks (यानी GPU required, matrix multiplication जैसी चीज़ों वाले tasks) को अलग-अलग servers पर रखना fault tolerant होने के लिहाज़ से बेहतर है (जैसे runpod पर cpu bound task host करना).
इसके अलावा भी कई development tips हैं, लेकिन जवाब बहुत लंबा हो जाएगा इसलिए अभी यहीं तक लिखता हूँ.
उम्मीद है यह किसी के काम आएगा.
Private remote server पर install करने वाले तरह की service कैसी रहेगी?
कोरियाई अनुवाद में पहले ही बेहूदा ऑटो-ट्रांसलेशन गंदे तरीके से ठूंस दिया था, और अब तो यह और भी विकसित हो गया है। ऑटो-ट्रांसलेशन भी नहीं रोक पाए, तो अब इस बेहूदा AI को गंदे तरीके से ठूंसना भी पूरा झेलेंगे!
cgiतो फिर भी समझ आता है, लेकिनjspपर लोगों की प्रतिक्रिया काफ़ी चौंकाने वाली है lolक्या
jspसच में अब उस हद तक का प्राचीन अवशेष बन चुका है?मुझे AI फीचर्स, खासकर वे सेवाएँ जो बैकग्राउंड में इंतज़ार करती रहती हैं और कहती हैं कि वे मदद करेंगी, बिल्कुल पसंद नहीं हैं।
अगर वे remote पर चलती हैं तो मेरी जानकारी साझा होने की समस्या है, और अगर वे local पर चलती हैं तो वे मेरे कंप्यूटर के resources (CPU, memory, battery, ...) खर्च करती हैं।
लगता है यह एक अच्छा reference बनेगा
रूस के एक डेवलपर हैं, Yandex से Riot गए थे और अब JPMorganChase में जॉब बदल ली है।
हाहाहाहा, बहुत मज़ेदार है
लगता है बस नाम ही बदला गया है।