Quy tắc của máy học:

Các phương pháp hay nhất để cải tiến kỹ thuật máy học

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ề máy học nhận được lợi ích từ các phương pháp hay nhất của Google trong công nghệ máy học. Nó thể hiện một phong cách cho công nghệ máy học, tương tự như Hướng dẫn về quy tắc lập trình Google C++ và các hướng dẫn phổ biến khác về lập trình thực tế. Nếu đã tham gia một lớp học về máy học hoặc được xây dựng hay làm việc trên một mô hình máy học, thì bạn 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 yêu thích của anh trong lĩnh vực máy học. Hãy đọc tiếp để tìm hiểu tất cả 43 quy tắc!

Thuật ngữ

Các thuật ngữ sau đây sẽ liên tục xuất hiện trong cuộc thảo luận của chúng ta về máy học hiệu quả:

  • Instance (Thực thể): Thứ mà bạn muốn đưa ra dự đoán. 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 hoặc câu trả lời do hệ thống máy học 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 của trang web có thể là "về mèo".
  • Đối tượng: Một thuộc tính của một thực thể được dùng trong một 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: Một tập hợp các tính năng liên quan, chẳng hạn như tập hợp tất cả quốc gia có thể sử dụng mà người dùng có thể sống. Ví dụ: cột tính năng có thể có một hoặc nhiều 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 trường.
  • Ví dụ: Một bản sao (với các tính năng của nó) và một nhãn.
  • Mô hình: Trình bày thống kê của một tác vụ dự đoán. Bạn huấn luyện một mô hình dựa trên các ví dụ, sau đó sử dụng mô hình đó để đưa ra các thông tin dự đoán.
  • Chỉ số: Chỉ số mà bạn quan tâm. Có thể hoặc không được tối ưu hoá trực tiếp.
  • Mục tiêu: Một chỉ số mà thuật toán của bạn đang cố gắng tối ưu hóa.
  • Pipeline (Cơ sở hạ tầng): Cơ sở hạ tầng xung quanh một thuật toán máy học. Bao gồm 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 đào tạo, đào tạo một hoặc nhiều mô hình và xuất các mô hình sang môi trường thực tế.
  • Tỷ lệ nhấp Tỷ lệ phần trăm khách truy cập vào một trang web nhấp vào một đường liên kết trong quảng cáo.

Tổng quan

Cách tạo ra những sản phẩm tuyệt vời:

những công nghệ máy học như bạn là một kỹ sư xuất sắc chứ không phải là chuyên gia máy học giỏi.

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

  1. Bạn cần đảm bảo quy trình của mình diễn ra suôn sẻ.
  2. Hãy bắt đầu với một mục tiêu hợp lý.
  3. Thêm các tính năng phổ biến theo cách đơn giản.
  4. Bạn cần đảm bảo quy trình này diễn ra suôn sẻ.

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

Một khi bạn đã hiểu được các thủ thuật đơn giản, công nghệ máy học tiên tiến có thể đã thực sự là một tương lai của bạn. Hãy xem phần về các dự án máy học 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 biết được thời điểm nào là phù hợp để xây dựng một hệ thống máy học.
  2. Phần thứ hai là về cách triển khai quy trình đầu tiên.
  3. Phần thứ ba là về việc ra mắt và lặp lại trong khi thêm các tính năng mới vào quy trình, cách đánh giá các mô hình và kỹ thuật phân phát huấn luyện.
  4. Phần cuối cùng là về những việc cần làm khi bạn đến cao nguyên.
  5. Sau đó là danh sách các công việc liên quan và một phụ lục đi kèm với một số thông tin cơ bản về các hệ thống thường được dùng làm ví dụ trong tài liệu này.

Trước công nghệ máy học

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

Công nghệ máy học rất thú vị, nhưng đòi hỏi phải 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. Tuy nhiên, việc này có thể sẽ kém hiệu quả hơn so với phương pháp phỏng đoán cơ bản. Nếu bạn nghĩ rằng công nghệ máy học sẽ tăng 100% thì định nghĩa sẽ mang lại cho bạn 50% thời gian ở đó.

Ví dụ: nếu đang xếp hạng ứng dụng trong một cửa hàng ứng dụng, bạn có thể sử dụng tỷ lệ cài đặt hoặc số lượt cài đặt làm phương pháp phỏng đoán. Nếu bạn đang phát hiện spam, hãy lọc ra các nhà xuất bản đã gửi spam trước đó. Bạn cũng đừng ngại sử dụng cách chỉnh sửa con người. Nếu bạn cần xếp hạng những người liên hệ, hãy xếp hạng người cao nhất 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 công nghệ máy học không hoàn toàn bắt buộc đối với sản phẩm của bạn, thì đừng sử dụng công nghệ này cho đến khi bạn có dữ liệu.

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

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

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

Nhóm Google Plus đo lường mức độ mở rộng trên mỗi lượt đọc, chia sẻ lại mỗi lượt đọc, cộng một lần mỗi lượt đọc, nhận xét/đọc, nhận xét trên mỗi người dùng, chia sẻ lại trên mỗi người dùng, v.v. mà họ sử dụng để tính toán mức độ hiệu quả của bài đăng tại thời điểm phân phát. Ngoài ra, xin lưu ý rằng một khung thử nghiệm mà 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à việc rất quan trọng. Xem Quy tắc #12.

Bằng cách tự do hơn về việc thu thập các chỉ số, bạn có thể có được bức tranh toàn cảnh hơn về hệ thống của mình. Bạn nhận thấy vấn đề? Hãy thêm chỉ số để theo dõi! Bạn có hào hứng với một số thay đổi về số 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!

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

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

Giai đoạn máy học 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 vui khi nghĩ về tất cả những gì máy học trí tưởng tượng bạn sẽ làm, nhưng sẽ rất khó để tìm hiểu đ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 #4: Giữ cho 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 là mô hình thúc đẩy lớn nhất cho sản phẩm, vì vậy, không cần phải quá kích thích. Tuy nhiên, bạn sẽ gặp nhiều vấn đề về cơ sở hạ tầng hơn dự kiến. Trước khi có ai đó có thể sử dụng hệ thống máy học mới lạ của bạn, bạn phải xác định:

  • Cách xem ví dụ về thuật toán học.
  • Một vết cắt đầu tiên có ý nghĩa như thế nào là "tốt" và "không tốt" đối với hệ thống.
  • 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 trong các ví dụ ngoại tuyến và 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.

Khi chọn các tính năng đơn giản, bạn sẽ dễ dàng đảm bảo rằng:

  • Các tính năng đều tiếp cận đúng thuật toán học.
  • Mô hình học hỏi trọng số hợp lý.
  • Các tính năng 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 ba việc này một cách đáng tin cậy, bạn đã hoàn tất hầu hết công việc. Mô hình đơn giản của bạn cung cấp cho bạn các chỉ số cơ sở và một hành vi cơ sở mà bạn có thể sử 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 "trung lập": lần phát hành đầu tiên ưu tiên rõ ràng mức tăng máy học để tránh bị phân tâm.

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

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

  1. Thử nghiệm việc lấy dữ liệu vào thuật toán. Kiểm tra để đảm bảo rằng các cột tính năng cần được điền sẵn. Khi quyền riêng tư cho phép, hãy kiểm tra thủ công dữ liệu đầu vào cho thuật toán đào tạo của bạn. 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. Thử nghiệm việc xoá mô hình khỏi thuật toán huấn luyện. Đảm bảo rằng mô hình trong môi trường huấn luyện của bạn có cùng điểm số với mô hình trong môi trường phân phát (xem Quy tắc #37).

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

Quy tắc #6: Hãy cẩn thận với dữ liệu được thả khi sao chép quy trình.

Thông thường, chúng tôi 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 giáo phái hàng hoá), và quy trình cũ loại bỏ dữ liệu mà chúng tôi cần cho quy trình mới. Ví dụ như quy trình cho Google+ Thú vị bỏ qua các bài đăng cũ (vì cố gắng xếp hạng bài đăng mới). Quy trình này đã được sao chép để sử dụng cho Bảng tin 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 giảm các bài đăng cũ. Một mẫu phổ biến khác là chỉ ghi lại dữ liệu mà người dùng đã xem. Do đó, dữ liệu này sẽ không hữu ích nếu chúng tôi muốn lập mô hình tại sao một bài đăng cụ thể không được người dùng nhìn thấy, vì tất cả ví dụ phủ định đã bị loại bỏ. Đã xảy ra sự cố tương tự trong Play. Trong quá trình làm việc trên Trang chủ ứng dụng Play, chúng tôi đã tạo một quy trình mới cũng chứa 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 tính năng hoặc xử lý suy luận bên ngoài.

Thông thường, các vấn đề mà công nghệ máy học đang cố gắng giải quyết không hoàn toàn mới. Hiện có 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. Điều này có nghĩa là có một loạt các quy tắc và phỏng đoán. Những phương pháp phỏng đoán này cũng có thể giúp bạn tăng hiệu suất khi điều chỉnh bằng công nghệ máy học. Bạn nên khai thác thông tin phỏng đoán của mình vì bất cứ thông tin nào có được vì hai lý do. Trước tiên, quá trình chuyển đổi sang hệ thống máy học sẽ mượt mà 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 loại bỏ. Bạn có 4 cách để sử dụng phương pháp phỏng đoán hiện có:

  • Xử lý trước bằng cách sử dụng phương pháp phỏng đoán. Nếu tính năng này thực sự tuyệt vời, thì đây là một tùy chọn. Ví dụ: nếu trong bộ lọc thư rác, người gửi đã bị đưa vào danh sách cấm, thì đừng cố gắng tìm hiểu lại ý nghĩa của "danh sách cấm". Chặn tin nhắn đó. Phương pháp này có ý nghĩa nhất trong các tác vụ phân loại nhị phân.
  • Tạo một tính năng. Việc trực tiếp tạo ra một tính năng từ phỏng đoán thật tuyệt vời. 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 kết quả truy vấn, bạn có thể đưa điểm số làm giá trị của một tính năng. Sau đó, bạn có thể sử dụng kỹ thuật máy học để mát-xa giá trị (ví dụ: chuyển đổi giá trị thành một trong các tập hợp giá trị riêng biệt 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ố lượng ký tự trong văn bản và ngày trong tuần, hãy cân nhắc tách riêng những phần này ra và đưa các dữ liệu đầu vào này vào hoạt động học tập một cách riêng biệt. Một số kỹ thuật áp dụng cho các nhóm được áp dụng ở đây (xem Quy tắc #40).
  • Sửa đổi nhãn. Đây là một tùy chọn khi bạn cảm thấy rằng phỏng đoán thu thập 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 có nội dung chất lượng cao, 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 đường đi ở đây. Hãy xem "Mục tiêu đầu tiên của bạn".

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

Monitoring

Nhìn chung, hãy áp dụng biện pháp vệ sinh cảnh báo hiệu quả, chẳng hạn như tạo cảnh báo hữu ích và có trang tổng quan.

Quy tắc #8: Biết các yêu cầu về độ mới của hệ thống.

Hiệu suất giảm xuống bao nhiêu nếu bạn có mô hình cách đây một ngày? Cách đây một tuần? Một quý? Thông tin này có thể giúp bạn hiểu rõ mức độ ưu tiên của hoạt động giám sát. Nếu bạn mất chất lượng sản phẩm đáng kể nếu mô hình không được cập nhật trong một ngày, việc kỹ sư xem mẫu liên tục là điều hợp lý. 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 mỗi ngày. Ví dụ: nếu mô hình Máy học cho Google Play Tìm kiếm không được cập nhật, mô hình này có thể có tác động tiêu cực trong vòng chưa đầy một tháng. Một số mô hình cho mục Thú vị trong Google Plus không có giá trị nhận dạng bài đăng trong mô hình của chúng để họ có thể không thường xuyên xuất những mô hình này. 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, hãy 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 xoá khỏi mô hình.

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

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

Hãy kiểm tra tình trạng ngay trước khi xuất mô hình. Cụ thể, hãy đảm bảo rằng hiệu suất của mô hình hợp lý khi lưu giữ dữ liệu. Hoặc, nếu bạn lo ngại về vấn đề lưu trữ 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 khu vực trong đường cong ROC (hoặc AUC) trước khi xuất. Bạn phải gửi cảnh báo qua email cho các vấn đề về mô hình chưa được xuất, nhưng các mô hình mà người dùng nhìn thấy có thể yêu cầu bạn gửi một trang. Vì vậy, bạn nên chờ và chắc chắn trước khi ảnh hưởng đến người dùng.

Quy tắc #10: Chú ý đến các lỗi im lặng.

Đây là một vấn đề xảy ra ở nhiều hệ thống máy học hơn so với 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. Hệ thống máy học sẽ điều chỉnh và hành vi của bạn sẽ tiếp tục diễn ra tốt, giảm dần. Đôi khi, bạn sẽ thấy các bảng đã lỗi thời vài tháng và tính năng làm mới đơn giản sẽ cải thiện hiệu suất hơn bất kỳ bảng 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 vào 90% ví dụ, và độ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ỉ làm mới bảng đã giúp tỷ lệ cài đặt tăng 2%. Nếu bạn 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, thì 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ộ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 đang duy trì từng cột tính năng. Nếu bạn thấy người hiểu rằng cột tính năng đang rời đi, hãy đảm bảo rằng người đó 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 của tính năng và dự kiến tính năng đó sẽ hữu ích như thế nào.

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

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

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

Bạn muốn kiếm tiền, làm cho người dùng hài lòng và giúp 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ố này (xem Quy tắc #2). Tuy nhiên, trong quá trình máy học, bạn sẽ nhận thấy tất cả các giá trị này được cải thiện, ngay cả những giá trị bạn không tối ưu hoá trực tiếp. 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 hóa cho số lượt nhấp, bạn có thể sẽ thấy thời gian tăng lên.

Vì vậy, hãy đơn giản và đừng quá cân nhắc 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 áp dụng quy tắc này quá xa: đừng nhầm lẫn mục tiêu với tình trạng cuối cùng của hệ thống (xem Quy tắc #39). Và nếu bạn thấy mình tăng chỉ số được tối ưu hoá trực tiếp, nhưng quyết định không khởi chạy, bạn có thể cần phải sửa đổi một số mục tiêu.

Quy tắc #13: Chọn một chỉ số đơn giản, quan sát được và phân bổ cho mục tiêu đầu tiên.

Thường thì bạn không biết mục tiêu thực sự là gì. Bạn nghĩ là bạn làm vậy nhưng sau đó khi nhìn vào dữ liệu và phân tích cạnh nhau của hệ thống cũ và hệ thống máy học mới, bạn nhận ra rằng mình muốn điều chỉnh mục tiêu. Ngoài ra, các thành viên nhóm khác nhau thường không thể thống nhất về mục tiêu thực sự. Mục tiêu ML phải là một thứ gì đó dễ đo lường và là một proxy cho mục tiêu "đúng". Trên thực tế, thường không có mục tiêu "thực" (xem Quy tắc#39). Vì vậy, hãy đào tạo về mục tiêu máy học đơ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 logic rất đơn giản) để thực hiện thứ hạng cuối cùng.

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

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

Trước hết, 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 tiếp theo không?
  • Người dùng truy cập vào trang web này trong bao lâu?
  • Người dùng hoạt động hằng ngày là gì?

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

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

  • Người dùng có hài lòng khi sử dụng sản phẩm này 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ó cải thiện được sức khoẻ tổng thể của người dùng không?
  • Việc này sẽ ảnh hưởng như thế nào đến sức khoẻ tổng thể của công ty?

Những chỉ số này đều quan trọng nhưng cũng vô cùng 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 trên 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. Về sức khỏe thể chất và tinh thần của công ty, sự đánh giá của con người là cần thiết để kết nối mọi mục tiêu máy học với bản 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 bằng một mô hình có thể diễn giải sẽ giúp gỡ lỗi dễ dàng hơn.

Các mô hình hồi quy tuyến tính, hồi quy logistic và hồi quy Poisson được thúc đẩy trực tiếp bởi mô hình xác suất. Mỗi dự đoán có thể được diễn giải là xác suất hoặc 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 (không mất một lần, mất nhiều bản lề, v.v.) cố gắng tối ưu hoá trực tiếp độ chính xác của cách phân loại hoặc hiệu suất xếp hạng. Ví dụ: nếu xác suất đào tạo sai lệch với xác suất được dự đoán cạnh nhau hoặc bằng cách kiểm tra hệ thống sản xuất thì độ lệch này có thể tiết lộ 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 của dữ liệu, trong đó kỳ vọng dự đoán trung bình bằng nhãn trung bình (1 – hiệu chỉnh thời điểm hoặc vừa hiệu chỉnh). Điều này đúng với giả định bạn không chuẩn hoá và thuật toán của bạn đã hội tụ, và điều này nói chung là đúng. Nếu bạn có một tính năng là 1 hoặc 0 cho mỗi ví dụ, thì tập hợp 3 ví dụ mà trong đó tính năng đó 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ả ví dụ sẽ được hiệu chỉnh.

Với các mô hình đơn giản, bạn sẽ dễ dàng xử lý các vòng lặp phản hồi hơn (xem nội dung 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: ví dụ: xếp hạng bài đăng trong việc giảm giá trị dự kiến (tức là xác suất nhấp chuột/tải xuống/v.v.). Tuy nhiên, hãy nhớ rằng khi đến lúc chọn mô hình sẽ sử dụng, quyết định này có ý nghĩa quan trọng hơn so với khả năng của dữ liệu dựa trên mô hình đó (xem Quy tắc #27).

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

Việc xếp hạng chất lượng là một nghệ thuật, nhưng việc lọc nội dung rác 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 nên tập trung vào việc xếp hạng nội dung được đăng một cách thành thực. Bạn không nên giảm giá cho người học xếp hạng chất lượng để có thứ hạng cao. Tương tự, bạn phải xử lý riêng nội dung "không phù hợp" với Thứ hạng chất lượng. Lọc spam là một câu chuyện khác. Các tính năng mà bạn cần tạo sẽ liên tục thay đổi. Thông thường, sẽ có những 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 ba phiếu bầu spam, thì bạn không được truy xuất nó, v.v.). Mọi mô hình đã học sẽ được cập nhật hằng ngày, nếu không sẽ nhanh hơn. Danh tiếng của nhà sáng tạo nội dung sẽ đóng vai trò rất quan trọng.

Ở cấp độ 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ể linh hoạt hơn so với việc lọc thư rác trong email. Điều này đúng với giả định bạn không chuẩn hoá và thuật toán của bạn đã hội tụ. Đó là điều gần đúng nói chung. Ngoài ra, đây là một phương pháp tiêu chuẩn để loại bỏ thư rác khỏi dữ liệu huấn luyện cho thuật toán phân loại chất lượng.

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

Trong giai đoạn đầu trong vòng đời của một hệ thống máy học, các vấn đề quan trọng là lấy dữ liệu đào tạo vào hệ thống học tập, lấy bất kỳ chỉ số nào được 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 kết thúc hoạt động với các kiểm thử đơn vị và kiểm thử hệ thống, Giai đoạn II bắt đầu.

Trong giai đoạn thứ hai, sẽ có nhiều quả ở vị trí thấp. Có nhiều tính năng rõ ràng có thể được kéo vào hệ thống. Do đó, giai đoạn thứ hai của công nghệ máy học sẽ kéo nhiều tính năng nhất có thể vào 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 tăng lên. Sẽ có rất nhiều lần phát hành, và đây là thời điểm tuyệt vời để thu hút nhiều kỹ sư có thể kết hợp tất cả dữ liệu mà bạn cần để 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 rằng mô hình mà bạn đang xây dựng sẽ là mô hình cuối cùng mà bạn sẽ khởi chạy, hoặc thậm chí là bạn sẽ không bao giờ ngừng khởi chạy các mô hình. Do đó, hãy cân nhắc xem độ phức tạp mà bạn thêm vào bản phát hành này sẽ làm chậm các lần khởi chạy trong tương lai hay không. Nhiều nhóm đã triển khai một mô hình theo quý hoặc nhiều năm hơn. Có 3 lý do cơ bản để ra mắt mô hình mới:

  • Bạn đang nghĩ ra các tính năng mới.
  • Bạn đang điều chỉnh quá trình thường xuyên 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.

Bất kể việc cung cấp một mô hình hơi yêu thích là một việc 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 xây dựng mô hình, hãy cân nhắc việc thêm hoặc xoá các tính năng dễ dàng như thế nào. Hãy cân nhắc việc dễ dàng 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. Hãy nghĩ xem có thể có hai hoặc ba bản sao song song không. Cuối cùng, đừng lo lắng về việc liệu tính năng 16/35 có thuộc về phiên bản này của quy trình hay không. Bạn sẽ nhận được bản phát hành này vào quý tiếp theo.

Quy tắc #17: Bắt đầu với các tính năng được quan sát và báo cáo trực tiếp thay vì các tính năng đã tìm hiểu.

Đây có thể là một vấn đề gây tranh cãi, nhưng nó giúp tránh được rất nhiều lỗi. 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 tạo ra (chẳng hạn như hệ thống phân nhóm không được giám sát) hoặc chính người học (ví dụ như thông qua mô hình phân bổ hoặc học sâu). Cả hai đều có thể hữu ích, nhưng cũng có thể xảy ra nhiều vấn đề, vì vậy không nên thuộc mô hình đầu tiên.

Nếu bạn sử dụng một hệ thống bên ngoài để tạo 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ỉ liên quan yếu với mục tiêu hiện tại của bạn. Nếu bạn chụp nhanh ảnh hệ thống bên ngoài, thì hệ thống đó 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 một hệ thống bên ngoài để cung cấp tính năng, xin lưu ý rằng phương pháp này yêu cầu bạn phải cẩn thận.

Vấn đề chính của các mô hình bao hàm và mô hình sâu là những mô hình này không giao nhau. Do đó, không có gì đảm bảo rằng có thể ước tính hoặc tìm ra giải pháp tối ưu và giải pháp tối thiểu cho từng vòng lặp có thể khác nhau. Biến thể này khiến bạn khó có thể đánh giá mức độ tác động của một thay đổi đối với hệ thống là ngẫu nhiên hay có ý nghĩa ngẫu nhiên. Bằng cách tạo mô hình không có các tính năng chuyên sâu, bạn có thể đạt được hiệu suất cơ bản 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 #18: Khám phá bằng các tính năng của nội dung khái quát hoá theo bối cảnh.

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

Quy tắc #19: Sử dụng các tính năng rất cụ thể khi bạn 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 sẽ dễ dàng hơn so với một số tính năng phức tạp. Giá trị nhận dạng của các tài liệu được truy xuất và truy vấn chuẩn hóa không cung cấp tính khái quát cao, nhưng bạn thống nhất thứ hạng của mình với nhãn trên truy vấn đầu. Vì vậy, đừng ngại sử dụng các nhóm tính năng mà mỗi tính năng áp dụng cho một phần rất nhỏ dữ liệu, nhưng mức độ bao phủ tổng thể sẽ trên 90%. Bạn có thể sử dụng quy trình thông thường để loại bỏ những 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 các tính năng mới theo cách dễ hiểu.

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

Sự khác biệt 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 từ tính năng đó. Hãy cân nhắc việc sử dụng một tính năng liên tục như độ tuổi. Bạn có thể tạo một tính năng gồm 1 khi độ tuổi dưới 18, một tính năng khác là 1 khi độ tuổi từ 18 đến 35, v.v. Đừng nghĩ quá xa về ranh giới của những biểu đồ này: các số liệu cơ bản sẽ cung cấp cho bạn hầu hết tác động.

Kiểu chữ thập kết hợp hai hoặc nhiều cột tính năng. Một cột tính năng, trong thuật ngữ của TensorFlow, là một tập hợp các tính năng đồng nhất, (ví dụ: {male, female}, {US, Canada, Mexico}, et cetera). Cross là một cột tính năng mới với các đối tượng có trong, ví dụ: {male,female} × {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à bạn yêu cầu TensorFlow tạo chữ thập này cho bạn, thì tính năng này (nam, Canada) sẽ xuất hiện trong các ví dụ tượng trưng cho người nam giới ở Canada. Xin lưu ý rằng cần đến một lượng lớn dữ liệu để tìm hiểu mô hình kết hợp với nhau từ 3, 4 cột trở lên.

Hình chữ thập tạo ra các cột có kích thước rất lớn có thể làm quá tải. 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 với các từ trong truy vấn và bạn có một cột tính năng có các từ trong tài liệu. Bạn có thể kết hợp các thuộc tính này với dấu gạch chéo, nhưng cuối cùng bạn sẽ có rất nhiều tính năng (xem Quy tắc #21).

Khi làm việc với văn bản, có hai lựa chọn thay thế. Kịch tính nhất là sản phẩm có dấu chấm. Một sản phẩm dấu chấm ở dạng đơn giản nhất chỉ đơn giản là tính số lượng từ chung giữa truy vấn và tài liệu. Sau đó, tính năng này có thể được tách biệt. Một cách tiếp cận khác là giao thức: do đó, chúng ta sẽ có một tính năng hiển thị nếu và chỉ khi từ "pony" có trong cả tài liệu và truy vấn, và một tính năng khác xuất hiện nếu 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 đối tượng mà bạn có thể tìm hiểu trong mô hình tuyến tính tương ứng với lượng dữ liệu bạn có.

Có nhiều kết quả lý thuyết học tập thống kê thú vị liên quan đến mức độ phức tạp thích hợp của 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 đã có những cuộc trò chuyện mà mọi người nghi ngờ rằng bất kỳ điều gì cũng có thể học được từ một nghìn ví dụ, hoặc rằng các bạn sẽ cần hơn một triệu ví dụ, vì họ bị kẹt trong một phương pháp học tập nhất định. Điều quan trọng là bạn phải mở rộng quy mô học tập theo quy mô dữ liệu của mình:

  1. Nếu bạn đang làm việc trên hệ thống xếp hạng tìm kiếm và có hàng triệu từ trong tài liệu cũng như truy vấn và bạn có 1000 ví dụ được gắn nhãn, thì bạn nên sử dụng một sản phẩm dấu chấm giữa các tính năng tài liệu và truy vấn, TF-IDF, và một nửa các tính năng khác do con người tạo ra. 1000 ví dụ, hàng chục tính năng.
  2. Nếu bạn có một triệu ví dụ, hãy kết hợp các cột tài liệu và truy vấn bằng cách sử dụng quy trình thông thường 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 với tính năng thường xuyên, 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à truy vấn, sử dụng tính năng lựa chọn tính năng và quy trình hoá. Bạn sẽ có một tỷ tỷ ví dụ và 10 triệu tính năng. Lý thuyết học tập thống kê hiếm khi đưa ra giới hạn chặt chẽ, nhưng đưa ra hướng dẫn tuyệt vời cho một điểm xuất phát.

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

Quy tắc #22: Dọn dẹp 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 nợ kỹ thuật. Nếu bạn thấy rằng mình không sử dụng một tính năng nào đó 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, thì bạn hãy bỏ tính năng đó ra khỏi cơ sở hạ tầng. Bạn muốn giữ cho cơ sở hạ tầng của mình gọn gàng để các tính năng hứa hẹn nhất có thể được thử nhanh nhất có thể. Nếu cần, người nào đó luôn có thể thêm lại tính năng của bạn.

Lưu ý 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ó 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ó tính năng cá nhân hoá, thì tính năng đó sẽ không hiệu quả lắm.

Đồ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 dương, thì đó sẽ là một tính năng tuyệt vời để thêm.

Phân tích con người về hệ thống

Trước khi chuyển sang giai đoạn thứ ba của công nghệ máy học, bạn cần tập trung vào một nội dung không được dạy trong bất kỳ lớp máy học nào: cách xem xét một mô hình hiện có và cách cải thiện mô hình đó. Đây không phải là một môn nghệ thuật nhiều mà là một ngành khoa học. Tuy nhiên, vẫn có một số mẫu chống lại nó mà bạn nên 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 gặp khó khăn. Mặc dù việc nuôi thử cá (sử dụng nguyên mẫu trong nhóm) mang lại rất nhiều lợi ích và thử nghiệm nội bộ (sử dụng nguyên mẫu trong công ty của bạn), nhưng nhân viên cũng nên xem xét xem hiệu suất có chính xác hay không. Mặc dù không nên sử dụng thay đổi rõ ràng là xấu, nhưng bạn nên kiểm thử thêm mọi thứ có vẻ hợp lý gần quá trình sản xuất, bằng cách trả tiền cho người không có chuyên môn để trả lời câu hỏi trên nền tảng đám mây hoặc thông qua một thử nghiệm trực tiếp với người dùng thực.

Có hai lý do. Lý do đầu tiên là bạn quá gần với mã. Bạn có thể đang tìm kiếm một khía cạnh cụ thể trong bài đăng hoặc đơn giản là bạn quá quan tâm đến cảm xúc (ví dụ: thành kiến xác nhận). Lý do thứ hai là thời gian của bạn quá quý giá. Hãy cân nhắc chi phí của 9 kỹ sư trong một cuộc họp kéo dài 1 giờ và nghĩ đến số lượng nhãn người mua theo hợp đồng mua trên nền tảng đám đông.

Nếu bạn thực sự muốn nhận được phản hồi của người dùng, hãy sử dụng phương pháp trải nghiệm người dùng. Tạo cá tính người dùng (một mô tả nằm trong Trải nghiệm người dùng phác thảo của Bill Buxton) trong quá trình thực hiện và thử nghiệm khả năng hữu dụng (một mô tả nằm trong Don't Make Me Think) của Steve Krug. Cá tính người dùng liên quan đến việc tạo người dùng giả định. Ví dụ: nếu nhóm của bạn đều là nam, việc này có thể giúp thiết kế một cá tính người dùng là nữ 35 tuổi (hoàn chỉnh với các tính năng người dùng) và xem kết quả mà công cụ này tạo ra thay vì 10 kết quả cho nam giới từ 25 đến 40 tuổi. Việc đưa những người thực tế đến để xem phản ứng của họ với trang web của bạn (tại địa phương hoặc từ xa) trong thử nghiệm về khả năng hữu dụng cũng có thể giúp bạn có cái nhìn mới mẻ.

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 là tính toán kết quả mới khác với kết quả thực tế ra sao. Ví dụ: nếu bạn gặp vấn đề về xếp 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 quy mô chênh lệch giữa các kết quả (có trọng số theo vị trí xếp hạng). Nếu sự khác biệt rất nhỏ, thì bạn có thể biết mà không cần chạy thử nghiệm rằng sẽ có một chút thay đổi. Nếu có sự khác biệt rất lớn, thì bạn cần đảm bảo rằng sự thay đổi đó tốt. Khi xem qua các truy vấn có mức chênh lệch cao, bạn có thể hiểu rõ hơn về sự thay đổi đó. Tuy nhiên, hãy đảm bảo rằng hệ thống ổn định. Đảm bảo rằng một mô hình khi so sánh với chính nó có mức chênh lệch đối xứng thấp (tốt nhất là 0).

Quy tắc #25: Khi chọn mô hình, hiệu suất thiết thực sẽ ưu tiê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, câu hỏi quan trọng là bạn sẽ làm gì với cụm từ gợi ý đó. Nếu bạn đang dùng hệ thống xếp hạng này để xếp hạng các tài liệu, thì chất lượng của thứ hạng cuối cùng sẽ đóng vai trò quan trọng hơn so với dự đoán. Nếu bạn dự đoán xác suất một tài liệu là thư rác và sau đó có giới hạn về nội dung bị chặn, thì độ chính xác của nội dung được phép thông qua việc quan trọng hơn. Trong hầu hết các trường hợp, bạn cần thống nhất hai điều sau đây: khi không đồng ý, có thể lợi ích sẽ 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.

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

Giả sử bạn thấy một ví dụ huấn luyện cho thấy mô hình có trạng thái "sai". Trong tác vụ phân loại, lỗi này có thể là dương tính giả (false positive) hoặc âm tính giả (false negative). Trong nhiệm vụ xếp hạng, lỗi có thể là một cặp trong đó kết quả tích cực được xếp hạng thấp hơn giá trị âm. Điều quan trọng nhất là đây là một ví dụ mà hệ thống máy học biết rằng hệ thống đã nhầm lẫn và muốn khắc phục nếu đưa ra 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 nhận thấy là lỗi, thì tính năng đó sẽ bị bỏ qua. Ví dụ: giả sử trong Tìm kiếm ứng dụng của Play, người nào đó tìm kiếm "trò chơi miễn phí". Giả sử một trong những kết quả hàng đầu là ứ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 hóa số lượt cài đặt và mọi người cài đặt một ứng dụng gag khi họ 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 ứng mà bạn muốn.

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

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

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

Hãy tưởng tượng rằng bạn có một hệ thống mới xem xét mọi doc_id và Exact_query, sau đó tính xác suất nhấp chuột cho mọi tài liệu cho mọi truy vấn. Bạn nhận thấy rằng hành vi của hệ thống này gần giống với hệ thống hiện tại ở cả bên cạnh và thử nghiệm A/B. Vì vậy, bạn nên khởi chạy tính năng này một cách đơn giản. Tuy nhiên, bạn nhận thấy rằng không có ứng dụng mới nào được hiển thị. Bạn nên làm vậy Vâng, vì hệ thống của bạn chỉ hiển thị một tài liệu dựa trên lịch sử của riêng nó với truy vấn đó, nên không có cách nào để tìm hiểu rằng một tài liệu mới sẽ được hiển thị.

Cách duy nhất để hiểu cách một hệ thống hoạt động như vậy trong thời gian dài là chỉ đào tạo về dữ liệu có được khi mô hình đang hoạt động. Điều này rất khó khăn.

Xương phục vụ đào tạo

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

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

Chúng tôi quan sát thấy rằng các hệ thống máy học của Google sản xuất bằng phương pháp huấn luyện – phân phát sai lệch 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 làm sai lệch ứng dụng.

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

Ngay cả khi bạn không thể làm việc này cho mọi ví dụ, hãy thực hiện việc này cho 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à đào tạo (xem Quy tắc #37). Các nhóm tiến hành đo lường này tại Google đôi khi ngạc nhiên về 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 điểm 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 đang chuyển đổi cơ sở hạ tầng khi chúng tôi nói.

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

Khi có quá nhiều dữ liệu, bạn sẽ muốn lấy tệp 1-12 và bỏ qua 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ị bỏ qua, nhưng trọng số quan trọng là tốt nhất cho phần còn lại. Tính trọng số tầm quan trọng có nghĩa là nếu bạn quyết định lấy mẫu ví dụ X với xác suất là 30%, thì hãy cho trọng số là 10/3. Với trọng số quan trọng, tất cả các thuộc tính hiệu chỉnh được thảo luận trong Quy tắc #14 vẫn giữ nguyên.

Quy tắc #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 điểm đào tạo và phân phát, thì dữ liệu trong bảng có thể thay đổi.

Giả sử bạn tham gia mã tài liệu bằng một bảng chứa các tính năng cho những tài liệu đó (chẳng hạn như số lượng nhận xét hoặc lượt nhấp). Giữa thời gian huấn luyện và phân phát, các tính năng trong bảng có thể thay đổi. Sau đó, dự đoán mô hình của bạn 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 nhật ký các tính năng tại thời điểm phân phát (xem Quy tắc #32). Nếu bảng chỉ thay đổi chậm, bạn cũng có thể chụp nhanh bảng theo giờ hoặc hằng ngày để nhận được dữ liệu đóng hợp lý. Xin lưu ý rằng việc 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 mã giữa quy trình đào tạo 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. Trong quá trình xử lý trực tuyến, bạn phải xử lý từng yêu cầu khi nó đến (ví dụ: bạn phải tra cứu riêng cho từng truy vấn), trong khi trong quá trình xử lý hàng loạt, bạn có thể kết hợp các nhiệm vụ (ví dụ: tạo một liên kết). Tại thời điểm phân phát, bạn đang xử lý trực tuyến, trong khi đào tạo là một tác vụ xử lý hàng loạt. Tuy nhiên, có một số việc mà 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 cụ thể 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ác lỗi có thể được kiểm tra dễ dàng. Sau khi thu thập tất cả thông tin, trong quá trình phân phát hoặc đào tạo, bạn chạy một phương thức phổ biến để kết nối giữa đối tượng có thể đọc được dành riêng cho hệ thống và bất kỳ định dạng nào mà hệ thống máy học mong đợi. Điều này loại bỏ nguồn của các sai lệch trong việc đào tạo. Vì không phải là hệ thống, nên cố gắng không sử dụng hai ngôn ngữ lập trình khác nhau giữa hoạt động đào tạo và phân phát. Quyết định đó sẽ gần như không thể giúp bạn 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 tra mô hình dựa trên dữ liệu từ ngày 6 tháng 1 trở đi.

Nhìn chung, hãy đo lường hiệu suất của một mô hình dựa trên dữ liệu được thu thập sau khi dữ liệu bạn đã huấn luyện mô hình, vì dữ liệu này phản ánh chính xác hơn những việc hệ thống của bạn sẽ làm trong quá trình sản xuất. 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 thử nghiệm mô hình đó trên dữ liệu từ ngày 6 tháng 1. Bạn mong đợi rằng hiệu suất sẽ không tốt trên dữ liệu mới, nhưng không được hoàn toàn tệ hơn. Vì có thể có những tác động hằng ngày, nên bạn có thể không dự đoán được tỷ lệ nhấp hoặc tỷ lệ chuyển đổi trung bình. Tuy nhiên, khu vực bên dưới đường cong thể hiện khả năng cho điểm dương cao hơn ví dụ phủ định.

Quy tắc #34: Trong việc 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 cho dữ liệu rất rõ ràng.

Trong một tác vụ lọc, những ví dụ được đánh dấu là âm không hiển thị cho người dùng. Giả sử bạn có một bộ lọc chặn 75% các ví dụ phủ định khi phân phát. Bạn có thể rất muốn lấy dữ liệu đào tạo bổ sung từ các phiên bản 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, thì bạn nên tìm hiểu từ email đó.

Tuy nhiên, phương pháp này cũng có xu hướng lấy mẫu. Bạn có thể thu thập dữ liệu rõ ràng hơn nếu trong quá trình phân phát, bạn gắn nhãn 1% tất cả lưu lượng truy cập là "bị giữ lại" và gửi tất cả ví dụ riêng cho người dùng. Bộ lọc của bạn hiện đang chặn ít nhất 74% ví dụ phủ định. Những ví dụ bị 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% các 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%). Mười nghìn ví dụ là đủ để ước tính hiệu suất khá chính xác.

Quy tắc #35: Cảnh giác với sự chênh lệch vốn có trong các vấn đề về xếp hạng.

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

  1. Thường xuyên cập nhật 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 này sẽ ưu tiên các tính năng dành riêng cho một hoặc một vài truy vấn so với các tính năng khái quát đối với tất cả truy vấn. 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. Xin 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 thường xuyên cập nhật 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 đó, bất kỳ tính năng tốt nào cũng 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 số 1. Ví dụ: ngay cả khi một ứng dụng nhất định là tệp tải xuống phổ biến bất kể truy vấn là gì, bạn không muốn hiển thị ứ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ẽ giúp việc đó trở nê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 tạo tất cả ứng dụng mong muốn. Ví dụ: nếu ai đó tìm kiếm "ứng dụng xem chim", họ có thể tải xuống "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 hiển thị một ứng dụng như vậy có thể cải thiện tỷ lệ tải xuống, nhưng cuối cùng vẫn khiến nhu cầu của người dùng không được đáp ứ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í nội dung ảnh hưởng đáng kể đến khả năng người dùng tương tác với nội dung đó. Nếu bạn đặt một ứng dụng ở vị trí đầu tiên, thì ứng dụng đó sẽ được nhấp vào 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 hơn. Có một cách để xử lý là thêm các tính năng về vị trí, tức là thêm các tính năng về vị trí của nội dung trên trang. Bạn đào tạo mô hình của mình bằng các tính năng vị trí và mô hình này sẽ học trọng số, chẳng hạn như tính năng "1stposition" rất quan trọng. Mô hình của bạn ít quan trọng hơn các yếu tố khác, chẳng hạn như "1stposition=true". Sau đó, khi phân phát, bạn không cung cấp bất kỳ bản sao vị trí nào hoặc cung cấp cho người dùng tất cả tính năng mặc định như vậy vì bạn đang cho điểm ứng viên trước khi quyết định thứ tự hiển thị.

Lưu ý rằng cần giữ cho các tính năng vị trí tách biệt với phần còn lại của mô hình vì sự bất cân xứng giữa việc huấn luyện và kiểm thử. Mô hình là tổng của các tính năng vị trí và một hàm của các tính năng còn lại là lý tưởng. Ví dụ: không kết hợp các tính năng vị trí với bất kỳ tính năng tài liệu nào.

Quy tắc #37: Đo lường mức độ huấn luyện/phân phát.

Có một số nguyên nhân có thể gây ra sai lệch theo cách khái quát nhất. 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 giữ lại. Nói chung, việc này sẽ luôn tồn tại và không phải lúc nào cũng xấu.
  • Sự khác biệt giữa hiệu suất trên dữ liệu giữ lại và dữ liệu "ngày tiếp theo". Xin nhắc lại, chiến dịch này sẽ luôn tồn tại. Bạn nên điều chỉnh mức độ thường xuyên để tối đa hóa hiệu suất vào ngày tiếp theo. Tuy nhiên, hiệu suất giảm mạnh giữa dữ liệu giữ lại và dữ liệu ngày tiếp theo có thể cho biết rằng 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 trên 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 đào tạo 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ả chính xác (xem Quy tắc #5 ). Do đó, sự khác biệt ở đây có thể cho thấy lỗi kỹ thuật.

Giai đoạn máy học III: Phát triển chậm, tinh chỉnh hoạt động tối ưu hóa và các mô hình phức tạp

Sẽ có một số chỉ báo nhất định cho biết giai đoạn thứ hai sắp kết thúc. Trước hết, mức tăng hằng tháng của bạn sẽ bắt đầu giảm. Bạn sẽ bắt đầu có sự đánh đổi giữa các chỉ số: bạn sẽ thấy một số mức tăng và một số khác rơi vào một số thử nghiệm. Đây là nội dung thú vị. Vì việc đạt được thành công đã khó khăn hơn, nên công nghệ máy học phải phức tạp hơn. Lưu ý: phần này có nhiều quy tắc bầu trời xanh hơn so với các phần trước. Chúng tôi đã thấy nhiều đội ngũ trải qua giai đoạn hạnh phúc của công nghệ máy học Giai đoạn I và Giai đoạn II. Sau khi đến Giai đoạn III, các nhóm phải tìm lộ trình 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 phù hợp đã trở thành vấn đề.

Khi tính toán đo lường cao hơn, 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 máy học hiện tại. Như đã nêu trước đó, nếu mục tiêu sản phẩm không được bao gồm bởi 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 của mình. Ví dụ: bạn có thể tối ưu hóa nhấp chuột, cộng một hoặc tải xuống, nhưng đưa ra quyết định khởi chạy dựa trên một phần của người đánh giá.

Quy tắc #39: Quyết định ra mắt là proxy cho các mục tiêu sản phẩm dài hạn.

Alice có ý tưởng giảm mức độ mất mát hậu quả của việc dự đoán số lượt cài đặt. Cô ấy thêm một tính năng. Tỷ lệ mất mát hậu cần sụt giảm. Khi tiến hành thử nghiệm trực tiếp, cô thấy tỷ lệ cài đặt tăng lên. Tuy nhiên, khi cô tham gia một cuộc họp đánh giá việc khởi chạy, ai đó chỉ ra rằng số 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. Alice thất vọng, nhưng giờ đây nhận ra rằng các quyết định khởi chạy phụ thuộc vào nhiều tiêu chí, chỉ một số tiêu chí có thể được tối ưu hóa trực tiếp bằng công nghệ máy học.

Sự thật là thế giới thực không phải là ngục tối và rồng: không có "điểm truy cập" nào xác định tình trạng của sản phẩm. Nhóm phải sử dụng số liệu thống kê thu thập được để cố gắng dự đoán một cách hiệu quả hệ thống sẽ có hiệu quả như thế nào 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 các chỉ số này có thể đo lường được trong thử nghiệm A/B chỉ là proxy cho các mục tiêu dài hạn hơn: làm hài lòng người dùng, tăng số người dùng, làm hài lòng đối tác và lợi nhuận. Từ đó, bạn có thể cân nhắc các proxy để sở hữu một sản phẩm hữu ích, chất lượng cao và công ty phát triển mạnh mẽ từ 5 năm trở lại đây.

Quyết định khởi chạy 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 là không tệ hơn). Nếu nhóm có lựa chọn giữa thuật toán máy học tinh vi và phỏng đoán đơn giản, nếu phương pháp phỏng đoán đơn giản hoạt động hiệu quả hơn với tất cả các chỉ số này, thì nhóm nên chọn phỏng đoán. Hơn nữa, không có thứ hạng rõ ràng nào cho tất cả giá trị chỉ số có thể có. Cụ thể, hãy xem xét hai 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 đô la
B 2 triệu 2 triệu đô la

Nếu hệ thống hiện tại là A, thì nhóm sẽ không có khả năng chuyển sang B. Nếu hệ thống hiện tại là B, thì nhóm có khả năng sẽ không chuyển sang A. Điều này có vẻ xung đột 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ể có hoặc có thể không xảy ra, do đó, có một rủi ro lớn liên quan đến một trong hai thay đổi này. Mỗi chỉ số bao gồm một số rủi ro liên quan đến nhóm.

Hơn nữa, không có chỉ số nào thể hiện mối quan tâm hàng đầu của nhóm, "sản phẩm của tôi sẽ tồn tại ở đâu trong 5 năm tới"?

Mặt khác, các cá nhân lại có xu hướng ủng hộ một mục tiêu mà họ có thể tối ưu hóa trực tiếp. Hầu hết các công cụ máy học đều thích môi trường như vậy. Một kỹ sư tạo ra các tính năng mới có thể nhận được luồng khởi chạy ổn định trong môi trường như vậy. Có một loại máy học, học nhiều đối tượng, bắt đầu 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 hạn chế về mức độ hài lòng có giới hạn thấp hơn trên mỗi chỉ số, và tối ưu hoá một số tổ hợp tuyến tính của chỉ số. Tuy nhiên, không phải tất cả các chỉ số đều dễ dàng được đóng khung dưới dạng mục tiêu máy học: nếu người dùng nhấp vào tài liệu hoặc cài đặt một ứng dụng, thì đó là do nội dung đã hiển thị. Tuy nhiên, việc tìm ra lý do người dùng truy cập vào trang web của bạn lại khó khăn hơn rất nhiều. Cách dự đoán thành công trong tương lai của một trang web nói chung là hoàn chỉnh bằng AI: khó theo dõi thị giác máy tính hoặc xử lý ngôn ngữ tự nhiên.

Quy tắc #40: Đảm bảo các chi tiết đơn giản.

Các mô hình hợp nhất có các tính năng thô và xếp hạng trực tiếp nội dung là các mô hình dễ nhất để gỡ lỗi và hiểu. Tuy nhiên, nhóm mô hình (một "mô hình" kết hợp với đ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ỉ lấy dữ liệu đầu vào của các mô hình khác, hoặc là một mô hình cơ sở nhận 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 đào tạo 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 và chỉ lấy kết quả của các mô hình "cơ sở" làm đầu vào. Bạn cũng muốn thực thi thuộc tính trên các mô hình kết hợp này. Ví dụ: sự gia tăng điểm số do mô hình cơ sở tạo ra sẽ không làm giảm điểm của nhóm. Ngoài ra, tốt nhất là các mô hình đến nên có thể diễn giải theo ngữ nghĩa (ví dụ: đã được hiệu chỉnh) để các thay đổi của mô hình cơ sở không gây nhầm lẫn cho mô hình tổ hợp. Ngoài ra, 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 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 cao, hãy tìm nguồn thông tin mới về chất lượng để thêm 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 đã thực hiện khám phá mẫu và điều chỉnh thường xuyên. Bạn không thấy sự kiện ra mắt có chỉ số cải thiện hơn 1% trong một vài quý. Sau đó thì sao?

Đã đến lúc bắt đầu xây dựng cơ sở hạ tầng cho những tính năng hoàn toàn khác, chẳng hạn như lịch sử tài liệu mà người dùng này đã truy cập trong ngày, tuần 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 đó nội bộ cho 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 của bạn về lợi tức đầu tư và mở rộng nỗ lực cho phù hợp. Như trong mọi dự án kỹ thuật khác, 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 để chống lại chi phí phức tạp hơn.

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

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

Vấn đề là những điều thông thường thường khó bị đánh bại.

Lưu ý rằng nếu hệ thống của bạn đang đo lường số lượt nhấp, thời gian dành cho đồng hồ, số lượt +1, số lượt chia sẻ lại, v.v., tức là bạn đang đo lường mức độ phổ biến của nội dung. Đôi khi, các nhóm muốn học hỏi mô hình cá nhân về 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 tài liệu này có bất kỳ đặc điểm chung nào với các tài liệu khác được trả về không, chẳng hạn như tác giả hoặc nội dung) và nhận thấy rằng 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 mong đợi.

Điều này không có nghĩa là tính đa dạng, cá nhân hóa hoặc mức độ liên quan không có giá trị. Như đã chỉ ra trong quy tắc trước đó, bạn có thể xử lý hậu kỳ để tăng tính đa dạng hoặc mức độ liên quan. Nếu bạn thấy 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 cách xử lý hậu kỳ hoặc sửa đổi trực tiếp đối tượng dựa trên sự đa dạng hoặc mức độ liên quan.

Quy tắc #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 giống nhau.

Các nhóm tại Google đã nhận được rất nhiều sức hút từ việc áp dụng mô hình dự đoán mức độ gần của kết nối trong một sản phẩm và công cụ này hoạt động hiệu quả trên một sản phẩm khác. Bạn bè của bạn là những người đó. Mặt khác, tôi đã xem một số nhóm đấu tranh với các tính năng cá nhân hóa trên các phân chia sản phẩm. Có vẻ như cách này có thể hiệu quả. Hiện tại, có vẻ như vậy chưa có. Đôi khi, hiệu quả hoạt độ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, xin lưu ý rằng ngay cả khi biết rằng người dùng có lịch sử trên một thuộc tính khác, thì việc biết được điều này sẽ có thể hữu ích. Ví dụ: sự hiện diện của hoạt động người dùng trên hai sản phẩm có thể cho biết rằng nội dung đó tự nó xuất hiện.

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

Xác nhận

Cảm ơn David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tullhar Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Katsiapis, Glen Steinu, Just Ducki Ngoài ra, nhờ có Kristen Lefevre, Suddha Basu và Chris Berg đã giúp chúng tôi chuẩn bị cho phiên bản cũ. Bất kỳ lỗi, thiếu sót hoặc (tìm hiểu!) ý kiến không phổ biến nào là của tôi.

Phụ lục

Có nhiều nội dung tham chiếu đến 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 cung cấp một đoạn mô tả ngắn về các ví dụ phổ biến nhất bên dưới.

Tổng quan về YouTube

YouTube là một dịch vụ video trực tuyến. Cả nhóm YouTube Watch Next và YouTube Home đều sử dụng mô hình ML để xếp hạng các đề xuất video. Watch Next đề xuất video để xem sau khi video đang phát, còn 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 nhiều vấn đề. Các ứng dụng trên Play Tìm kiếm, Play Đề xuất được cá nhân hóa và "Người dùng cũng đã cài đặt" đều sử dụng máy học.

Tổng quan về Google+

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