Evolution and Scale of Uber's Delivery Search Platform

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

Bối cảnh

• Phần lớn đơn Uber Eats bắt đầu từ ô tìm kiếm. Khớp từ khoá hỏng với từ đồng nghĩa, lỗi gõ, viết tắt, trộn ngôn ngữ ("pan" là bánh mì tiếng Tây Ban Nha, là cái chảo tiếng Anh). Semantic search mã hoá query và tài liệu vào cùng không gian vector. Theo Uber, đưa nó vào production là cả một stack: deploy model, phục vụ index ANN, giám sát, quản lý phiên bản.

Thay đổi chính

• Model (tóm tắt): two-tower trên backbone Qwen tinh chỉnh bằng dữ liệu Uber Eats, một model cho mọi vertical và thị trường; huấn luyện với loss theo Matryoshka (MRL) để một model ra nhiều độ dài embedding (128 tới 1.536 chiều). Query embedding tính online, document embedding tính batch theo lịch; mỗi lần train có ID phiên bản cho query model, doc model và cặp. Embedding tính ở mức feature (store, item) rồi join về catalog hàng tỉ ứng viên, lưu trong bảng feature store.
• Index: Lucene Plus, index riêng cho nhà hàng và cho grocery/retail; HNSW lưu cả float32 lẫn int8. Pre-filter boolean (hexagon, city_id, doc_type, fulfillment_types) chạy trước ANN để thu nhỏ tập ứng viên trên kho hàng tỉ tài liệu; sau ANN có bước micro-rerank bằng mạng nhỏ.
• Chất lượng so với chi phí, theo thí nghiệm của Uber: giảm k mỗi shard từ 1.200 xuống khoảng 200 (chọn theo thống kê phân phối dữ liệu để giữ cỡ tập kết quả tổng): latency −34%, CPU −17%, recall gần như không đổi; scalar quantization int7 giảm latency hơn một nửa so với fp32, recall vẫn trên 0,95; cắt embedding còn 256 chiều mất dưới 0,3% chất lượng cho tiếng Anh và Tây Ban Nha, storage gần −50%.
• Làm mới hai tuần một lần, đồng bộ model và index: workflow train hoặc lấy model, sinh embedding, dựng snapshot index mới mà không đụng đường đọc đang chạy.
• Blue/green ở mức cột của index: mỗi index có hai cột cố định embedding_blue và embedding_green, cấu hình nhẹ ánh xạ model đang dùng vào một cột; mỗi lần làm mới, cột đang phục vụ giữ nguyên, cột kia được nạp embedding mới. Đã cân nhắc hai index blue/green riêng (an toàn hơn vì không đụng index production) nhưng tốn storage và bảo trì gấp đôi.
• Ba cổng trước khi deploy (vì snapshot dựng lại cả cột đang phục vụ, lỗi có thể âm thầm làm hỏng nó): đầy đủ (số tài liệu và các tập con đã lọc khớp bảng nguồn); tương thích ngược (cột không đổi phải giống từng byte giữa bản trước và sau làm mới, lệch là dừng); đúng (deploy index mới lên môi trường non-prod, phát lại query thật có kiểm soát tốc độ, so recall với index production).
• Kiểm tra lúc phục vụ: index ghi model ID của cả hai cột trong metadata; trên request lấy mẫu, service so model sinh query embedding với model ID của cột đang dùng; lệch thì phát metric lỗi tương thích và log ngữ cảnh; lỗi khác 0 trong một khoảng ngắn thì alert và tự rollback model về bản trước (index giữ nguyên). Không thêm latency hay bước mạng trên đường đọc.

Vì sao

• Model và index phải đi cùng phiên bản; hai thứ phát hành riêng có thể lệch nhau mà mọi request vẫn trả kết quả, chỉ là kết quả sai.

Bài học cho SWE

• Tham số tìm kiếm (k mỗi shard), lượng tử hoá và độ dài embedding là ba núm chi phí độc lập; đo từng núm theo recall trước khi chọn.
• Khi bản dựng mới chứa lại cả phần đang phục vụ, kiểm phần đó không đổi (so byte) trước khi deploy.
• Ghi phiên bản của thứ phụ thuộc vào metadata của dữ liệu và kiểm khớp lúc phục vụ trên mẫu; lệch thì tự rollback.
• Blue/green không nhất thiết là hai hạ tầng; hai cột trong một index rẻ hơn nhưng cần cổng kiểm mạnh hơn.

Liên quan

• Vector search và index ANN · Hạ tầng tìm kiếm · Deploy và release an toàn
• Cùng công ty: Uber 2026 · Uber 2026
• Cùng bài toán: eBay 2023 · Instacart 2023 (mỗi phiên bản model một cột)