Muse Spark 1.1 जारी

 (ai.meta.com)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Meta Superintelligence Labs द्वारा जारी Muse Spark 1.1 agent कार्यों को ध्यान में रखकर बनाया गया एक multimodal reasoning model है, जो tool·computer use, coding और multimodal understanding को पिछले संस्करण की तुलना में अधिक मजबूत बनाता है
  • बाहरी apps और services के पूरे दायरे में planning·orchestration संभालना, और native tools, MCP servers, custom skills पर zero-shot generalization इसकी मुख्य विशेषता है
  • यह 10 लाख token context window को सक्रिय रूप से manage करता है, ताकि पिछले कार्यों की जानकारी retrieve कर सके और आगे के चरणों के लिए ज़रूरी मुख्य context को compress करके बनाए रखे
  • developers सार्वजनिक preview के रूप में जारी Meta Model API में इस model को access कर सकते हैं, और Meta AI app तथा meta.ai में इसे “Thinking” mode में इस्तेमाल किया जा सकता है
  • Meta ने Advanced AI Scaling Framework के अनुसार deployment से पहले safety evaluation किया, और Chemical & Biological, Cybersecurity, Loss of Control श्रेणियों में इसे safety margin के भीतर आंका

Muse Spark 1.1 की स्थिति और उपलब्धता

  • Muse Spark 1.1 Meta Superintelligence Labs का नवीनतम model है, जिसे मौजूदा Muse Spark के मुकाबले एक प्रमुख upgrade के रूप में पेश किया गया है
  • यह agent कार्यों के लिए एक multimodal reasoning model है और निम्न क्षेत्रों में सुधार पर ज़ोर देता है
    • tool use
    • computer use
    • coding
    • multimodal understanding
  • यह release Muse Image की घोषणा के साथ जुड़ा है और Meta के अनुसार “personal superintelligence” vision के और करीब जाने वाला एक कदम है
  • developers सार्वजनिक preview के रूप में जारी Meta Model API के जरिए Muse Spark 1.1 को access कर सकते हैं
  • Meta AI app और meta.ai में यह “Thinking” mode में उपलब्ध है

Agent कार्य और लंबे context की प्रोसेसिंग

  • कई बाहरी apps और services में फैले personal agent tasks के लिए यह planning करता है और execution flow को orchestrate करता है
  • यह native tools, MCP servers, और custom skills पर zero-shot generalize करता है
  • इसे Muse Spark की तुलना में कहीं अधिक तेज़ी से जटिल projects को संभालने के लिए train किया गया है
    • main agent context इकट्ठा करता है, plan बनाता है और execution को parallel subagents को delegate करता है
    • subagents अपने assigned tasks का पालन करते हैं, उपलब्ध tools को समझते हैं और ज़रूरत पड़ने पर main agent तक escalate करते हैं
  • यह 10 लाख token context window को सक्रिय रूप से manage करता है
    • किए गए actions को याद रखता है
    • बहुत पहले के tasks की जानकारी retrieve करता है
    • आगे के tasks के लिए ज़रूरी मुख्य steps को बचाए रखने के लिए compress करता है

Computer use automation

  • Muse Spark 1.1 उन computer use workflows में मज़बूती दिखाता है जहाँ कई applications के बीच आना-जाना होता है और जानकारी real time में बदलती रहती है
  • यह लंबे sessions में भी context बनाए रखता है, बदलती requirements के अनुसार adapt करता है और अपरिचित interfaces को न्यूनतम human intervention के साथ navigate करता है
  • यह desktop tasks को हमेशा केवल click-level actions से नहीं संभालता, बल्कि स्थिति के अनुसार automation और direct manipulation में से चुनता है
    • जब automation तेज़ होती है तो script लिखता है
    • जब direct interaction सरल होती है तो clicks का उपयोग करता है
    • हर चरण में कई actions को जोड़कर generate करता है
  • dinner party preparation उदाहरण में, order प्रक्रिया के दौरान नया context बनने पर यह उसे पहचानता है और user intervention के बिना ज़रूरी updates करता है

Coding performance और development workflow

  • बड़े और जटिल codebases से जुड़े real-world coding tasks में Muse Spark 1.1 का performance काफ़ी बेहतर हुआ है
  • यह जटिल bugs का diagnosis और fixes, enterprise-grade systems में नई features का implementation, और बड़े पैमाने पर code migration कर सकता है
  • web application generation और end-to-end question answering जैसे use cases में यह पहले model की तुलना में बड़ा सुधार दिखाता है
  • इसे विभिन्न harnesses के साथ smoothly adapt करने और जटिल multi-turn behavior को स्थिर रूप से संभालने के लिए train किया गया है
    • planning mode
    • goal conditioning
    • subagent delegation
    • context compaction जैसी सामान्य agent coding capabilities को support करता है
  • OpenCode debugging demo में इसने एक chat web app बनाया, automatic screenshots से user को दिख रही failure को ढूँढा, संबंधित code तक trace किया, उसे fix किया और फिर changes को verify किया
  • Meta के internal developers और researchers Muse Spark 1.1 का रोज़ाना उपयोग कर रहे हैं, और Meta Internal Coding Bench में यह Muse Spark की तुलना में काफ़ी बेहतर तथा प्रमुख alternatives के मुकाबले competitive results दिखाता है
  • researchers Muse Spark 1.1 का उपयोग workflows में model development·evaluation tasks को automate करने के लिए भी कर रहे हैं
  • DeepSWE evaluation उदाहरण में, इसने OpenCode के भीतर अलग-अलग reasoning intensity पर DeepSWE के कुछ tasks का self-evaluation किया और results-आधारित analysis dashboard बनाया

Multimodal understanding और execution

  • Muse Spark 1.1 उन tasks में भी मज़बूती दिखाता है जहाँ perception, multimodal reasoning, और tool use का संयोजन आवश्यक होता है
  • यह वास्तविक environment के साथ interact करते हुए grounded outputs बना सकता है
    • visual सामग्री से code outputs generate करना
    • images·videos के लिए बेहद detailed captions बनाना
    • multimodal use cases के लिए agent workflows चलाना
  • जहाँ perception और action दोनों साथ चाहिए, वहाँ इसकी multimodal capabilities विशेष रूप से उपयोगी होती हैं
    • visual और audio की जाँच करता है
    • लंबे workflows के दौरान details को बनाए रखता है
    • user की ओर से computer operate करते समय उन्हीं details का उपयोग करता है
  • Facebook Marketplace agent उदाहरण में, इसने smartphone से शूट किए गए video से उपयोगी photos निकाले, item का inference किया, और फिर user के browser को operate करके Marketplace listing बनाई

Safety evaluation

  • Meta ने deployment से पहले Advanced AI Scaling Framework के अनुसार व्यापक safety evaluation किया
  • यह framework Meta के सबसे उन्नत models के लिए evaluation, threat models, और deployment criteria को परिभाषित करता है
  • evaluation categories में निम्न frontier risks शामिल हैं
    • Chemical & Biological
    • Cybersecurity
    • Loss of Control
  • Meta के evaluation में Muse Spark 1.1 सभी frontier risk categories में safety margin के भीतर operate करता है
  • इसने direct jailbreak, अविश्वसनीय data से आने वाले indirect attacks, prompt injection, और developer-prompt attacks के प्रति मज़बूत resistance दिखाया
  • इसके परिणामस्वरूप adversarial robustness में सुधार हुआ और hallucination rate तथा sycophancy कम हुई
  • पूरी safety-संबंधित जानकारी Muse Spark 1.1 Evaluation Report में documented है

शुरुआती partner प्रतिक्रिया और आगे की योजना

  • Meta Model API के सार्वजनिक preview के जरिए developers पहली बार Muse Spark 1.1-आधारित builds शुरू कर सकते हैं
  • शुरुआती partners ने इसे ऐसे foundation model के रूप में आंका है जो लंबे context handling, coding, और reasoning capabilities को जोड़कर बड़े पैमाने के agent workloads संभाल सकता है
  • Replit CEO Amjad Masad ने इस बात पर ज़ोर दिया कि एक ही model में 10 लाख token context, image·video·PDF multimodal support, citations के साथ built-in search, structured outputs, parallel tool calling, और OpenAI-compatible package शामिल हैं
  • Cline CEO Saoud Rizwan ने कहा कि मज़बूत tool use और बड़े पैमाने पर real-world coding workloads चलाने लायक pricing, दोनों एक साथ होने के कारण वे Cline developers को early access देना चाहते थे
  • Box की Yashodha Bhavnani ने कहा कि Box के enterprise work evaluation set में Muse Spark ने मौजूदा प्रमुख frontier models के मुकाबले competitive enterprise capabilities दिखाईं
  • OpenClaw Foundation के Dave Morin ने Muse Spark 1.1 को agent execution के लिए तेज़ और शक्तिशाली model बताया
  • Meta ने कहा कि वह और अधिक performant models को train कर रहा है और भविष्य में उन्हें साझा करने की योजना है

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • लिंक किए गए रिपोर्ट में कहीं ज़्यादा विस्तार है: https://ai.meta.com/static-resource/muse-spark-1-1-evaluatio...
    Terminal-Bench-2.1 के विवरण में लिखा है, “आधिकारिक repository के Terminal-Bench 2.1 के 89 tasks को bash tool-only agent harness के साथ evaluate किया गया, और resources को CPU 6 cores और RAM 8GB तक सीमित किया गया,” लेकिन ऐसा है तो यह नतीजा अयोग्य है
    हर terminal bench task की अलग CPU सीमा और RAM सीमा होती है, और अगर इनमें से किसी एक को भी पार किया जाए तो अयोग्य माना जाता है। tbench-2.1 के हिसाब से 89 में से CPU 6 cores की अनुमति देने वाले tasks 0 हैं, और RAM 8GB की अनुमति देने वाले tasks सिर्फ 8 हैं
    इस तरह की संदिग्ध benchmarking, model की benchmark performance बढ़ाने के लिए harness बनाने का सारा मज़ा खत्म कर देती है। क्योंकि आप जो भी करें, headline में दिए गए गलत numbers को हरा नहीं सकते। शायद इसी वजह से यह model आधिकारिक leaderboard https://www.tbench.ai/leaderboard/terminal-bench/2.1 पर नहीं है
    Meta का पूर्व कर्मचारी होने के नाते यह थोड़ा कड़वा लगता है, लेकिन बहुत चौंकाने वाला नहीं है। PSC खत्म होने और अगले चरण पर जाने से पहले तक numbers बढ़ाना ही performance evaluation का मुख्य metric था

    • अगर model गलती से fork bomb न चला दे, तो मुझे समझ नहीं आता कि resource limits पर ध्यान देने की ज़रूरत क्यों है। मुझे लगा यह benchmark terminal इस्तेमाल करने की क्षमता, खासकर बहुत सारे bash tool calls को जोड़ने की क्षमता, मापता है। किस तरह के test case में यह महत्वपूर्ण हो जाता है?
    • closed model की समस्या यही है। हम जिस चीज़ के लिए पैसे दे रहे हैं, वह बेहतर base model है या benchmark scores को maximize करने के लिए अच्छी तरह डिजाइन किया गया harness, यह हम ठीक-ठीक नहीं जान सकते
    • बस जिज्ञासा है, resource limits कितनी बार bottleneck बनती हैं? harness यहां क्या मदद करता है? क्या यह parallelism सीमित करता है या ज़्यादा efficient tools का इस्तेमाल करता है?
    • बात समझ में आती है, लेकिन इतना महत्वपूर्ण है या नहीं, इस पर यक़ीन नहीं
      harbor / tb2.1 ने Docker runs के लिए उपलब्ध swap को सीमित किया था क्या? पहले एक bug था जिसमें Docker instances spec से ज़्यादा memory इस्तेमाल कर सकते थे। कुछ मूल tasks swap का उपयोग किए बिना लगभग पूरे ही नहीं हो सकते थे, और अगर Docker को swap तक पहुंच से रोक दिया जाए तो oracle solution भी pass नहीं कर पाता
      याद पड़ता है कि crack-7z-hash और filter-js-from-html में यह समस्या थी, लेकिन कई महीनों से देखा नहीं है इसलिए पक्का नहीं कह सकता
    • यह मुझे इतना बड़ा मुद्दा नहीं लगता। किसी भी product का मूल्यांकन करते समय हम उसे बनाने वालों की बात सीधे नहीं मानते। bias तो होगा ही। इसी लिए https://artificialanalysis.ai जैसे independent tests मौजूद हैं

  • मुझे इसे कुछ दिनों पहले इस्तेमाल करने का मौका मिला, और उस दौरान मैं LLM के लिए एक plugin बना सका। terminal में इस तरह model को आज़माया जा सकता है
    uv tool install llm
    llm install llm-meta-ai
    llm keys set meta-ai
    # paste API key here
    llm -m meta-ai/muse-spark-1.1 "Generate an SVG of a pelican riding a bicycle"
    नतीजा यहां है: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...
    तुलना के लिए Muse Spark 1 से निकला pelican यहां है: https://simonwillison.net/2026/Apr/8/muse-spark/

    • मैं सोचता हूं कि आप इतने सारे models को preview करने का समय कैसे निकाल लेते हैं। हाल की model releases तो वाकई बहुत hectic रही हैं, कभी-कभी क्या यह काम जैसा नहीं लगने लगता?

  • हो सकता है Zuck सीधे मुकाबले से ज़्यादा model market में spoiler की भूमिका निभाने पर ध्यान दे तो बेहतर हो
    उसे Anthropic या OpenAI के model revenue को पकड़ने की ज़रूरत नहीं है, बस इतना काफी है कि वह उस revenue को 99% तक गिरा दे। frontier model development पर अरबों डॉलर खर्च करता रहे, और उन्हें open weights के साथ जारी करके coding models को commodity बना दे। इसके साथ एक अच्छी open source standards harness भी चाहिए
    बहुत कम लोग ऐसी स्थिति में हैं कि यह कर सकें और व्यापारिक रूप से भी यह समझ में आए। वैसे भी संभावना है कि रुझान उसी दिशा में जाएगा, और वह उसकी रफ्तार काफ़ी बढ़ा सकता है। जैसे compiler के साथ हुआ था, वैसे ही models भी proprietary products से commodity की तरफ जाएं, यही उम्मीद होनी चाहिए
    यह दुनिया के लिए Zuck के सबसे अच्छे कामों में से एक हो सकता है

    • अगर उनकी revenue चली गई, तो Meta के compute resources किराए पर कौन लेगा?
    • सच में spoiler king बनना है तो training datasets को open source कर दे। वहां तक जाएगा, इस पर शक है
    • coding models मंज़िल नहीं हैं। coding models तो general intelligence तक पहुंचने की bootstrapping प्रक्रिया का सिर्फ एक हिस्सा हैं
    • क्या उन्होंने llama के साथ पहले ही यह कोशिश नहीं की थी?
    • उसे बस यह साबित करना है कि ऐसे models बनाना अब उतना कठिन नहीं रहा। इन कंपनियों की moat frontier models बनाना वास्तव में बहुत कठिन है, इस धारणा पर टिकी है

  • कीमत हैरान कर देने वाली हद तक अच्छी है। 10 लाख tokens पर input $1.25, output $4.5 है, और cached input $0.15 है
    https://dev.meta.ai/docs/getting-started/pricing-rate-limits

    • इसकी तुलना सबसे सीधे xAI Grok 4.5 से की जा सकती है। दोनों की दिशा कुछ ऐसी है: “Haiku की कीमत पर Opus-स्तर की intelligence”, और ऐसे मॉडल को ऐप में शामिल करना चाहने वाले application developers के लिए यह बहुत बड़ी बात है
      मैं Haiku और Sonnet को Grok 4.5 से बदलने के tests कर रहा था, इसे भी एक बार आज़माने का सोच रहा हूँ। खासकर cached pricing काफी सस्ती है
    • cached input की price ratio अच्छी है
      Grok 4.5 $2/$6 पर आया, लेकिन चुपचाप cached input के लिए 10 लाख tokens पर $0.50 लेता है। यह Opus 4.8 जितना महंगा है
    • अभी model चुनने वाले ज़्यादातर लोगों के radar पर Meta नहीं है। अगर उनके पास सच में अच्छा model है, तो competitors की pricing match करने से पहले subsidy देकर users हासिल करना समझदारी है
    • Qwen 3.7 Max से भी सस्ता है। Grok 4.5 के $2 input / $6 output के बाद, यह दूसरा संकेत है कि बड़े labs GLM 5.2 के दबाव को महसूस कर रहे हैं
    • फिर भी यह अब भी बेतुका महंगा है। सोचिए Google search के 100 results के लिए $10 देना पड़े — असल में बात लगभग वही है
      मुझे सच में समझ नहीं आता कि कोई output के 10 लाख tokens पर $1.50 से ज़्यादा क्यों देना चाहेगा। $15~50 की तो बात ही छोड़िए। क्या consumers वाकई कभी usage-based billing देते हैं?

  • कल तक तो माहौल ऐसा लग रहा था कि OpenAI और Anthropic इतनी आगे निकल चुके हैं कि वापसी नहीं हो सकती, लेकिन अब xAI और Meta ने कम से कम practical models में competitive चीज़ें उतारी हैं, और कीमत भी कम है
    बेशक, Fable और शायद जल्द आने वाला GPT-6 देखें तो यह बात अभी भी बनी रहती है कि ये दोनों leading labs आगे हैं, लेकिन opinion leaders जैसा कहते थे, खेल पूरी तरह खत्म नहीं हुआ है

    • अब models मोटे तौर पर काफी अच्छे हो चुके हैं। कोई बड़ा breakthrough न हुआ तो अब से सबसे अहम चीज़ सिर्फ cost है
    • लोगों ने Google के पीछे रह जाने को Anthropic और OpenAI के बहुत आगे निकल जाने के रूप में गलत समझ लिया। असल में यह ज़्यादा वैसा है जैसे Google Tensorflow, Angular, GCP के समय पीछे रह गया था
    • उसका nuance थोड़ा अलग है
      GLM 5.2 को लेकर उम्मीद पहले से ही काफी ऊँची थी। xAI या Meta ने किसी बिल्कुल अलग तरीके से बड़ा फ़र्क नहीं बनाया, बल्कि वे GLM 5.2 जैसे नतीजों और मिलती-जुलती pricing के करीब हैं

  • व्यक्तिगत रूप से मुझे Meta पसंद नहीं है, लेकिन इसका श्रेय देना पड़ेगा। जितनी ज़्यादा competition, उतना आम consumers के लिए अच्छा, और companies के लिए भी
    Chinese models, Grok, Meta, Google, OpenAI, Anthropic — सबका मुकाबला करना मुझे जीत जैसा लगता है। जब तक ऐसे subsidized tokens इस्तेमाल किए जा सकते हैं, मैं पागलों की तरह चीज़ें बना रहा हूँ ताकि इसका पूरा फायदा उठा सकूँ

    • Meta के local llama models कभी open source AI का चेहरा थे। हालात सच में बहुत बदल गए हैं
    • यह निश्चित रूप से अच्छी बात लगती है। लेकिन इन प्रगतियों की वजह से AI युग में ज़रूरी software engineers की संख्या बढ़ेगी या घटेगी, इस पर अभी भी मन में बहस चल रही है
      एक तरफ, products बनाना आसान हो जाएगा, इसलिए ज़्यादा लोग बनाएँगे, और ज़्यादा products व features आएँगे। non-technical लोग भी बहुत कुछ बनाने की कोशिश करेंगे, लेकिन अटकेंगे, और आखिरकार engineers की ज़रूरत पड़ेगी। skilled tech companies, non-technical founders, और aspiring founders मिलकर जितने products बनाएँगे, उनकी कुल मात्रा बहुत बड़ी होगी। निकट भविष्य में ज़्यादा software engineers की ज़रूरत पड़ने वाला upside scenario यही है
      दूसरी तरफ, करीब एक साल में लोग ऐसे ढेरों products बना लेंगे, लेकिन उनमें से ज़्यादातर का marketing, sales, या monetization नहीं हो पाएगा। तब शायद इतने सारे software engineers की ज़रूरत ही न रहे। फिर भी कुल मिलाकर मुझे लगता है कि net effect में upside scenario के जीतने की संभावना ज़्यादा है
    • Chinese models को थोड़ा और खोलकर कहें तो DeepSeek, GLM(Z.ai), Minimax, Kimi(Moonshot), Hy3(Tencent), Qwen(Alibaba) शामिल हैं
      इनमें से हर एक के weights डाउनलोड करके local execution किया जा सकता है
    • उसने यह खबर अपने Meta Threads पर नहीं, बल्कि X पर पोस्ट की। इससे पता चलता है कि इसे ज़ोर से आगे बढ़ाने में उनकी दिलचस्पी कितनी है। बेशक, जब तक ये कंपनियाँ cash जलाती रहेंगी, हमारी तरफ से लागत शायद संभालने लायक बनी रह सकती है
    • यह अब तक की सबसे बड़ी tech competition है। सबसे अमीर कंपनियाँ, सबसे होशियार लोग, और सबसे अमीर देश इसमें उतर चुके हैं
      competition अच्छी है या नहीं, यह कुछ साल बाद पता चलेगा। लंबे समय बाद फिर से कोई शारीरिक मेहनत वाला काम करने के दिन का इंतज़ार कर रहा हूँ

  • हर कंपनी हर benchmark में खुद को नंबर 1 जैसा कैसे दिखा लेती है?

    • पहले वे चुनकर बनाए गए benchmark bundle में देखते हैं कि कौन से models बदतर दिखते हैं
      फिर competitors के पुराने versions से तुलना करते हैं। अगर तब भी अच्छा न लगे, तो अपने ही पिछले model से तुलना कर लेते हैं
    • क्योंकि moat बहुत बड़ी नहीं है, improvements incremental हैं, और तुलना के लिए models को चुन-चुनकर रखा जाता है
      निष्पक्ष रूप से कहें तो अगर मुख्य ताकत pricing है, तो मिलते-जुलते performance वाले models से तुलना करना ज़्यादा सही लगता है
    • अब Gemini से तुलना करना free bingo square जैसा महसूस होता है
    • जो लोग AI को गहराई से जानते हैं, उनके हिसाब से coding में standard benchmark किसे मानना चाहिए?
    • बस उस सटीक पल का इंतज़ार करो जब तुम्हारा model कम-से-कम N benchmarks में आगे निकल जाए, और फिर announce कर दो

  • यह बात छूट गई थी कि Meta closed-weight model बना और रिलीज़ कर रहा था। अफ़सोस है। अच्छा होता अगर अमेरिकी open-weight models में और प्रगति दिखती

  • मैंने इसे container के अंदर codex के साथ काम करने लायक बना लिया। जानकारी के लिए, लगता है Codex:Muse interface में वही bug है जिससे ज़्यादातर लोग टकराएँगे
    मेरी समझ से codex को server-side tool calling की उम्मीद नहीं थी, और Meta जिस तरह उन IDs को संभालता है, उससे किसी तरह की parsing या integration error पैदा होती है। जब मैंने codex को muse के साथ शुरुआती कुछ बार चलाया, तो पहले non-web-search call पर यह fail हो गया
    मैंने इसे ठीक कर लिया है, और व्यक्तिगत रूप से मैं अभी भी custom server-side tool calling और अनिश्चितकालीन file storage को लेकर पूरी तरह आश्वस्त नहीं हूँ, लेकिन अभी तक यह काफी बढ़िया model है और मज़े से इस्तेमाल कर रहा हूँ
    https://github.com/accretional/awesome-muse-spark/blob/main/...

  • सार्वजनिक बेंचमार्क को देखें तो coding और multimodal भी काफ़ी अच्छे लगते हैं, लेकिन tool calling success rate बहुत अच्छी लगती है
    इस तरह के performance profile के लिए सबसे उपयुक्त use case क्या होगा?

    • debugging और diagnosis में tool calling बहुत ज़्यादा होती है। इसमें logs को grep करना या transform करना, profiler या tracer को call करना, और incident report लिखना तक शामिल है
      bug diagnosis ऐसा क्षेत्र है जहाँ कुछ हद तक coding करनी पड़ती है, लेकिन उससे भी ज़्यादा tools का उपयोग अच्छी तरह करना ज़रूरी है। अगर अच्छी diagnosis report हो, तो fix को Opus के हवाले किया जा सकता है
      Opus भी कुछ हद तक report लिखता है, लेकिन typst document में अब भी अक्सर table width ग़लत कर देता है, जिससे आख़िरी column में text ठूँस जाता है जबकि width सिर्फ़ कुछ अक्षरों जितनी रह जाती है
    • Gemini 3.5 Flash, tool calling में Fable से बेहतर है। संभवतः tool calling उन क्षेत्रों में से एक है जिन्हें post-training से तुलनात्मक रूप से आसानी से सुधारा जा सकता है
    • सोचता हूँ कि क्या आगे हर नए release में यही pattern दिखेगा। tool use तेज़ी से बदल सकने वाला क्षेत्र है, इसलिए सबसे intelligent model की बजाय सबसे latest model को हमेशा बढ़त मिल सकती है
    • यह थोड़ा कम उपयोगी लग सकता है। JSON जैसे constrained decoder का शानदार performance दिलचस्प है, लेकिन सामान्य decoder में tool validator से गुज़रकर अच्छे error messages मिलने के बाद retry loop चलाने पर लगभग हमेशा दूसरे प्रयास में tool काम कर जाता है। input cache हो जाता है, इसलिए cost भी ज़्यादा नहीं होती