- LLM-आधारित सिस्टम बनाने वाली ज़्यादातर टीमें सबसे पहले Agent बनाना चाहती हैं, लेकिन अधिकतर मामलों में वे complexity, control की कमी, और debugging की कठिनाई की वजह से जल्दी टूट जाती हैं
- असली agent pattern, जिसमें memory, RAG, tool use, और workflow control सबकी ज़रूरत होती है, व्यवहार में कम ही मिलता है; ज़्यादातर समस्याएँ simple workflows (chaining, parallelization, routing आदि) से ज़्यादा प्रभावी ढंग से हल की जा सकती हैं
- पहले वास्तव में उपयोगी 5 LLM workflow patterns लागू करने की सलाह दी जाती है, और agents का इस्तेमाल केवल तब करना चाहिए जब उनकी सच में ज़रूरत हो
- Prompt Chaining, Parallelization, Routing, Orchestrator-Worker, Evaluator-Optimizer
- जिन मामलों में agent की ज़रूरत पड़ती भी है, वहाँ भी मानव की भागीदारी, स्पष्ट नियंत्रण, और observability ही सबसे अहम हैं
AI एजेंट, क्या वाकई ज़रूरी हैं?
- Netflix, Meta, अमेरिकी वायुसेना सहित कई इंजीनियरों और टीमों को LLM systems बनाने पर consulting और training देने वाले Hugo Bowne-Anderson की अंतर्दृष्टि
गलत शुरुआत: सब लोग agents पर इतने अटके क्यों हैं
- कई टीमें LLM project शुरू करते समय agent, memory, routing, tool use, और character/persona जैसी जटिल संरचनाएँ पहले ही जोड़ देती हैं
- जब इन्हें वास्तव में बनाया जाता है, तो agents के बीच collaboration, tool selection, और long-term memory जैसे हिस्सों में बार-बार असामान्य behavior और failure देखने को मिलता है
- उदाहरण के तौर पर, CrewAI-आधारित research agent project में हर role (researcher, summarizer, coordinator) उम्मीद के मुताबिक सहयोग नहीं कर पाया और सिस्टम बुरी तरह ढह गया
Agent क्या है?
- LLM system की 4 विशेषताएँ: memory, information retrieval (RAG), tool use, और workflow control
- आख़िरी workflow control, यानी LLM का अगला step या tool use खुद तय करना, agentic trait कहलाता है
- लेकिन वास्तविक दुनिया के ज़्यादातर कामों में simple workflows (chaining, routing आदि) ज़्यादा स्थिर साबित होते हैं
Agent की जगह इस्तेमाल करने लायक, व्यवहार में उपयोगी LLM workflow patterns
1. Prompt Chaining
- विवरण: कई कामों को क्रमबद्ध चरणों की एक chain में बाँटकर, हर चरण को LLM से बारी-बारी प्रोसेस कराया जाता है
- उदाहरण: LinkedIn profile से नाम, पद, और company जानकारी निकालना → उस company की अतिरिक्त जानकारी (mission, hiring आदि) जोड़ना → profile + company जानकारी के आधार पर customized email लिखना
- फायदे: हर चरण साफ़ तौर पर अलग होता है, इसलिए bug आने पर कारण ढूँढना और सुधारना आसान होता है; debugging और maintenance में मदद मिलती है
- Guidelines:
- उन tasks के लिए उपयुक्त जो क्रम से जुड़े हों
- एक भी चरण fail हुआ तो पूरी chain टूट सकती है
- काम को छोटे हिस्सों में बाँटने से results ज़्यादा predictable होते हैं और debugging आसान होती है
2. Parallelization
- विवरण: कई independent tasks को एक साथ चलाकर पूरी process की speed बढ़ाई जाती है
- उदाहरण: कई लोगों की profiles से education, experience, skills जैसी कई जानकारियाँ parallel में निकालकर कुल processing time घटाना
- फायदे: independent data extraction/processing जैसे कामों में बड़े scale पर भी efficient, और distributed processing environments के साथ अच्छी तरह काम करता है
- Guidelines:
- जब हर task एक-दूसरे से independent हो और साथ चलाने से overall speed काफ़ी बढ़े
- parallel execution के दौरान race condition, timeout जैसी exceptions पर ध्यान देना ज़रूरी है
- बड़े पैमाने के data processing और कई sources के simultaneous analysis के लिए उपयुक्त
3. Routing
- विवरण: LLM input data को classify करके अपने-आप उपयुक्त workflow की ओर भेजता है
- उदाहरण: customer support tool में input को product query, payment issue, या refund request के रूप में classify करके संबंधित workflow में भेजना; type अस्पष्ट हो तो default handler को देना
- फायदे: input type के अनुसार specialized processing logic लागू करके अलग-अलग मामलों को साफ़-सुथरे ढंग से अलग किया जा सकता है
- Guidelines:
- जब अलग-अलग input types या situations के लिए अलग handling चाहिए
- boundary cases या exceptions में routing fail हो सकती है या कुछ छूट सकता है
- unclassified/exception cases के लिए catch-all handler ज़रूर डिज़ाइन करें
4. Orchestrator-Worker
- विवरण: orchestrator की भूमिका वाला LLM task को तोड़ता/आँकता है और worker (execution LLM) को detail tasks सौंपता है, जबकि पूरी flow और sequence पर खुद नियंत्रण रखता है
- उदाहरण: target profile को tech/non-tech में classify करना → अगर tech हो तो specialized worker को email generation देना, non-tech हो तो दूसरे worker को देना
- फायदे: decision-making (classification/judgment) और execution (individual processing) अलग हो जाते हैं, जिससे dynamic flow control और scaling आसान होती है
- Guidelines:
- जब हर task के लिए specialized handling चाहिए, या branching और step-by-step coordination जटिल हो
- अगर orchestrator task को ग़लत तरीके से तोड़े या delegate करे, तो पूरी flow में error आ सकती है
- logic को स्पष्ट और सरल रखें, और delegation/sequence/termination conditions को साफ़ तौर पर डिज़ाइन करें
5. Evaluator-Optimizer
- विवरण: LLM output का मूल्यांकन करता है (score/feedback), और अगर वह मानक से कम हो तो उसे बार-बार सुधारता/बेहतर करता है
- उदाहरण: email draft बनाना → evaluator quality score/feedback देता है → तय मानक पूरा होने पर या maximum iteration limit पार होने पर समाप्त, नहीं तो फिर से संशोधन
- फायदे: final output की quality को लक्ष्य स्तर तक बार-बार बेहतर किया जा सकता है, और quantitative criteria का उपयोग आसान होता है
- Guidelines:
- जब speed से ज़्यादा quality महत्वपूर्ण हो, और iterative optimization की ज़रूरत हो
- termination condition न हो तो infinite loop में फँसने का जोखिम है
- स्पष्ट quality criteria और iteration limits तय करना ज़रूरी है
जब agent सच में ज़रूरी हो
- ऐसे environment में जहाँ Human-in-the-loop की real-time भागीदारी सुनिश्चित हो, agent अपनी असली उपयोगिता दिखाते हैं
- उदाहरण1: data science assistant - SQL query, visualization, data analysis recommendation जैसे कामों में LLM रचनात्मक रूप से कोशिश करे, और इंसान परिणाम को आँके/सुधारे
- उदाहरण2: creative partner - copy idea, headline suggestion, text structure recommendation जैसे कामों में इंसानी दिशा-संशोधन और quality review अहम हो
- उदाहरण3: code refactoring assistant - design pattern suggestions, edge-case detection, code optimization आदि में developer approval/adjustment दे
- विशेषता: agent “सब कुछ अपने-आप” नहीं करता; यह सबसे प्रभावी तब होता है जब इंसान real time में errors और direction को संभालता है
जब agent उपयुक्त नहीं है
- Enterprise और mission-critical systems (finance, healthcare, legal आदि):
- यहाँ automation की reliability और deterministic behavior महत्वपूर्ण हैं, इसलिए LLM agent द्वारा decision लेने वाली संरचना जोखिमपूर्ण है
- Orchestrator, routing जैसे स्पष्ट control patterns का उपयोग करना चाहिए
- हर वह स्थिति जहाँ stability और predictability महत्वपूर्ण है
- असामान्य उदाहरण: agent बिना context/memory के बार-बार ग़लत tool चुनता रहे, या delegation/coordination fail होने से पूरी flow टूट जाए
- व्यावहारिक काम में अक्सर दिखने वाले agent systems के failure factors
- explicit memory system डिज़ाइन न होने से context छूट जाना
- tool selection constraints की कमी (अनावश्यक/ग़लत tools का उपयोग)
- बहुत ढीली delegation structure पर निर्भर रहने से collaboration/coordination का विफल होना
व्यावहारिक system design के लिए सबक
- agent अपनाने पर भी “उच्च-गुणवत्ता वाले software system” के स्तर की design, observability, और control व्यवस्था अनिवार्य है
- जटिल agent frameworks के बजाय, observability, स्पष्ट evaluation loops, और सीधे नियंत्रित की जा सकने वाली संरचना के साथ डिज़ाइन करना ज़्यादा तेज़ और सुरक्षित है
निष्कर्ष (TL;DR)
- agents को अक्सर ज़रूरत से ज़्यादा महत्व दिया जाता है या उनका अति-उपयोग होता है
- ज़्यादातर वास्तविक कार्यों के लिए simple workflow patterns ज़्यादा उपयुक्त हैं
- agents की असली ताकत “जहाँ इंसान सीधे शामिल हो” ऐसे environments में दिखती है
- स्थिर systems में वे उलटे जोखिम पैदा कर सकते हैं
- systems को observability, explicit control, और iterative evaluation structure के साथ डिज़ाइन करें
- जटिल agent frameworks की जगह, observability, स्पष्ट evaluation loops, और सीधे नियंत्रित की जा सकने वाली संरचना के साथ डिज़ाइन करना ही वास्तव में तेज़ और सुरक्षित LLM-आधारित services बनाने की कुंजी है
6 टिप्पणियां
एक महीने पहले CURSOR का उपयोग करके AI coding क्या है यह सीखने के लिए मैंने एक development framework बनाना शुरू किया।
करीब 3 हफ्तों तक, सफलता और AI Agent द्वारा validate किया गया source code बार-बार टूटता रहा, और मैंने हर संभव तरीका अपनाकर AI Agent को नियंत्रित करने की कोशिश की, लेकिन असफल रहा।
फिर मुझे एहसास हुआ कि development framework बनाने से पहले AI Agent को नियंत्रित करने वाला source code विकसित करना प्राथमिकता है।
आखिरकार, पहला AI क्या है यह समझने के लिए शुरुआत करने के ठीक एक महीने के भीतर, मैंने ऐसा software पूरी तरह विकसित कर लिया जो AI द्वारा 100% implement और 100% operate किया जा सकता है — या अधिक सटीक रूप से कहें तो जिसमें external LLM या AI Agent की आवश्यकता ही नहीं है।
अब 14वें दिन पर, अतिरिक्त उन्नयन के लिए मैं उस META AI को आगे train कर रहा हूँ और उसके लिए operation rules बनाकर उनका पालन करवाने की प्रक्रिया चला रहा हूँ। साथ ही, लोगों द्वारा पहले अपूर्ण रूप से बनाए गए 3 MES systems का एक साथ migration, improvement और standardization चल रहा है, और यह अब समापन चरण में है।
और अब मैं एक और evolution की तैयारी कर रहा हूँ।
लेकिन क्या prompt chaining में individual prompts चलाने वाले LLM, execution worker, orchestrator worker, evaluator LLM वगैरह को अलग-अलग agent कहना भी ठीक नहीं होगा?
आह, तो "अंतिम workflow control (जब LLM सीधे तय करता है कि अगला कदम क्या होगा या टूल का इस्तेमाल करना है या नहीं, इसे agentic विशेषता कहा जाता है)" जैसी बात है। समझ गया। यह autonomous agent को target करके लिखी गई पोस्ट थी। मुझे अभी agent के बारे में ज़्यादा जानकारी नहीं है, इसलिए...
Hacker News राय
https://github.com/astronomer/airflow-ai-sdk
मैं भी अभी
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 हैं, लेकिन जवाब बहुत लंबा हो जाएगा इसलिए अभी यहीं तक लिखता हूँ.
उम्मीद है यह किसी के काम आएगा.
अपना बहुमूल्य अनुभव और विचार साझा करने के लिए आपका बहुत-बहुत धन्यवाद। इस तरह मैदान में काम कर रहे व्यक्ति की राय वास्तव में बहुत मददगार होती है।