Thuật Toán Chốt Đơn Mua Hàng: Từ Tổng Kho Đến Tận Cửa Cuối (Last-Mile)

Hễ mà bạn chốt 1 cái đơn hàng trên Amazon lúc 11:47 PM và sáng hôm sau nó lọt thỏm trước cửa nhà, thì từng li từng tí của cái hành trình đó đều bị giật dây (orchestrated) bởi một bầy thuật toán. Bọn này tự quyết định real-time chẻ ngang dọc qua cả mạng lưới ôm hàng trăm cái tổng kho (warehouses), hàng ngàn tài xế, và hàng triệu món đồ trong kho (inventory). Chả có cái khỉ gì là tình cờ (chance), và cũng ứ phải do con người tự quyết.

Bài này lột trần cái chuỗi quyết định 6 bước bằng thuật toán (algorithmic decision chain) đã hô biến một cái đơn hàng (confirmed order) thành cục hàng nằm chỏng chơ trước cửa: từ trò dòm kho chốt tồn (inventory availability checks) và chấm chọn tổng kho, vọt qua hệ thống optimizer CONDOR của Amazon và logic chẻ đơn hàng (split shipment logic), tới tận mấy cái VRP solvers hòng đẽo đường chạy chặng cuối (last mile).

Để cày trọn sớ bài kiến trúc nhào nặn đơn hàng (order allocation) của e-commerce, coi Sớ Bài Nhào Nặn Đơn Hàng E-Commerce (E-Commerce Order Allocation Series).

Mảng Nhức Nhối Nhào Nặn Đơn (Order Allocation Problem): Cớ Sao Chệch Vài Miligiây Lại Đốt Hàng Triệu Đô

Cái quyết định chọn kho nghe qua thì đơn giản: dòm xem cái kho nào đang ôm món đồ (in stock), rồi chấm cái kho gần nhất. Nhưng thực tế, nó là 1 cái bài toán tối ưu hóa đa mục tiêu (multi-objective optimization problem) ngậm đầy các điều kiện ràng buộc đan chéo nhau (interdependent constraints) mà buộc phải giải lọt dưới mốc 200ms cho mỗi đơn, với cường độ hàng triệu đơn đổ mỗi ngày.

Đám ràng buộc đó bao gồm:

• Tồn Kho (Stock availability): Cái món đồ đó có sẵn ở từng cái kho ứng viên hông?
• Tiền Dũa Gói Đơn (Fulfillment cost): Giao hàng từ 1 cái kho gần hơn thì rẻ hơn, nhưng tiền nhân công thì thay đổi theo cơ sở.
• Cam Kết Giao (Delivery SLA): Cái kho này có nhét nổi cục hàng lên xe tải giao hàng kịp giờ để đáp ứng được cái ngày hẹn giao hông?
• Sức Gồng Của Thằng Giao (Carrier capacity): Thằng giao hàng gánh cái kho này có đang bị kẹt cứng (at capacity) hông? Nó có còn thừa công suất hốt hàng (pickup capacity) trong ngày hôm nay hông?
• Mục Tiêu Xanh Carbon Cùng Bảo Vệ Môi Trường (Carbon and sustainability targets): Vài danh mục SKU có gắn kèm mấy cái chuẩn (preferences) điều hướng giao hàng dựa vô lượng phát thải (emissions-based routing).
• Nhu Cầu Tiên Liệu (Anticipated demand): CONDOR (máy ép ràng buộc của Amazon) ứ thèm chỉ ngó mỗi mấy cái đơn hiện tại, mà nó còn tính luôn xác suất bọng đơn rớt vô trong tương lai khi chia chác hàng tồn.

Quyết cái này sai 1 ly — chấm cái kho ứ gánh nổi SLA, hay chọn cái kho tưởng còn hàng (stock) mà hóa ra đống đó đã bị xí chỗ (reserved) cho 1 kênh giao hàng khác mất rồi — sẽ kéo theo hậu quả là thằng giao hàng rề rà, người mua nguyền rủa (customer experience failures), và ăn phạt ngập mặt tiền.

Bước 1 — Dò Mạch Tồn Kho (Inventory Availability Check): Đồng Bộ (Sync) Hàng Tồn Kho Real-Time Quét Dọc Mọi Kho

Trước khi thuật toán chia chác (allocation algorithm) nó chạy, cả hệ thống cần có 1 cái nhìn cực chuẩn, real-time về đống hàng tồn. Cái trò này nó khó ăn hơn cái mác nghe ngoài tai.

Hệ thống tồn kho của Amazon ôm khư khư 2 cái cục đếm (counts) tách bạch:

• Ôm Vật Lý (Physical on-hand): Số lượng cục hàng sờ nắm được nằm chình ình trong kho.
• Còn Thừa Để Chốt Hứa (Available-to-promise - ATP): Số lượng vật lý vứt bớt (minus) đi đám hàng đã bị nhồi (committed) cho mấy cái đơn khác (đã bị xí chỗ, đang bị nhặt (picked), đang bồng bế (in transit) qua chỗ đóng gói).

Cái cục đếm ATP mới là con số có giá trị (relevant) cho mấy đơn hàng mới. Một món đồ dòm bề ngoài có vẻ còn tồn (in stock) dựa trên đếm vật lý, có thể thực chất cái ATP của nó bằng 0 nếu mọi món hàng đều đã bị chia chác (allocated) cho mấy đơn đang chạy (processed).

Ở quy mô của Amazon, bộ đếm ATP được cập nhật (updated) liên tục xuyên qua 1 dòng suối (stream) các sự kiện tồn kho: nhặt (picks), cất (putaways), trả hàng (returns), nhập kho (inbound receipts), và cross-docking. Đám sự kiện này chảy qua 1 cái ống dẫn (pipeline) stream real-time (y hệt cái mẫu Kafka + Flink đã được bóc phốt trong bài Kiến Trúc Gọi Xe Real-Time (Real-Time Ride-Hailing Architecture)) tọt vô 1 bộ nhớ tạm (cache) in-memory ôm trọn đống tồn để nốc (serves) lệnh tra cứu (lookup) chia chác.

Trò Xí Chỗ Mềm (Soft Reservations)

Hễ có 1 đơn được chốt, một cái xí chỗ mềm được tạo ra tức thì ở trong cache — thụt lùi (decrementing) đồng hồ ATP xuống trước khi đơn đó được xác nhận chính thức trong database. Cái này chặn đứng việc 2 cái đơn hàng bị cấp cho cùng 1 món hàng cuối cùng 1 lúc. Cái trò xí chỗ mềm này có 1 cái TTL (tuổi thọ, thường là 5–15 phút); hễ đơn bị tịt đoạn trả tiền (payment) hay kẹt vòng check lừa đảo (fraud checks), thì cái xí chỗ đó hết hạn (expires) và cục hàng (inventory) được nhả ra (released).

Cái trò này nó y chang cái mẫu Redis atomic counter pattern (Mẫu đồng hồ Redis nguyên tử) được xài trong mấy đợt flash sales — hốc ngó vô Kiến Trúc Shopee Flash Sale: Cản Bước & Redis hòng coi chi tiết cái trò đó.

Bước 2 — Thuật Toán Chọn Tổng Kho (Warehouse Selection Algorithm): Giằng Co (Trade-Offs) Quãng Đường, Tiền, Cùng SLA

Có trong tay bản đồ hàng tồn, thuật toán chọn kho sẽ mang mấy cái kho ứng viên (candidate fulfillment centers) ra đập lên 1 hàm phí tổn (cost function).

Cái ngây thơ (naive) của hàm này nó hình thù như sau:

cost(warehouse, order) = shipping_distance * shipping_rate_per_km + labor_cost(warehouse)

Còn cái bản xài thiệt (production version) nó nhồi thêm 1 đống các hệ số nhân (multipliers) và ràng buộc (constraints):

cost(warehouse, order) = 
    (shipping_distance * carrier_rate_per_km)
    + (labor_cost_per_unit(warehouse))
    + (SLA_risk_penalty if fulfillment_time > SLA_threshold)
    + (carrier_capacity_surcharge if capacity_utilization > 0.85)
    - (carbon_credit if warehouse_in_green_zone)

Hàm chi phí (cost function) này được tính cho mọi kho ứng viên (candidate warehouse) mà ôm ATP > 0 cho món hàng bị gọi (ordered item). Kho nào có chi phí (cost) rẻ nhất (minimum) sẽ được chốt (selected).

Đối với mấy món hàng chỉ có 1 kho duy nhất ngậm (availability at only one warehouse), thì quyết định chọn kho là trò con nít (trivial). Đối với mấy món hàng vứt đầy cả hàng tá kho (khoái khẩu của mấy SKU bán đắt như tôm tươi high-velocity SKUs), trò tối ưu qua 1 mảng lớn đám ứng viên (large candidate set) nài nỉ ốp thêm mấy mưu (strategies) xén bớt (pruning) — hất cẳng (discarding) đám kho nằm ngoài bán kính SLA (SLA radius) cho phép trước khi rảnh rỗi tính nguyên 1 hàm chi phí đầy đủ.

Bước 3 — CONDOR Của Amazon: Cỗ Máy Ép Tối Ưu Cho Nhào Nặn Đơn Hàng Toàn Cầu

CONDOR (Constraint Optimizer for Network Distribution of Orders and Replenishment - Cỗ Máy Ép Tối Ưu Mạng Lưới Nhồi Trút và Bù Hàng) là hệ thống nội bộ (internal system) của Amazon hòng nhằn cục toán nhào nặn (allocation problem) hàng tồn toàn cầu. Nó ngồi chễm chệ ở bên trên tầng quyết kho cho từng đơn (per-order warehouse selection layer) và nhằn cục toán chia chác hàng tồn nguyên mạng lưới (network-wide inventory allocation problem): Amazon nên định vị đống tồn của mình rải xuyên khắp mạng lưới kho (fulfillment network) ra sao hòng đè bẹp (minimize) tổng chi phí chia chác cho mấy đơn sẽ đổ xuống (anticipated future orders)?

CONDOR Ngồi Ghế Tổng Chỉ Huy Tối Ưu (Global Optimizer)

CONDOR nốc (ingests):

• Đống ATP hiện tại ở mọi tổng kho toàn cầu
• Tín hiệu (signals) nhu cầu trong quá khứ theo SKU, vùng địa lý, và ngày trong tuần
• Bản dự báo nhu cầu bằng xác suất (probabilistic demand forecasts - đám mô hình ML dự đoán số lượng đơn theo vùng và SKU cho 14 ngày tới)
• Lịch trình khả năng vận tải (carrier capacity schedules), giá cước xe tải (truck lane rates), và các mô hình chi phí nhân công tổng kho

Nó nhả ra (outputs):

• Bản khuyên (recommendations) điều hàng (inventory transfer - di dời X cục SKU Y từ FC A sang FC B trước ngày Z)
• Mục tiêu xí chỗ đường vận tải (carrier lane reservation targets)
• Đề xuất (suggestions) đập thêm hàng (replenishment order) gửi tới mấy ông bán hàng (vendors)

Mấy bản khuyên của CONDOR ứ có bị ốp vô tự động (applied automatically) — chúng lọt vô tầm ngắm (reviewed) của team quản lý chuỗi cung ứng (supply chain operations team) của Amazon và bị đem ra xử (executed) thông qua mấy luồng đập hàng (replenishment workflows). Nhưng cái kết quả (outputs) nó nhả ra thì lại dắt mũi (drive) đại đa số mấy quyết định rải hàng chủ động (proactive inventory positioning decisions) của Amazon.

Tại Sao Cục Này Lại Đóng Đinh (Matters) Cho Trò Chọn Từng Đơn (Per-Order Allocation)

Sức ảnh hưởng của CONDOR lên nhào nặn từng đơn tuy đi vòng (indirect) mà thấm cực sâu (profound). Bởi vì CONDOR nó cứ xoay vần (rebalances) tồn kho liên tục hòng đè chi phí vận tải ngóng (expected shipping distance) cho đám đơn dự đoán (anticipated orders), thành ra thuật toán chọn kho (warehouse selection algorithm) thường nhắm mắt cũng trúng cái kho xịn (optimal warehouse) nó nằm trình ình ngay sát đít (already nearby). Cỗ máy tối ưu per-order real-time chạy rẹt rẹt (faster) và nhả ra kết quả thơm hơn (better results) là vì CONDOR nó đã dọn mâm (strategic pre-positioning work) sẵn hết rồi.

Muốn đào sâu vô mấy mô hình tối ưu ép buộc (constraint optimization models) của CONDOR, hốt bài Phần 4 — CONDOR Của Amazon & Cái Trò Quăng Hàng Đi Trước (Anticipatory Shipping).

Bước 4 — Ném Hàng Trước (Anticipatory Shipping): Trò Tiên Đoán Đơn Hàng Trước Cả Khi Khách Chốt Đơn

Trò ném hàng trước (anticipatory shipping — Amazon lận lưng cái bằng sáng chế trò này với mác “ném hàng đoán trước - predictive shipping”) nâng tầm trò dự báo của CONDOR đi thêm 1 bước: thay vì ngồi đợi khách chốt đơn rồi mới rinh hàng (shipping), Amazon quăng đồ (products) tọt vô các trung tâm chia chác theo vùng (regional distribution centers) từ khi khách còn chưa buồn chốt đơn (before an order has been placed), dựa trên dự đoán nhu cầu (predicted demand).

Trò Quăng Hàng Trước Chạy Bằng Động Cơ Nào (How Anticipatory Shipping Works)

Mô hình ML lái cái trò này nó liếc dòm (considers):

• Thói quen khách đi dạo (browsing behavior) và thẩy đồ vô wishlist
• Ba cái nhịp nhu cầu theo mùa ở từng vùng (regional seasonal patterns - áo khoác mùa đông ở mấy thành phố phía bắc vào tháng 11)
• Lịch lên sóng của mấy chiến dịch marketing gần nhất
• Đám Đăng ký & Tiết kiệm (Subscribe & Save) và mấy nhịp đơn hàng đẻ lặp (scheduled repeat order patterns)

Hễ điểm tự tin (confidence score) của mô hình cho 1 ông khách chốt đơn một món hàng (specific product) nhảy vọt qua ngưỡng (threshold), Amazon hốt ngay 1 món (unit) từ 1 trung tâm (fulfillment center) ở giữa (central) quăng tọt vô 1 trung tâm chia chác (sortation center) theo vùng (regional) hay 1 bến đỗ Prime Now (delivery station) nằm ngay sát nách (near) ông khách bị đưa vô tầm ngắm (predicted buyer). Chẳng may mà ông khách đó chốt đơn thiệt, thì món hàng đã nằm sẵn ở trong khu đô thị (metro area) của ổng rồi — giúp giao hàng trong ngày (same-day) hay sáng hôm sau (next-morning) mà ứ tốn thêm đồng phí giao gấp (express shipping costs) nào.

Nếu cú đoán đó trật lất (wrong) và ông khách đó chả thèm chốt đơn, thì món đồ bị rinh đi hớ đó (pre-positioned unit) sẽ bị nuốt lại (reabsorbed) vô đống tồn của vùng và có thể sẽ được bán cho 1 ông khách khác ở trong vùng đó — hoặc ngậm đắng rinh lại về FC trung tâm (central FC) nếu chả có nhu cầu (demand) nảy sinh (materialize).

Độ sống còn về mặt tiền bạc (financial viability) của trò ném hàng trước này đu bám (depends) vô độ chuẩn xác (prediction accuracy) cao chót vót. Tiền phí (cost) của 1 cú rinh hàng đi trước hố (incorrect pre-shipment = phí ném đi đổ sông biển + phí có thể vác hàng lại) buộc phải thấp hơn cái tiền lời bình quân (average revenue improvement) từ việc dụ dỗ (converting) được khách — những kẻ có nguy cơ bỏ đi chọn 1 thằng đối thủ (competitor) có tốc độ giao hàng nhanh hơn.

Bước 5 — Tách Đơn (Split Shipment) Chỏi Lại Gộp Đơn (Consolidation): Lúc Nào Thì Tách Làm Nhiều Gói

Mấy cái đơn ôm nhiều món (multi-item orders) đẻ ra 1 cục nhức đầu lúc chia chác: mọi món đồ có nên cùng chui ra từ cùng 1 kho hông (gộp đơn - consolidation), hay là mỗi món tự đi từ cái kho đang ôm món đó (tách đơn - split shipment)?

Ma Trận Giằng Co Cân Não (The Trade-Off Matrix)

Thuật toán tách đơn của Amazon lên mô hình (models) trọn gói cái chi phí của từng lựa chọn:

• Tiền chi cho trò gộp đơn (Consolidation cost): Phí giao hàng + tiền phạt (penalty) có thể rớt xuống đầu nếu phạm SLA
• Tiền chi cho trò tách đơn (Split cost): Hai lần trả tiền giao hàng + điểm trải nghiệm khách hàng bị tuột (studies show customers perceive split deliveries as service failures even when both arrive on time)

Thuật toán ném 1 cái tạ (weights) cực nặng vô mấy tín hiệu trải nghiệm khách hàng: 1 ông khách mà bị nhận 1 đơn tách (split shipment) trước đó thì ôm 1 xác suất quay xe (churn probability) cao hơn (đo được đàng hoàng), thành thử né cái trò tách đơn cho mấy ông khách high-LTV (cày tiền nhiều) được ưu tiên (priority boost).

Bước 6 — Giao Hàng Chặng Cuối (Last-Mile Delivery): Hệ Máy Giải VRP (VRP Solvers) Và Chiêu Tính Ma Trận Khoảng Cách (Distance Matrix Calculation)

Một khi cái quyết định kho đã được chốt, cục hàng thật (physical package) bắt đầu lăn bánh. Bài toán dò đường chặng cuối (last-mile routing problem) — quăng gói hàng cho mấy ông tài xế và lên kế hoạch thứ tự giao hàng (delivery sequence) ngon lành nhất cho từng ông — là 1 bài toán Đẽo Đường Xe Chạy (Vehicle Routing Problem - VRP) kinh điển.

Cái Bài Toán Đẽo Đường Xe Chạy (Vehicle Routing Problem - VRP)

Thằng VRP nó hỏi thế này: với 1 đống các điểm giao hàng, 1 dàn xe với mấy cái giới hạn sức chở (capacity constraints), và 1 cái bến (depot), hãy đào ra 1 bộ đường chạy sao cho tổng quãng đường (hay thời gian) bị đè bẹp (minimizes) xuống mức đáy, trong khi phải đảm bảo mọi điểm giao hàng đều được ghé thăm y xì 1 lần (exactly once) và chả có con xe nào bị nhét quá sức (exceeds its capacity).

Cái VRP về cơ bản là NP-hard — ứ có cái thuật toán nào có thể giải chính xác (exact solution) trong thời gian đa thức (polynomial-time). Ở quy mô của Amazon (hàng triệu đơn giao mỗi ngày), đòi tối ưu chính xác là chuyện không thể tính toán nổi (computationally intractable). Mấy cái trò thực tế (practical approaches) là:

• Cỗ Máy Giải Heuristic (Heuristic solvers): Thuật toán Clarke-Wright Savings, or-opt, 2-opt improvement heuristics
• OR-Tools của Google: Một cái cỗ máy giải mã nguồn mở (open-source) cho Constraint Programming (quy hoạch ràng buộc) và routing (dò đường), nó ốp vô meta-heuristics (LNS — Large Neighborhood Search) hòng móc ra mấy cái nghiệm gần ngon nhất (near-optimal solutions)
• Dò đường bằng ML (ML-augmented routing): Xài mấy cái hàm giá trị đã được dạy dỗ (learned value functions) hòng nhồi ưu tiên cho mấy cái hướng tìm kiếm sáng sủa (promising search directions) trong quá trình tối ưu bằng heuristic

Tính Toán Ma Trận Khoảng Cách (Distance Matrix Calculation)

Mấy cái VRP solvers nài nỉ 1 cái ma trận khoảng cách (hay thời gian di chuyển) giăng giữa tất cả mấy điểm giao hàng và cái bến (depot). Cái ma trận này ứ thể bị tính bằng trò xài khoảng cách đường thẳng (Euclidean) — mấy cái khoảng cách trên mạng lưới đường sá (road network distances) nó lệch pha xa lắm, nhất là ở mấy khu đô thị với đường 1 chiều, đèn giao thông (traffic signals), và rào cản vật lý (physical barriers).

Amazon xài 1 cái mớ hổ lốn (combination) giữa GraphHopper (chơi hệ tự host trên đống data mạng đường sá từ OpenStreetMap) và mấy API của HERE Maps (hàng độc quyền - proprietary) hòng tính trước (pre-compute) mấy cái thời gian chạy trên mạng đường (road-network travel times) chuẩn đời (realistic) giữa tất cả các cặp điểm giao hàng trong 1 vùng (zone). Cái trò tính toán ma trận khoảng cách này nó chạy vô đêm hôm trước, để sáng ra là mấy cái đường chạy đã được lên lịch (planned).

Để xem 1 bản bóc mẻ (breakdown) chi tiết về API tính ma trận khoảng cách của GraphHopper và cách nó được quăng ra chạy thật (deployed in production), ngó GraphHopper So Găng CARTO: Cỗ Máy Dò Đường Chốt Đơn Hàng (Order Fulfillment Routing Engine).

App Tài Xế “A-to-Z” Và Tính Tối Ưu Thứ Tự Giao Hàng (Sequence Optimization)

Mấy ông tài xế giao hàng của Amazon xài cái app Amazon Flex “A-to-Z”, cái app này phơi ra 1 cái thứ tự dừng xe (stops) đã được tối ưu. Cái thứ tự này được tính toán trước (pre-computed) bởi cái VRP solver nhưng có thể bị nắn bóp (dynamically adjusted) trong thời gian thực dựa vô:

• Data kẹt xe thực tế (live traffic - Google Maps hay HERE Traffic APIs)
• Mấy cục hàng giao thành công (vứt mấy cái trạm dừng đã xong)
• Mấy cục hàng giao xịt (lên lịch giao lại (reattempt) hay bẻ lái (redirect) vô tủ đồ locker)
• Khách đổi lịch giao (reschedules) hay mấy cái yêu cầu OTP (One-Time Password)

Cái trò tối ưu lại (re-optimization) nhảy nhót (dynamic) này nó chạy liên tục trong suốt khung giờ giao hàng (delivery window), đảm bảo là 1 cú kẹt xe giữa đường (mid-route traffic jam) hay 1 cú giao hụt (access failure) sẽ chích (triggers) 1 cú vẽ đường lại (re-route) chớ hông phải để rớt cái SLA.

Tự Build Một Bộ Nhào Nặn Đơn (Allocation Engine) Thu Nhỏ Cho Mình (Google OR-Tools)

Với mấy ông kỹ sư đang nặn 1 hệ thống chia chác kho (warehouse allocation) hay dò đường chặng cuối (last-mile routing) cho 1 nền tảng scale nhỏ (smaller-scale platform), Google OR-Tools sẽ quăng cho bạn 1 cái móng nhà (foundation) bằng mã nguồn mở (open-source) xịn cỡ production (production-grade).

Một bản code Python cùi bắp nhất (minimal Python implementation) của cỗ máy giải VRP xài OR-Tools:

from ortools.constraint_solver import routing_enums_pb2, pywrapcp

def solve_vrp(distance_matrix, num_vehicles, depot):
    """
    distance_matrix: NxN matrix of travel times between locations
    num_vehicles: number of available delivery vehicles
    depot: index of the depot location in the matrix
    """
    manager = pywrapcp.RoutingIndexManager(
        len(distance_matrix), num_vehicles, depot
    )
    routing = pywrapcp.RoutingModel(manager)

    def distance_callback(from_index, to_index):
        from_node = manager.IndexToNode(from_index)
        to_node = manager.IndexToNode(to_index)
        return distance_matrix[from_node][to_node]

    transit_callback_index = routing.RegisterTransitCallback(distance_callback)
    routing.SetArcCostEvaluatorOfAllVehicles(transit_callback_index)

    # Đập thêm ràng buộc Distance (sức chứa của mỗi đường chạy tính bằng đơn vị thời gian)
    dimension_name = "Distance"
    routing.AddDimension(
        transit_callback_index,
        0,       # no slack
        3000,    # maximum distance per vehicle
        True,    # start cumul to zero
        dimension_name,
    )

    search_parameters = pywrapcp.DefaultRoutingSearchParameters()
    search_parameters.first_solution_strategy = (
        routing_enums_pb2.FirstSolutionStrategy.PATH_CHEAPEST_ARC
    )
    search_parameters.local_search_metaheuristic = (
        routing_enums_pb2.LocalSearchMetaheuristic.GUIDED_LOCAL_SEARCH
    )
    search_parameters.time_limit.FromSeconds(30)

    solution = routing.SolveWithParameters(search_parameters)
    return solution, routing, manager

Cái cỗ máy giải này dư sức nhai (capable of handling) hàng trăm điểm giao hàng cho mỗi kế hoạch đường chạy (route plan). Để quăng ra chạy thật (production use) cho hàng ngàn điểm mỗi ngày, OR-Tools có thể được chạy (deployed) như 1 cái microservice ôm bằng container (containerized microservice) có 1 cái REST API — tha hồ bung ngang (scalable) độc lập với cái hệ thống quản lý đơn hàng (order management system). Cái kiến trúc cho 1 dịch vụ như vậy ăn khớp một cách tự nhiên (integrates naturally) vô đống Go microservices chạy trên nền Kubernetes đã được bóc phốt trong Thiết Kế Kiến Trúc Hệ Sinh Thái E-Commerce 21-Service (Architecting a 21-Service E-Commerce Ecosystem).

Những Câu Hỏi Thường Lặp (FAQ)

Amazon ra quyết định giao hàng từ kho nào bằng cách nào?

Thuật toán chọn kho (warehouse selection algorithm) của Amazon cân đo đong đếm (evaluates) mọi cái trung tâm (fulfillment center) có ôm hàng tồn có thể chốt hứa (available-to-promise inventory) đập vô 1 cái hàm chi phí (cost function) gộp (combines) quãng đường giao hàng, cước phí của thằng giao hàng, tiền nhân công, rủi ro SLA, và độ kẹt của thằng giao hàng (carrier capacity utilization). CONDOR, cỗ máy ép tối ưu ràng buộc toàn cầu (global constraint optimizer) của Amazon, định vị trước hàng rải ngang qua mạng lưới dựa trên dự báo nhu cầu, nên cái kho xịn nhất (optimal warehouse) thường là đã nằm sẵn ngay gần đó rồi khi thuật toán chia chác real-time chạy.

Cái Bài Toán Đẽo Đường Xe Chạy (Vehicle Routing Problem - VRP) trong e-commerce là cái quái gì?

VRP là 1 bài toán tối ưu tổ hợp (combinatorial optimization problem): với 1 dàn xe (fleet of vehicles), 1 cái bến (depot), và 1 đống điểm giao hàng, hãy tìm ra mấy cái đường chạy hòng đè bẹp tổng quãng đường trong khi phải tôn trọng giới hạn sức chở của xe (vehicle capacity constraints) và ghé thăm mọi điểm giao y xì 1 lần (exactly once). Nó là thuật toán cốt lõi (core algorithm) đằng sau mọi hệ thống dò đường giao hàng chặng cuối (last-mile delivery routing system). Nó là NP-hard, nên mấy hệ thống chạy thật (production systems) xài mấy cái cỗ máy giải heuristic (heuristic solvers — kiểu như OR-Tools của Google) để đào ra mấy cái nghiệm gần ngon nhất (near-optimal solutions) trong giới hạn thời gian (time constraints).

Trò Ném Hàng Đoán Trước Của Amazon (Amazon Anticipatory Shipping) là gì và nó chạy ra sao?

Trò ném hàng đoán trước (được cấp bằng sáng chế với tên “ném hàng đoán trước - predictive shipping”) quăng đồ tọt vô mấy cái trung tâm chia chác theo vùng trước khi 1 ông khách chốt 1 cái đơn, dựa trên nhu cầu được ML dự đoán (ML-predicted demand). Mô hình dòm ngó (considers) cái thói quen đi dạo (browsing behavior), ba cái nhịp theo mùa của vùng (regional seasonal patterns), và mấy cái đơn đẻ lặp được lên lịch (scheduled repeat orders). Hễ mà cái dự đoán là chuẩn (correct), thì cái món đồ đó đã nằm sẵn ở trong khu đô thị (metro area) của ông khách, giúp giao hàng trong ngày hay sáng hôm sau (same-day or next-morning delivery) với giá tiền giao hàng bình thường (standard shipping cost).