स्वायत्त एजेंट्स के "hype" और उन AI एजेंट्स में अंतर जो वास्तव में production में काम करते हैं

 (utkarshkanwat.com)
4 पॉइंट द्वारा GN⁺ 2025-07-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 2025 में AI एजेंट बूम आने की उम्मीदों के बावजूद, वास्तविक production environment में व्यावहारिक सीमाएँ मौजूद हैं
  • error accumulation और token cost की समस्या के कारण, multi-step workflow को पूरी तरह automate करना फिलहाल संभव नहीं है
  • अधिकांश सफल agent systems में सख्ती से सीमित domain और human approval या verification process अनिवार्य होते हैं
  • असली मुश्किल AI की performance नहीं, बल्कि ऐसे tools और feedback systems का design है जिन्हें agent प्रभावी ढंग से इस्तेमाल कर सके
  • 2025 में fully autonomous agents को सामने रखकर चलने वाले startup/companies को वास्तविक adoption और scaling के दौरान बड़ी बाधाओं का सामना करना पड़ने की संभावना है

मैं क्यों शर्त लगा रहा हूँ कि 2025 में AI एजेंट्स नहीं आएँगे (हालाँकि मैं खुद AI एजेंट्स बना रहा हूँ)

  • 2025 को AI एजेंट्स का साल बताने वाला hype हर जगह फैला हुआ है
  • लेखक ने पिछले एक साल में वास्तविक production environment में चलने वाले विभिन्न AI agent systems खुद बनाकर देखे हैं
  • इसी सीधे practical experience के आधार पर, लेखक बाजार में चल रही "agent revolution" को लेकर संशयवादी रुख रखता है

विभिन्न agent systems बनाने का अनुभव

  • development agents: natural language से React components बनाना, legacy code refactoring, API documentation का automated management, specs के आधार पर function generation आदि
  • data & infrastructure agents: complex queries और migrations संभालना, multi-cloud DevOps automation
  • quality & process agents: lint auto-fixes, test code generation, code review और detailed Pull Request automation
  • ये systems वास्तविक value देते हैं और समय बचाते हैं, लेकिन यही अनुभव hype पर आलोचनात्मक नज़र का आधार भी है

मुख्य सार: AI एजेंट्स के बारे में तीन कठोर सच

  1. error rate accumulation: steps बढ़ने पर success rate geometrically गिरता है। production standard (99.9%+) पूरा करना कठिन है
  2. context window और cost: बातचीत लंबी होने पर token cost घातांकीय रूप से बढ़ती है, जिससे economic viability टूट जाती है
  3. tools और feedback design की कठिनाई: सबसे बड़ी चुनौती model की तकनीकी सीमा नहीं, बल्कि agent के उपयोग योग्य tools और feedback systems का design है

error accumulation की गणितीय वास्तविकता

  • multi-step autonomous workflows error accumulation की वजह से वास्तविक operational scale पर practically संभव नहीं हैं
  • उदाहरण के लिए, अगर हर step पर 95% reliability हो, तो 20 steps के बाद अंतिम success rate सिर्फ 36% रह जाती है (जबकि production की मांग: 99.9%+)
  • बहुत high reliability मान लेने पर भी, steps बढ़ने के साथ failure probability तेज़ी से बढ़ती है
  • व्यवहार में टीमें पूरे process को fully automate नहीं करतीं, बल्कि हर step पर independent validation और rollback points तथा human checks के साथ architecture बनाती हैं
  • सफल agent systems का pattern: स्पष्ट रूप से सीमित context, verifiable tasks, और महत्वपूर्ण बिंदुओं पर human decision-making

token cost structure और आर्थिक सीमाएँ

  • context window और conversation बनाए रखने की token cost, system scale होने पर अव्यावहारिक आर्थिक वास्तविकता बन जाती है
  • conversational agents को हर बार पूरी conversation history process करनी पड़ती है, इसलिए turns बढ़ने पर cost square की तरह तेज़ी से बढ़ती है
  • 100 rounds की बातचीत में केवल token cost ही 50~100 डॉलर तक पहुँच सकती है, और बड़े user base पर economics टूट जाती है
  • इसके उलट, stateless तरीके के single-slot, context-free function generation agents cost और scalability दोनों में बेहतर होते हैं
  • सबसे सफल production agents दरअसल "conversational" systems से ज़्यादा clear-purpose smart tools के करीब होते हैं

tool design और feedback systems की दीवार

  • high-productivity agents बनाने की असली चुनौती वह tool design capability है जिसे मौजूदा टीमें अक्सर कम आँकती हैं
  • tool calling की accuracy बेहतर हुई है, लेकिन complex state और results को प्रभावी ढंग से summarize करके agent को feedback देना ही असली कुंजी है
  • उदाहरण:
    • जब कोई task आंशिक रूप से सफल हो, तब कितनी जानकारी और किस तरह का summary चाहिए, यह तय करना पड़ता है
    • मान लीजिए query result में 10,000 rows हैं, तो "success, 10,000 rows, केवल पहली 5" जैसे abstraction की ज़रूरत होती है ताकि state समझी जा सके
    • tool failure होने पर recovery information की मात्रा नियंत्रित करनी होती है और context pollution से बचाना होता है
  • वास्तव में सफल database agents का core यह है: agent को ऐसा structured feedback देना जिस पर वह वास्तव में निर्णय ले सके
  • वास्तविक दुनिया में AI लगभग 30% काम करता है; बाकी 70% पारंपरिक engineering जैसे tool feedback, recovery, और context management में जाता है

वास्तविक system integration की सीमाएँ

  • reliability और cost की समस्या हल हो जाए, तब भी real-world integration एक अलग बड़ी दीवार बनकर सामने आती है
  • वास्तविक organizational systems consistent APIs नहीं होते; उनमें legacy behavior, exceptional errors, changing authentication, variable limits, compliance rules जैसी अनपेक्षित जटिलताएँ होती हैं
  • वास्तविक database agents में connection pool management, transaction rollback, read-only replicas का सम्मान, query timeout, logging आदि जैसे पारंपरिक programming कौशल अनिवार्य होते हैं
  • "AI पूरे stack को fully autonomously integrate कर देगा" जैसा वादा, वास्तविक implementation में जाकर वास्तविकता से टकरा जाता है

वास्तव में अच्छी तरह काम करने वाले patterns

  • सफल agent systems के साझा सिद्धांत
    1. UI generation agents: user experience की final review इंसान करता है (AI केवल natural language → React conversion की complexity संभालता है)
    2. database agents: destructive actions की पुष्टि हमेशा इंसान करता है (AI केवल SQL transformation करता है, data preservation control इंसान के पास रहता है)
    3. function generation agents: स्पष्ट specs के भीतर सीमित behavior (कोई state, side effects, या complex integration नहीं)
    4. DevOps automation: infrastructure code AI बनाता है, deployment/version control/recovery मौजूदा pipelines संभालती हैं
    5. CI/CD agents: हर step स्पष्ट success criteria और rollback mechanism के साथ design किया जाता है
  • pattern summary: AI complexity संभालता है, इंसान control बनाए रखता है, और reliability पारंपरिक engineering सुनिश्चित करती है

market outlook और पूर्वानुमान

  • fully autonomous agents पर ज़ोर देने वाले venture startups सबसे पहले profitability की समस्या से टकराएँगे
  • 5-step workflow में demo शानदार दिख सकता है, लेकिन वास्तविक enterprises 20+ steps माँगते हैं और वहाँ गणितीय सीमाएँ सामने आती हैं
  • जिन कंपनियों ने मौजूदा software में सिर्फ AI agents जोड़ दिए, वे practical integration की कमी के कारण adoption stagnation झेल सकती हैं
  • असल विजेता वे टीमें होंगी जो स्पष्ट रूप से सीमित domains में AI को केवल कठिन tasks पर लागू करें और महत्वपूर्ण निर्णयों पर human oversight व boundary conditions रखें
  • बाज़ार को "demo में अच्छा दिखने वाला AI" और "वास्तव में reliable AI" के बीच का अंतर महँगे अनुभव से सीखना पड़ेगा

बेहतर agent systems बनाने के सिद्धांत

  • स्पष्ट boundaries तय करें: agent की भूमिका और human/existing systems के बीच handoff points साफ़ परिभाषित करें
  • failure-first design: AI error होने पर rollback और recovery structure पहले से तैयार होना चाहिए
  • economics validate करें: per-interaction cost और scale-out structure का परीक्षण करें (stateful की तुलना में stateless अधिक किफायती है)
  • autonomy से पहले reliability: कभी-कभार जादू दिखाने वाले system की तुलना में लगातार सही काम करने वाला system ज्यादा भरोसा बनाता है
  • मजबूत foundation पर निर्माण: केवल कठिन हिस्से (intent interpretation, generation आदि) AI को दें; बाकी (execution, error handling आदि) पारंपरिक software को सौंपें

वास्तविक अनुभव से मिला असली सबक

  • "demo में काम करना" और "वास्तविक बड़े पैमाने पर production में काम करना" — इन दोनों के बीच बहुत बड़ा अंतर है
  • agent reliability, cost optimization, और integration complexity जैसी समस्याएँ अब भी पूरे industry में अनसुलझी मुख्य चुनौतियाँ हैं
  • वास्तविक implementation experience और ईमानदार अनुभव-साझा करना industry की प्रगति की कुंजी है
  • जितने अधिक practitioners व्यावहारिक methodologies और वास्तविक failure cases पर चर्चा करेंगे, उतनी ही सामूहिक सफलता की संभावना बढ़ेगी

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-07-21
Hacker News राय

  • Amazon के एक AI प्रोडक्शन इंजीनियर से बातचीत का अनुभव है; उनके अनुसार अभी कोई भी कंपनी ऐसी नहीं है जो ग्राहकों से सीधे बात करने वाली जगहों पर सिर्फ generative AI का इस्तेमाल करती हो। सारे ऑटो-रिस्पॉन्स अब भी पुराने non-generative "legacy" तकनीक पर चलते हैं, क्योंकि generative AI की reliability समस्या इतनी बड़ी है कि उस पर कंपनी की प्रतिष्ठा दांव पर नहीं लगाई जा सकती।

    • पहले मेरी दिलचस्पी ऐसे एजेंट्स में थी जो "legacy AI" symbolic techniques और traditional machine learning को मिलाते थे, लेकिन काम ज़्यादातर pre-transformer neural networks पर हुआ। आखिरकार हमेशा पहले human-in-the-loop सिस्टम बनाया जाता था, उसी से evaluation और training data इकट्ठा किया जाता था, और फिर सिस्टम काम का कुछ हिस्सा संभालकर बाकी की quality भी बेहतर करता था। खासकर 'subjective' कामों में symbolic systems का मूल्यांकन ज़रूर करना चाहिए। अगर सिस्टम को train करना है, तो evaluation से बचा नहीं जा सकता।

    • वास्तव में कई tech कंपनियां पहले से generative AI को real-time chatbot customer support में ला रही हैं। मुझे Sonder और Wealthsimple जैसे उदाहरण पता हैं। अगर LLM query का जवाब नहीं दे पाता, तो बातचीत तुरंत human agent को सौंप दी जाती है।

  • एक बात जिस पर अभी तक चर्चा नहीं हुई, वह है context window। इंसान किसी विशेषज्ञ क्षेत्र में लगभग "लगभग अनंत" जैसा context संभाल सकता है। मॉडल बड़े और विविध training data से कुछ हद तक इस सीमा को पार कर सकते हैं, लेकिन मुझे नहीं लगता कि वही असली समाधान है। अभी लोगों को अपना context compress करके prompt में भरना पड़ता है, इसलिए English जैसी लचीली भाषा में यह engineering से ज़्यादा कोई जादुई मंत्र याद करने या अंदाज़ा लगाने जैसा लगता है। deterministic तरीके की जगह ऐसा महसूस होता है कि डेटा का बड़ा हिस्सा खो रहा है।

    • इंसानों में "context" और "weights" इस तरह स्थिर और अलग-अलग नहीं बंटे होते। समय के साथ अनुभव और परिणाम मेरे "weights" को ही लगातार बदलते रहते हैं, लेकिन LLM में architecture के हिसाब से weights read-only होते हैं, इसलिए यह संभव नहीं।

    • मुझे संदेह है कि क्या इंसानों के पास सचमुच इतना विशाल context window होता है। जटिल समस्या-समाधान के दौरान मैं अक्सर इंसानी "context window" की अपनी सीमाओं से टकराता हूं। जानना चाहूंगा कि क्या इसके वास्तविक उदाहरण हैं।

  • AI tools के साथ मेरा अनुभव कुल मिलाकर सकारात्मक रहा है। जब मुझे ब्रेक चाहिए होता है, तब छोटे-मोटे काम सौंपने में, या काम को organize और शुरू कराने में यह बहुत मददगार होता है। लेकिन cost की समस्या जल्दी सामने आती है। उदाहरण के लिए, बड़े codebase पर Claude Code चलाने में 1–2 घंटे में लगभग $25 लग जाते हैं। अगर automated review भी जोड़ दें तो यह $50/hr तक पहुंच जाता है। यानी speed, accuracy, cost का trade-off है। आजकल जो Agents आ रहे हैं, उनमें भी इस triangle में उनकी जगह अभी साफ नहीं है, इसलिए बहुत से प्रयोग दिलचस्प हैं, लेकिन मुझे अब भी उनमें risk दिखता है।

    • थोड़ा cynical होकर देखें तो LLM का लगातार खुद को re-prompt करके error ठीक करना, और "RAG की ज़रूरत नहीं! बस 1m token context window में सारा code ठूंस दो" वाला approach आखिरकार 'per-token billing' बिजनेस मॉडल के लिए एकदम सही फ्रेम बन जाता है।

    • इन दिनों जिस विचार पर सोच रहा हूं, वह यह है कि AI शुरुआत से ही कई commit drafts बना दे, और फिर इंसान उन्हें सीधे या automated तरीके से filter करके हाथ से refine करे। काम जितना बड़ा होता है, शुरुआती छोटी गड़बड़ी के पूरे नतीजे को खराब कर देने की संभावना उतनी बढ़ जाती है। इसलिए मौजूदा SOTA में भी अगर agents को कई विकल्प parallel में आज़माने दिए जाएं, तो manual refactoring में लगने वाला समय घटता है। इस प्रक्रिया पर मैंने GitHub पर एक पोस्ट लिखी थी।

    • पूछना चाहता हूं, क्या यह subscription service है?

  • इंसानी multi-step workflow में आमतौर पर validation checkpoints होते हैं, क्योंकि इंसान भी 99% से ज़्यादा accurate नहीं होते। आगे चलकर agents को भी outputs पर validation process डिज़ाइन करके, अगला step लेने से पहले उससे गुजरने के लिए train किया जाएगा। पहले से risk assessment भी हो सकती है, जैसे "यह हिस्सा कम-से-कम 99% accurate होना चाहिए"।

    • Claude Code हर बार काम आगे बढ़ाने से पहले रुककर user से पूछता है कि आगे बढ़ना है या नहीं, और proposed changes भी पहले दिखाता है। यह token की बर्बादी और बेअसर काम को रोकने में असरदार है।

    • कई applications को भी इस ढांचे के हिसाब से फिर से redesign करने की ज़रूरत होगी। मुझे लगता है कि microservices architecture की LLM के साथ अच्छी बनती है, इसलिए वह फिर से लोकप्रिय हो सकती है।

  • मैं इस बात से सहमत हूं कि "असल समस्या AI की क्षमता नहीं, बल्कि ऐसे tools और feedback systems को डिज़ाइन करना है जिन्हें agents सचमुच प्रभावी ढंग से इस्तेमाल कर सकें।" बाज़ार इसे कैसे लेगा, इस पर यक़ीन नहीं था, इसलिए पहले सिर्फ देख रहा था, लेकिन बाद में agents बनाने में विशेषज्ञ एक बहुत छोटे startup से जुड़ गया। पांच महीने में मेरा रुख़ skeptical → supportive → convinced हो गया। अगर विषय-क्षेत्र बहुत संकरा रखा जाए और tooling पर ध्यान दिया जाए ताकि मॉडल काम कर सके, तो completion rate काफ़ी ऊंचा मिलता है। लोगों को non-deterministic प्रकृति पसंद नहीं आती, लेकिन बेहतरीन tooling और लगातार संकरे scope के साथ यह व्यवहारिक रूप से काफ़ी उपयोगी बन सकता है। tooling खुद कठिन लगती है, लेकिन मुझे लगता है इसे ठीक-ठाक हल किया जा सकता है। मैं भविष्य को लेकर आशावादी हूं।

  • मुझे लगता है कि ये सब सुलझाए जा सकने वाले engineering problems हैं। बस तेज़ी से ARR हासिल करने की दौड़ में बहुत से startups इन पर ध्यान नहीं दे रहे। यह कहना कुछ हद तक सही है कि agents अपने वादों जितने उपयोगी नहीं हैं, लेकिन असल में यह engineering problem है। दूसरे नज़रिए से जाएं तो यह काम करेगा—व्यक्तिगत रूप से मैं RL वाले दृष्टिकोण के पक्ष में हूं। उदाहरण के लिए, एक अच्छा verifier चाहिए। कई कामों में खुद काम करने की तुलना में verification आसान होती है। अगर 80% accuracy वाले 5 parallel outputs हों, तो 99.96% संभावना है कि उनमें से कम-से-कम एक सही होगा, और verifier उसे चुन सकता है। multi-step स्थिति में भी यह गणितीय रूप से फायदेमंद हो जाता है। यह अब तक के तरीकों से अलग approach है। लेख में भी 3–5 step workflow paradigm की बात है, और वह वास्तव में ठीक बैठती है। आगे ऐसे मॉडल और आने चाहिए।

    • मेरा मानना है कि बहुत से कामों में verification वास्तव में खुद काम से भी मुश्किल होती है। खासकर software QA में इसी तर्क पर कई बार restructuring हुई है और नतीजे में quality गिरती दिखी है। verifier मुश्किल इसलिए हो जाता है क्योंकि system और बाहरी दुनिया की संभावित states के combinations geometric तरीके से बढ़ते जाते हैं। LLM ऐसे जटिल कार्य-परिवेश में dependencies को mock करना या data को पहले से भरना जैसी दोहराव वाली मेहनत के लिए आकर्षक हैं, लेकिन meaningful verification tests के लिए अक्सर 100% accuracy की मांग जुड़ जाती है, और फिर हर precondition के लिए अलग verifier चाहिए होता है। अगर अंत में हर step को 100% होना ही पड़े, तो cumulative probability घटती जाती है। इंसान भी आमतौर पर case-by-case सावधानी से test करते हैं; वे हर संभव स्थिति की पूरी verification नहीं करते। white-box testing, black-box से कहीं ज़्यादा आम है। अगर LLM बहुत सारा code बनाए, तो white-box verification के लिए worker को पूरा code समझना ही पड़ेगा, और तब बचाया गया समय फिर कम हो जाता है। अभी तो स्थिति यह है कि LLM बनाता है और errors भी मुझे ही ठीक करने पड़ते हैं, इसलिए confidence और घटता है और समय भी ज़्यादा लगता है। कुछ हालात में interface को LLM की अपेक्षाओं के हिसाब से ढालकर इसे संभाला जा सकता है, लेकिन यह universal नहीं है। software के बाहर तो कई बार verification संभव ही नहीं होती, जैसे "सबसे promising game startups में से 5 चुनो"—यह objective verification के बाहर है। ऐसे क्षेत्र भी अगर आंख मूंदकर मशीन को दे दिए जाएं, तो हालात संभलना मुश्किल हो जाएगा।

    • क्या यह मान लेना ठीक है कि पांचों generations एक-दूसरे से independent होंगी?

    • सही बात है। कई agents को कोशिश करने देना, बार-बार दोहराना, और अलग-अलग solutions लागू करना व्यवहारिक रूप से असरदार है। मैंने खुद ऐसे मामले देखे हैं जहां एक approach को negative feedback मिला लेकिन दूसरे approach से सफलता मिली।

  • यह थोड़ा हैरान करने वाला है कि एक व्यक्ति, या बहुत छोटी टीम, development, DevOps, data operations वगैरह में production में चल रहे 12 से ज़्यादा AI agents बना चुकी है। startup failure rate देखें तो "एक" अच्छा product बनाना ही कठिन है, ऐसे में 12 बनाना चौंकाता है। हम भी Definite जैसे data stack + AI agent tool पर 2 साल लगे रहने के बाद ही लगभग 6 महीने पहले जाकर कुछ ठीक स्थिति में पहुंचे हैं। Definite

    • दरअसल इसका मतलब 12 independent products नहीं, बल्कि काम की ज़रूरत के हिसाब से workplace में इस्तेमाल होने वाले बहुत specific-purpose tools के 12 टुकड़े हैं। पूरे लेख का विषय भी यही है कि उपयोगी agents के लिए बेहद simple और स्पष्ट उद्देश्य पर ही ध्यान देना चाहिए।

    • full-time नौकरी करते हुए 3 साल में 12 से ज़्यादा बना लेना कुछ अटपटा लगता है।

  • agent/AI automation बनाना ही मेरा पेशा है। open-ended coding agents सीधी-सी बात में बेवकूफी भरा विचार हैं। human validation checkpoints, छोटा search space, और बहुत specific सवाल/prompts—जैसे "क्या इस email में invoice है YES/NO"—यही यथार्थवादी है। पूरी तरह autonomous agent चाहने की इच्छा समझ में आती है, लेकिन तकनीक अभी वहां नहीं पहुंची। मैं content generation—text, image, code—में हाथ नहीं डालता। वह अंत में नुकसान ही करेगी।

    • मैं भी agent frameworks के साथ chat coding का इस्तेमाल करके अपने workload का लगभग 50% घटा पाया हूं। GPT से मुझे असली फायदा मिला है। लेकिन 10 में 1 बार गलती ज़रूर होती है। मेरा मानना है कि जब तक LLM architecture में बुनियादी बदलाव नहीं होगा, यह error rate नहीं सुधरेगी। अभी hype के कारण developers का trust टूटने का खतरा है, लेकिन अगर ऐसा नहीं हुआ, तो मुझे यक़ीन है कि आगे कहीं ज़्यादा robust systems आएंगे। productivity improvement इतनी स्पष्ट है कि अब team hiring पहले की तुलना में बहुत कम करनी पड़ सकती है। अलग-अलग विषयों की learning curve भी काफ़ी घट गई है, क्योंकि Google search की गिरती quality की कमी LLM पूरी कर देते हैं। automated workflows में इंसानी काम का कुछ हिस्सा LLM को सौंपने वाला orchestration framework सबसे महत्वपूर्ण संरचना है। LLM अपनी confidence भी बताए, और confidence % कम हो तो काम तुरंत इंसान को handoff हो जाए। अगर testing, guardrails वगैरह सही हों, तो non-core tasks से शुरुआत करके इंसानी काम का अच्छा-खासा हिस्सा automate किया जा सकता है। लक्ष्य लोगों को replace करना नहीं, बल्कि automation से team size कम करना है। उदाहरण के तौर पर, बड़े e-commerce में product description, image validation, typos, image mismatch जैसी चीज़ें जो अभी इंसान करते हैं, मुझे यक़ीन है कि LLM उन्हें संभालेंगे।

    • कुल मिलाकर सहमत हूं, लेकिन इस तरह जाएं तो बचा-खुचा नतीजा शायद "बस एक महंगा workflow system" ही रह जाए। तब सवाल उठता है कि जो काम पुरानी तकनीक से हो सकता था, उसके लिए LLM की ज़रूरत क्या है?

    • मैं भी सहमत हूं। अभी के लिए agents का सबसे सही उपयोग "narrow scope, low risk, highly repetitive boring work" है। उदाहरण के तौर पर, dev-log markdown सहायक काम में agent इस्तेमाल करने का अनुभव मैंने यहां लिखा है।

    • यह सही है कि human validation checkpoints सबसे भरोसेमंद होते हैं, लेकिन unit tests और पूरे system की ad-hoc validation जैसे कई अतिरिक्त तरीके भी मौजूद हैं।

  • मुझे सच में लगता है कि लेखक को autonomous agents को लेकर अभी से भी ज़्यादा आशावादी होना चाहिए। आज जो चीज़ों का 90% किया जा रहा है, वह 2024 की शुरुआत में संभव ही नहीं था। प्रगति की रफ़्तार को कम करके नहीं आंकना चाहिए।

  • मैं भी यही सोचता हूं। इस पर एक ब्लॉग पोस्ट भी है। मुख्य फर्क यह है कि HITL(Human in the loop) से errors कम किए जा सकते हैं, जबकि HOTL(Human out of the loop) उल्टा समस्याएं पैदा करता है।