Cách chạy nhiều thử nghiệm cùng một lúc bằng cách sử dụng Nhóm điều khiển thích ứng

Thử nghiệm A/B đang chết dần và tôi ở đây vì điều đó. Việc đánh giá rời rạc, có giới hạn thời gian đối với một nhóm nhỏ các biện pháp can thiệp (đôi khi chỉ một biện pháp can thiệp) không nhất quán mang lại kết quả khả thi lâu dài.

• Có quá nhiều thứ bạn có thể thử nghiệm. Trong mọi tình huống kinh doanh trong thế giới thực, số lượng thứ cần thử nghiệm sẽ tăng lên rất nhanh — nếu bạn đang sử dụng khung thử nghiệm A/B. Sự choáng ngợp là một hạn chế của phương pháp thử nghiệm, không phải là một tính năng của môi trường thử nghiệm.

  
  

• Có thể mất nhiều thời gian để chạy thử nghiệm và thời gian dài, rất lâu để chạy nhiều thử nghiệm . Bạn phải cẩn thận để các thử nghiệm khác nhau không trùng lặp với những người dùng mà chúng tác động. Bạn phải tránh những ngày và địa điểm mà doanh nghiệp không sẵn sàng tham gia thử nghiệm. Nó độc quyền rất nhiều tài nguyên để chạy thử nghiệm A/B.

  
  

• Thử nghiệm có khả năng ảnh hưởng rất nhiều đến biến thể thua cuộc — nếu bạn chạy A so với B trong một tháng và thấy rằng A hoạt động tốt hơn rất nhiều, điều đó có nghĩa là bạn đã cho một nửa số người dùng của mình xem biến thể có hiệu suất thấp trong cả tháng. Bạn đã mất tất cả giá trị đó. Không ai hài lòng về điều đó.

  
  

• Hiệu quả lâu dài của một bài kiểm tra là không bao giờ chắc chắn. Tác động của bất kỳ lựa chọn nào bạn đưa ra có thể bị ảnh hưởng bởi thời gian trong ngày, ngày trong tuần, thời gian trong tháng, thời gian trong năm, các sự kiện thế giới, những thay đổi trên thị trường — chỉ vì A tốt hơn B trong tháng mà bạn đã thử nghiệm nó, không có nghĩa là nó sẽ luôn tốt hơn. Và không có thử nghiệm A/B nào có thể cho bạn biết thời hạn sử dụng của kết quả.

Nếu bạn muốn thảo luận sâu hơn một chút về các vấn đề với thử nghiệm A/B, những người ở [Babbel](https://Chạy nhiều thử nghiệm cùng lúc bằng cách sử dụng nhóm kiểm soát thích ứng) sẽ có một bài thuyết trình hay về chủ đề này và hướng dẫn về phản hồi của kẻ cướp này là một quan điểm tuyệt vời từ một số nhà lãnh đạo ngành.

Những tên cướp nhiều vũ trang là tương lai, và tương lai là bây giờ, và bây giờ chúng ta có những vấn đề mới.

Trong cài đặt thử nghiệm A/B truyền thống, bạn có biến thể A và biến thể B. Trong hầu hết các tình huống thực tế, A hoặc B chỉ “tốt hơn” theo nghĩa thống kê.

Nếu bạn chạy thử nghiệm và A nhận được tỷ lệ thành công 20% và B nhận được tỷ lệ thành công 10%, A rõ ràng là “thắng”… nhưng còn những người đã phản hồi với B thì sao? Họ sẽ ổn với việc đạt được điểm A chứ? Cả thử nghiệm A/B và thuật toán kẻ cướp đều buộc bạn phải hy sinh sở thích thiểu số của mình vì lợi ích của đa số. Không nhất thiết phải như vậy - đó chỉ là cách hoạt động của những công cụ cụ thể đó. Một chiến lược tốt hơn là cung cấp tùy chọn A cho những người thích tùy chọn A và tùy chọn B cho những người phản hồi tùy chọn B. Vì vậy:

• Gửi tùy chọn A cho 100 người và tùy chọn B cho 100 người.
• Tỷ lệ thành công 20% của tùy chọn A có nghĩa là bạn có 20 lần thành công.
• Tỷ lệ thành công 10% của tùy chọn B có nghĩa là bạn đã thành công 10 lần.

Hãy rộng lượng và giả sử rằng một nửa số người đã trả lời tùy chọn B thực sự sẽ trả lời tùy chọn A nếu thay vào đó họ thấy điều đó.

Điều đó có nghĩa là:

• Chỉ hiển thị tùy chọn A sau khi kiểm tra xong mang lại tỷ lệ thành công 12,5% (20 người đã trả lời A, cộng với 5 người đã trả lời B nhưng lẽ ra sẽ trả lời A, chia cho tổng số 200 người ở cả hai nhóm).
• Gửi tùy chọn A cho những người muốn A và B cho những người muốn B mang lại tỷ lệ thành công 15%.

Vì vậy, bằng cách điều chỉnh cách bạn triển khai từng phương pháp điều trị dựa trên kết quả dựa trên cơ sở, bạn sẽ để lại ít giá trị hơn trên bàn. Đó là tất cả những gì một thuật toán kẻ cướp thực hiện — nó đặt cược phòng hộ: B thành công bằng một nửa so với A, vì vậy bạn thực sự chỉ cho B một nửa thời gian. Bạn có thể làm điều này với nhiều tùy chọn khác nhau cùng lúc (không chỉ A và B), việc triển khai và điều chỉnh tự động giúp việc chạy thử nghiệm ít tốn kém hơn, bạn không phải hy sinh nhiều giá trị để mất các biến thể và hệ thống có thể điều chỉnh theo những thay đổi trong sở thích của người dùng hoặc môi trường quyết định lớn hơn.

Tất cả các vấn đề về thử nghiệm A/B đã được giải quyết!

Nhưng điều này có thể phản tác dụng.

Tần suất bạn sẽ hiển thị B cho những người thích A hoặc hiển thị A cho những người thích B, bởi vì bạn đang đưa ra quyết định dựa trên số liệu thống kê tổng hợp thay vì tùy chọn cá nhân? Thuật toán kẻ cướp thực sự có thể hoạt động kém hơn thử nghiệm A/B trong các loại tình huống này. Và, tất nhiên, tất cả những điều này có thể thay đổi theo thời gian. Có thể một nửa số người thích B thực sự thay đổi theo thời gian để thích A hơn. Và một phần tư số người thích A thay đổi theo thời gian để thích B. Số liệu thống kê tổng hợp của bạn và do đó, quyết định bạn sẽ đưa ra về nội dung sẽ hiển thị cho ai , sẽ vẫn giống hệt nhau. Đó không phải là tối ưu.

Các thuật toán kẻ cướp thông thường mang theo chi phí ẩn — hay nói đúng hơn là chúng lấy chi phí của các thử nghiệm A/B và xáo trộn nó ở những nơi khác nhau để bạn không dễ dàng nhận thấy. Bạn thiết lập thuật toán của mình và bắt đầu gửi và mọi thứ đều ổn…cho đến khi bạn bắt đầu nhận ra một số vấn đề mà tôi đã đề cập trong các đoạn trước. Có thể sự cân bằng giữa các tùy chọn dành cho A so với B là khác nhau đối với người dùng mới, chẳng hạn như đối với người dùng cũ. Có thể những sở thích đó là khác nhau đối với các khu vực địa lý khác nhau. Ngay cả những người dùng có kinh nghiệm cũng có thể được chia thành những người dùng thành thạo và những người chỉ là người bình thường. Đây là lý do tại sao mọi người đã phát minh rakẻ cướp theo ngữ cảnh , đây thực sự chỉ là một từ hoa mỹ cho kẻ cướp cộng với phân đoạn.

Giờ đây, bạn phải thực hiện nhiều báo cáo hơn để hiểu phân khúc nào trong cơ sở người dùng của mình có thể có các cấu hình tùy chọn khác nhau. Vì vậy, bạn đã giảm nhu cầu báo cáo để phân tích các thử nghiệm, nhưng lại tăng nhu cầu báo cáo để xác định phạm vi kẻ cướp của mình. Và bạn đã tăng số lượng công việc cần thiết để biến báo cáo đó thành phạm vi thực tế. Và khi bạn có các phân khúc khác nhau này, bạn nhận ra rằng có thể bạn cần nhiều quảng cáo hơn để tính đến bối cảnh đó, vì vậy sẽ có nhiều việc hơn. Và sau đó là công việc kỹ thuật để xây dựng các quy trình đưa đúng người dùng vào đúng kẻ cướp. Và có công việc bạn cần làm trong hệ thống nhắn tin của mình để đảm bảo rằng nó hỗ trợ tất cả những thứ này đang diễn ra trong nền.

Vì vậy, những tên cướp giải quyết được rất nhiều vấn đề của thử nghiệm A/B, nhưng những tên cướp thực sự hiệu quả lại tạo ra nhu cầu phân tích mới và những rào cản hậu cần mới không dễ giải quyết. Đó là một trong những lý do khiến thử nghiệm A/B vẫn rất phổ biến: quy trình này đủ phổ biến để có rất nhiều công cụ hỗ trợ thực hiện công việc nặng nhọc này.

Kiểm thử động yêu cầu đánh giá động, cần có nhóm kiểm soát động.

Vì vậy, tôi đã giúp thiết kế và xây dựng một sản phẩm giúp thử nghiệm kẻ cướp theo ngữ cảnh phức tạp trở nên dễ dàng — dễ dàng đến mức nó tạo ra một ngữ cảnh riêng biệt cho từng người dùng trên trang web hoặc ứng dụng của bạn. Bạn có thể tham khảo thêm thông tin chi tiết về sản phẩm đó tại đây , đó không thực sự là vấn đề của bài viết này nên tôi sẽ không nói thêm về nó nữa. Điều tôi muốn nói ở đây là cách chúng tôi giải quyết vấn đề đánh giá hàng trăm nghìn bài kiểm tra thích ứng cá nhân mỗi ngày.

Các chi tiết có thể được tìm thấy trong bài báo của chúng tôi về arXiv .

Trước đây tôi đã viết về những thách thức thực tế, phân tích và đôi khi thậm chí cả đạo đức vốn có trong việc xây dựng một nhóm nắm giữ để đánh giá các thử nghiệm. Tôi vẫn đứng về phía đó. Chúng tôi đánh giá các thử nghiệm thích ứng của mình bằng cách sử dụng biện pháp kiểm soát tổng hợp vì điều đó không liên quan đến việc tước bỏ các biện pháp can thiệp có khả năng mang lại lợi ích của bất kỳ người dùng nào. Tuy nhiên, các phương pháp kiểm soát tổng hợp truyền thống có thể chứa đầy những cạm bẫy trong phân tích, bởi vì về cơ bản, bạn đang lập mô hình quy trình tạo dữ liệu cơ sở cho môi trường mà bạn đang tiến hành thử nghiệm. Thực hiện rất nhiều thử nghiệm song song, nhiều thử nghiệm trong số đó diễn ra trong các môi trường chồng chéo và một giải pháp phân tích cho vấn đề kiểm soát trở nên… khó khăn.

Đó là lý do tại sao chúng tôi không đi theo con đường đó.

Gary King và các đồng nghiệp của ông tại Harvard, vài năm trước, đã nghĩ ra một phương pháp cực kỳ đơn giản để rút ra kết luận nhân quả từ dữ liệu quan sát. Nó được gọi là So khớp chính xác thô (CEM). Bạn có thể tìm thấy bài báo chuyên đề ở đây và nền tảng lý thuyết ở đây .

Ý tưởng rất đơn giản:

1. Thu thập tất cả các quan sát của bạn về sự can thiệp (thử nghiệm) đang diễn ra.
2. Thu thập một loạt các quan sát mà can thiệp không diễn ra nhưng có thể xảy ra.
3. Chọn các thuộc tính có thể đo lường sự giống nhau giữa bất kỳ cặp quan sát cụ thể nào từ hai nhóm.
4. Các thuộc tính “thô” thành các biến phân loại. Vì vậy, nếu "tuổi" là một thuộc tính, bạn có thể phân loại nó thành các loại tuổi.
5. Ghép từng quan sát can thiệp với quan sát không can thiệp dựa trên kết hợp chính xác các thuộc tính thô. Điều này có nghĩa là bạn sẽ chỉ chọn một tập hợp con các quan sát không can thiệp và thường thì cuối cùng bạn cũng sẽ loại bỏ một số quan sát can thiệp của mình, nhưng những gì bạn còn lại sẽ được khớp.
6. Mô hình sự khác biệt giữa hai nhóm tinh chế.

CEM chuyển sự phức tạp của suy luận nhân quả ra khỏi các phương pháp phân tích — bạn có thể sử dụng bất kỳ phương pháp nào bạn thích — và thay vào đó đặt nó vào các phương pháp tạo tập dữ liệu. Về mặt khái niệm, nó tương tự như việc lấy mẫu thừa hoặc thiếu một tập dữ liệu mất cân bằng trong một bài toán phân loại.

Điều chúng tôi nhận ra là chúng tôi có thể sử dụng cùng loại logic này để tìm bối cảnh kiểm soát thích hợp cho các thử nghiệm kẻ cướp của mình bằng cách đưa thời gian vào làm một trong những tính năng phù hợp. Chúng tôi đã đối sánh một số thuộc tính can thiệp — loại can thiệp mà người dùng nhận được và mức độ hoạt động mà người dùng thể hiện trên ứng dụng tại thời điểm can thiệp. Nhưng sau đó, chúng tôi cũng xác định khoảng thời gian quan sát và đảm bảo rằng bất kỳ người dùng phù hợp nào cũng sẽ nhận được biện pháp can thiệp vào khoảng thời gian gần với biện pháp can thiệp mà chúng tôi đang tìm kiếm biện pháp kiểm soát, nhưng không nằm trong khoảng thời gian quan sát của chính biện pháp can thiệp đó.

Điều này cho phép chúng tôi có các biện pháp kiểm soát phù hợp ở cấp độ người dùng đối với phần lớn các thử nghiệm mà chúng tôi chạy. Thuật toán kẻ cướp loại bỏ một số tính phức tạp của thử nghiệm A/B trên quy mô lớn, nhưng ẩn các phần khác của tính phức tạp đó. Phương pháp kiểm soát của chúng tôi sử dụng sự phức tạp tiềm ẩn đó và giải quyết nó để chúng tôi có thể nhận được các lợi ích thích ứng của việc chỉ định kẻ cướp, nhưng suy luận và phân bổ rõ ràng của thử nghiệm A/B.

Vì vậy, đây là danh sách việc cần làm của bạn:

1. Đối với mọi can thiệp bạn thực hiện, hãy xác định cửa sổ nhìn về phía trước và nhìn về phía sau. Cửa sổ nhìn về phía trước là những gì bạn sử dụng để xem cách người dùng phản ứng với biện pháp can thiệp và cửa sổ nhìn về phía sau là nơi bạn tìm kiếm các trường hợp kiểm soát.
2. Đối với mỗi biện pháp can thiệp, hãy xác định một nhóm các biện pháp can thiệp khác (1) diễn ra trong cửa sổ nhìn về phía sau và (2) không có cửa sổ nhìn về phía trước chồng lên cửa sổ nhìn về phía trước của biện pháp can thiệp mà bạn đang tìm kiếm một sự điều khiển.
3. So khớp những người dùng đã nhận được các biện pháp can thiệp kiểm soát tiềm năng đó với người dùng đã nhận được biện pháp can thiệp mà bạn đang tìm kiếm một biện pháp kiểm soát. Bạn có thể so khớp theo bất kỳ tiêu chí nào bạn muốn - mức độ hoạt động, mức độ tương tự của biện pháp can thiệp nhận được, v.v.
4. Chọn ngẫu nhiên một người dùng từ những người thực hiện được thông qua quy trình so khớp.
5. Giả sử bạn đã gửi can thiệp ban đầu không chỉ cho người dùng thực sự nhận được nó mà còn cho người dùng mà bạn đã chọn làm đối chứng.
6. Đo lường sự khác biệt trong phản hồi giữa người dùng thử nghiệm và kiểm soát của bạn trong bất kỳ khoảng thời gian nào bạn quan tâm.

Một lần nữa, bạn có thể tìm thêm thông tin trong bài báo về arXiv .