Các nguyên tắc nền tảng

Các hệ thống machine learning tuân theo một heuristic tưởng như đơn giản: độ phức tạp thường dịch chuyển chứ không biến mất, dù thiết kế tốt có thể loại bỏ độ phức tạp ngẫu nhiên. Độ phức tạp luân chuyển giữa ba miền của phân loại D·A·M: Dữ liệu với vai trò thông tin, Thuật toán với vai trò logic, và Máy với vai trò vật lý. Đơn giản hóa một miền có thể khiến các miền khác gánh thêm tải. Một pipeline đặc trưng được làm thủ công có thể giảm độ phức tạp phía thuật toán nhưng đòi hỏi nhiều công sức kỹ thuật dữ liệu hơn. Một mô hình lớn hơn có thể hấp thụ dữ liệu lộn xộn nhưng lại đẩy độ phức tạp sang phần cứng phải huấn luyện và phục vụ nó. Heuristic Bảo toàn độ phức tạp này là động lực cho mọi nội dung trong cuốn sách. Các giới hạn định lượng, mô hình và nguyên tắc được trình bày xuyên suốt mô tả những ràng buộc nảy sinh từ nơi độ phức tạp đang cư trú.

Kiến trúc, framework và các tối ưu hóa chỉ thành công khi tôn trọng các ràng buộc do phần cứng, toán học và lý thuyết thông tin áp đặt. Cũng như kỹ sư xây dựng không thể bỏ qua trọng lực, kỹ sư ML không thể bỏ qua các quy luật vật lý chi phối dữ liệu, tính toán và thông lượng hệ thống. Phần I đặt những nền tảng này: không phải là những thực hành tốt nhất thay đổi theo framework hay những ý kiến khác nhau giữa các nhóm, mà là các ràng buộc vật lý bền vững và các mô hình định lượng cho kỹ thuật ML. Ràng buộc đầu tiên bắt đầu từ chính dữ liệu, nơi ranh giới quen thuộc giữa chương trình và đầu vào dần biến mất.

Principle 1: Nguyên tắc dữ liệu như mã

Bất biến: Dữ liệu đóng vai trò là mã nguồn của hệ thống ML. Một thay đổi đối với tập dữ liệu huấn luyện có thể làm thay đổi hành vi đã học của hệ thống. Ở đây, hành vi đã học có nghĩa là ánh xạ đầu vào-đầu ra đã được huấn luyện; \(f\) biểu thị quá trình huấn luyện, và \(\approx\) đánh dấu một quan hệ phụ thuộc định tính hơn là một đẳng thức dự đoán. Kiến trúc mô hình, khởi tạo, cấu hình optimizer và tính ngẫu nhiên trong huấn luyện đều được bao gồm trong quy trình huấn luyện. \[ \text{Learned Behavior} \approx f(\text{Training Data}, \text{Training Procedure}) \]

Hàm ý: Kỹ thuật dữ liệu đòi hỏi sự chặt chẽ tương tự như kỹ thuật phần mềm. Các tập dữ liệu nên được quản lý phiên bản (như Git), kiểm thử đơn vị (kiểm tra chất lượng dữ liệu) và gỡ lỗi. Xóa một hàng dữ liệu huấn luyện có thể làm thay đổi mô hình được huấn luyện lại, giống như việc xóa một dòng mã có thể làm thay đổi một thành phẩm đã biên dịch.

Nếu dữ liệu đóng vai trò như mã nguồn, thì nó không chỉ là một thực thể logic; nó còn có các thuộc tính vật lý hạn chế kiến trúc hệ thống, nhất là khi dữ liệu và tính toán đặt ở những vị trí khác nhau.

Principle 2: Nguyên tắc trọng lực dữ liệu

Bất biến: Khi khối lượng dữ liệu (\(D_{\text{vol}}\)) tăng, việc truyền cả một tập dữ liệu có thể tốn kém hơn nhiều so với việc gửi một truy vấn hoặc một gói mã nhỏ hơn qua cùng một liên kết bị giới hạn (McCrory 2010). Ở đây, chi phí chỉ biểu thị một thước đo truyền tải tại một thời điểm, chẳng hạn thời gian truyền đã trôi qua hoặc số byte đã gửi, trong cùng điều kiện liên kết; nó không gộp độ trễ và băng thông thành một đại lượng duy nhất. \[ \text{Cost to transfer dataset} \gg \text{Cost to transfer query or code} \quad \text{in this regime} \]

Hàm ý: Các tập dữ liệu lớn có thể trở thành trung tâm trọng lực của kiến trúc. Hệ thống có thể đưa tính toán đến dữ liệu bằng cách gửi các truy vấn hoặc mã đến lớp lưu trữ, thay vì liên tục tải xuống các tập dữ liệu lớn để đưa dữ liệu đến nơi tính toán.

McCrory, Dave. 2010. Data Gravity – in the Clouds.

Gộp lại, hai nguyên tắc này cho thấy dữ liệu vừa có thể là chương trình logic, vừa là điểm neo vật lý của một hệ thống ML. Phần I phát triển các hàm ý này như một chuỗi phụ thuộc. Các ràng buộc về triển khai xác định hệ thống có thể thực thi ở đâu; vòng đời mang các ràng buộc đó xuyên suốt: định nghĩa vấn đề, dữ liệu, mô hình, xác thực và vận hành; và kỹ thuật dữ liệu biến chúng thành hiện thực trong các tạo phẩm pipeline được kiểm thử và quản lý phiên bản. Bỏ qua bất kỳ mắt xích nào sẽ hoàn lại độ phức tạp dưới dạng chi phí tích hợp: một mô hình chính xác nhưng không thể chạy, một quy trình làm việc không thể tái tạo đầu vào, hoặc một pipeline có đầu ra không còn phù hợp với điều kiện triển khai.