बेहतर मॉडल, बदतर टूल

 (lucumr.pocoo.org)
1 पॉइंट द्वारा GN⁺ 6 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Pi के edit टूल में Claude Opus 4.8 और Sonnet 5 ने edits[] के अंदर schema में मौजूद नहीं होने वाले fields जोड़ दिए, जिससे call reject हो गया; यह देखा गया कि नए मॉडल किसी खास tool schema का पालन पुराने मॉडलों से खराब कर रहे हैं
  • Tool calling असल में मॉडल द्वारा special markers और JSON जैसी शक्ल वाला text generate करने की प्रक्रिया है, इसलिए unconstrained sampling में सीखे हुए conventions schema से आगे निकल सकते हैं
  • failure cases में oldText और newText खुद सही थे, फिर भी requireUnique, oldText2, matchCase, in_file जैसे नकली keys जुड़ गए; reproducibility agent history और thinking block शामिल होने या न होने पर बदलती रही
  • Claude Code एक closed harness है, लेकिन गलत calls की retry, parameter aliases, type correction, Unicode recovery, unknown keys filtering जैसी बहुत सारी ढीली correction करता है और strict mode इस्तेमाल नहीं करता
  • Anthropic के strict tool calling ने यह समस्या खत्म कर दी; अगर मॉडल performance बेहतर होने के साथ alternative tool schemas नुकसान में जा सकते हैं, तो harness को grammar constraints जैसी मजबूत guarantees चाहिए

Pi edit टूल में दिखी regression

  • Pi issue को track करते समय पता चला कि नए Claude मॉडल Pi के edit tool को call करते हुए edits[] array के अंदर ऐसे fields जोड़ रहे हैं जो मौजूद नहीं हैं
  • यह किसी छोटे मॉडल में नहीं, बल्कि Opus 4.8 में दिखा, और Sonnet 5 में भी वही व्यवहार मिला
  • पुराने Anthropic मॉडलों में यही समस्या नहीं दिखी, यानी नया high-performance मॉडल इस खास tool schema पर उल्टा खराब behave कर रहा है
  • Fable को test नहीं किया गया, क्योंकि classifier request को चुपचाप Opus पर downgrade कर सकता है

Tool calling text generation के करीब है

  • LLM tool calling में मॉडल conversation history, system prompt और available tools की list लेने के बाद special markers वाले बड़े prompt के अंदर call format generate करता है
  • File editing tool के intended arguments में इस तरह path और edits array शामिल हो सकते हैं
{
  "path": "some/file.py",
  "edits": [
    {
      "oldText": "text to replace",
      "newText": "replacement text"
    }
  ]
}
  • Harness arguments validate करता है, edit perform करता है, फिर result मॉडल में वापस डालता है; validation fail होने पर मॉडल error देखकर आम तौर पर retry करता है
  • Anthropic model का internal format public नहीं है, लेकिन ANTML markers leak हुए हैं या public communication में दिखे हैं
  • यह format XML जैसा दिखता है, लेकिन असल XML से ज्यादा tokenization और training के लिए convenient in-band signal जैसा है
    • Top-level string parameters inline जा सकते हैं
    • Object arrays JSON serialization के रूप में जाने लगते हैं

Unconstrained generation और grammar-constrained generation

  • Structured output बनाने के मॉडल के तरीके broadly दो हैं
    • मॉडल से schema के अनुसार JSON generate करने को कहना और बाद में validation करना
    • sampler को शुरुआत से ही invalid JSON या schema shape sample करने से रोकना
  • दूसरा तरीका grammar-aware decoding या constrained decoding कहलाता है, और grammar तोड़ने वाले tokens को mask करता है
  • अगर schema सिर्फ oldText और newText allow करता है, तो sampler "in_file" या "type" जैसे keys generate होने से रोक सकता है
  • ऐसी constraints न हों तो मॉडल abstract contract को सख्ती से follow करने के बजाय सीखे हुए conventions के हिसाब से generate करता है

असली failure patterns

  • Pi का edit tool एक call में कई exact string replacements support करता है, इसलिए edits array इस्तेमाल करता है
  • Failed calls में इस तरह disallowed fields जुड़ गए
{
  "oldText": "...",
  "newText": "...",
  "requireUnique": true
}

{
  "oldText": "...",
  "newText": "...",
  "oldText2": "",
  "newText2": ""
}
  • Repeated experiments में निकले fake keys बहुत तरह के थे: type, id, kind, unique, requireUnique, matchCase, in_file, forceMatchCount, children, notes, cost, oldText2, newText2, oldText_2, newText_2, event.0.additionalProperties आदि
  • Confirmed bad calls में actual oldText और newText payload byte-level पर correct थे, लेकिन object के अंत में बेकार keys जुड़ने से call reject हो गया
  • Reproduction context पर बहुत निर्भर है
    • नए single-turn prompt “edit this file” में reproduce नहीं हुआ
    • मॉडल द्वारा file पढ़ने, problem diagnose करने और multi-line edit बनाने वाली agent history में reproduce हुआ
    • Reproduce करने के लिए Petr Baudis का transcript जरूरी था
    • उसी user session को जारी रखने पर Opus 4.8 लगभग 20% probability से fail करता है
    • History से thinking block हटाने पर failure rate आधा हो जाता है
    • strict tool calling on करने पर उस run में समस्या गायब हो जाती है

यह और खराब क्यों हुआ

  • सबसे मजबूत hypothesis यह है कि यह random performance drop नहीं बल्कि training artifact है
  • पुराने Anthropic models कुछ tools पर trained थे, लेकिन Claude Code जैसे user-provided harness के साफ target बनने से पहले के थे
  • नए Anthropic models ने संभवतः Claude Code या उससे बहुत मिलते-जुलते harness सहित post-training पाई है, और उस environment में successful tool calls के साथ allowable mistakes भी सीखी हो सकती हैं
  • Claude Code का edit tool Pi की nested edits[] structure नहीं, बल्कि file_path, old_string, new_string, optional replace_all जैसी flat structure के करीब है
  • Claude Code client गलत tool usage retries, parameter aliases, type coercion, Unicode recovery, unknown key filtering जैसी काफी error correction करता है
  • अगर reinforcement learning ऐसे harness या उसके simulation में हुई है, तो थोड़ा गलत tool call भी task पूरा कर सकता है और reward पा सकता है
  • कोई दूसरा harness उसी meaning वाला edit tool अलग schema में देता है, तो model की नजर में वह धीरे-धीरे out-of-distribution tool बन सकता है
  • Opus 4.5 release के समय दूसरे edit tools के साथ बहुत अच्छी तरह adapt करता था, लेकिन अभी observed direction दिखाता है कि alternative tool schemas किसी खास permissive tool ecosystem में disadvantage में जा सकते हैं
  • Documented text editor tool मौजूद है, लेकिन Claude Code उसका format वैसा ही follow नहीं करता, और Claude Code का internal behavior closed-source harness होने के कारण दिखाई नहीं देता

Claude Code का loose harness

  • Claude Code closed-source है, लेकिन minified code देखने पर incoming data के प्रति बहुत permissive दिखता है
  • यह check करता है कि model के visible text में <invoke markup leak हुआ है या नहीं, और अगर हुआ हो तो telemetry भेजकर अपने state machine से गलत call को retry करता है
  • String values में टूटे हुए \uXXXX sequences और lone surrogate ठीक करने वाली Unicode escape recovery है
  • Tool-specific parameter aliases भी हैं
    • Edit में old_str, old_string, new_str, new_string accept होते हैं
    • path को file_path के alias के रूप में accept किया जाता है
  • Unexpected keys चुपचाप filter हो जाते हैं
  • strict mode इस्तेमाल नहीं होता
    • Anthropic strict mode में tool definition complexity limits apply करता है, जिससे API request fail हो सकती है
    • Claude Code के strict mode try न करने की वजह यही लगती है

Strict mode और दूसरे ecosystems

  • Anthropic models और harness दोनों closed हैं, इसलिए दूसरे harnesses में भी वही समस्या जारी रहेगी या नहीं, यह judge करना मुश्किल है
  • Codex models भी closed हैं, लेकिन harness closed नहीं है
  • gpt-oss को OpenAI के harmony response format इस्तेमाल करने के लिए explicitly trained किया गया है, और OpenAI की सोच दिखाने वाले काफी docs हैं
  • harmony channels और tool call content types को prompt format का हिस्सा बनाता है, और tool call body में <|constrain|>json जैसा marker शामिल कर सकता है
<|start|>assistant<|channel|>commentary to=functions.get_weather
<|constrain|>json<|message|>{"location":"San Francisco"}<|call|>
  • <|constrain|>json inference stack को tool call body में JSON-constrained sampling पर switch करने की boundary आसानी से खोजने देता है
  • Hosted GPT models में user tools द्वारा follow की जाने वाली grammar के लिए LARK grammar देने का option भी है
  • Anthropic भी strict mode में कुछ समान processing करता लगता है, लेकिन nested array parameters में मॉडल को लंबे multi-line file content को string literal के अंदर escaped JSON के रूप में generate करना पड़ता है
  • Fake keys सैकड़ों tokens लंबे newText string को close करने के तुरंत बाद, उस high-entropy point पर दिखते हैं जहाँ मॉडल को } और , "..." में से चुनना होता है
  • Opus 4.8 और Sonnet 5 में edit tool call shape के लिए मजबूत prior distribution दिखता है, और वह prior Claude Code के flat edit schema के ज्यादा करीब है
  • Anthropic का strict mode problem fix करता है, इसका कारण यह हो सकता है कि server side पर JSON schema structure में disallowed key sampling reject हो जाती है
  • Test किए गए Codex models में इस तरह की regression नहीं दिखी, और access न होने के कारण 5.6 को exclude किया गया

Harness design पर असर

  • Anthropic models में tool schema शायद neutral abstract contract नहीं है
  • कुछ tool shapes post-training में देखी हुई shapes के करीब हैं, और कुछ दूर हैं
  • कुछ shapes provider की hidden encoding में आसान हो सकती हैं, जबकि कुछ लंबी multi-line strings के बाद nested array में बड़ा escaped JSON object लिखने के कारण मुश्किल operate करती हैं
  • Model schema समझता हो, फिर भी pressure वाली स्थितियों में exact structure sample करने में fail हो सकता है
  • Anthropic में strict sampling on करने से यह problem खत्म हो सकती है
  • लेकिन नए models का behavior दिखाता है कि reinforcement learning model पर क्या असर डालती है, और किसी खास harness के priors से लड़कर best performance पाना disadvantageous हो सकता है
  • Claude Code open-source नहीं है और RL environment में क्या करता है, यह भी पता नहीं, इसलिए यह मानना मुश्किल है कि Claude Code के लिए trained behavior दूसरे tools में साफ-सुथरा transfer होगा
  • एक dominant harness के अंदर जितनी ज्यादा post-training होगी, दूसरे harnesses को उतना ही उस harness की अजीब विशेषताएँ inherit करनी होंगी
  • Constrained decoding में quality trade-offs हो सकते हैं, लेकिन अगर नए model task-solving में बेहतर होते हुए भी alternative tool schemas faithfully emit करने में खराब हो रहे हैं, तो harness में कहीं न कहीं stronger guarantees चाहिए

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

1 टिप्पणियां

 
GN⁺ 6 시간 전
Lobste.rs की राय

  • अगर आप Fable के बारे में सोच रहे हैं, तो मेरी समझ यह है कि Fable अब downgrade करते समय हमेशा स्पष्ट रूप से बताता है
    मेरे साथ भी classifier ने एक बार ऐसा किया था; शायद “bugs को severity के हिसाब से sort कर दो” उसे security research जैसा लगा

    • मैं इस पर थोड़ा test करने वाला हूँ
      उन्होंने कहा है कि वे इसे चुपचाप पीछे से नहीं करेंगे, लेकिन downgrade के लिए इस्तेमाल होने वाला mechanism मैंने अभी तक verify नहीं किया है

  • अगर यह hypothesis सही है, तो इसका असर coding agents से आगे तक जा सकता है
    जो applications stable tool calling पर निर्भर करती हैं, वे भी शायद वैसी ही performance गिरावट झेलें, जब model को किसी खास provider के पसंदीदा execution environment के मुताबिक post-train किया गया हो

  • वैसे, मैंने यह पोस्ट vibecoding नहीं बल्कि ai में डाली थी
    इस साइट पर vibecoding की सीमा आखिर कहाँ है, यह समझना सच में मुश्किल है
    यह पोस्ट base LLM, reinforcement learning, और उसके आसपास execution environment बनाने जैसी चीज़ों से कहीं ज़्यादा जुड़ी है
    अगर यह भी vibecoding है, तो फिर ai tag आखिर कहाँ इस्तेमाल होगा, समझ नहीं आता

    • यहाँ vibecoding एक तरह से उस हर चीज़ पर लगने वाला बड़ा scarlet letter बन गया है, जिसका generative AI से थोड़ा भी संबंध हो, या ऐसा लगे कि हो सकता है
      हाल के हफ्तों में mood-driven blog posts, बड़े projects के README जो LLM contributions पर रोक लगाते हैं, और ऐसे posts जिनमें “X नहीं बल्कि Y” जैसी पंक्तियाँ बहुत ज़्यादा हों—इन सब पर vibecoding tag लग गया है
      मैंने तो व्यक्तिगत रूप से उस tag की परवाह करना पूरी तरह छोड़ दिया है। community उसे इतनी reflexively लगाती है कि उसका असली मतलब ही खत्म हो गया है
      फिर भी, यह खास पोस्ट वास्तव में उन models के बारे में है जो सचमुच उस use case में इस्तेमाल होते हैं, इसलिए इस पर vibecoding tag लगने से मैं सहमत हूँ
      साथ ही, जिस कारण की ओर इशारा किया गया है, उसी वजह से मैं यह भी मानता हूँ कि ai को हटाया नहीं जाना चाहिए। मैं उसे फिर से जोड़ना चाहता हूँ, लेकिन किसी वजह से इस पोस्ट में वह option नहीं है

  • हैरानी की बात नहीं है। vendor lock-in शायद योजना का हिस्सा ही हो सकता है

    • कुछ हद तक cost cutting भी इसमें मिली हुई लगती है। अगर सब लोग Claude Code इस्तेमाल करें, तो prompt caching बेहतर होती है
      “अगर आप Claude subscription fee दे रहे हैं और पहले से ही अपना सारा code हमें भेज रहे हैं, तो आपको एक free UI भी ज़रूर इस्तेमाल करना चाहिए जो model से अलग होकर शायद उतना मजबूत lock-in साधन न हो”—यह pure vendor lock-in आम तौर पर जैसे काम करता है, उससे थोड़ा अलग है

  • यह बात समझ में आती है कि model अपने उसी execution environment में सबसे अच्छा काम करे, जिसमें उसे train किया गया है, यानी model developers द्वारा बनाया गया environment
    अगर उसने Claude Code जैसे trace logs पर भारी reinforcement learning किया है, तो यह उम्मीद की जा सकती थी कि Claude Code की तरह behave न करने वाले execution environments में वह काफ़ी खराब होगा
    मुझे तो उल्टा इस बात पर ज़्यादा हैरानी हुई कि वह Pi जैसे third-party execution environments में भी काफ़ी अच्छा लगता है
    यह भी वाजिब लगता है कि bug agent trace की गहराई में जाकर ही सामने आता हो
    इस साल की शुरुआत में, मैंने GPT 5.2 और 5.3 models में एक bug से जूझा था, जहाँ trace के बाद वाले हिस्से में agent ls -la की जगह ls -ლა output करने लगता था
    मैंने इसे यहाँ संक्षेप में दर्ज किया है: https://github.com/openai/codex/issues/7988
    मेरे अनुभव में, यह भी तभी होता था जब trace काफ़ी गहरा हो जाता था
    लंबे context में ऐसा लगता है कि model साफ़ तौर पर “सोच” नहीं पाता और किसी आदिम instinct पर लौट जाता है
    शायद यही वह बिंदु है जहाँ model की training distribution और execution environment, या user द्वारा model पर मजबूर किए गए task, के बीच का अंतर performance पर सबसे नाटकीय असर डालता है

    • समस्या यह नहीं है कि reinforcement learning करके वह अपने execution environment में बेहतर चलता है
      समस्या यह है कि उसने इतना ज़्यादा reinforcement learning कर लिया है कि पहले के release की तुलना में दूसरे execution environments में regression दिख रहा है
      इस बिंदु पर हमें ऐसे सवाल पूछने चाहिए जैसे, “क्या किसी और तरह का overfitting भी शुरू हो रहा है?”