Mythos के साथ काम करना कैसा लगता है

 (oneusefulthing.org)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • सार्वजनिक रूप से जारी किया गया पहला Mythos-क्लास मॉडल Claude 5 Fable बहु-चरणीय specification लेकर अधिकतम कई घंटों तक खुद काम करता है, और पहले इस्तेमाल किए गए लगभग सभी मॉडलों को बड़े अंतर से पीछे छोड़ देता है
  • एक ही prompt और सिर्फ एक बार feedback से बेहद परिष्कृत social science paper से लेकर हर शब्द s से शुरू होने वाली 10-पेज की तुकांत कविता तक बना देता है
  • काम के दौरान दूसरे AI (मुख्यतः सस्ते Claude Sonnet) को सीधे चलाकर research, coding और verification का बंटवारा करता है, और 2,200 से अधिक flights, railway timetables और देश-वार road speed data इकट्ठा करता है
  • उपयोगकर्ता की भूमिका निर्देश देने और नतीजे का मूल्यांकन करने तक सिमट जाती है, और मॉडल की decision-making प्रक्रिया दिखाई नहीं देती, इसलिए यह अंतिम black box की तरह काम करता है
  • AI के साथ रिश्ता सीधे काम करने वाले 'wizard' से नतीजे commission करने और जज करने वाले 'patron' में बदल रहा है, और क्षमता जितनी बढ़ेगी, इंसानों के दखल की गुंजाइश उतनी कम हो सकती है

Claude 5 Fable की क्षमता और उपयोग का अनुभव - Ethan Mollick

  • मुझे जनता के लिए जारी होने वाले पहले Mythos-क्लास AI मॉडल Claude 5 Fable का Early Access में उपयोग करने का मौका मिला
  • Claude 5 Fable पहला जारी किया गया Mythos-क्लास AI मॉडल है; software security पर इसके प्रभाव को लेकर काफी चर्चा हुई, लेकिन परीक्षण उस क्षेत्र को छोड़कर किया गया
  • Fable के guardrails इस स्तर पर काम करते हैं कि cyber security के लिए इसका उपयोग लगभग असंभव हो जाता है
  • कई प्रयोगों में Fable ने पहले इस्तेमाल किए गए लगभग सभी सार्वजनिक मॉडलों से काफी बेहतर प्रदर्शन दिखाया
  • Fable ने कई समस्याओं पर अपनी क्षमता दिखाई, और multi-page specification के आधार पर अधिकतम लगभग 12 घंटे तक काम चलाया

Fable का प्रदर्शन और outputs

  • किए गए हर प्रयोग में इसने अन्य सार्वजनिक मॉडलों को बड़े अंतर से पीछे छोड़ा, और सभी कार्यों में समग्र performance improvement दिखा
  • एक ही prompt और एक बार feedback के साथ इसने अब तक AI द्वारा बनाए गए सबसे परिष्कृत academic social science paper में से एक तैयार किया
  • Claude Code में अस्पष्ट शुरुआती prompt और "make it better" जैसे थोड़े-से अतिरिक्त feedback से playable games तैयार किए
    • coin flip game की शुरुआत “Balatro, but for the game of coin flips” prompt से हुई
    • self-aware snake game में साँप self-aware हो जाता है और अजीब घटनाएँ होने लगती हैं
    • नीचे गहराई में उतरने वाला game में नीचे जाते हुए यह देखा जाता है कि वहाँ क्या है
    • Claude image generate नहीं कर सकता, इसलिए सारा art और 3D object बिना किसी बाहरी asset के सिर्फ mathematical operations से बनाया गया
  • जैसे-जैसे काम अधिक गंभीर होता गया, tool का उपयोग अनुभव आनंद और बेचैनी के बीच रहा — क्योंकि जो माँगो, वह वैसा ही हो जाता है

Maps and Methods — isochrone map बनाने का उदाहरण

  • isochrone map वह नक्शा है जो दिखाता है कि तय समय के भीतर कितनी दूरी तय की जा सकती है; इसका पहला उदाहरण 1881 में London से यात्रा समय दिखाने के लिए बनाया गया था
  • पहले के मॉडल ऐसे नक्शे को आधा भी उपयोगी नहीं बना पाते थे, क्योंकि इसमें हजारों संभावित यात्रा-दूरी जाँच और बहुत-से छोटे निर्णयों की ज़रूरत होती है

  • काम करने का तरीका

    • ऐसा prompt दिया गया जिसमें शहर चुनने और airport, train, walking और driving को शामिल करते हुए वास्तविक data पर आधारित, अलग design वाला map माँगा गया; साथ ही निर्देश दिया गया कि data real-time होना ज़रूरी नहीं, लेकिन शोध-आधारित वास्तविक data होना चाहिए
    • मॉडल ने पहले 1881 के मूल style में इसे बनाने का प्रस्ताव दिया, और सहमति के बाद काम शुरू किया
    • कई घंटों तक चले build session में कई दूसरे AI (मुख्यतः सस्ते Claude Sonnet) चलाकर यात्रा समय का research किया गया
      • TGV से लेकर Shinkansen तक के rail timetables, कई academic papers पर आधारित देश-वार सड़क गति, और 2,200 से अधिक विशिष्ट flight data जुटाया गया
    • research agents के चलते रहने के दौरान coding शुरू हुई, code verification के लिए अतिरिक्त agents और tests चलाए गए, और progress log किया गया

  • दूरस्थ क्षेत्रों का correction और token usage

    • Greenland जैसे remote क्षेत्रों में सटीक आँकड़ों की जगह सिर्फ estimates थे, इसलिए वास्तविक यात्रा समय प्राप्त करने के लिए इसे संशोधित करने को कहा गया
    • इस बार शोध करने और एक-दूसरे के नतीजों की जाँच करने वाला adversarial groups workflow चलाया गया
    • Pacific के Pitcairn Island तक जहाज़ कितनी बार जाते हैं, और Ottawa से Grise Fjord तक का route निकाला गया
    • कम समय में बहुत बड़ी मात्रा में tokens खर्च हुए
  • उपयोगकर्ता ने सिर्फ महत्वाकांक्षी निर्देश और थोड़ा feedback दिया; मॉडल ने सैकड़ों छोटे निर्णय खुद लिए, और उन चुनावों को समझने या उनमें दखल देने का मौका नहीं था
    • सिर्फ काम की मात्रा ही नहीं, बल्कि मॉडल के तरीके, approach के चयन और नतीजे की गहराई पर भी नियंत्रण सीमित था
  • परिणाम क्लिक करके देखने योग्य isochrone map के रूप में उपलब्ध है, और graph के नीचे methods और sources देखे जा सकते हैं

Working with a Mythos-class model — Concord का उदाहरण

  • सबसे महत्वाकांक्षी project ऐसा research task था जिसमें इंसानों द्वारा दिए गए अव्यवस्थित जवाबों को सही तरह से classify करना था — जैसे कोई idea कितना innovative है, या लोग किसी खास किताब को क्यों पसंद करते हैं
    • पहले मानव शोधकर्ता निर्णय लेते थे और दूसरे जवाबों के साथ statistical comparison करके data reliability की जाँच करते थे
    • AI और मानव judgment का calibration कठिन और महँगा है
  • Fable से इस समस्या का समाधान माँगा गया; इसने पहले 19-पेज का जटिल design document बनाया और फिर उसे execute किया
    • Fable ने इस पर 9 घंटे 30 मिनट तक काम किया
  • परिणाम AI द्वारा Concord नाम दिया गया software था, जो कई datasets लेकर human और AI responses को calibrate करता है और जटिल data analysis करता है
    • यह पूरी तरह perfect नहीं था; expert के नज़रिए से कुछ errors और omissions मिले, जिनमें कुछ माँगे गए design से ही आए थे, इसलिए सुधार के निर्देश दिए गए
    • इसका delivery scope पहले देखी गई किसी भी चीज़ से आगे था, और यह वही software था जिसकी शोधकर्ताओं को वर्षों से ज़रूरत थी, लेकिन profitability न होने के कारण बनाया नहीं गया था
    • बचे हुए संभावित bugs software engineer ठीक कर सकते हैं, और नए software के उपयोग में विस्फोटक वृद्धि से निपटने के लिए coders की ज़रूरत और बढ़ सकती है
    • Concord का code GitHub repository में उपयोग या modify किया जा सकता है

सीमाएँ और बाधाएँ

  • Fable की ताकत के साथ अपरिचितपन और सीमाएँ भी आती हैं

  • token cost

    • Fable, Opus की तुलना में 2 गुना महँगा है, और production cost के लिहाज़ से tokens बहुत तेज़ी से खर्च करता है, स्तर "काफी ज़्यादा(a lot)" जैसा है
    • हालांकि, सस्ते मॉडलों को समझदारी से delegation देने पर वास्तविक लागत काफ़ी कम हो सकती है

  • guardrails और style

    • security issue का बहुत हल्का संकेत मिलते ही guardrails सक्रिय हो जाते हैं और मॉडल को कम सक्षम Claude 4.8 Opus पर switch कर दिया जाता है; ऐसा ज़रूरत से ज़्यादा बार होता है
    • Mythos पर चर्चा मुख्यतः software security प्रभावों पर केंद्रित रही, लेकिन Fable के guardrails cyber security उपयोग को लगभग पूरी तरह रोक देते हैं
    • फिर भी jagged frontier मौजूद है, और outputs तथा progress reports में खास तरह की "Claudism" शैली बनी रहती है

wizard से patron तक — इंसानी भूमिका में बदलाव

  • पिछले साल मैंने इस अनुभव की तुलना ऐसे wizard से की थी जो मंत्र पढ़े और कुछ हो जाए
  • Fable में यह मंत्र इतना शक्तिशाली हो गया है कि उपयोगकर्ता खुद wizard से अधिक patron जैसा हो जाता है
    • आप बताते हैं कि क्या चाहिए, कीमत चुकाते हैं, और नतीजे का मूल्यांकन करते हैं — असली काम कहीं अदृश्य जगह पर सैकड़ों छोटे चुनावों के ज़रिए होता है
    • काम process से result की ओर खिसकता है; अब आप steer नहीं करते, बल्कि commission करते हैं

  • दो संभावनाएँ

    • यह एक अस्थायी स्थिति हो सकती है जहाँ interface अभी पीछे है, और आगे मॉडल के काम करने के तरीके को देखने तथा बीच में steer करने के बेहतर तरीके आ सकते हैं
    • या फिर उल्टा, मॉडल जितना अधिक सक्षम होगा, इंसानों के लिए अर्थपूर्ण काम उतना कम बचेगा, और black box उसी क्षमता की कीमत होगी
  • इसका अर्थ यह नहीं कि नियंत्रण साफ़ तौर पर खो गया है; अब भी इसे steer किया जा सकता है और यह निर्देशों का बहुत अच्छी तरह पालन करता है — निर्देश जितने महत्वाकांक्षी हों, नतीजे उतने बेहतर आते हैं
    • लेकिन steering अब सीधे खुद काम करने जैसा नहीं रहा; मॉडल अपने agents चलाकर research, writing और cross-verification पूरा करता है और अंत में तैयार परिणाम लौटा देता है
    • patron जहाँ किसी एक कलाकार को commission करता है, उसके बजाय Fable पूरे studio जैसा है, जहाँ patron काम की जगह पर कदम रखे बिना सिर्फ अंतिम परिणाम को approve करता है

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News राय

  • इस लेख में जनरेट किए गए कोड की गुणवत्ता और माध्यम के बारे में ठोस बात लगभग न के बराबर है, यह दिलचस्प लगा
    मैं जानना चाहूँगा कि कोड में documentation और tests हैं या नहीं, क्या उसे समझना और extend करना संभव है, क्या वह सुरक्षित है, और उसमें कौन-सी language, framework, database इस्तेमाल किए गए। लेखक ने judgment और taste की बात की, लेकिन असल कोड भी taste के साथ लिखा गया है या नहीं, यह पता नहीं। अगर उससे कोई नया feature जोड़ने को कहा जाए, तो क्या मॉडल पूरी architecture फिर से बदलते हुए फिर 9.5 घंटे के tokens खपा देगा, यह भी सवाल है। research वाला हिस्सा शायद domain knowledge का है—यानी अलग-अलग travel types के हिसाब से समय को कैसे convert करके देखने लायक बनाया गया—तो यह भी जानने की उत्सुकता है कि लेखक ने इसे verify कैसे किया
    ये सवाल सिर्फ AI पर लागू नहीं होते। अगर किसी human agency को पैसे देकर “यह काम करता है” वाला deliverable मिला होता, तब भी मैं यही सब पूछता। अगर मुझे evaluate करना न आता, तो evaluate करने वाला किसी को hire करता। LLMs में सबसे बड़ी अड़चन verification है

    • ऐसे लेख software engineers बहुत कम लिखते हैं; आम तौर पर इन्हें tech executives, retired engineers, या VCs लिखते हैं
      लगता है लेखक Wharton School of Management के professor हैं। ऐसे लोगों को असली product launch करने या उसे maintain करने की ज़रूरत नहीं होती; यह ज़्यादा एक side project बनाने जैसा है
      ठीक-ठाक software engineering नज़रिए से लिखा हुआ मुझे लगभग सिर्फ Mitchell Hashimoto से ही देखने को मिला है
    • अब यह समझ आने लगा है कि LLMs कम-जोखिम वाले projects बनाने में वाकई बहुत अच्छे हैं
      ऊपर के सवाल ज़्यादातर ज़्यादा जोखिम वाली स्थितियों को मानकर चलते हैं—जहाँ software लंबे समय तक maintain होना है, requirements बदलती रहेंगी, और गलतियों की गुंजाइश नहीं है
      software में LLMs का अच्छा इस्तेमाल शायद इस बात को सीखना है कि हर project को low-risk कैसे बनाया जाए
    • पिछले लगभग 2 साल की सारी LLM चर्चा कुछ ऐसी ही रही है
      जैसे ही आप ठोस बातें माँगते हैं, जवाब आता है, “इंसान भी यह ठीक से नहीं कर पाते!”। quantitative evidence बहुत कम है, शुद्ध rhetoric बहुत ज़्यादा
    • मॉडल जितने बेहतर होते जाएँगे, शायद कोड कैसा दिखता है यह सच में इतना महत्वपूर्ण न रहे
      अगर software का observable behavior अच्छा है, तो software अच्छा है। किसी भी तरह का bug अगर मॉडल vibe-coded codebase में ठीक कर सकता है, तो वह ठीक होने लायक bug है। अगर exploit की जा सकने वाली vulnerabilities नहीं हैं, तो कोड सुरक्षित है, और performance पर्याप्त है, तो performance अच्छी है
      बाहर से जो काम होना चाहिए वह हो रहा हो, और अंदर समस्या मिलने पर मॉडल उसे ठीक कर सके, तो कोड का आकार-प्रकार मायने नहीं रखता। software engineering अब पहले से कहीं ज़्यादा इस बात को सुनिश्चित करने का काम बन गई है कि कोड इरादे के मुताबिक behave करे
      और अगर कोड का आकार-प्रकार महत्वपूर्ण भी हो, तो वह भी मॉडल से ठीक कराया जा सकता है
    • मैंने उदाहरणों में से एक, “एक Snake game जिसमें साँप self-aware हो जाता है और अजीब चीज़ें होती हैं,” पर क्लिक किया, लेकिन 1–2 मिनट खेलने पर वह बस 1980s वाला Snake game निकला
      समझ नहीं आया कि मैं क्या मिस कर रहा हूँ। क्या “self-aware” से मतलब स्क्रीन के नीचे आने वाले कुछ मज़ेदार messages हैं? “अजीब चीज़ें” क्या हैं, यह भी समझ नहीं आया

  • मैंने Fable में वे models डालकर देखे जिन्हें मैं हाथ से verify किया करता था
    मोटे तौर पर तरीका यह था: Opus से scenario model करवाओ, उससे math दिखाने को कहो, फिर सुधारो और दोहराओ, और आखिर में दोबारा check करो कि code model की logic से मेल खाता है या नहीं। Fable ने मेरे पाए लगभग सारे errors पकड़ लिए, और कुछ अतिरिक्त variables के बारे में दिलचस्प सुझाव भी दिए
    बस usage limit को उसने 90s के आख़िरी दौर वाले Hummer की तरह जला डाला

    • मैं Max 5x subscription पर हूँ, और Fable ने 40 मिनट की code review session में मेरी weekly limit का 16% खा लिया
      review पूरा भी नहीं हुआ, और memory safety वाले उस अहम हिस्से में जहाँ सच में Fable की ज़रूरत थी, मुझे वापस Opus 4.8 पर लौटना पड़ा
      लग रहा है कि कीमत की वजह से जल्द ही ऐसे models इस्तेमाल करना मुश्किल हो जाएगा। शायद 22 जून तक Fable से जितना हो सके उतना निकाल लेना चाहिए
    • सबसे अहम सवाल यही है: यहाँ return on investment कितना है?

  • आज मैंने Fable के साथ एक personal project किया; वह काफ़ी solid लगा, लेकिन 4.8 से बहुत दूर नहीं
    वही hallucinations, वही तरह के bugs, और बड़े projects में जो माँगा गया है बस वही करना, जबकि उससे क्या touch, break, या impact हो सकता है उसे नज़रअंदाज़ कर देना—यह प्रवृत्ति भी वही है। शुरुआत में वह tests चलाता है, लेकिन context बड़ा होते ही कहता है “बाद में चलाऊँगा”, और जब तक आप गाली देकर push न करें, आख़िर तक नहीं चलाता
    मैं इसे इस्तेमाल करता रहूँगा, लेकिन अभी के हिसाब से यह incremental improvement है, “OMG OMG OMG Mythos आ गया!” वाला स्तर नहीं

    • मेरा अनुभव उल्टा रहा। Fable ऐसा लगा जैसे वह सब कुछ पहले से भाँप लेता है और बिना पूछे सब कर देता है
      बहुत प्रभावशाली था और उसके साथ काम करना अच्छा लगा
      यह कोई अजीब बात भी नहीं, क्योंकि जब मैंने पहली बार subscribe किया था तब Opus भी बिल्कुल ऐसा ही था। Anthropic ने capacity shortage की वजह से Opus को कमजोर कर दिया—ऐसा meme काफ़ी फैला हुआ है; सच है या नहीं, पता नहीं। लेकिन यह ज़रूर सोचता हूँ कि क्या Fable का भी वही हाल होगा
    • मेरे project में 4.8 जिन चीज़ों को मिस कर गया, Fable ने उन्हें तुरंत और साफ़-साफ़ देख लिया
      लेकिन उन समस्याओं को एक-एक करके पार करते हुए उसने मुझे काफ़ी प्रभावित किया, और थोड़ी ही देर बाद वह फिर हमेशा की तरह कुछ करने के बजाय बस बोलते रहने वाले infinite loop में फँस गया, और कभी-कभी रुक भी जाता था, फिर मुझे दोबारा टोकना पड़ता था
      इसलिए यह AGI नहीं है। फिर भी, सुधार साफ़ दिखता है

  • लेख की यह छोटी-सी पंक्ति डरावनी है: “लेकिन software engineer उन बाकी संभावित bugs को polish कर देगा जिन्हें मैं जल्दी नहीं ढूँढ पाया”
    हर software developer जानता है कि यह एक बहुत खतरनाक और अवास्तविक assumption है

    • यह असल में हर वास्तविक काम को बड़ी आसानी से किनारे कर देने वाली छोटी-सी पंक्ति है

  • लेखक जिस लेख को “AI द्वारा बनाया गया सबसे परिष्कृत academic social science paper” कह रहा है, उसके शुरुआती कुछ paragraphs पढ़े, लेकिन वह उम्मीद जितना प्रभावशाली नहीं था
    जैसे: “बाज़ार की मांग के बारे में posterior beliefs पूरी तरह reference-point dependent हैं। fundraising amount को स्थिर रखने पर, founder सिर्फ अपने तय किए गए लक्ष्य के मुकाबले performance को track करता है। threshold पर standard deviation के आधे जितनी छलाँग होती है, उसके बाद पहले 10 points पर तेज़ प्रतिक्रिया आती है, और फिर वह flatten हो जाती है”
    इंसान आम तौर पर data को इस तरह शब्दों में नहीं खोलते। summary document भी काफ़ी फुलाया हुआ लगा

  • यही वह जगह है जहाँ समस्या सबसे साफ़ दिखती है
    लेखक ने prompt में यह डाल दिया कि सारा data वास्तविक और verified होना चाहिए, और फिर बस उस पर भरोसा कर लिया। data-driven project में भी उसने यही किया। लोग यही काम अनगिनत बार करेंगे, यहाँ तक कि महत्वपूर्ण चीज़ों में भी

    • काश यह बात मुझे ज़िंदगी में पहले पता चलती—अगर कोई check ही नहीं करने वाला, तो मैं कहीं ज़्यादा यकीन दिलाने वाली तरह से गढ़ सकता था

  • “मैंने 9 घंटे 30 मिनट काम किया” वाला हिस्सा और “यह परफेक्ट नहीं था। एक विशेषज्ञ के रूप में मैंने कुछ errors और omissions पाए और AI से उन्हें ठीक करवाया” वाला हिस्सा ध्यान खींचता है
    मैं यह उम्मीद नहीं करता कि एक दिन में एक समस्या पर इतना लंबा समय लगाऊँगा, और न ही यह कि core reward loop कुछ घंटों के output को फिर से ठीक करने में इतना लंबा समय लेगा
    मेरे ग्राहक अभी agent response time को 85 सेकंड से घटाकर 20 सेकंड से नीचे लाने की मांग कर रहे हैं
    साथ ही, industry को agents के ज़रिए एक घंटे से ज़्यादा लंबे workflow की ओर जाते देखना बहुत विसंगतिपूर्ण लगता है

    • Claude का बचाव करूँ तो, और यकीन मानिए, मैं सच में उसका बचाव कर रहा हूँ, मैं ऐसा कोई अकेला developer नहीं जानता जो 19-पेज के design document से Concord जैसी चीज़ 9.5 कार्य-घंटों में बना दे
      हम फिर उस दौर में लौटेंगे जहाँ boss पूछेगा कि तुम बस बैठे क्यों हो। बस फर्क इतना होगा कि “compile हो रहा है” की जगह “Claude का इंतज़ार कर रहा हूँ” कहा जाएगा
    • इस बिंदु पर, अगर मुझे कहीं ज़्यादा पैसे मिलें तो मैं खुद कर लूँगा
    • मेरा Opus 4.8 एक गैर-तुच्छ single coding request पर भी नियमित रूप से 10 मिनट से ज़्यादा लेता है
    • काम में लगा समय कोई खास उपयोगी metric नहीं है
      आम तौर पर बेहतर यह होता है कि आप process को खुद code में define करें, और वही code काम के chunks को models को delegate करे। असली समस्या बस यह है कि providers के subscription discounts का फायदा उठाना मुश्किल हो जाता है
      दूसरी तरफ, model routing खुद करना आसान हो जाता है। मैंने अभी तक कोई ऐसा सामान्य chatbot नहीं देखा जो कई दिनों या हफ्तों के workflow में consistently बना रहे
    • जब QWEN models आए, तभी से मुझे लगा कि हम पहले ही sigmoid region में दाखिल हो चुके हैं
      अगर project को ठीक से structure किया जाए, तो आप इसे मनचाहे extension point की ओर इशारा करके लगभग 30 मिनट चलने दे सकते हैं ताकि functionality बढ़े। यह पूरे codebase पर प्रभावी ढंग से ‘god mode’ नहीं कर सकता, लेकिन एक सावधान observer और code expert के रूप में 128GB VRAM से ज़्यादा अनिवार्य नहीं लगता
      यह हैरान करने वाला है कि नए models का गैर-वार्तालापी उपयोग इतना आगे आ गया है, और अगर चीन ऐसे models के लिए silicon बनाना शुरू कर दे, तो लगता है खेल खत्म हो जाएगा

  • मुझे बहुत जिज्ञासा है कि कविता वाला prompt क्या था
    विचार परिचित लगा, इसलिए खोजते-खोजते मुझे 14 साल पुरानी reddit की एक कविता मिली: [https://www.reddit.com/r/RedditDayOf/comments/tjjw2/may_12_a...]
    यह लेखक द्वारा साझा की गई चीज़ जितनी लंबी नहीं है, लेकिन विचार वही है
    यह पोलिश लेखक Stanislaw Lem के SF दंतकथा-संग्रह “The Cyberiad” से है। एक कहानी में robot-निर्माता Trurl एक कविता लिखने वाली मशीन बनाता है, और उसका ईर्ष्यालु प्रतिद्वंद्वी Klapaucian उस मशीन से यह मांग करता है: “बाल कटाने पर कविता! लेकिन उदात्त, महान, दुखांत, शाश्वत, प्रेम और विश्वासघात, प्रतिशोध, शांत वीरता और निश्चित विनाश के सामने की कविता! छह पंक्तियाँ, चतुर तुकबंदी के साथ, और हर शब्द s से शुरू होना चाहिए!”
    कंप्यूटर इस तरह जवाब देता है:
    “Seduced, shaggy Samson snored.
    She scissored short. Sorely shorn,
    Soon shackled slave, Samson sighed.
    Silently scheming,
    Sightlessly seeking
    Some savage, spectacular suicide”
    ऐसा लगता है कि लेखक ने Fable/Mythos को challenge देते समय इसी दृश्य का संदर्भ लिया होगा। असल prompt क्या था, यह जानने की जिज्ञासा है

    • दिलचस्प बात यह है कि यह अंग्रेज़ी अनुवाद की कठिनाई है
      अंग्रेज़ी अनुवाद में पोलिश मूल से अलग शुरुआती अक्षर और अलग शब्द हैं:
      Cyprian cyberotoman, cynik, ceniąc czule
      Czarnej córy cesarskiej cud ciemnego ciała,
      Ciągle cytrą czarował. Czerwieniała cała,
      Cicha, co-dzień czekała, cierpiała, czuwała...
      ... Cyprian ciotkę całuje, cisnąwszy czarnulę!!
      translator के काम की तुलना LLM से की जा सकती है। दोनों ही derivative काम हैं, constraints के भीतर काम करते हैं, लेकिन creativity की गुंजाइश रहती है
    • हो सकता है कि लेखक ने उस दृश्य का संदर्भ न लिया हो, बल्कि Anthropic ने reddit comments का license लिया है, तो यह training data से भी सोखा गया हो सकता है

  • उन्होंने इसे एक घंटे से भी कम इस्तेमाल किया है, इसलिए यह भी ध्यान रखना चाहिए कि वे नई technology को लेकर उत्साहित अवस्था में हैं
    मेरे project(https://github.com/tsz-org/tsz) के मामले में, मैं लगातार इस बात से निराश रहा कि models पर्याप्त जांच नहीं करते और दूसरी परिस्थितियों पर विचार नहीं करते। model एक चीज़ ठीक करने वाला code बनाता, और बार-बार दो “असंबंधित लगने वाले” tests तोड़ देता
    Fable में काम शायद कहीं ज़्यादा समय लेता है, और मैंने अभी तक किसी Fable session में pull request नहीं देखा है, लेकिन session logs पढ़ने पर दिखता है कि यह कोई कसर न छोड़ने वाले तरीके से सही काम कर रहा है
    जैसा कि लेख में कहा गया है, ऐसे models की “feel” project दर project इतनी बदलती है कि इसे बताना कठिन है, फिर भी साझा कर रहा हूँ

    • क्या यह इस बात का संकेत नहीं है कि project की संरचना incrementally features जोड़ने में आसान नहीं हो सकती?

  • मुझे जिज्ञासा है कि लोग Mythos और Opus के बीच इतना बड़ा फर्क महसूस करने लायक आखिर किस तरह का काम कर रहे हैं।
    मुझे भी लगता है कि मैं काफ़ी उन्नत काम करता हूँ, लेकिन कई बार सिर्फ़ Deepseek ही काफ़ी होता है। यहाँ के लोग क्या सब के सब जीनियस हैं?

    • यह इस बात पर निर्भर करता है कि आप क्या बना रहे हैं।
      अगर आप Hades या Baazar जैसे अच्छे इंडी गेम स्तर का वीडियो गेम बनाना चाहते हैं, और organic, interactive, animated-feel वाले UI elements, visual effects, complex shaders वगैरह बना रहे हैं, तो कोई भी model इतना काफ़ी नहीं है कि वह इसे आसानी से पूरा कर दे। टॉप 3% गेम्स में आने वाली समस्याओं का बड़ा हिस्सा सिर्फ़ साधारण prompts से किसी भी model के लिए सच में बहुत मुश्किल होता है।
      निजी तौर पर मुझे खुद coding करना और सीखना पसंद है, इसलिए मैं इस पर ज़्यादा ध्यान नहीं देता, और DeepSeek Flash स्तर का model मेरे लिए काफ़ी है। फिर भी ऐसे बहुत से benchmarks बनाना बेहद आसान है जिनके करीब भी सबसे अच्छे models नहीं पहुँच पाते, और मुझे ऐसी समस्याओं पर test करना पसंद है कि model कितना बेहतर हो रहा है।
      वैसे, Fable 5, 4.8 से निश्चित रूप से थोड़ा बेहतर है।
    • यह कुछ वैसा ही है जैसे नया laptop announce होते ही employees अचानक कहने लगते हैं कि अब सबको upgrade चाहिए।
      जबकि असल में 90% लोग Macbook Neo पर भी आराम से काम चला सकते हैं।
    • हाल में मैं Rust में एक सामान्य web infrastructure तरह का project implement कर रहा हूँ।
      मैं rustls, Tokio जैसे Rust के अच्छे building blocks का खूब इस्तेमाल करके memory-safe, या उसके काफ़ी करीब, nginx replacement बनाने की कोशिश कर रहा हूँ।
      इसी काम के हिस्से के रूप में मैं Lua in Rust का एक high-quality repository भी बना रहा हूँ। मैं अपने Lua interpreter की performance समस्या, जहाँ gpt 5.5 और Opus 4.8 अटक गए थे, Mythos से ठीक करवा रहा हूँ।
      मुझे नहीं पता Mythos इसे हल कर पाएगा या नहीं, लेकिन यह कई घंटों से चल रहा है और नतीजे काफ़ी promising हैं।
      अगर जिज्ञासा हो, तो performance chart यहाँ है: https://github.com/ianm199/lua-rs
    • मैं खुद एक programming language बना रहा हूँ।
      साथ ही मैं ऐसे open source projects भी देख रहा हूँ जिनमें योगदान दिया जा सके। मैं कुछ ऐसा ढूँढ़ रहा हूँ जो hobby developer से professional बनने में मदद कर सके, हालांकि पता नहीं आजकल के दौर में यह संभव भी है या नहीं।
      Fable 5 ने code review में काफ़ी सारी ऐसी समस्याएँ पकड़ीं जो Opus 4.8 से छूट गई थीं। यह तब भी हुआ जब बेवकूफ़ाना cyber security restrictions की वजह से model को कमजोर कर दिया गया था। इससे ज़्यादा कहना मुश्किल है, क्योंकि Max 5x में हर 5 घंटे की window में सिर्फ़ एक session मिलता है। अभी तक मैंने सिर्फ़ दो sessions चलाए हैं।
    • अगर आप माँग का स्तर लगातार बढ़ाते जाएँ, तो किसी भी model को उसकी सीमा तक धकेलना मुश्किल नहीं होगा।
      मान लीजिए एक बहुत extreme prompt हो: “एक feature-complete और highly polished Facebook clone बनाओ।” Facebook जटिल है, लेकिन तकनीकी रूप से शायद बहुत कठिन नहीं है। फिर भी, काफ़ी tokens खर्च करने के बाद, उस prompt पर अलग-अलग models के output में कई पहलुओं पर काफ़ी बड़ा फर्क दिखेगा।
      बेशक ऊपर वाला अनुरोध वास्तव में उपयोगी नहीं है। लेकिन जब तक आप सीमा के क़रीब नहीं पहुँच जाते, तब तक बड़े chunks क्यों न सौंपें? किसी बिंदु पर आप boundary तक पहुँचेंगे, और फर्क साफ़ दिखने लगेगा।