The Orchestration Tax

 (x.com/addyosmani)
2 पॉइंट द्वारा ragingwind 19 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें

AI एजेंट के दौर में ‘orchestration tax’ और मानवीय attention की bottleneck

Addy Osmani की यह पोस्ट इस समस्या पर बात करती है कि कई AI एजेंटों को एक साथ चलाना हमेशा सीधे-सीधे productivity बढ़ाने में नहीं बदलता। एजेंट parallel में काम कर सकते हैं, लेकिन उनके नतीजों को समझना, review करना और merge करना इंसानी judgment पर निर्भर रहता है, और उसे parallelize नहीं किया जा सकता। लेखक इस लागत को ‘orchestration tax’ कहते हैं। यानी कई workflows को coordinate करने की छिपी हुई लागत। delegation के नज़रिए से देखें तो, बात सिर्फ़ ज़्यादा काम सौंपने की नहीं है, बल्कि उतना ही सौंपने की है जितना आप ठीक से review कर सकें.

  • मुख्य तर्क

    • वे बताते हैं कि AI एजेंट शुरू करना आसान है, लेकिन उनके परिणामों को verify करना और उन्हें दूसरे बदलावों के साथ align करना आसान नहीं है।
    • कई एजेंट चलाने से “मेरे और ज़्यादा versions” पैदा नहीं हो जाते; judgment और merge आख़िरकार एक ही व्यक्ति की attention से होकर गुजरते हैं।
    • वे इशारा करते हैं कि व्यस्त महसूस करना और वास्तव में productive होना अलग बातें हो सकती हैं।
    • 20 एजेंट चलाने का मतलब यह नहीं कि आपके पास तुरंत 20 एजेंटों जितना deployable काम तैयार हो जाएगा।

  • orchestration tax

    • लेखक कई एजेंटों को coordinate करने की लागत को एक structural समस्या मानते हैं। यह केवल focus या training की कमी का मामला नहीं, बल्कि system design का मुद्दा है।
    • एजेंटों द्वारा बनाए गए outputs को अंततः इंसान को review करना ही पड़ता है। इस प्रक्रिया में accuracy, architecture consistency और merge conflicts जैसी समस्याएँ एक ही व्यक्ति पर आ टिकती हैं।
    • इसलिए AI एजेंट सिस्टम के भीतर इंसान एक धीमा serial component बन जाता है। serial component से मतलब सिस्टम का वह हिस्सा है जो कई काम एक साथ नहीं, बल्कि क्रम से संभालता है।

  • तकनीकी उपमा

    • लेखक इस स्थिति की तुलना Python के GIL से करते हैं। GIL ऐसा mechanism है जो कई threads होने पर भी एक समय में केवल एक thread को Python code चलाने देता है।
    • यानी एजेंट साथ-साथ चल सकते हैं, लेकिन जहाँ वास्तविक understanding और judgment की ज़रूरत होती है, वहाँ सबको इंसानी attention नाम के एक ही lock का इंतज़ार करना पड़ता है।
    • वे performance engineering के उस सिद्धांत का भी ज़िक्र करते हैं कि parallel processing से मिलने वाली speedup, उस हिस्से से सीमित होती है जिसे parallelize नहीं किया जा सकता। इसलिए एजेंट बढ़ाने पर भी अगर judgment time कम नहीं होता, तो कुल throughput को बहुत बढ़ाना मुश्किल है।

  • फायदे

    • एजेंट background में independent tasks संभालने के लिए उपयोगी हो सकते हैं।
    • test लिखना या screen captures बनाना जैसे काम, जिन्हें मशीन कुछ हद तक verify कर सकती है, इंसान का बोझ कम कर सकते हैं।
    • वे सुझाव देते हैं कि अगर result review को batch में किया जाए, तो अलग-अलग कामों के बीच बार-बार context switch करने की लागत कम हो सकती है।

  • सीमाएँ और जोखिम

    • एजेंटों की संख्या बढ़ाने से इंसान की cognitive bandwidth — यानी समझने और judgment लेने की क्षमता — नहीं बढ़ती।
    • अगर आप एजेंटों को बार-बार check करते हैं, तो हर बार अलग task context फिर से लोड करना पड़ता है, जिससे थकान बढ़ सकती है।
    • वे चेतावनी देते हैं कि अगर review सतही हो जाए, तो एजेंट द्वारा बनाया गया code बिना पूरी तरह समझे स्वीकार किया जा सकता है।
    • अगर इस लागत को सही तरह manage न किया जाए, तो technical debt और cognitive debt दोनों साथ जमा हो सकते हैं। technical debt का मतलब बाद में ठीक करने में कठिन code-related बोझ है, जबकि cognitive debt वह स्थिति है जहाँ developer system को पूरी तरह समझे बिना बदलाव जोड़ता जाता है।

  • अंतर

    • इस लेख का फोकस AI एजेंटों की अपनी performance पर नहीं, बल्कि इंसानी attention पर है।
    • वे कहते हैं कि productivity को एजेंट run count से नहीं, बल्कि उस काम की मात्रा से मापना चाहिए जो वास्तव में review, merge और deploy किया जा सके।
    • इसकी एक खास बात यह है कि इंसान को system के बाहर खड़े supervisor की तरह नहीं, बल्कि parallel system के भीतर मौजूद एक सीमित resource की तरह देखा गया है।

  • व्यावहारिक दिशा

    • वे सुझाव देते हैं कि एजेंटों का scale tool UI जितने एजेंट दिखा सकता है उससे नहीं, बल्कि उस speed से तय होना चाहिए जिस पर आप उन्हें ठीक से review कर सकते हैं।
    • काम को बाँटना ज़रूरी है। isolated tasks को background agents को दें, लेकिन strange bugs या architecture design जैसे judgment-heavy कामों को parallelize न करना बेहतर हो सकता है।
    • इंसानी attention को judgment के लिए बचाना चाहिए, और जिन हिस्सों को मशीन verify कर सकती है, वहाँ एजेंट पहले test या evidence दिखाएँ।
    • delegation का मतलब भी यहाँ सीमित है। ज़्यादा काम सौंपने की क्षमता से ज़्यादा अहम यह है कि आप किन कामों को सौंप सकते हैं और किन्हें खुद judge करना चाहिए।

यह लेख बताता है कि AI एजेंटों के उपयोग में bottleneck execution नहीं, बल्कि review और judgment की क्षमता हो सकती है। कई एजेंटों को चलाना अब आसान हो गया है, लेकिन उनके नतीजों को ज़िम्मेदारी से स्वीकार करना अब भी इंसान का काम है। इसलिए productivity एजेंटों की संख्या बढ़ाने से नहीं, बल्कि अपनी attention को एक महत्वपूर्ण system resource मानकर उसी हिसाब से काम व्यवस्थित करने से आती है। delegation भी इसी सिद्धांत के भीतर आता है। असली बात ज़्यादा काम सौंपने की नहीं, बल्कि उतना ही सौंपने की है जितने पर आप सही judgment दे सकें।

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

2 टिप्पणियां

 
jjpark78 16 시간 전

मुझे भी आजकल यही महसूस हो रहा है—जब मैं एक साथ 10-20 काम चला कर लौटता हूँ और फिर उन्हें एक-एक करके review करता हूँ, तो context switch ठीक से नहीं हो पाता, और ऐसा होता है कि यह क्या था?? कहते हुए याददाश्त को फिर से खंगालना पड़ता है..
 
j2sus91 13 시간 전

अगर इसे serial काम के रूप में किया जाए, तो मानव verification और review अनिवार्य रूप से bottleneck बन जाते हैं.

आखिरकार workflow को agent parallel processing की ओर शिफ्ट होना ही होगा,
लेकिन मानव की cognitive क्षमता की अपनी सीमाएँ हैं.

आखिरकार ऐसा लगता है कि verification loop बनाना quality और incident prevention की कुंजी बनने वाला दौर आ गया है.
यह भी सही है कि मानव verification ज़रूरी है, लेकिन agents के बीच mutual checks के ज़रिए verification चरण को और मज़बूत बनाना होगा.