Голосовой поиск и поиск по фото в каталоге на 1С-Битрикс

Покупатель всё чаще приходит в магазин не с клавиатурой, а с телефоном в руке и в движении. Он хочет продиктовать запрос голосом, пока едет или готовит, или сфотографировать понравившуюся вещь и сказать «найди мне такое же». Классическая строка поиска для таких сценариев неудобна: набирать текст на маленьком экране медленно, а описать словами внешний вид товара, название которого покупатель не знает, — вообще почти невозможно. Отсюда растёт интерес к двум механикам: голосовому поиску и поиску по фото (визуальному поиску) прямо в каталоге интернет-магазина.

В этой статье разберём обе механики трезво, без хайпа и обещаний «искусственного интеллекта, который решит все проблемы». Посмотрим, как голосовой поиск устроен на уровне браузера (Web Speech API), почему он на самом деле сводится к обычному текстовому поиску и в каких сценариях реально полезен. Разберём, что происходит при поиске по картинке: как изображение превращается в эмбеддинг, что такое векторный поиск и как подбираются похожие товары. Обсудим сценарии применения — от моды до автозапчастей, — архитектуру внедрения на 1С-Битрикс (фронтенд-виджет, бэкенд-обработчик, внешний ML-сервис), качество распознавания и ложные срабатывания, приватность, стоимость и, главное, когда всё это оправдано, а когда преждевременно. Материал — из практики нашей работы по разработке сайтов с умным поиском на 1С-Битрикс.

Что такое голосовой и визуальный поиск

Начнём с определений, потому что вокруг этих терминов много путаницы. Голосовой поиск — это способ задать поисковый запрос голосом вместо набора текста. Покупатель нажимает на иконку микрофона, произносит фразу, система распознаёт речь и превращает её в текст, а дальше этот текст идёт в обычный поиск по сайту. Ключевое здесь: голосовой поиск не «понимает» товары как-то по-особому, он лишь меняет способ ввода. Всё, что происходит после распознавания, — это тот же самый текстовый поиск по каталогу, о котором мы подробно писали в статье про поиск по сайту и Sphinx.

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

Есть и промежуточный вариант — распознавание текста на фото (например, штрихкода, артикула на упаковке или ценника). Технически это ближе к обычному поиску: с картинки считывается код или строка, и дальше идёт точный поиск по каталогу. Такой сценарий проще и надёжнее полноценного визуального поиска, и о нём стоит помнить как о «дешёвом» ответвлении темы: если покупателю нужно просто отсканировать штрихкод, полноценная модель компьютерного зрения избыточна.

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

Голосовой поиск: как он работает

Разберём путь голосового запроса по шагам. Он короче и понятнее, чем кажется, и почти весь укладывается в браузер покупателя.

1. Запрос доступа к микрофону. Покупатель нажимает иконку микрофона в строке поиска. Браузер спрашивает разрешение на доступ к микрофону — это обязательный шаг, инициированный действием человека.
2. Захват речи. Пользователь произносит фразу: «чёрные кроссовки сорок второй размер». Браузер записывает звук.
3. Распознавание речи в текст. Механизм распознавания (в браузере, часто с помощью облака платформы) превращает звук в строку текста. Магазин получает готовый текст, а не аудио.
4. Очистка и передача в поиск. Распознанный текст при необходимости слегка чистят (убирают лишние слова, знаки) и отдают в обычный поиск по каталогу.
5. Обычная выдача. Дальше работает штатный поиск: морфология, синонимы, ранжирование — и покупатель видит привычную страницу результатов.

Из этой схемы видно главное следствие: качество голосового поиска на 80% определяется качеством обычного текстового поиска. Если распознанный текст «чёрные кроссовки 42 размер» ваш поиск и так находит хорошо — голос будет работать отлично. Если текстовый поиск на такой запрос выдаёт пустоту, голос ничего не улучшит. Поэтому голосовой поиск не имеет смысла внедрять раньше, чем настроен нормальный поиск по каталогу.

Web Speech API в браузере

Техническая основа голосового поиска в вебе — это Web Speech API, а точнее его часть, отвечающая за распознавание речи (интерфейс SpeechRecognition). Это встроенная возможность современных браузеров: страница просит доступ к микрофону, запускает распознавание и получает обратно текст. Магазину не нужно самому писать нейросеть для распознавания речи — эту работу берёт на себя браузер и платформа устройства.

Что делает браузер

Когда страница запускает распознавание, браузер захватывает звук с микрофона и передаёт его своему механизму распознавания. У части браузеров этот механизм облачный — звук отправляется на серверы платформы (например, экосистемы браузера), там превращается в текст и возвращается обратно. Это важный момент для приватности, о котором ниже: технически звук может покидать устройство, и пользователя об этом стоит предупреждать.

Что важно на практике

• Поддержка неоднородна. Web Speech API хорошо поддержан в мобильных браузерах на распространённых платформах, но не везде одинаково. В части десктопных браузеров распознавание либо отсутствует, либо ограничено. Поэтому кнопку микрофона показывают только там, где API доступен, а не всем подряд.
• Нужен HTTPS. Доступ к микрофону браузер даёт только на защищённом соединении. Для боевого магазина это норма, но об этом стоит помнить при тестировании.
• Разрешение спрашивают явно. Браузер сам покажет запрос доступа к микрофону, и пользователь может отказать. Виджет должен корректно вести себя при отказе — не ломаться и не навязываться повторно.
• Результат приходит текстом. API отдаёт распознанную строку (иногда несколько вариантов с оценкой уверенности). Аудио хранить не требуется — магазин работает уже с текстом.

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

Языки, мобильный сценарий и ограничения

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

Язык распознавания

Распознавание речи привязано к языку. Для русскоязычного магазина указывают русский язык распознавания — тогда система лучше разбирает русскую речь. Но покупатели вставляют в речь иностранные названия брендов и моделей («самсунг галакси», «эпл вотч»), и здесь возможны искажения: распознавание может записать бренд «на слух» кириллицей или ошибиться. Частично это лечится на стороне поиска — синонимами и нормализацией (об этом мы писали в разборе обычного поиска): «самсунг» должен находить Samsung. То есть языковые огрехи голоса компенсируют не в распознавании, а в текстовом поиске, куда попадает результат.

Мобильный сценарий — основной

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

Разговорность запроса

Надиктованный запрос почти всегда «разговорнее» набранного. Человек печатает «кроссовки 42», а говорит «покажи мне пожалуйста чёрные кроссовки где-то сорок второго размера». В такой фразе много лишних слов. Здесь выручают стоп-слова и морфология обычного поиска: служебные слова отсекаются, а значимые приводятся к нормальной форме. Но об этом надо позаботиться заранее — на «сыром» тексте из распознавания разговорные запросы дают более шумную выдачу, чем короткие печатные.

Поиск по фото: путь от снимка к товарам

Визуальный поиск сложнее голосового, потому что здесь нет промежуточного текста — сопоставляются изображения. Разберём путь фотографии от загрузки до выдачи похожих товаров.

1. Загрузка изображения. Покупатель загружает фото из галереи или снимает предмет камерой прямо в интерфейсе поиска.
2. Предобработка. Изображение приводят к нужному виду: обрезают, масштабируют, иногда выделяют главный объект, чтобы фон не мешал распознаванию.
3. Извлечение признаков (эмбеддинг). Модель компьютерного зрения превращает картинку в эмбеддинг — числовой вектор, компактно описывающий внешний вид.
4. Поиск похожих в векторном пространстве. Систему заранее «накормили» эмбеддингами всех фото каталога. Теперь она ищет товары, чьи эмбеддинги ближе всего к эмбеддингу запроса.
5. Формирование выдачи. По найденным ID товаров подгружают карточки — картинку, цену, наличие — и показывают «похожие товары», обычно несколько кандидатов с возможностью уточнить.

Обратите внимание на пунктирную стрелку внизу схемы: эмбеддинги всех товаров каталога считаются заранее, а не в момент запроса. Это отдельная фоновая работа — при добавлении товара или обновлении его фото нужно пересчитать эмбеддинг и обновить векторный индекс. Как и с обычным поиском, где есть поисковый индекс, здесь есть векторный индекс, который надо поддерживать в актуальном состоянии. Если фото товара не проиндексировано в векторном пространстве, визуальный поиск его не найдёт — ровно как обычный поиск не находит непроиндексированный товар.

Распознавание: сторонний сервис или своя модель

Ключевое инженерное решение в поиске по фото — где брать модель компьютерного зрения. Есть два пути, и у каждого своя цена и свои компромиссы.

Сторонний ML-сервис (API)

Первый путь — использовать готовый облачный сервис визуального поиска или распознавания изображений через API. Магазин отправляет картинку в сервис, тот возвращает либо эмбеддинг, либо сразу список похожих товаров (если сервис специализируется на товарном визуальном поиске и вы загрузили в него каталог). Плюсы очевидны: не нужно обучать и держать свою модель, старт быстрый, качество распознавания «из коробки» приличное. Минусы — постоянная оплата по объёму запросов, зависимость от внешнего поставщика и передача изображений на сторону, что важно для приватности.

Своя модель

Второй путь — развернуть собственную модель компьютерного зрения на своём сервере: взять предобученную модель для извлечения эмбеддингов, посчитать эмбеддинги каталога и организовать векторный поиск у себя. Плюсы — независимость от внешнего сервиса, отсутствие поштучной оплаты запросов, полный контроль над данными (изображения не покидают инфраструктуру). Минусы — нужны компетенции в машинном обучении, серверные ресурсы (в идеале с ускорением вычислений), и всё это надо поддерживать. Это заметно более тяжёлый путь, который оправдан на больших каталогах и высоких объёмах запросов.

Практичный подход — начинать с внешнего сервиса как с пилота, чтобы проверить, пользуются ли покупатели визуальным поиском вообще и на каких категориях он приносит пользу. Если сценарий «взлетел» и объёмы выросли настолько, что оплата API стала заметной, а приватность — критичной, тогда рассматривают перенос на свою модель. Начинать сразу со своей модели «на всякий случай» — типичная переинженерия: можно потратить месяцы на инфраструктуру ради фичи, которой в итоге почти не будут пользоваться.

Эмбеддинги и векторный поиск обзорно

Чтобы принимать решения о визуальном поиске осознанно, полезно на обзорном уровне понимать два понятия: эмбеддинг и векторный поиск. Без формул, но по сути.

Что такое эмбеддинг

Эмбеддинг — это представление объекта (в нашем случае картинки) в виде набора чисел, вектора. Модель компьютерного зрения обучена так, что похожие по виду изображения получают близкие векторы, а непохожие — далёкие. Условно можно представить, что каждой картинке присваивается точка в многомерном пространстве, и визуально близкие товары оказываются рядом. Эмбеддинг не хранит саму картинку и не «понимает» её смысл словами — он кодирует внешние признаки в форму, удобную для сравнения.

Что такое векторный поиск

Векторный поиск — это поиск ближайших точек к заданной. Когда покупатель загрузил фото, для него посчитали эмбеддинг-вектор, и задача сводится к тому, чтобы найти в каталоге товары, чьи векторы ближе всего к этому. На больших каталогах перебирать все товары по очереди дорого, поэтому используют специальные структуры и алгоритмы приближённого поиска ближайших соседей и векторные базы/индексы — они находят близкие векторы быстро, жертвуя малой долей точности ради скорости. Это прямая аналогия с поисковым индексом текста: там ускоряют текстовый поиск, здесь — поиск по векторам.

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

Голос против фото: что выбрать

Голосовой и визуальный поиск часто обсуждают вместе, но это разные инструменты с разной сложностью, стоимостью и областью применения. Сведём различия в таблицу, чтобы было проще решать, что и когда внедрять.

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

Сценарии применения и ниши

Обе механики полезны не «вообще», а в конкретных сценариях. Разберём, где голос и фото приносят реальную пользу, а где — лишняя кнопка.

Где выигрывает голосовой поиск

• Мобильный трафик и «руки заняты». Человек в дороге, на кухне, с ребёнком на руках — диктовать быстрее, чем печатать.
• Длинные и составные запросы. «Беспроводные наушники с шумоподавлением до пяти тысяч» проще сказать, чем набрать.
• Аудитория, которой неудобно печатать. Пожилые покупатели, люди с нарушениями моторики — голос делает магазин доступнее.

Где выигрывает поиск по фото

• Мода и обувь. Покупатель увидел вещь на улице или в соцсети — фотографирует и ищет похожее. Здесь визуальный поиск максимально уместен: выбирают глазами, названия не знают.
• Мебель, декор, освещение, плитка. «Хочу такой же торшер / такую же плитку». Внешний вид решает, а описать словами трудно.
• Автозапчасти и крепёж. Деталь проще сфотографировать, чем описать. Но здесь визуальное сходство обязательно дополняют точными атрибутами и проверкой совместимости — иначе легко подобрать похожую, но не подходящую деталь.
• Товары «без названия» у покупателя. Запчасть, фурнитура, расходник, который человек держит в руках, но не знает, как называется, — классический случай для фото.

Где обе механики почти бесполезны

Есть ниши, где ни голос, ни фото серьёзной пользы не дадут. Электроника, которую выбирают по характеристикам, а не по виду корпуса: сфотографировать похожий чёрный прямоугольник легко, но это не поможет подобрать нужный ноутбук. Лекарства и товары, где важен состав, а не облик упаковки. Продукты, где решают вес, срок годности и бренд. В этих категориях лучше вложиться в обычный поиск, фильтр и структуру каталога, а не в визуальные механики.

Архитектура на 1С-Битрикс

Теперь о том, как это собирается на 1С-Битрикс. Архитектура и для голоса, и для фото раскладывается на три слоя: фронтенд-виджет, бэкенд-обработчик и внешний сервис (или своя модель). Разница в том, что для голоса внешний слой в базовом варианте почти не нужен, а для фото он — центральный.

Разберём каждый слой отдельно в следующих разделах. Сейчас важно уложить в голове общую картину: сайт на 1С-Битрикс остаётся «хозяином» — он показывает интерфейс, хранит каталог, отдаёт карточки товаров и выдачу. Голос и фото добавляют к нему входной слой (виджет) и, для визуального поиска, отдельный вычислительный сервис. Каталог, цены, наличие, фильтр и обычный поиск при этом никуда не деваются — они работают ровно так же, как и без этих механик.

Фронтенд-виджет голосового ввода

Фронтенд-виджет — это то, что видит и трогает покупатель. Для голосового поиска он реализуется как доработка существующей строки поиска, и это самая простая часть.

Что делает виджет голоса

• Показывает кнопку микрофона в строке поиска — но только там, где браузер поддерживает Web Speech API. Если поддержки нет, кнопку не рисуют, чтобы не создавать нерабочий элемент.
• Запрашивает доступ к микрофону по нажатию и запускает распознавание. Показывает понятную индикацию «слушаю» — чтобы человек понимал, что говорить можно.
• Подставляет распознанный текст в поле поиска и даёт его отредактировать перед запуском выдачи. Это защита от ошибок распознавания.
• Корректно обрабатывает отказ и ошибки. Отказали в микрофоне, ничего не распозналось, шумно — виджет не ломается, а мягко возвращает к обычному вводу.

Для поиска по фото фронтенд-виджет чуть сложнее: он даёт загрузить изображение из галереи или снять камерой (на мобильных это делается штатными средствами браузера), показывает превью, отправляет картинку на бэкенд и отображает подобранные похожие товары. Но и здесь ключевой принцип тот же — интерфейс должен деградировать мягко: если что-то пошло не так, покупатель всегда может вернуться к обычному поиску и фильтру.

Бэкенд-обработчик и внешний сервис

Бэкенд-обработчик — это серверная часть на стороне 1С-Битрикс, которая принимает запрос от виджета и оркестрирует работу. Для голосового поиска его роль минимальна (текст просто идёт в обычный поиск), для визуального — центральна.

Что делает бэкенд при поиске по фото

1. Принимает изображение от виджета через собственный endpoint (например, обработчик на стороне Битрикс), проверяет тип и размер файла, ограничивает злоупотребления.
2. Отправляет картинку на распознавание — во внешний ML-сервис по API или в свою модель на сервере — и получает эмбеддинг либо сразу список похожих.
3. Выполняет векторный поиск по индексу эмбеддингов каталога (если он на вашей стороне) и получает ID наиболее похожих товаров с оценкой близости.
4. Подгружает данные товаров из каталога Битрикс — название, цену, наличие, картинку — по найденным ID, отсекает распроданные или скрытые.
5. Возвращает выдачу виджету: несколько похожих товаров, при необходимости с честной пометкой уверенности и предложением уточнить фильтром.

Важная деталь: за пределами распознавания бэкенд работает с обычным каталогом Битрикс — теми же инфоблоками, ценами, наличием, что и весь магазин. Именно поэтому визуальный поиск нельзя делать в отрыве от каталога: результат распознавания — это лишь список ID, а всё «мясо» (карточка, цена, кнопка в корзину) берётся из штатного каталога. Хорошо спроектированный каталог здесь так же важен, как и модель: если товары без нормальных данных, красивый подбор упрётся в пустые карточки.

Синхронизация индекса

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

Связь с обычным поиском и Sphinx

Мы уже несколько раз повторили, что голос и фото опираются на обычный поиск. Разберём эту связь предметно, потому что она определяет, будет ли от новых механик польза.

Голосовой поиск и текстовый движок. После распознавания голос превращается в текстовый запрос, который идёт ровно в тот же поисковый движок, что и напечатанный, — штатный модуль «Поиск» или внешний Sphinx/ElasticSearch. Значит, всё, что мы настраивали для текстового поиска (морфология, стоп-слова, синонимы, ранжирование, обработка опечаток), работает и для голоса. Более того, для голоса это даже важнее: разговорные запросы длиннее и «грязнее», и без хороших синонимов и стоп-слов они дают шумную выдачу. Так что первый шаг к хорошему голосовому поиску — это хороший текстовый поиск, о настройке которого мы подробно писали в статье про поиск по сайту и Sphinx.

Визуальный поиск и текстовый движок. Здесь связь другая, но она есть. Визуальный поиск возвращает ID товаров, а дальше карточки, цены и наличие берутся из того же каталога и отдаются теми же компонентами. Часто визуальный и текстовый поиск объединяют в единый опыт: покупатель загрузил фото, получил похожие товары, а затем сузил результат обычным фильтром и текстовым уточнением. На больших каталогах, где для текстового поиска уже подключён Sphinx, векторный поиск живёт рядом как отдельная подсистема, но оба выдают результат в общий каталог и общую витрину.

Связь с рекомендациями

Визуальный поиск технологически близок к товарным рекомендациям «похожие товары», и это стоит использовать. И там, и там задача — по одному товару (или картинке) найти похожие. Механика эмбеддингов, которую строят для визуального поиска, естественно переиспользуется в блоке «похожие товары» на карточке: если у вас уже посчитаны визуальные эмбеддинги каталога, вы почти бесплатно получаете визуально-похожие рекомендации.

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

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

Качество и ложные срабатывания

Самое важное для трезвого разговора: и распознавание речи, и распознавание изображений — вероятностные. Они не дают гарантированно правильный ответ, они дают наиболее вероятный. Это надо закладывать в дизайн, а не бороться с этим как с багом.

Ошибки голосового поиска

• Неверное распознавание слова. Особенно в шуме и с иностранными названиями. Лечится показом распознанного текста для правки и синонимами в поиске.
• Лишние разговорные слова. «Ну покажи мне такие...» — шум в запросе. Лечится стоп-словами и морфологией.

Ошибки визуального поиска

• Ложное сходство. Модель подобрала внешне похожий, но не тот товар: тот же силуэт и цвет, но другая суть. Самый частый и коварный случай.
• Пропуск подходящего. Нужный товар есть в каталоге, но не попал в выдачу из-за плохого фото товара или плохого фото-запроса.
• Проблема фона и ракурса. Товар на пёстром фоне, под непривычным углом, в упаковке — модель может «зацепиться» не за то.

Как проектировать под ошибки

Правильный дизайн честно признаёт вероятностную природу и не притворяется, что нашёл «единственно верный» товар.

1. Показывайте несколько кандидатов. Не один ответ, а сетку похожих — покупатель сам выберет ближайшее.
2. Вводите порог уверенности. Если близость ниже порога, честно говорите: «Точного совпадения не нашли — вот что похоже» вместо навязчивого «нашли ваш товар».
3. Давайте уточнить фильтром. После визуального подбора покупатель должен иметь возможность сузить результат по цене, размеру, бренду — привычными галочками.
4. Не прячьте обычный поиск. Всегда оставляйте путь к текстовому поиску и каталогу как запасной вариант.

Приватность и согласие

Голос и изображения — это персональные данные, и относиться к ним нужно ответственно, а не как к «просто запросу». Пренебрежение приватностью здесь бьёт и по доверию покупателей, и по соответствию требованиям к обработке персональных данных.

Голосовой поиск

• Явное разрешение. Доступ к микрофону запрашивают по действию человека, честно объясняя зачем. Никакого скрытого прослушивания.
• Не хранить аудио без нужды. Web Speech API отдаёт текст; сам звук магазину хранить не требуется. Работайте с распознанным текстом.
• Помнить про облако платформы. В части браузеров звук уходит на серверы платформы для распознавания. Это стоит учитывать и отражать в политике конфиденциальности.

Поиск по фото

• Объяснить, куда уходит фото. Если изображение обрабатывается сторонним сервисом, покупатель имеет право знать об этом.
• Не хранить дольше нужного. Загруженное фото нужно только для подбора; после него хранить изображение обычно не требуется.
• Не передавать лишнего. Ограничить круг сервисов и данных, которые получают изображение, необходимым минимумом.
• Отразить в документах. Всё это фиксируют в политике конфиденциальности и согласии на обработку данных.

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

Стоимость сервисов и экономика

Разговор о голосе и фото не полон без денег. Стоимость двух механик отличается на порядок, и это влияет на решение.

Голосовой поиск

Базовый голосовой поиск на Web Speech API дёшев: основная стоимость — это разработка виджета и его аккуратная интеграция со строкой поиска. Постоянных платежей за распознавание в базовом варианте нет, потому что работу делает браузер и платформа устройства. Дополнительные расходы появляются, только если понадобится платный сервис распознавания речи ради единого качества на всех платформах, — но для большинства магазинов это избыточно.

Поиск по фото

Визуальный поиск ощутимо дороже, и расходы бывают нескольких видов:

• Оплата ML-сервиса. Если используете внешний API, платите по объёму: за распознавания и/или за хранение и обслуживание индекса каталога. Чем больше запросов и товаров, тем дороже.
• Своя инфраструктура. Если разворачиваете свою модель — это серверные ресурсы (нередко с ускорением вычислений), их обслуживание и электричество.
• Разработка и интеграция. Бэкенд-обработчик, векторный индекс, синхронизация с каталогом, фронтенд загрузки фото — всё это работа команды.
• Поддержка. Модель и индекс надо сопровождать: обновлять эмбеддинги, следить за качеством, реагировать на изменения каталога.

Экономический вывод: голосовой поиск легко окупается уже за счёт мобильного удобства и почти не несёт постоянных расходов. Визуальный поиск требует осознанного бизнес-обоснования — он оправдан там, где выбирают глазами и где дополнительная конверсия и средний чек перекроют расходы на сервис и поддержку. Внедрять дорогой визуальный поиск «для имиджа», без расчёта отдачи, — способ потратить бюджет впустую.

Влияние на конверсию и мобильный UX

Зачем всё это, если свести к деньгам и удобству? Голос и фото влияют на конверсию через сокращение усилий покупателя — но по-разному.

Голосовой поиск снимает трение ввода на мобильных. Чем короче путь от намерения к запросу, тем меньше людей бросает поиск на полпути. Диктовка вместо набора экономит секунды и раздражение, особенно в длинных запросах и в движении. Это работает на ту же «горячую» аудиторию, что и обычный поиск: человек с намерением быстрее доходит до товара. Прямой связи «голос = +X% конверсии» никто честно не назовёт — эффект зависит от доли мобильного трафика и качества обычного поиска, — но механика однозначно снижает трение там, где набирать неудобно.

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

Про мобильный UX стоит сказать отдельно: обе механики — прежде всего мобильные. На телефоне тесно, набирать неудобно, зато есть микрофон и камера. Поэтому голос и фото проектируют под мобильный экран в первую очередь: крупные кнопки, понятные состояния, быстрый ответ. Общие принципы мобильной витрины — в статье про мобильную версию магазина на 1С-Битрикс; голос и фото ложатся на них как естественное продолжение.

Когда это оправдано, а когда рано

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

Голосовой поиск оправдан, когда

• У магазина много мобильного трафика, а обычный текстовый поиск уже работает хорошо.
• Есть длинные и составные запросы, которые неудобно набирать.
• Внедрение дёшево (браузерное API), а деградация мягкая — риск минимален.

Поиск по фото оправдан, когда

• Товары выбирают глазами: мода, обувь, мебель, декор, свет, украшения.
• Есть качественная база фотографий товаров — иначе визуальному поиску не на чем работать.
• Покупатели часто не знают названий и приходят с картинкой или предметом.
• Объём и маржинальность категории оправдывают расходы на сервис и поддержку.

Внедрять рано, когда

• Обычный поиск по каталогу выдаёт пустоту, не знает морфологии и синонимов.
• Каталог с плохими или отсутствующими фотографиями товаров.
• Нет данных о том, каким сценарием реально пользуются покупатели.
• Мотивация — «потому что модно» или «у конкурента есть», без расчёта отдачи.

Внедрение пошагово

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

1. Доведите до ума обычный поиск. Морфология, синонимы, стоп-слова, ранжирование, обработка опечаток, качественная выдача. Это фундамент для голоса и опора для фото.
2. Наведите порядок в фотографиях товаров. Для визуального поиска это критично: единый фон, нормальный ракурс, достаточное качество главного фото.
3. Измерьте сценарии. Посмотрите долю мобильного трафика, поисковые запросы, категории. Поймите, где голос, а где фото дадут пользу.
4. Добавьте голосовой виджет. Кнопка микрофона в мобильной строке поиска на Web Speech API, показ распознанного текста для правки, мягкая деградация без поддержки API.
5. Выберите путь для фото. Внешний ML-сервис для пилота или своя модель для больших объёмов и приватности — по объёму, бюджету и требованиям к данным.
6. Постройте векторный индекс. Посчитайте эмбеддинги каталога, организуйте векторный поиск, настройте синхронизацию при изменениях товаров.
7. Свяжите с каталогом. Бэкенд по ID товаров подтягивает карточки, цены, наличие, отсекает распроданное и скрытое.
8. Спроектируйте под ошибки. Несколько кандидатов, порог уверенности, честная формулировка «похожее», возможность уточнить фильтром.
9. Закройте приватность. Согласия, честные предупреждения, аккуратное хранение, отражение в политике конфиденциальности.
10. Измерьте эффект. Смотрите, пользуются ли механиками, как это влияет на путь к покупке, окупается ли визуальный поиск. Не «взлетело» — не стесняйтесь свернуть.

Частые ошибки

• Голос и фото поверх плохого обычного поиска. Голос сведётся к тому же плохому поиску, а фото упрётся в пустые карточки. Сначала — обычный поиск и каталог.
• Визуальный поиск на плохих фотографиях. Тёмные, мелкие фото на пёстром фоне дают «грязные» эмбеддинги и промахи. Без нормальных фото товаров визуальный поиск бесполезен.
• Показ одного «точного» ответа. Распознавание вероятностно; выдавать один результат как гарантированно верный — обманывать покупателя. Нужны несколько кандидатов и порог уверенности.
• Похожее выдают за подходящее в автозапчастях. Визуальное сходство без проверки совместимости ведёт к возвратам и жалобам. Сходство — первичный отбор, не финальный ответ.
• Кнопка микрофона там, где нет поддержки API. Нерабочий элемент раздражает. Показывать голос только там, где Web Speech API доступен.
• Молчаливый уход в поиск по «услышанному». Без показа распознанного текста и правки шумные запросы дают пустую выдачу. Дайте покупателю поправить слово.
• Игнор приватности. Скрытый запрос доступа к микрофону и камере, непрозрачная передача фото на сторону подрывают доверие и нарушают требования к данным.
• Векторный индекс не обновляется. Новые товары не находятся, удалённые всплывают. Эмбеддинги надо пересчитывать при изменениях каталога — как переиндексацию.
• Дорогой визуальный поиск без обоснования. Внедрили «потому что модно» в нише, где выбирают по характеристикам, — потратили бюджет впустую.
• Ломка базового сценария. Ради «умной» фичи сломали обычную строку поиска и фильтр. Голос и фото — надстройки; базовый путь должен работать всегда.
• Сразу своя модель «на всякий случай». Месяцы на инфраструктуру ML до проверки спроса. Начните с пилота на внешнем сервисе.

Чек-лист внедрения

Практический список, по которому удобно принимать готовность голосового и визуального поиска перед запуском:

1. Обычный поиск работает. Морфология, синонимы, стоп-слова, ранжирование и опечатки настроены; выдача качественная.
2. Фотографии товаров в порядке. Для визуального поиска — единый фон, нормальный ракурс, достаточное качество главного фото.
3. Голосовой виджет корректен. Микрофон только при поддержке API; показ и правка распознанного текста; мягкая деградация при отказе.
4. Путь для фото выбран осознанно. Внешний сервис для пилота или своя модель — по объёму, бюджету, приватности.
5. Векторный индекс построен и синхронизируется. Эмбеддинги каталога посчитаны; обновление при изменениях товаров налажено.
6. Связь с каталогом работает. По ID подтягиваются карточки, цены, наличие; распроданное и скрытое отсекается.
7. Дизайн учитывает ошибки. Несколько кандидатов, порог уверенности, честная формулировка, уточнение фильтром.
8. Совместимость проверяется. В автозапчастях и подобных нишах сходство подтверждается точными атрибутами.
9. Приватность закрыта. Согласия, предупреждения, аккуратное хранение, отражение в политике конфиденциальности.
10. Мобильный UX продуман. Крупные кнопки, понятные состояния, быстрый ответ, запасной путь к обычному поиску.
11. Эффект измеряется. Видно, пользуются ли механиками и окупается ли визуальный поиск; есть готовность свернуть, если не «взлетело».

Вывод

Голосовой поиск и поиск по фото — это не «искусственный интеллект, который заменит каталог», а два дополнительных способа задать запрос для покупателей, которым неудобно или невозможно набрать его текстом. Голосовой поиск через Web Speech API дёшев и полезен на мобильных: он распознаёт речь в текст и отдаёт его в обычный поиск, поэтому его качество целиком стоит на качестве текстового поиска. Визуальный поиск по фото сложнее и дороже: он превращает картинку в эмбеддинг, ищет похожие товары в векторном пространстве и оправдан там, где выбирают глазами и не знают названия — в моде, декоре, отчасти в автозапчастях с обязательной проверкой совместимости.

Практический вывод трезвый: сначала — нормальный обычный поиск и качественный каталог с хорошими фотографиями. Потом — голосовой ввод как дешёвая мобильная надстройка. И только там, где есть сценарий, база фото и бизнес-обоснование, — визуальный поиск, спроектированный под вероятностную природу распознавания: с несколькими кандидатами, порогом уверенности, уточнением фильтром и уважением к приватности. Внедрять голос и фото «потому что модно», без данных и без готовой базы, — преждевременная оптимизация. А сделать это по уму, поверх сильного обычного поиска, — способ открыть новые точки входа в каталог и не потерять покупателя там, где текст бессилен. Другие разборы по теме — в рубрике «Каталог и поиск», а про поисковый фундамент — в статье про поиск по сайту и Sphinx.