Agents को अधिक prompts नहीं, बल्कि control flow की ज़रूरत है

 (bsuh.bearblog.dev)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • जटिल कार्यों को भरोसेमंद तरीके से संभालने वाले agents को अधिक परिष्कृत prompt chain नहीं, बल्कि software में encoded deterministic control flow की ज़रूरत होती है
  • अगर आप prompt में MANDATORY या DO NOT SKIP जैसे वाक्यांशों पर निर्भर हैं, तो आप prompting की सीमा तक पहुँच चुके हैं
  • अगर आप ऐसी programming language की कल्पना करें जिसमें वाक्य सुझाव की तरह काम करें और functions hallucinate करते हुए “Success” लौटाएँ, तो जटिलता बढ़ने के साथ reasoning असंभव हो जाती है और reliability टूट जाती है
  • software, libraries, modules और functions से बनी recursive composability के ज़रिए scale करता है, और क्योंकि यह predictable behavior देता है, इसलिए local reasoning संभव होती है
  • prompt chain संकीर्ण कार्यों के लिए उपयोगी है, लेकिन यह non-deterministic, weakly specified और validate करना कठिन होती है, इसलिए इसमें वही गुण नहीं होते

एजेंट विश्वसनीयता के लिए आवश्यक संरचना

  • reliability सुनिश्चित करने के लिए logic को natural language description से निकालकर runtime में ले जाना होगा
  • आवश्यक संरचना एक deterministic scaffold है, जो LLM को पूरे system के रूप में नहीं बल्कि एक component के रूप में संभालती है
  • इस scaffold में explicit state transitions और validation checkpoints शामिल होने चाहिए
  • केवल deterministic orchestration पर्याप्त नहीं है; जो systems चुपचाप fail हो सकते हैं, उनमें aggressive error detection की ज़रूरत होती है
  • programmatic validation के बिना विकल्प तीन तक सिमट जाते हैं

    • निगरानीकर्ता(Babysitter)

      • इंसान को loop के अंदर रहकर errors को फैलने से पहले पकड़ना होगा

    • लेखापरीक्षक(Auditor)

      • execution खत्म होने के बाद पूरे result की कड़ाई से जाँच करनी होगी

    • प्रार्थना(Prayer)

      • परिणाम को माहौल के आधार पर स्वीकार कर लेने के तरीके पर निर्भर होना पड़ता है

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News टिप्पणियाँ

  • 1000% सहमत। Anthropic बार-बार जो यह ढोल पीटता है कि “भविष्य के मॉडल के प्रदर्शन को ध्यान में रखकर बनाओ, वे जल्द ही बेहतर हो जाएंगे”, उस पर भरोसा करना अब लगातार कठिन होता जा रहा है
    मैंने browser session में 200 requirements Markdown files खंगालने वाला एक QA agent बनाया था, और वह टीम की efficiency काफी बढ़ाने वाला अच्छा सिस्टम था। लेकिन जब “इस directory की requirements files देखो, और हर file के लिए app उन requirements को पूरा करता है या नहीं, इसकी जाँच करने वाले todo items बनाओ” जैसा high-level control flow मॉडल पर छोड़ा, तो लगभग 30 files के बाद यह बिखरने लगा
    कभी files छूट जाती थीं, कभी कुछ file groups को तीन-तीन बार test करके 3 मिनट के काम को 10 मिनट का बना देता था, और कभी एक file की गलती की वजह से उससे पहले की 4 files को बिना कारण फिर से test करने लगता था। Opus 4.6 और GPT 5.4, और हल्के तौर पर देखे गए Opus 4.7 और GPT 5.5 में भी workflow orchestration की क्षमता consistent नहीं थी
    आखिरकार मैंने मॉडल के आसपास एक बहुत simple deterministic harness बनाया, जिसमें हर test case के लिए मॉडल को call करके test चलाया, result को array में store किया और फिर file में लिखवाया; इससे सिस्टम की reliability बेहद बेहतर हो गई। लेकिन Cursor Cloud Agents या Anthropic जैसे managed agent platforms शायद “सब कुछ agent ही चलाए” वाले विचार में इतने फँसे हैं कि सही जगह थोड़ी determinism डालने की अहमियत उन्हें दिखती ही नहीं

    • पहले मुझे लगता था कि वे लोगों को prompt-only workflows में इसलिए धकेलते हैं क्योंकि token cost का पैसा तो मिलता है, लेकिन user द्वारा बनाए गए scaffolding से नहीं। अब लगता है कि शायद वे इस बात से डरते हैं कि ऐसे scaffolding को किसी को design और implement करना पड़ेगा
      क्योंकि इससे इस दावे पर पानी फिरता है कि यह तकनीक पूरे इंसान, पूरे workflow या पूरे project को replace कर देगी। मेरा मानना है कि यह productivity बहुत बढ़ाकर developer hiring market और wages पर विनाशकारी असर डाल सकती है, लेकिन इस तकनीक का मौजूदा version उनके बताए स्तर तक पहुँचेगा, ऐसा नहीं लगता। अगर इसे “मानव developer teams के बहुत-से झंझट वाले काम कम करने वाला बेहद उपयोगी tool” कहकर position किया जाता, तो developers इसे चाहते, executives कम चाहते, और investors भी शायद इसे यूँ ही न छोड़ते
      साथ ही, बारीकी से और कड़े नियंत्रण वाले stages, test automation या CSI fanfic के 5 खंड फटाफट लिख देने वाले बड़े models की बजाय, छोटे, सस्ते और specialized models जोड़ने के लिए कहीं अधिक अनुकूल हैं
    • यह शायद मॉडलों को evaluate करने के benchmarking तरीकों से भी आता हो
      कुछ benchmarks क्या ऐसा नहीं करते कि एक ही problem पर कई बार कोशिश करने देते हैं, फिर failure rate को नज़रअंदाज़ करके यदि एक बार भी success मिले तो वही result अपना लेते हैं?
    • सहमत। ऐसे सिस्टम को reliable बनाने का एकमात्र तरीका problem को छोटे हिस्सों में तोड़ना है। Internal consistency checks भी आखिर यही दिखाते हैं कि LLM हमारी उम्मीद से कहीं कम consistent है
    • apply_patch जैसे tool के साथ check_compilation और run_unit_tests को जोड़ने के बाद performance बहुत बेहतर हो गई। Tool का नाम अब भी apply_patch है, लेकिन अब patch सफल होने पर वह build और tests की अतिरिक्त जानकारी भी लौटाता है
      Agent की success rate लगभग 80% से बढ़कर अभी तक तो लगभग deterministic दिखने वाले स्तर तक पहुँच गई है। अब prompt में compilation और unit test process को अलग से समझाने की ज़रूरत नहीं, बस उसे dependencies के साथ चलाकर result लौटाना होता है
      आजकल जो trend चल रहा है, उससे मैं खुद को थोड़ा दूर जाता महसूस करता हूँ। मैं बहुत पहले से prepaid tokens और custom harnesses इस्तेमाल कर रहा हूँ, और वे बस अच्छे से काम करते हैं। ज़्यादातर news को नज़रअंदाज़ किया जा सकता है। जिन problems को explicit target किया गया है, उनमें Copilot-जैसे tools अब ज़्यादा उपयोगी नहीं लगते, और कुछ codebases में तो वही GPT 5.4 आधारित model होने के बावजूद performance का स्तर ही बिल्कुल अलग है
    • राज़ यह है कि उस orchestration prompt को “compile” किया जाए। Prompt को code में बदल दो, फिर वह code agent को चला सकता है, code execute कर सकता है, या दोनों कर सकता है, और इससे determinism की समस्या हल हो जाती है
      सब लोग skills में इस pattern को miss कर रहे हैं। अगर SKILL.md के साथ code भी रखो, तो specific behavior guarantee कर सकते हो, लेकिन अजीब तरह से सब prompt-writing के नशे में हैं। CLI बनाने की भी ज़रूरत नहीं, काम वाला एक simple skill.py काफी है। claude -p को call करने वाला helper भी रखा जा सकता है

  • यह मज़ेदार होगा अगर कुछ साल बाद भी लोग LLM इस्तेमाल करें, लेकिन आखिरकार केवल ऐसे controlled vocabulary और grammar के ज़रिए जिन्हें उन्हें सीखना पड़े। कुछ वैसा ही जैसे 15 साल पहले सब NoSQL की तरफ गए और फिर तुरंत JSON के अंदर schema दोबारा बनाने लगे

  • मुझे लगता है समस्या का एक हिस्सा यह भी हो सकता है कि शुरू से ही LLM को गलत तरीके से लगाया गया। जैसा और जगहों पर भी कहा गया है, agent का prompt शायद यह होना चाहिए कि ऐसा code लिखो जो काम को यथासंभव repeatable, verifiable और deterministic तरीके से करे
    Agent output validation भी इसमें शामिल होनी चाहिए। कुल लक्ष्य यह है कि जिन tasks को programs अधिक कुशलता से और अक्सर अधिक सही तरीके से संभाल सकते हैं, उनमें से LLM को हटाया जाए

    • 100% सहमत। 90% सही non-deterministic tool का उपयोग करके 100% सही deterministic tool बनवाना चाहिए। मैं prompt में जो एक जरूरी वाक्य ज़रूर डालता हूँ, वह है: “अगर कोई ambiguous edge case मिले, तो मुझसे पूछो”
      AI को production में लगाकर उससे सीधे API call के जरिए कुछ करवा देना बुरा विचार है। मेरे हिसाब से app में AI का एकमात्र सही उपयोग reading, classification जैसी चीज़ें हैं। यानी पुराने CRUD apps के “R” को replace करने जैसा
      उसी AI-आधारित “R” endpoint से prompt के अनुसार “C”, “U”, “D” forms को auto-fill कराना ठीक है, लेकिन मानव review से पहले ग्राहक के लिए कुछ बदलना नहीं चाहिए। CRUD apps अभी भी CRUD apps ही हैं और आगे भी रहेंगे; बस अब हमारे पास एक बहुत smart “R” endpoint है जो customers, internal tools या Jenkins pipelines वगैरह के लिए form autocomplete या action suggestions दे सकता है। वह actions suggest कर सकता है, लेकिन उन्हें खुद execute नहीं करना चाहिए
    • ज़्यादातर organizations में flow शायद llm -> prompt -> result, llm -> prompt + prompt encoded as skill -> result, llm -> prompt + deterministic code encoded as skill -> result की दिशा में जाता दिख रहा है
      शुरुआती code generation को prompt से करवाकर deterministic code तक पहुँचने का रास्ता छोटा किया जा सकता है, लेकिन तब भी आप non-deterministic wrapper के अंदर deterministic code ही रख रहे होते हैं। Long-running tasks को सफल बनाना हो तो कई बार जो missing layer होती है, वह determinism की होती है
      Agent loop या framework के ज़रिए non-deterministic boundary के बाहर deterministic code रखना पड़ता है। तब flow कुछ deterministic agent flow -> non-deterministic decision-making -> deterministic tools जैसा बनता है, जहाँ non-deterministic judgment determinism की परतों के बीच फँसी होती है। Experiments में यह बहुत शक्तिशाली pattern रहा है, और जब auto-researcher जैसे tools से agents खुद determinism बना लेते हैं, तो यह और ताकतवर हो जाता है
    • हमारा अनुभव भी यही रहा। शुरुआत में हमने agent को ऐसे tools की list दी थी जो data structures को खास तरीकों से manipulate कर सकते थे, लेकिन यह तरीका काफी fragile था
      अब हम एक छोटी domain-specific language और एक single tool इस्तेमाल करते हैं, और agent उस language में लिखी script को input के रूप में देता है। इससे ज़्यादा dynamic use cases संभाले जा सकते हैं, और गलत grammar parser आसानी से पकड़कर agent को वापस भेज सकता है
    • समस्या यह है कि programs अक्सर ऐसे edge cases से टकराते हैं जिनमें interpretation चाहिए होती है, और उसी क्षण मन करता है कि LLM से वह edge case संभलवाया जाए; फिर धीरे-धीरे पूरा loop और tool calls भी उसी पर छोड़ देने का मन होता है
    • अपने आख़िरी project में, hardware को control करने वाले server और mobile app के बीच interface library generation को automate करते समय मैंने यही किया
      Hardware control team docs और spreadsheets में specs देती थी, और mobile team उन्हें देखकर interface library code करती थी, फिर server के साथ validate करती थी। मैंने docs को TSV में बदला और उसका कुछ हिस्सा Claude को भेजकर ऐसा TSV parser लिखवाया जो मानव-लिखित specs की बारीकियाँ बनाए रख सके
      सारे edge cases संभालने और intermediate results को JSON में generate करने तक पहुँचने में 150 से ज़्यादा iterations लगे। उसके बाद Claude ने Apollo के ऊपर custom glue code जोड़कर mobile app के लिए code generate करने वाला code generator लिखने में मदद की
      यह पूरी pipeline Github Actions के हिस्से के रूप में चलती है, और Claude को सिर्फ तब call किया जाता है जब library validator fail हो। Failure की स्थिति में क्या गलत हुआ, यह समझने, समाधान सुझाने और PR बनाने के लिए request में एक md file शामिल होती है। उसके बाद इंसान review, edit और merge करता है। इस सब पर कुल credit cost 350 डॉलर से कम रही

  • मंशा से सहमत हूँ, लेकिन मुझे लगता है निष्कर्ष बदलना चाहिए। जब prompts की सीमा सामने आए, तो runtime पर LLM से task करवाने की बजाय वह software LLM से लिखवाना चाहिए जो task करेगा
    Runtime पर LLM की भूमिका अक्सर बस इतनी रह जाएगी कि वह user को ऐसे inputs चुनने में मदद करे जो कड़े business rules वाले software system में फिट हों

    • कंपनी में कुछ हफ्तों का समय मिला तो हमने note-taking, task tracking, document management जैसी business processes में agents लगाने की कोशिश की, और यह बात मेरे अनुभव से बिल्कुल मेल खाती है
      पहले हफ्ते prompts लगातार बड़े होते गए और performance गिरती गई। दूसरे हफ्ते हमने notes, tasks, projects, people जैसे objects को ठीक-ठीक define करने और उन objects पर well-defined operations करने वाले methods define करने पर ध्यान दिया। जैसा आपने कहा, agent का surface area घटकर एक translation layer रह जाता है जो natural language को input validation से गुजरने वाले commands और arguments में बदलता है
    • अगर system prompt को पूरी तरह घुमाकर देखें, तो वह शायद यह होगा: “अपने आपको बेरोज़गार करने के लिए automation के हर मौके की तलाश करो। अगर तुमसे ऐसा सवाल पूछा जाए जिसका जवाब code दे सकता है, तो code लिखो, उसे चलाओ, और result के आधार पर जवाब दो”
      ऐसा LLM शायद strawberry test में बेहतर करता
    • इस forum में भी कुछ लोगों ने भविष्य के software को generative AI के ज़रिए runtime पर generate और adapt होने वाले programs के रूप में देखा है। वहाँ तक पहुँचने में कितना समय है, पता नहीं
    • मैंने ऐसे cases देखे हैं जहाँ model किसी खास problem-solving approach में फँस जाता है, और उसे किसी दूसरी दिशा में मोड़ने के लिए nudges चाहिए होते हैं। उदाहरण के लिए audio stream के hotplug/unplug को संभालने के लिए system service settings में बहुत छेड़छाड़ करने के बजाय, असल में कुछ दर्जन lines की Python ही चाहिए थी
      मैंने Claude से अपने workflow के लिए खुद कुछ shell scripts लिखवाईं जो common cases जैसे test runs संभालती हैं। अब वह 30 मिनट तक चक्कर काटने के बजाय उन्हीं tools को चला कर setup पूरा कर देता है
      जब भी वह कुछ करने के लिए कोई अजीब-सा one-off shell या Python one-liner चलाने की अनुमति माँगता है, मैं सोचने लगता हूँ कि क्या उसे किसी auto-approvable tool की तरफ मोड़ना चाहिए

  • शायद इसी वजह से लोग “next-generation AI” जैसी अभिव्यक्ति बार-बार इस्तेमाल करते हैं। इसका मतलब सिर्फ LLM नहीं है। LLM काफ़ी शानदार हैं, और चाहे fundamental advances और न भी हों, मुझे लगता है कि इन्हें और रोचक तरीकों से इस्तेमाल और optimize करके इनसे मूल्य निकलता रहेगा
    लेकिन कुछ हिस्सों में किसी न किसी तरह के मूलभूत अगली-पीढ़ी के सुधार की ज़रूरत साफ दिखती है। LLM जिस तरह “कभी X मत करो” को धुँधला कर देते हैं, और बहुत सारे कामों के बाद उसे “कृपया X करो” की तरह लेने लगते हैं, वह उनकी कार्यप्रणाली के मूल से जुड़ी चीज़ लगती है। हम अभी भी इस शुरुआती उत्साह में हैं कि इससे क्या-क्या किया जा सकता है, इसलिए भूलना आसान है, लेकिन LLM वह सब कुछ नहीं हैं जिसकी हमें AI में तलाश है
    कोई ऐसी architecture होनी चाहिए जो “कभी X मत करो” को इंसानों की तरह संभाले। “context window” की जगह इंसानों जैसी memory hierarchy वाली architecture भी होनी चाहिए। यानी भले शुरुआत में AI एक जैसा हो, लेकिन अगर दो लोग उससे पर्याप्त लंबी बातचीत करें, तो अंत में वे दो AI सिर्फ अलग context window वाले नहीं, बल्कि सच में अलग entities बन जाएँ
    बेशक यह कैसा दिखेगा, यह किसी को नहीं पता। लेकिन LLM ही AI का अंतिम उत्तर हैं, ऐसा मानने की भी कोई वजह नहीं

    • मेरे हिसाब से वास्तविक memory चाहिए। अभी की memory मोटे तौर पर ऐसे post-it system जैसी है जिसे AI खुद लिखकर हर बार फिर देखता है; यह कोई integrated system नहीं है जो learning संभव करे और अधिक लचीले ढंग से सक्रिय हो
    • एक दिलचस्प example है https://www.youtube.com/watch?v=kYkIdXwW2AE&t=315s

  • prompt enforcement → deterministic flow → prompt enforcement, यह पूरा चक्कर काटकर आने के बाद मैं सहमत नहीं हूँ
    “skip मत करो” fail इसलिए होता है क्योंकि agent पर बहुत काम लादा गया है, और context की दूसरी चीज़ें उस instruction से उसका ध्यान हटा देती हैं
    लेकिन ऐसा किसने कहा कि enforcement करने वाला agent वही होना चाहिए जो build भी कर रहा है? Deterministic control flow में कुछ smart decision logic encode की जा सकती है, लेकिन अगर उसे बहुत rigid बना दो तो वह ठीक काम नहीं करती, और अगर बहुत complex बना दो तो setup और maintenance cost के हिसाब से agent इस्तेमाल करना ही सस्ता पड़ता है
    मूल रूप से तीन तरह के agents चाहिए। एक supervisor जो loop manage करे और समस्या आने पर सही चीज़ activate करे, एक orchestrator जो सही agent को delegate करे और जहाँ ज़रूरत हो वहाँ guardrails enforce करे, और एक worker जो work units execute करे

    • सही है, बस और agents जोड़ दो

  • मेरी नज़र में लगभग सारे harnesses इस मामले में गलत हैं, और कुछ तो बुरी तरह गलत हैं
    उदाहरण के लिए slash commands एक गलत feature हैं। Context window की स्थिति या इस session में कितना पैसा खर्च हुआ, यह देखने के लिए मुझे chatbot के एक turn के खत्म होने का इंतज़ार नहीं करना चाहिए। Control, chat loop के साथ orthogonal होना चाहिए
    Text generator के input और output को control करने से जिन चीज़ों का कोई लेना-देना नहीं, वे भी सिर्फ “यह chat है, तो IRC bot की तरह चलाते हैं” सोच के कारण chat behavior में उलझी हुई हैं
    आजकल LLM agents बहुत हैं, लेकिन control, agent loop और presentation layer को ठीक से अलग करने वाले लगभग नहीं के बराबर हैं। कुछ में कम-से-कम headless mode है, जो अच्छी बात है

    • मैं समझ रहा हूँ कि आप क्या कहना चाहते हैं, लेकिन आपने जो architecture सुझाया है, उसे वास्तव में बनाना कहीं अधिक कठिन है। क्यों न खुद बनाकर किसी बड़ी कंपनी में नौकरी पाने की कोशिश करें?
    • codex CLI में /status turn के बीच में भी ठीक से काम करता है
      बाकी tools में ऐसा नहीं है
    • मैं Codex desktop app इस्तेमाल करता हूँ। GUI में context indicators और usage stats देखे जा सकते हैं
      Conversations के बीच आना-जाना और updates देखना भी आसान है। कभी-कभी terminal में Claude Code या opencode इस्तेमाल करता हूँ, लेकिन Codex desktop app की तुलना में अनुभव बहुत खराब लगता है

  • “ऐसी programming language की कल्पना करो जहाँ statements सुझाव हों और functions hallucinate करके ‘Success’ लौटा दें। Reasoning असंभव हो जाती है, और complexity बढ़ने पर reliability टूट जाती है” — यह बात असल में declarative programming के काफी करीब लगती है
    ज़्यादातर traditional programming developers के लिए परिचित imperative शैली में होती है। आप exact instructions का set देते हैं और उम्मीद करते हैं कि चीज़ें आपके लिखे अनुसार चलेंगी। Agents imperative की तुलना में declarative के कहीं अधिक करीब हैं: आप desired outcome देते हैं और वे उसे पाने के लिए काम करते हैं
    बेशक SQL जैसे declarative systems में results काफ़ी consistent और well-defined होते हैं, लेकिन फिर भी आप processing कैसे होगी, इसके लिए internal engine पर भरोसा करते हैं। Agents को declarative तरह से सोचना, Rube Goldberg-जैसे “control” systems design करने की कोशिश से कहीं अधिक मददगार लगा। अगर fit न बैठे, तो validate करो, गलत होने की रिपोर्ट करो, फिर retry करो या दूसरा approach लो
    अगर सचमुच imperative चाहिए, तो imperative में लिखो। या agent से वैसा लिखवाओ। यह वैसा लगता है जैसे काम के लिए गलत tool इस्तेमाल करने की कोशिश हो रही हो

    • यह declarative से भी एक स्तर ऊपर का abstraction लगता है। शायद इसे “narrative programming” कह सकते हैं? बेशक “programming” शब्द यहाँ अब भी सही है या नहीं, इस पर बहस हो सकती है
      यह declarative जैसा दिख सकता है, लेकिन वह एक भ्रम के भीतर है। हम वास्तव में AI को goal समझाकर उसकी व्याख्या नहीं करवा रहे; बल्कि हमारे पास एक story document है जिसमें मानव-प्रतिनिधि character एक computer character से बात कर रहा है, और हम वास्तविक दुनिया में उम्मीद कर रहे हैं कि LLM उसके पीछे एक अधिक coherent कहानी जोड़ दे, जिससे हम कुछ उपयोगी निकाल सकें
      यह सिर्फ academic distinction नहीं है। अगर आपको पता है कि वहाँ कहानी चल रही है, तो input और output के रिश्ते को समझने और strategy बनाने के models बेहतर बनते हैं। उदाहरण के लिए prompt injection जैसे risks को समझने में मदद मिलती है, और यह भी दिशा मिलती है कि किस तरह का training data जोड़ना या हटाना चाहिए
    • declarative की बात सोचते हुए मेरा मन SQL नहीं, बल्कि PROLOG की तरफ गया था। यानी ऐसा जिसमें असली control flow और reasoning capability हो
      वहाँ भी LLM जैसी समस्याएँ मिलती हैं: अगर बहुत सावधान न रहें तो silent failures, repetition और contradiction सामने आते हैं। हो सकता है कि मूल समस्या वही closed-world assumption हो। LLM में यह “मुझे नहीं पता” मानने के बजाय hallucination के रूप में निकलती है
    • सहमत। लेकिन agent से imperative ढंग से भी बात की जा सकती है। “यहाँ concrete steps हैं, इन्हें follow करो” कहने पर भी वह बिगाड़ सकता है। असल में जिस चीज़ की तलाश है, वह imperative-ness नहीं बल्कि determinism है
      और जैसा आपने कहा, non-deterministic LLM से declarative तरीके में “मुझे इस final state तक ले चलो” कहना, उसके पटरी से उतरने की संभावना और बढ़ा देता है
    • SQL की declarative प्रकृति relational algebra जैसे गणित पर आधारित है, इसलिए वह हर बार वही result लौटाती है। हर query उसी समय-सीमा में लौटेगी या नहीं, यह indexes और database के आकार पर निर्भर करता है
      लेकिन query खुद LLM की तरह बदलती नहीं रहती

  • मैं इस समस्या पर काफ़ी समय से सोच रहा हूँ। यह specialization वाली बात से भी जुड़ सकती है। जैसे-जैसे models ज़्यादा specialized होते हैं, लगता है कि उनकी base-level capabilities कुछ घट जाती हैं, और अगर बहुत हल्का abstraction target किया जाए तो शायद दोनों दुनियाओं का फायदा मिल सकता है
    यह काफ़ी specific example है, लेकिन सोचने लायक है
    Podcast 20-minute summary: https://pub-6333550e348d4a5abe6f40ae47d2925c.r2.dev/EP008.ht...
    Paper: https://arxiv.org/abs/2605.00225

  • यह बात 2023 के Auto-GPT दौर में ही दिख गई थी। लोग GPT को “drive” करने दे रहे थे, जबकि ज़्यादातर मामलों में वास्तव में ज़रूरत सिर्फ 10 lines की Python और शायद कुछ llm() function calls की थी
    विकल्प यह था कि उन्हीं 10 lines की Python को यथासंभव सबसे महंगे, सबसे धीमे और सबसे कम reliable तरीके से execute किया जाए। हाँ, लोकप्रियता ज़रूर बहुत थी
    उदाहरण के लिए, ज़्यादातर लोग agents का उपयोग internet research के लिए करते थे। वे घंटों चलते रहते, फिर भटक जाते या भूल जाते कि वे मूल रूप से क्या कर रहे थे
    इसके उलट import duckduckgo और import llm के साथ 20 सेकंड में वही काम करने वाला 10-line code लिखा जा सकता है, जो वास्तव में deterministic चलता है और cost भी 50 गुना कम आती है
    मौजूदा models बहुत बेहतर हो चुके हैं, और अब वे शायद इतने अच्छे हैं कि Auto-GPT जैसी चीज़ें सचमुच व्यवहारिक हो सकें। लेकिन खराब तरह से specified control flow को सबसे महंगे संभव तरीके से चलाना अब भी बुरा विचार है