Поиск в приложении не прощает опечаток: как это ломает воронку
Пользователь вводит «кроссовки 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-исправления опечаток в поиске раскладывается на этапы с предсказуемой длительностью — от аудита поисковых запросов до выката на всю аудиторию. Ориентировочные сроки ниже даны для типового приложения со сложившейся поисковой выдачей; на итоговый план внедрения влияют объём логов запросов, число языков интерфейса и требования к приватности данных.
Длительность настройки зависит не столько от модели, сколько от качества разметки: если в логах много коротких запросов на смешанных языках, этап подготовки данных растягивается. План внедрения мы строим так, чтобы каждый этап давал проверяемый результат — после аудита видно, какую долю промахов закрывает исправление, после интеграции — как меняется доля успешных поисков.
Этапы идут с частичным перекрытием: подготовку данных можно начинать до завершения аудита, а тестирование — параллельно с дообучением. Поэтому суммарный срок внедрения обычно короче суммы этапов. Опишите вашу поисковую выдачу и объём логов — вернёмся с оценкой и планом под ваш случай.
