AI-оптимізація пошуку в мобільному додатку вирішує проблему коротких запитів, помилок та відсутності персоналізації. Стандартні текстові движки (BM25, TF-IDF) не справляються з короткими запитами, помилками та необхідністю персоналізації. Ми вирішуємо це завдання через комбінацію Learning to Rank (LTR), семантичного пошуку та адаптації видачі під кожного користувача. Оцінимо ваш проєкт і запропонуємо рішення під ключ. Ми маємо понад 5 років досвіду та 20+ впроваджень AI-пошуку.
Як AI-оптимізація пошуку в мобільному додатку вирішує проблему мобільного пошуку?
BM25 хороший на точних текстових збігах. Але мобільний пошук — це короткі запити («nike білі 42»), голосові запити з транскрипційними помилками. BM25 не розуміє семантику, дає нерелевантні результати. Друга проблема — персоналізація: запит «кросівки» для різних віків і статей повинен видавати різні топи. BM25 про це не знає. У результаті користувачі не знаходять потрібне, падає CTR та конверсія. Уявіть: користувач вводить «nike білі кросівки 42». BM25 поверне товари, де є всі слова, але не зрозуміє, що «білі» — колір, а «42» — розмір. AI-оптимізація пошуку вирішує це через семантичне розуміння та персоналізацію.
Як AI-оптимізація пошуку підвищує точність?
Ми використовуємо комбінацію BM25 (первинний retrieval), LTR (переранжування) та семантичних ембеддингів (розуміння сенсу). LTR-модель в 2-3 рази ефективніша за чистий BM25 у CTR@5. Згідно з нашими даними, LTR у 2-3 рази краще за BM25 за метрикою CTR@5. Процес включає:
- Аудит поточного пошукового движка — перевіряємо якість логування кліків, конверсій, час на сторінці.
- Feature engineering — збираємо ознаки: BM25 score, CTR, conversion rate, семантична близькість, афініті до категорії/бренду.
- Навчання LTR-моделі — використовуємо pairwise LightGBM з LambdaRank objective. Для навчання LTR ми використовуємо pairwise hinge loss з LambdaRank, що безпосередньо оптимізує NDCG@10. Навчаємо на історичних пошукових сесіях.
- Семантичний пошук — кодуємо запити та документи у вектори (BERT-ембеддинги), шукаємо через FAISS. Комбінуємо з BM25 через Reciprocal Rank Fusion.
- Інтеграція в мобільний додаток — деплоїмо модель на сервер, додаємо трекінг impressions/clicks в UI (SwiftUI / Jetpack Compose).
- A/B тест — порівнюємо з baseline BM25 за метриками CTR@5 та конверсії.
Таблиця: порівняння підходів LTR
| Метод | Принцип | Якість | Складність реалізації |
|---|---|---|---|
| Pointwise | Передбачення relevance score | Середня | Низька |
| Pairwise | Попарне порівняння документів | Висока | Середня |
| Listwise | Оптимізація метрик (NDCG) | Максимальна | Висока |
Pairwise — золота середина: дає приріст CTR@5 на 20‑40% і реалізується швидше listwise.
Приклад коду: Elasticsearch + ML ранжувальник
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 } ) 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] Чому семантичний пошук критичний для мобільних додатків?
Голосові запити, помилки, короткі фрази — ембеддинги розуміють сенс, а не тільки слова. Ми використовуємо Reciprocal Rank Fusion для об'єднання BM25 та семантичних результатів:
def reciprocal_rank_fusion(bm25_results: list, semantic_results: list, k=60) -> list: from collections import defaultdict 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) Згідно з нашими тестами, така комбінація підвищує залученість у 2-3 рази порівняно з чистим BM25.
З нашої практики: інтернет-магазин одягу
Після впровадження LTR+семантика CTR@5 виріс на 35%, конверсія з пошуку — на 18%. Досягнуто за 3 тижні.
Метрики AI-оптимізації пошуку
Офлайн-метрика NDCG@10 показує якість ранжування на історичних даних. Онлайн — CTR@5 (частка користувачів, які клікнули по топ-5 результатів) та конверсія з пошуку. Наші проєкти демонструють зростання CTR@5 мінімум на 20%.
Що входить у роботу
- Аудит поточного пошукового движка та логування
- Feature engineering та збір навчальних даних з пошукових сесій (від 10k подій)
- Розробка та навчання LTR-моделі (LightGBM) з pairwise-оптимізацією
- Впровадження семантичного пошуку (BERT ембеддинги + FAISS) з RRF
- Інтеграція у ваш Elasticsearch / мобільний додаток
- A/B тестування (мінімум 2 тижні) та звіт за метриками: NDCG@10, CTR@5, конверсія
- Документація та навчання команди з донавчання моделі
Орієнтири за термінами та вартістю
| Етап | Терміни | Вартість |
|---|---|---|
| BM25 + базові персоналізаційні фільтри | 1 тиждень | від $5,000 |
| LTR-ранжувальник з feature engineering | 3–4 тижні | від $7,000 до $15,000 |
| Семантичний пошук з FAISS + RRF fusion | +2 тижні | від $10,000 |
Середня вартість впровадження LTR становить $7,000–$15,000, що окупається за 2-3 місяці за рахунок зростання конверсії. Точні терміни та вартість розраховуємо після аудиту вашого проєкту.
Learning to Rank — детальніше про підхід. Семантичний пошук — детальніше про технологію.
Зв'яжіться з нами — оцінимо ваш пошук безкоштовно. Досвід: понад 5 років у мобільній розробці, 20+ впроваджень AI-пошуку, робота з додатками на мільйони користувачів. Гарантуємо приріст CTR@5 від 20%. Отримайте консультацію щодо вашого проєкту вже сьогодні.