Μέσα στο Μονολιθικό Σύστημα της ByteDance: Η Μηχανή που Τροφοδοτεί Έξυπνες, Ταχύτερες Ροές Περιεχομένου

Συγγραφείς: 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 University Yijie Zhu, Bytedance Inc. Peng Wu, Bytedance Inc. Ke Wang, Bytedance Inc. Youlong Cheng†, Bytedance Inc. (youlong.cheng@bytedance.com) ΠΕΡΙΛΗΨΗ Η δημιουργία ενός επεκτάσιμου και πραγματικού χρόνου συστήματος προτάσεων είναι ζωτικής σημασίας για πολλές επιχειρήσεις που βασίζονται σε χρονικά ευαίσθητη ανατροφοδότηση πελατών, όπως η κατάταξη βίντεο ή οι διαδικτυακές διαφημίσεις. Παρά την πανταχού παρούσα υιοθέτηση πλαισίων βαθιάς μάθησης σε κλίμακα παραγωγής, όπως το TensorFlow ή το PyTorch, αυτά τα γενικής χρήσης πλαίσια υστερούν στις επιχειρηματικές απαιτήσεις σε σενάρια προτάσεων για διάφορους λόγους: αφενός, η προσαρμογή συστημάτων με βάση στατικές παραμέτρους και πυκνές υπολογισμούς για προτάσεις με δυναμικά και αραιά χαρακτηριστικά είναι επιζήμια για την ποιότητα του μοντέλου. αφετέρου, τέτοια πλαίσια έχουν σχεδιαστεί με εντελώς διαχωρισμένο στάδιο εκπαίδευσης και στάδιο εξυπηρέτησης, αποτρέποντας το μοντέλο από την αλληλεπίδραση με την ανατροφοδότηση πελατών σε πραγματικό χρόνο. Αυτά τα ζητήματα μας οδήγησαν να επανεξετάσουμε παραδοσιακές προσεγγίσεις και να διερευνήσουμε ριζικά διαφορετικές επιλογές σχεδιασμού. Σε αυτήν την εργασία, παρουσιάζουμε το 1, ένα σύστημα προσαρμοσμένο για διαδικτυακή εκπαίδευση. Ο σχεδιασμός μας καθοδηγείται από παρατηρήσεις των φόρτων εργασίας των εφαρμογών μας και του περιβάλλοντος παραγωγής που αντικατοπτρίζουν μια σαφή απόκλιση από άλλα συστήματα προτάσεων. Οι συνεισφορές μας είναι πολλαπλές: πρώτον, δημιουργήσαμε έναν πίνακα ενσωματώσεων χωρίς συγκρούσεις με βελτιστοποιήσεις όπως λήξιμες ενσωματώσεις και φιλτράρισμα συχνότητας για να μειώσουμε το αποτύπωμα μνήμης του. δεύτερον, παρέχουμε μια αρχιτεκτονική διαδικτυακής εκπαίδευσης έτοιμη για παραγωγή με υψηλή ανθεκτικότητα σε σφάλματα. τέλος, αποδείξαμε ότι η αξιοπιστία του συστήματος μπορεί να ανταλλαχθεί για πραγματικό χρόνο μάθησης. Το Monolith έχει ενσωματωθεί επιτυχώς στο προϊόν BytePlus Recommend2. Monolith 1 ΕΙΣΑΓΩΓΗ Η προηγούμενη δεκαετία είδε μια έκρηξη επιχειρήσεων που τροφοδοτούνται από τεχνικές προτάσεων. Στην επιδίωξη καλύτερης εμπειρίας πελατών, η παροχή εξατομικευμένου περιεχομένου για κάθε μεμονωμένο χρήστη ως απάντηση σε πραγματικό χρόνο είναι ένας κοινός στόχος αυτών των επιχειρηματικών εφαρμογών. Για αυτόν τον σκοπό, οι πληροφορίες από την τελευταία αλληλεπίδραση ενός χρήστη χρησιμοποιούνται συχνά ως η κύρια είσοδος για την εκπαίδευση ενός μοντέλου, καθώς θα απεικόνιζε καλύτερα το προφίλ ενός χρήστη και θα έκανε προβλέψεις για το ενδιαφέρον και τις μελλοντικές συμπεριφορές του χρήστη. Η βαθιά μάθηση κυριαρχεί στα μοντέλα προτάσεων [ , , , , , ] καθώς η τεράστια ποσότητα δεδομένων χρήστη ταιριάζει φυσικά σε νευρωνικά μοντέλα που τροφοδοτούνται μαζικά από δεδομένα. Ωστόσο, οι προσπάθειες αξιοποίησης της δύναμης της βαθιάς μάθησης σε συστήματα προτάσεων βιομηχανικού επιπέδου συναντούν συνεχώς προβλήματα που προκύπτουν από τα μοναδικά χαρακτηριστικά των δεδομένων που προέρχονται από πραγματική συμπεριφορά χρήστη. Αυτά τα δεδομένα διαφέρουν δραστικά από αυτά που χρησιμοποιούνται στα συμβατικά προβλήματα βαθιάς μάθησης, όπως η γλωσσική μοντελοποίηση ή η όραση υπολογιστών, σε δύο πτυχές: 5 6 10 12 20 21 (1) Τα χαρακτηριστικά είναι κυρίως αραιά, κατηγορικά και δυναμικά μεταβαλλόμενα. (2) Η υποκείμενη κατανομή των δεδομένων εκπαίδευσης δεν είναι στάσιμη, γνωστή και ως Concept Drift . Τέτοιες διαφορές έχουν δημιουργήσει μοναδικές προκλήσεις για ερευνητές και μηχανικούς που εργάζονται σε συστήματα προτάσεων. 1.1 Αραίωση και Δυναμισμός Τα δεδομένα για προτάσεις περιέχουν κυρίως αραιά κατηγορικά χαρακτηριστικά, μερικά από τα οποία εμφανίζονται με χαμηλή συχνότητα. Η κοινή πρακτική της αντιστοίχισης τους σε έναν πολυδιάστατο χώρο ενσωμάτωσης θα οδηγήσει σε μια σειρά προβλημάτων: • Σε αντίθεση με τα γλωσσικά μοντέλα όπου ο αριθμός των λέξεων-κομματιών είναι περιορισμένος, ο αριθμός των χρηστών και των αντικειμένων κατάταξης είναι τάξεις μεγέθους μεγαλύτερος. Ένας τέτοιος τεράστιος πίνακας ενσωμάτωσης δύσκολα χωράει στη μνήμη ενός μόνο κεντρικού υπολογιστή. • Ακόμα χειρότερα, το μέγεθος του πίνακα ενσωμάτωσης αναμένεται να αυξηθεί με την πάροδο του χρόνου καθώς προστίθενται περισσότεροι χρήστες και αντικείμενα, ενώ πλαίσια όπως τα [ , ] χρησιμοποιούν πυκνές μεταβλητές σταθερού μεγέθους για να αναπαραστήσουν τον πίνακα ενσωμάτωσης. 1 17 Στην πράξη, πολλά συστήματα υιοθετούν κατακερματισμό χαμηλών συγκρούσεων [ , ] ως έναν τρόπο μείωσης του αποτυπώματος μνήμης και για να επιτρέψουν την αύξηση των IDs. Αυτό βασίζεται σε μια υπερβολικά ιδεαλιστική παραδοχή ότι τα IDs στον πίνακα ενσωμάτωσης κατανέμονται ομοιόμορφα σε συχνότητα και οι συγκρούσεις είναι αβλαβείς για την ποιότητα του μοντέλου. Δυστυχώς, αυτό σπάνια ισχύει για ένα σύστημα προτάσεων πραγματικού κόσμου, όπου μια μικρή ομάδα χρηστών ή αντικειμένων έχει σημαντικά περισσότερες εμφανίσεις. Με την οργανική αύξηση του μεγέθους του πίνακα ενσωμάτωσης, οι πιθανότητες σύγκρουσης κλειδιών κατακερματισμού αυξάνονται και οδηγούν σε υποβάθμιση της ποιότητας του μοντέλου 3 6 . Επομένως, είναι μια φυσική απαίτηση για συστήματα προτάσεων κλίμακας παραγωγής να έχουν την ικανότητα να συλλαμβάνουν όσα περισσότερα χαρακτηριστικά στις παραμέτρους τους, και επίσης να έχουν τη δυνατότητα να προσαρμόζουν ελαστικά τον αριθμό των χρηστών και αντικειμένων που προσπαθούν να παρακολουθούν. 1.2 Μη Στάσιμη Κατανομή Τα οπτικά και γλωσσικά μοτίβα μετά βίας αναπτύσσονται σε χρονική κλίμακα αιώνων, ενώ ο ίδιος χρήστης που ενδιαφέρεται για ένα θέμα μπορεί να αλλάξει τον ενθουσιασμό του κάθε λεπτό. Ως αποτέλεσμα, η υποκείμενη κατανομή των δεδομένων χρήστη δεν είναι στάσιμη, ένα φαινόμενο που αναφέρεται συνήθως ως Concept Drift . Διαισθητικά, οι πληροφορίες από ένα πιο πρόσφατο ιστορικό μπορούν να συμβάλουν πιο αποτελεσματικά στην πρόβλεψη της αλλαγής στη συμπεριφορά ενός χρήστη. Για να μετριαστεί η επίδραση του Concept Drift, τα μοντέλα εξυπηρέτησης πρέπει να ενημερώνονται από νέα ανατροφοδότηση χρήστη όσο το δυνατόν πιο κοντά στον πραγματικό χρόνο για να αντικατοπτρίζουν το τελευταίο ενδιαφέρον ενός χρήστη. Υπό το φως αυτών των διαφορών και παρατηρώντας τα προβλήματα που προκύπτουν από την παραγωγή μας, σχεδιάσαμε το , ένα σύστημα προτάσεων μεγάλης κλίμακας για την αντιμετώπιση αυτών των προβλημάτων. Πραγματοποιήσαμε εκτεταμένα πειράματα για να επαληθεύσουμε και να επαναλάβουμε τον σχεδιασμό μας στο περιβάλλον παραγωγής. Το Monolith μπορεί: Monolith (1) Να παρέχει πλήρη εκφραστική δύναμη για αραιά χαρακτηριστικά σχεδιάζοντας έναν πίνακα κατακερματισμού χωρίς συγκρούσεις και έναν μηχανισμό δυναμικής εκκαθάρισης χαρακτηριστικών. (2) Να επαναφέρει την ανατροφοδότηση εξυπηρέτησης στην εκπαίδευση σε πραγματικό χρόνο με διαδικτυακή εκπαίδευση. Ενδυναμωμένο από αυτές τις αρχιτεκτονικές δυνατότητες, το Monolith ξεπερνά σταθερά τα συστήματα που υιοθετούν hash-tricks με συγκρούσεις με παρόμοια χρήση μνήμης, και επιτυγχάνει state-of-the-art online serving AUC χωρίς να υπερφορτώνει την υπολογιστική ισχύ των διακομιστών μας. Το υπόλοιπο της εργασίας είναι οργανωμένο ως εξής. Πρώτον, αναλύουμε τις λεπτομέρειες του σχεδιασμού για το πώς το Monolith αντιμετωπίζει τις υπάρχουσες προκλήσεις με τον πίνακα κατακερματισμού χωρίς συγκρούσεις και την πραγματικού χρόνου εκπαίδευση στην Ενότητα 2. Τα πειράματα και τα αποτελέσματα θα παρουσιαστούν στην Ενότητα 3, μαζί με συμπεράσματα που έχουν δοκιμαστεί στην παραγωγή και κάποιες συζητήσεις για τις αντιστάθμιση μεταξύ ευαισθησίας στο χρόνο, αξιοπιστίας και ποιότητας μοντέλου. Η Ενότητα 4 συνοψίζει σχετικές εργασίες και τις συγκρίνει με το Monolith. Η Ενότητα 5 ολοκληρώνει αυτήν την εργασία. 2 ΣΧΕΔΙΑΣΜΟΣ Η συνολική αρχιτεκτονική του Monolith ακολουθεί γενικά τη διανεμημένη ρύθμιση Worker- arameter erver του TensorFlow (Σχήμα Σε μια αρχιτεκτονική Worker-PS, οι μηχανές ανατίθενται σε διαφορετικούς ρόλους. Οι μηχανές Worker είναι υπεύθυνες για την εκτέλεση υπολογισμών όπως ορίζονται από το γράφημα, και οι μηχανές PS αποθηκεύουν παραμέτρους και τις ενημερώνουν σύμφωνα με τις κλίσεις που υπολογίζονται από τους Workers. P S 2). Στα μοντέλα προτάσεων, οι παράμετροι κατηγοριοποιούνται σε δύο σύνολα: πυκνές και αραιές. Οι πυκνές παράμετροι είναι βάρη/μεταβλητές σε ένα βαθύ νευρωνικό δίκτυο, και οι αραιές παράμετροι αναφέρονται σε πίνακες ενσωμάτωσης που αντιστοιχούν σε αραιά χαρακτηριστικά. Στον σχεδιασμό μας, τόσο οι πυκνές όσο και οι αραιές παράμετροι είναι μέρος του Γραφήματος TensorFlow και αποθηκεύονται σε διακομιστές παραμέτρων. Όπως και η Μεταβλητή του TensorFlow για πυκνές παραμέτρους, σχεδιάσαμε ένα σύνολο εξαιρετικά αποδοτικών, χωρίς συγκρούσεις και ευέλικτων λειτουργιών HashTable για αραιές παραμέτρους. Ως συμπλήρωμα στον περιορισμό του TensorFlow που προκύπτει από τον διαχωρισμό της εκπαίδευσης και της εξαγωγής συμπερασμάτων, η ελαστικά επεκτάσιμη διαδικτυακή εκπαίδευση του Monolith έχει σχεδιαστεί για να συγχρονίζει αποτελεσματικά παραμέτρους από το training-PS στο online serving-PS εντός σύντομων διαστημάτων, με εγγύηση ανθεκτικότητας μοντέλου που παρέχεται από τον μηχανισμό ανοχής σε σφάλματα. 2.1 Πίνακας Κατακερματισμού Μια αρχική αρχή στον σχεδιασμό μας για την αναπαράσταση αραιών παραμέτρων είναι η αποφυγή συμπίεσης πληροφοριών από διαφορετικά IDs σε μια σταθερού μεγέθους ενσωμάτωση. Η προσομοίωση ενός πίνακα ενσωμάτωσης δυναμικού μεγέθους με μια έτοιμη Μεταβλητή TensorFlow αναπόφευκτα οδηγεί σε σύγκρουση ID, η οποία επιδεινώνεται καθώς φτάνουν νέα IDs και ο πίνακας μεγαλώνει. Επομένως, αντί να βασιζόμαστε στη Μεταβλητή, αναπτύξαμε έναν νέο πίνακα κατακερματισμού κλειδιού-τιμής για τις αραιές παραμέτρους μας. Ο HashTable μας χρησιμοποιεί Cuckoo Hashmap [ ] εσωτερικά, το οποίο υποστηρίζει την εισαγωγή νέων κλειδιών χωρίς σύγκρουση με τα υπάρχοντα. Το Cuckoo Hashing επιτυγχάνει χρόνο πολυπλοκότητας 𝑂(1) στη χειρότερη περίπτωση για αναζητήσεις και διαγραφές, και αναμενόμενο επιμερισμένο 𝑂(1) χρόνο για εισαγωγές. Όπως απεικονίζεται στο Σχήμα , διατηρεί δύο πίνακες 𝑇0, 𝑇1 με διαφορετικές συναρτήσεις κατακερματισμού ℎ0 (𝑥), ℎ1 (𝑥), και ένα στοιχείο θα αποθηκευτεί σε έναν από αυτούς. Όταν προσπαθείτε να εισάγετε ένα στοιχείο 16 3 𝐴 στο 𝑇0, προσπαθεί πρώτα να τοποθετήσει το 𝐴 στο ℎ0 (𝐴). Αν το ℎ0 (𝐴) καταλαμβάνεται από ένα άλλο στοιχείο 𝐵, θα εκτοπίσει το 𝐵 από το 𝑇0 και θα προσπαθήσει να εισάγει το 𝐵 στο 𝑇1 με την ίδια λογική. Αυτή η διαδικασία θα επαναληφθεί έως ότου όλα τα στοιχεία σταθεροποιηθούν, ή συμβεί επανακατακερματισμός όταν η εισαγωγή καταλήξει σε κύκλο. Η μείωση του αποτυπώματος μνήμης είναι επίσης μια σημαντική εκτίμηση στον σχεδιασμό μας. Μια απλή προσέγγιση εισαγωγής κάθε νέου ID στον HashTable θα εξαντλήσει γρήγορα τη μνήμη. Η παρατήρηση μοντέλων πραγματικής παραγωγής οδηγεί σε δύο συμπεράσματα: (1) Τα IDs που εμφανίζονται μόνο λίγες φορές έχουν περιορισμένη συμβολή στη βελτίωση της ποιότητας του μοντέλου. Μια σημαντική παρατήρηση είναι ότι τα IDs κατανέμονται με ουρά, όπου τα δημοφιλή IDs μπορεί να εμφανίζονται εκατομμύρια φορές, ενώ τα μη δημοφιλή εμφανίζονται όχι περισσότερο από δέκα φορές. Οι ενσωματώσεις που αντιστοιχούν σε αυτά τα αραιά IDs υποεκπαιδεύονται λόγω έλλειψης δεδομένων εκπαίδευσης και το μοντέλο δεν θα μπορεί να κάνει καλή εκτίμηση βασιζόμενο σε αυτά. Τελικά, αυτά τα IDs δεν είναι πιθανό να επηρεάσουν το αποτέλεσμα, οπότε η ποιότητα του μοντέλου δεν θα υποφέρει από την αφαίρεση αυτών των IDs με χαμηλές εμφανίσεις. (2) Τα παλιά IDs από μακρινό ιστορικό σπάνια συμβάλλουν στο τρέχον μοντέλο, καθώς πολλά από αυτά δεν επισκέπτονται ποτέ. Αυτό μπορεί να οφείλεται σε έναν χρήστη που δεν είναι πλέον ενεργός, ή σε ένα βίντεο που έχει ξεπεραστεί. Η αποθήκευση ενσωματώσεων για αυτά τα IDs δεν μπορεί να βοηθήσει το μοντέλο με κανέναν τρόπο, παρά μόνο να εξαντλήσει τη μνήμη του PS μας μάταια. Βασιζόμενοι σε αυτές τις παρατηρήσεις, σχεδιάσαμε διάφορους κανόνες φιλτραρίσματος ID χαρακτηριστικών για μια πιο αποδοτική από πλευράς μνήμης υλοποίηση του HashTable: (1) Τα IDs φιλτράρονται πριν εισαχθούν στους πίνακες ενσωμάτωσης. Έχουμε δύο μεθόδους φιλτραρίσματος: Πρώτον, φιλτράρουμε με βάση τις εμφανίσεις τους πριν εισαχθούν ως κλειδιά, όπου το όριο των εμφανίσεων είναι μια ρυθμιζόμενη υπερπαράμετρος που διαφέρει για κάθε μοντέλο. Επιπλέον, χρησιμοποιούμε ένα πιθανοτικό φίλτρο που βοηθά στη περαιτέρω μείωση της χρήσης μνήμης. ![#Figure 4: Streaming Engine. Ο κύκλος ανατροφοδότησης πληροφοριών από [Χρήστης → Διακομιστής Μοντέλου → Εκπαιδευτής → Διακομιστής Μοντέλου → Χρήστης] θα δαπανούσε πολύ χρόνο ακολουθώντας τη διαδρομή Batch Training, ενώ το Online Training θα έκλεινε τον κύκλο πιο άμεσα.](https://cdn.hackernoon.com/images/InxBRjRIs6M1kdhuWcyNHiiUrxm1-78b3ep4.jpeg) (2) Τα IDs χρονολογούνται και ορίζονται να λήγουν μετά από μια προκαθορισμένη περίοδο αδράνειας. Ο χρόνος λήξης είναι επίσης ρυθμιζόμενος για κάθε πίνακα ενσωμάτωσης, επιτρέποντας τη διάκριση χαρακτηριστικών με διαφορετική ευαισθησία σε ιστορικές πληροφορίες. Στην υλοποίησή μας, το HashTable υλοποιείται ως λειτουργία πόρου TensorFlow. Παρόμοια με τη Μεταβλητή, οι αναζητήσεις και οι ενημερώσεις υλοποιούνται επίσης ως εγγενείς λειτουργίες TensorFlow για ευκολότερη ενσωμάτωση και καλύτερη συμβατότητα. 2.2 Διαδικτυακή Εκπαίδευση Στο Monolith, η εκπαίδευση χωρίζεται σε δύο στάδια (Σχήμα 1): (1) Στάδιο εκπαίδευσης κατά παρτίδες. Αυτό το στάδιο λειτουργεί ως ένας συνηθισμένος βρόχος εκπαίδευσης TensorFlow: Σε κάθε βήμα εκπαίδευσης, ένας εκπαιδευτής διαβάζει μια μικρο-παρτίδα παραδειγμάτων εκπαίδευσης από την αποθήκη, ζητά παραμέτρους από το PS, υπολογίζει μια εμπρόσθια και μια οπίσθια διάβαση, και τέλος ωθεί ενημερωμένες παραμέτρους στο training PS. Ελαφρώς διαφορετικό από άλλες κοινές εργασίες βαθιάς μάθησης, εκπαιδεύουμε το σύνολο δεδομένων μας μόνο για μία διάβαση. Η εκπαίδευση κατά παρτίδες είναι χρήσιμη για την εκπαίδευση ιστορικών δεδομένων όταν τροποποιούμε την αρχιτεκτονική του μοντέλου μας και επανεκπαιδεύουμε το μοντέλο. (2) Στάδιο διαδικτυακής εκπαίδευσης. Μετά την ανάπτυξη ενός μοντέλου σε διαδικτυακή εξυπηρέτηση, η εκπαίδευση δεν σταματά αλλά εισέρχεται στο στάδιο της διαδικτυακής εκπαίδευσης. Αντί να διαβάζει παραδείγματα μικρο-παρτίδων από την αποθήκη, ένας εκπαιδευτής καταναλώνει δεδομένα πραγματικού χρόνου εν κινήσει και ενημερώνει το training PS. Το training PS συγχρονίζει περιοδικά τις παραμέτρους του με το serving PS, οι οποίες θα τεθούν σε ισχύ για τον χρήστη αμέσως. Αυτό επιτρέπει στο μοντέλο μας να προσαρμόζεται διαδραστικά σύμφωνα με την ανατροφοδότηση ενός χρήστη σε πραγματικό χρόνο. Το Monolith είναι κατασκευασμένο με τη δυνατότητα απρόσκοπτης εναλλαγής μεταξύ εκπαίδευσης κατά παρτίδες και διαδικτυακής εκπαίδευσης. Αυτό επιτυγχάνεται από τον σχεδιασμό μας του streaming engine όπως απεικονίζεται στο Σχήμα 2.2.1 Streaming Engine. 4. Στον σχεδιασμό μας, χρησιμοποιούμε μια ουρά Kafka [ ] για την καταγραφή ενεργειών χρηστών (π.χ. Κλικ σε ένα αντικείμενο ή Like σε ένα αντικείμενο κ.λπ.) και μια άλλη ουρά Kafka για τα χαρακτηριστικά. Στην καρδιά του engine είναι μια ροή Flink [ ] για το Online Feature Joiner. Ο online joiner συνενώνει χαρακτηριστικά με ετικέτες από τις ενέργειες των χρηστών και παράγει παραδείγματα εκπαίδευσης, τα οποία στη συνέχεια γράφονται σε μια ουρά Kafka. Η ουρά για τα παραδείγματα εκπαίδευσης καταναλώνεται τόσο από την online όσο και από την batch εκπαίδευση: 13 4 Για την online εκπαίδευση, ο εκπαιδευτής διαβάζει απευθείας δεδομένα από την ουρά Kafka. Για την batch εκπαίδευση, ένα job dumping δεδομένων θα κάνει πρώτα dump δεδομένα στο HDFS [ ]. Αφού συσσωρευτούν δεδομένα στο HDFS σε ένα ορισμένο ποσό, ο εκπαιδευτής θα ανακτήσει δεδομένα από το HDFS και θα εκτελέσει batch εκπαίδευση. 18 Οι ενημερωμένες παράμετροι στο training PS θα ωθηθούν στο serving PS σύμφωνα με το πρόγραμμα συγχρονισμού παραμέτρων. Στην πραγματικότητα, τα αρχεία καταγραφής ενεργειών χρηστών και τα χαρακτηριστικά μεταδίδονται στο online joiner (Σχήμα χωρίς εγγύηση χρονικής σειράς. Επομένως, χρησιμοποιούμε ένα μοναδικό κλειδί για κάθε αίτημα, ώστε η ενέργεια του χρήστη και τα χαρακτηριστικά να μπορούν να αντιστοιχιστούν σωστά. 2.2.2 Online Joiner. 5) Η καθυστέρηση της ενέργειας του χρήστη μπορεί επίσης να αποτελέσει πρόβλημα. Για παράδειγμα, ένας χρήστης μπορεί να χρειαστεί μερικές ημέρες πριν αποφασίσει να αγοράσει ένα αντικείμενο που του παρουσιάστηκε μέρες νωρίτερα. Αυτό αποτελεί πρόκληση για τον joiner, διότι αν όλα τα χαρακτηριστικά διατηρηθούν στην κρυφή μνήμη, απλώς δεν θα χωρέσει στη μνήμη. Στο σύστημά μας, χρησιμοποιείται μια αποθήκη κλειδιού-τιμής στο δίσκο για την αποθήκευση χαρακτηριστικών που περιμένουν για περισσότερο από ένα ορισμένο χρονικό διάστημα. Όταν φτάνει ένα αρχείο καταγραφής ενέργειας χρήστη, πρώτα ελέγχει την κρυφή μνήμη στη μνήμη, και στη συνέχεια ελέγχει την αποθήκευση κλειδιού-τιμής σε περίπτωση χαμένης κρυφής μνήμης. Ένα άλλο πρόβλημα που προκύπτει στην πραγματική εφαρμογή είναι ότι η κατανομή των αρνητικών και θετικών παραδειγμάτων είναι πολύ άνιση, όπου ο αριθμός των πρώτων μπορεί να είναι τάξεις μεγέθους υψηλότερος από τους τελευταίους. Για να αποφευχθεί η υπερκάλυψη των θετικών παραδειγμάτων από τα αρνητικά, μια κοινή στρατηγική είναι η δειγματοληψία αρνητικών. Αυτό σίγουρα θα αλλάξει την υποκείμενη κατανομή του εκπαιδευμένου μοντέλου, προσαρμόζοντάς το προς υψηλότερη πιθανότητα θετικών προβλέψεων. Ως θεραπεία, εφαρμόζουμε διόρθωση log odds [ ] κατά την εξυπηρέτηση, διασφαλίζοντας ότι το online μοντέλο είναι ένας αμερόληπτος εκτιμητής της αρχικής κατανομής. 19 Κατά τη διάρκεια της διαδικτυακής εκπαίδευσης, το cluster εκπαίδευσης Monolith συνεχίζει να λαμβάνει δεδομένα από την online μονάδα εξυπηρέτησης και να ενημερώνει παραμέτρους στο training PS. Ένα κρίσιμο βήμα για να επωφεληθεί το online serving PS από αυτές τις νεο-εκπαιδευμένες παραμέτρους είναι ο συγχρονισμός των ενημερωμένων παραμέτρων του μοντέλου. Στο περιβάλλον παραγωγής, αντιμετωπίζουμε διάφορες προκλήσεις: 2.2.3 Συγχρονισμός Παραμέτρων. Τα μοντέλα στο online serving PS δεν πρέπει να σταματούν την εξυπηρέτηση κατά την ενημέρωση. Τα μοντέλα μας στην παραγωγή είναι συνήθως αρκετά terabytes σε μέγεθος, και ως αποτέλεσμα, η αντικατάσταση όλων των παραμέτρων διαρκεί λίγο. Θα ήταν μη ανεκτό να σταματήσει ένας online PS την εξυπηρέτηση του μοντέλου κατά τη διάρκεια της διαδικασίας αντικατάστασης, και οι ενημερώσεις πρέπει να γίνονται εν κινήσει. Η μεταφορά ενός μοντέλου πολλαπλών terabytes στο σύνολό του από το training PS στο online serving PS θα ασκήσει τεράστια πίεση τόσο στο εύρος ζώνης του δικτύου όσο και στη μνήμη στο PS, καθώς απαιτεί διπλάσιο μέγεθος μοντέλου μνήμης για να δεχτεί το νεο-εισερχόμενο μοντέλο. Για να κλιμακωθεί η διαδικτυακή εκπαίδευση στο μέγεθος του επιχειρηματικού μας σεναρίου, σχεδιάσαμε έναν μηχανισμό σταδιακού, εν κινήσει, περιοδικού συγχρονισμού παραμέτρων στο Monolith, βασιζόμενοι σε αρκετά αξιοσημείωτα χαρακτηριστικά των μοντέλων μας: (1) Οι αραιές παράμετροι κυριαρχούν στο μέγεθος των μοντέλων προτάσεων. (2) Δεδομένου ενός σύντομου χρονικού παραθύρου, μόνο ένα μικρό υποσύνολο IDs εκπαιδεύεται και οι ενσωματώσεις τους ενημερώνονται. (3) Οι πυκνές μεταβλητές κινούνται πολύ πιο αργά από τις αραιές ενσωματώσεις. Αυτό συμβαίνει επειδή σε βελτιστοποιητές που βασίζονται σε ορμή, η συσσώρευση ορμής για πυκνές μεταβλητές μεγεθύνεται από το τεράστιο μέγεθος των δεδομένων εκπαίδευσης προτάσεων, ενώ μόνο λίγες αραιές ενσωματώσεις λαμβάνουν ενημερώσεις σε μια ενιαία παρτίδα δεδομένων. (1) και (2) μας επιτρέπουν να εκμεταλλευτούμε τις αραιές ενημερώσεις σε όλα τα IDs χαρακτηριστικών. Στο Monolith, διατηρούμε ένα hash set από επαφές κλειδιών, που αντιπροσωπεύει IDs των οποίων οι ενσωματώσεις εκπαιδεύτηκαν από τον τελευταίο συγχρονισμό παραμέτρων. Ωθούμε το υποσύνολο των αραιών παραμέτρων των οποίων τα κλειδιά βρίσκονται στο σύνολο των κλειδιών επαφής με ένα διάστημα λίγων λεπτών από το training PS στο online serving PS. Αυτή η σχετικά μικρή δέσμη επαυξητικής ενημέρωσης παραμέτρων είναι ελαφριά για τη μετάδοση δικτύου και δεν προκαλεί απότομη αύξηση της μνήμης κατά τη διάρκεια του συγχρονισμού. Εκμεταλλευόμαστε επίσης το (3) για να μειώσουμε περαιτέρω την δικτυακή I/O και τη χρήση μνήμης, ορίζοντας ένα πιο επιθετικό πρόγραμμα συγχρονισμού για τις αραιές παραμέτρους, ενώ ενημερώνουμε τις πυκνές παραμέτρους λιγότερο συχνά. Αυτό μπορεί να μας οδηγήσει σε μια κατάσταση όπου οι πυκνές παράμετροι που εξυπηρετούμε είναι μια σχετικά παλιά έκδοση σε σύγκριση με το αραιό τμήμα. Ωστόσο, τέτοια ασυνέπεια μπορεί να είναι ανεκτή λόγω του λόγου που αναφέρθηκε στο (3), καθώς δεν έχει παρατηρηθεί εμφανής απώλεια. 2.3 Αντοχή σε Σφάλματα