How we reduced our text similarity runtime by 99.96%

Microsoft · 2021 · 2. Tăng trưởng · Độ khó: Dễ — bài gốc

Dự án của đội Commercial Software Engineering của Microsoft làm cùng EPPI Centre (UCL): đề xuất bài báo khoa học mới cho các tổng quan hệ thống. Đây là tối ưu một job batch, không phải hạ tầng lớn.

Bối cảnh

• Mỗi lần chạy phải chấm 100.000 tới 1,5 triệu bài báo mới so với mọi review (mỗi review là một tập bài đã chọn), trong vài giờ. Model chính xác nhất là TF-IDF + cosine với từng bài trong review rồi gộp (ví dụ trung bình 10 bài gần nhất), tốt hơn USE, sciBERT, FastText trên dữ liệu này.
• Bản research đầu tiên: 16 giây cho một bài báo, tức khoảng hai tuần cho cả tập.

Thay đổi chính

• Liệt kê sáu hướng (tiền xử lý nhanh hơn, vector hoá, lấy mẫu review, lọc bằng luật, cách tính cosine, Spark) rồi dựng một script nhỏ đo khoảng 20 cấu hình trên dữ liệu đại diện.
• Qua 8 vòng: tiền xử lý một lần mỗi bài thay vì mỗi review; đổi sang scipy.cdist (khoảng 12 s → 2 s); gom mỗi review thành một ma trận (khoảng 1,5 s); rồi gom mọi bài của mọi review vào một ma trận toàn cục: mỗi bài mới chỉ còn một phép nhân vector × ma trận. Với ma trận lớn, sklearn trên ma trận thưa (CSR) thắng hẳn (0,059 s), dù ở mọi cấu hình nhỏ hơn nó thua scipy vì chi phí xử lý thưa. Cuối cùng lọc trước ứng viên theo lĩnh vực.
• Tổng cộng giảm 99,96% thời gian mỗi bài trước khi song song hoá; cộng Spark, 500.000 bài chạy dưới hai giờ. Độ chính xác được kiểm sau mỗi thay đổi.

Vì sao

• Chi phí cố định của mỗi lần gọi (tiền xử lý, gọi hàm so sánh cho từng cặp) lấn át phép tính; gom thành một phép toán lớn trên biểu diễn thưa trả chi phí đó một lần.

Bài học cho SWE

• Tối ưu không tuyến tính: cách cài đặt thua ở cấu hình nhỏ có thể thắng hẳn khi đổi biểu diễn dữ liệu; đổi một biến mỗi lần dễ bỏ lỡ cấu hình tốt nhất.
• Đo trên mẫu nhỏ đại diện với profiler trước khi nghĩ tới phân tán; Spark là bước cuối chứ không phải bước đầu.

Liên quan

• Batching và khấu hao round-trip