#206 - Technical debt nào tiềm ẩn trong hệ thống Machine Learning?
Thân chào quý bạn đọc Newsletter,
Trong các survey phản hồi trước đây, team Grokking có ghi nhận góp ý từ một số bạn đọc là việc tìm lại nội dung của các số newsletter cũ hơi khó.
Nhằm giải quyết vấn đề này, team Grokking đang phát triển một trang chỉ mục online dành cho các bài viết liên quan đến chủ đề Software Engineering nói chung, đặc biệt là các bài viết đã được đăng trên các số newsletter cũ.
Sắp tới, team product đang cần phỏng vấn 4-5 bạn đọc thường xuyên của Newsletter để có thêm ý tưởng giúp hoàn thiện trang chỉ mục này. Buổi phỏng vấn sẽ diễn ra online và dự kiến sẽ kéo dài 1-2 giờ đồng hồ.
Bạn đọc nào quan tâm và có thể tham gia phỏng vấn vui lòng đăng ký vào form này: Form đăng ký , team Grokking sẽ liên hệ để xếp lịch phỏng vấn tùy theo thời gian rảnh của bạn. Team cũng sẽ gửi tặng 1 quyển Dijkstra tập 2 vừa xuất bản đến các bạn tham gia phỏng vấn để cảm ơn.
Rất cảm ơn quý bạn đọc đã ủng hộ Grokking Newsletter thời gian qua, và rất mong sẽ nhận được nhiều sự ủng hộ hơn nữa trong thời gian sắp tới.
---
Trong số này, chúng ta sẽ cùng tìm hiểu về:
Cách WePay phát triển hệ thống model logging;
Tại sao một số cryptographic key lại nhỏ hơn các cryptographic key khác;
Technical debt tiềm ẩn của các hệ thống Machine Learning;
Bài nghiên cứu về FLP Impossibillity;
Lời giải bài Number of Matching Subsequences.
Những bài viết hay
Logging Machine Learning Data at WePay
WePay sử dụng Machine Learning để phân tích rủi ro và phát hiện thanh toán gian lận. Tất cả những model này đều phải có khả năng diễn giải (interpretability) và có thể retrain. Mặc dù hiện tại đã có hệ thống xử lý việc này, nhưng quá trình này vẫn còn tốn nhiều thời gian và thiếu chính xác. Từ đó, đội ngũ kỹ sư WePay đặt mục tiêu xây dựng nên một hệ thống tốt hơn, đơn giản hóa quy trình duy trì và phát triển model. Với model logging, đội Data Scientist ở WePay có thể trích xuất dữ liệu một cách chính xác và hiểu về historical data - tất cả các bước đều diễn ra một cách mạch lạc, hiệu quả và dễ dàng.
Yêu cầu khi xây dựng hệ thống này là:
Data model phải linh hoạt, đáp ứng được một số lượng column hoặc dimension bất kỳ của tập feature.
Ngoài ra, hệ thống cũng không được ảnh hưởng đến độ trễ của model, và có thể scale tương ứng với lưu lượng các request thanh toán của WePay.
Tất nhiên, hệ thống cần đảm bảo rằng chất lượng của dữ liệu giống hệt như payload ban đầu đã đưa vào model.
WePay đã xây dựng hệ thống gồm:
Một microservice chịu trách nhiệm xây dựng model-agnostic payload để gửi đến tất cả các model service.
Kafka, Google Cloud Storage, Google BigQuery để tính toán và xử lý dữ liệu.
Các dashboard tùy chỉnh bằng Graphite để theo dõi dữ liệu trong quá trình tích hợp.
Google’s BigQuery API để trích xuất dữ liệu này trên Jupyter.
Để biết thêm chi tiết về quá trình xây dựng hệ thống và cách triển khai, mời các bạn tìm hiểu tại đây.
Why some cryptographic keys are much smaller than others
Khi kết nối đến một website nào đó bằng HTTPS, kết nối này sẽ được bảo mật bằng một cơ chế mã hoá SSL/TLS. Ví dụ, khi kết nối đến website của CloudFlare bằng Chrome, bạn nhận được một kết nối RC4_128 (khoá 128-bit) sử dụng cơ chế trao đổi khoá ECDHE_RSA (khoá 2048-bit) để thiết lập kết nối này. (Hiện tại, RC4 đã không còn được sử dụng do không đảm bảo độ bảo mật).
Có thể bạn sẽ đặt những câu hỏi như: tại sao sử dụng cả khóa 128-bit lẫn khóa 2048-bit, tại sao không sử dụng toàn bộ khoá lớn (2048-bit), liệu độ bảo mật của khóa 128-bit có yếu hơn khóa 2048-bit hay không?
Thực ra RC4_128 là mã hoá đối xứng, còn RSA là mã hoá bất đối xứng. Do đặc trưng về cách tạo khoá của 2 cơ chế này, nên cho dù độ dài của khoá đối xứng 128-bit nhỏ hơn, thì không gian khoá (số lượng khoá có thể được sinh ra) của nó vẫn tương đương với không gian khoá của một khoá bất đối xứng có độ dài 3072-bit. Nghĩa là nếu không bàn đến các phương pháp tấn công dựa trên cơ chế sinh khoá, thì độ bảo mật của một khoá đối xứng 128-bit và một khoá bất đối xứng 3072-bit là ngang nhau.
Bài viết không đi sâu vào giải thích cơ chế mã hoá trong giao thức HTTPS mà chủ yếu giải thích sự khác nhau về độ dài của 2 loại khoá trên. Mời bạn tìm hiểu kỹ hơn tại bài viết gốc bên dưới.
Hidden Technical Debt in Machine Learning Systems
Machine Learning (ML) cho phép chúng ta xây dựng những hệ thống dự đoán phức tạp một cách nhanh chóng. Tuy nhiên, điều gì cũng có giá của nó. Technical debt của hệ thống ML càng tồn đọng lâu, thì càng tổn hại về lâu dài.
Bài viết tập trung chủ yếu vào những tương tác và giao thức ở tầng hệ thống, cũng chính là nơi tích tụ technical debt. Ở tầng này, mô hình ML có thể âm thầm xoá nhoà "ranh giới trừu tượng" giữa các thành phần trong hệ thống (abstraction boundary). Nhiều khi chúng ta thích tái sử dụng hoặc kết chuỗi các tín hiệu input, để rồi vô tình kết nối hai hệ thống đáng ra phải hoạt động riêng rẽ. Chúng ta coi ML package như "hộp đen", hệ luỵ là một số lượng "glue code" khổng lồ, hoặc những lớp hiệu chuẩn (calibration layer) có nguy cơ hàm chứa giả định. Các tác nhân từ bên ngoài cũng có thể ảnh hưởng đến hành vi của hệ thống mà chúng ta không lường trước được. Thậm chí bản thân việc theo dõi hành vi của hệ thống ML cũng đã là một công việc khó khăn nếu hệ thống không được thiết kế cẩn thận.
Mời các bạn đọc bài viết gốc để có thêm thông tin chi tiết về các vấn đề trên, cũng như những giải pháp ngăn ngừa mà nhóm tác giả đề xuất.
Góc Distributed System
FLP Impossibility
FLP Impossibillity là một bài nghiên cứu quan trọng về hệ thống phân tán, trong đó chỉ ra một số giới hạn mà chúng ta không thể vượt qua được. Trong bài, nhóm tác giả đã chứng minh rằng: Không tồn tại consensus protocol cho những hệ thống phân tán không đồng bộ, nếu trong hệ thống đó có thể chứa các process lỗi.
Định nghĩa về consensus
Các thuật toán consensus được dùng để giải quyết bài toán đồng thuận trên hệ thống phân tán. Một thuật toán consensus được coi là hợp lệ nếu thoả mãn ba điều kiện sau đây:
Termination: Tất cả các process bình thường đều sẽ đưa ra quyết định trên một giá trị.
Agreement: Tất cả những process đưa ra quyết định đều quyết định cùng một giá trị.
Validity: Giá trị được đồng thuận phải được đề nghị từ một trong các process trong hệ thống.
Chúng ta mặc định rằng: Thuật toán consensus chỉ chạy đúng khi số lượng process bị lỗi là ít hơn một hằng số được định trước.
Định nghĩa về asynchronous model
Asynchronous là một trong ba giả định về sự đồng bộ trong hệ thống phân tán (hai giả định còn lại là Synchronous và Partially synchronous). Asynchronous model có những tính chất sau:
Không xác định được tốc độ xử lý của các process;
Message có thể bị deliver trễ với thời gian không xác định;
Không sử dụng synchronized clocks;
Không thể sử dụng các thuật toán dựa vào time-out;
Không thể phân định được hai trường hợp: process này bị lỗi, hay chỉ đơn giản là process đó xử lý rất chậm.
Chứng minh
Nghiên cứu này chứng minh rằng: Không tồn tại thuật toán consensus với những điều kiện sau:
Asynchronous model;
Chỉ cần duy nhất một process bị lỗi (crash-stop failure);
Không xảy ra Byzantine failure;
Messages system là đáng tin cậy (Tất cả message đều được deliver đến các process không bị lỗi duy nhất một lần);
Consensus: Đồng thuận trên tập giá trị 0, 1; và chỉ cần một số process đồng thuận trên cùng một giá trị (partially correct).
Có thể thấy rằng những điều kiện trên yếu hơn các điều kiện thông thường trên hệ thống phân tán (trừ asynchronous model). Do đó, nếu chúng ta chứng minh được không tồn tại thuật toán concensus trong trường hợp này, thì consensus protocol cũng không thể tồn tại trong các trường hợp tổng quát hơn.
Mời các bạn đọc về bài gốc tiếng Anh ở đây, hoặc giải thích chứng minh bằng tiếng Việt ở đây.
Góc Lập Trình
Đề tuần này: Number of Subarrays with Bounded Maximum
Lời giải đề bài tuần trước:
Đề bài: Number of Matching Subsequences
Với string "s" và một dãy các string "words" đã cho, cho biết có bao nhiêu string trong tập "words" là dãy con của "s"?
Lời giải:
Đây là một bài mở rộng của bài kiểm tra dãy con: Is Subsequence, vì vậy ta có ngay cách tiếp cận là: với mỗi string "word" trong "words", ta kiểm tra xem "word" có phải là dãy con của "s" hay không? Nếu đúng, ta tăng biến đếm lên 1. Ta có giải mã như sau: https://pastebin.com/vR2EBpxt
Tuỳ vào cách thực hiện hàm "isSubsequence", giải thuật sẽ có độ phức tạp khác nhau.
Ví dụ: Bằng cách kiểm tra tuyến tính, ta có độ phức tạp giải thuật time complexity là O(W*S)
, trong đó:
W là số string trong "words",
S là độ dài string "s".
Với cách tiếp cận trên, ta phải duyệt string "s" W lần. Áp dụng vào bài này, string "s" dài hơn rất nhiều so với string trong "words":
Constraints:
- 1 <= s.length <= 5 * 10^4
- 1 <= words.length <= 5000
Vì vậy, ta cần một cách tiếp cận khác, tối ưu hơn. Nếu ta có thể chỉ duyệt string "s" một lần, liệu ta có thể có độ phức tạp time complexity tốt hơn so với giải thuật trên không?
Tại mỗi kí tự "sch" của string "s", ta thử tìm kí tự tương ứng của mỗi string "word" trong tập "words" như sau:
Ví dụ: s = "apppleen", words = ["apple", "pen"]
Ta nhóm string trong "words" theo kí tự đầu tiên:
heads = { 'a': ["apple"], 'p': ["pen"] }
Với sch là "a" ([a]pppleen), ta tăng vị trí của các từ trong group 'a' lên 1, ta có:
heads = { 'p': ["pple", "pen"] }
Với sch là "p" (a[p]ppleen), ta tăng vị trí của các từ trong group 'p' lên 1, ta có:
heads = { 'p': ["ple"], 'e': ["en"] }
Tiếp tục duyệt string "s" cho tới cuối cùng, ta sẽ có kết quả của bài toán.
Mời bạn xem chi tiết giải thuật tại: https://pastebin.com/fCxcpBNV
Code & Tools
kuchiki - Thư viện để thao tác HTML/XML tree bằng Rust.
faker - Thư viện JavaScript giúp tạo ra một lượng lớn dữ liệu giả trong browser và Node.js, phục vụ mục đích testing và development.
Góc Sponsors
FPT Smart Cloud (FCI) – a subsidiary of FPT Corporation, is a leading provider of Artificial Intelligence (AI) and Cloud Computing solutions in Vietnam. FCI was established with a mission to offer best-in-class AI & Cloud platforms, creating a breakthrough in business operations. FPT Smart Cloud strives to be a pioneer in AI and Cloud with state-of-the-art technology, a diverse product ecosystem, and global connectivity.
Products and services within the FPT Smart Cloud ecosystem:
Infrastructure as a Service (IaaS)
Platform as a Service (PaaS)
Software as a Service (SaaS)
Artificial Intelligence (AI)
Open positions:
HN - Project Manager
HN - Senior DevOps
HCM - Security Solution Expert
HN/HCM – Fullstack Engineer (All level)
Other positions at FPT Smart Cloud Careers Page
Quotes
When they first built the University of California at Irvine they just put the buildings in. They did not put any sidewalks, they just planted grass. The next year, they came back and put the sidewalks where the trails were in the grass. Perl is just that kind of language. It is not designed from first principles. Perl is those sidewalks in the grass.
― Larry Wall