ByteDance-ın Monolitində: Daha Ağıllı, Daha Sürətli Məzmun Axınlarını Gücləndirən Mühərrik

```html Müəlliflər: Zhuoran Liu, Bytedance Inc. Leqi Zou, Bytedance Inc. Xuan Zou, Bytedance Inc. Caihua Wang, Bytedance Inc. Biao Zhang, Bytedance Inc. Da Tang, Bytedance Inc. Bolin Zhu∗, Fudan Universiteti Yijie Zhu, Bytedance Inc. Peng Wu, Bytedance Inc. Ke Wang, Bytedance Inc. Youlong Cheng†, Bytedance Inc. (youlong.cheng@bytedance.com) ABSTRAKT Tələb olunan müştəri rəyi ilə idarə olunan bir çox müəssisə üçün, məsələn, qısa video reytinqi və ya onlayn reklamlar üçün miqyaslı və real-vaxt rejimində tövsiyə sistemi qurmaq vacibdir. Ten-sorFlow və ya PyTorch kimi istehsal miqyaslı dərin öyrənmə çərçivələrinin hər yerdə qəbul edilməsinə baxmayaraq, bu ümumi məqsədli çərçivələr müxtəlif səbəblərə görə tövsiyə ssenarilərində biznes tələblərini ödəmir: bir tərəfdən, dinamik və seyrək xüsusiyyətlərə malik tövsiyə üçün statik parametrlər və sıx hesablamalar əsasında sistemləri tənzimləmək modelin keyfiyyətinə zərər verir; digər tərəfdən, belə çərçivələr toplu təlim mərhələsi və xidmət mərhələsi tamamilə ayrılmış şəkildə hazırlanmışdır ki, bu da modelin real-vaxt rejimində müştəri rəyi ilə qarşılıqlı əlaqəsinə mane olur. Bu məsələlər bizi ənənəvi yanaşmaları yenidən nəzərdən keçirməyə və radikal fərqli dizayn seçimlərini araşdırmağa sövq etdi. Bu məqaledə biz onlayn təlim üçün nəzərdə tutulmuş bir sistem olan 1-i təqdim edirik. Dizaynımız tətbiq iş yüklərimiz və digər tövsiyə sistemlərindən əhəmiyyətli dərəcədə fərqlənən istehsal mühitimiz haqqında müşahidələrimizlə idarə olunmuşdur. Bizim töhfələrimiz çoxsaylıdır: ilk növbədə, biz expirable embeddings və tezlik filtrləməsi kimi optimallaşdırmalarla toqquşmayan embedding cədvəlini yaratdıq ki, bu da onun yaddaş izini azaldır; ikinci, biz yüksək səhvlərə davamlı istehsal-hazır onlayn təlim arxitekturası təqdim edirik; nəhayət, biz sistem etibarlılığının real-vaxt öyrənmə üçün fəda edilə biləcəyini sübut etdik. Monolith uğurla BytePlus Recommend2 məhsuluna inteqrasiya olunmuşdur. Monolith 1 GİRİŞ Son on ildə tövsiyə texnikaları ilə dəstəklənən müəssisələrin böyük bir artımı müşahidə edilmişdir. Daha yaxşı müştəri təcrübəsi axtarışında, hər bir fərdi istifadəçi üçün fərdiləşdirilmiş məzmunu real-vaxt cavabı olaraq təqdim etmək bu biznes tətbiqlərinin ümumi məqsədidir. Bu məqsədlə, istifadəçinin son qarşılıqlı əlaqəsindən əldə edilən məlumatlar tez-tez bir modelin təlimi üçün əsas giriş kimi istifadə olunur, çünki bu, istifadəçinin profilini ən yaxşı şəkildə təsvir edir və istifadəçinin marağını və gələcək davranışlarını proqnozlaşdırır. Dərin öyrənmə, istifadəçi məlumatlarının nəhəng miqdarının kütləvi məlumat-idarəli neyron modelləri üçün təbii bir uyğunluq olması səbəbindən tövsiyə modellərində [ , , , , , ] üstünlük təşkil edir. Bununla belə, sənaye səviyyəli tövsiyə sistemlərində dərin öyrənmənin gücündən istifadə etmək səyləri, real dünya istifadəçi davranışından əldə edilən məlumatların unikal xüsusiyyətlərindən yaranan problemlərlə daim qarşılaşır. Bu məlumatlar iki cəhətdən dil modelləşdirməsi və ya kompüter görməsi kimi ənənəvi dərin öyrənmə problemlərində istifadə olunan məlumatlardan əhəmiyyətli dərəcədə fərqlənir: 5 6 10 12 20 21 (1) Xüsusiyyətlər əsasən seyrək, kateqoriyalı və dinamik olaraq dəyişir; (2) Təlim məlumatlarının əsas paylanması qeyri-sabitdir, başqa cürə Konsept Kayması [8]. Bu fərqlər tövsiyə sistemləri üzərində işləyən tədqiqatçılar və mühəndislər üçün unikal çətinliklər yaratmışdır. 1.1 Seyrəklik və Dinamizm Tövsiyə üçün məlumatlar əsasən seyrək kateqoriyalı xüsusiyyətlər ehtiva edir, bəziləri isə aşağı tezliklə görünür. Bunları yüksək ölçülü embedding mühitinə emal etməyin ümumi praktikası bir sıra problemlərə səbəb olur: • Söz modellərindəki söz hissəciklərinin sayı məhdud olsa da, istifadəçilərin və reytinq maddələrinin sayı dəfələrlə böyükdür. Belə nəhəng bir embedding cədvəli tək bir host yaddaşına sığmaz; • Daha da pisi, daha çox istifadəçi və maddə daxil olduqca embedding cədvəlinin ölçüsünün zamanla artması gözlənilir, halbuki [ , ] kimi çərçivələr embedding cədvəlini təmsil etmək üçün sabit ölçülü sıx dəyişkənlərdən istifadə edir. 1 17 Praktikada, bir çox sistemlər yaddaş izini azaltmaq və ID-lərin böyüməsinə icazə vermək üçün az toqquşma hasarlamasından [ , ] istifadə edir. Bu, embedding cədvəlindəki ID-lərin tezlikdə bərabər paylandığı və toqquşmaların modelin keyfiyyətinə zərərsiz olduğu barədə həddindən artıq ideal bir fərziyyəyə əsaslanır. Təəssüf ki, bu, real dünya tövsiyə sistemində nadir hallarda olur, burada kiçik bir qrup istifadəçi və ya maddə əhəmiyyətli dərəcədə çox təkrarlanır. Embedding cədvəlinin ölçüsünün təbii böyüməsi ilə, hash açar toqquşmalarının ehtimalları artır və model keyfiyyətinin pisləşməsinə səbəb olur 3 6 [3]. Beləliklə, istehsal miqyaslı tövsiyə sistemləri üçün parametrlərindəki bütün xüsusiyyətləri əhatə etmək, həm də tutmaq istədikləri istifadəçi və maddə sayını elastik şəkildə tənzimləmək qabiliyyətinə sahib olmaq təbii bir tələbdir. 1.2 Qeyri-sabit Paylanma Vizual və dilPatterns yüzilliklərlə müddət ərzində demək olar ki, inkişaf etmir, eyni vaxtda bir mövzuya maraqlı olan istifadəçi növbəti dəqiqədə həvəsini dəyişə bilər. Nəticədə, istifadəçi məlumatlarının əsas paylanması qeyri-sabitdir, bu hadisə ümumiyyətlə Konsept Kayması olaraq adlandırılır. [8] İntuitiv olaraq, daha sonrakı tarixə aid məlumatlar istifadəçinin davranışındakı dəyişikliyi proqnozlaşdırmaq üçün daha effektiv şəkildə töhfə verə bilər. Konsept Kayması təsirini azaltmaq üçün xidmət modellərinin istifadəçinin son marağını əks etdirmək üçün real vaxta mümkün qədər yaxın yeni istifadəçi rəyindən yenilənməsi lazımdır. Bu fərqləri nəzərə alaraq və istehsalımızdan yaranan məsələləri müşahidə edərək, bu problemləri həll etmək üçün böyük miqyaslı tövsiyə sistemi olan -i hazırladıq. İstehsal mühitində dizaynımızı təsdiqləmək və təkmilləşdirmək üçün geniş təcrübələr apardıq. Monolith bacarıqlıdır Monolith (1) Toqquşmayan hash cədvəli və dinamik xüsusiyyət silinmə mexanizmi hazırlayaraq seyrək xüsusiyyətlər üçün tam ifadə gücü təmin edir; (2) Onlayn təlimlə real vaxt rejimində xidmət rəyini təlimə geri qaytarır. Bu arxitektur imkanları ilə təchiz olunmuş Monolith, təxminən eyni yaddaş istifadəsi ilə toqquşmalarla hash-trix istifadə edən sistemlərdən daim üstün nəticə verir və serverlərimizin hesablaşma gücünü həddindən artıq yükləmədən dövlət səviyyəsində onlayn xidmət AUC əldə edir. Qalan məqalə belə təşkil olunur: Biz ilk növbədə Monolith-in toqquşmayan hash cədvəli və real vaxt təlimi ilə mövcud çətinlikləri necə həll etdiyinin dizayn detallarını 2-ci Bölmədə təsvir edirik. Təcrübələr və nəticələr 3-cü Bölmədə, istehsalda sınaqdan keçirilmiş nəticələr və vaxt həssaslığı, etibarlılıq və model keyfiyyəti arasındakı mübadilələr haqqında bəzi müzakirələrlə birlikdə təqdim olunacaq. 4-cü Bölmədə əlaqəli işlər ümumiləşdirilir və Monolith ilə müqayisə edilir. 5-ci Bölmədə bu iş yekunlaşdırılır. 2 DİZAYN Monolith-in ümumi arxitekturası ümumiyyətlə TensorFlow-un paylanmış Worker- arameter erver quruluşunu izləyir (Şəkil Worker-PS arxitekturasında maşınlara fərqli rollar verilir; Worker maşınları qrafiklə müəyyən edilmiş hesablamaları yerinə yetirməkdən məsuldur, PS maşınları isə parametrləri saxlayır və Workers tərəfindən hesablanan qradientlərə uyğun olaraq onları yeniləyir. P S 2). Tövsiyə modellərində, parametrlər iki dəstə bölünür: sıx və seyrək. Sıx parametrlər dərin neyron şəbəkəsindəki çəkilər/dəyişkənlərdir, seyrək parametrlər isə seyrək xüsusiyyətlərə uyğun gələn embedding cədvəllərinə aiddir. Bizim dizaynımızda, həm sıx, həm də seyrək parametrlər TensorFlow Qrafikinin bir hissəsidir və parametrlər serverlərində saxlanılır. Sıx parametrlər üçün TensorFlow-un Variable-ına bənzər şəkildə, biz yüksək səmərəli, toqquşmayan və çevik HashTable əməliyyatları dəsti hazırladıq. Təlim və inferensiyanın ayrılmasından yaranan TensorFlow məhdudiyyətlərinə əlavə olaraq, Monolith-in elastik şəkildə miqyaslana bilən onlayn təlimi, səhvlərə qarşı davamlılıq mexanizmi ilə təmin edilən model etibarlılığı ilə qısa fasilələrlə təlim-PS-dən onlayn xidmət-PS-ə parametrləri səmərəli şəkildə sinxronlaşdırmaq üçün nəzərdə tutulmuşdur. 2.1 Hash Cədvəli Seyrək parametrlərin təmsilinin dizaynımızda ilk prinsip, müxtəlif ID-lərdən gələn məlumatları eyni sabit ölçülü embeddingə sıxmaqdan çəkinməkdir. Təsadüfi ölçülü bir embedding cədvəlini mövcud TensorFlow Variable-ı ilə simulyasiya etmək qaçılmaz olaraq ID toqquşmasına səbəb olur, bu da yeni ID-lər gəldikcə və cədvəl böyüdükcə pisləşir. Buna görə Variable üzərində qurmaq əvəzinə, biz seyrək parametrlərimiz üçün yeni bir açar-dəyər HashTable yaratdıq. Bizim HashTable-imiz, mövcud olanlarla toqquşmadan yeni açarları əlavə etməyə imkan verən Cuckoo Hashmap [ ] istifadə edir. Cuckoo Hashing, axtarışlar və silmələr üçün ən pis halda 𝑂 (1) vaxt mürəkkəbliyinə və əlavələr üçün gözlənilən amortizasiya olunmuş 𝑂 (1) vaxta nail olur. Şəkil göstərildiyi kimi, o iki cədvəl 𝑇0, 𝑇1 fərqli hash funksiyaları ℎ0 (𝑥), ℎ1 (𝑥) saxlayır və bir element onlardan birində saxlanılacaq. Bir element 16 3-də 𝐴-nı 𝑇0-a əlavə etməyə çalışarkən, əvvəlcə 𝐴-nı ℎ0 (𝐴)-da yerləşdirməyə çalışır; Əgər ℎ0 (𝐴) 𝐵 başqa bir element tərəfindən tutulubsa, o 𝐵-ni 𝑇0-dan çıxaracaq və eyni məntiqdən istifadə edərək 𝐵-ni 𝑇1-ə əlavə etməyə çalışacaq. Bu proses bütün elementlər sabitləşənə qədər təkrarlanacaq, və ya əlavə edilmə dövrə girdikdə rehash baş verəcək. Yaddaş izinin azaldılması da dizaynımızda vacib bir məqamdır. Hər yeni ID-ni HashTable-ə əlavə etməyin sadə bir üsulu yaddaşı tez bir zamanda tükədə bilər. İstehsal modellərinin müşahidəsi iki nəticəyə gətirdi: (1) Bir neçə dəfə görünən ID-lərin model keyfiyyətini yaxşılaşdırmaq üçün məhdud töhfəsi var. Əhəmiyyətli bir müşahidə budur ki, ID-lər uzun quyruqlu paylanmışdır, burada populyar ID-lər milyonlarla dəfə görünə bilər, lakin qeyri-populyar olanlar on dəfədən çox görünmür. Bu təxminən az olan ID-lərə uyğun gələn Embeddinglər təlim məlumatlarının çatışmazlığı səbəbindən az təsir edilmişdir və model onlardan yaxşı bir təxmin etməyəcəkdir. Günün sonunda bu ID-lər nəticəyə təsir etməyəcəkdir, buna görə də az təkrarlanan bu ID-lərin silinməsindən model keyfiyyəti əziyyət çəkməyəcəkdir; (2) Uzaq tarixdən qalma köhnə ID-lər nadir hallarda cari modele töhfə verir, çünki onlardan bir çoxu heç vaxt ziyarət edilmir. Bu, aktiv olmayan bir istifadəçi və ya köhnəlmiş bir qısa-video səbəbindən ola bilər. Bu ID-lər üçün embedding saxlamaq, yalnız bizim PS yaddaşımızı boş yerə boşaltmaqdan başqa, modelə heç bir şəkildə kömək edə bilməz. Bu müşahidələrə əsaslanaraq, HashTable-in daha yaddaş-səmərəli reallaşdırılması üçün bir sıra xüsusiyyət ID filtrləmə heuristikaları hazırladıq: (1) ID-lər embedding cədvəllərinə daxil edilmədən əvvəl filtirlənir. İki filtrləmə metodumuz var: Əvvəlcə onları açar kimi əlavə edilmədən əvvəl təkrarlanmalarına görə filtirləyirik, burada təkrarlanma həddi hər bir model üçün fərqlənən tənzimlənən bir hiperparametrdür; Əlavə olaraq, biz yaddaş istifadəsini daha da azaltmağa kömək edən probabilistik filtirdən istifadə edirik; ![#Figure 4: Streaming Engine. [İstifadəçi → Model Server → Təlim Worker → Model Server → İstifadəçi] informasiya rəy döngüsü Toplu Təlim yolunu götürərkən uzun vaxt sərf edir, Onlayn Təlim isə döngünü daha dərhal bağlayır.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) ID-lər vaxtla işarələnir və müəyyən bir müddət aktiv olmamışdan sonra müddəti bitir. Müddət bitmə vaxtı, müxtəlif həssaslığa malik xüsusiyyətləri fərqləndirməyə imkan vermək üçün hər bir embedding cədvəli üçün tənzimlənəndir. Bizim reallaşdırmamızda, HashTable bir Tensor-Flow resurs əməliyyatı kimi reallaşdırılır. Variable-a bənzər şəkildə, axtarışlar və yeniləmələr də daha asan inteqrasiya və daha yaxşı uyğunluq üçün TensorFlow-un yerli əməliyyatları kimi reallaşdırılır. 2.2 Onlayn Təlim Monolith-də təlim iki mərhələyə bölünür (Şəkil 1): (1) Toplu təlim mərhələsi. Bu mərhələ adi bir Tensor-Flow təlim döngüsü kimi işləyir: Hər bir təlim addımında, bir təlim worker-i anbardan bir mini-partiya təlim nümunələri oxuyur, PS-dən parametrlər istəyir, bir irəli və bir geri keçidi hesablayır və nəhayət yenilənmiş parametrləri təlim PS-ə göndərir. Digər ümumi dərin öyrənmə tapşırıqlarından bir qədər fərqli olaraq, biz yalnız bir dəfə öz məlumat dəstimizi təlim edirik. Toplu təlim, model arxitekturasını dəyişdirdiyimizdə və modeli yenidən təlim etdiyimizdə tarixi məlumatları təlim etmək üçün faydalıdır; (2) Onlayn təlim mərhələsi. Model onlayn xidmətə yerləşdirildikdən sonra, təlim dayanmır, lakin onlayn təlim mərhələsinə girir. Anbardan mini-partiya nümunələri oxumaq əvəzinə, bir təlim worker-i real vaxt məlumatlarını anında istehlak edir və təlim PS-ni yeniləyir. Təlim PS mütəmadi olaraq öz parametrlərini xidmət PS-ə sinxronlaşdırır, bu da dərhal istifadəçi tərəfində təsirli olur. Bu, modelimizin real vaxtda istifadəçinin rəyinə uyğun olaraq özünü interaktiv şəkildə uyğunlaşdırmasına imkan verir. Monolith, təlim və onlayn təlim arasında problemsiz keçid qabiliyyəti ilə hazırlanmışdır. Bu, Şəkil göstərildiyi kimi, streaming engine dizaynımızla təmin edilir. 2.2.1 Streaming Engine. 4-də Bizim dizaynımızda, biz istifadəçilərin hərəkətlərini (Məsələn, bir maddəyə klik etmək və ya bir maddəni bəyənmək və s.) və xüsusiyyətləri qeyd etmək üçün bir Kafka [ ] növbəsindən istifadə edirik. Engine-in mərkəzində, onlayn xüsusiyyət Joiner üçün bir Flink [ ] streaming jobu var. Onlayn joiner, istifadəçi hərəkətlərindən alınan etiketləri xüsusiyyətlərlə birləşdirir və təlim nümunələri yaradır, bunlar sonra bir Kafka növbəsinə yazılır. Təlim nümunələri üçün növbə həm onlayn təlim, həm də toplu təlim tərəfindən istehlak olunur: 13 4 Onlayn təlim üçün, təlim worker-i birbaşa Kafka növbəsindən məlumat oxuyur; Toplu təlim üçün, bir məlumat boşaltma işi əvvəlcə məlumatları HDFS-ə [ ] boşaldacaqdır; HDFS-dəki məlumatlar müəyyən bir miqdarda toplandıqdan sonra, təlim worker-i HDFS-dən məlumatı alacaq və toplu təlim aparacaq. 18 Təlim PS-də yenilənmiş parametrlər parametrlərin sinxronizasiya cədvəlinə uyğun olaraq xidmət PS-ə göndəriləcək. Real-world tətbiqlərdə, istifadəçi hərəkətləri jurnalı və xüsusiyyətləri vaxt sırasına zəmanət verilmədən onlayn joiner-ə (Şəkil axır. Buna görə də, istifadəçi hərəkəti və xüsusiyyətlərinin düzgün şəkildə cütləşdirilməsini təmin etmək üçün hər bir sorğu üçün unikal açardan istifadə edirik. 2.2.2 Online Joiner. 5) İstifadəçi hərəkətinin gecikməsi də bir problem ola bilər. Məsələn, bir istifadəçi günlər əvvəl gördüyü bir maddəni almağa qərar vermədən əvvəl bir neçə gün sərf edə bilər. Bu, joiner üçün bir çətinlikdir, çünki bütün xüsusiyyətlər keşdə saxlanılsa, bu sadəcə yaddaşa sığmaz. Bizim sistemimizdə, müəyyən bir müddətdən çox gözləyən xüsusiyyətləri saxlamaq üçün diskdən kənar açar-dəyər anbarı istifadə olunur. İstifadəçi hərəkət jurnalının gəlməsi, əvvəlcə yaddaş keşini axtarır, sonra isə keş çatışmazlığı halında açar-dəyər anbarını axtarır. Real-world tətbiqdə yaranan başqa bir problem, mənfi və müsbət nümunələrin paylanmasının qeyri-bərabər olmasıdır, burada birincinin sayı ikincidən dəfələrlə çox ola bilər. Müsbət nümunələrin mənfi nümunələr tərəfindən əzilməsinin qarşısını almaq üçün, ümumi strategiya mənfi nümunə seçimini aparmaqdır. Bu, mütləq təlim keçmiş modelin əsas paylanmasını dəyişəcək, onu müsbət proqnozlar üçün daha yüksək ehtimala doğru tənzimləyəcək. Düzəliş olaraq, biz xidmət zamanı log-odds düzəlişi [ ] tətbiq edirik, bu da onlayn modelin orijinal paylanmanın qərəzsiz bir təxminçisi olmasını təmin edir. 19 Onlayn təlim zamanı, Monolith təlim klasteri onlayn xidmət modulundan məlumat almağa və təlim PS-dəki parametrləri yeniləməyə davam edir. Bu yeni təlim keçmiş parametrlərdən onlayn xidmət PS-nin faydalanmasını təmin edən vacib bir addım, yenilənmiş model parametrlərinin sinxronizasiyasıdır. İstehsal mühitində bir sıra çətinliklərlə qarşılaşdıq: 2.2.3 Parametr Sinxronizasiyası. Onlayn xidmət PS-dəki modellər yenilənərkən xidmət etməyi dayandırmamalıdır. İstehsalımızda modellərimiz adətən bir neçə terabayt ölçüsündədir və nəticədə bütün parametrləri əvəz etmək bir müddət çəkir. Bir onlayn PS-nin yeniləmə prosesi zamanı modeli xidmət etməsini dayandırmaq dözülməz olardı və yeniləmələr anında edilməlidir; Bütöv bir multi-terabayt modelini təlim PS-dən onlayn xidmət PS-ə köçürmək, yeni gələn modeli qəbul etmək üçün ikiqat model ölçüsü yaddaş tələb etdiyi üçün həm şəbəkə zolağına, həm də PS-dəki yaddaşa böyük təzyiq göstərəcəkdir. Onlayn təlimin bizim iş ssenarilərimizin ölçüsünə qədər miqyaslanmasını təmin etmək üçün, biz modellərimizin bir sıra diqqətəlayiq xüsusiyyətlərinə əsaslanaraq Monolith-də artımlı, vaxtında parametrlərin sinxronizasiya mexanizmi hazırladıq: (1) Seyrək parametrlər tövsiyə modellərinin ölçüsünü təşkil edir; (2) Qısa bir zaman pəncərəsi nəzərə alınsa, yalnız kiçik bir ID alt dəsti təlim keçir və onların embeddingləri yenilənir; (3) Sıx dəyişkənlər daha yavaş hərəkət edir. Bunun səbəbi, momentum əsaslı optimizatorlarda, sıx dəyişkənlər üçün momentumun toplanması, tövsiyə təlim məlumatlarının nəhəng ölçüsü ilə artırılması, halbuki yalnız bir neçə seyrək embedding bir data partiyasında yeniləmələr alır. (1) və (2) bizə bütün xüsusiyyət ID-ləri üzrə seyrək yeniləmələrdən istifadə etməyə imkan verir. Monolith-də biz toxunulan açarların bir hash dəstini saxlayırıq, bu da son parametr sinxronizasiyasından bəri təlim keçmiş ID-ləri təmsil edir. Təlim PS-dən onlayn xidmət PS-ə toxunulan açar dəstində olan ID-lərin seyrək parametrlərinin alt dəstini dəqiqə səviyyəsində vaxt fasiləsi ilə göndəririk. Bu nisbətən kiçik, artımlı parametr yeniləmə paketi şəbəkə ötürülməsi üçün yüngüldür və sinxronizasiya zamanı kəskin yaddaş artımına səbəb olmaz. Biz həmçinin (3)-dən istifadə edərək seyrək parametrlər üçün daha aqressiv sinxronizasiya cədvəli təyin etməklə şəbəkə I/O və yaddaş istifadəsini daha da azaltırıq, eyni zamanda sıx parametrləri daha az tez-tez yeniləyirik. Bu bizə xidmət etdiyimiz sıx parametrlərin seyrək hissə ilə müqayisədə nisbətən köhnə bir versiya olduğu bir vəziyyətə gətirə bilər. Lakin, (3)-də qeyd olunan səbəbə görə, belə bir uyğunsuzluq dözülə bilər, çünki heç bir aşkar itki müşahidə edilməmişdir. 2.3 Səhvlərə Davamlılıq İstehsalda bir sistem olaraq, Monolith PS-nin sıradan çıxması halında onu bərpa etmək qabiliyyəti ilə hazırlanmışdır. Səhvlərə davamlılıq üçün ümumi seçim, modelin vəziyyətini mütəmadi olaraq snapshot etmək və PS səhvini aşkar etdikdə sonuncu snapshot-dan bərpa etməkdir. Snapshot tezliyinin seçilməsi iki əsas təsirə malikdir: