Cách xây dựng công cụ đề xuất cơ bản mà không cần học máy

Hệ thống khuyến nghị đã trở thành một phần không thể thiếu trong cuộc sống của chúng ta. Những thuật toán thông minh này đóng vai trò then chốt trong việc định hình trải nghiệm trực tuyến của chúng ta, ảnh hưởng đến nội dung chúng ta xem, sản phẩm chúng ta mua và dịch vụ chúng ta khám phá. Cho dù chúng ta đang phát trực tuyến nội dung trên các nền tảng như Netflix , khám phá âm nhạc mới trên Spotify hay mua sắm trực tuyến, các hệ thống đề xuất vẫn âm thầm hoạt động ở hậu trường để cá nhân hóa và nâng cao khả năng tương tác của chúng ta.

Yếu tố độc đáo của các hệ thống đề xuất này là khả năng hiểu và dự đoán sở thích của chúng tôi dựa trên hành vi lịch sử và mẫu người dùng. Bằng cách phân tích các lựa chọn trước đây của chúng tôi, các hệ thống này sẽ đưa ra các đề xuất phù hợp, giúp chúng tôi tiết kiệm thời gian và công sức đồng thời giới thiệu cho chúng tôi nội dung/sản phẩm phù hợp với sở thích của chúng tôi. Điều này nâng cao sự hài lòng của người dùng và thúc đẩy khả năng khám phá, giới thiệu cho chúng tôi những dịch vụ mới và phù hợp mà chúng tôi có thể chưa gặp phải.

Ở cấp độ cao, các nhà phát triển hiểu rằng các thuật toán này được hỗ trợ bởi hệ thống học máy và học sâu (có thể gọi là mạng thần kinh), nhưng điều gì sẽ xảy ra nếu tôi nói với bạn rằng có một cách để xây dựng công cụ đề xuất mà không gặp khó khăn khi triển khai mạng thần kinh của bạn? mô hình net hay máy học?

Câu hỏi này đặc biệt phù hợp trong bối cảnh các công ty khởi nghiệp ở giai đoạn đầu và giữa vì họ không có nhiều dữ liệu có cấu trúc để đào tạo mô hình của mình. Và như chúng ta đã biết, hầu hết các mô hình học máy sẽ không đưa ra dự đoán chính xác nếu không có dữ liệu đào tạo phù hợp.

Gần đây tôi đã xây dựng và triển khai một công cụ đề xuất cơ bản cho một mạng xã hội đầu tiên bằng giọng nói , điều này đã khiến các chỉ số chính của chúng tôi tăng 40%. Tại thời điểm viết blog này, hệ thống đang tạo ra hơn 30 triệu đề xuất mỗi tháng. Mặc dù hệ thống đề xuất này được xây dựng cho mạng xã hội nhưng bạn có thể áp dụng kiến trúc cơ bản cho bất kỳ trường hợp sử dụng nào, chẳng hạn như đề xuất sản phẩm, đề xuất âm nhạc, đề xuất nội dung trên nền tảng văn bản và video hoặc bất kỳ nội dung nào khác. Hãy để tôi bắt đầu bằng cách mô tả báo cáo vấn đề.

Tuyên bố vấn đề từ góc độ kỹ thuật

Tôi đã có một cuộc họp rộng rãi tài liệu yêu cầu sản phẩm Và tài liệu yêu cầu kỹ thuật tiếp theo bởi vì chúng tôi đang xây dựng hệ thống đề xuất cho một sản phẩm đã được hàng nghìn người dùng sử dụng hàng ngày. Nhưng để giữ cho blog này ngắn gọn và đúng trọng tâm, tôi sẽ chỉ viết các yêu cầu cấp cao và sau đó thảo luận về giải pháp tương tự. Nếu bạn đang xây dựng một hệ thống đề xuất cho sản phẩm của mình (dựa trên mạng đơn giản hoặc dựa trên mạng thần kinh) và bị mắc kẹt ở đâu đó, vui lòng liên hệ với tôi theo số Twitter hoặc Linkedin , và tôi sẽ rất vui được trả lời câu hỏi của bạn.

Ở cấp độ cao, chúng tôi có các yêu cầu sau từ góc độ kỹ thuật -

1. Hệ thống sẽ có thể nắm bắt được sở thích của người dùng dưới dạng từ khóa. Hệ thống cũng có thể phân loại mức độ quan tâm của người dùng đối với các từ khóa cụ thể.

   
   

2. Hệ thống phải có khả năng nắm bắt được sự quan tâm của người dùng đối với những người dùng khác. Nó có thể phân loại mức độ quan tâm của người dùng đối với nội dung do người dùng khác tạo.

   
   

3. Hệ thống sẽ có thể tạo ra các đề xuất chất lượng cao dựa trên sở thích của người dùng.

   
   

4. Hệ thống phải có thể đảm bảo rằng các đề xuất đã được người dùng xem/từ chối sẽ không xuất hiện lại trong X số ngày.

   
   

5. Hệ thống phải có logic để đảm bảo rằng các bài đăng của cùng một người sáng tạo không được nhóm trên cùng một trang. Hệ thống nên cố gắng hết sức để đảm bảo rằng nếu người dùng xem mười bài đăng (kích thước trang của chúng tôi), thì tất cả những bài đăng đó phải đến từ những người sáng tạo khác nhau.

   
   

6. Hệ thống phải nhanh. Độ trễ P99 dưới 150 mili giây.

   
   

7. Tất cả các yêu cầu phi chức năng khác, chẳng hạn như tính sẵn sàng cao, khả năng mở rộng, bảo mật, độ tin cậy, khả năng bảo trì, v.v., phải được đáp ứng.

   
   

Một lần nữa, đây là một danh sách các báo cáo vấn đề được đơn giản hóa quá mức. Trên thực tế, các tài liệu dài hơn 3000 từ vì chúng cũng bao gồm rất nhiều trường hợp phức tạp và các trường hợp góc có thể phát sinh khi tích hợp công cụ đề xuất này vào các hệ thống hiện có của chúng tôi. Hãy chuyển sang giải pháp.

Giải pháp - Công cụ đề xuất hoạt động ở mức độ cao

Tôi sẽ thảo luận từng giải pháp cho vấn đề và sau đó sẽ mô tả hoạt động tổng thể của toàn bộ hệ thống.

Vấn đề đầu tiên của chúng ta là nắm bắt được sở thích của người dùng và xác định mức độ quan tâm của họ với một sở thích cụ thể

Để làm được điều này, chúng tôi đã tạo ra một thứ gọi là biểu đồ xã hội . Nói một cách đơn giản, biểu đồ xã hội lưu trữ các mối quan hệ và kết nối giữa các thực thể khác nhau trong mạng xã hội. Những thực thể này có thể là những người dùng khác nhau hoặc mối quan hệ của những người dùng có mối quan tâm cụ thể. Đồ thị xã hội là một cách mạnh mẽ để hiểu và cấu trúc các mối quan hệ trong một hệ thống cụ thể. Để ngắn gọn, tôi sẽ không giải thích chi tiết về biểu đồ xã hội nhưng tôi sẽ khuyên bạn nên google và tìm hiểu thêm về nó. Sau đây là phiên bản đơn giản của biểu đồ xã hội mà tôi đã xây dựng cho công cụ đề xuất của mình.

Như bạn có thể thấy từ hình ảnh trên, chúng tôi đang lưu trữ rất nhiều thông tin, chẳng hạn như số lượng tương tác (thích, nhận xét, chia sẻ) và mức độ gần đây của những tương tác này (khi chúng xảy ra lần cuối) cũng như dữ liệu về mối quan hệ giữa hai người dùng giữa một người dùng và một mối quan tâm. Chúng tôi thậm chí còn lưu trữ mối quan hệ giữa hai từ khóa sở thích khác nhau. tôi đã sử dụng Sao Hải Vương Amazon , cơ sở dữ liệu biểu đồ được quản lý bởi AWS, để lưu trữ biểu đồ xã hội này. Bạn có thể sử dụng bất kỳ cơ sở dữ liệu đồ thị nào khác, chẳng hạn như Neo4j, JanusGraph, ArrangoDB , v.v.

Những từ khóa quan tâm này chủ yếu là danh từ. Có một hệ thống chia nhỏ nội dung của bài đăng thành các từ khóa (danh từ) này. Nó được hỗ trợ bởi AWS; dịch vụ xử lý ngôn ngữ tự nhiên (NLP) sử dụng máy học để chia văn bản thành các thực thể, cụm từ khóa, v.v. Một lần nữa, bạn có thể sử dụng bất kỳ dịch vụ NLP được quản lý nào (một số dịch vụ có sẵn) để thực hiện điều tương tự. Bạn không cần phải tìm hiểu hoặc triển khai các mô hình học máy của mình! Nếu bạn đã hiểu về học máy thì bạn có thể kiểm tra các mô hình NLP nguồn mở cũng như trên Huggingface .

Vấn đề thứ hai của chúng tôi là tạo ra các đề xuất chất lượng cao dựa trên sở thích của người dùng

Sơ đồ sau đây là sự trình bày ở cấp độ cao được đơn giản hóa về cách hệ thống hoạt động.

Mặc dù những điều trên có vẻ dễ dàng nhưng còn có rất nhiều điều khác diễn ra ở mỗi bước và những điều đó phải được suy nghĩ kỹ lưỡng rồi lập trình để đảm bảo hệ thống hoạt động tối ưu.

Hãy để tôi giải thích từng bước:

Bước 1 - Chuyển đổi nội dung bài đăng thành dạng nhúng vector

Để tạo ra những đề xuất này, trước tiên, chúng tôi phải chuyển đổi nội dung của bài đăng thành thứ gọi là - nhúng vector . Với sự gia tăng gần đây trong việc xây dựng thương hiệu LLM, OpenAI (nhà sản xuất ChatGPT) và Cơ sở dữ liệu vectơ , Việc nhúng Vector đang trở thành một thuật ngữ hàng ngày. Tôi sẽ không đi sâu vào chi tiết chúng là gì và chúng hoạt động như thế nào, nhưng tôi thực sự khuyên bạn nên đọc thêm về chúng. Tuy nhiên, việc tạo ra các ứng cử viên khả thi cho nguồn cấp dữ liệu cũng phải tính đến những thứ như quyền riêng tư và kiểm duyệt nội dung (xóa các từ tục tĩu, lạm dụng, nội dung khiêu dâm, quấy rối, lọc người dùng bị chặn, v.v.).

Để tạo các phần nhúng vectơ, bạn có thể sử dụng bất kỳ mô hình nhúng nổi bật nào, chẳng hạn như mô hình nhúng OpenAI , Amazon titan hoặc bất kỳ mô hình nhúng văn bản nguồn mở nào, tùy thuộc vào trường hợp sử dụng của bạn. Chúng tôi chọn Amazon Titan vì giá cả thân thiện, hiệu suất và khả năng vận hành dễ dàng.

Bước 2 - Truy vấn sở thích của người dùng

Bây giờ, đây là nơi mọi thứ trở nên thú vị. Bạn sẽ muốn thiết kế các truy vấn dựa trên nhu cầu kinh doanh cụ thể của mình. Ví dụ: chúng tôi đánh giá cao mức độ tương tác gần đây trong khi truy vấn sở thích hơn số lượng tương tác với một từ khóa hoặc người dùng cụ thể. Chúng tôi cũng chạy nhiều truy vấn song song để tìm các loại sở thích khác nhau của người dùng - từ khóa hoặc người dùng khác. Vì chúng tôi tạo nhiều nguồn cấp dữ liệu cho một người dùng nên chúng tôi cũng chạy một số truy vấn quảng cáo một chủ đề cụ thể theo xu hướng (ví dụ: bạn sẽ thấy nhiều bài đăng liên quan đến Giáng sinh gần Giáng sinh hoặc các bài đăng liên quan đến động đất nếu trận động đất nào đó đã xảy ra). Không cần phải nói, chủ đề này sẽ chỉ xuất hiện trong kết quả truy vấn nếu người dùng bày tỏ sự quan tâm đến họ trong hành trình của họ.

Vì vậy, hãy chọn logic phù hợp với trường hợp sử dụng kinh doanh của bạn cũng như hành vi mà bạn muốn thúc đẩy và chạy nhiều truy vấn để có được danh sách đủ lớn về tất cả sở thích của người dùng.

Bước 3 - Thực hiện tìm kiếm ANN dựa trên sở thích được tìm thấy

Cơ sở dữ liệu vectơ chủ yếu được sử dụng để thực hiện một loại tìm kiếm cụ thể được gọi là Tìm kiếm hàng xóm gần nhất gần đúng (ANN). Một lần nữa, cách bạn phân loại các sở thích khác nhau và việc bạn đang thực hiện một tìm kiếm ANN lớn hay tìm kiếm khác biệt song song hoàn toàn phải dựa trên trường hợp sử dụng và yêu cầu kinh doanh của bạn. Tôi khuyên bạn nên thực hiện nhiều hơn các tìm kiếm dựa trên nhóm và sau đó sắp xếp các kết quả (chúng ta sẽ thảo luận vấn đề này sau trong blog này) để có trải nghiệm tốt nhất cho người dùng cuối. Trong trường hợp này, công việc tìm kiếm ANN thực hiện là tìm các bài đăng khác trên nền tảng tương tự (gần hơn) với sở thích của người dùng.

Bước 4 - Lưu trữ kết quả vào cơ sở dữ liệu bộ đệm theo thứ tự.

Cache cơ sở dữ liệu vì một trong những vấn đề mà chúng ta cần giải quyết là tốc độ. Chúng tôi đã sử dụng các bộ được sắp xếp lại để lưu trữ ID duy nhất của bài đăng cho một người dùng cụ thể. Chúng tôi đã sử dụng các bộ được sắp xếp lại vì thứ tự các bài đăng trong nguồn cấp dữ liệu của người dùng là rất quan trọng. Ngoài ra, một vấn đề khác mà bạn phải giải quyết là “ hệ thống phải có logic để đảm bảo rằng các bài đăng của cùng một người sáng tạo không được nhóm trên cùng một trang”. Để tránh lặp lại nội dung của cùng một người sáng tạo, chúng tôi đã viết một thuật toán đơn giản để đảm bảo rằng nếu bài đăng của một người sáng tạo cụ thể được chèn vào bất kỳ vị trí nào trong nguồn cấp dữ liệu của một người dùng cụ thể (bộ đã sắp xếp), chúng tôi sẽ không chèn một bài đăng khác từ cùng một người sáng tạo cho mười vị trí liên tiếp (chúng tôi có kích thước trang là 10 trong khi phân phát nguồn cấp dữ liệu cho người dùng cuối, vì vậy chúng tôi giữ nó ở trạng thái tĩnh để tránh phức tạp).

Để quyết định thứ tự của một đề xuất cụ thể của người dùng, chúng tôi đã tính đến những điều sau -

1. Sức mạnh của mối quan hệ với sở thích cụ thể (hoặc người dùng khác) đối với người dùng này : Nó được xác định bằng công thức số học lấy nhiều điểm dữ liệu khác nhau từ biểu đồ xã hội. Tất cả những điều này đều là dữ liệu tương tác như dấu thời gian của lượt thích cuối cùng được tạo, số lượt thích được tạo, nhận xét cuối cùng, v.v. Hành vi tương tác của người dùng là dấu hiệu cho thấy họ quan tâm đến điều gì đó.

   
   

2. Mức độ phổ biến của bài đăng trên nền tảng: Để xác định điều này, chúng tôi đã tạo một thuật toán lấy nhiều yếu tố khác nhau như mức độ tương tác, tỷ lệ tương tác trên hiển thị, số lượng người dùng duy nhất đã tương tác, v.v. để tạo ra điểm tương tác đó đăng ở cấp độ nền tảng.

   
   

Trong một số nguồn cấp dữ liệu, chúng tôi ưu tiên mức độ phổ biến; ở những nơi khác, chúng tôi ưu tiên biểu đồ xã hội. Nhưng chủ yếu, tất cả chúng đều là sự kết hợp lành mạnh của cả hai.

Hệ thống hoạt động như thế nào

Như bạn có thể thấy từ sơ đồ trên, hệ thống đã được cố tình giữ rất đơn giản. Sau đây là cách hệ thống hoạt động -

1. Khi người dùng A tạo một bài đăng, dịch vụ bưu chính, sau khi lưu bài đăng đó, sẽ kích hoạt một sự kiện pub/sub vào hàng đợi, sự kiện này sẽ được nhận bởi một dịch vụ nền dành cho việc tạo ứng viên. Chúng tôi sử dụng Google Pub/Sub cho chức năng pub/sub.

   
   

2. Dịch vụ nền này nhận thông tin này một cách không đồng bộ và thực hiện các chức năng được thảo luận trước đó - Kiểm tra quyền riêng tư, kiểm tra kiểm duyệt và tạo từ khóa, sau đó tạo các phần nhúng vectơ và lưu trữ chúng trong cơ sở dữ liệu vectơ. Chúng tôi đang sử dụng AstraDB làm cơ sở dữ liệu vectơ của chúng tôi (thảo luận sau).

   
   

3. Bất cứ khi nào người dùng tương tác (thích/bình luận/chia sẻ, v.v.) sau khi cập nhật cơ sở dữ liệu NoSQL chính của chúng tôi, dịch vụ hậu kỳ sẽ kích hoạt một sự kiện pub/sub cho dịch vụ công cụ đề xuất.

   
   

4. Dịch vụ công cụ đề xuất này cập nhật cơ sở dữ liệu biểu đồ và sau đó cập nhật nguồn cấp dữ liệu được đề xuất của người dùng trong thời gian gần thực bằng cách thực hiện tìm kiếm ANN và cập nhật cơ sở dữ liệu Redis. Vì vậy, càng nhiều người dùng tương tác thì nguồn cấp dữ liệu càng trở nên tốt hơn. Có các bước kiểm tra để đảm bảo rằng các đề xuất không thiên về một danh sách từ khóa cụ thể . Những kiểm tra đó được thực hiện trong khi chúng tôi truy vấn cơ sở dữ liệu Đồ thị. Dịch vụ này cũng cập nhật điểm tương tác không đồng bộ. Điểm tương tác cũng được tính lại đối với người dùng xem bài đăng.

   
   

5. Vì tất cả các bước trên được thực hiện không đồng bộ ở hậu trường nên những tính toán này không ảnh hưởng đến trải nghiệm của người dùng cuối.

   
   

6. Nguồn cấp dữ liệu cuối cùng được cung cấp cho người dùng cuối thông qua dịch vụ nguồn cấp dữ liệu. Vì dịch vụ này chỉ thực hiện tra cứu trên redis và cơ sở dữ liệu NoSQL chính của chúng tôi ( DyanmoDB ), độ trễ P99 của nó nhỏ hơn 110 mili giây. Cả hai cơ sở dữ liệu này đều trả về kết quả truy vấn với độ trễ một phần nghìn giây bất kể quy mô.

Công cụ và công nghệ được sử dụng

1. Một số dịch vụ đã được viết bằng Đi ngôn ngữ lập trình , trong khi những người khác đã được viết bằng NodeJS (có bản đánh máy).

   
   

2. Chúng tôi đang sử dụng AstraDB của Datastax như cơ sở dữ liệu vector của chúng tôi. Chúng tôi đi đến quyết định này sau khi đánh giá nhiều cơ sở dữ liệu khác, chẳng hạn như Pinecone, Milvus và Weaviate . Ngoài khả năng truy vấn và lập chỉ mục tuyệt vời trên vectơ và các loại dữ liệu khác, nó còn cung cấp gói giá không có máy chủ thân thiện với túi tiền. Nó chạy trên công cụ Cassandra mà chúng tôi sử dụng làm cơ sở dữ liệu trong một số tính năng khác trên nền tảng của mình và nó cung cấp giao diện truy vấn CQL rất thân thiện với nhà phát triển. Tôi thực sự khuyên bạn nên thử nó cho các trường hợp sử dụng vector của bạn.

   
   

3. Chúng tôi sử dụng Nhà xuất bản/phụ của Google dành cho giao tiếp không đồng bộ của chúng tôi vì ở quy mô hiện tại của chúng tôi (tổng số vài vạn người dùng, vài nghìn người dùng hoạt động hàng ngày), nó có hiệu quả cao về mặt chi phí. Tôi đã chạy nó ở quy mô vài vạn người dùng với hàng nghìn sự kiện mỗi giây. Nó hoạt động tốt, dễ dàng sử dụng và mở rộng.

   
   

4. Làm lại - Tốc độ, đơn giản và cấu trúc dữ liệu mạnh mẽ. Tôi không nghĩ mình cần phải thảo luận tại sao lại thực hiện lại vào năm 2024.

   
   

5. DynamoDB - Một lần nữa, nó có khả năng mở rộng cao và dễ sử dụng, đồng thời chúng tôi chạy nó ở chế độ không có máy chủ, mặc dù có hàng trăm nghìn truy vấn mỗi phút nhưng tổng chi phí của chúng tôi khá thấp. Nó cũng cung cấp khả năng lập chỉ mục rất mạnh mẽ và độ trễ một phần nghìn giây khi đọc và ghi.

Những vấn đề cần giải quyết trong tương lai

Như bạn có thể tưởng tượng, thiết lập tương tự này có thể được điều chỉnh để xây dựng công cụ đề xuất cơ bản cho mọi trường hợp sử dụng. Tuy nhiên, vì mạng của chúng tôi là mạng xã hội nên chúng tôi sẽ yêu cầu một số điều chỉnh về sau để hệ thống này hoạt động hiệu quả hơn.

1. Sẽ cần đến các thuật toán học máy/học sâu ở cấp độ biểu đồ xã hội để dự đoán các từ khóa và người dùng phù hợp nhất với người dùng. Hiện tại, tập dữ liệu quá nhỏ để có thể dự đoán chính xác bất cứ điều gì vì đây là một sản phẩm rất mới. Tuy nhiên, khi dữ liệu tăng lên, chúng ta sẽ cần thay thế các truy vấn và công thức đơn giản hiện tại bằng đầu ra của thuật toán học máy.

   
   

2. Mối quan hệ giữa các từ khóa khác nhau và người dùng phải được tinh chỉnh và chi tiết hơn. Hiện tại họ đang ở một đẳng cấp rất cao. Nhưng họ sẽ cần phải sâu sắc hơn. Trước tiên, chúng tôi sẽ cần khám phá các mối quan hệ cấp độ thứ hai và cấp độ thứ ba trong biểu đồ của mình để tinh chỉnh các đề xuất.

   
   

3. Hiện tại, chúng tôi không thực hiện bất kỳ tinh chỉnh nào trong các mô hình nhúng của mình. Chúng ta sẽ cần phải làm điều đó trong thời gian tới.

Ghi chú kết thúc

Tôi hy vọng bạn thấy blog này hữu ích. Nếu bạn có bất kỳ câu hỏi, nghi ngờ hoặc đề xuất nào, xin vui lòng liên hệ với tôi trên Twitter , Linkedin hoặc Instagram . Hãy chia sẻ bài viết này với bạn bè và đồng nghiệp của bạn.