3 Kĩ thuật phân tích ma trận cho hệ thống khuyến nghị
3.3.3Trường hợp tổng quát
Sau đây, chúng ta xét thuật toán phân tích ma trận DSGD đầy đủ trong trường hợp tổng quát. Ý tưởng cốt lõi của thuật toán này là việc phân tách tập huấn luyệnZ ra làm tập S =Z1, Z2, . . . , Zq gồm có q lớp mà mỗi lớp Zs⊆Z có thể được xử lý theo mô hình phân tán, chúng ta thực hiện điều này bằng việc đảm bảo rằng mỗi lớp là d - monomial tức là mỗi lớp gồm dkhối trong ma trận có tính tráo đổi được tổng quát trường hợp của ma trận block-diagonal như trường hợp đơn giản trên nhưng phải đảm bảo điều kiện là bao phủ toàn bộ dữ liệu huấn luyện T
s=1...qZs = Z và các lớp Zs được phép chồng lên nhau, tham số d ở đây được chọn lớn hơn hoặc bằng số tác vụ có thể thực hiện của hệ thống.
Định nghĩa 3.2. Một phân lớp Zs được gọi là d-monomial nếu nó có thể được phân chia ra thành d tập con không rỗng Z1
s, Z2
s, . . . , Zd
s có i 6=i0 và j =6 j0 khi (i, j) ∈Zb1
s và
(i0, j0)∈Zb2
s với b1 6=b2. Một ma trận huấn luyện Zs được gọi làd-monomial nếu nó được tạo thành từ một phân lớp d-monomial Zs.
Thực tế là có nhiều cách khác nhau để phân tách lớp dữ liệu như theo định nghĩa 3.2, ở đây ta thực hiện giải pháp data-independent blocking (phân chia khối độc lập dữ liệu), các chiến lược cao cấp khác có thể tăng tốc độ hội tụ của thuật toán. Đầu tiên, ta xáo trộn ngẫu nhiên các hàng, các cột của Z và phân chia ra làm d×d khối có kích thước
(m/d)×(n/d), đồng thời ta cũng phân chia ma trận W và H một cách tương ứng. Việc xáo trộn ngẫu nhiên này nhằm hi vọng rằng số điểm cập nhật trên mỗi khối là tương đương nhau. Như vậy, với mỗi hoán vị j1, j2, . . . , jd của 1,2, . . . , d ta có thể định ra một
phân lớp Zs =Z11j ∪Z22j∪. . .∪Zddj với mỗi Zij là tập hợp các điểm thuộc vào khối Zij. Chúng ta có thể biểu diễn phân lớp Zs dưới dạng một khuôn mẫu cZs, trong đó mỗi khối
Zij tương ứng với một tập con Zij của Zs, còn các khối khác thì được gán là ma trận 0. Ví dụ, vớid= 2 ta có: Z1 = Z 11 0 0 Z22 ! Z2 = 0 Z 12 Z21 0 !
Tập tất cả các phân lớp có thể S sẽ gồm có d! phần tử, mỗi phần tử là một hoán vị của tập 1,2, . . . , d, chú ý rằng các phân lớp có thể chồng lên nhau nếud >2.
Các bước cập nhật riêng rẽ trong DSGD được gộp với nhau để tạo ra cácsubepochs tương ứng là xử lý các phân lớp.
Thuật toán DSGD cho phân tích ma trận
Đầu vào: Tập dữ liệu huấn luyện Z, ma trận khởi tạo W0, H0, kích thước cụm d
Đầu ra: Hai ma trận thành phần W, H cực tiểu hàm sai số
W ← W0 H ← H0
1: ChiaZ, W, H ra làm các khối với kích thước tương ứng d×d/d×1/1×d
2:While (chưa hội tụ) do /* bước lặp*/ 3: Chọn giá trị cho bước cập nhật ε
4: For s = 1, . . . , d do /* trên một tập phân lớp */ 5: Chọn d khối Z1j1, . . . , Zdjd tạo nên 1 phân lớp 6: For b = 1, . . . , d do /* chạy SGD song song */
7: Chạy thuật toán SGD trên các điểm huấn luyện trên tập Zbjb
8: End for
9: End for 10: End while
3.4 Thuật toán FPSGD
Hiện nay, SGD (Stochastic Gradient Descent) là một trong những thuật toán phổ biến nhất trong phân tích ma trận. Tuy nhiên, SGD khó tiếp cận song song để xử lý các vấn đề quy mô lớn trên web. Do vậy, vấn đề xử lý song song phương pháp SGD này được phát triển thành FPSGD (Fast Parallel SGD) cho các hệ thống chia sẻ bộ nhớ. FPSGD hiệu quả hơn các thuật toán song song khác trong phân tích ma trận do việc giảm tải tỷ lệ lỗi bộ nhớ cache và cân bằng tốt địa chỉ tải luồng dữ liệu.
3.4.1 Vấn đề locking
Đối với thuật toán song song, việc cực đại hóa quá trình và duy trì tất cả các luồng làm việc là rất quan trọng. Vấn đề locking xảy ra nếu một luồng không hoạt động vì phải
3.4 Thuật toán FPSGD 37
chờ đợi các luồng khác thực hiện trước. Trong DSGD, nếu s luồng được dùng thì theo thuật toán SGD, s khối độc lập được cập nhật đồng loạt. Tuy nhiên, nếu thời gian chạy của mỗi khối khác nhau thì luồng đó có thể kết thúc phiên làm việc của mình sớm hơn để chờ các luồng khác. (adsbygoogle = window.adsbygoogle || []).push({});
Việc locking có thể gây ảnh hưởng lớn nếuR không được cân bằng. Do đó, cần phải sắp xếp các rating có sẵn phân bố đều trên tất cả các vị trí của R. Trong trường hợp luồng đang cập nhật một khối bằng vài chỉ số rating có thể là để chờ các luồng khác. Ví dụ trong hình 3.2 sau khi tất cả các xếp hạng ở khối b1,1 đã có tiến trình, chỉ có một rating thứ 3 của khối b0,0 được xử lý. Do đó luồng b1,1 đang cập nhật sẽ ở trạng thái chờ nhiều nhất tại thời gian đó.
Hình 3.2: Ví dụ về vấn đề locking trong DSGD.
Trong hình trên, mỗi dấu chấm biểu diễn một xếp hạng; các khối màu xám là tập hợp các khối độc lập. Các xếp hạng ở khối trắng không được hiển thị.
Phương pháp đơn giản đểR cân bằng hơn là xáo trộn ngẫu nhiên, tức là hoán vị ngẫu nhiên những người dùng và item đồng nhất trước khi chạy tiến trình. Tuy nhiên, số lượng các xếp hạng trong mỗi khối có thể vẫn không bằng nhau tuyệt đối. Vì vậy, mỗi khối chứa số lượng các xếp hạng giống nhau, thời gian tính toán của mỗi mã code vẫn khác nhau. Bởi vậy, cần các công nghệ để giải quyết vấn đề locking.
Điều thú vị là DSGD có lý do để đảm bảo rằngs khối đã được xử lý trước khi thực hiện đếns khối tiếp theo. Như đã đề cập, DSGD thiết kế ở hệ thống phân tán, vì vậy cực tiểu các trọng số liên kết giữa các nút tính toán có thể sẽ quan trọng hơn việc giảm thời gian chết (thời gian chờ đợi - Idle time) của các nút. Tuy nhiên, trong các hệ thống chia sẻ bộ nhớ vấn đề locking lại trở thành một vấn đề quan trọng.
3.4.2 Gián đoạn bộ nhớ
Khi một chương trình nào đó truy cập dữ liệu vào bộ nhớ gián đoạn thì nó chịu tỉ lệ lỗi cache và bị suy giảm hiệu suất. Hầu hết, thuật toán SGD giải quyết cho phân tích ma trận (gồm HogWild và DSGD) lấy ngẫu nhiên các phần tử từ ma trận R (hoặc từ một khối của R) để cập nhật. Chúng ta gọi cài đặt này là phương pháp ngẫu nhiên (random method) được minh họa ở hình 3.3 dưới đây.
Hình 3.3: Phương pháp chọn ngẫu nhiên các xếp hạng để cập nhật.
Phương pháp ngẫu nhiên nói chung được hưởng sự hội tụ tốt, chịu ảnh hưởng chủ yếu từ bộ nhớ gián đoạn. Lý do này không chỉ cho xếp hạng được truy cập một cách ngẫu nhiên khi các mã đồng nhất của user/item cũng trở thành gián đoạn.
Mức độ nghiêm trọng của bộ nhớ gián đoạn bị biến thiên trong các phương pháp là khác nhau. Trong HogWild mỗi luồng lấy ngẫu nhiên một phần tử nào đó trong sốR độc lập, vì vậy nó bị gián đoạn bộ nhớ trong R, P và Q. Ngược lại, đối với DSGD mỗi một khối được chọn ngẫu nhiên dễ dàng thay đổi được thứ tự cập nhật để giảm thiểu sự gián đoạn bộ nhớ.
3.4.3 Giải quyết vấn đề
Để giải quyết 2 vấn đề được đề cập ở trên, ở đây chúng ta xem xét đến 2 kĩ thuật: lập lịch khóa nhàn rỗi (lock - free scheduling) và phương pháp ngẫu nhiên từng phần. Chúng ta đặt tên cho phương pháp thực hiện SGD song song là FPSGD (Fast Parallel SGD). Trong phần này, chúng ta sẽ thảo luận FPSGD gán động các khối cho luồng để tránh vấn đề locking như thế nào. Tiếp theo, chúng ta quan sát một lựa chọn ngẫu nhiên và hiển thị ngẫu nhiên mà có thể chỉ được áp dụng giữa các khối thay vì trong khối duy trì bộ nhớ liên tục và hội tụ nhanh. Từ đó, chúng ta đi đến tổng quát thiết kế hoàn chỉnh FPSGD. Cuối cùng, chúng ta giới thiệu các kỹ thuật thực hiện để đẩy nhanh tiến độ tính toán.
Lập lịch Lock - Free
Chúng ta theo dõi DSGD dạng lưới R khối và thiết kế một lập lịch để giữ s luồng đang làm việc với tập hợp các khối độc lập. Xét khối bi,j, nếu nó độc lập với tất cả các khối đang được xử lý thì được gọi là khối rỗi (free block). Ngoài ra, còn có khối không rỗi khác (non-free block). Khi luồng kết thúc tiến trình với một khối, lập lịch giao một khối mới thỏa mãn 2 tiêu chuẩn dưới đây:
1. Là một khối rỗi.
2. Số các cập nhật quá khứ là nhỏ nhất trong số tất cả các khối rỗi.
Số lượng các bản cập nhật của một khối chỉ ra số lần nó đã được xử lý. Nếu có hai hoặc nhiều hơn các khối đáp ứng 2 tiêu chí trên thì chúng ta chọn ngẫu nhiên một khối trong
3.4 Thuật toán FPSGD 39
số đó. Cho sluồng, ta biểu diễn FPSGD bằng việc chiaR thành ít nhất(s+ 1)×(s+ 1)
khối. Lấy 2 khối làm ví dụ. Cho T1 là luồng đang cập nhật một khối xác định và T2 là luồng vừa kết thúc cập nhật một khối khác và đang gán một công việc mới trong lập lịch. Nếu ta chia R thành 2×2 khối như trong hình 3.4a thì T2 chỉ có một lựa chọn: khối đó chỉ xử lý chính nó. Tình trạng xảy ra tương tự khi T1 xử lý công việc mới. Vì T1 và T2
luôn luôn xử lý cùng một khối, còn lại 2 khối không bao giờ được xử lý. Ngược lại, nếu chúng ta chiaR thành 3×3khối như hình 3.4b thì T2 có 3 lựa chọn:b1,1, b1,2 và b2,1 khi tạo một khối mới.
Hình 3.4: Minh họa cách chia R thành các khối ảnh hưởng từ việc lập lịch.
Ở hình trên, T1 là luồng đang cập nhật khối b0,0. T2 là luồng đang tạo một khối mới từ lập lịch. Các khối được đánh dấu "x" phụ thuộc vào khối b0,0 nên chúng không thể được cập nhật bởi khốiT2.
Như đã thảo luận ở trên, vì chúng ta luôn luôn có thể chỉ định một khối rảnh rỗi cho một luồng khi nó kết thúc cập nhật trước đó, lập lịch của chúng không bị vấn đề locking. Tuy nhiên, đối với các tập dữ liệu lớn không cân bằng, hầu hết các xếp hạng có sẵn có trong các khối nhất định, lập lịch của chúng không thể giữ số lượng các bản cập nhật trong tất cả các khối cân bằng. Trong trường hợp các khối có nhiều xếp hạng nó chỉ được cập nhất rất ít thời gian. Một biện pháp đơn giản để khắc phục là dùng kĩ thuật xáo trộn ngẫu nhiên đã được giới thiệu ở phần DSGD. Theo kinh nghiệm ở các nghiên cứu thì sau khi xáo trộn ngẫu nhiên, số các xếp hạng trong khối nặng nhất nhỏ hơn 2 lần khối nhẹ nhất. Đã có nhiều nghiên cứu và phần thực nghiệm kiểm tra mức độ nghiêm trọng của vấn đề mất cân bằng sau khi xáo trộn ngẫu nhiên. Ở đây chúng ta xác định mức độ cân bằng (DoI) để kiểm tra số các cập nhật trong tất cả các khối.
Cho U TM(t) và U Tm(t) lần lượt là cực đại và cực tiểu số các cập nhật trong tất cả các khối, trong đót là chỉ số lặp. (FPSGD không có khái niệm lặp. Ở đây chúng ta gọi mỗi chu kỳ xử lý(s+ 1)2 như một lần lặp.) DoI được định nghĩa bởi công thức sau:
DoI = U TM(t)−U Tm(t)
t (3.8)
DoI nhỏ cho thấy số các cập nhật tương tự nhau trên tất cả các khối. Trong hình 3.5 minh họa DoI cho 3 tập dữ liệu khác nhau. Chúng ta có thể thấy lập lịch giảm DoI xuống 0 chỉ trong vài lần lặp. Trong hình 3.5 có 8 luồng được sử dụng và R được chia thành
Hình 3.5: DoI trên 3 tập dữ liệu.
Phương pháp ngẫu nhiên từng phần (adsbygoogle = window.adsbygoogle || []).push({});
Để đạt được bộ nhớ liên tục, ngược lại với phương pháp ngẫu nhiên chúng ta xét một phương pháp sắp xếp tuần tự khi chọn trường hợp đánh giá bằng danh tính người dùng hoặc một item nào đó. Hình 3.6 cung cấp ví dụ theo một trật tự người dùng. Sau đó ma trậnP có thể được truy cập liên tục. Ngoài ra, nếu theo thứ tự các item sau đó truy cập liên tụcQđạt được. Đối với R, nếu trật tự các trường hợp xếp hạng là cố định thì chúng ta có thể lưu trữR vào cùng bộ nhớ để đảm bảo truy cập liên tục của nó.
Hình 3.6: Phương pháp sắp thứ tự chọn các xếp hạng để cập nhật.
Mặc dù phương pháp sắp xếp có thể truy cập dữ liệu một cách liên tục hơn nhưng kinh nghiệm cho thấy nó không thực sự được ổn định nhất. Hình 3.7 cho ta ví dụ chứng tỏ rằng với hai tỉ lệ học khác nhau rất nhỏ thì đối với SGD, phương pháp sắp xếp có thể nhanh hơn hoặc chậm hơn nhiều so với phương pháp ngẫu nhiên.
3.4 Thuật toán FPSGD 41
Hình 3.7: So sánh giữa phương pháp ngẫu nhiên và phương pháp sắp thứ tự với tập dữ liệu của Yahoo!Music. Ở đây chỉ xét 1 luồng được sử dụng
Thực nghiệm cho thấy một truy cập ngẫu nhiên của dữ liệu/biến có thể có ích cho sự hội tụ. Đặc tính này được quan sát trong các kỹ thuật tối ưu hóa có liên quan. Ví dụ, trong kết hợp phương pháp để giải quyết các vấn đề tối ưu hóa thì phương pháp ngẫu nhiên nhanh hơn sắp xếp tuần tự để cập nhật các biến và nó góp phần cải thiện đáng kể tốc độ hội tụ. Từ sự liên quan giữa dữ liệu liên tục và tốc độ hội tụ trong FPSGD, các tác giả trong tài liệu [11] đã đề xuất phương pháp ngẫu nhiên từng phần dùng để chọn các xếp hạng trong một khối có trật tự, tuy nhiên việc lựa chọn các khối là ngẫu nhiên. Mặc dù lập lịch gần với việc xác định các khối với số truy cập nhỏ nhất, tính ngẫu nhiên có thể tăng lên bởi sự phân chiaR thành nhiều khối. Sau đó, bất cứ thời điểm nào một vài khối được xử lý cùng thời điểm, do vậy lịch trình có thể chọn ngẫu nhiên một trong số đó. Hình 3.8 minh họa hoạt động của phương pháp ngẫu nhiên từng phần. Trình tự cập nhật tổng thể không phải là user by user hay item by item nên một số ngẫu nhiên được chọn thành công.
Hình 3.8: Minh họa phương pháp ngẫu nhiên từng phần.
Mỗi màu khác nhau chỉ các luồng khác nhau. Chấm được tô màu là khối khởi tạo của luồng. Hình 3.9 mở rộng so sánh thời gian chạy trong hình 3.6 bao gồm FPSGD. Chúng ta có thể thấy FPSGD có cả sự hội tụ nhanh và RMSE tốt hơn.
Hình 3.9: So sánh phương pháp sắp thứ tự, phương pháp ngẫu nhiên và ngẫu nhiên từng phần trên tập dữ liệu Yahoo!Music. Ở đây chỉ xét 1 luồng được sử dụng
Một số phương pháp có liên quan đã được nghiên cứu, mặc dù chúng cho thấy sự hội tụ trên phương pháp sắp xếp tồi hơn phương pháp ngẫu nhiên khi bị mất các điều kiện huấn luyện. Quan sát này đối lập với kết quả thực nghiệm; lý do có thể là do việc xét RMSE trên tập dữ liệu kiểm tra khi chúng bị mất huấn luyện.
Có một vài chi tiết cần được lưu ý như sau: Chúng ta đã biết FPSGD áp dụng xáo trộn ngẫu nhiên để tránh số lượng không cân bằng các bản cập nhật của mỗi khối. Tuy nhiên, sau khi áp dụng các xáo trộn ngẫu nhiên và chia R thành các khối, các xếp hạng trong mỗi khối không sắp xếp theo người sử dụng hoặc item. Áp dụng phương pháp ngẫu nhiên từng phần chúng ta phải sắp xếp danh tính người dùng hoặc item trước khi xử lý từng khối một vì phương pháp sắp thứ tự được áp dụng bị khóa (block) trước đó.