В этой статье речь пойдет о том, как устроены алгоритмы поиска по картинке и почему подходы со временем перешли от простых признаков к нейросетям и векторным представлениям. Это не абстрактная теория: ниже будет достаточно деталей, чтобы спроектировать собственный поиск по фото для интернет-магазина, каталога или другого продукта, где важно находить похожие товары по изображению. Для понимания того, как работал Google-поиск по картинке раньше стоит почитать обзоры на сайте upbyte.net. Там представлены результаты экспериментов с поиском и обнаруженные проблемы.
Если вы планируете написать свой поиск по картинке, вам придется объединить несколько направлений: компьютерное зрение, поиск по индексам (похожие вектора), математику метрик близости и инженерию (хранение, дедупликация, скорость ответа). Google в этом смысле удобен как “контур” понимания: публично рассказывают не все детали, но общая схема, эволюция методов и инженерные компромиссы прослеживаются.
Карта эволюции: от цвета и маркеров к эмбеддингам и ИИ
История поиска по фото по сути отражает историю вычислительной эффективности и качества признаков. Когда вычисления были дорогими, делали грубые представления. Когда данные и GPU стали массовыми, научились строить универсальные признаки, которые хорошо переносятся на разные домены.
Этап 1. Ранжирование по цветовым гистограммам и кластерам
Самый ранний путь выглядел просто: извлечь глобальные характеристики изображения. Например, гистограмму цветов и сравнивать ее по метрикам вроде Chi-square или Earth Mover’s Distance. Для задач “найти картинку с похожей цветовой палитрой” этого иногда достаточно, но для реального поиска товаров почти всегда недостаточно: одинаковые цвета могут быть у разных объектов, а один и тот же объект может выглядеть по-разному (ракурс, освещение, фон).
Если мыслить математически, цветовые признаки часто сводились к вектору фиксированной размерности, а сравнение к расстоянию между векторами. Это похоже на базовую задачу метрического поиска, где вы строите расстояния и ранжируете кандидатов.
Этап 2. Локальные маркеры и дескрипторы
Дальше добавилась идея локальных признаков: выделять ключевые точки на изображении и описывать окрестность. Классические семейства вроде SIFT / SURF (и аналоги) давали более инвариантные признаки к повороту и масштабированию. Затем строили систему поиска: “дескриптор → кандидаты → ранжирование”.
По сути это был гибрид: локальные дескрипторы + поиск по ближайшим соседям или bag-of-visual-words. Но расплата была в вычислениях: много ключевых точек, много сопоставлений, много вариантов на краевых кейсах.
Этап 3. Машинное обучение признаков: от hand-crafted к learning
Когда в индустрии стало нормой обучать представления, появилось понимание: если вы можете обучить нейросеть извлекать признаки так, чтобы “похожие объекты были близко в пространстве”, то поиск превращается в поиск по векторам. Это можно рассматривать как построение эмбеддингов: функция f(x) переводит изображение в вектор, а затем вы ищете ближайшие по косинусному расстоянию или по L2.
Для интернет-магазина этот этап особенно важен: товары часто представлены на разных фонах, с разными углами, иногда частично перекрыты, а иногда на фото есть текст, логотипы, упаковка. Нейросети позволяют лучше переносить такие вариации.
Этап 4. Индексация и приближенный поиск по ближайшим соседям
Как только признаки стали векторами, главный инженерный вопрос стал не “как сравнить два изображения”, а “как найти кандидатов быстро, когда у вас миллионы товаров”. Тонкость в том, что поиск “точных” ближайших соседей по всем векторам может быть слишком медленным. Поэтому индустрия активно использует приближенные методы индексации.
Типовые решения: HNSW, IVF, PQ, комбинации с rerank. В простом приближении: вы используете индекс, который быстро отдает топ-N кандидатов, а затем более дорогая модель/сравнение переранжирует результат.
Что именно сравнивают в Google-подобных системах по фото
На практике современные системы обычно строят обучаемые эмбеддинги изображений, а затем выполняют поиск ближайших соседей в векторном пространстве. Дальше добавляют доуточнение ранжирования и обработку дубликатов, разных представлений одного товара и шумных факторов (фон, масштаб, освещение).
Как устроить собственный поиск по картинке для интернет-магазина
Представьте схему, которую реально можно внедрить в продукте. Она состоит из конвейера: индексация товаров, обработка запроса пользователя, поиск кандидатов и итоговый скоринг/ранжирование.
Шаг 1. Нормализация и предобработка
На входе у вас будет изображение пользователя и фотоматериалы из каталога. Они могут отличаться по размеру, плотности, обрезке, наличию водяных знаков, стилю съемки. Минимальный набор: ресайз, иногда центрирование, обработка экзотики форматов, приведение к единому цветовому пространству.
Если у вас есть возможность, лучше заранее приводить изображение товара к более “упорядоченному” виду: например, удалять фон (или маскировать фон), если это помогает модели. Но не превращайте это в обязательную сложность: многие современные эмбеддинг-модели уже устойчивы к фону, и лишний препроцессинг может ухудшить качество.
Шаг 2. Извлечение эмбеддингов
Вы выбираете модель и получаете вектор фиксированной размерности. Дальше все сравнения сводятся к метрике. На практике косинусная близость часто используется вместе с нормировкой эмбеддингов до единичной нормы.
Типичные варианты в реализации:
- Один базовый backbone (например, vision-энкодер) и простой similarity для кандидатов.
- Двухстадийный подход: быстрые эмбеддинги для индексации и отдельный rerank-модуль для улучшения порядка выдачи.
- Фьюжн признаков: добавление метаданных (категория, бренд, цена) в итоговый скоринг.
Шаг 3. Индексация: когда “миллионы” становятся проблемой
Если в каталоге много позиций, вы заранее строите индекс по векторным эмбеддингам. В реальном проекте вам важно:
- управлять компромиссом между скоростью и точностью;
- уметь обновлять индекс при добавлении новых товаров;
- хранить связи “товар → изображения/ракурсы”, чтобы не ломать выдачу.
С инженерной точки зрения, это похоже на задачу: вы хотите быстро найти минимум по расстоянию среди набора векторов. Математика простая, но “быстро” требует умных структур данных.
Шаг 4. Ранжирование и фильтры
На этапе ранжирования вы обычно делаете несколько вещей: отсеиваете откровенно нерелевантные кандидаты, добавляете штрафы за дубликаты и используете бизнес-правила (например, показывать только наличие на складе или только определенные категории).
Если вы внедряете это для интернет-магазина, часто оказывается полезным ограничить поиск по домену: искать “похожее платье” среди платьев, “похожую обувь” среди обуви. Это снижает риск, что модель найдет “похожую по стилю” картинку из другой категории.
Когда стоит писать свой поиск по фото (а когда лучше не надо)
Решение “писать самим” зависит от цели, контента и требований по контролю. Есть сценарии, где собственный поиск по картинке реально нужен, и сценарии, где достаточно интеграции внешних сервисов.
Ниже варианты, где часто возникает потребность в собственном решении:
- Нужна выдача именно ваших товаров с вашей логикой ранжирования, наличием и ценами.
- Каталог с доменными особенностями: например, запчасти, компоненты техники, редкие предметы, где “общая” модель может путать визуальные похожести.
- Требуется контроль приватности и хранение данных пользователей без передачи наружу.
- Вы хотите улучшать качество по мере накопления кликов и покупок, то есть делать персонализированное ранжирование или обучение по вашему лейблингу.
- У вас есть разметка и вы готовы обучать или дообучать модель под свою предметную область.
А вот когда “своего” может не хватить из-за ресурсов: если у вас очень маленький каталог и сложные требования к покрытию (много разнообразных категорий), то иногда проще начать с базового эмбеддинг-поиска и постепенно добавлять доменную тонкую настройку.
Типичные сложности и ошибки разработки
Ошибка 1. Ожидать идеального совпадения при глобальном сходстве
Люди часто думают: “если изображения похожи, значит и поиск выдаст нужный товар”. Но в реальности эмбеддинги могут схватить “поверхностные” признаки. Например, одинаковый фон, освещение или общий стиль съемки. В магазине это особенно опасно, если вы используете однотипные фото-студии: модель начинает переучиваться на студийный паттерн.
Как лечить: используйте разнообразие аугментаций при обучении/дообучении, ограничивайте поиск по доменам и делайте rerank, который учитывает более устойчивые признаки.
Ошибка 2. Неправильная метрика близости
Эмбеддинги можно сравнивать по косинусной близости, по L2, по dot-product. Если вы выбрали модель, которая ожидает определенную нормировку, а вы сравниваете “как попало”, качество может падать без очевидных причин.
Практика: проверьте на валидационной выборке несколько вариантов similarity и зафиксируйте лучший. Это банально, но именно так рождаются “магические” разницы в качестве.
Ошибка 3. Дубликаты и “почти один и тот же товар”
Каталоги часто содержат дубликаты: разные карточки, разные цены, разные форматы фото, но визуально один и тот же товар. Поиск начинает возвращать несколько копий одного и того же, и пользователь считает, что система плохо понимает запрос.
Как лечить: заранее дедуплицируйте по изображениями и по товарам. Иногда помогает кластеризация изображений на уровне эмбеддингов (например, объединение по порогу расстояния), иногда помогает явная таблица соответствий.
Ошибка 4. Слабый датасет для дообучения
Если вы решите дообучать модель под свой каталог, главный риск в качестве данных. Нужно понимать, что “похожие” по мнению модели должны совпадать с тем, что нужно пользователю: клики, добавления в корзину, покупки, явные метки “это то, что искали”.
Частая ошибка: собирать пары “один артикул → один другой артикул” без контроля качества. Тогда модель начинает учиться артефактам (например, одна категория на сайте всегда сфотографирована на белом фоне).
Чем полезна математика в этой задаче
В основе поиска по фото лежит метрическое пространство: изображения переводятся в вектора, а релевантность ранжируется по расстоянию или сходству. Когда вы выбираете метрику и нормировку, вы фактически меняете геометрию поиска, а значит и то, какие кандидаты попадают в топ.
Практический пример: минимальная архитектура для старта
Ниже пример “скелета” подхода: индексация изображений из каталога, получение эмбеддинга запроса, поиск ближайших соседей в индексе и затем бизнес-фильтрация.
Схема конвейера
- Индексация: для каждой карточки товара храните один или несколько эмбеддингов (по основному фото и по альтернативным ракурсам).
- Индекс: строите структуру для приближенного NN поиска по векторам.
- Запрос: для изображения пользователя делаете тот же preprocessing и эмбеддинг.
- Поиск: получаете топ-N кандидатов по similarity и ограничиваете выдачу бизнес-правилами.
Фрагмент псевдокода для понимания потока
Ниже не готовый код под конкретный фреймворк, а принцип, который легко перенести на Python и любую библиотеку индексов.
# 1) Индексация
for product in catalog:
for image in product.images:
emb = encoder(image) # f(x) -> vector
emb = normalize(emb) # часто нужно для cos similarity
index.add(id=image.id, vec=emb)
# 2) Поиск по запросу
query_emb = normalize(encoder(query_image))
neighbors = index.search(vec=query_emb, top_k=200)
# 3) Ранжирование/фильтры
candidates = map_neighbor_ids_to_products(neighbors)
ranked = rerank_and_apply_rules(candidates, query_image)
return ranked[:20]
Главная мысль: “поиск” почти всегда двухуровневый. Индекс делает быстрый отбор, а rerank делает качество осмысленным.
Как улучшать качество: эксперименты, которые реально дают эффект
Дальше начинается инженерная часть: вы измеряете качество не “на глаз”, а метриками по выборке. Для интернет-магазина обычно важны такие показатели, как точность в топ-N, средняя позиция релевантного товара, доля кликов на ранних местах.
Практический набор экспериментов:
- сравнить несколько backbones и выбрать лучший на вашей доменной подвыборке;
- протестировать разные метрики similarity и нормировку эмбеддингов;
- добавить rerank на более дорогом модели/агрегации;
- оценить влияние дедупликации и кластеризации похожих карточек;
- проверить устойчивость к обрезкам и сильным изменениям освещения на “трудных” примерах.
И да, стоит завести небольшой банк “случаев, где модель ошибается”: без этого вы будете оптимизировать вслепую.
Нюансы, которые часто всплывают в продакшене
Пользовательские изображения и разные сценарии
Запрос по фото может быть снят на телефон, часто с перспективными искажениями, размытиями и частичным закрытием объекта. Плюс могут быть ситуации, где пользователь прислал часть товара, а не весь объект целиком. В такой реальности иногда лучше показывать не только “точное совпадение”, но и близкие варианты с правильным ранжированием по вероятности.
Масштабирование индекса и стоимость обновлений
Когда вы добавляете новые товары или меняете изображения, вы должны обновлять эмбеддинги и индекс. Часто обновление делается пакетами. Вопрос в том, насколько быстро система должна реагировать на новые карточки и как это отражается на стоимости вычислений.
Оценка качества без полной разметки
Если у вас нет возможности разметить “пары похожих товаров” вручную, начинайте с слабого обучения на кликах или с self-supervised/контрастивных подходов на вашем же корпусе. Но все равно нужна хотя бы базовая валидация: короткий цикл “обучили → протестировали → увидели ошибки → собрали данные на ошибки” обычно быстрее, чем долго строить идеальную теорию.
Почему подход “как у Google” не копируется один-в-один
У крупного поисковика другие масштабы, другие данные и другой инженерный контур. Но принципы одинаковые: строим признаки, переводим поиск в пространство ближайших векторов, делаем индексацию для скорости и добавляем ранжирование, которое соответствует реальному пользовательскому спросу.
Ваша задача как разработчика интернет-магазина или другого сервиса сильно упрощается, если вы заранее задаете доменные ограничения: категория, тип товара, ожидания пользователя по формату выдачи. Это уменьшает “геометрию ошибок” и позволяет быстрее достичь измеримого результата.
Если хотите, опишите ваш каталог (сколько товаров, какие категории, есть ли несколько фото на карточку, какие ошибки уже заметили) и я предложу стартовый план экспериментов: от выбора эмбеддинг-модели и метрики до схемы индексации и стратегии тестирования. Какой домен у вас ближе всего к “поиск по фото критически важен”: одежда, электроника, запчасти, или что-то другое?
