Quy tắc của công nghệ máy học:

Các phương pháp hay nhất về kỹ thuật học máy

Martin Zinkevich

Tài liệu này nhằm giúp những người có kiến thức cơ bản về công nghệ học máy hưởng lợi từ các phương pháp hay nhất của Google về công nghệ học máy. Đây là một phong cách dành cho công nghệ học máy, tương tự như Hướng dẫn về quy tắc lập trình C++ của Google và các hướng dẫn phổ biến khác về việc lập trình thực tế. Nếu đã tham gia một lớp học về máy học, tạo hay xây dựng một mô hình học máy, thì bạn đã có kiến thức nền tảng cần thiết để đọc tài liệu này.

Martin Zinkevich giới thiệu 10 quy tắc ưa thích của anh về công nghệ học máy. Hãy đọc tiếp để tìm hiểu toàn bộ 43 quy tắc!

Thuật ngữ

Các thuật ngữ sau sẽ xuất hiện nhiều lần trong cuộc thảo luận của chúng ta về công nghệ học máy hiệu quả:

  • Instance (Thực thể): Đây là vấn đề bạn muốn đưa ra dự đoán. Ví dụ: ví dụ có thể là một trang web mà bạn muốn phân loại là "về mèo" hoặc "không phải về mèo".
  • Nhãn: Câu trả lời cho một nhiệm vụ dự đoán có thể là câu trả lời do hệ thống học máy tạo ra hoặc câu trả lời đúng được cung cấp trong dữ liệu huấn luyện. Ví dụ: nhãn cho một trang web có thể là "về mèo".
  • Feature: Thuộc tính của một thực thể được dùng trong tác vụ dự đoán. Ví dụ: một trang web có thể có tính năng "chứa từ "mèo".
  • Cột Tính năng: Tập hợp các tính năng liên quan, chẳng hạn như nhóm tất cả quốc gia mà người dùng có thể đang sinh sống. Ví dụ: có thể có một hoặc nhiều tính năng có trong cột tính năng. "Cột tính năng" là thuật ngữ dành riêng cho Google. Cột tính năng được gọi là "không gian tên" trong hệ thống VW (tại Yahoo/Microsoft) hoặc là một trường.
  • Ví dụ: Một phiên bản (cùng các tính năng của nó) và một nhãn.
  • Mô hình: Biểu thị thống kê của một nhiệm vụ dự đoán. Bạn huấn luyện một mô hình dựa trên các ví dụ rồi sử dụng mô hình đó để đưa ra dự đoán.
  • Chỉ số: Số mà bạn quan tâm. Có thể được hoặc không được tối ưu hoá trực tiếp.
  • Mục tiêu: Chỉ số mà thuật toán của bạn đang cố gắng tối ưu hoá.
  • Pipeline: Cơ sở hạ tầng bao quanh thuật toán học máy. Bao gồm việc thu thập dữ liệu từ giao diện người dùng, đưa dữ liệu đó vào các tệp dữ liệu huấn luyện, huấn luyện một hoặc nhiều mô hình và xuất mô hình sang phiên bản chính thức.
  • Tỷ lệ nhấp Tỷ lệ phần trăm khách truy cập vào một trang web sau đó nhấp vào đường liên kết trong quảng cáo.

Tổng quan

Cách tạo ra sản phẩm chất lượng cao:

hãy học máy giống như một kỹ sư uy tín, chứ không phải một chuyên gia máy học cừ khôi.

Thực tế thì hầu hết vấn đề bạn sẽ gặp phải là các vấn đề về kỹ thuật. Ngay cả với mọi tài nguyên của một chuyên gia học máy giỏi, phần lớn lợi ích đều đến từ các tính năng tuyệt vời, chứ không phải từ các thuật toán học máy hiệu quả. Vì vậy, phương pháp cơ bản là:

  1. Đảm bảo quy trình của bạn có sự ổn định từ đầu đến cuối.
  2. Bắt đầu với một mục tiêu hợp lý.
  3. Thêm các tính năng thường dùng theo cách đơn giản.
  4. Đảm bảo quy trình của bạn luôn ổn định.

Phương pháp này sẽ có hiệu quả trong một thời gian dài. Chỉ phân biệt phương pháp tiếp cận này khi không có thủ thuật đơn giản nào giúp bạn tiến xa hơn. Việc thêm mức độ phức tạp sẽ làm chậm các bản phát hành trong tương lai.

Khi bạn đã áp dụng các thủ thuật đơn giản, công nghệ học máy tiên tiến có thể thực sự xuất hiện trong tương lai. Xem phần về các dự án học máy Giai đoạn III.

Tài liệu này được sắp xếp như sau:

  1. Phần đầu tiên sẽ giúp bạn hiểu được thời điểm thích hợp để xây dựng một hệ thống học máy.
  2. Phần thứ hai là về việc triển khai quy trình đầu tiên.
  3. Phần thứ ba là về việc khởi chạy và lặp lại trong khi thêm các tính năng mới vào quy trình của bạn, cách đánh giá các mô hình và xu hướng phân phát huấn luyện.
  4. Phần cuối cùng là việc cần làm khi bạn đạt đến một điểm ổn định.
  5. Sau đó là danh sách công việc có liên quan và phụ lục với một số thông tin cơ bản về các hệ thống thường dùng làm ví dụ trong tài liệu này.

Trước khi học máy

Quy tắc 1: Đừng ngại ra mắt một sản phẩm mà không có công nghệ học máy.

Công nghệ máy học rất thú vị nhưng công nghệ này cần có dữ liệu. Về lý thuyết, bạn có thể lấy dữ liệu từ một vấn đề khác rồi điều chỉnh mô hình cho một sản phẩm mới, nhưng cách này có thể sẽ kém hiệu quả hơn so với các heuristics cơ bản. Nếu bạn cho rằng công nghệ học máy sẽ giúp bạn tăng 100% hiệu quả, thì phương pháp phỏng đoán sẽ giúp bạn đạt 50% hiệu quả.

Ví dụ: nếu đang xếp hạng ứng dụng trong một chợ ứng dụng, bạn có thể sử dụng tỷ lệ cài đặt hoặc số lượt cài đặt dưới dạng phỏng đoán. Nếu bạn phát hiện nội dung rác, hãy lọc ra những nhà xuất bản trước đây từng gửi nội dung rác. Đừng ngại sử dụng chỉnh sửa của con người. Nếu bạn cần xếp hạng người liên hệ, hãy xếp hạng người liên hệ được sử dụng gần đây nhất (hoặc thậm chí xếp hạng theo thứ tự bảng chữ cái). Nếu bạn không nhất thiết phải sử dụng công nghệ học máy cho sản phẩm của mình, thì đừng dùng công nghệ này cho đến khi bạn có dữ liệu.

Quy tắc #2: Trước tiên, thiết kế và triển khai các chỉ số.

Trước khi chính thức hoá công việc mà hệ thống học máy sẽ thực hiện, hãy theo dõi nhiều nhất có thể trong hệ thống hiện tại. Thực hiện việc này vì những lý do sau:

  1. Bạn sẽ dễ dàng được người dùng hệ thống cho phép trước đó.
  2. Nếu cho rằng có vấn đề nào đó có thể đáng lo ngại trong tương lai, bạn nên thu thập dữ liệu trong quá khứ ngay bây giờ.
  3. Nếu bạn thiết kế hệ thống có cân nhắc đến khả năng đo lường chỉ số, mọi thứ sẽ tốt hơn cho bạn trong tương lai. Cụ thể là bạn không muốn tự mình tìm kiếm các chuỗi trong nhật ký để đo lường các chỉ số của mình!
  4. Bạn sẽ nhận thấy những thứ thay đổi và những thứ gì vẫn giữ nguyên. Ví dụ: giả sử bạn muốn tối ưu hoá trực tiếp số người dùng hoạt động trong một ngày. Tuy nhiên, trong các thao tác ban đầu với hệ thống, bạn có thể nhận thấy rằng những thay đổi lớn về trải nghiệm người dùng không làm thay đổi đáng kể chỉ số này.

Nhóm Google Plus đo lường số lượt mở rộng cho mỗi lượt đọc, lượt chia sẻ lại cho mỗi lượt đọc, lượt +1 cho mỗi lượt đọc, lượt nhận xét/lượt đọc, số lượt nhận xét của mỗi người dùng, số lượt chia sẻ lại cho mỗi người dùng, v.v. mà họ sử dụng để tính toán độ hay của bài đăng tại thời điểm phân phát. Ngoài ra, hãy lưu ý rằng một khung thử nghiệm, trong đó bạn có thể nhóm người dùng thành các nhóm và tổng hợp số liệu thống kê theo thử nghiệm, là rất quan trọng. Xem Quy tắc số 12.

Bằng cách thoải mái hơn trong việc thu thập chỉ số, bạn có thể có được bức tranh rộng hơn về hệ thống của mình. Bạn nhận thấy có vấn đề? Hãy thêm chỉ số để theo dõi chỉ số đó! Bạn có hào hứng về một số thay đổi về định lượng trong bản phát hành gần đây nhất không? Hãy thêm chỉ số để theo dõi chỉ số đó!

Quy tắc #3: Chọn công nghệ máy học thay vì phương pháp phỏng đoán phức tạp.

Một phương pháp phỏng đoán đơn giản có thể giúp bạn giới thiệu sản phẩm của mình. Một phương pháp phỏng đoán phức tạp sẽ không thể duy trì được. Sau khi có dữ liệu và ý tưởng cơ bản về những gì bạn đang cố gắng đạt được, hãy chuyển sang công nghệ học máy. Như trong hầu hết các tác vụ kỹ thuật phần mềm, bạn sẽ muốn liên tục cập nhật phương pháp của mình, cho dù đó là mô hình phỏng đoán hay mô hình học máy. Bạn sẽ thấy rằng mô hình học máy sẽ dễ cập nhật và duy trì hơn (xem Quy tắc #16).

Học máy giai đoạn I: Quy trình đầu tiên của bạn

Tập trung vào cơ sở hạ tầng hệ thống cho quy trình đầu tiên của bạn. Mặc dù thật thú vị khi nghĩ về tất cả công nghệ học máy giàu trí tưởng tượng mà bạn sẽ làm, nhưng sẽ khó để tìm ra điều gì sẽ xảy ra nếu trước tiên bạn không tin tưởng vào quy trình của mình.

Quy tắc số 4: Duy trì mô hình đầu tiên đơn giản và xây dựng cơ sở hạ tầng phù hợp.

Mô hình đầu tiên mang đến sự tăng cường lớn nhất cho sản phẩm, vì vậy, bạn không cần phải thiết kế cầu kỳ. Tuy nhiên, bạn sẽ gặp phải nhiều vấn đề về cơ sở hạ tầng hơn những gì bạn mong đợi. Trước khi mọi người có thể sử dụng hệ thống học máy mới và ưa thích của mình, bạn phải xác định:

  • Cách lấy ví dụ về thuật toán học tập.
  • Giới thiệu sơ lược về ý nghĩa của "tốt" và "xấu" đối với hệ thống của bạn.
  • Cách tích hợp mô hình vào ứng dụng của bạn. Bạn có thể áp dụng mô hình trực tiếp hoặc tính toán trước mô hình trên các ví dụ khi không có mạng rồi lưu trữ kết quả trong bảng. Ví dụ: bạn có thể muốn phân loại trước các trang web và lưu trữ kết quả trong một bảng, nhưng bạn có thể muốn phân loại các tin nhắn trò chuyện trực tiếp.

Việc chọn các tính năng đơn giản giúp bạn dễ dàng đảm bảo rằng:

  • Các tính năng tiếp cận được thuật toán học tập của bạn một cách chính xác.
  • Mô hình này sẽ tìm hiểu các trọng số hợp lý.
  • Các tính năng này tiếp cận mô hình của bạn trong máy chủ một cách chính xác.

Sau khi có một hệ thống thực hiện 3 việc này một cách ổn định, thì bạn đã hoàn thành hầu hết công việc. Mô hình đơn giản này sẽ cung cấp cho bạn các chỉ số cơ sở và hành vi cơ sở mà bạn có thể dùng để kiểm thử các mô hình phức tạp hơn. Một số nhóm nhắm đến lần phát hành đầu tiên "theo cách không thúc đẩy gian lận": lần phát hành đầu tiên rõ ràng giảm mức độ ưu tiên của công nghệ học máy, để tránh bị phân tâm.

Quy tắc số 5: Kiểm tra cơ sở hạ tầng một cách độc lập với công nghệ học máy.

Hãy đảm bảo rằng cơ sở hạ tầng có thể kiểm thử được và các phần học tập của hệ thống được đóng gói để bạn có thể kiểm thử mọi thứ xung quanh. Cụ thể:

  1. Kiểm thử việc đưa dữ liệu vào thuật toán. Kiểm tra để đảm bảo các cột tính năng cần được điền đã được điền sẵn. Nếu quyền riêng tư cho phép, hãy kiểm tra đầu vào cho thuật toán huấn luyện của bạn theo cách thủ công. Nếu có thể, hãy kiểm tra số liệu thống kê trong quy trình của bạn so với số liệu thống kê cho cùng dữ liệu được xử lý ở nơi khác.
  2. Kiểm thử việc đưa mô hình ra khỏi thuật toán huấn luyện. Hãy đảm bảo rằng mô hình trong môi trường đào tạo của bạn cho điểm số bằng với mô hình trong môi trường phân phát (xem Quy tắc #37).

Công nghệ học máy có một yếu tố khó dự đoán, vì vậy, hãy nhớ kiểm thử mã để tạo ví dụ trong quá trình huấn luyện và phân phát, đồng thời có thể tải và sử dụng mô hình cố định trong quá trình phân phát. Ngoài ra, điều quan trọng là bạn phải hiểu dữ liệu của mình: xem Lời khuyên thiết thực để phân tích các tập dữ liệu lớn và phức tạp.

Quy tắc số 6: Hãy cẩn thận với dữ liệu bị bỏ qua khi sao chép quy trình.

Thông thường, chúng ta tạo một quy trình bằng cách sao chép một quy trình hiện có (tức là lập trình mô-đun hàng hóa) và quy trình cũ sẽ bỏ dữ liệu mà chúng ta cần cho quy trình mới. Ví dụ: quy trình cho Bài đăng nổi bật trên Google Plus sẽ bỏ qua các bài đăng cũ hơn (vì quy trình này đang cố gắng xếp hạng các bài đăng mới). Quy trình này được sao chép để sử dụng cho Luồng Google Plus, nơi các bài đăng cũ vẫn có ý nghĩa, nhưng quy trình này vẫn đang bỏ các bài đăng cũ. Một mẫu phổ biến khác là chỉ ghi nhật ký dữ liệu mà người dùng đã xem. Do đó, dữ liệu này vô ích nếu chúng ta muốn lập mô hình lý do người dùng không xem được một bài đăng cụ thể, vì tất cả các ví dụ tiêu cực đã bị loại bỏ. Vấn đề tương tự cũng xảy ra trong Play. Trong quá trình làm việc trên Trang chủ của ứng dụng Play, một quy trình mới đã được tạo, trong đó cũng có các ví dụ từ trang đích cho Play Games mà không có tính năng nào để phân biệt nguồn gốc của từng ví dụ.

Quy tắc #7: Biến suy nghiệm thành các tính năng hoặc xử lý chúng từ bên ngoài.

Thông thường, các vấn đề mà công nghệ học máy đang cố gắng giải quyết không phải hoàn toàn mới. Hiện tại, chúng tôi có sẵn một hệ thống để xếp hạng, phân loại hoặc bất kỳ vấn đề nào mà bạn đang cố gắng giải quyết. Tức là có một loạt quy tắc và phỏng đoán. Các phương pháp phỏng đoán tương tự này có thể giúp bạn tăng mức tăng khi được điều chỉnh bằng công nghệ học máy. Bạn nên khai thác các phương pháp phỏng đoán của mình cho bất kỳ thông tin nào trong đó, vì hai lý do. Thứ nhất, quá trình chuyển đổi sang một hệ thống mà máy học sẽ diễn ra suôn sẻ hơn. Thứ hai, thông thường, các quy tắc đó chứa rất nhiều trực giác về hệ thống mà bạn không muốn bỏ đi. Bạn có thể sử dụng phương pháp phỏng đoán hiện có theo 4 cách:

  • Tiền xử lý bằng cách sử dụng phương pháp phỏng đoán. Nếu tính năng này cực kỳ tuyệt vời, thì đây là lựa chọn. Ví dụ: nếu trong bộ lọc thư rác, người gửi đã được đưa vào danh sách cấm, đừng cố tìm hiểu lại ý nghĩa của "bị đưa vào danh sách cấm". Chặn tin nhắn đó. Đây là phương pháp hợp lý nhất trong các tác vụ phân loại tệp nhị phân.
  • Tạo một đối tượng. Trực tiếp tạo ra một tính năng thông qua phương pháp phỏng đoán thì thật tuyệt. Ví dụ: nếu sử dụng phương pháp phỏng đoán để tính điểm mức độ liên quan cho một kết quả truy vấn, bạn có thể đưa điểm số này vào dưới dạng giá trị của một tính năng. Sau này, bạn có thể muốn sử dụng các kỹ thuật học máy để mát xa giá trị (ví dụ: chuyển đổi giá trị thành một trong các giá trị rời rạc hữu hạn, hoặc kết hợp giá trị đó với các tính năng khác), nhưng bắt đầu bằng cách sử dụng giá trị thô do phương pháp phỏng đoán tạo ra.
  • Khai thác dữ liệu đầu vào thô của phương pháp phỏng đoán. Nếu có phương pháp phỏng đoán cho ứng dụng kết hợp số lượt cài đặt, số ký tự trong văn bản và ngày trong tuần, hãy cân nhắc tách các phần này ra và đưa những thông tin đầu vào này vào mô hình học riêng biệt. Một số kỹ thuật áp dụng cho nhóm nhạc sẽ áp dụng ở đây (xem Quy tắc #40).
  • Sửa đổi nhãn. Đây là tuỳ chọn khi bạn cảm thấy rằng phương pháp phỏng đoán ghi lại thông tin hiện không có trong nhãn. Ví dụ: nếu bạn đang cố gắng tối đa hoá số lượt tải xuống, nhưng cũng muốn nội dung chất lượng, thì có thể giải pháp là nhân nhãn với số sao trung bình mà ứng dụng nhận được. Có rất nhiều cách khác ở đây. Xem "Mục tiêu đầu tiên của bạn".

Hãy lưu ý đến sự phức tạp tăng lên khi sử dụng thông tin phỏng đoán trong hệ thống học máy. Việc sử dụng các phương pháp phỏng đoán cũ trong thuật toán học máy mới có thể giúp tạo ra quá trình chuyển đổi suôn sẻ, nhưng hãy nghĩ xem có cách nào đơn giản hơn để thực hiện hiệu ứng tương tự hay không.

Giám sát

Nhìn chung, hãy thực hành tốt việc thiết lập cảnh báo, chẳng hạn như thiết lập cảnh báo thành hành động và có một trang tổng quan.

Quy tắc số 8: Nắm rõ các yêu cầu làm mới của hệ thống.

Hiệu suất giảm bao nhiêu nếu bạn có mô hình mới một ngày? Một tuần tuổi? 1/4 tuổi? Thông tin này có thể giúp bạn hiểu mức độ ưu tiên của hoạt động giám sát. Nếu chất lượng sản phẩm giảm đáng kể nếu mô hình không được cập nhật trong một ngày, thì bạn nên có một kỹ sư theo dõi mô hình đó liên tục. Hầu hết các hệ thống phân phát quảng cáo đều có quảng cáo mới cần xử lý mỗi ngày và phải cập nhật hằng ngày. Ví dụ: nếu không cập nhật mô hình học máy cho Tìm kiếm trên Google Play, mô hình này có thể gây ảnh hưởng tiêu cực trong vòng chưa đầy một tháng. Một số kiểu máy cho mục Phổ biến trong Google Plus không có giá trị nhận dạng bài đăng trong mô hình nên không thể xuất các mô hình này thường xuyên. Các mô hình khác có giá trị nhận dạng bài đăng được cập nhật thường xuyên hơn nhiều. Ngoài ra, xin lưu ý rằng độ mới có thể thay đổi theo thời gian, đặc biệt là khi các cột tính năng được thêm hoặc bị xoá khỏi mô hình.

Quy tắc #9: Phát hiện vấn đề trước khi xuất mô hình.

Nhiều hệ thống học máy có giai đoạn xuất mô hình để phân phát. Nếu có vấn đề với mô hình đã xuất, thì đó là vấn đề dành cho người dùng.

Kiểm tra độ chính xác ngay trước khi xuất mô hình. Cụ thể, hãy đảm bảo rằng mô hình có hiệu suất hợp lý trên dữ liệu bị giữ lại. Hoặc, nếu bạn vẫn còn lo ngại về dữ liệu, đừng xuất mô hình. Nhiều nhóm liên tục triển khai các mô hình sẽ kiểm tra diện tích dưới đường cong ROC (hay AUC) trước khi xuất. Bạn cần gửi thông báo qua email cho các vấn đề về mô hình chưa được xuất, nhưng có thể cần có trang để hiển thị các vấn đề về mô hình mà người dùng nhìn thấy. Vì vậy, tốt hơn là bạn nên chờ và đảm bảo trước khi tác động đến người dùng.

Quy tắc #10: Chú ý đến những thất bại thầm lặng.

Đây là vấn đề xảy ra với các hệ thống học máy nhiều hơn các loại hệ thống khác. Giả sử một bảng cụ thể đang được tham gia không còn được cập nhật nữa. Hệ thống học máy sẽ điều chỉnh và hành vi sẽ tiếp tục tốt và giảm dần. Đôi khi, bạn thấy các bảng đã lỗi thời trong nhiều tháng và một lần làm mới đơn giản sẽ cải thiện hiệu suất hơn bất kỳ lần phát hành nào khác trong quý đó! Mức độ phù hợp của một tính năng có thể thay đổi do các thay đổi về cách triển khai: ví dụ: một cột tính năng có thể được điền sẵn trong 90% ví dụ nhưng đột ngột giảm xuống 60% số ví dụ. Play từng có một bảng lỗi thời trong 6 tháng và chỉ riêng việc làm mới bảng đã giúp tỷ lệ cài đặt tăng 2%. Nếu theo dõi số liệu thống kê về dữ liệu, cũng như thỉnh thoảng kiểm tra dữ liệu theo cách thủ công, bạn có thể giảm các loại lỗi này.

Quy tắc #11: Cung cấp tài liệu và chủ sở hữu của các cột tính năng.

Nếu hệ thống lớn và có nhiều cột tính năng, hãy biết ai đã tạo hoặc duy trì từng cột tính năng. Nếu bạn thấy người hiểu cột tính năng đang rời khỏi, hãy đảm bảo rằng người nào đó có thông tin. Mặc dù nhiều cột tính năng có tên mô tả, nhưng bạn nên mô tả chi tiết hơn về tính năng, nguồn gốc và lợi ích của tính năng đó.

Mục tiêu đầu tiên của bạn

Bạn có nhiều chỉ số hoặc phép đo về hệ thống mà bạn quan tâm, nhưng thuật toán học máy của bạn thường sẽ yêu cầu một mục tiêu duy nhất, một con số mà thuật toán của bạn đang "cố gắng" tối ưu hoá. Ở đây, tôi phân biệt giữa mục tiêu và chỉ số: chỉ số là bất kỳ số nào mà hệ thống báo cáo, có thể quan trọng hoặc không quan trọng. Xem thêm Quy tắc số 2.

Quy tắc 12: Đừng suy nghĩ quá nhiều về mục tiêu mà bạn chọn để trực tiếp tối ưu hoá.

Bạn muốn kiếm tiền, làm cho người dùng hài lòng và làm cho thế giới trở nên tốt đẹp hơn. Có rất nhiều chỉ số mà bạn quan tâm và bạn nên đo lường tất cả các chỉ số đó (xem Quy tắc số 2). Tuy nhiên, trong giai đoạn đầu của quá trình học máy, bạn sẽ nhận thấy tất cả chúng sẽ tăng lên, ngay cả những thành phần mà bạn không trực tiếp tối ưu hoá. Ví dụ: giả sử bạn quan tâm đến số lượt nhấp và thời gian dành cho trang web. Nếu tối ưu hoá cho số lượt nhấp, thì bạn có thể thấy thời gian dùng tăng lên.

Vì vậy, hãy đơn giản hoá và đừng nghĩ quá khó về việc cân bằng các chỉ số khác nhau khi bạn vẫn có thể dễ dàng tăng tất cả các chỉ số. Tuy nhiên, đừng nhầm lẫn quy tắc này với mục tiêu của bạn với tình trạng sau cùng của hệ thống (xem Quy tắc #39). Ngoài ra, nếu bạn tự thấy mình tăng chỉ số được tối ưu hoá trực tiếp nhưng lại quyết định không chạy chiến dịch, thì bạn có thể phải sửa đổi mục tiêu.

Quy tắc số 13: Chọn một chỉ số đơn giản, có thể quan sát và có thể phân bổ cho mục tiêu đầu tiên của bạn.

Thường thì bạn không biết mục tiêu thực sự là gì. Bạn nghĩ mình sẽ làm vậy, nhưng rồi khi nhìn chằm chằm vào dữ liệu và phân tích song song hệ thống cũ và hệ thống học máy mới, bạn nhận ra rằng bạn muốn điều chỉnh mục tiêu. Ngoài ra, các thành viên khác trong nhóm thường không thể thống nhất về mục tiêu thực sự. Mục tiêu học máy phải là một mục tiêu dễ đo lường và đại diện cho mục tiêu "thực tế". Trên thực tế, thường không có mục tiêu "đúng" (xem Quy tắc số 39). Vì vậy, hãy đào tạo về mục tiêu học máy đơn giản và cân nhắc việc đặt một "lớp chính sách" ở trên cùng, cho phép bạn thêm logic bổ sung (hy vọng là logic rất đơn giản) để tiến hành xếp hạng cuối cùng.

Cách dễ nhất để lập mô hình là hành vi của người dùng được quan sát trực tiếp và quy cho một hành động của hệ thống:

  • Bạn có nhấp vào đường liên kết được xếp hạng này không?
  • Đối tượng được xếp hạng này đã được tải xuống chưa?
  • Đối tượng được xếp hạng này có được chuyển tiếp/trả lời/gửi email không?
  • Đối tượng được xếp hạng này có được xếp hạng không?
  • Đối tượng được hiển thị này có bị đánh dấu là nội dung rác/nội dung khiêu dâm/phản cảm không?

Trước tiên, hãy tránh lập mô hình các hiệu ứng gián tiếp:

  • Người dùng có truy cập vào ngày hôm sau không?
  • Người dùng đã truy cập trang web này trong bao lâu?
  • Số người dùng hoạt động hằng ngày là gì?

Hiệu ứng gián tiếp tạo nên các chỉ số tuyệt vời và có thể được sử dụng trong quá trình thử nghiệm A/B và trong quá trình đưa ra quyết định ra mắt.

Cuối cùng, đừng cố gắng để công nghệ học máy tìm ra:

  • Người dùng có hài lòng khi sử dụng sản phẩm không?
  • Người dùng có hài lòng với trải nghiệm đó không?
  • Sản phẩm này có giúp cải thiện sức khoẻ tổng thể của người dùng không?
  • Điều này sẽ ảnh hưởng như thế nào đến tình trạng tổng thể của công ty?

Đây đều là những chỉ số quan trọng nhưng cũng cực kỳ khó đo lường. Thay vào đó, hãy sử dụng proxy: nếu người dùng hài lòng, họ sẽ ở lại trang web lâu hơn. Nếu người dùng hài lòng, họ sẽ truy cập lại vào ngày mai. Xét đến sức khoẻ thể chất và tinh thần của công ty, cần có sự đánh giá của con người để kết nối mọi mục tiêu học máy với tính chất của sản phẩm bạn đang bán và kế hoạch kinh doanh của bạn.

Quy tắc #14: Bắt đầu với một mô hình có thể diễn giải giúp gỡ lỗi dễ dàng hơn.

Mô hình xác suất trực tiếp thúc đẩy hồi quy tuyến tính, hồi quy logistic và hồi quy Poisson. Mỗi dự đoán đều có thể diễn giải là một xác suất hoặc một giá trị dự kiến. Điều này giúp việc gỡ lỗi dễ dàng hơn so với các mô hình sử dụng mục tiêu (mất một đơn vị, nhiều tổn thất bản lề, v.v.) cố gắng trực tiếp tối ưu hoá độ chính xác của quá trình phân loại hoặc hiệu suất xếp hạng. Ví dụ: nếu xác suất trong quá trình huấn luyện sai lệch so với xác suất được dự đoán song song hoặc bằng cách kiểm tra hệ thống sản xuất, thì sự sai lệch này có thể làm phát hiện một vấn đề.

Ví dụ: trong hồi quy tuyến tính, logistic hoặc Poisson, có một số tập hợp con dữ liệu, trong đó kỳ vọng dự đoán trung bình bằng nhãn trung bình (1 thời điểm được hiệu chỉnh hoặc vừa hiệu chỉnh). Điều này đúng khi giả định rằng bạn không có quy trình chuẩn hoá và thuật toán của bạn đã hội tụ, và nhìn chung thì điều này cũng gần đúng. Nếu bạn có một tính năng với giá trị là 1 hoặc 0 cho mỗi ví dụ, thì tập hợp 3 ví dụ có giá trị là 1 sẽ được hiệu chỉnh. Ngoài ra, nếu bạn có một tính năng là 1 cho mỗi ví dụ, thì tập hợp tất cả các ví dụ sẽ được hiệu chỉnh.

Với các mô hình đơn giản, việc xử lý các vòng lặp phản hồi sẽ dễ dàng hơn (xem Quy tắc #36). Thông thường, chúng tôi sử dụng các dự đoán xác suất này để đưa ra quyết định, chẳng hạn như xếp hạng bài đăng theo mức giảm giá trị dự kiến (tức là xác suất nhấp/tải xuống/v.v.). Tuy nhiên, hãy nhớ rằng tại thời điểm lựa chọn mô hình sử dụng, quyết định quan trọng hơn khả năng dữ liệu được cung cấp cho mô hình (xem Quy tắc #27).

Quy tắc #15: Lọc riêng thư rác và xếp hạng chất lượng trong lớp chính sách.

Xếp hạng chất lượng là một nghệ thuật, nhưng lọc spam là một cuộc chiến. Tín hiệu mà bạn sử dụng để xác định bài đăng chất lượng cao sẽ trở nên rõ ràng đối với những người sử dụng hệ thống của bạn và họ sẽ điều chỉnh bài đăng để có các thuộc tính này. Do đó, thứ hạng chất lượng của bạn cần tập trung vào việc xếp hạng nội dung được đăng một cách có thiện chí. Bạn không nên giảm giá người học có thứ hạng chất lượng cao để xếp hạng cao cho nội dung rác. Tương tự, nội dung "không phù hợp" nên được xử lý riêng biệt với Xếp hạng chất lượng. Lọc thư rác là một câu chuyện khác. Bạn phải dự kiến rằng các tính năng mà bạn cần tạo ra sẽ liên tục thay đổi. Thông thường, sẽ có các quy tắc rõ ràng mà bạn đưa vào hệ thống (nếu một bài đăng có nhiều hơn 3 lượt bình chọn không liên quan, đừng truy xuất bài đăng đó, v.v.). Mọi mô hình đã học sẽ phải được cập nhật hằng ngày, nếu không muốn nhanh hơn. Danh tiếng của người tạo nội dung sẽ đóng vai trò rất quan trọng.

Ở một mức độ nào đó, đầu ra của hai hệ thống này sẽ phải được tích hợp. Xin lưu ý rằng việc lọc thư rác trong kết quả tìm kiếm có thể nghiêm ngặt hơn so với lọc thư rác trong email. Ngoài ra, một phương pháp tiêu chuẩn là xoá nội dung rác khỏi dữ liệu huấn luyện cho thuật toán phân loại chất lượng.

Học máy giai đoạn II: Kỹ thuật tính năng

Trong giai đoạn đầu tiên trong vòng đời của một hệ thống học máy, các vấn đề quan trọng là đưa dữ liệu huấn luyện vào hệ thống học, lấy mọi chỉ số đo lường mối quan tâm và tạo cơ sở hạ tầng phân phát. Sau khi bạn có một hệ thống hoạt động toàn diện bằng cách đo lường kiểm thử đơn vị và hệ thống, Giai đoạn II sẽ bắt đầu.

Trong giai đoạn thứ hai, có nhiều trái cây treo ở tầm thấp. Có nhiều tính năng rõ ràng có thể được đưa vào hệ thống. Do đó, giai đoạn thứ hai của công nghệ học máy bao gồm việc đưa vào nhiều tính năng nhất có thể và kết hợp chúng theo cách trực quan. Trong giai đoạn này, tất cả các chỉ số vẫn sẽ tăng. Sẽ có rất nhiều tính năng ra mắt và đây là thời điểm tuyệt vời để quy tụ rất nhiều kỹ sư có thể kết hợp tất cả dữ liệu cần thiết nhằm tạo ra một hệ thống học tập thực sự tuyệt vời.

Quy tắc #16: Lên kế hoạch khởi chạy và lặp lại.

Đừng mong đợi mô hình bạn đang xây dựng sẽ là mô hình cuối cùng bạn sẽ ra mắt, hoặc thậm chí là bạn sẽ ngừng ra mắt mô hình. Do đó, hãy cân nhắc xem sự phức tạp mà bạn thêm vào lần khởi chạy này có làm chậm các lần khởi chạy trong tương lai hay không. Nhiều nhóm đã ra mắt một mô hình mỗi quý trở lên trong nhiều năm. Có ba lý do cơ bản để ra mắt các mô hình mới:

  • Chúng tôi sắp phát hành một số tính năng mới.
  • Bạn đang điều chỉnh quy trình chính quy và kết hợp các tính năng cũ theo những cách mới.
  • Bạn đang điều chỉnh mục tiêu.

Dù vậy, việc dành tình yêu cho một mô hình có thể là một điều tốt: việc xem qua dữ liệu được đưa vào ví dụ có thể giúp tìm thấy các tín hiệu mới cũng như các tín hiệu cũ, bị hỏng. Vì vậy, khi bạn xây dựng mô hình, hãy nghĩ xem việc thêm, xoá hoặc kết hợp lại các tính năng có thể dễ dàng đến mức nào. Hãy nghĩ về việc tạo một bản sao mới của quy trình và xác minh tính chính xác của quy trình đó dễ dàng đến mức nào. Hãy suy nghĩ xem có thể có 2 hoặc 3 bản sao chạy song song hay không. Cuối cùng, đừng lo lắng về việc tính năng 16/35 có được đưa vào phiên bản quy trình này hay không. Bạn sẽ có dữ liệu này vào quý tới.

Quy tắc #17: Bắt đầu bằng các tính năng được báo cáo và ghi nhận trực tiếp thay vì các tính năng đã học.

Đây có thể là một điểm gây tranh cãi, nhưng sẽ tránh được nhiều sai lầm. Trước hết, hãy mô tả tính năng đã học là gì. Tính năng đã học là một tính năng do hệ thống bên ngoài (chẳng hạn như hệ thống phân cụm không được giám sát) hoặc do chính người học tạo ra (ví dụ: thông qua mô hình tích hợp hoặc học sâu). Cả hai đều có thể hữu ích, nhưng cũng có thể gặp nhiều vấn đề, vì vậy, bạn không nên đưa chúng vào mô hình đầu tiên.

Nếu bạn sử dụng hệ thống bên ngoài để tạo một tính năng, hãy nhớ rằng hệ thống bên ngoài có mục tiêu riêng. Mục tiêu của hệ thống bên ngoài có thể chỉ tương quan một chút với mục tiêu hiện tại của bạn. Nếu bạn có được ảnh chụp nhanh của hệ thống bên ngoài, thì thông tin đó có thể trở nên lỗi thời. Nếu bạn cập nhật các tính năng từ hệ thống bên ngoài, thì ý nghĩa có thể thay đổi. Nếu bạn sử dụng hệ thống bên ngoài để cung cấp một tính năng, hãy lưu ý rằng phương pháp này cần bạn sử dụng rất cẩn thận.

Vấn đề chính với mô hình tích hợp và mô hình sâu là chúng không lồi. Do đó, không thể đảm bảo rằng có thể ước chừng hoặc tìm thấy giải pháp tối ưu và giá trị cực tiểu cục bộ đạt được trên mỗi vòng lặp có thể khác nhau. Biến thể này gây khó khăn trong việc đánh giá xem tác động của một thay đổi đối với hệ thống là có ý nghĩa hay ngẫu nhiên. Bằng cách tạo một mô hình không có các tính năng sâu, bạn có thể có được hiệu suất cơ sở tuyệt vời. Sau khi đạt được đường cơ sở này, bạn có thể thử các phương pháp bí truyền hơn.

Quy tắc số 18: Khám phá các tính năng của nội dung tổng quát theo các bối cảnh cụ thể.

Thông thường, hệ thống máy học chỉ là một phần nhỏ của một bức tranh lớn hơn rất nhiều. Ví dụ: nếu bạn hình dung một bài đăng có thể được sử dụng trong mục Phổ biến, nhiều người sẽ cộng một, chia sẻ lại hoặc nhận xét về một bài đăng trước khi bài đăng đó hiển thị trong mục Phổ biến. Nếu bạn cung cấp các số liệu thống kê đó cho người học, học viên có thể quảng bá các bài đăng mới mà nó không có dữ liệu trong bối cảnh đang tối ưu hoá. YouTube Watch Next có thể dùng số lượt xem hoặc số lượt cùng xem (số lần xem một video sau khi xem một video khác) trong phần tìm kiếm trên YouTube. Bạn cũng có thể sử dụng điểm xếp hạng rõ ràng của người dùng. Cuối cùng, nếu bạn có một hành động của người dùng mà bạn đang sử dụng làm nhãn, thì việc xem hành động đó trên tài liệu ở một ngữ cảnh khác có thể là một tính năng tuyệt vời. Tất cả các tính năng này cho phép bạn đưa nội dung mới vào ngữ cảnh. Xin lưu ý rằng đây không phải là nội dung cá nhân hoá: trước tiên, hãy tìm hiểu xem có người thích nội dung trong ngữ cảnh này hay không, sau đó tìm ra người thích nội dung nhiều hơn hay ít hơn.

Quy tắc #19: Sử dụng các tính năng rất cụ thể khi có thể.

Với rất nhiều dữ liệu, việc tìm hiểu hàng triệu tính năng đơn giản trở nên đơn giản hơn so với một vài tính năng phức tạp. Giá trị nhận dạng của tài liệu được truy xuất và truy vấn chuẩn hoá không cung cấp nhiều khái quát hoá nhưng sẽ căn chỉnh thứ hạng của bạn với nhãn trên truy vấn tiêu đề. Do đó, đừng e ngại các nhóm tính năng mà trong đó mỗi tính năng áp dụng cho một phần rất nhỏ dữ liệu của bạn, nhưng mức độ bao phủ tổng thể đều trên 90%. Bạn có thể sử dụng quy trình chính quy để loại bỏ các tính năng áp dụng cho quá ít ví dụ.

Quy tắc #20: Kết hợp và sửa đổi các tính năng hiện có để tạo ra các tính năng mới theo cách mà con người có thể hiểu được.

Có nhiều cách để kết hợp và sửa đổi các đối tượng. Các hệ thống học máy như TensorFlow cho phép bạn xử lý trước dữ liệu thông qua quy trình biến đổi. Hai phương pháp chuẩn nhất là "phân rã" và "giao chéo".

Sự phân tách bao gồm việc sử dụng một tính năng liên tục và tạo ra nhiều tính năng riêng biệt. Hãy xem xét một tính năng liên tục, chẳng hạn như độ tuổi. Bạn có thể tạo một tính năng là 1 khi dưới 18 tuổi, một tính năng khác là 1 khi độ tuổi từ 18 đến 35, v.v. Đừng suy nghĩ quá nhiều về ranh giới của những biểu đồ này: các lượng tử cơ bản sẽ mang lại cho bạn nhiều tác động nhất.

Dấu chéo kết hợp hai hoặc nhiều cột tính năng. Trong thuật ngữ của TensorFlow, cột tính năng là một tập hợp các tính năng đồng nhất (ví dụ: {male,{9/}}, {Hoa Kỳ, Canada, Mexico}, v.v.). Dấu chữ thập là một cột tính năng mới có các đối tượng tại, ví dụ: {male, HTML} × {US,Canada, Mexico}. Cột tính năng mới này sẽ chứa tính năng (Nam, Canada). Nếu bạn đang sử dụng TensorFlow và yêu cầu TensorFlow tạo chữ thập này cho bạn, thì tính năng này (đối với nam, Canada) sẽ xuất hiện trong các ví dụ đại diện cho những người Canada là nam giới. Xin lưu ý rằng cần có một lượng dữ liệu khổng lồ để tìm hiểu các mô hình với 3, 4 hoặc nhiều cột tính năng cơ sở hơn.

Các dấu chéo tạo ra các cột tính năng rất lớn có thể bị thừa. Ví dụ: giả sử bạn đang thực hiện một số loại tìm kiếm và bạn có một cột tính năng chứa các từ trong cụm từ tìm kiếm và một cột tính năng chứa các từ trong tài liệu. Bạn có thể kết hợp các đường liên kết này với dấu thập, nhưng bạn sẽ có nhiều tính năng (xem Quy tắc #21).

Khi làm việc với văn bản, bạn có hai lựa chọn. Một cách hoành tráng nhất là sản phẩm chấm. Sản phẩm dấu chấm ở dạng đơn giản nhất chỉ cần đếm số lượng từ chung giữa truy vấn và tài liệu. Sau đó, bạn có thể phân phối tính năng này. Một phương pháp khác là giao nhau: do đó, chúng ta sẽ có một đối tượng xuất hiện khi và chỉ khi từ "pony" xuất hiện trong cả tài liệu và truy vấn, còn một tính năng khác xuất hiện khi và chỉ khi từ "the" có trong cả tài liệu và truy vấn.

Quy tắc #21: Số lượng trọng số của tính năng mà bạn có thể tìm hiểu trong mô hình tuyến tính tỷ lệ thuận với lượng dữ liệu bạn có.

Lý thuyết thống kê có những kết quả rất thú vị liên quan đến mức độ phức tạp phù hợp cho một mô hình, nhưng về cơ bản, quy tắc này là tất cả những gì bạn cần biết. Tôi đã nói chuyện với nhau, trong đó mọi người nghi ngờ rằng bất cứ điều gì có thể học được từ 1.000 ví dụ, hoặc rằng bạn sẽ cần nhiều hơn 1 triệu ví dụ vì họ bị mắc kẹt trong một phương pháp học nhất định. Điều quan trọng là phải mở rộng quy mô học tập theo kích thước dữ liệu:

  1. Nếu bạn đang hoạt động trên một hệ thống xếp hạng kết quả tìm kiếm, có hàng triệu từ khác nhau trong tài liệu và cụm từ tìm kiếm, đồng thời bạn có 1.000 ví dụ được gắn nhãn, thì bạn nên sử dụng một dấu chấm giữa các tính năng của tài liệu và cụm từ tìm kiếm, TF-IDF và nửa số tính năng khác do con người thực hiện. 1.000 ví dụ, rất nhiều tính năng.
  2. Nếu bạn có một triệu ví dụ, hãy cắt cột tài liệu và cột tính năng truy vấn bằng cách sử dụng quy tắc điều chỉnh và có thể là lựa chọn tính năng. Điều này sẽ cung cấp cho bạn hàng triệu tính năng, nhưng nếu thường xuyên điều chỉnh, bạn sẽ có ít tính năng hơn. Mười triệu ví dụ, có thể là một trăm nghìn tính năng.
  3. Nếu có hàng tỷ hoặc hàng trăm tỷ ví dụ, bạn có thể vượt qua các cột tính năng bằng mã thông báo tài liệu và mã truy vấn, bằng cách sử dụng tính năng lựa chọn tính năng và điều chỉnh. Bạn sẽ có hàng tỷ ví dụ và 10 triệu tính năng. Lý thuyết học thống kê hiếm khi đưa ra giới hạn chặt chẽ, nhưng lại đưa ra hướng dẫn hữu ích cho điểm xuất phát.

Cuối cùng, hãy sử dụng Quy tắc số 28 để quyết định tính năng sẽ sử dụng.

Quy tắc #22: Xoá các tính năng bạn không còn sử dụng.

Các tính năng không được sử dụng sẽ tạo ra món nợ kỹ thuật. Nếu bạn nhận thấy mình không sử dụng một tính năng và việc kết hợp tính năng đó với các tính năng khác không hoạt động, hãy loại bỏ tính năng đó khỏi cơ sở hạ tầng của bạn. Bạn muốn giữ cho cơ sở hạ tầng của mình sạch sẽ để có thể dùng thử các tính năng hứa hẹn nhất nhanh nhất có thể. Nếu cần, người khác luôn có thể thêm lại tính năng của bạn.

Cân nhắc mức độ phù hợp khi cân nhắc những tính năng cần thêm hoặc giữ lại. Tính năng này đề cập đến bao nhiêu ví dụ? Ví dụ: nếu bạn có một số tính năng cá nhân hoá, nhưng chỉ 8% người dùng có các tính năng cá nhân hoá, thì cách này sẽ không hiệu quả.

Đồng thời, một số tính năng có thể vượt quá trọng lượng của chúng. Ví dụ: nếu bạn có một tính năng chỉ bao gồm 1% dữ liệu, nhưng 90% ví dụ có tính năng này là tích cực, thì đây sẽ là một tính năng tuyệt vời để thêm vào.

Quy trình phân tích hệ thống do con người thực hiện

Trước khi chuyển sang giai đoạn thứ ba của công nghệ học máy, quan trọng là bạn phải tập trung vào những nội dung chưa được dạy trong bất kỳ lớp học máy nào: cách xem xét và cải thiện mô hình hiện có. Đây thiên về một nghệ thuật hơn là một khoa học, nhưng vẫn có một số phản mẫu mà nó giúp tránh.

Quy tắc #23: Bạn không phải là người dùng cuối thông thường.

Đây có lẽ là cách dễ nhất để một nhóm bắt tay vào làm việc. Mặc dù việc thử nghiệm fishfood (sử dụng nguyên mẫu trong đội ngũ của bạn) và thử nghiệm nội bộ (sử dụng nguyên mẫu trong công ty bạn) mang lại rất nhiều lợi ích, nhưng nhân viên vẫn nên xem xét liệu hiệu suất có chính xác hay không. Mặc dù không nên sử dụng một thay đổi rõ ràng là không tốt, nhưng bạn nên kiểm thử thêm mọi thay đổi có vẻ gần như đã được phát hành chính thức, bằng cách trả tiền cho những người không có chuyên môn để trả lời câu hỏi trên nền tảng sử dụng nguồn lực cộng đồng hoặc thông qua thử nghiệm trực tiếp trên người dùng thực.

Có hai lý do dẫn đến điều này. Nguyên nhân đầu tiên là bạn ở quá gần mã. Có thể bạn đang tìm kiếm một khía cạnh cụ thể của bài đăng hoặc đơn giản là bạn quá liên quan đến cảm xúc (ví dụ: thiên vị xác nhận). Thứ hai là thời gian của bạn quá quý giá. Hãy xem xét chi phí của 9 kỹ sư ngồi trong cuộc họp kéo dài một giờ và nghĩ xem có bao nhiêu nhãn do nhân viên theo hợp đồng mua trên nền tảng sử dụng nguồn lực cộng đồng.

Nếu bạn thực sự muốn có ý kiến phản hồi của người dùng, hãy sử dụng các phương thức trải nghiệm người dùng. Tạo chân dung độc giả (một phần mô tả nằm trong phần Bill Buxton’s Phác trải nghiệm người dùng) sớm trong quy trình và tiến hành kiểm tra khả năng hữu dụng (một nội dung mô tả nằm trong phần Steve Krug’s Don’t Make Me Think) ở phần sau. Chân dung độc giả liên quan đến việc tạo ra một người dùng giả định. Ví dụ: nếu nhóm của bạn đều là nam giới, bạn nên thiết kế chân dung độc giả là nữ 35 tuổi (đầy đủ các tính năng của người dùng) và xem kết quả mà nhóm tạo ra thay vì 10 kết quả đối với nam giới từ 25 đến 40 tuổi. Việc đưa người dùng thực tế đến xem phản ứng của họ đối với trang web của bạn (tại chỗ hoặc từ xa) trong quá trình kiểm thử khả năng hữu dụng cũng có thể mang đến cho bạn góc nhìn mới.

Quy tắc #24: Đo lường delta giữa các mô hình.

Một trong những phép đo dễ nhất và đôi khi hữu ích nhất mà bạn có thể thực hiện trước khi bất kỳ người dùng nào xem xét mô hình mới của bạn là tính toán sự khác biệt giữa kết quả mới so với kết quả chính thức. Ví dụ: nếu bạn gặp vấn đề về thứ hạng, hãy chạy cả hai mô hình trên một mẫu truy vấn thông qua toàn bộ hệ thống và xem xét kích thước của sự chênh lệch đối xứng của các kết quả (có trọng số theo vị trí xếp hạng). Nếu sự khác biệt là rất nhỏ, thì bạn có thể biết được rằng sẽ có rất ít thay đổi mà không cần chạy thử nghiệm. Nếu sự khác biệt rất lớn, thì bạn cần đảm bảo rằng thay đổi đó là phù hợp. Việc xem xét các truy vấn có sự chênh lệch đối xứng cao có thể giúp bạn hiểu một cách định tính về sự thay đổi đó. Tuy nhiên, hãy đảm bảo rằng hệ thống đã ổn định. Hãy đảm bảo rằng một mô hình khi so sánh với chính nó có sự chênh lệch đối xứng thấp (tốt nhất là bằng 0).

Quy tắc #25: Khi chọn mô hình, hiệu suất thực dụng được ưu tiên hơn khả năng dự đoán.

Mô hình của bạn có thể cố gắng dự đoán tỷ lệ nhấp. Tuy nhiên, cuối cùng, vấn đề quan trọng nhất là bạn sẽ làm gì với thông tin dự đoán đó. Nếu bạn đang sử dụng công cụ này để xếp hạng tài liệu, thì chất lượng của thứ hạng cuối cùng quan trọng hơn so với gợi ý. Nếu bạn dự đoán xác suất một tài liệu là nội dung rác sau đó bị giới hạn, thì độ chính xác của nội dung được cho phép sẽ quan trọng hơn. Trong hầu hết trường hợp, hai điều này nên được đưa ra với nhau: khi hai bên không đồng ý thì có thể sẽ mang lại một lợi ích nhỏ. Do đó, nếu có một số thay đổi giúp cải thiện tình trạng mất nhật ký nhưng làm giảm hiệu suất của hệ thống, hãy tìm một tính năng khác. Khi điều này bắt đầu xảy ra thường xuyên hơn, đã đến lúc xem lại mục tiêu của mô hình của bạn.

Quy tắc #26: Tìm kiếm đặc điểm trong các lỗi được đo lường và tạo các tính năng mới.

Giả sử bạn thấy một ví dụ huấn luyện cho biết mô hình này nhận được kết quả "sai". Trong một nhiệm vụ phân loại, lỗi này có thể là dương tính giả (FN) hoặc âm tính giả (FN). Trong một nhiệm vụ xếp hạng, lỗi có thể là một cặp mà trong đó giá trị dương được xếp hạng thấp hơn giá trị âm. Điểm quan trọng nhất là đây là một ví dụ mà hệ thống học máy biết rằng đã nhầm lẫn và sẽ muốn khắc phục nếu có cơ hội. Nếu bạn cung cấp cho mô hình một tính năng cho phép sửa lỗi, mô hình sẽ cố gắng sử dụng tính năng đó.

Mặt khác, nếu bạn cố gắng tạo một tính năng dựa trên các ví dụ mà hệ thống không cho là lỗi, thì tính năng này sẽ bị bỏ qua. Ví dụ: giả sử trong Tìm kiếm ứng dụng trên Play, ai đó tìm kiếm "trò chơi miễn phí". Giả sử một trong các kết quả hàng đầu là một ứng dụng gag ít liên quan hơn. Vì vậy, bạn tạo một tính năng cho "ứng dụng gag". Tuy nhiên, nếu bạn đang tối đa hoá số lượt cài đặt và mọi người cài đặt một ứng dụng gag khi tìm kiếm trò chơi miễn phí, thì tính năng "ứng dụng gag" sẽ không có hiệu quả như bạn muốn.

Sau khi có các ví dụ cho thấy mô hình này không chính xác, hãy tìm các xu hướng nằm ngoài nhóm tính năng hiện tại của bạn. Ví dụ: nếu có vẻ như hệ thống đang giảm hạng các bài đăng dài hơn, hãy thêm độ dài bài đăng. Đừng quá cụ thể về các tính năng bạn thêm. Nếu bạn định thêm độ dài bài đăng, đừng cố đoán ý nghĩa của bài đăng, chỉ cần thêm nhiều tính năng và mô hình sẽ tìm ra việc cần làm với các tính năng đó (xem Quy tắc #21). Đó là cách dễ nhất để có được nội dung bạn muốn.

Quy tắc #27: Cố gắng định lượng hành vi không mong muốn quan sát được.

Một số thành viên trong nhóm của bạn sẽ bắt đầu cảm thấy khó chịu với những thuộc tính của hệ thống mà họ không thích và không được chức năng mất dữ liệu hiện tại nắm bắt. Tại thời điểm này, họ sẽ làm bất cứ điều gì cần thiết để biến thế giới hạn thành những con số vững chắc. Ví dụ: nếu họ cho rằng có quá nhiều "ứng dụng gag" hiển thị trong Tìm kiếm trên Play, họ có thể yêu cầu người đánh giá xác định ứng dụng gag. (Trong trường hợp này, bạn có thể sử dụng dữ liệu có nhãn do con người thực hiện vì các cụm từ tìm kiếm chiếm phần lớn lưu lượng truy cập.) Nếu các vấn đề của bạn có thể đo lường được, thì bạn có thể bắt đầu sử dụng các vấn đề đó làm tính năng, mục tiêu hoặc chỉ số. Quy tắc chung là "đo lường thứ nhất, tối ưu hóa thứ hai".

Quy tắc #28: Xin lưu ý rằng hành vi ngắn hạn giống hệt nhau không bao hàm hành vi dài hạn giống hệt nhau.

Hãy tưởng tượng rằng bạn có một hệ thống mới xem xét mọi tài liệu và truy vấn chính xác, sau đó tính toán xác suất nhấp chuột cho mỗi tài liệu đối với mỗi truy vấn. Bạn nhận thấy hành vi của hệ thống này gần giống với hệ thống hiện tại của mình ở cả hai bên và trong quy trình kiểm thử A/B. Vì vậy, dựa trên sự đơn giản của phương thức này, bạn hãy khởi chạy nó. Tuy nhiên, bạn nhận thấy không có ứng dụng mới nào hiển thị. Tại sao? Vì hệ thống của bạn chỉ hiển thị một tài liệu dựa trên nhật ký của chính nó kèm theo truy vấn đó, nên không có cách nào để biết rằng một tài liệu mới sẽ xuất hiện.

Cách duy nhất để hiểu được cách thức hoạt động lâu dài của một hệ thống như vậy là chỉ huấn luyện dựa trên dữ liệu thu thập được khi mô hình đang hoạt động. Điều này rất khó.

Xiên phục vụ đào tạo

Độ lệch trong quá trình phân phát đào tạo là sự khác biệt giữa hiệu suất trong quá trình huấn luyện và hiệu suất trong quá trình phân phát. Sự sai lệch này có thể do:

  • Có sự khác biệt giữa cách bạn xử lý dữ liệu trong quy trình đào tạo và phân phát.
  • Thay đổi về dữ liệu từ khi bạn huấn luyện đến khi bạn phân phát quảng cáo.
  • Vòng lặp phản hồi giữa mô hình và thuật toán của bạn.

Chúng tôi quan sát thấy các hệ thống học máy trong sản xuất tại Google có sự sai lệch trong hoạt động đào tạo, gây ảnh hưởng tiêu cực đến hiệu suất. Giải pháp tốt nhất là theo dõi rõ ràng để các thay đổi về hệ thống và dữ liệu không gây ra các sự cố không mong muốn.

Quy tắc số 29: Cách tốt nhất để đảm bảo rằng bạn huấn luyện giống như bạn phục vụ là lưu tập hợp các tính năng được sử dụng trong thời gian phân phát, sau đó chuyển các tính năng đó vào nhật ký để sử dụng chúng tại thời gian huấn luyện.

Ngay cả khi bạn không thể thực hiện việc này cho mọi ví dụ, hãy thực hiện việc này trong một phần nhỏ để bạn có thể xác minh tính nhất quán giữa việc phân phát và huấn luyện (xem Quy tắc #37). Đôi khi, các nhóm thực hiện phép đo này tại Google còn ngạc nhiên trước kết quả. Trang chủ YouTube đã chuyển sang các tính năng ghi nhật ký tại thời điểm phân phát với những cải tiến đáng kể về chất lượng và giảm độ phức tạp của mã. Đồng thời, nhiều nhóm cũng đang chuyển đổi cơ sở hạ tầng của họ như chúng tôi đã nói.

Quy tắc #30: Đừng tự ý bỏ qua dữ liệu được lấy mẫu theo trọng số quan trọng!

Khi có quá nhiều dữ liệu, bạn sẽ thường lấy các tệp 1-12 và bỏ qua các tệp 13-99. Đây là một sai lầm. Mặc dù dữ liệu không bao giờ hiển thị cho người dùng có thể bị loại bỏ, nhưng trọng số tầm quan trọng là tốt nhất cho phần còn lại. Tầm quan trọng có nghĩa là nếu bạn quyết định lấy mẫu X với xác suất 30%, thì hãy cho trọng số là 10/3. Với trọng số tầm quan trọng, tất cả thuộc tính hiệu chỉnh được thảo luận trong Quy tắc số 14 sẽ vẫn được giữ lại.

Quy tắc số 31: Hãy lưu ý rằng nếu bạn kết hợp dữ liệu từ một bảng tại thời gian huấn luyện và phân phát, dữ liệu trong bảng có thể thay đổi.

Giả sử bạn kết hợp mã tài liệu với một bảng chứa các tính năng của các tài liệu đó (chẳng hạn như số nhận xét hoặc lượt nhấp). Giữa thời gian huấn luyện và thời gian phân phát, các tính năng trong bảng có thể thay đổi. Sau đó, thông tin dự đoán của mô hình cho cùng một tài liệu có thể khác nhau giữa quá trình huấn luyện và phân phát. Cách dễ nhất để tránh loại vấn đề này là ghi lại các tính năng tại thời điểm phân phát (xem Quy tắc số 32). Nếu bảng chỉ thay đổi chậm, bạn cũng có thể chụp nhanh bảng hằng giờ hoặc hằng ngày để nhận được dữ liệu gần đúng. Xin lưu ý rằng điều này vẫn không giải quyết được hoàn toàn vấn đề.

Quy tắc #32: Sử dụng lại đoạn mã giữa quy trình huấn luyện và quy trình phân phát bất cứ khi nào có thể.

Xử lý hàng loạt khác với xử lý trực tuyến. Khi xử lý trực tuyến, bạn phải xử lý từng yêu cầu khi yêu cầu đến (ví dụ: bạn phải tra cứu riêng từng truy vấn), còn khi xử lý hàng loạt, bạn có thể kết hợp các tác vụ (ví dụ: kết hợp). Tại thời điểm phân phát, bạn đang xử lý trực tuyến, còn huấn luyện là một tác vụ xử lý hàng loạt. Tuy nhiên, có một số việc bạn có thể làm để sử dụng lại mã. Ví dụ: bạn có thể tạo một đối tượng dành riêng cho hệ thống của mình, trong đó kết quả của bất kỳ truy vấn hoặc liên kết nào có thể được lưu trữ theo cách rất dễ đọc và có thể dễ dàng kiểm tra lỗi. Sau đó, sau khi đã thu thập tất cả thông tin, trong quá trình phân phát hoặc huấn luyện, bạn sẽ chạy một phương thức chung để làm cầu nối giữa đối tượng mà con người có thể đọc được dành riêng cho hệ thống của bạn và bất kỳ định dạng nào mà hệ thống học máy mong muốn. Điều này giúp loại bỏ nguồn gây ra sự sai lệch trong việc phân phát nội dung đào tạo. Do đó, hãy cố gắng không sử dụng hai ngôn ngữ lập trình khác nhau giữa huấn luyện và phân phát. Quyết định đó sẽ khiến bạn gần như không thể chia sẻ mã.

Quy tắc #33: Nếu bạn tạo mô hình dựa trên dữ liệu cho đến ngày 5 tháng 1, hãy kiểm thử mô hình đó trên dữ liệu từ ngày 6 tháng 1 trở đi.

Nhìn chung, bạn nên đo lường hiệu suất của một mô hình dựa trên dữ liệu thu thập được sau dữ liệu mà bạn đã huấn luyện mô hình, vì dữ liệu này phản ánh rõ hơn hoạt động của hệ thống trong quá trình sản xuất chính thức. Nếu bạn tạo một mô hình dựa trên dữ liệu cho đến ngày 5 tháng 1, hãy kiểm thử mô hình đó trên dữ liệu từ ngày 6 tháng 1. Bạn dự kiến rằng hiệu suất trên dữ liệu mới sẽ không tốt như vậy, nhưng cũng không hẳn là kém hơn nhiều. Vì có thể có các tác động hằng ngày, nên bạn có thể không dự đoán tỷ lệ nhấp hoặc tỷ lệ chuyển đổi trung bình, nhưng khu vực bên dưới đường cong (thể hiện khả năng mang lại điểm số tích cực cao hơn ví dụ tiêu cực) sẽ gần đúng.

Quy tắc #34: Trong phân loại nhị phân để lọc (chẳng hạn như phát hiện thư rác hoặc xác định các email thú vị), hãy hy sinh ngắn hạn về hiệu suất để có được dữ liệu rất sạch.

Trong tác vụ lọc, các ví dụ được đánh dấu là tiêu cực sẽ không hiển thị cho người dùng. Giả sử bạn có một bộ lọc chặn 75% ví dụ phủ định khi phân phát. Bạn có thể muốn lấy thêm dữ liệu huấn luyện từ các thực thể mà người dùng nhìn thấy. Ví dụ: nếu người dùng đánh dấu một email là thư rác mà bộ lọc của bạn cho phép, bạn nên tìm hiểu điều đó.

Tuy nhiên, phương pháp này tạo ra thiên kiến lấy mẫu. Bạn có thể thu thập dữ liệu sạch hơn nếu trong quá trình phân phát, bạn gắn nhãn 1% cho tất cả lưu lượng truy cập là "bị giữ" và gửi tất cả các ví dụ bị giữ lại cho người dùng. Hiện tại, bộ lọc của bạn đang chặn ít nhất 74% ví dụ phủ định. Những ví dụ được giữ lại này có thể trở thành dữ liệu huấn luyện của bạn.

Lưu ý rằng nếu bộ lọc của bạn đang chặn 95% ví dụ phủ định trở lên, thì phương pháp này sẽ ít khả thi hơn. Mặc dù vậy, nếu muốn đo lường hiệu suất phân phát, bạn có thể tạo một mẫu nhỏ hơn nữa (chẳng hạn như 0,1% hoặc 0,001%). 10.000 ví dụ là đủ để ước tính hiệu suất khá chính xác.

Quy tắc #35: Hãy cảnh giác với sự sai lệch vốn có trong các vấn đề về thứ hạng.

Khi bạn chuyển đổi thuật toán xếp hạng đủ để các kết quả khác nhau xuất hiện, thì bạn đã thay đổi hiệu quả dữ liệu mà thuật toán của bạn sẽ nhìn thấy trong tương lai. Loại độ lệch này sẽ xuất hiện và bạn nên thiết kế mô hình xung quanh nó. Có nhiều cách tiếp cận. Các phương pháp này đều là cách để ưu tiên dữ liệu mà mô hình của bạn đã thấy.

  1. Có mức độ chính quy cao hơn đối với các tính năng bao gồm nhiều truy vấn hơn so với các tính năng chỉ được bật cho một truy vấn. Bằng cách này, mô hình sẽ ưu tiên các tính năng dành riêng cho một hoặc một vài cụm từ tìm kiếm thay vì các tính năng chung cho tất cả các cụm từ tìm kiếm. Phương pháp này có thể giúp ngăn các kết quả rất phổ biến bị rò rỉ vào các truy vấn không liên quan. Lưu ý rằng điều này trái ngược với lời khuyên thông thường hơn về việc điều chỉnh nhiều hơn các cột tính năng với các giá trị độc đáo hơn.
  2. Chỉ cho phép các tính năng có trọng số dương. Do đó, mọi tính năng tốt sẽ tốt hơn một tính năng "không xác định".
  3. Không có các tính năng chỉ dành cho tài liệu. Đây là phiên bản cực đoan của #1. Ví dụ: ngay cả khi một ứng dụng nhất định là một nội dung tải xuống phổ biến bất kể cụm từ tìm kiếm là gì, thì bạn không được phép xuất hiện ứng dụng đó ở mọi nơi. Việc không có các tính năng chỉ dành cho tài liệu sẽ luôn đơn giản. Lý do bạn không muốn hiển thị một ứng dụng phổ biến cụ thể ở mọi nơi có liên quan đến tầm quan trọng của việc làm cho tất cả ứng dụng mong muốn có thể truy cập được. Ví dụ: nếu ai đó tìm kiếm "ứng dụng xem chim", họ có thể tải "những chú chim tức giận", nhưng chắc chắn đó không phải là ý định của họ. Việc cho thấy một ứng dụng như vậy có thể giúp cải thiện tỷ lệ tải xuống, nhưng sau cùng sẽ khiến người dùng không hài lòng.

Quy tắc #36: Tránh vòng lặp phản hồi với các tính năng vị trí.

Vị trí của nội dung ảnh hưởng đáng kể đến khả năng người dùng sẽ tương tác với nội dung đó. Nếu bạn đặt ứng dụng ở vị trí đầu tiên, người dùng sẽ nhấp vào ứng dụng đó thường xuyên hơn và bạn sẽ tin rằng ứng dụng đó có nhiều khả năng được nhấp vào hơn. Một cách để xử lý vấn đề này là thêm các tính năng vị trí, tức là các tính năng về vị trí của nội dung trong trang. Bạn huấn luyện mô hình của mình bằng các tính năng vị trí và mô hình sẽ học trọng số, ví dụ: tính năng "vị trí thứ nhất". Do đó, mô hình của bạn giảm trọng số cho các yếu tố khác, ví dụ như "1stposition=true". Sau đó, khi phân phát, bạn không cung cấp cho bất kỳ thực thể nào tính năng vị trí hoặc bạn cung cấp cho chúng tất cả tính năng mặc định giống nhau, vì bạn đang chấm điểm đề xuất trước khi quyết định thứ tự hiển thị chúng.

Lưu ý rằng điều quan trọng là phải giữ mọi tính năng vị trí tách biệt với phần còn lại của mô hình do sự bất cân xứng này giữa quá trình huấn luyện và kiểm thử. Lý tưởng thì mô hình này là tổng hàm của các tính năng vị trí và hàm của các tính năng còn lại. Ví dụ: đừng chọn các tính năng có vị trí với bất kỳ tính năng nào của tài liệu.

Quy tắc #37: Đo lường độ lệch trong quá trình đào tạo/phân phát.

Theo nghĩa chung, có một số điều có thể gây ra sự sai lệch. Hơn nữa, bạn có thể chia báo cáo thành nhiều phần:

  • Sự khác biệt giữa hiệu suất trên dữ liệu huấn luyện và dữ liệu lưu giữ. Nhìn chung, vấn đề này sẽ luôn tồn tại và không phải lúc nào cũng xấu.
  • Sự chênh lệch giữa hiệu suất của dữ liệu giữ lại và dữ liệu "ngày tiếp theo". Xin nhắc lại rằng điều này sẽ luôn tồn tại. Bạn nên điều chỉnh quy trình chính quy để tối đa hoá hiệu suất vào ngày tiếp theo. Tuy nhiên, sự sụt giảm lớn về hiệu suất giữa dữ liệu tạm ngưng và dữ liệu của ngày tiếp theo có thể cho thấy một số tính năng có giới hạn về thời gian và có thể làm giảm hiệu suất của mô hình.
  • Sự khác biệt giữa hiệu suất của dữ liệu "ngày tiếp theo" và dữ liệu trực tiếp. Nếu bạn áp dụng một mô hình cho một ví dụ trong dữ liệu huấn luyện và cùng một ví dụ khi phân phát, thì mô hình đó sẽ cung cấp cho bạn kết quả giống hệt nhau (xem Quy tắc #5). Do đó, sự chênh lệch ở đây có thể là do lỗi kỹ thuật.

Giai đoạn học máy III: Tăng trưởng chậm, Tinh chỉnh cách tối ưu hoá và Mô hình phức tạp

Sẽ có những dấu hiệu nhất định cho thấy giai đoạn 2 sắp kết thúc. Trước hết, lợi nhuận hằng tháng của bạn sẽ bắt đầu giảm đi. Bạn sẽ bắt đầu có sự đánh đổi giữa các chỉ số: bạn sẽ thấy một số chỉ số tăng lên và một số khác lại giảm trong một số thử nghiệm. Đây là điểm thú vị. Vì khó đạt được lợi ích hơn nên công nghệ học máy phải trở nên tinh vi hơn. Lưu ý: phần này có nhiều quy tắc trời xanh hơn so với các phần trước. Chúng tôi đã chứng kiến nhiều nhóm trải qua thời gian vui vẻ của công nghệ học máy ở Giai đoạn I và Giai đoạn II. Sau khi đạt đến Giai đoạn III, các nhóm phải tìm ra con đường của riêng mình.

Quy tắc #38: Đừng lãng phí thời gian vào các tính năng mới nếu các mục tiêu không nhất quán trở thành vấn đề.

Khi đo lường xong, nhóm của bạn sẽ bắt đầu xem xét các vấn đề nằm ngoài phạm vi mục tiêu của hệ thống học máy hiện tại. Như đã nêu trước đó, nếu mục tiêu sản phẩm không thuộc phạm vi áp dụng của mục tiêu thuật toán hiện tại, bạn cần thay đổi mục tiêu hoặc mục tiêu sản phẩm. Ví dụ: bạn có thể tối ưu hoá số lượt nhấp, lượt cộng một hoặc lượt tải xuống, nhưng đưa ra quyết định về việc ra mắt một phần dựa trên người đánh giá.

Quy tắc số 39: Quyết định ra mắt là chỉ số đại diện cho mục tiêu sản phẩm dài hạn.

Alice có ý tưởng về việc giảm thiểu tổn thất hậu cần khi dự đoán số lượt cài đặt. Cô ấy thêm một tính năng. Tỷ lệ tổn thất hậu cần giảm. Khi thực hiện thử nghiệm trực tiếp, cô ấy thấy tỷ lệ cài đặt tăng lên. Tuy nhiên, khi cô đi đến cuộc họp đánh giá việc ra mắt, có người chỉ ra rằng số lượng người dùng hoạt động hằng ngày giảm 5%. Nhóm quyết định không ra mắt mô hình này. Alice cảm thấy thất vọng, nhưng giờ đây, cô nhận ra rằng các quyết định ra mắt phụ thuộc vào nhiều tiêu chí, chỉ có một số tiêu chí có thể được tối ưu hoá trực tiếp bằng công nghệ học máy.

Sự thật là thế giới thực không phải là những hầm ngục và con rồng: không có "điểm chạm" nào xác định tình trạng của sản phẩm của bạn. Nhóm phải sử dụng số liệu thống kê thu thập được để cố gắng dự đoán hiệu quả mức độ tốt của hệ thống trong tương lai. Họ cần quan tâm đến mức độ tương tác, số người dùng hoạt động trong 1 ngày (DAU), 30 DAU, doanh thu và lợi tức đầu tư của nhà quảng cáo. Bản thân những chỉ số có thể đo lường trong thử nghiệm A/B này chỉ là proxy cho các mục tiêu dài hạn hơn: đáp ứng người dùng, tăng số người dùng, đáp ứng đối tác và lợi nhuận.

Quyết định ra mắt dễ dàng duy nhất là khi tất cả các chỉ số trở nên tốt hơn (hoặc ít nhất không kém đi). Nếu phải lựa chọn giữa thuật toán học máy tinh vi và phương pháp phỏng đoán đơn giản, thì nếu phương pháp phỏng đoán đơn giản hoạt động hiệu quả hơn về tất cả những chỉ số này, thì nhóm nên chọn phương pháp phỏng đoán đó. Hơn nữa, không có thứ hạng rõ ràng về tất cả các giá trị chỉ số có thể có. Cụ thể, hãy xem xét 2 trường hợp sau:

Thử nghiệm Số người dùng hoạt động hàng ngày Doanh thu/Ngày
A 1 triệu 4 triệu USD
B 2 triệu 2 triệu USD

Nếu hệ thống hiện tại là A, thì nhóm khó có khả năng chuyển sang B. Nếu hệ thống hiện tại là B, thì nhóm sẽ không có khả năng chuyển sang A. Điều này có vẻ mâu thuẫn với hành vi hợp lý; tuy nhiên, các dự đoán về việc thay đổi chỉ số có thể hoặc có thể không mở rộng, và do đó có rủi ro lớn liên quan đến thay đổi này. Mỗi chỉ số thể hiện một số rủi ro mà nhóm quan tâm.

Hơn nữa, không có chỉ số nào bao hàm mối quan tâm hàng đầu của nhóm: "Sản phẩm của tôi sẽ ra mắt trong 5 năm tới"?

Mặt khác, các cá nhân có xu hướng ưu tiên một mục tiêu mà họ có thể trực tiếp tối ưu hoá. Hầu hết các công cụ học máy đều ưa thích môi trường như vậy. Một kỹ sư ứng dụng các tính năng mới có thể có được chuỗi sự kiện ra mắt ổn định trong môi trường như vậy. Có một loại công nghệ học máy là học đa mục tiêu, giúp giải quyết vấn đề này. Ví dụ: người dùng có thể xây dựng một bài toán về sự hài lòng ràng buộc có giới hạn dưới đối với mỗi chỉ số và tối ưu hoá một số tổ hợp chỉ số tuyến tính. Tuy nhiên, ngay cả khi đó, không phải mọi chỉ số nào cũng dễ dàng được coi là mục tiêu học máy: nếu người dùng nhấp vào một tài liệu hoặc cài đặt một ứng dụng, thì đó là do nội dung đã được hiển thị. Nhưng khó tìm hiểu lý do người dùng truy cập vào trang web của bạn. Cách dự đoán thành công trong tương lai của một trang web nói chung là trí tuệ nhân tạo hoàn chỉnh: khó như thị giác máy tính hay khả năng xử lý ngôn ngữ tự nhiên.

Quy tắc #40: Giữ cho trang phục đơn giản.

Mô hình hợp nhất sử dụng các tính năng thô và trực tiếp xếp hạng nội dung là mô hình dễ nhất để gỡ lỗi và hiểu được. Tuy nhiên, một tập hợp các mô hình ("mô hình" kết hợp điểm số của các mô hình khác) có thể hoạt động tốt hơn. Để đơn giản hoá mọi thứ, mỗi mô hình nên là một tập hợp chỉ nhận dữ liệu đầu vào của các mô hình khác, hoặc một mô hình cơ sở có nhiều tính năng, chứ không phải cả hai. Nếu bạn có các mô hình ngoài các mô hình khác được huấn luyện riêng, thì việc kết hợp các mô hình đó có thể dẫn đến hành vi xấu.

Sử dụng một mô hình đơn giản để kết hợp chỉ lấy đầu ra của các mô hình "cơ sở" làm dữ liệu đầu vào. Bạn cũng nên thực thi các thuộc tính trên các mô hình tập hợp này. Ví dụ: việc tăng điểm số do mô hình cơ sở tạo ra không được làm giảm điểm của tập hợp. Ngoài ra, tốt nhất là các mô hình sắp tới có thể diễn giải được ngữ nghĩa (ví dụ: đã được hiệu chỉnh) để những thay đổi của mô hình cơ sở không gây nhầm lẫn cho mô hình tổng thể. Ngoài ra, hãy thực thi việc tăng xác suất dự đoán của một thuật toán phân loại cơ bản sẽ không làm giảm xác suất dự đoán của tập hợp.

Quy tắc #41: Khi hiệu suất không thay đổi, hãy tìm các nguồn thông tin mới về mặt định tính để bổ sung thay vì tinh chỉnh các tín hiệu hiện có.

Bạn đã thêm một số thông tin nhân khẩu học về người dùng. Bạn đã thêm một số thông tin về các từ trong tài liệu. Bạn đã trải qua quá trình khám phá mẫu và điều chỉnh việc điều chỉnh. Trong một vài quý, bạn chưa thấy một đợt phát hành mà các chỉ số chính của bạn cải thiện hơn 1%. Bây giờ bạn phải làm gì?

Đã đến lúc bắt đầu xây dựng cơ sở hạ tầng cho các tính năng hoàn toàn khác biệt, chẳng hạn như nhật ký tài liệu mà người dùng này đã truy cập trong ngày, tuần trước hoặc năm trước hoặc dữ liệu từ một tài sản khác. Sử dụng các thực thể wikidata hoặc nội dung nào đó trong nội bộ công ty của bạn (chẳng hạn như sơ đồ tri thức của Google). Sử dụng công nghệ học sâu. Hãy bắt đầu điều chỉnh kỳ vọng về mức lợi tức đầu tư mà bạn mong đợi và mở rộng các nỗ lực cho phù hợp. Như trong bất kỳ dự án kỹ thuật nào, bạn phải cân nhắc lợi ích của việc thêm các tính năng mới với chi phí tăng độ phức tạp.

Quy tắc #42: Đừng mong đợi tính đa dạng, cá nhân hoá hoặc mức độ liên quan cùng với mức độ phổ biến như bạn vẫn nghĩ.

Sự đa dạng trong một nhóm nội dung có thể mang lại nhiều ý nghĩa, trong đó sự đa dạng về nguồn nội dung là một trong những yếu tố phổ biến nhất. Hoạt động cá nhân hoá ngụ ý rằng mỗi người dùng nhận được kết quả của riêng họ. Mức độ liên quan ngụ ý rằng các kết quả cho một cụm từ tìm kiếm cụ thể phù hợp hơn với cụm từ tìm kiếm đó so với bất kỳ cụm từ tìm kiếm nào khác. Do đó, cả ba thuộc tính này được xác định là khác với thuộc tính thông thường.

Vấn đề là sự bình thường thường khó vượt qua.

Xin lưu ý rằng nếu hệ thống của bạn đo lường số lượt nhấp, thời gian sử dụng, số lượt xem, lượt +1, lượt chia sẻ lại, v.v., thì bạn đang đo lường mức độ phổ biến của nội dung đó. Đôi khi, các nhóm cố gắng học một mô hình cá nhân với sự đa dạng. Để cá nhân hoá, họ thêm các tính năng cho phép hệ thống cá nhân hoá (một số tính năng thể hiện mối quan tâm của người dùng) hoặc đa dạng hoá (các tính năng cho biết liệu tài liệu này có bất kỳ đặc điểm nào chung với các tài liệu khác được trả về, chẳng hạn như tác giả hoặc nội dung) và nhận thấy các tính năng đó có trọng số ít hơn (hoặc đôi khi là một dấu hiệu khác) so với dự kiến.

Điều này không có nghĩa là tính đa dạng, cá nhân hoá hoặc mức độ phù hợp không có giá trị. Như đã nêu trong quy tắc trước đó, bạn có thể tiến hành xử lý hậu kỳ để tăng tính đa dạng hoặc mức độ liên quan. Nếu thấy các mục tiêu dài hạn tăng lên, thì bạn có thể khai báo rằng tính đa dạng/mức độ liên quan là có giá trị, ngoài mức độ phổ biến. Sau đó, bạn có thể tiếp tục sử dụng tính năng xử lý hậu kỳ hoặc trực tiếp sửa đổi mục tiêu dựa trên tính đa dạng hoặc mức độ liên quan.

Quy tắc số 43: Bạn bè của bạn có xu hướng giống nhau trên các sản phẩm khác nhau. Mối quan tâm của bạn thường không như vậy.

Các nhóm tại Google đã thu hút được nhiều công sức từ việc xây dựng một mô hình dự đoán mức độ gần gũi của mối kết nối trong một sản phẩm, và việc mô hình đó hoạt động tốt trên một sản phẩm khác. Bạn bè của bạn là ai. Mặt khác, tôi đã theo dõi nhiều nhóm vật lộn với các tính năng cá nhân hoá trên các sản phẩm được phân chia. Có, có vẻ như nó sẽ hoạt động. Có vẻ hiện tại thì chưa. Đôi khi, một tính năng là sử dụng dữ liệu thô từ một thuộc tính để dự đoán hành vi trên một thuộc tính khác. Ngoài ra, hãy lưu ý rằng việc biết rằng người dùng có nhật ký trên một tài sản khác cũng có thể giúp ích. Ví dụ: sự hiện diện của hoạt động của người dùng trên 2 sản phẩm có thể chỉ biểu thị.

Có nhiều tài liệu về công nghệ học máy tại Google cũng như bên ngoài.

Xác nhận

Cảm ơn những tài liệu hữu ích của David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Information, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Katsiapis xue. Ngoài ra, nhờ Kristen Lefevre, Suddha Basu và Chris Berg giúp phiên bản cũ hơn. Mọi lỗi, thiếu sót hay ý kiến không phổ biến đều là của tôi.

Phụ lục

Có nhiều nội dung tham khảo về các sản phẩm của Google trong tài liệu này. Để cung cấp thêm ngữ cảnh, tôi sẽ mô tả ngắn gọn các ví dụ phổ biến nhất bên dưới.

Tổng quan về YouTube

YouTube là dịch vụ phát video trực tuyến. Cả nhóm Xem video tiếp theo trên YouTube và Trang chủ YouTube đều sử dụng các mô hình học máy để xếp hạng video đề xuất. Trang Watch Next đề xuất video để xem sau video đang phát, trong khi Trang chủ đề xuất video cho người dùng duyệt xem trang chủ.

Tổng quan về Google Play

Google Play có nhiều mô hình giải quyết đa dạng vấn đề. Các ứng dụng Tìm kiếm trên Play, Đề xuất được cá nhân hoá trên Trang chủ Play và "Người dùng cũng cài đặt" đều sử dụng công nghệ máy học.

Tổng quan về Google+

Google Plus đã sử dụng công nghệ học máy trong nhiều tình huống: xếp hạng bài đăng trong "luồng" bài đăng mà người dùng đang xem, xếp hạng bài đăng "Phổ biến" (bài đăng hiện rất phổ biến), xếp hạng những người bạn biết, v.v. Google Plus đã đóng cửa tất cả tài khoản cá nhân vào năm 2019 và được thay thế bằng Google Currents dành cho tài khoản doanh nghiệp vào ngày 6 tháng 7 năm 2020.