Покупатель на бегу, в наушниках, с телефоном в одной руке — печатать точное название товара ему неудобно, а иногда он и не знает его. Он хочет произнести «беспроводные наушники с шумодавом до пяти тысяч» или сфотографировать понравившуюся вещь и получить похожие. Голосовой и мультимодальный поиск — это не модная игрушка, а способ снять барьер ввода и не потерять покупателя, который не смог сформулировать запрос текстом.
Разберёмся, как устроен голосовой и поиск по фото, что для этого нужно в интернет-магазине на 1С-Битрикс, при чём тут модуль «Поиск» и Sphinx, и почему успех этого канала на 90% зависит от качества данных каталога, а не от нейросети. Наведение порядка в данных и обмене — тема, которую мы закрываем через аудит и оптимизацию 1С.
Коротко
- Мультимодальный поиск принимает запрос голосом, фото или их сочетанием — барьер ввода ниже.
- Распознавание речи и изображений подключают как внешний сервис; дальше работает обычный поиск по каталогу.
- На больших каталогах поверх модуля «Поиск» ставят Sphinx для скорости и морфологии.
- Качество поиска определяют данные каталога и синонимы, а не сама модель распознавания.
Что такое мультимодальный поиск
Обычный поиск принимает один тип ввода — текст. Мультимодальный поиск снимает это ограничение: запрос можно задать голосом, изображением или комбинацией. Человек фотографирует товар и добавляет голосом «такой же, но дешевле» — система понимает и картинку, и уточнение. Смысл в том, чтобы покупатель выражал намерение так, как ему удобно в моменте, а не подстраивался под строку ввода.
Для интернет-магазина это в первую очередь способ не терять запросы, которые не превращаются в текст. Кто-то не знает, как называется деталь; кто-то видит вещь офлайн и хочет найти её онлайн; кому-то проще сказать, чем напечатать. Каждый такой сценарий — это покупатель, которого обычный поиск мог бы упустить.
Зачем магазину голос и фото
Ценность голосового и фото-поиска не абстрактна — она измеряется в снятых барьерах и сохранённых сессиях. Основные выгоды:
- Ниже барьер ввода. Не нужно знать точное название — достаточно сказать или показать.
- Мобильный сценарий. На телефоне голос и камера удобнее клавиатуры, особенно на ходу.
- Ловля «немых» запросов. Товар, который человек не смог описать словами, находится по фото.
- Скорость. Произнести запрос быстрее, чем набрать длинную фразу с характеристиками.
При этом важно трезво оценивать эффект. На небольшом каталоге с понятной номенклатурой выгода скромная, и деньги правильнее вложить в базовый поиск и фильтры. На крупном каталоге с мобильной аудиторией голос и фото дают ощутимый прирост. Решение принимают по данным, а не по моде.
Как устроен голосовой поиск
Голосовой поиск проще, чем кажется, потому что делится на два независимых этапа. Сначала речь превращается в текст, затем этот текст обрабатывается обычным поиском по каталогу.
- Захват речи. Пользователь нажимает микрофон, браузер записывает голос.
- Распознавание. Аудио отправляется во внешний сервис распознавания речи и возвращается текстом.
- Обработка запроса. Текст нормализуется, из него убираются вводные слова, выделяются значимые термины.
- Поиск по каталогу. Готовый текст уходит в модуль «Поиск» или Sphinx, как обычный запрос.
Ключевая мысль: голосовой поиск — это надстройка над текстовым, а не отдельная система. Распознавание можно вынести на сторону браузера или во внешний API, и тогда на 1С-Битрикс приходит уже готовый текст. Это делает интеграцию управляемой: вы не переписываете поиск, а добавляете новый способ ввода.
Поиск по изображению
Поиск по фото сложнее голосового, потому что изображение нельзя просто «превратить в текст». Здесь работает распознавание визуальных признаков: сервис анализирует фотографию и выдаёт набор характеристик или похожих объектов, которые затем сопоставляются с товарами каталога.
Реалистичный путь для большинства магазинов — использовать внешний сервис распознавания изображений, а на своей стороне держать сопоставление с номенклатурой. Для этого товарам нужны качественные изображения и структурированные характеристики: цвет, форма, категория. Чем богаче данные, тем точнее фото-поиск попадает в нужный товар. Собственная модель распознавания оправдана лишь на очень крупных и специфичных каталогах — это уже задача уровня автоматизации на 1С и серьёзной разработки.
Роль модуля «Поиск» и Sphinx
Что бы ни было на входе — голос, фото или текст, — в итоге запрос приходит к поисковому движку по каталогу. В 1С-Битрикс это штатный модуль «Поиск» на инфоблоках либо связка со Sphinx.
| Критерий | Модуль «Поиск» Битрикс | Sphinx |
|---|---|---|
| Размер каталога | Малый и средний | Крупный |
| Скорость на объёме | Падает на больших данных | Стабильно высокая |
| Морфология | Базовая | Гибкая, настраиваемая |
| Ранжирование | Ограниченное | Тонкая настройка |
| Внедрение | Из коробки | Отдельный сервис и индекс |
Для голосовых запросов, которые обычно длиннее и «живее» обычных, гибкость Sphinx особенно полезна. Но Sphinx — отдельный сервис, который нужно установить, индексировать и обслуживать. Устойчивую инфраструктуру под такой сервис мы разбирали в статье про хостинг и инфраструктуру для 1С-Битрикс.
Качество данных каталога решает всё
Самая частая иллюзия: «подключим распознавание — и поиск заработает». На деле распознавание отдаёт текст или признаки, а дальше всё упирается в данные каталога. Если у товаров скудные названия, пустые характеристики и нет описаний, найти по ним разговорный запрос невозможно, каким бы точным ни было распознавание речи.
Поэтому работа над мультимодальным поиском начинается не с нейросети, а с каталога: полные названия, заполненные свойства, корректные категории, качественные изображения. Данные приходят из учётной системы обменом, и их порядок — это в значительной степени вопрос корректной интеграции. Наведение порядка в номенклатуре и обмене мы делаем в рамках автоматизации продаж и склада на 1С.
Синонимы и разговорные запросы
Голос порождает запросы, каких не бывает в тексте: люди говорят разговорно, с лишними словами, местным сленгом и обиходными названиями. «Зарядка для айфона», «шуруповёрт», «краска в баллончике» — это не то, как товар назван в карточке. Мостом между речью и сухими полями каталога служат синонимы и обработка естественных формулировок.
- Словарь синонимов. Обиходные и профессиональные названия связываются с официальными наименованиями товаров.
- Стоп-слова. Вводные и незначащие слова из запроса отбрасываются.
- Морфология. Разные формы слова приводятся к одной, чтобы «наушников» и «наушники» находили одно.
- Опечатки распознавания. Сервис распознавания иногда ошибается — поиск должен быть терпим к небольшим искажениям.
Именно этот слой чаще всего недооценивают, а он определяет, превратится ли разговорный запрос в найденный товар. Без словаря синонимов голосовой поиск даёт много пустых выдач и разочаровывает пользователя.
Архитектура интеграции
С точки зрения инженерии мультимодальный поиск — это слой между пользователем и каталогом. Правильная архитектура держит его модульным и устойчивым:
- Ввод. Захват голоса или фото на стороне клиента.
- Распознавание. Вызов внешнего сервиса через API, с таймаутами и обработкой ошибок.
- Нормализация. Приведение результата к поисковому запросу: синонимы, стоп-слова, морфология.
- Поиск. Обращение к модулю «Поиск» или Sphinx поверх каталога на инфоблоках.
Обращения к внешним сервисам распознавания — это сетевые вызовы, которые могут падать и тормозить, поэтому их изолируют, ставят таймауты и предусматривают запасной путь (обычный текстовый ввод). Такую интеграцию строят по правилам работы с внешними API — вопросы безопасности и надёжности вызовов мы разбирали в статье про безопасность REST и вебхуков в 1С-Битрикс, а современный доступ к данным каталога — в материале про D7 и ORM в 1С-Битрикс.
Приватность и согласие
Голос и фотографии — чувствительные данные, и обращаться с ними нужно аккуратно. Пользователь должен понимать, что его запись уходит на распознавание, и осознанно давать согласие. Данные не стоит хранить дольше, чем требуется для обработки запроса, а при использовании внешнего сервиса важно понимать, где и как он обрабатывает информацию.
Практически это означает прозрачные формулировки в интерфейсе («нажимая микрофон, вы отправляете запись на распознавание»), отражение обработки в политике конфиденциальности и минимизацию хранения. Пренебрежение этим — не только репутационный, но и юридический риск.
Метрики успеха
Новый канал поиска нужно измерять, иначе непонятно, работает ли он. Ключевые метрики:
- Доля успешных поисков. Сколько запросов заканчивается переходом в карточку или заказом.
- Доля пустых выдач. Высокий процент — сигнал проблем с данными или синонимами.
- Конверсия из поиска в покупку. Отдельно по голосу, фото и тексту.
- Возвраты к обычному поиску. Если люди после голоса переключаются на текст — что-то не работает.
Сравнивая голосовые и фото-запросы с текстовыми, вы видите реальную отдачу канала и понимаете, куда вкладывать усилия — в распознавание, в данные или в синонимы.
Частые ошибки внедрения
- Начинают с нейросети, а не с данных. Распознавание идеально, а находить нечего — каталог пустой.
- Нет словаря синонимов. Разговорные запросы не связаны с официальными названиями, много пустых выдач.
- Монолитная интеграция. Распознавание и поиск слиты в одно — дорого поддерживать и легко сломать.
- Нет запасного пути. Сервис распознавания упал — и поиск не работает вообще.
- Игнорируют приватность. Голос и фото обрабатываются без согласия и прозрачности.
- Внедряют без метрик. Непонятно, приносит ли канал пользу и где он проваливается.
Чек-лист внедрения
- Каталог в порядке. Полные названия, заполненные характеристики, качественные изображения, корректные категории.
- Поиск усилен. На крупном каталоге — Sphinx поверх модуля «Поиск» с настроенной морфологией.
- Синонимы заведены. Обиходные и профессиональные названия связаны с номенклатурой.
- Распознавание подключено. Внешний сервис речи и изображений с таймаутами и обработкой ошибок.
- Запасной путь есть. При сбое распознавания доступен обычный текстовый ввод.
- Приватность учтена. Согласие, прозрачность, минимальное хранение данных.
- Метрики настроены. Успешность, пустые выдачи, конверсия по каждому типу ввода.
Вывод
Голосовой и мультимодальный поиск — это про снятие барьера ввода: покупатель выражает намерение голосом или фото, а не подбирает слова для строки поиска. Технически это надстройка над обычным поиском: распознавание отдаёт текст или признаки, а дальше работает модуль «Поиск» или Sphinx поверх каталога на инфоблоках.
Главный вывод: успех этого канала определяет не модель распознавания, а качество данных каталога и словарь синонимов. Начните с порядка в номенклатуре и обмене с 1С, добавьте синонимы, усильте поиск — и только потом подключайте голос и фото. Тогда новый способ ввода будет находить товары, а не выдавать пустоту.
