A/B test tính năng AI tại khách: kiểm tra SRM trước khi báo con số

Thử hình dung: khách hàng vừa xem demo tính năng AI của bạn và gật đầu. Hai tuần sau, giám đốc vận hành bên khách hỏi thẳng: “Có số nào chứng minh nó giúp được không?” Độ chính xác trên tập test không trả lời được câu đó. Chỉ một thí nghiệm có đối chứng trên người dùng thật mới trả lời được.

Validation offline giúp bạn kiểm tra model có generalize hay không. Nhưng việc model generalize trên tập dữ liệu giữ lại chưa nói lên điều gì về tác động trên quy trình và người dùng thật của khách.

Với một FDE, đó là khoảng trống giữa “model tốt” và “khách gia hạn hợp đồng”. Hướng dẫn dưới đây giúp bạn dựng một A/B test tối giản nhưng đúng kỹ thuật, ngay trên laptop, rồi mang nó tới chỗ khách.

Bạn sẽ dựng gì?

Lấy một tình huống giả định: khách là một công ty thương mại điện tử, bạn deploy tính năng LLM gợi ý câu trả lời cho nhân viên chăm sóc khách hàng.

Nhóm treatment thấy gợi ý, nhóm control làm việc như cũ. Bạn cần ba thứ: hàm chia nhóm ổn định, log đủ thông tin, và một bước kiểm tra chất lượng dữ liệu trước khi đọc kết quả.

Chuẩn bị: Python 3 và thư viện chuẩn (hashlib, math), cộng với quyền ghi log ở hệ thống của khách. Code dưới đây là bản rút gọn để học. Ở môi trường production, bạn sẽ đặt các phần này vào nền tảng experimentation mà khách đang dùng.

Bước 1: Chọn chỉ số trước khi viết dòng code nào

Hãy chia chỉ số thành ba tầng. Chỉ số chính đo hành vi gần tính năng, chẳng hạn tỷ lệ gợi ý được nhân viên dùng. Chỉ số kinh doanh nằm xa hơn, ví dụ thời gian xử lý ticket. Tầng cuối là guardrail, những thứ không được phép xấu đi.

Tầng kinh doanh hay bị kỳ vọng quá mức. Chỉ số downstream là loại kém nhạy nhất, nên muốn thấy được mức tăng có ý nghĩa trên đó thì cần mẫu lớn và thời gian dài.

Ở khách hàng có ít traffic, bạn nên thống nhất từ đầu rằng chỉ số chính mới là thứ quyết định, còn chỉ số kinh doanh chỉ để theo dõi.

Guardrail là phần nhiều người bỏ quên với tính năng AI. Một tài liệu của Milvus lấy ví dụ: nếu Model B kích hoạt bộ phát hiện PII nhiều hơn Model A 10%, đó là tín hiệu rõ ràng để xem lại dữ liệu huấn luyện. Tỷ lệ bị safety filter chặn và tỷ lệ phát hiện PII nên được đo song song ở cả hai nhóm.

Kiểm tra: bạn có một tài liệu một trang ghi tên từng chỉ số, công thức và được người phụ trách bên khách ký xác nhận.

Bước 2: Chia nhóm bằng hash, không bằng random mỗi request

Cùng một người dùng phải luôn rơi vào cùng một nhóm. Nếu nhân viên hôm nay thấy gợi ý, mai lại không, bạn đang đo sự bối rối của họ chứ không phải tác dụng của tính năng.

import hashlib

EXPERIMENT = "goi-y-tra-loi-v1"

def assign(user_id: str) -> str:
    key = f"{EXPERIMENT}:{user_id}".encode()
    bucket = int(hashlib.sha256(key).hexdigest(), 16) % 100
    return "treatment" if bucket < 50 else "control"

Gắn tên experiment vào key để mỗi thí nghiệm có một cách chia độc lập. Kiểm tra: chạy hàm với 10.000 user_id giả, đếm hai nhóm. Con số phải sát 50/50, và gọi lại với cùng một ID phải cho cùng một kết quả.

Bước 3: Khoá phiên bản model và ghi nó vào log

Treatment của bạn không đứng yên. Các nhà cung cấp LLM cập nhật model liên tục, thường không kèm cam kết phiên bản khớp với khung thời gian thí nghiệm. Nếu model đổi giữa chừng, nửa đầu và nửa sau thí nghiệm thực ra đang đo hai tính năng khác nhau.

MODEL_VERSION = "ten-model-kem-phien-ban-cu-the"  # không dùng alias trỏ tới bản mới nhất

def log_exposure(user_id, variant, ts):
    return {
        "experiment": EXPERIMENT,
        "user_id": user_id,
        "variant": variant,
        "model_version": MODEL_VERSION if variant == "treatment" else None,
        "ts": ts,
    }

Đừng nghĩ đặt temperature bằng 0 là xong: nó không loại bỏ được tính bất định của output LLM. Vì thế, ngoài việc khoá phiên bản, hãy ghi model_version vào từng dòng log. Nếu có gì thay đổi giữa chừng, bạn vẫn tách được dữ liệu theo phiên bản để phân tích.

Kiểm tra: truy vấn log và đếm số giá trị model_version khác nhau trong nhóm treatment. Kết quả phải là một.

Bước 4: Tính trước traffic, rồi chạy đủ lâu

Tính năng LLM khó đo hơn một nút bấm đổi màu. Dao động của output LLM chồng lên dao động hành vi người dùng, khiến standard error và minimum detectable effect cùng tăng, nên thí nghiệm cần nhiều traffic hơn.

Thời gian cũng là cái bẫy. Khung hai tuần thường không đủ để phân biệt mức tăng thật với hiệu ứng mới lạ, nên hãy lên kế hoạch chạy 3-4 tuần. Ở chỗ khách, đây là điều cần nói ngay trong buổi kickoff, vì không ai muốn nghe “phải chờ thêm hai tuần” vào phút cuối.

Kiểm tra: vẽ chỉ số chính theo tuần cho từng nhóm. Nếu khoảng cách giữa hai nhóm co lại dần, bạn đang thấy hiệu ứng mới lạ phai đi.

Bước 5: Kiểm tra SRM trước khi nhìn vào kết quả

Trước khi mở bảng kết quả, hãy kiểm tra xem hai nhóm có đúng tỷ lệ đã thiết kế không. Sample Ratio Mismatch (SRM) là khi số người dùng quan sát được ở mỗi nhóm lệch khỏi tỷ lệ phân bổ đã định.

import math

def srm_pvalue(n_a, n_b, ratio_a=0.5):
    total = n_a + n_b
    exp_a, exp_b = total * ratio_a, total * (1 - ratio_a)
    chi2 = (n_a - exp_a) ** 2 / exp_a + (n_b - exp_b) ** 2 / exp_b
    return math.erfc(math.sqrt(chi2 / 2))  # chi-square 1 bậc tự do

print(srm_pvalue(5200, 4800))

Thử với một con số giả định: thiết kế 50/50 trên 10.000 người, nhưng log ghi 5.200 người treatment và 4.800 control. Mỗi nhóm lệch 200 so với kỳ vọng 5.000, chi-square bằng 16, p-value khoảng 0,00006. Chênh lệch này gần như không thể do may rủi.

Nhóm tác giả của Microsoft Research, trong một bài báo tại KDD 2019, ví SRM như cơn sốt: một triệu chứng có thể đến từ nhiều loại lỗi chất lượng dữ liệu khác nhau.

Có thể log của nhóm treatment bị mất khi gọi LLM timeout, hoặc bot chỉ rơi vào một nhóm. SRM không biến mất khi bạn chờ lâu hơn hay thêm người dùng. Cách sửa nằm ở instrumentation, không phải ở việc tính lại trọng số sau khi đã có dữ liệu.

Kiểm tra: chọn trước một ngưỡng chặt, chẳng hạn 0,001. Nếu p-value của SRM nhỏ hơn 0,001 (như 0,00006 ở ví dụ trên), dừng đọc kết quả và đi lần theo đường log của nhóm bị thiếu. Ngưỡng chặt giúp bạn không báo động nhầm khi chạy kiểm tra này mỗi ngày.

Những lỗi hay gặp nhất là gì?

Lỗi phổ biến nhất là báo cáo sau vài ngày vì số liệu “trông đẹp”, đúng lúc hiệu ứng mới lạ đang ở đỉnh. Lỗi thứ hai là chia nhóm theo request thay vì theo người dùng. Lỗi thứ ba là chỉ ghi log exposure ở nhánh treatment, vô tình tạo ra chính SRM mà bạn sẽ phải đi gỡ.

Cũng đừng mang chỉ số kinh doanh ra làm tiêu chí thắng thua khi traffic của khách nhỏ. Bạn sẽ có một kết quả “không có ý nghĩa thống kê”, và khách sẽ hiểu thành “tính năng không có tác dụng”.

Kỹ năng này xuất hiện thế nào ở chỗ khách và trong CV?

Ở chỗ khách, việc đầu tiên không phải là viết hàm assign, mà là ngồi với người phụ trách để chốt chỉ số chính, guardrail và thời lượng 3-4 tuần. Sau đó mới đến log và kiểm tra SRM. Bản báo cáo cuối cùng nên mở đầu bằng dòng “SRM: đạt”, rồi mới đến mức tăng.

Khi đọc JD vị trí FDE, bạn nên dò xem vị trí đó có yêu cầu đo lường tác động hay chạy thí nghiệm với khách không; nếu có, hãy đưa kỹ năng này lên đầu CV. Một gạch đầu dòng mạnh sẽ nêu cụ thể: chia nhóm theo người dùng, khoá phiên bản model, guardrail PII, phát hiện và sửa một lỗi SRM.

Chi tiết cuối cùng đó cho người phỏng vấn thấy bạn đã thật sự chạy thí nghiệm, không chỉ đọc về nó.

Demo giúp bạn có hợp đồng thử nghiệm. Muốn khách gia hạn, bạn cần một thí nghiệm mà chính đội data của họ kiểm tra lại cũng không tìm ra lỗi.