How Instacart Modernized the Prediction of Real Time Availability for Hundreds of Millions of Items While Saving Costs
Bài tóm tắt Instacart 2023 4. Điều chỉnh Độ khó: Trung bình
Instacart · 2023 · 4. Điều chỉnh · Độ khó: Trung bình — bài gốc
Phần 2 trong series ba phần; phần 3 (kiến trúc phục vụ điểm): Instacart 2023. Phần 1 (sản phẩm) đã bỏ qua vì lệch chủ đề. Bài nặng về mô hình ML; wiki chỉ tóm tắt ngắn phần mô hình. Site chặn crawler; ghi chú viết từ bản đọc qua trình duyệt.
Bối cảnh
- Instacart dự đoán xác suất tìm thấy mỗi item (một sản phẩm tại một cửa hàng) để báo còn hàng, sắp hết, hết. Sau đại dịch, catalog lớn lên nhiều lần; tín hiệu từ shopper chỉ có hàng triệu mỗi ngày nên phần lớn item gần như không có quan sát.
- Pipeline cũ: tính feature trong data warehouse Snowflake, job batch chấm điểm mọi item mỗi 2–4 giờ, ghi vào Postgres để phục vụ. Vấn đề: chấm hàng trăm triệu item thường xuyên rất đắt; tín hiệu trễ vài giờ từ nguồn tới lúc phục vụ; một bộ điểm duy nhất không hợp mọi ngữ cảnh (đặt hàng tối cho giao sáng mai khác với điều shopper tới cửa hàng ngay).
Thay đổi chính
- Mô hình ba phần (tóm tắt): General (mẫu dài hạn 7–180 ngày, nới phạm vi theo địa lý và thời gian tới khi đủ mẫu), Trending (lệch so với nền, XGBoost), Real-time (suy từ quan sát gần nhất, ví dụ phân phối thời gian bổ sung hàng).
- Lịch chấm điểm phân tầng theo tần suất: item "đầu" (có tín hiệu trong 10 giờ, khoảng 1% item) được chấm trending hằng giờ và real-time; item "thân" (trong một tháng, khoảng 85%) và "đuôi" chỉ chấm general + trending hằng ngày. Theo Instacart, chi phí tính toán giảm khoảng 80% mà metric online còn tốt hơn.
- Nền tảng mới: là use case đầu tiên của pipeline streaming realtime và bộ công cụ MLOps Griffin (có feature store) của Instacart.
- API nhiều phiên bản điểm: query chỉ định phiên bản, nên điều phối shopper dùng điểm real-time, còn giỏ hàng dùng điểm dự đoán cho thời điểm giao.
Vì sao
- Độ tươi chỉ đáng tiền ở phần nhỏ item thay đổi nhiều; chấm đều mọi thứ với cùng tần suất là lãng phí.
Bài học cho SWE
- Tần suất tính lại theo mức thay đổi, không đồng loạt: phần nóng tính thường xuyên, phần đuôi tính thưa (Pipeline dữ liệu và analytics · Chi phí hạ tầng và build vs buy).
- Một đại lượng có thể cần nhiều "phiên bản theo ngữ cảnh"; phơi phiên bản ra ở API thay vì ép một con số cho mọi người dùng.
Liên quan
Pipeline dữ liệu và analyticsChi phí hạ tầng và build vs buyNền tảng ML (feature, training, serving, giám sát model)
#Batch scoring#Real-time scoring#Snowflake#Feature store#Streaming#Tiered scheduling#Cost#Model versioning
Được nhắc tới trong
Chủ đề (3)
Công ty (1)
Bài tóm tắt (5)