Optimizing Search Timeliness: From Feature Extraction to Ranking Models

Problem Definition

Timeliness in search is understood from both content and demand perspectives. Content timeliness reflects how information value decays over time, modeled as a half‑life where the information value drops to 50%. Demand timeliness measures how sensitive a query is to recent information; higher sensitivity means users expect newer results.

Types of Timeliness

Timeliness can be categorized into three groups based on the time distribution of queries: sudden, periodic, and generic. The article focuses on generic timeliness, where query time distribution is stable and similar to ordinary search queries.

Evaluation Standards

Timeliness satisfaction is scored on a 3‑point scale (0‑2) similar to overall satisfaction, with deductions applied for issues such as expired time (over 8 years), information loss, overly old results (over 5 years), mismatched timestamps, and non‑latest content. Additional rules handle time‑sensitive queries, video resources, dead links, and cases with no timeliness demand.

Overall Approach

The optimization follows four stages: rule improvement → model migration → abstract feature design → model iteration. Starting with basic feature optimization, the process moves to data labeling and model training for both ranking and timeliness.

Basic Feature Optimization

Web‑Time Extraction

Five timestamps are extracted from a page: content time, publish time, update time, discovery time, and first‑index time. A rule‑based selector chooses the most representative timestamp, preferring publish time for news, high‑confidence timestamps when inconsistencies exist, etc.

Time Sensitivity (Half‑Life)

The half‑life quantifies how quickly a page’s information decays. It is discretized into five levels via labeled data. Guidelines for labeling emphasize intuitive perception of timeliness rather than strict rules.

Time‑Sensitivity Models

Both pairwise and pointwise models are trained: the pairwise model provides fine‑grained scores for ranking, while the pointwise model outputs coarse categories (0, 1, 2, ≥3) used for pseudo‑feedback and query‑level sensitivity estimation.

Data Labeling

Timeliness optimization relies on labeled samples for Learning‑to‑Rank (LTR). Initially, timeliness was merged into the existing AC 5‑level label set, but low annotator agreement led to a separate timeliness satisfaction label. Annotators evaluate query intent, relevance, and timeliness satisfaction, assigning scores of 2 (excellent), 1 (average), or 0 (poor) plus additional categories for non‑relevant or dead links.

Ranking Model

A multi‑label LTR framework extends LightGBM to handle both AC and timeliness labels. Three algorithm versions were explored: (1) auxiliary loss when primary labels match, (2) label scaling to integrate timeliness into AC scores, and (3) weighting timeliness strongest on the middle AC tier. The final score blends the AC rank score and timeliness score using a dynamic λ:

RankScore = RankScoreAC * Lambda + RankScoreTimeliness * (1 - Lambda)

Lambda is computed from three sources: a rule‑based TriggerModel, a smoothed combination of TriggerModel output, and a multi‑objective fusion using IRGAN‑style adversarial training.

Recall Strategies

Recall combines generic retrieval with timeliness‑aware processing:

TimelinessTermWeightReadjust lowers the weight of time‑sensitive terms (e.g., "latest", "this year") in the inverted index.

TimelinessQueryRewrite rewrites queries by adding absolute time constraints.

Time‑limited queries filter results based on the query’s half‑life (e.g., only return results from the past week for a highly sensitive query).

Dedicated timeliness indexes store fresh content for fast recall of news‑type or strongly time‑sensitive pages.

Indexing and Collection

Timeliness collection consists of targeted seed‑page crawling for news, demand‑driven crawling of specific services, and a layered generic index that separates content by time sensitivity. This layered approach balances performance with the need for up‑to‑date results.

Key Diagrams