Ctrip Search Recommendation System Architecture and Evolution

Author Bio Ge Rongliang, senior R&D engineer in Ctrip's search department, joined Ctrip in 2015 and is responsible for front‑end and data mining work on the search platform.

1. Introduction With the rapid development of tourism, user expectations for search have become increasingly sophisticated, driving the need for intelligent, personalized recommendation systems.

Key challenges include:

User dimension: diverse needs such as local vs. non‑local, age, family structure.

Time and geography: seasonal preferences, time‑of‑day variations, city‑specific product demands.

Product dimension: delivering diverse offerings like hotels and attractions.

The article shares the iterative updates of Ctrip's recommendation system.

2. Recommendation System Architecture

The overall architecture is illustrated below:

Focusing on the service layer, the simplified structure is shown:

2.1 User Behavior Offline analysis of user actions and preferences helps generate recommendation sources for online products. Typically, one‑month or recent 7‑day data is used to ensure freshness.

2.2 Available Products Defines the set of products and articles that can be offered, including hotels, attractions, and other content, without limiting to strictly sellable items.

2.3 Recall

The core of the system, recall is divided into several strategies:

2.3.1 Supplementary Strategy Outputs currently hot products (e.g., seasonal hotels or attractions) to address cold‑start situations.

2.3.2 Location‑Based Recall Uses precise location to provide tailored results, such as local popular items, distinguishing between local and out‑of‑town demands, and recommending nearby products within a few kilometers.

2.3.3 Historical Association Strategy Leverages users' past behavior to suggest related items, e.g., recommending nearby hotels after a user books a theme‑park ticket.

2.3.4 Collaborative Filtering Applies classic item‑based collaborative filtering to compute similarity between products based on user interactions, using methods described in "Recommender Systems Practice".

2.4 Ranking After recall, a large set of candidates must be ordered. Early versions (1.0) used rule‑based sorting (category sales, recency weighting, rule scores). Later, a machine‑learning ranking model was introduced: features such as season, local vs. out‑of‑town, time‑of‑day were engineered, and XGBoost was trained on click and order data to score items from 1 to 5.

The model scores each recalled product in real time, and the results are periodically refreshed and iteratively improved via A/B testing.

2.5 Output Filtering Formats the final list, removes invalid or blacklisted items, and applies exposure controls to mitigate the Matthew effect, ensuring less‑popular products still receive some visibility.

3. Outlook The system is already deployed across multiple scenarios, but query analysis remains limited. Future work includes enriching product coverage, incorporating more advanced machine‑learning techniques, and adding deep‑learning components for intent detection and NLP‑driven analysis.

Join us on June 15 for the latest architecture practices from Baidu, Alibaba, and Ctrip.