Гібридний пошук зображень у великих масштабах: SigLIP, SPLADE, YOLOv8 та Gemini Captions

Пошук за ключовими словами в тегах має обмежені можливості щодо зображень. Команди, які створюють каталоги електронної комерції, інструменти керування контентом чи бібліотеки цифрових активів, прагнуть пошуку, який би розумів те, що показує зображення, його стиль та емоційний настрій, а не лише слова, введені у поле тега. Наведена нижче схема описує гібридну систему пошуку зображень, яка знаходить інформацію у репозиторії приблизно з мільйоном зображень, використовуючи як візуальний контент, так і текстові запити; вона побудована переважно з існуючих сервісів ШІ, щоб зменшити обсяг роботи над розробкою.

Архітектура поєднує кілька спеціалізованих компонентів. Вони описані нижче в порядку проходження даних через них: ембеддинги, аналіз зображень, генерація опису, обробка запитів та операції.

Два моделі ембеддингів

Система ґрунтується на двох окремих каналах ембеддингу, кожен з яких фіксує різні аспекти контенту.

Для зображень використовується SigLIP. Після оцінки моделей CLIP та ImageBind SigLIP виявився кращим. Це контрастна модель зображень та тексту, навчена за допомогою функції втрати сигмоїди; за повідомленими результатами її точність у тестах ImageNet без попередньої налаштування становить близько 76%, що на кілька пунктів вище, ніж у схожих моделей CLIP. Крім того, вона потребує менше обчислювальних ресурсів — приблизно на 40% менше, згідно з наведеним тут порівнянням — та може застосовуватися у нових сферах без додаткової налаштування. Кожне зображення перетворюється на щільний вектор у просторі, де сусідні точки виглядають схожими.

Для тексту використовується SPLADE v2. SPLADE створює розріджені вектори, прямо пов’язані з лексиконом, що дає три переваги:

• Розріджений вихід залишається зрозумілим, оскільки кожен вимір відповідає реальному терміну.
• Він самостійно розширює запити за допомогою лексики, що полегшує проблеми незбігу лексикону, які трапляються під час пошуку (наприклад, „sofa“ проти „couch“).

Оскільки розміри є термінами, можна простежити походження збігу до саме тих слів, які його спричинили, що допомагає пояснити результати.

Розуміння кожної зображення

Чисті пікселі перетворюються на шари інформації, які можна запитувати, у багатоетапному процесі обробки.

Виявлення об’єктів за допомогою YOLOv8. YOLO аналізує все зображення за один прохід мережі, тому він набагато швидший за двоетапні детектори, такі як Faster R-CNN. У цій конфігурації велика версія займає близько 50 мс на зображення, що достатньо для ефективної групування. Він досягає 53,9% mAP у тесті COCO серед 80 поширених класів, а модель легко розподіляється між кластерами GPU.

Від загальних класів до іменованих ентитетів. Детекція дає такі мітки, як людина, автомобіль та будівля. Для розширених пошукових функцій потрібні конкретні ідентифікатори, тому сервіс веб-ентитетів їх перетворює:

Example Transformation:

YOLO: "person" (coordinates: [120, 45, 220, 320])
Web Extraction: "Elon Musk" (confidence: 0.96)

YOLO: "building" (coordinates: [50, 100, 400, 600])
Web Extraction: "Eiffel Tower" (confidence: 0.92)

Ця служба розпізнає понад п’ять мільйонів об’єктів у таких категоріях, як публічні особи, визначні пам’ятки, продукти та бренди, а також події. Цей етап поєднує візуальне розпізнавання та зрозумілість контенту. Тоді можна використовувати запит на конкретного співака замість загального запиту на людину.

Етикети від API для розпізнавання зображень. Загальні поняття, дії та теми отримуються завдяки розпізнаванню етикетів, яке під час тестування ідентифікувало понад 10 000 різних концепцій у всьому репозиторії. Це допомагає у трьох аспектах: діях, таких як прогулянки чи приготування їжі, сценах, таких як пляж чи ліс, та об’єктах, які занадто специфічні для класифікації YOLO, наприклад капучино, який YOLO розпізнає лише як чашку.

Безпечний пошук. Контент позначається за п’ятьма критеріями: для дорослих, насильство, медичний контент, фейки (меми та відредаговані зображення) та відвертий контент. Кожен критерій має показник впевненості, тож фільтрацію можна налаштувати відповідно до політики організації. Автоматизація цього етапу замінила велику кількість ручної перевірки.

Gemini для метаданих та описів

Gemini створює структуровані метадані. Ретельна розробка запитів призвела до створення шаблону, який надійно витягує 25 атрибутів, кожен з яких має показник впевненості від 0 до 1, наприклад рівень чутливості та емоції:

System: You are an expert image analyzer. Extract the following attributes from the image, with a confidence score (0-1):

1. sensitivity (none, low, medium, high)
2. emotion (neutral, joy, sadness, surprise, etc.)
3. emotion_triggered (yes/no)
4. text_overlay (yes/no)
5. has_frames (yes/no)
6. has_religious_symbols (yes/no)
7. has_scattered_objects (yes/no)
8. style (photographic, illustrated, cartoon, abstract, etc.)
9. has_crowd (yes/no)
...
[full list of 25 attributes]

Response format: JSON object with attributes as keys and values as described above.

Об’єднані результати виявлення елементів, сутностей, атрибутів та метаданих потім надходять до другого запиту Gemini, який створює повний опис. Тут дуже важлива правильна розробка запиту, оскільки описи мають бути:

1. Багатими на ключові слова, що допомагає у пошуку тексту.
2. Однорідними за структурою, щоб їх можна було надійно обробляти.
3. Змістовними в контексті, що пояснюють, чому виявлені елементи мають значення.
4. З урахуванням атрибутів, таких як емоції та стиль.
5. Написаними з урахуванням ймовірних запитів до пошуку.

Шаблон виглядає так:

Generate a comprehensive, search-optimized description for this image based on the following data:

[Entity data from object detection and recognition]
[Label data from Vision API]
[Structured metadata from previous Gemini analysis]

Your description should:
1. Begin with the most significant entities and their actions/relationships
2. Include key visual attributes (colors, style, composition)
3. Mention emotional tone and aesthetic qualities
4. Incorporate likely search terms
5. Be 3-5 sentences in length

Спочатку візьміть необроблені дані виявлення:

Objects: person (0.98), guitar (0.95), microphone (0.92)
Entities: Taylor Swift (0.97)
Labels: concert, performance, stage, entertainment
Metadata: emotion=joy, has_crowd=yes, style=photographic, dominant_color=purple

Після обробки воно стає реченням, яке можна шукати:

Taylor Swift performs energetically on stage with an acoustic guitar during a concert, singing into a microphone with passionate expression. The image captures the excitement of a live performance with purple stage lighting creating a vibrant atmosphere. This high-quality photograph conveys feelings of joy and excitement, with Swift's iconic performance style clearly visible. The composition includes partial views of an enthusiastic crowd in the foreground, making this suitable for music, entertainment, and celebrity content.

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

Відповідь на запит

Запити проходять через шість кроків:

1. Аналіз. Класифікація наміру визначає, чи бажає користувач конкретні ентитети, стилі, емоції чи інші атрибути.
2. Вилучення ентитетів. Іменовані ентитети у запиті порівнюються з базою даних ентитетів, щоб вони отримали належну вагу.
3. Вбудовування. Запит вбудовується за допомогою SPLADE v2 та SigLIP, що відповідає способу представлення зображень.
4. Векторний пошук. Ембеддинг запиту знаходить найближчі ембеддинги зображень у індексі.

Фільтрація за правилами. Діють правила, специфічні для регіону та організації: пороги безпеки, пристосовані до регіону користувача, безпека бренду, фільтрація відповідно до віку та права на ліцензування.

Переранжування. Кілька факторів впливають на порядок результатів після першого проходження:

• Різноманітність – за допомогою алгоритму, який забезпечує мінімальну косинусову відстань між обраними зображеннями.
• Новизна – пріоритет надається новішим елементам за допомогою формули: score_boost = base_score * (1 + alpha * exp(-beta * days_old)).
• Популярність – використовується логарифмічне зниження ваги, щоб елементи, які використовуються часто, не домінували.
• Бізнес-правила для корекцій, специфічних для певної доменної структури.

Дві складні проблеми

Затримка. Послідовне використання кількох сервісних стеків спричиняло затримки, і початкові вимірювання показували час обробки кожного зображення від початку до кінця понад чотири секунди. Для вирішення цієї проблеми було використано асинхронні паралельні виклики, групування операцій у неконфліктні потоки, розміщення сервісів поруч для скорочення часу передачі даних через мережу, а також розподіл роботи відповідно до складності зображень. Середній час обробки знизився до 850 мс на зображення, причому 95% з них оброблялися менш ніж за 1,2 секунди.

Складність інтеграції. Кожен сервіс має власний API, механізми обробки помилок та характеристики продуктивності. Допомогло впровадження єдиного шару абстракції з послідовною обробкою помилок, механізмами захисту та альтернативними рішеннями для кожного сервісу, показниками стану кожної залежності та поетапним зниженням якості роботи, що дозволяє системі продовжувати функціонувати навіть під час часткових збоїв.

Результати та наступні кроки

Інвестиції у керовані сервіси ШІ дали позитивні результати. Розробка зайняла чотири місяці, на відміну від оцінки у понад дванадцять місяців для індивідуальної реалізації; рівень задоволення результатами пошуку зріс на 40%, а кількість ручного позначення та класифікації скоротилась на 80%.

Існує кілька напрямків для подальшого розвитку: персоналізація на основі поведінки користувачів, інтерактивна оптимізація результатів, запити, що поєднують текст та зображення, цикли зворотного зв’язку, які навчаються на основі кліків, та доробка моделей ембеддингу для конкретних галузей.