GOOGLE · ПОИСК ПО ФОТО · КАТАЛОГ
EmbeddingGemma 2: как проверить поиск товара по фото
Как оценить поиск по фотографиям на уровне продаваемых вариантов: проверить пять разных SKU, неоднозначные запросы и цену экономии памяти.
Что Google выпустил 6 октября
6 октября 2026 года Google представил EmbeddingGemma 2. Модель преобразует текст, изображения, аудио и видео в числовые представления, которые можно сравнивать в общем пространстве. Она предназначена в том числе для локального поиска на пользовательских устройствах; веса доступны под лицензией Apache 2.0. Официальный анонс Google.
Для магазина это повод проверить конкретную задачу: клиент присылает фотографию, а продавец быстрее находит несколько подходящих позиций своего каталога. Применение к такому каталогу — редакционный сценарий ниже. Анонс не подтверждает готовое подключение к SABSUS или качество поиска в вашем ассортименте.
Google показывает поиск похожих изображений в приложении AI Edge Gallery. В отдельной публикации от 6 октября поддержка через ML Kit обозначена как будущая возможность на ближайшие недели. Демонстрацию и доступность нужного пути внедрения проверяйте отдельно. Примеры и статус инструментов AI Edge.
Когда поиск по фото стоит проверять
Выберите товарную группу, где покупатель часто не знает названия: мебельная фурнитура, декоративные элементы, посуда. Для первого пилота хватит одного типа обращений и одного рабочего устройства продавца. Если клиенты обычно называют точный артикул или приносят читаемый штрихкод, сначала измерьте обычный поиск по этому идентификатору.
Учебный магазин продаёт мебельные ручки. На фотографии две модели выглядят одинаково, но расстояние между креплениями составляет 96 и 128 мм. Сходство изображения помогает собрать кандидатов; определить размер по снимку без масштаба может быть невозможно. Интерфейс должен позволять спросить размер, показать различия и продолжить подбор.
Не включайте в такой пилот автоматическое заключение о безопасности, технической совместимости или допустимости замены. Эти решения требуют своих подтверждённых данных и правил. Для замены уже выбранного товара используйте отдельную проверку разрешённого соответствия.
Считайте товары, а не фотографии
У каждой индексируемой фотографии сохраните связь с устойчивым кодом продаваемого варианта. Три ракурса одной ручки дают три записи изображений, но один SKU. Название папки и порядковый номер файла для этой связи недостаточны. До поиска проверьте соответствие фотографий вариантам.
Почему пять картинок могут дать только два товара
Задайте тестовый список результатов: первые три изображения относятся к H96, следующие два — к H160, шестое — к нужному H128. Это специально составленная проверка интерфейса, не результат EmbeddingGemma 2.
Если взять первые пять картинок и убрать повторы SKU, останется два товара, а H128 исчезнет. Для пяти разных товаров потребуется просматривать более глубокий список, группировать совпадения по SKU и продолжать до пяти уникальных кандидатов либо исчерпания результатов.
Попросите разработчика зафиксировать правило ранжирования группы: например, по лучшему совпадению её изображения. Сохраните и исходные позиции, и итоговую выдачу по товарам. Смена способа группировки способна изменить результат даже при неизменной модели.
Число рядом с кандидатом подпишите как оценку сходства, если именно её возвращает поиск. Не превращайте значение 0,84 в утверждение «84% вероятности, что это нужный артикул» без отдельной проверки такой интерпретации.
Подготовьте проверочный набор до настройки
Следующий набор из 60 запросов — учебный план приёмки. Он не описывает измеренную точность модели и не задаёт обязательный размер выборки для каждого бизнеса.
- 40 запросов с определимым товаром. Ответственный за каталог заранее указывает правильный SKU или допустимый набор SKU. Добавьте разные ракурсы, фон и освещение. Критерий — нужная позиция среди первых пяти уникальных товаров.
- 10 неоднозначных запросов. Например, внешне одинаковые ручки без масштаба. Заранее запишите недостающий признак и полезный уточняющий вопрос. Однозначное обещание точного совпадения здесь считается ошибкой процесса.
- 10 товаров, которых в каталоге нет. Включите внешне близкие изделия другой серии. Проверяется, не выдаёт ли интерфейс похожую позицию за установленное совпадение. Предложение посмотреть аналоги должно быть явно обозначено.
Проверочные фотографии должны отличаться от индексируемых снимков. Поиск того же самого файла проще клиентской задачи и может скрыть слабое различение вариантов. Не включайте персональные сведения в тестовые изображения.
Разделите примеры для настройки и отложенной проверки. На первой части выбирают пороги, глубину поиска и группировку; вторую открывают после фиксации настроек. Не подбирайте порог отказа по тем же обращениям, которыми затем доказываете качество. Если тестовая группа мала, считайте результат предварительным.
Сравните полный путь продавца
На одинаковых заданиях измерьте обычный поиск сотрудника и новый сценарий. Если клиент передал артикул, он доступен обоим способам. Если пришло только фото, нельзя незаметно дать одному способу известное из разметки название товара. Время уточняющего вопроса тоже входит в работу.
- Покрытие кандидатов: число определимых запросов, где правильный SKU попал в первые пять уникальных товаров, делённое на число проверенных определимых запросов.
- Ошибочные точные совпадения: случаи, когда весь интерфейс или сотрудник объявил конкретный SKU без достаточного основания. Считайте отдельно для неоднозначных и отсутствующих товаров.
- Время до решения: получение запроса, поиск, проверка признаков и необходимое уточнение. Покажите обычное время и медленные случаи, а не только скорость вычисления вектора.
- Отказы и исправления: полезное уточнение, необоснованный отказ при наличии товара, ручная смена кандидата, повторное открытие карточки.
Векторная модель формирует представления. Уточнения, ограничения выдачи и сообщение покупателю реализует вся поисковая система. Поэтому обещание «ничего подходящего нет» и ложное подтверждение товара оценивайте на уровне конечного сценария.
Не экономьте память вслепую
В руководстве Google предусмотрена загрузка только нужных модулей: для текста и изображений указано 440 млн параметров, для полного набора — 740 млн. Если пилот принимает фотографии и текст, аудиомодуль не является обязательной частью этой задачи. Руководство разработчика.
Карточка модели описывает векторы длиной 768, 512, 256 и 128 компонентов. Она предупреждает об ухудшении мультимодального качества при 128 компонентах. После усечения нужна повторная нормализация, а запросы и каталог должны иметь одинаковую размерность. Размерность и ограничения модели.
Учебный расчёт только для сырых векторов
5 000 SKU × 3 отдельно индексируемых фото = 15 000 векторов. Если каждый компонент хранится в float32 по 4 байта:
- 768 компонентов: 15 000 × 768 × 4 = 46 080 000 байт, или 46,08 МБ.
- 256 компонентов: 15 000 × 256 × 4 = 15 360 000 байт, или 15,36 МБ.
- 128 компонентов: 15 000 × 128 × 4 = 7 680 000 байт, или 7,68 МБ.
МБ здесь — миллион байт. В суммы не входят фотографии, веса модели, поисковый индекс, служебные поля, резервные копии и рабочая память приложения.
Сравнивайте варианты на одном каталоге, одних отложенных запросах и одной единице результата: уникальном SKU. Уменьшение сырых векторов в шесть раз не означает такого же сокращения всего приложения или расходов. Если правильный вариант чаще выпадает из списка, включите дополнительное время продавца в стоимость экономии.
Учтите обновления и полную стоимость
До запуска составьте смету работ: подготовка связей «изображение — SKU», создание индекса, интерфейс уточнения, проверка на выбранном устройстве и поддержка обновлений. Отдельно оцените время сотрудника на исправление ошибочной выдачи. Открытые веса позволяют выбрать способ размещения, но не устраняют эти работы.
Протестируйте три изменения: добавление нового варианта, замена ошибочного фото и удаление позиции из доступного ассортимента. Запишите, когда обновился источник, когда изменился индекс и что увидел продавец. Старое изображение не должно продолжать выдавать удалённый SKU как доступное предложение.
После выбора кандидата остаток, цену и условия продажи получают из текущей карточки. Локальный индекс может работать без сети, пока коммерческие данные требуют обновления. При отсутствии связи покажите дату известных сведений и не подтверждайте доступность без проверки.
Локальное вычисление само по себе не описывает движение всех данных. Уточните, отправляются ли фотографии в журналы, резервные копии, аналитику или сторонний сервис. Для каталога с ограниченным доступом проверьте, какие позиции может увидеть конкретный сотрудник. Эти свойства зависят от реализации приложения.
Как принять решение о пилоте
До испытания владелец задаёт допустимое число неверных точных совпадений, минимальное покрытие кандидатов и предел времени проверки. Критерии должны учитывать последствия ошибки именно в выбранной товарной группе. Чужой показатель на общем тесте моделей не заменяет эту договорённость.
Продолжать внедрение имеет смысл, когда поиск сокращает полный путь подбора, правильно обрабатывает неопределённость и остаётся поддерживаемым после изменения каталога. Если выигрыш виден только на одинаковых исходных фотографиях или исчезает после группировки по SKU, сначала исправьте тест и выдачу.
Для проекта SABSUS подготовьте одну товарную группу, фотографии и правила выбора в структурированном каталоге. Поддержку EmbeddingGemma 2, обмен данными и порядок обновления индекса нужно подтвердить отдельно для выбранной конфигурации.
Что должно остаться после проверки
Размеченные запросы, выдача по уникальным SKU, понятные ошибки, полное время подбора и проверенный порядок обновления каталога.
Другие практические разборы