Github: Gorse recommendation engine

In the recommendation system, data is the support of all recommendation results. This article will briefly introduce how to collect user data and submit it to Gorse recommendation system. Recommendation systems mainly rely on behavioral feedback between users and objects as training data, and the quality of training data determines the quality of recommendation.

Users, objects, feedback

The recommendation system is actually a relatively complex system, but in order to maximize reuse, Gorse classifies the data sources in the recommendation system into a collection of three entities: users, items and feedback.

• User: A user consists of a user ID and a label describing the user. The user label can be empty, but the label information helps improve the recommendation accuracy of the recommendation system.

type User struct {
    UserId    string
    Labels    []string
}
Copy the code

• Item: Item is composed of item ID, item time stamp and label describing the item. The timestamp and label can be empty. Similarly, label information helps improve the recommendation accuracy of the recommendation system, while the timestamp is used to judge the freshness of the item.

type Item struct {
    ItemId    string
    Timestamp time.Time
    Labels    []string
}
Copy the code

• Feedback: A feedback message consists of the user ID, item ID, feedback type, and feedback timestamp. The triplet of user ID, item ID, and feedback type must be unique in the database.

Feedback refers to some events generated between the user and the item, which can be positive or negative. For example, sharing, liking and so on all belong to the positive feedback of the user on the item. If there is no further positive feedback after the user reads, the user’s feedback on the item is considered to be negative. Gorse does not directly provide the concept of negative feedback but the concept of read feedback. If the user views the item, record a read feedback. Then, if the user gives the item positive feedback, the read feedback is overwritten by the positive feedback. Conversely, if the user gives no positive feedback, the read feedback is considered negative.

type Feedback struct {
    FeedbackType string
    UserId       string
    ItemId       string
    Timestamp    time.Time
}
Copy the code

The Gorse service node provides apis for inserting users, items, and feedback, as well as obtaining user recommendations through the API. For details about the APIS, see the RESTful API documentation.

Identify positive and read feedback

Before submitting feedback to the Gorse recommendation system, you need to determine which user actions are positive and which are read. Read feedback is relatively easy to determine, when the user sees the recommended item, it can be recorded as read feedback. However, the determination of positive feedback depends more on specific business scenarios. For Douyin, users’ likes or shares can be regarded as positive feedback. For Bilibili, when users watch a video and reach a certain degree of completion or like, share or favorites, it is considered as positive feedback. To sum up, the determination of positive feedback and read feedback follows the following rules:

• Read Feedback: The user sees the item.
• Positive feedback: Actions that the user is expected to take.

For example, if much Newell to build a Steam game recommendation system based on Gorse, you can click on the game page as read feedback (too little game list page information, can’t judge the user has read), and then will join the wish list, add to cart as positive feedback, in the configuration file is set as follows.

Positive_feedback_types = ["wish_list"."cart"Read_feedback_types = ["read"]
Copy the code

Insert positive feedback

For positive feedback, it can be inserted when the user performs relevant operations, where the timestamp is the current time point.

curl -X POST "http://127.0.0.1:8088/api/feedback" \
    -H "accept: application/json" \
    -H "Content-Type: application/json" \
    -d '[{" FeedbackType ":" read ", "ItemId" : "10086", "Timestamp" : "the 2021-10-24 T06: observe. 207 z", "UserId" : "jack"}]'
Copy the code

Insert read feedback

For read feedback, timestamps can be used to set the life cycle of the recommendation results in addition to recording the read time.

Take the initiative to insert

Forward feedback can be inserted into the recommendation system when the user takes action, while read feedback requires the application to detect the user’s “read” behavior. The methods used by various applications to present recommendation results vary, but can be generally grouped into two categories:

• Full screen view: The most typical app is Tiktok, which is considered “read” when only one item is shown to the user. In other words, the application can write a “read” feedback to the recommendation system when it is presented to the user, and the read content will no longer be shown to the user.

• Information flow view: The most typical application is Taobao, when the user sees multiple items in the list, it is not considered “read”. When there are a lot of recommendations, the user’s attention won’t be able to read all the content. Also, if the read content is quickly discarded in the information flow view, the recommended content will be consumed too quickly. Therefore, the best solution is to write a read feedback of the future timestamp to the recommendation system when the item is presented to the user in the form of information flow. When the time reaches the timestamp, the read feedback takes effect and the read content is no longer shown to the user.

Automatic insertion

Actively inserting read feedback into the recommendation system requires the application to accurately capture user browsing behavior. This task is relatively easy for mobile applications, but difficult for simple Web applications. To solve this problem, The Gorse API for obtaining the recommended result provides write−back typewrite-back-Typewrite −back−type and write−back−delaywrite-back-delaywrite−back−delay parameters.

• Full screen view: Take a recommendation and write “read” feedback. The recommendation does not appear again.

curl -X GET "Http://172.18.0.3:8087/api/recommend/zhenghaoz? write-back-type=read&n=1" \
    -H "accept: application/json" \
    -H "X-API-Key: 19260817"
Copy the code

• Flow view: Take ten recommendations and write “read” feedback, stamped 10 minutes later. The 10 recommendations are discarded after 10 minutes.

curl -X GET "Http://172.18.0.3:8087/api/recommend/zhenghaoz? write-back-type=read&write-back-delay=10&n=10" \
    -H "accept: application/json" \
    -H "X-API-Key: 19260817"
Copy the code

Recommended Result Write − Back − Typewrite -back- Typewrite −back−type and Write −back−delaywrite-back-delaywrite−back− Delay provide convenient read records. To ensure accurate read feedback, the application side should write the data to the recommendation system.