Implementing AI-Powered Search Ranking Optimization in Mobile Applications
Mobile app search underperforms web search not because of worse algorithms—but because of limited screen space. On mobile, users see 5–7 results without scrolling. If none are relevant, they close the app. Optimizing search ranking for mobile is doubly important.
What breaks in standard search engines
BM25 and TF-IDF work well for exact text matches. But mobile search is short queries ("nike white size 42"), voice queries with transcription errors, visual search. BM25 with these inputs gives irrelevant results because it doesn't understand semantics.
The second class of problems is personalization. A query for "sneakers" for a 28-year-old man and a 55-year-old woman should return different top results. BM25 knows nothing about this.
Learning to Rank: how AI ranking works
Three LTR approaches
Pointwise: train a model to predict relevance score for a (query, document) pair. Simple, but doesn't account for relative order in results.
Pairwise: model learns to order pairs of documents (A is better than B for query Q). RankNet, LambdaRank fall in this category.
Listwise: optimizes ranking quality metrics (NDCG, MAP) directly across the entire results list. Best quality, harder to implement.
For most mobile apps, the optimum is pairwise LightGBM with LambdaRank objective. Trained on search session logs: what users clicked, what they ignored.
Feature engineering for search ranker
@dataclass
class SearchRankingFeatures:
# Query-Document relevance
bm25_score: float
exact_match_title: bool
semantic_similarity: float # cosine between query and doc embeddings
# Document quality
click_through_rate: float # historical CTR from search
avg_session_time_after_click: float # time on card after click
conversion_rate: float # purchases / clicks from search
# User personalization
category_affinity: float # similarity to user's history
brand_affinity: float
price_range_match: bool # price in user's typical range
# Context
query_length: int
is_voice_query: bool
device_screen_dpi: int # for screen optimization
Elasticsearch + ML ranker
Elasticsearch is the standard primary retrieval engine. BM25 results from ES are passed to an ML ranker as candidates:
async def search(query: str, user: User, size: int = 20) -> list[SearchResult]:
# Stage 1: BM25 retrieval
es_results = await elasticsearch.search(
index="products",
body={
"query": {"multi_match": {"query": query, "fields": ["title^3", "description", "tags"]}},
"size": 100 # retrieve 100 candidates for reranking
}
)
candidates = [SearchResult.from_es(hit) for hit in es_results["hits"]["hits"]]
# Stage 2: ML reranking
features = extract_features(query, candidates, user)
scores = ranker.predict(features)
return sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)[:size]
Semantic search via embeddings
For semantic queries (not exact matches): query and documents are encoded into vectors, search for nearest neighbors via FAISS. Works well paired with BM25 through Reciprocal Rank Fusion:
def reciprocal_rank_fusion(bm25_results: list, semantic_results: list, k=60) -> list:
scores = defaultdict(float)
for rank, doc_id in enumerate(bm25_results):
scores[doc_id] += 1 / (k + rank + 1)
for rank, doc_id in enumerate(semantic_results):
scores[doc_id] += 1 / (k + rank + 1)
return sorted(scores, key=scores.get, reverse=True)
Mobile implementation: ranking UX
// iOS: display search results with skeleton loading
struct SearchResultsView: View {
@StateObject var viewModel: SearchViewModel
var body: some View {
List {
if viewModel.isLoading {
ForEach(0..<6) { _ in
SearchResultSkeletonRow()
}
} else {
ForEach(viewModel.results) { result in
SearchResultRow(result: result)
.onAppear {
viewModel.trackImpression(result.id)
}
.onTapGesture {
viewModel.trackClick(result.id)
navigateTo(result)
}
}
}
}
}
}
Tracking impressions and clicks directly in the UI provides data for training the next ranker version. Without this logging, the model degrades.
Process
Audit current search engine and click/conversion logging quality.
Feature engineering and collect training data from search sessions.
Train LTR model and offline evaluate on NDCG@10.
Deploy reranker behind Elasticsearch + mobile integration.
A/B test: LTR vs baseline BM25 → CTR@5 and conversion from search.
Timeline estimates
BM25 + basic personalization filters—1 week. LTR ranker with feature engineering—3–4 weeks. Semantic search with FAISS + RRF fusion—2 more weeks on top.