text: 0.7, image: 0.3, the system learns from clicks, purchases, and feedback to discover the optimal blend for every user — using Thompson Sampling (a multi-armed bandit algorithm) with hierarchical fallback from personal to demographic to global priors.
Auto-Tune closes the gap between “search works” and “search works for this user” without building a separate recommendation system.
How It Works
1
User searches
A query arrives with a
user_id. The system looks up that user’s learned fusion weights — or falls back to segment-level or global weights if the user is new.2
Results ranked by fusion weights
The feature search stage runs each embedding search and fuses results using the personalized weights. Early on, weights are exploratory (high variance). As data accumulates, they stabilize around what works for this user.
3
User interacts
The user clicks, purchases, skips, or provides feedback. Each interaction is recorded with the document ID, position, and the feature URI that produced the match.
4
Weights updated
Positive interactions (clicks, purchases) increase the weight of the feature that surfaced the result. Negative signals (skips, negative feedback) decrease it. Different interaction types carry different reward magnitudes — a purchase is a stronger signal than a click.
5
Next search reflects preferences
The next query from this user samples from the updated weight distributions. After dozens of interactions, the system converges on near-optimal weights while still occasionally exploring alternatives.
Quick Start
1. Create a retriever with learned fusion
2. Execute with a user ID
execution_id and each result contains a feature_id and feature_uri — you’ll use these in Step 3.
3. Post interactions — results automatically improve
When a user clicks, purchases, or otherwise engages with a result, post an interaction using thefeature_id and execution_id from the search response:
Python SDK shortcut —
create_interaction_from_result() extracts all the IDs for you:
user_456 returns results personalized to their feature preferences. If this user consistently engages with text-matched results over image-matched ones, the text feature weight increases for their queries.
Key Concepts
Reward Signals
Configure how different interaction types (clicks, purchases, feedback) influence learned fusion weights. Customize the reward map, handle negative signals, and tune temporal decay.
Rollout & Safety
Safely deploy learned fusion with traffic splitting, shadow mode, kill switches, per-user opt-out, and weight bounds. Includes a recommended rollout plan.
Interactions
How to capture clicks, purchases, and feedback that power the learning loop.
Evaluations
Measure whether learned fusion actually improves retrieval quality. Compare NDCG, precision, and recall against static fusion baselines.
Configuration Reference
Thelearning_config object is set inside the feature search stage parameters alongside fusion: "learned":
Every
learning_config field is optional — each has the default shown above. The only field you almost always set is context_features (so the system knows which INPUT.* field identifies a user). The minimal config in the quickstart (context_features + reward_map + min_interactions + exploration_bonus) is enough to get started; the rest are tuning knobs.Complete learning_config example
Every documented field, set to its default. Drop this into the feature search stage’s parameters (alongside fusion: "learned") and adjust only what you need — omitted fields fall back to these defaults:
Hierarchical Fallback
Not every user has enough interaction history for personalized weights. The system uses a four-level fallback:
The
context_features field controls personal-level resolution (typically ["INPUT.user_id"]). The demographic_features field enables segment-level fallback (e.g., ["INPUT.plan_tier"]).
Related
- Interactions — capturing the user behavior that powers learning
- Feature Search stage — where fusion and
learning_configare configured - Fusion Strategies — comparison of all 5 fusion strategies

