Similarity Engine at eBay

eBay · 2023 · 3. Quy mô lớn · Độ khó: Khó — bài gốc

Bối cảnh

• eBay (12/2022) có khoảng 134 triệu người dùng và 1,7 tỉ listing đang hoạt động. Tìm kiếm theo từ khoá vấp từ đồng âm, query đuôi dài, ý định người dùng; team CoreAI dựng một engine ANN để tìm listing giống nhau theo embedding (tiêu đề, thuộc tính, ảnh) và gợi ý cá nhân hoá theo lịch sử duyệt.

Thay đổi chính

• Backend ANN cắm được: HNSW (bản sửa riêng của eBay) và ScaNN (Google, product quantization + phân vùng); hỗ trợ L2, inner product, cosine, Hamming.
• Index builder phân tán: dịch vụ ingest ghi yêu cầu dựng vào kho metadata job; scheduler chia việc cho các node builder, node lỗi thì chạy lại chỗ khác; dữ liệu embedding được chia shard theo shard key hoặc thuật toán phân cụm, mỗi shard một index HNSW hoặc ScaNN. Shard là đơn vị scale; số shard tự chọn theo kích thước file embedding, và tự chia lại nền với ít dữ liệu di chuyển nhất.
• Query node (C++): thấy index mới trên storage chung theo timestamp thì nạp ngầm vào RAM rồi hot swap, không downtime; mỗi shard nhân bản trên nhiều query node ở nhiều cluster để cân tải và chịu lỗi.
• Cập nhật gần thời gian thực: sự kiện thêm/sửa/xoá listing đi qua pipeline NRT, gọi dịch vụ embedding, lưu vào time series DB, stream tới query node cập nhật index hnswlib trong RAM; listing mới tìm được trong vài giây.
• Central Control Plane chỉ là control plane: theo dõi query node vào/ra, phân bổ shard, đưa bảng phân bổ (grid) cho Ingest Gateway; không nằm trên đường phục vụ, nên CCP sập thì ứng dụng chạy tiếp ở chế độ suy giảm với phân bổ hiện có. Ingest Gateway gửi query tới mọi shard, gộp và xếp kết quả theo khoảng cách, cân tải giữa các replica của cùng shard.
• Filter theo thuộc tính: post-filter trên top-k trả về thiếu kết quả, nhiều điều kiện chặt có thể ra 0; tăng k thì latency tăng. Chuyển sang lọc ngay trong lúc duyệt đồ thị HNSW (chỉ đi qua node thoả điều kiện, gộp index vector và metadata). Filter càng chặt thì tìm càng gần vét cạn, latency vọt; thêm trần số bước tìm (800) và rơi về brute-force khi filter quá chặt (tập ứng viên khoảng 500 nghìn), theo thí nghiệm trên dữ liệu eBay Ads thì cho kết quả rất tốt.
• Đo backend: với HNSW, k càng lớn thì càng chậm (efSearch lớn) nhưng không mất chất lượng; ScaNN ít chậm đi nhưng rescore bằng độ chính xác đầy đủ thành nút thắt khi k lớn. Đánh đổi giữa kích thước index, bộ nhớ, kích thước embedding được đo cho từng cấu hình (có lượng tử hoá 8-bit).
• Kết quả, theo eBay: hàng chục nghìn request/giây; 13 index ở production (item–item, query–item, query–query, user–item; văn bản và ảnh); index lớn nhất 1,7 tỉ listing, top k=200 trong 12 ms ở p95; mang lại doanh thu hàng triệu USD mỗi năm.

Vì sao

• Theo eBay, bốn đại lượng latency, throughput, thời gian dựng và recall luôn đánh đổi lẫn nhau nên backend phải cắm được và cấu hình theo từng use case.

Bài học cho SWE

• Tách control plane khỏi đường phục vụ: control plane sập thì dữ liệu phân bổ cũ vẫn đủ để chạy tiếp.
• Dựng index ngoài, phát hành bằng hot swap, rồi vá bằng luồng cập nhật gần thời gian thực: hai đường bổ sung nhau.
• Filter chặt làm tìm kiếm xấp xỉ thoái hoá thành vét cạn; đặt trần công việc và có đường lùi rẻ hơn (brute-force trên tập nhỏ).

Liên quan

• Vector search và index ANN · Hạ tầng tìm kiếm
• Cùng công ty: eBay 2019 · eBay 2026
• Cùng bài toán: Elastic 2026 · Qdrant 2026 (filter chặt trong HNSW, từ phía nhà cung cấp)