Reweights ranking-signal contributions per query so each query class (news, transactional, navigational, informational) gets the signal mix it benefits from, rather than applying one universal ranking formula across the entire query distribution.
Patent Overview
- Filed
- 2013-11-15
- Granted
- 2015-12-22
- Application Number
- US 14/081,540
The Challenge
The Challenge
A single global ranking formula treats every query identically. But different queries need different signal mixes: news queries reward freshness, navigational queries reward exact-match, transactional queries reward commerce signals. One formula is structurally suboptimal across the spectrum.
- Universal Formula Cannot Optimize All Queries — Tuning a single formula to do well on news hurts informational; tuning to do well on transactional hurts navigational. No setting wins everywhere.
- Query Type Predicts Signal Importance — News queries weight freshness heavily; reference queries weight authority and depth; transactional queries weight commerce and reviews. The right weighting depends on the query type.
- Query Classification Must Be Fast — Classification runs in the query path before ranking. It cannot add significant latency or every query pays the cost regardless of benefit.
- Class Boundaries Are Soft — Queries do not fall cleanly into one type. The system must support fractional class membership and smooth signal-weight interpolation across classes.
- Ranking Model Must Stay Tractable — Per-class signal weights multiply the model complexity. Engineering must keep training and inference tractable as classes proliferate.
Innovation
How The System Works
The system classifies each query into a soft mixture over query classes, looks up per-class signal weights from a learned table, blends weights according to class membership, applies the blended weights to the ranking signals, and produces the ranked results.
- Define Query Classes — Editorial process plus log mining defines query classes: news, navigational, transactional, informational, locational, image-seeking, video-seeking. Each class has known signal-weight preferences.
- Train Query Classifier — A learned model classifies incoming queries into a soft mixture over the defined classes. Training data comes from labeled queries plus click-pattern proxies.
- Learn Per-Class Signal Weights — For each class, learn the signal weights that produce the best ranking outcomes. Training uses labeled relevance data per class so the weights are class-optimal.
- Classify Incoming Query — At query time, classify the query into its class mixture. Output is a probability distribution over classes.
- Blend Signal Weights — Blend the per-class weight vectors using the class probabilities. Output is a query-specific weight vector that optimizes the expected outcome.
- Apply Blended Weights To Ranking — The ranker scores candidates using the blended weights. The result is a ranking shaped by what the query actually needs.
- Continuously Learn From Outcomes — Click and dwell signals reveal whether the ranking served the user. Outcomes feed back into per-class weight learning so the system improves over time.
Per-Query Signal Mix
The patent's load-bearing idea is that one ranking formula cannot serve all queries optimally. Per-query signal-mix tuning unlocks ranking quality the universal formula cannot reach.
Different Queries Want Different Signals
Freshness matters intensely for news, almost not at all for reference. Tuning the weight per query class lets each query type benefit from its most-predictive signals.
- Query Class Mixture — Each query is a soft mixture over classes. The mixture captures the query's blend of characteristics.
- Per-Class Weight Vectors — Each class has a weight vector optimized for that class. Learning uses class-specific relevance data.
- Blended Application — The query-specific weight vector is a blend of per-class vectors according to class membership. Ranking uses the blended weights.
Technical Foundation
Technical Foundation
The patent specifies the query class taxonomy, the classifier model, the per-class weight learning, and the integration with the ranking pipeline.
- Query Class Taxonomy — A hierarchical taxonomy defines classes (news, navigational, etc.) and their relationships. New classes can be added as new query patterns emerge.
- Soft Classifier Model — A neural or logistic classifier outputs class probabilities. Soft classification handles ambiguous queries without forcing hard categorization.
- Per-Class Weight Tables — For each class, a vector of signal weights is stored. Tables update as per-class weight learning produces improvements.
- Weight Blending Logic — Query-specific weights are a probability-weighted sum of per-class weight vectors. The blend is computed in microseconds.
- Ranking Integration — The ranker accepts the blended weight vector and applies it to candidate signals. Implementation reuses the existing ranking infrastructure with weights as a configurable input.
- Feedback-Driven Weight Updates — Click outcomes per query class feed back into the weight-learning pipeline. Periodic refresh keeps weights aligned with current user expectations.
The Process
The Process
The pipeline runs in the query path. Classification and blending add microseconds; the rest of the ranking is the standard path with input-tuned weights.
- Receive Query — Query arrives at the dispatcher. Classification runs immediately.
- Classify Into Class Mixture — The classifier outputs class probabilities. Output is the query's class signature.
- Blend Weight Vectors — Per-class weight vectors are blended according to class probabilities. Result is the query-specific weight vector.
- Retrieve Candidates — Standard retrieval produces the candidate set. Candidates carry their signal values.
- Score With Blended Weights — Each candidate's score is the dot product of its signals with the blended weights. Highest-scoring candidates rise.
- Render Results — Top-scoring candidates render in the SERP. The user sees results shaped by their query's specific needs.
- Log Outcomes For Learning — Click and dwell signals tagged by class feed back into the weight-learning pipeline.
Quality Control
Quality Control
Per-class weighting risks misclassification cascading into bad rankings. The patent specifies safeguards.
- Classifier Calibration — Probabilities are calibrated against empirical class distribution. Wrong calibration would lead to consistent misweighting.
- Weight Vector Bounds — Per-class weights are bounded so no single class can produce wildly out-of-distribution weight vectors. Robustness to classifier errors.
- Multi-Class Hedging — Ambiguous queries (high uncertainty across classes) get hedged weight vectors that produce reasonable rankings across the spectrum, not aggressive specialization.
- Per-Class Outcome Monitoring — Click outcomes by class are monitored. Sudden quality drops in a class flag investigations into classifier drift or weight regression.
- Rollback Path — Per-class weight updates can be rolled back independently. Bad updates in one class do not pollute others.
Real-World Application
Query-dependent ranking is a core part of modern Google ranking. Its descendants drive QDF (Query Deserves Freshness), per-vertical scoring, and the specialization layers behind shopping, image, and video result modes.
- Per-class Weight Tuning — Each query class has its own weight vector. The blend per query produces ranking tuned to the query's actual needs.
- Soft mixture Classification Approach — Queries are soft-classified so ambiguous cases get hedged weights rather than forced hard categorization.
- Continuous Weight Learning — Outcomes feed back continuously into the weight-learning pipeline. Per-class weights stay aligned with current user expectations.
Why Audit Each Query By Intent Class
SEO that ignores query type optimizes for the average query, which exists for almost no real query. Audit your target queries by class first, then prioritize the signals each class rewards. This is a direct mapping of the patent's ranking logic into content strategy.
Why One Page Cannot Serve Multiple Intents
A page that hedges across informational and transactional intent weakens its signal in both classes. Splitting intent-mixed pages into class-specific pages, with internal links between, almost always outperforms cramming.
<\/section>What This Means for SEO
What This Means for SEO
When ranking factors weight differently for different queries, an SEO checklist that ignores query type is just optimizing for the average query.
- Query Type Sets The Factor Weights — A transactional query weights different signals than an informational query. Audit each target query by intent and prioritize the signals that matter for that intent type.
- Freshness, Authority, And Depth Trade Off Per Query — A news query rewards freshness, a reference query rewards authority and depth. Aligning your content shape to the query is a stronger lever than universal best-practices.
- One Page Cannot Serve Many Query Types Well — Combining transactional and informational intent on one page weakens it for both. Splitting them, and linking between, almost always outperforms cramming.