Пошук у застосунку не прощає одруків: як це ламає воронку
Користувач вводить «кросівки nike air max 90», промахується на одну клавішу — «nike air maz 90» — і отримує екран «Нічого не знайдено». Він не стане виправляти запит: закриває пошук, гортає категорії або йде в інший застосунок.
Одна одруківка в пошуковому запиті обриває шлях до замовлення на найдорожчій ділянці воронки, де користувач уже знає, що хоче купити.
Ціна цього збою видна в метриках: частка порожніх видач зростає на довгих запитах із брендами та артикулами, а конверсія пошуку в застосунку падає в рази порівняно із запитами без помилок.
При цьому пошук формально працює — індекс відповідає, інтерфейс не падає, у логах немає жодної помилки. Проблема не у відмові інфраструктури, а в тому, що пошуковий шар не вміє зіставляти введення користувача з реальним каталогом.
AI виправлення одруків у пошуку закриває цю прогалину: модель на льоту розпізнає спотворене слово, підбирає найімовірніший товарний запит і віддає релевантну видачу замість порожнього екрана.
Якість пошуку мобільного застосунку перестає залежати від акуратності набору на маленькій клавіатурі — а саме там помиляється більшість користувачів.
Далі розбираємо, як це влаштовано: які типи помилок ловимо, де проходить межа між виправленням і підміною запиту, і як вимірюємо ефект на воронку.
Як працює AI виправлення одруків у пошуку і що змінюється
Режими виправлення: від підстановки до мовної моделі
Базовий рівень — словникова правка за відстанню редагування: запит звіряється з індексом популярних формулювань, і при розходженні в 1-2 символи підставляється найближчий варіант. Це дешево і передбачувано, але ламається на злитих і транслітерованих запитах.
Фонетичне зіставлення закриває цей клас: «айфон» і «iphone» приводяться до спільного звукового коду і знаходять одне одного, навіть якщо написані різними алфавітами.
Нечіткий пошук працює не замість, а поверх: він не переписує запит, а розширює видачу — токени з одруками все одно беруть участь у ранжуванні, і користувач бачить результати без порожнього екрана.
Мовна модель для пошуку підключається на останньому шарі і вирішує те, що правилами не описати: відновлює сенс за контекстом фрази, розрізняє «кофе» і «кофта» при схожому написанні, підказує продовження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Словникова правка | Каталог з усталеними назвами, стабільний словник запитів | Не тягне злиті і транслітеровані введення |
| Фонетичне зіставлення | Мультимовна аудиторія, бренди та імена | Хибні спрацьовування на коротких словах |
| Нечіткий пошук | Довгий хвіст запитів, широкий асортимент | Зростає навантаження на пошуковий індекс |
| Мовна модель | Розмовні та складені запити | Потрібна розмітка і регулярна переоцінка |
Метрики якості пошуку знімаємо до і після: частка запитів з нульовою видачею, частка переходів у картку з першої п'ятірки результатів, частка повторних уточнень запиту. За ними видно, чи пішов клас відмов, чи правка просто переставила результати.
Шари вмикаємо по одному і порівнюємо на одному й тому ж зрізі запитів — інакше ефект не відокремити від сезонності.
Elasticsearch
Етапи впровадження виправлення одруків у пошук застосунку
Впровадження AI-виправлення одруків починається не з моделі, а з даних: без реальних запитів користувачів будь-яка схема залишається здогадкою.
Тому перший крок — вивантажити пошукові логи за період, достатній для покриття сезонних сплесків, і подивитися, яка частка запитів закінчується нульовою видачею.
Зазвичай саме там ховаються одруки, трансліт і злитно написані слова — користувач не отримує нічого і йде із застосунку.
Далі робота йде за етапами, кожен з яких закінчується перевірюваним артефактом.
- Аудит пошукових запитів. Розбираємо логи: частотні запити, частка порожніх видач, типові спотворення — пропущені та переставлені символи, зайві, розкладка не в тій мовній схемі. На виході — зріз проблемних запитів з оцінкою, скільки трафіку вони зачіпають.
- Проєктування схеми виправлення одруків. Визначаємо, де вносити правку: на вході в пошук, на рівні індексу або як підказку «можливо, ви мали на увазі». Обираємо поріг спрацювання, щоб не підміняти рідкісні, але коректні запити — інакше пошук почне «виправляти» назви товарів і брендів.
- Налаштування нечіткого пошуку. Підключаємо відстань редагування та фонетичне порівняння, налаштовуємо словник винятків для назв з каталогу. Перевіряємо на історичних запитах: скільки одруків закривається автоматично, скільки йде в підказку.
- Перевірка якості пошуку. Рахуємо частку запитів з непорожньою релевантною видачею до і після, дивимося на позицію потрібного результату. Окремо перевіряємо, що коректні запити не почали переписуватися — це головний ризик при агресивних порогах.
- Передача рішення замовнику. Віддаємо налаштовану схему, словники, конфігурацію порогів і метрики якості, щоб команда могла супроводжувати пошук без нас.
Ключовий момент — етап перевірки: без нього виправлення одруків легко перетворюється на джерело нових помилок. Ми проганяємо обидва зрізи на одному наборі запитів, щоб ефект був вимірюваним, а не відчутним. Опишіть вашу задачу — повернемося з оцінкою та планом за цими етапами.
Чим нечіткий пошук відрізняється від виправлення одруківок?
Нечіткий пошук і виправлення одруківок розв'язують різні задачі, хоча на рівні користувача виглядають однаково — «знайшлося те, що я мав на увазі».
Нечіткий пошук розширює область збігу: запит порівнюється з індексом за відстанню редагування, фонетичними ключами або векторною близькістю, і у видачу потрапляють схожі рядки.
Виправлення одруківок працює інакше — воно спочатку приводить запит до гаданого правильного вигляду, а вже потім шукає за ним. Різниця підходів проявляється в момент, коли запит не містить помилки, але й точного збігу в каталозі немає.
Нечіткий пошук підвищує повноту: він витягує товари та статті, які користувач інакше не побачив би. Плата за це — падіння точності. За слабкого порогу у видачу лізуть далекі за змістом позиції, і людина гортає список, не довіряючи результату.
За жорсткого порогу частина реальних одруківок не ловиться, і повнота повертається до рівня звичайного пошуку.
Виправлення одруківок працює на точність: запит «наушники беспроводные» після нормалізації перетворюється на «наушники беспроводные», і пошук іде за чистою формулюванням. Тут ризик інший — хибне спрацювання.
Якщо алгоритм «виправить» назву бренду, артикул або рідкісний термін, користувач отримає видачу за запитом, якого не задавав, і втратить довіру до пошуку сильніше, ніж від порожньої сторінки.
На практиці підходи комбінують у конвеєрі. Спочатку запит проходить нормалізацію та виправлення одруківок за словником і частотними парами — так прибирається шум. Потім за очищеним запитом запускається нечіткий пошук з керованим порогом, щоб добрати близькі позиції.
Поріг підбирається за метриками: частка запитів без результату, частка переходів із видачі, частка уточнень запиту. Тільки за цими числами видно, де закінчується корисна повнота і починається сміття.
Для мобільного застосунку це критично: екран вузький, користувач не гортає довгі списки й іде після першої невдалої видачі.
Тому виправлення одруківок тримають консервативним — воно не повинно змінювати запити, які вже дають результат, — а нечіткий пошук вмикають другим шаром з обмеженням за кількістю кандидатів.
Кейс: як виправлення одруків підвищило конверсію пошуку
Клієнт — сервіс із каталогом на десятки тисяч позицій і пошуком, який тримає основну частину замовлень. Аналітика показувала: помітна частка запитів закінчувалася порожньою видачею або переходом на другий-третій екран.
Причина виявилася не в релевантності, а в одруках і розкладці — користувач набирає «айфон чекхол», система шукає точний збіг і видає нуль. Кожен такий запит — втрачене замовлення, яке ніхто не бачить у звітах, бо формально пошук «відпрацював».
Що було до впровадження
Ми зняли зріз за логами за кілька тижнів: частка успішних запитів трималася близько 71%, порожні видачі — порядку 18% від усіх звернень до пошуку, ще частина користувачів отримувала результати, але не знаходила потрібне й ішла. Конверсія пошуку в замовлення — 4,2%.
Окремо рахували частку запитів з ознаками одруку або змішаної розкладки: вона виявилася вищою, ніж припускала команда, і зростала на мобільних, де клавіатура частіше промахується.
Що змінили
Впровадили шар AI-виправлення одруків перед движком пошуку: модель приводить запит до словникової форми, враховує розкладку й фонетичну близькість, а рішення про виправлення ухвалює лише за достатньої впевненості — інакше запит іде як є, щоб не підміняти рідкісні, але валідні назви.
Виправлений варіант не підміняє вихідний: користувач бачить «Можливо, ви шукали…» і може повернутися до свого варіанта.
Паралельно додали логування пар «запит → виправлення → результат», щоб бачити, де модель помиляється. Це дало керований контур: спірні випадки потрапляють на розбір, словник поповнюється, якість зростає без перенавчання з нуля.
Що стало
| Метрика | До | Після |
|---|---|---|
| Частка успішних запитів | ~71% | ~89% |
| Порожні видачі | ~18% | ~6% |
| Конверсія пошуку в замовлення | 4,2% | 5,6% |
| Частка запитів з виправленням | — | ~14% |
Зростання конверсії пошуку дало приріст до замовлень без змін у каталозі та цінах — ефект прийшов із уже наявного трафіку. Порожні видачі перестали бути «тихою» зоною втрат: їх видно в моніторингу і можна розбирати точково.
Elasticsearch використовували як движок пошуку, а шар виправлення поставили перед ним — так рішення не залежить від внутрішньої логіки пошуку і переноситься на інший стек.
Сумніви щодо сумісності, міграції та доступів — обговоримо задачу
Основне сумнів замовника звучить так: «у нас уже працює пошук, і він нас влаштовує — чи не зламає його AI виправлення друкарських помилок». Відповідаємо по суті: шар виправлення друкарських помилок ставиться перед поточним пошуковим движком і не замінює його.
Запит проходить через нормалізацію, виправлений варіант іде в наявний індекс, а якщо впевненість моделі нижча за поріг — пошук відпрацьовує за вихідним рядком, як раніше.
Сумісність із поточним пошуком зберігається на рівні контракту запиту, тому переписувати логіку видачі не потрібно.
Що якщо індекс доведеться перебудовувати? Міграція пошукового індексу йде паралельно: новий індекс збирається поруч зі старим, трафік перемикається після звірки видачі на контрольній вибірці запитів.
Відкат змін — це перемикання назад на попередній індекс, а не відновлення з бекапу, тому займає хвилини. Доступи до даних видаємо за принципом мінімально необхідного: сервіс виправлення бачить лише пошукові рядки, без прив'язки до облікових записів та історії замовлень.
Чи можна впровадити виправлення друкарських помилок без зупинки пошуку?
Так. Шар працює в режимі спостереження: спочатку він лише логує, які запити виправив би, і ми звіряємо це з реальною видачею. Перемикання на бойовий режим — окремий крок з миттєвим відкатом. Користувач не помічає жодного простою.
На руки після впровадження замовник отримує:
- конфігурації шару виправлення з порогами впевненості та правилами обходу;
- схему проходження запиту від введення до видачі з точками логування;
- політику доступу до пошукових даних та розмежування ролей;
- регламент міграції індексу та процедуру відкату з критеріями спрацювання;
- документацію з пошуку: словники, правила нормалізації, метрики якості;
- дашборд із часткою виправлених запитів та зростанням успішних переходів.
Опишіть вашу поточну схему пошуку та обмеження щодо доступів — повернемося з оцінкою та планом впровадження.
Терміни впровадження виправлення одруків за етапами
Впровадження AI-виправлення одруків у пошуку розкладається на етапи з передбачуваною тривалістю — від аудиту пошукових запитів до викату на всю аудиторію.
Орієнтовні терміни нижче наведено для типового застосунку з усталеною пошуковою видачею; на підсумковий план впровадження впливають обсяг логів запитів, кількість мов інтерфейсу та вимоги до приватності даних.
Тривалість налаштування залежить не стільки від моделі, скільки від якості розмітки: якщо в логах багато коротких запитів змішаними мовами, етап підготовки даних розтягується.
План впровадження ми будуємо так, щоб кожен етап давав перевірюваний результат — після аудиту видно, яку частку промахів закриває виправлення, після інтеграції — як змінюється частка успішних пошуків.
Етапи йдуть із частковим перекриттям: підготовку даних можна починати до завершення аудиту, а тестування — паралельно з донавчанням. Тому сумарний термін впровадження зазвичай коротший за суму етапів. Опишіть вашу пошукову видачу та обсяг логів — повернемося з оцінкою та планом під ваш випадок.
