Triển khai AI trong bán lẻ với Apache Cassandra và Apache Pulsar

Hành trình triển khai các giải pháp trí tuệ nhân tạo và học máy đòi hỏi phải giải quyết rất nhiều thách thức thường xuyên xuất hiện trong các hệ thống kỹ thuật số: cập nhật các hệ thống cũ, loại bỏ các quy trình hàng loạt và sử dụng các công nghệ đổi mới dựa trên AI/ML để cải thiện trải nghiệm của khách hàng trong những cách mà chỉ vài năm trước đây có vẻ giống như khoa học viễn tưởng.

Để minh họa cho sự phát triển này, chúng ta hãy theo dõi một nhà thầu giả định được thuê để giúp triển khai các giải pháp AI/ML tại một nhà bán lẻ lớn. Đây là bài đầu tiên trong loạt bài viết trình bày chi tiết các khía cạnh quan trọng của hành trình đến với AI/ML.

Vấn đề: Một quá trình hàng loạt giòn

Đây là ngày đầu tiên tại BigBoxCo trong nhóm “Cơ sở hạ tầng”. Sau khi hoàn thành các hoạt động nhân sự bắt buộc, tôi đã nhận được huy hiệu nhà thầu và lên đường đến không gian làm việc mới của mình.

Sau khi gặp nhóm, tôi được thông báo rằng chúng tôi có cuộc họp với nhóm “Đề xuất” sáng nay.

Quyền truy cập hệ thống của tôi vẫn chưa hoạt động tốt, vì vậy, hy vọng, bộ phận CNTT sẽ giải quyết vấn đề đó trong khi chúng ta đang họp.

Trong phòng họp, chỉ có vài người chúng tôi: quản lý của tôi và hai kỹ sư khác từ nhóm mới của tôi và một kỹ sư từ nhóm Đề xuất. Chúng tôi bắt đầu với một số lời giới thiệu và sau đó chuyển sang thảo luận về một vấn đề từ tuần trước.

Rõ ràng là tuần trước đã xảy ra một số đợt lỗi qua đêm và họ vẫn đang chịu ảnh hưởng của việc đó.

Có vẻ như các đề xuất sản phẩm hiện tại được thúc đẩy bởi dữ liệu được thu thập từ các đơn đặt hàng của khách hàng. Với mỗi đơn đặt hàng, có một mối liên hệ mới giữa các sản phẩm được đặt hàng và được ghi lại.

Khi khách hàng xem các trang sản phẩm, họ có thể nhận được các đề xuất dựa trên số lượng khách hàng khác đã mua sản phẩm hiện tại cùng với các sản phẩm khác.

Các đề xuất sản phẩm được cung cấp cho người dùng trên bigboxco.com thông qua một lớp vi dịch vụ trên đám mây. Lớp microservice sử dụng triển khai trung tâm dữ liệu (đám mây) cục bộ của Apache Cassandra để cung cấp kết quả.

Tuy nhiên, kết quả được thu thập và phục vụ như thế nào lại là một câu chuyện hoàn toàn khác. Về cơ bản, kết quả của sự liên kết giữa các sản phẩm (được mua cùng nhau) được tổng hợp trong một công việc MapReduce. Đây là quy trình hàng loạt đã thất bại vào tuần trước.

Mặc dù quy trình hàng loạt này chưa bao giờ nhanh, nhưng nó đã trở nên chậm hơn và dễ vỡ hơn theo thời gian. Trên thực tế, đôi khi quá trình này mất hai hoặc thậm chí ba ngày để chạy.

Cải thiện trải nghiệm

Sau cuộc họp, tôi kiểm tra máy tính của mình và có vẻ như cuối cùng tôi cũng có thể đăng nhập. Khi tôi đang nhìn xung quanh, kỹ sư chính (PE) của chúng tôi đi ngang qua và tự giới thiệu.

Tôi kể cho anh ấy nghe về cuộc họp với nhóm Đề xuất và anh ấy cho tôi biết thêm một chút về lịch sử đằng sau dịch vụ Đề xuất.

Có vẻ như quy trình hàng loạt đó đã được thực hiện trong khoảng 10 năm. Kỹ sư thiết kế nó đã chuyển đi, không nhiều người trong tổ chức thực sự hiểu nó và không ai muốn chạm vào nó.

Tôi bắt đầu giải thích về một vấn đề khác, đó là tập dữ liệu thúc đẩy mỗi đề xuất hầu như luôn có tuổi đời vài ngày.

Mặc dù đây có thể không phải là vấn đề lớn trong kế hoạch tổng thể, nhưng nếu dữ liệu đề xuất có thể được cập nhật hơn, thì nó sẽ có lợi cho các chương trình khuyến mãi ngắn hạn mà hoạt động tiếp thị thực hiện.

Anh ấy gật đầu đồng ý và nói rằng anh ấy chắc chắn sẵn sàng đón nhận các đề xuất về cách cải thiện hệ thống.

Có lẽ đó là một vấn đề đồ thị?

Khi bắt đầu, điều này đối với tôi giống như một vấn đề về đồ thị. Chúng tôi có những khách hàng đăng nhập vào trang web và mua sản phẩm. Trước đó, khi họ xem một sản phẩm hoặc thêm sản phẩm đó vào giỏ hàng, chúng tôi có thể hiển thị các đề xuất ở dạng “Khách hàng đã mua X cũng đã mua Y”.

Trang web có điều này ngày hôm nay, trong đó dịch vụ đề xuất thực hiện chính xác điều này: Nó trả về bốn sản phẩm bổ sung hàng đầu thường được mua cùng nhau.

Nhưng chúng tôi phải có cách nào đó để “xếp hạng” các sản phẩm bởi vì việc sắp xếp một sản phẩm với mọi sản phẩm khác được mua đồng thời bởi bất kỳ khách hàng nào trong số 200 triệu khách hàng của chúng tôi sẽ trở nên lớn và nhanh chóng.

Vì vậy, chúng ta có thể xếp hạng chúng theo số lần chúng xuất hiện trong một đơn hàng. Biểu đồ của hệ thống này có thể trông giống như những gì được hiển thị bên dưới trong Hình 1.

Sau khi lập mô hình này và chạy nó trên cơ sở dữ liệu đồ thị của chúng tôi với khối lượng dữ liệu thực, tôi nhanh chóng nhận ra rằng điều này sẽ không hiệu quả.

Quá trình truyền từ một sản phẩm đến khách hàng lân cận đến sản phẩm của họ và tính toán các sản phẩm xuất hiện nhiều nhất mất khoảng 10 giây.

Về cơ bản, chúng tôi đã “xử lý” vấn đề lô hai ngày, để mỗi lần tra cứu đặt độ trễ truyền tải chính xác ở nơi chúng tôi không muốn: trước mặt khách hàng.

Nhưng có lẽ, mô hình đồ thị đó không quá xa với những gì chúng ta cần làm ở đây? Trên thực tế, phương pháp được mô tả ở trên là một kỹ thuật máy học (ML) được gọi là “lọc cộng tác”.

Về cơ bản, lọc cộng tác là một phương pháp kiểm tra sự giống nhau của các đối tượng dữ liệu nhất định dựa trên hoạt động với những người dùng khác và nó cho phép chúng tôi đưa ra dự đoán dựa trên dữ liệu đó.

Trong trường hợp của chúng tôi, chúng tôi sẽ ngầm thu thập dữ liệu về giỏ hàng/đơn đặt hàng từ cơ sở khách hàng của mình và chúng tôi sẽ sử dụng dữ liệu đó để đưa ra các đề xuất sản phẩm tốt hơn nhằm tăng doanh số bán hàng trực tuyến.

Thực hiện

Trước hết, hãy xem xét việc thu thập dữ liệu. Việc thêm một cuộc gọi dịch vụ bổ sung vào chức năng “đặt hàng” mua sắm không phải là vấn đề quá to tát. Trên thực tế, nó đã tồn tại; chỉ là dữ liệu được lưu trữ trong cơ sở dữ liệu và được xử lý sau. Đừng nhầm lẫn: Chúng tôi vẫn muốn bao gồm quá trình xử lý hàng loạt.

Nhưng chúng tôi cũng sẽ muốn xử lý dữ liệu giỏ hàng đó trong thời gian thực, vì vậy chúng tôi có thể đưa dữ liệu đó trở lại tập dữ liệu trực tuyến và sử dụng dữ liệu đó ngay sau đó.

Chúng tôi sẽ bắt đầu bằng cách đưa vào một giải pháp phát trực tuyến sự kiện như Sao xung Apache . Bằng cách đó, tất cả hoạt động giỏ hàng mới được đặt trên một chủ đề sao xung , nơi nó được sử dụng và gửi đến cả cơ sở dữ liệu lô bên dưới cũng như để giúp đào tạo mô hình ML thời gian thực của chúng tôi.

Về phần sau, người tiêu dùng Pulsar của chúng tôi sẽ ghi vào bảng Cassandra (hiển thị trong Hình 2) được thiết kế đơn giản để giữ các mục nhập cho từng sản phẩm theo thứ tự. Sau đó, sản phẩm có một hàng cho tất cả các sản phẩm khác từ sản phẩm đó và các đơn đặt hàng khác:

 CREATE TABLE order_products_mapping ( id text, added_product_id text, cart_id uuid, qty int, PRIMARY KEY (id, added_product_id, cart_id) ) WITH CLUSTERING ORDER BY (added_product_id ASC, cart_id ASC); 

Sau đó, chúng tôi có thể truy vấn bảng này cho một sản phẩm cụ thể (“DSH915” trong ví dụ này), như sau:

 SELECT added_product_id, SUM(qty) FROm order_products_mapping WHERE id='DSH915' GROUP BY added_product_id; added_product_id | system.sum(qty) ------------------+----------------- APC30 | 7 ECJ112 | 1 LN355 | 2 LS534 | 4 RCE857 | 3 RSH2112 | 5 TSD925 | 1 (7 rows)

Sau đó, chúng tôi có thể lấy bốn kết quả hàng đầu và đưa chúng vào bảng đề xuất sản phẩm, sẵn sàng cho dịch vụ đề xuất truy vấn theo ` product_id `:

 SELECT * FROM product_recommendations WHERE product_id='DSH915'; product_id | tier | recommended_id | score ------------+------+----------------+------- DSH915 | 1 | APC30 | 7 DSH915 | 2 | RSH2112 | 5 DSH915 | 3 | LS534 | 4 DSH915 | 4 | RCE857 | 3 (4 rows)

Bằng cách này, dữ liệu đề xuất mới liên tục được cập nhật. Ngoài ra, tất cả các tài sản cơ sở hạ tầng được mô tả ở trên đều được đặt tại trung tâm dữ liệu cục bộ.

Do đó, quá trình lấy các mối quan hệ sản phẩm từ một đơn đặt hàng, gửi chúng qua chủ đề Pulsar và xử lý chúng thành các đề xuất được lưu trữ trong Cassandra diễn ra trong chưa đầy một giây.

Với mô hình dữ liệu đơn giản này, Cassandra có khả năng phục vụ các đề xuất được yêu cầu trong mili giây một chữ số.

Kết luận và các bước tiếp theo

Về lâu dài, chúng tôi muốn đảm bảo kiểm tra xem dữ liệu của chúng tôi được ghi vào bảng Cassandra như thế nào. Bằng cách này, chúng tôi có thể vượt qua các vấn đề tiềm ẩn liên quan đến những thứ như tăng trưởng hàng không liên kết và cập nhật tại chỗ.

Cũng có thể cần thêm một số bộ lọc heuristic bổ sung, chẳng hạn như danh sách “không khuyến nghị”.

Điều này là do có một số sản phẩm mà khách hàng của chúng tôi sẽ mua một lần hoặc không thường xuyên và việc giới thiệu những sản phẩm đó sẽ chỉ chiếm chỗ của các sản phẩm khác mà họ có nhiều khả năng mua theo cảm hứng.

Ví dụ: đề xuất mua thứ gì đó từ bộ phận thiết bị của chúng tôi, chẳng hạn như máy giặt, không có khả năng mang lại “mua hàng bốc đồng”.

Một cải tiến khác trong tương lai là triển khai nền tảng AI/ML thời gian thực như Kaskada để xử lý cả luồng quan hệ sản phẩm và trực tiếp cung cấp dữ liệu đề xuất cho dịch vụ.

May mắn thay, chúng tôi đã nghĩ ra một cách để tăng cường quy trình hàng loạt chậm chạp hiện có bằng cách sử dụng Pulsar để cung cấp các sự kiện thêm giỏ hàng được xử lý trong thời gian thực. Khi chúng tôi cảm nhận được hệ thống này hoạt động như thế nào trong thời gian dài, chúng tôi nên xem xét việc tắt quy trình hàng loạt cũ.

PE thừa nhận rằng chúng tôi đã đạt được tiến bộ tốt với giải pháp mới và tốt hơn nữa là chúng tôi cũng đã bắt đầu đặt nền móng để loại bỏ một số khoản nợ kỹ thuật. Cuối cùng, mọi người đều cảm thấy tốt về điều đó.

Trong bài viết sắp tới, chúng ta sẽ xem xét việc cải thiện quảng cáo sản phẩm bằng tìm kiếm vectơ .

Tìm hiểu cách DataStax kích hoạt AI thời gian thực

Bởi Aaron Ploetz, DataStax

Cũng được xuất bản ở đây