हाल की Claude गुणवत्ता गिरावट से जुड़े तीन मुद्दों का पोस्टमॉर्टम विश्लेषण

• अगस्त से सितंबर की शुरुआत तक Claude के response quality में गिरावट की घटना तीन infrastructure bugs की वजह से हुई
• समस्या के मुख्य कारण क्रमशः context window routing error, output corruption, और XLA:TPU approximate top-k miscompile त्रुटि थे
• हर bug अलग-अलग hardware और deployment paths पर एक-दूसरे के साथ ओवरलैप हुआ, जिससे diagnosis और कठिन हो गया
• Detection और resolution में देरी के कारणों में validation process की कमियां और privacy policy के कारण access restrictions शामिल थे
• Anthropic ने evaluation और monitoring को मजबूत करने, और तेज debugging tools विकसित करने जैसे उपायों से ऐसी घटनाओं की पुनरावृत्ति रोकने की दिशा में कदम उठाए हैं

---

अवलोकन और पृष्ठभूमि

• अगस्त से सितंबर की शुरुआत तक Claude के response quality में बीच-बीच में गिरावट की रिपोर्ट मिली
• शुरुआत में इसे user feedback के भीतर सामान्य उतार-चढ़ाव माना गया, लेकिन रिपोर्ट लगातार बढ़ने पर जांच शुरू की गई
• Anthropic ने स्पष्ट किया कि इसका कारण demand या server load नहीं, बल्कि केवल infrastructure bugs थे
• Claude को लाखों users तक APIs, Amazon Bedrock, Google Vertex AI जैसे कई platforms के जरिए उपलब्ध कराया जाता है, और AWS Trainium, NVIDIA GPU, Google TPU जैसे अलग-अलग hardware पर समान परिणाम सुनिश्चित करने के लिए कड़े validation standards लागू हैं
• इस पोस्टमॉर्टम में bug के कारण, diagnosis और resolution में देरी के कारण, और recurrence रोकने के उपाय बताए गए हैं

Claude को बड़े पैमाने पर सेवा देने का तरीका

• Claude service कई hardware platforms (Trainium, GPU, TPU) के जरिए global deployment बनाए रखती है
• हर platform पर समान quality सुनिश्चित करने के लिए implementation equivalence standards सख्त हैं
• infrastructure में बदलाव होने पर सभी platforms और settings में सटीक validation process की आवश्यकता होती है

प्रमुख घटनाक्रम की समयरेखा

• 5 अगस्त: पहला bug, Sonnet 4 requests के लगभग 0.8% पर असर
• 25 और 26 अगस्त: दूसरा और तीसरा bug क्रमशः deploy हुए
• 29 अगस्त: load balancing बदलाव के कारण प्रभावित traffic तेजी से बढ़ा, और अधिक users प्रभावित हुए
• हर bug के symptoms एक-दूसरे पर चढ़े हुए थे, इसलिए diagnosis बहुत कठिन था

तीन ओवरलैपिंग bugs और समाधान प्रक्रिया

1. Context window routing error

• 5 अगस्त को Sonnet 4 की कुछ requests को 1M token context window के लिए बने servers पर गलत तरीके से route कर दिया गया
• load balancing बदलाव के बाद Sonnet 4 requests के अधिकतम 16% तक असर पड़ा, और Amazon Bedrock व Google Vertex AI पर भी मामूली असर देखा गया
• routing तरीका "sticky" था, इसलिए एक बार गलत server से जुड़ने पर आगे भी वही server बार-बार इस्तेमाल होता रहा
• समाधान: routing logic में सुधार, 4 सितंबर को Anthropic के अपने platform पर patch लागू, Google Cloud पर 16 सितंबर तक deploy, और Bedrock पर चरणबद्ध rollout जारी है

2. Output corruption (bug)

• 25 अगस्त को Claude API के TPU servers पर गलत setting लागू हो गई, जिससे token generation के दौरान errors होने लगे
• अंग्रेजी सवालों के जवाब में थाई या चीनी जैसे असंगत अक्षर मिल जाने, या code में साफ़ grammar errors जुड़ जाने जैसी समस्याएँ सामने आईं
• असर केवल Opus 4.1, Opus 4 और Sonnet 4 पर पड़ा; third-party platforms प्रभावित नहीं हुए
• समाधान: 2 सितंबर को बदलाव rollback किया गया, और abnormal character output detect करने वाले tests को deployment process में जोड़ा गया

3. Approximate top-k XLA:TPU miscompile error

• 25 अगस्त को token selection method को बेहतर बनाने के दौरान XLA:TPU compiler में एक latent bug सामने आया
• इसका असर Claude Haiku 3.5, कुछ Sonnet 4, और Opus 3 पर पड़ा
• third-party platforms प्रभावित नहीं हुए
• समाधान: Haiku 3.5 को 4 सितंबर और Opus 3 को 12 सितंबर को rollback किया गया; Sonnet 4 पर यह सीधे reproduce नहीं हुआ था, फिर भी एहतियातन rollback किया गया
• साथ ही XLA:TPU टीम के साथ मिलकर compiler bug को ठीक किया जा रहा है, और exact top-k method पर switch किया गया है

XLA compiler bug का विस्तृत विश्लेषण

• Claude token generation के दौरान हर candidate के लिए probability calculation और sampling करता है
• TPUs distributed environment में काम करते हैं, इसलिए token probabilities को synchronize करना पड़ता है, जो जटिल होता है
• 2024 के दिसंबर में bf16-32-bit mixed precision के कारण error से highest-probability token छूट जाने की समस्या मिली, जिसके लिए एक temporary fix deploy किया गया
• 26 अगस्त को root cause को हल करने के लिए sampling code में बदलाव के दौरान approximate top-k operation में एक और गहरा bug सामने आया, जिसमें कुछ मामलों में पूरी तरह गलत output आने लगा
• पहले का temporary fix इस समस्या को छिपा रहा था
• साथ ही approximate top-k bug के symptoms production environment और batch size के अनुसार अनियमित रूप से बदलते थे
• approximate top-k की जगह अब performance cost काफी कम हो जाने के कारण exact top-k अपनाया गया है, और प्रमुख operations को fp32 standardization के जरिए सुधारा गया है

Detection में देरी के कारण

• periodic automated evaluation और pre-group deployment जैसी प्रक्रियाएँ पहले से इस्तेमाल हो रही थीं
• इस घटना ने evaluation process की कमियों को उजागर किया। उदाहरण के लिए, कुछ evaluation items समस्या की स्थितियों को ठीक से detect नहीं कर पाए, और internal privacy policy (engineers को specific user requests तक पहुंच नहीं) की वजह से तेज analysis मुश्किल हुआ
• platform और version के हिसाब से symptoms अलग-अलग दिखे, इसलिए एक single root cause पहचानना कठिन था
• online reports बढ़ने के बावजूद, standard load balancing change से इसके संबंध को तुरंत पहचाना नहीं जा सका

आगे के सुधार और प्रतिक्रिया उपाय

• उच्च संवेदनशीलता वाले evaluation items विकसित करना, ताकि corrupted state और normal implementation के बीच automated evaluation अधिक स्पष्ट अंतर कर सके
• पूरे production environment में evaluation और monitoring systems का विस्तार, जैसे context window routing error जैसी runtime परिस्थितियों पर केंद्रित evaluation
• तेज और अधिक सटीक debugging tools तैयार करना, ताकि privacy बनाए रखते हुए community feedback का जल्दी analysis किया जा सके, इसके लिए infrastructure और custom tools विकसित किए जा रहे हैं
• internal evaluation के साथ-साथ user feedback के निरंतर संग्रह पर भरोसे पर जोर: जिन errors या bugs की भविष्यवाणी करना कठिन है, उनके लिए वास्तविक user reports अहम signal का काम करती हैं
• "/bug" command या 'thumbs down' फीचर का उपयोग, और email के जरिए model quality evaluation methods साझा करने को सक्रिय रूप से प्रोत्साहित किया गया है

संदर्भ विवरण

• XLA:TPU, XLA के high-level optimized language code को TPU instructions में बदलने वाला compiler है
• model size बड़ा होने के कारण इसे एक chip पर नहीं, बल्कि कई chips पर विभाजित करके रखा जाता है, और sorting operations जैसी चीज़ों को vectorized form में implement करना पड़ता है
• approximate top-k operation performance बढ़ाने के लिए उपयोगी है, लेकिन इसमें highest-probability token छूट जाने जैसी गंभीर समस्याएँ हो सकती हैं
• फिलहाल exact top-k method अपनाया गया है, और top-p threshold के करीब आने वाले tokens के शामिल होने के पैटर्न में हल्के बदलाव हो सकते हैं। कुछ मामलों में users को top-p value adjust करनी पड़ सकती है

[GN⁺]

Hacker News राय

• हाल में सबसे ध्यान देने वाली बात यह लगी कि unit tests की कमी है। XLA compiler bug के लिए test भी सिर्फ output print करने के स्तर के थे, असली unit tests जैसे नहीं जो test harness में चलें और coverage track करें। समाधान के तौर पर Eval पर ज़्यादा निर्भर रहने की बात कही जा रही है। अभी पूरे LLM के लिए unit testing व्यावहारिक नहीं है, लेकिन अब तक सामने आए ज़्यादातर bugs सिस्टम के छोटे deterministic हिस्सों में थे। जैसे load balancing, top-k probability calculation आदि दूसरे software की तरह engineered हिस्से हैं, इसलिए सिद्धांततः इनका unit test किया जा सकता है। ज़रूरत हो तो एक injectable PRNG काफ़ी होगा। nondeterministic optimization bugs निश्चित रूप से सिरदर्द हैं, लेकिन पहले पारंपरिक app test suite से compiler और database bugs भी पकड़े गए हैं। अगर CI में बहुत सारे tests बार-बार चलाए जाएँ, तो rare events भी सामने आ सकते हैं। मेरे एक निजी प्रोजेक्ट में सभी unit tests एक ही process में parallel चलाता हूँ, और इस तरीके से rare thread-safety issues और database deadlocks भी अच्छी तरह पकड़ पाया हूँ। कुछ दिन पहले Java लॉन्च से जुड़े thread में मैंने कहा था कि Java को Python से ज़्यादा 'enterprise' इसलिए माना जाता है क्योंकि code unit testing पर ज़ोर देकर लिखा जाता है। dependency injection जैसी ज़रूरतों के कारण abstraction भी ज़्यादा होती है। दूसरी तरफ scripting language संस्कृति में अक्सर testing या तो होती ही नहीं, या सिर्फ सतही रूप से होती है, जैसे केवल types assert करना। PyTorch सीखते समय भी ऐसा ही लगा; tutorial धीरे-धीरे जटिल विषयों तक जाते हैं, लेकिन testing या code structure पर लगभग कोई चर्चा नहीं होती। ML research में लक्ष्य evaluation score बढ़ाना होता है, पर यह बड़े पैमाने की production deployment के लिए उपयुक्त तरीका नहीं है। सोचता हूँ कि AI labs को SRE या HA software engineer पृष्ठभूमि वाले लोग ज़्यादा चाहिए। व्यक्तिगत रूप से मुझे संदेह है कि production में Eval को आक्रामक रूप से चलाना ही bug रोकने का सबसे अच्छा तरीका है
  • मुझे AI से Python में वैसी unit tests लिखवाने के लिए जैसा मैं चाहता था, बहुत detailed prompts और examples देने पड़े। अक्सर केवल types पर assertions का उपयोग करते भी देखा है। मैं values पर assertions चाहता हूँ। AI हर चीज़ को बहुत ज़्यादा mock करने की ओर झुकता है; mocking उपयोगी है, लेकिन unit test में जितना ज़्यादा असली code path को call किया जाए, उतना code interaction और interface risk भी cover होता है। लेकिन AI द्वारा बनाई गई Python unit tests अक्सर mocking पर इतनी अटक जाती हैं कि वे सिर्फ self-fulfilling (tautological) code ही verify करके रुक जाती हैं। इसलिए मैं prompts में mocking से सावधान रहने की चेतावनी और सावधानीपूर्वक test examples सक्रिय रूप से शामिल करता हूँ। वैसे Python में भी dependency injection जैसे structured code के लिए बेहतरीन tools हैं
• लेख में यह पढ़कर हैरानी हुई कि Anthropic, AWS Bedrock infrastructure को सीधे प्रभावित कर सकता है। यह AWS के मूल वादे के भी ख़िलाफ़ लगता है। मुझे लगता है Google Vertex AI के साथ भी यही सच हो सकता है, हालाँकि compliance के नज़रिए से मैंने अभी इसकी पुष्टि नहीं की है।

मैं इस बात से सहमत हूँ कि internal privacy और security policy के कारण engineers की Claude के user interactions तक पहुँच सीमित होती है। यह भी सही है कि user द्वारा सीधे feedback भेजना अब भी सबसे मददगार होता है, और Claude Code में /bug command इस्तेमाल की जा सकती है। उस command से रिपोर्ट करने पर engineers context देख सकते होंगे, लेकिन user के नज़रिए से यह प्रक्रिया बहुत स्पष्ट रूप से बताई जानी चाहिए (मैं Claude Code user नहीं हूँ)। Claude app में "thumbs down" button इस्तेमाल करने का निर्देश थोड़ा चिंताजनक है। ज़्यादातर users शायद यह नहीं सोचते कि इस button को दबाने का मतलब privacy छोड़ने जितना गंभीर हो सकता है

• (Anthropic कर्मचारी, व्यक्तिगत हैसियत से बोल रहा/रही हूँ)

यह सच नहीं है कि AWS Bedrock infrastructure को Anthropic सीधे manage करता है। अभी इसे AWS ही operate करता है। "thumbs down" button की privacy notice के बारे में, उस modal में साफ़ लिखा है: "इस feedback को submit करने पर, पूरी current conversation Anthropic को भेजी जाएगी और model improvement के लिए उपयोग होगी।" अगर इस message को और आसान बनाया जा सके तो जानना चाहूँगा/चाहूँगी कि कैसे

• "thumbs down" क्लिक करने पर "इस feedback को submit करने पर, पूरी conversation Anthropic को भेजी जाएगी" जैसा संदेश दिखता है, इसलिए मुझे लगता है कि यह notice काफ़ी स्पष्ट है
• Anthropic जैसी lab अगर infrastructure details साझा कर रही है, तो लगता है स्थिति काफ़ी कठिन रही होगी। असली FMA (fused multiply-add) precision bug वाकई दुर्भाग्यपूर्ण है, और numerical समस्याएँ अक्सर बेहद उलझाने वाली होती हैं; यह अब भी ऐसा क्षेत्र है जिसे AI हल नहीं कर सकता। जब प्रतिस्पर्धी real time में market share छीन रहे हों, ऐसे अत्यधिक दबाव में अंततः मानवीय दख़ल ज़रूरी होता है, और root cause ढूँढने में हफ़्ते लग सकते हैं
• इसमें कहा गया है, "29 अगस्त के load balancing बदलाव ने संयोग से 1M context servers पर ज़्यादा short-context requests भेजनी शुरू कर दीं, और 31 अगस्त को एक घंटे के दौरान Sonnet 4 requests का 16% प्रभावित हुआ।" इससे तो लगता है कि 1M context servers short-context input पर उल्टा खराब perform करते हैं। शायद इन servers पर KV cache compression, eviction, sparse attention जैसी अलग तकनीकें लागू हों?
  • यह RoPE (rotary position embedding) scaling की वजह से है। ज़्यादातर प्रसिद्ध open source frameworks static YaRN लागू करते हैं, जहाँ scaling factor input length से स्वतंत्र fixed रहता है, इसलिए short text processing पर performance प्रभावित हो सकती है। rope_scaling setting सिर्फ तब जोड़ने की सलाह है जब लंबा context सच में चाहिए, और factor भी application की average input length के हिसाब से adjust करना बेहतर है। उदाहरण के लिए अगर औसत लगभग 5.2 लाख tokens है, तो factor 2.0 बेहतर रहेगा स्रोत (Qwen3-Next-80B विवरण पृष्ठ)
  • इनके postmortem report की असली बात यह है कि तीन समस्याओं में से दो की सटीक जड़ वजह सामने नहीं आई। मेरी समझ से मेरी request इस समय तीन पूरी तरह अलग code paths में से किसी पर भी जा सकती है, और हर path पर अलग stack और tuning लागू है। यह optimization model version upgrade के बिना भी अचानक बदल सकती है, इसलिए जो कल काम कर रहा था वह आज टूट सकता है। ऐसे postmortem की तारीफ़ देखकर समझ नहीं आता; उल्टा इससे और निराशा होती है
• Anthropic टीम के प्रति सम्मान रखते हुए कहूँगा कि Claude status page की गुणवत्ता ऐसी है कि अंदरूनी तौर पर code red बज जाना चाहिए। जुलाई में 50, अगस्त में 40, और सितंबर में 21 incidents हुए। पहले मुझे ऐसे हालात में इसका आधा भी दिखता तो सबको uptime और quality पर फ़ोकस करने के लिए कड़ी दिशा दे दी जाती। फिर भी Claude अभी भी इतना अच्छा product है कि मैं paid customer बना हुआ हूँ। API आज़माई और तुरंत Max membership ले ली। उससे productivity बहुत बढ़ी। लेकिन हाल के हफ़्तों में बार-बार हुई quality degradation के कारण सोचने लगा हूँ कि subscription जारी रखूँ या नहीं। समस्या की स्थिति ईमानदारी से साझा करने के लिए शुक्रिया, लेकिन customer के तौर पर असंतोष है। मेरा मानना है कि load balancing जैसी समस्याएँ अब भी न पूरी तरह detect हुई हैं, न solve। खास तौर पर 12 बजे (Eastern) / 9 बजे (Pacific) के आसपास Claude Code की quality मुझे स्पष्ट रूप से गिरती हुई लगती है। उम्मीद है टीम लगातार समस्या ढूँढ़ती और ठीक करती रहेगी। घर पर local models चलाते समय भी बहुत जटिल bugs झेले हैं, इसलिए समझता हूँ कि ये समस्याएँ आसान नहीं हैं। status page लिंक
  • मैं यह निश्चित नहीं कह सकता कि दूसरी कंपनियों की तुलना में Claude बेहतर है या बदतर, लेकिन एक बात पक्की है: बहुत-सी कंपनियों के status pages झूठ बोलते हैं। असल में outages अक्सर होते हैं, लेकिन status page पर दिखते नहीं। अब तो जब कोई ईमानदारी से समस्या बताता है, वही ज़्यादा चौंकाता है। व्यक्तिगत रूप से मुझे Claude में कोई गंभीर issue नहीं मिला, हालाँकि हो सकता है मैं lucky रहा हूँ। मेरी नज़र में Claude शायद outage reporting में उल्टा ज़्यादा ईमानदार है। बेशक यह सिर्फ संयोग भी हो सकता है
  • और भी चिंताजनक बात यह है कि status page पर कई छोटे incidents छूट जाते हैं। सभी AI providers में यही हाल है। अगर वे real-time token latency, failed requests, और tokens per second जैसी metrics graphs सार्वजनिक करें, तो नज़ारा काफ़ी चौंकाने वाला होगा। OpenRouter data देखने पर साफ़ है कि API uptime उतना अच्छा नहीं है। Claude Code भी कई बार इतना slow हो जाता है कि उसे manually रोककर retry करना पड़ता है। खासकर UK समयानुसार शाम 4–6 बजे के बीच यह बहुत खराब होता है, जब Europe, US East और US West सबका peak overlap होता है। आज भी Gemini AI studio में model overload के कारण 503 error आया, लेकिन status page पर कुछ नहीं दिखा। सोचता हूँ Claude वगैरह अगर off-peak समय में सस्ते plans दें तो demand को spread किया जा सकता है। हालांकि ऐसा pricing बाहर से नकारात्मक भी दिख सकता है। साथ ही, लगता है GB200 GPU का rollout उम्मीद से कहीं धीमा था और hardware/software defects भी काफ़ी थे। liquid cooling की समस्याएँ भी कम नहीं रही होंगी (और failure होने पर विनाशकारी)
  • "फिर भी Claude इतना अच्छा है कि मैं पैसे देता हूँ" — यह अपने आप में अहम संकेत है। इस समय AI quality, service reliability से ज़्यादा महत्वपूर्ण है ग्राहकों के लिए, मेरे लिए भी। हाँ, provider बाद में reliability पर ध्यान देंगे, लेकिन अभी quality से ऊपर reliability को प्राथमिकता क्यों दी जाए?
  • हाल की quality crash से मैं काफ़ी अस्थिर महसूस कर रहा हूँ। अच्छी बात है कि मैं अभी production service में AI का उपयोग नहीं कर रहा, लेकिन development के दौरान अगर model अचानक 'बेवकूफ़' हो जाए, तो उससे बच निकलना सच में मुश्किल है। इस समय मुझे यह भी शक होता है कि openrouter के अलग-अलग vendors भरोसा तोड़ते हुए चुपचाप context घटा रहे हों, quantization कम कर रहे हों, या experts की संख्या घटाकर compute resources बचा रहे हों
  • इसी वजह से status page पर incidents की संख्या कम-से-कम दिखाने की रणनीति अपनाई जाती है। customer ratings थोड़े समय के लिए खराब होती हैं, लेकिन समय के साथ नकारात्मक असर मिट जाता है। जबकि अगर status page लगातार maintain किया जाए तो समस्याओं का साफ़ 'सबूत' रह जाता है। लंबी अवधि में धोखा देना ही ज़्यादा फ़ायदेमंद पड़ता है। वास्तव में S3 में कई बार errors जैसे outages हुए, लेकिन सार्वजनिक नहीं किए गए और किसी ने मुद्दा नहीं बनाया। लोग बहुत कुछ कहते हैं, लेकिन व्यवहार में इनाम उसी को मिलता है जो छिपाता है। सारे startup growth hackers यह बात पहले से जानते हैं
• इसमें बताया गया है कि 25 अगस्त को Claude API TPU server पर गलत configuration deploy हो गई, जिससे token generation के दौरान errors हुए। code bugs तो समझ आते हैं, लेकिन LLM तो इंसान सीधे नहीं लिखते; वे बड़े पैमाने की automated training से बनते हैं। ऐसे में यह bug कैसे हो सकता है, यह जानने की जिज्ञासा है। उदाहरण के लिए अगर model अंग्रेज़ी query के बीच अचानक 'สวัสดี' (Thai) उछाल दे, तो संरचनात्मक रूप से ऐसा bug इंसानी स्तर पर कैसे inject हो सकता है?
  • LLM आखिरकार इंसानों द्वारा लिखे code से ही चलाए जाते हैं। अंतिम चरण में model पूरे token vocabulary (लगभग 2 लाख tokens) पर probability distribution बनाता है। उसके बाद असली next token किस तरीके से चुना जाएगा, यह इंसान तय करते हैं। उदाहरण के लिए हमेशा highest-probability token चुनना, या creativity बढ़ाने के लिए top-k में से random selection करना। इस top-k sampling को कुशलता से चलाने के लिए XLA से kernel compile किया जाता है, और लगता है इसी kernel में bug होने से कभी-कभी top-k के बाहर का token चुन लिया जाता था
  • LLM next token के लिए probability distribution देता है, और असली output sampling method उदाहरण पर निर्भर करती है। जैसे अगर नियम हो "सबसे अधिक probability वाले 4 tokens में से random चुनो" और operator (inequality) गलत हो जाए, तो लेख में बताए गए जैसा व्यवहार दिख सकता है
  • user और model parameters के बीच इंसानों द्वारा लिखी गई code layers की कई परतें होती हैं
  • सरल शब्दों में कहें तो दो चरण होते हैं: training और inference। training लंबा automated process है, लेकिन inference वह अलग software stack है जो user prompt आते ही तुरंत चलता है। इस stack को लगातार performance-improving updates मिलते रहते हैं, और उसी दौरान ऐसे inference-related issues पैदा हो सकते हैं
  • AI kernels floating-point operations पर चलते हैं, इसलिए सामान्य real-number intuition के उलट non-negative value भी अजीब तरह से negative बन सकती है। performance के लिए overflow checks बंद कर दिए जाते हैं, और अगर negative निकल आए तो कभी-कभी उसे बहुत बड़े number की तरह treat किया जाता है, जैसे -1वाँ array index माँगने पर आख़िरी element मिल जाना
• लगता है LLM inference को deterministic बनाने पर विचार करना issue tracking में मददगार हो सकता है। हाल ही में एक paper भी आया है कि "floating-point association order" को जो मुख्य कारण माना जाता था, वह असल में पूरी कहानी नहीं है संबंधित paper परिचय
  • network traffic और machine load स्वभावतः nondeterministic होते हैं। निकट भविष्य में पूरी determinism, जैसे auditing के लिए, सिर्फ उन batch jobs में व्यावहारिक है जहाँ cost sensitivity कम हो। वास्तव में Google Search भी deterministic नहीं है, social media recommendation loading भी नहीं। distributed systems में असली सलाह graceful degradation की होती है, लेकिन पूरी तरह deterministic system में ऐसा करना संभव नहीं होता
  • deterministic design performance को नुकसान पहुँचाती है। अंत में शायद यही रास्ता बचता है कि एक और model बनाया जाए, जो पहले model की quality पर निगरानी रखे और alert करे — एक तरह का 'IQ test' approach
• "Google Cloud Vertex AI में 27 अगस्त से 16 सितंबर के बीच गलत routing 0.0004% से कम थी" — यह बात मुझे विश्वसनीय लगती है। मैं काम के लिए उसी account से CC इस्तेमाल करता हूँ और quality drop महसूस नहीं हुई। कुल मिलाकर, bugs गंभीर तो थे, लेकिन online reviews में जितना कहा गया उससे कहीं अधिक दुर्लभ लगे। issue period भी असल में ज़्यादातर 1–2 हफ़्तों में सिमटा हुआ था। कुल requests की तुलना में प्रभावित अनुपात भी अपेक्षाकृत छोटा था
  • लेकिन कंपनी के लेख में खुद लिखा है कि "Claude Code users में से 30% को कम-से-कम एक बार गलत server पर route किया गया, जिससे response quality गिर गई।" routing 'sticky' थी, इसलिए एक बार गलत server मिलने के बाद लगातार उसी पर requests जाती रहीं। अगर Claude Code users के 30% ने quality degradation झेली, तो यह बहुत बड़ा bug है
  • हाल के समय में, चाहे global outage ही क्यों न हो, कंपनियाँ अक्सर बस इतना कहती हैं कि "कुछ कम users के लिए errors बढ़े" और status page तभी update होता है जब CTO मंज़ूरी दे। इसलिए कंपनियों पर आसानी से भरोसा नहीं होता। अगर कोई कंपनी सचमुच ईमानदार communication करे, तो वह बाज़ार में एक ताकत बन सकती है
• राय यह है कि LLM service को deterministic तरीके से चलाने योग्य बनाना समस्या tracing में सहायक होगा। हाल की एक paper में यह भी कहा गया कि जिन कारणों को पहले सिर्फ floating point association order पर डाला जाता था, दरअसल determinism टूटने के और भी कारण हैं। paper लिंक
• webapp design में हाल में मैंने देखा है कि Claude DOM में random text दिखाने लगता है। लगता है यह खास तौर पर svelte के साथ इस्तेमाल करने पर हुआ, हालाँकि यक़ीन नहीं कि इसका संबंध लेख में बताए गए issues से है; लेकिन पहले मैंने इतनी गंभीर quality degradation नहीं देखी थी
• काश पोस्ट में actual failure cases भी शामिल किए गए होते। Claude Code में tool call के बाद पूरी तरह रुक जाने वाली समस्या मुझे अक्सर मिली है; जानना चाहता हूँ कि क्या यह इस बार बताए गए bugs में से किसी से जुड़ी थी
  • मैंने भी पिछले कुछ दिनों में बिल्कुल यही समस्या तेज़ी से बढ़ती हुई देखी है। मेरा अनुमान है कि यह लेख वाले bug से अलग भी हो सकता है, हालांकि तब भी यह bug ही है। उम्मीद है मेरा अनुमान गलत हो। "आप क्यों रुके? आगे बढ़िए" जैसी बातें बार-बार भेजने की ज़रूरत साफ़ तौर पर बढ़ गई है