Как AI учится понимать опечатки и синонимы в поиске

Покупатель набирает «фен дайсон» с опечаткой, путает раскладку или называет товар так, как привык в разговоре, и получает пустую страницу, хотя нужная позиция есть на складе. Для бизнеса это прямая потеря заказа: не найдя товар через поиск, человек чаще уходит, чем идет листать каталог вручную.

Живой язык плохо ложится на логику точного совпадения строки, на которой построено большинство стандартных поисковых движков. Решает это умный поиск с AI: чтобы понять нечеткий запрос, такая система выполняет три разные задачи — исправляет ошибки ввода, распознает смысл за непривычной формулировкой и выстраивает выдачу в осмысленном порядке. Ниже разобрано, что стоит за каждым из этих слоев и почему по отдельности они не работают.

Почему «точный поиск» ломается на реальных запросах

Стандартный поиск рассчитывает, что пользователь введет запрос ровно так, как товар записан в каталоге. На практике это допущение нарушается почти всегда. Запросы приходят с опечатками, с незакрытой раскладкой (lfqcjy вместо «дайсон»), в транслите, с разговорными сокращениями и в произвольной грамматической форме. Для движка, который сравнивает строки по точному вхождению, любое такое отклонение означает «совпадений не найдено».

Причина техническая, но понятная. Запрос вида LIKE ‘%…%’ проверяет наличие конкретной последовательности символов, а не близость к ней. Одной перепутанной буквы достаточно, чтобы товар, лежащий в базе, стал недоступен покупателю. Чем крупнее каталог, тем дороже обходится каждая такая осечка.

По данным бенчмарка Baymard Institute (2024), 72% протестированных e-commerce-сайтов не поддерживают хотя бы один из распространенных типов поисковых запросов. Доля запросов с нулевой выдачей по разным оценкам составляет от 5 до 15%, и заметная их часть приходится не на отсутствие товара, а на неспособность движка распознать формулировку.

Управленцу важно отличать проблему движка от проблемы каталога. Запросы с очевидными опечатками, не дающие результата, указывают на движок. Осмысленные запросы по несуществующим позициям говорят о пробелах в ассортименте или в товарных описаниях. Разводит эти случаи анализ логов поиска.

Как алгоритм исправляет искажения, не зная заранее правильного слова

Главная трудность в том, что система не знает заранее, что пользователь хотел написать, и сравнивать с эталоном ей не с чем. Поэтому она оценивает, насколько введенная строка близка к словам, которые уже есть в каталоге. Чем меньше «расстояние» между запросом и кандидатом, тем выше шанс, что это и есть искомый товар.

На практике движок опирается на несколько механизмов, каждый из которых закрывает свой тип искажения:

• Расстояние Левенштейна считает, сколько односимвольных правок (вставить, удалить или заменить букву) нужно, чтобы превратить одно слово в другое. «Крассовки» и «кроссовки» отличаются на одно такое действие, и алгоритм это распознает.
• Фонетические алгоритмы сравнивают слова по звучанию, а не по написанию. Это выручает, когда покупатель пишет название на слух.
• Триграммный (n-граммный) разбор режет слово на короткие куски по три буквы и сравнивает наборы таких кусков. Одна ошибка портит лишь часть фрагментов, а не все сопоставление целиком, поэтому метод устойчив к опечаткам.
• Обратное преобразование раскладки понимает, что «lfqcjy» — это «дайсон», набранный в латинской раскладке, и переводит его в кириллицу еще до поиска.
• Транслитерация сводит к одному виду варианты вроде «xiaomi» и «сяоми».

У этих методов есть четкая граница. Они хорошо чинят механические искажения в написании, но работают с формой слова, а не с его значением. Если покупатель написал правильное, но непривычное название товара, коррекция букв уже не поможет, и в дело вступает следующий слой.

От букв к смыслу, и почему без ранжирования это все не работает

Исправить символы — это только начало. Часто покупатель называет товар иначе, чем он заведен в каталоге: пишет «стиралка» вместо «стиральной машины» или описывает потребность словами, например «подарок на новоселье». Слова написаны верно, расходится смысл, и формальная коррекция здесь бессильна.

Простейшее решение — словари синонимов, где альтернативные названия вручную привязаны к основным. Они надежны, но плохо масштабируются, потому что каждый новый вариант приходится добавлять руками. Более гибкий путь — семантический поиск. Он переводит слова в числовые векторы так, что близкие по смыслу формулировки оказываются рядом, и это позволяет связать «подарок на новоселье» с посудой, текстилем или декором, хотя ни в одном из этих товаров нет слова «подарок».

Но даже правильно найденный набор товаров еще не результат. По широкому запросу движок может вернуть сотни релевантных позиций, и от порядка их вывода зависит, увидит ли покупатель то, что купит. Ранжирование учитывает соответствие запросу, популярность, наличие на складе и коммерческие приоритеты магазина. Поиск, который точно понял запрос, но показал нужный товар на третьем экране, на практике мало чем отличается от поиска, который ничего не нашел: до этой позиции покупатель просто не дойдет.

Отсюда практический вывод: оценивать поиск стоит не по отдельным удачным запросам, а по нескольким измеримым показателям. Имеет смысл выгрузить долю запросов с нулевой выдачей, частые запросы без переходов на товар и среднее время отклика строки. Эти цифры показывают, на каком слое (коррекция, смысл или ранжирование) теряются продажи.

Что с этим делать бизнесу

Понимание опечаток и синонимов держится на трех связанных слоях: исправление искажений в написании, распознавание смысла за непривычной формулировкой и ранжирование выдачи. Слабое звено в любом из них обесценивает работу двух других.

Практический вопрос не в том, нужен ли умный поиск, а в том, что выгоднее делать самим, а что брать готовым. Базовую коррекцию опечаток реально собрать своими силами. Семантический поиск и обучаемое ранжирование требуют данных, инфраструктуры и постоянной доработки, которые для отдельного магазина окупаются редко. Разумный первый шаг — снять метрики своего поиска (нулевые выдачи, запросы без кликов, скорость отклика) и по ним понять, какой слой проседает сильнее всего. Этот замер и подскажет, стоит ли вкладываться в собственную разработку или проще подключить внешнее решение.