Avqust və sentyabrın əvvəlləri arasında üç infrastruktur xətası fasilələrlə Claude-un cavab keyfiyyətini aşağı saldı. Biz indi bu problemləri həll etdik və nə baş verdiyini izah etmək istəyirik.
Avqustun əvvəlində bir sıra istifadəçilər Claude-dan alınan cavabların keyfiyyətinin aşağı düşdüyünü bildirməyə başladılar. Bu ilkin hesabatları istifadəçi rəylərindəki normal dəyişikliklərdən fərqləndirmək çətin idi. Avqustun sonlarında bu hesabatların artan tezliyi və davamlılığı bizi araşdırma açmağa vadar etdi və bu, üç ayrı infrastruktur xətasını aşkar etməyimizə səbəb oldu.
Açıq şəkildə bildirək: Biz heç vaxt tələb, günün vaxtı və ya server yükünə görə model keyfiyyətini azaltmırıq. İstifadəçilərimizin bildirdiyi problemlər yalnız infrastruktur xətalarından qaynaqlanırdı.
Biz anlayırıq ki, istifadəçilər Claude-dan ardıcıl keyfiyyət gözləyirlər və biz infrastruktur dəyişikliklərinin model çıxışlarına təsir etməməsini təmin etmək üçün son dərəcə yüksək standartlar saxlayırıq. Bu son insidentlərdə biz həmin standartlara cavab verə bilmədik. Aşağıdakı post-mortem təhlil nəyin səhv getdiyini, aşkarlanma və həllin niyə istədiyimizdən daha uzun çəkdiyini və gələcəkdə oxşar insidentlərin qarşısını almaq üçün nəyi dəyişdirdiyimizi izah edir.
Biz adətən infrastrukturumuz haqqında bu səviyyədə texniki detalları paylaşmırıq, lakin bu problemlərin miqyası və mürəkkəbliyi daha əhatəli bir izahatı zəruri etdi.
Claude-u miqyaslı şəkildə necə xidmət edirik
Biz Claude-u milyonlarla istifadəçiyə birinci tərəf API-miz, Amazon Bedrock və Google Cloud-un Vertex AI vasitəsilə xidmət edirik. Claude-u müxtəlif hardware platformalarında yerləşdiririk, yəni AWS Trainium, NVIDIA GPU-lar və Google TPU-lar. Bu yanaşma dünya üzrə istifadəçilərə xidmət göstərmək üçün lazım olan tutum və coğrafi paylanmanı təmin edir.
Hər bir hardware platformasının fərqli xüsusiyyətləri var və xüsusi optimallaşdırmalar tələb edir. Bu fərqliliklərə baxmayaraq, model tətbiqləri üçün ciddi ekvivalentlik standartlarımız var. Məqsədimiz odur ki, istifadəçilər sorğularını hansı platformanın xidmət göstərməsindən asılı olmayaraq eyni keyfiyyətdə cavablar alsınlar. Bu mürəkkəblik o deməkdir ki, hər hansı bir infrastruktur dəyişikliyi bütün platformalar və konfiqurasiyalar üzrə diqqətli validasiya tələb edir.
Hadisələrin xronologiyası
Claude API-də hadisələrin illüstrativ xronologiyası. Sarı: problem aşkar edildi, Qırmızı: deqradasiya pisləşdi, Yaşıl: düzəliş tətbiq edildi.
Bu xətaların üst-üstə düşən xarakteri diaqnozu xüsusilə çətinləşdirdi. Birinci xəta avqustun 5-də tətbiq edildi və Sonnet 4-ə edilən sorğuların təxminən 0,8%-nə təsir etdi. Daha iki xəta avqustun 25-i və 26-sı yerləşdirmələrindən yarandı.
İlkin təsirlər məhdud olsa da, avqustun 29-da yük balanslaşdırma dəyişikliyi təsirlənmiş trafiki artırmağa başladı. Bu, daha çox istifadəçinin problemlərlə üzləşməsinə səbəb oldu, digərləri isə normal performans görməyə davam etdi və bu da qarışıq və ziddiyyətli hesabatlar yaratdı.
Üç üst-üstə düşən problem
Aşağıda deqradasiyaya səbəb olan üç xətanı, nə vaxt baş verdiklərini və onları necə həll etdiyimizi təsvir edirik:
1. Kontekst pəncərəsi yönləndirmə xətası
Avqustun 5-də bəzi Sonnet 4 sorğuları qarşıdan gələn 1M token kontekst pəncərəsi üçün konfiqurasiya edilmiş serverlərə səhv yönləndirildi. Bu xəta əvvəlcə sorğuların 0,8%-nə təsir edirdi. Avqustun 29-da adi yük balanslaşdırma dəyişikliyi təsadüfən qısa kontekst sorğularının 1M kontekst serverlərinə yönləndirilən sayını artırdı. Avqustun 31-də ən çox təsirlənmiş saatda Sonnet 4 sorğularının 16%-i təsirləndi.
Bu dövrdə sorğu göndərən Claude Code istifadəçilərinin təxminən 30%-nin ən azı bir mesajı səhv server tipinə yönləndirildi və bu, aşağı keyfiyyətli cavablarla nəticələndi. Amazon Bedrock-da səhv yönləndirilmiş trafik avqustun 12-dən etibarən bütün Sonnet 4 sorğularının 0,18%-nə çatdı. Google Cloud-un Vertex AI-da avqustun 27-si ilə sentyabrın 16-sı arasında sorğuların 0,0004%-dən azı səhv yönləndirilmədən təsirləndi.
Lakin bəzi istifadəçilər daha ciddi şəkildə təsirləndi, çünki yönləndirməmiz "yapışqan" xarakter daşıyır. Bu o demək idi ki, bir sorğu səhv server tərəfindən xidmət edildikdən sonra, sonrakı sorğular da eyni səhv server tərəfindən xidmət edilmə ehtimalı yüksək idi.
Həll: Qısa və uzun kontekst sorğularının düzgün server hovuzlarına yönləndirilməsini təmin etmək üçün yönləndirmə məntiqini düzəltdik. Düzəlişi sentyabrın 4-də tətbiq etdik. Birinci tərəf platformamıza və Google Cloud-un Vertex AI-na yayılması sentyabrın 16-da, AWS Bedrock-a isə sentyabrın 18-də tamamlandı.
2. Çıxış korrupsiyası
Avqustun 25-də Claude API TPU serverlərinə token generasiyası zamanı xətaya səbəb olan yanlış konfiqurasiya tətbiq etdik. İcra zamanı performans optimallaşdırmasından qaynaqlanan bir problem ara-sıra kontekstə görə nadir hallarda yaranmalı olan tokenlərə yüksək ehtimal təyin edirdi — məsələn, İngilis dilli sorğulara cavab olaraq Tay və ya Çin hərfləri istehsal etmək və ya kodda aşkar sintaksis xətaları yaratmaq. İngiliscə sual verən kiçik bir istifadəçi qrupu, məsələn, cavabın ortasında "สวัสดี" görə bilərdi.
Bu korrupsiya avqustun 25-28-i arasında Opus 4.1 və Opus 4-ə, avqustun 25-i – sentyabrın 2-si arasında isə Sonnet 4-ə edilən sorğulara təsir etdi. Üçüncü tərəf platformaları bu problemdən təsirlənmədi.
Həll: Problemi müəyyən etdik və dəyişikliyi sentyabrın 2-də geri qaytardıq. Gözlənilməz simvol çıxışları üçün aşkarlama testlərini yerləşdirmə prosesimizə əlavə etdik.
3. Approximate top-k XLA:TPU kompilyasiya xətası
Avqustun 25-də Claude-un mətn generasiyası zamanı tokenləri necə seçdiyini yaxşılaşdırmaq üçün kod tətbiq etdik. Bu dəyişiklik təsadüfən XLA:TPU[1] kompilyatorunda gizli bir xətanı aktivləşdirdi və bunun Claude Haiku 3.5-ə edilən sorğulara təsir etdiyi təsdiqləndi.
Həmçinin inanırıq ki, bu, Claude API-də Sonnet 4 və Opus 3-ün bir hissəsinə təsir edə bilərdi. Üçüncü tərəf platformaları bu problemdən təsirlənmədi.
Həll: Əvvəlcə xətanın Haiku 3.5-ə təsir etdiyini müşahidə etdik və sentyabrın 4-də geri qaytardıq. Daha sonra Opus 3 ilə bağlı bu xətaya uyğun gələn istifadəçi hesabatlarını gördük və sentyabrın 12-də geri qaytardıq. Geniş araşdırmadan sonra bu xətanı Sonnet 4-də təkrarlaya bilmədik, lakin ehtiyat məqsədi ilə onu da geri qaytarmaq qərarına gəldik.
Eyni zamanda, biz (a) kompilyator xətasının həlli üçün XLA:TPU komandası ilə işləyirik və (b) artırılmış dəqiqliklə exact top-k istifadəsinə keçid düzəlişini tətbiq etdik. Ətraflı məlumat üçün aşağıdakı dərin təhlilə baxın.
XLA kompilyator xətasına daha yaxından baxış
Bu problemlərin mürəkkəbliyini göstərmək üçün XLA kompilyator xətasının necə özünü göstərdiyini və niyə diaqnozunun xüsusilə çətin olduğunu izah edirik.
Claude mətn generasiya edərkən hər mümkün növbəti söz üçün ehtimalları hesablayır, sonra bu ehtimal paylanmasından təsadüfi nümunə seçir. Mənasız çıxışların qarşısını almaq üçün "top-p sampling" istifadə edirik — yalnız kumulyativ ehtimalı müəyyən bir həddə (adətən 0,99 və ya 0,999) çatan sözləri nəzərə alırıq. TPU-larda modellərimiz çoxlu çiplər üzrə işləyir və ehtimal hesablamaları müxtəlif yerlərdə baş verir. Bu ehtimalları sıralamaq üçün çiplər arasında məlumat koordinasiyası lazımdır ki, bu da mürəkkəbdir.[2]
2024-cü ilin dekabrında aşkar etdik ki, TPU tətbiqimiz temperature sıfır olduqda ara-sıra ən yüksək ehtimallı tokeni itirir. Bu halı həll etmək üçün müvəqqəti həll tətbiq etdik.
Temperature = 0 olduqda gözlənilməz itirilmiş token xətası üçün 2024-cü il dekabr yamağının kod fraqmenti.
Əsas səbəb qarışıq dəqiqlik arifmetikası idi. Modellərimiz növbəti token ehtimallarını bf16 (16-bit üzən nöqtə) formatında hesablayır. Lakin vektor prosessoru fp32-native olduğundan, TPU kompilyatoru (XLA) bəzi əməliyyatları fp32-yə (32-bit) çevirərək icra zamanı performansı optimallaşdıra bilər. Bu optimallaşdırma addımı defolt olaraq true olan xla_allow_excess_precision bayrağı ilə idarə olunur.
Bu uyğunsuzluğa səbəb oldu: ən yüksək ehtimallı token üzərində razılaşmalı olan əməliyyatlar fərqli dəqiqlik səviyyələrində işləyirdi. Dəqiqlik uyğunsuzluğu onların hansı tokenin ən yüksək ehtimala malik olduğu barədə razılığa gəlməməsinə səbəb oldu. Bu, ən yüksək ehtimallı tokenin bəzən tamamilə nəzərdən kənar qalmasına gətirib çıxardı.
Avqustun 26-da dəqiqlik problemlərini həll etmək və top-p həddinə çatan ehtimalları idarə etmə tərzimizi yaxşılaşdırmaq üçün sampling kodunun yenidən yazılmasını tətbiq etdik. Lakin bu problemləri həll edərkən daha çətin bir problemi üzə çıxardıq.
Avqustun 11-i dəyişikliyi ilə birləşdirilmiş minimizə edilmiş reproducer-in kod fraqmenti. Bu dəyişiklik 2024-cü il dekabrında müvəqqəti həll edilən "xəta"nın əsas səbəbini tapdı; əslində bu, xla_allow_excess_precision bayrağının gözlənilən davranışıdır.
Düzəlişimiz dekabr müvəqqəti həllini sildi, çünki əsas səbəbi həll etdiyimizə inanırdıq. Bu, approximate top-k əməliyyatında — ən yüksək ehtimallı tokenləri tez tapan performans optimallaşdırmasında — daha dərin bir xətaya gətirib çıxardı.[3] Bu yaxınlaşdırma bəzən tamamilə yanlış nəticələr qaytarırdı, lakin yalnız müəyyən batch ölçüləri və model konfiqurasiyaları üçün. Dekabr müvəqqəti həlli təsadüfən bu problemi maskalamışdı.
Alqoritmi hazırlayan XLA:TPU mühəndisləri ilə paylaşılan əsas approximate top-k xətasının reproducer-i. Kod CPU-larda işlədildikdə düzgün nəticələr qaytarır.
Xətanın davranışı məyusedici dərəcədə qeyri-ardıcıl idi. Ondan əvvəl və ya sonra hansı əməliyyatların icra edilməsi, debugginq alətlərinin aktiv olub-olmaması kimi əlaqəsiz amillərdən asılı olaraq dəyişirdi. Eyni sorğu bir istəkdə mükəmməl işləyə, növbətisində isə uğursuz ola bilərdi.
Araşdırma zamanı həmçinin aşkar etdik ki, exact top-k əməliyyatının artıq əvvəlki kimi yüksək performans cəriməsi yoxdur. Approximate-dən exact top-k-ya keçdik və bəzi əlavə əməliyyatları fp32 dəqiqliyinə standartlaşdırdıq.[4] Model keyfiyyəti müzakirə olunmazdır, ona görə də cüzi effektivlik təsirini qəbul etdik.
Aşkarlamanın niyə çətin olduğu
Validasiya prosesimiz adətən benchmarklar, təhlükəsizlik qiymətləndirmələri və performans metriklərindən istifadə edir. Mühəndislik komandaları nöqtəvi yoxlamalar aparır və əvvəlcə kiçik "canary" qruplarına tətbiq edirlər.
Bu problemlər daha əvvəl müəyyən etməli olduğumuz kritik boşluqları üzə çıxardı. Apardığımız qiymətləndirmələr istifadəçilərin bildirdiyi deqradasiyanı sadəcə tutmadı, qismən ona görə ki, Claude tək-tük səhvlərdən yaxşı bərpa olunur. Öz məxfilik təcrübələrimiz də hesabatların araşdırılmasında çətinliklər yaratdı. Daxili məxfilik və təhlükəsizlik nəzarətlərimiz mühəndislərin Claude ilə istifadəçi qarşılıqlı əlaqələrinə necə və nə vaxt daxil ola biləcəyini məhdudlaşdırır, xüsusən bu qarşılıqlı əlaqələr bizə rəy olaraq bildirilmədikdə. Bu, istifadəçi məxfiliyini qoruyur, lakin mühəndislərin xətaları müəyyən etmək və ya təkrarlamaq üçün lazım olan problemli qarşılıqlı əlaqələri araşdırmasının qarşısını alır.
Hər bir xəta fərqli platformalarda fərqli əlamətlər və fərqli nisbətlərdə yaradırdı. Bu, heç bir tək səbəbə işarə etməyən qarışıq hesabatlar yaratdı. Təsadüfi, qeyri-ardıcıl deqradasiya kimi görünürdü.
Daha əsaslı olaraq, biz həddindən artıq səs-küylü qiymətləndirmələrə güvənirdik. Onlayn hesabatların artdığından xəbərdar olsaq da, bunları son dəyişikliklərimizin hər biri ilə əlaqələndirməyin aydın yolu yox idi. Avqustun 29-da mənfi hesabatlar kəskin artdığında, bunu standart yük balanslaşdırma dəyişikliyi ilə dərhal əlaqələndirmədik.
Nəyi dəyişdiririk
İnfrastrukturumuzu yaxşılaşdırmağa davam edərkən, Claude-a xidmət göstərdiyimiz bütün platformalarda yuxarıda müzakirə edilən kimi xətaları qiymətləndirmə və qarşısını alma üsullarımızı da təkmilləşdiririk. Dəyişdirdiklərimiz bunlardır:
- Daha həssas qiymətləndirmələr: İstənilən problemin əsas səbəbini tapmağa kömək etmək üçün işləyən və xarab tətbiqləri daha etibarlı şəkildə fərqləndirə bilən qiymətləndirmələr hazırladıq. Model keyfiyyətinə daha yaxından nəzarət etmək üçün bu qiymətləndirmələri yaxşılaşdırmağa davam edəcəyik.
- Daha çox yerdə keyfiyyət qiymətləndirmələri: Sistemlərimizdə müntəzəm qiymətləndirmələr aparsaq da, kontekst pəncərəsi yük balanslaşdırma xətası kimi problemləri tutmaq üçün həqiqi istehsal sistemlərində davamlı olaraq işlədəcəyik.
- Daha sürətli debugginq alətləri: İstifadəçi məxfiliyini qurban vermədən icma tərəfindən təqdim edilən rəyləri daha yaxşı araşdırmaq üçün infrastruktur və alətlər hazırlayacağıq. Bundan əlavə, burada hazırlanan bəzi xüsusi alətlər gələcək oxşar insidentlərdə, əgər baş verərsə, aradan qaldırma müddətini azaltmaq üçün istifadə ediləcək.
Qiymətləndirmələr və monitorinq vacibdir. Lakin bu insidentlər göstərdi ki, Claude-dan gələn cavablar adi standartlara uyğun olmadıqda istifadəçilərdən davamlı siqnala da ehtiyacımız var. Müşahidə edilən spesifik dəyişikliklərin hesabatları, gözlənilməz davranış nümunələri və müxtəlif istifadə halları üzrə nümunələr — bunların hamısı problemləri təcrid etməyimizə kömək etdi.
İstifadəçilərin rəylərini birbaşa göndərməyə davam etmələri xüsusilə faydalı olaraq qalır. Bunun üçün Claude Code-da /bug əmrindən və ya Claude tətbiqlərindəki "bəyənmədim" düyməsindən istifadə edə bilərsiniz. Tərtibatçılar və araşdırmaçılar tez-tez daxili testlərimizi tamamlayan model keyfiyyətinin qiymətləndirilməsinin yeni və maraqlı yollarını yaradırlar. Öz yanaşmanızı paylaşmaq istəyirsinizsə, [email protected] ünvanına müraciət edin.
İcmamıza bu töhfələrə görə minnətdarıq.
Təşəkkürlər
Sam McAllister tərəfindən yazılıb, Stuart Ritchie, Jonathan Gray, Kashyap Murali, Brennan Saeta, Oliver Rausch, Alex Palcuie və bir çox başqalarına təşəkkürlə.
[1] XLA:TPU, XLA High Level Optimizing dilini — tez-tez JAX istifadə edərək yazılır — TPU maşın təlimatlarına çevirən optimallaşdırıcı kompilyatordur.
[2] Modellərimiz tək çiplər üçün çox böyükdür və onlarla çip və ya daha çoxu üzrə bölüşdürülür, bu da sıralama əməliyyatımızı paylanmış sıralamaya çevirir. TPU-lar (GPU-lar və Trainium kimi) CPU-lardan fərqli performans xüsusiyyətlərinə malikdir və serial alqoritmlər əvəzinə vektorlaşdırılmış əməliyyatlardan istifadə edən fərqli tətbiq texnikaları tələb edir.
[3] Bu approximate əməliyyatı əhəmiyyətli performans yaxşılaşdırmaları verdiyi üçün istifadə edirdik. Yaxınlaşdırma ən aşağı ehtimallı tokenlərdə potensial qeyri-dəqiqlikləri qəbul etməklə işləyir ki, bu da keyfiyyətə təsir etməməlidir — xəta ən yüksək ehtimallı tokeni əvəzinə atmasına səbəb olduğu hallar istisna olmaqla.
[4] Qeyd edək ki, indi düzgün işləyən top-k tətbiqi top-p həddinə yaxın tokenlərin daxil edilməsində cüzi fərqlərə gətirib çıxara bilər və nadir hallarda istifadəçilər top-p seçimlərini yenidən tənzimləməkdən faydalana bilərlər.