Чому AI-класифікація фотографій ламається на реальних галереях
AI-класифікація фотографій на демо-стенді виглядає переконливо: десяток чистих знімків, охайні категорії, миттєвий відгук. На реальній галереї та сама модель розвалюється за лічені дні.
Користувач знімає серії по 10-20 кадрів підряд, половина з них — майже однакові, частина змазана на бігу, частина знята в темряві з шумом.
Модель бачить у цьому не «дублікати знімків», а різні зображення, і розмітка зображень перетворюється на хаос: та сама сцена розкидана по трьох категоріях, а поруч лежать кадри, які взагалі нікуди не потрапили.
Окрема біда — хибні категорії. Знімок їжі в теплому світлі від'їжджає в «документи», дитина в басейні — в «тварини», скриншот із текстом — у «пейзажі».
Чим більше файлів, тим помітніша помилка: при десятках тисяч знімків навіть 3-5% промахів дають тисячі фотографій не на своєму місці, і користувач перестає довіряти сортуванню галереї. Далі ламається пошук по фото: людина шукає «море», не знаходить, гортає вручну і йде з застосунку.
Є й суто інженерна сторона. Наївна реалізація проганяє через модель кожен файл при кожному відкритті галереї — час відгуку зростає лінійно і на великих обсягах стає нестерпним.
Розмиті та темні знімки додатково забивають індекс сміттєвими векторами, а дублікати плодять однакові записи, між якими модель не може вибрати.
Розбираємо, як це закривається: де ставити фільтр якості до моделі, як згортати серії в один кадр, чим обмежувати хибні спрацювання і як рахувати ознаки один раз, а не при кожному показі.
Що дає коректна класифікація: ефект у метриках
Класифікація перестає бути «фічею для галочки», коли її ефект видно в метриках продукту. Ми дивимося на три вимірювані величини: швидкість пошуку потрібного знімка, частку помилкових категорій і час обробки нової партії фотографій.
Саме вони показують, чи окупається модель на реальній галереї користувача, а не на демо-наборі з десятка картинок.
Швидкість пошуку — перше, що відчуває людина. Коли знімки розкладені за категоріями на пристрої, а не відправлені на сервер, результат з'являється за частки секунди: користувач вводить «документи» або «чеки» і одразу бачить потрібне.
На галереї в кілька тисяч знімків це різниця між «гортаю і чекаю» та «знайшов з першого запиту» — і саме вона утримує людину в застосунку.
Точність категорій вимірюється часткою помилкових спрацювань: скільки знімків потрапило не до своєї групи. Ми тримаємо цей показник низьким завдяки дообученню на фотографіях конкретного продукту, а не на універсальному наборі.
Чим менше помилок, тим рідше користувач перестає довіряти добіркам і повертається до ручного гортання.
Час обробки нової партії знімків визначає, як швидко галерея залишається актуальною. Класифікація йде інкрементально: обробляється тільки те, що додалося, а не вся бібліотека заново.
Тому навіть після зйомки сотні нових кадрів добірки оновлюються без помітної паузи, а навантаження на пристрій залишається передбачуваним.
Ці три метрики пов'язані: швидкий пошук марний при високій частці помилок, а висока точність втрачає сенс, якщо обробка гальмує інтерфейс. Ми налаштовуємо їх спільно і перевіряємо на реальних сценаріях — так користувацький досвід стає вимірюваним, а не декларативним.
Як влаштована AI-класифікація фотографій у мобільному застосунку
Класифікація починається з вилучення ознак: модель проганяє знімок і віддає вектор — набір чисел, що описують вміст кадру. За ним знімки й порівнюються між собою, а не за іменем файлу чи датою.
Для цього використовуємо Core ML на iOS та аналог на Android — inference відбувається на пристрої, фото не залишають телефон.
Далі вектори потрапляють в індекс галереї — локальне сховище, де кожному знімку відповідає запис із вектором і метаданими. Групування знімків будується на близькості векторів: схожі кадри збираються в кластери, які користувач бачить як «Пляж», «Документи», «Діти».
Індекс перебудовується інкрементально — при додаванні нових фото обробляються лише вони, а не вся бібліотека.
Синхронізація між пристроями — найчутливіша ділянка. Вектори передаються на сервер у стисненому вигляді й прив'язуються до ідентифікатора знімка, а не до самого файлу: так метадані не розростаються до розмірів галереї.
Якщо користувач видалив фото на одному пристрої, запис інвалідується за ідентифікатором, і кластер перезбирається без нього.
На практиці це дає галерею, яка шукає за змістом, а не за тегами: «покажи чеки за місяць» працює без ручної розмітки. Точність групування залежить від якості моделі — ми дообучаємо її на реальних знімках замовника, а не залишаємо базову.
Порівняння підходів: на пристрої, у хмарі, гібридно
Вибір між обробкою на пристрої, у хмарі та гібридною схемою визначається не «модністю» підходу, а тим, де фізично лежать фото і скільки обчислень потребує модель.
Обробка на пристрої виконується на нейромережевому прискорювачі телефона: зображення не покидає галерею, приватність фото зберігається за замовчуванням, затримка мінімальна, але модель обмежена пам'яттю та тепловим бюджетом пристрою.
Хмарна обробка знімає ці обмеження — доступні великі моделі та регулярне оновлення словника класів, зате кожен кадр іде на сервер, а розпізнавання залежить від мережі.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| На пристрої | Приватність критична, потрібна робота офлайн, класи стабільні | Модель урізана за розміром, слабкі пристрої гріються й гальмують |
| У хмарі | Велика бібліотека класів, часті оновлення моделі, потужна аналітика | Затримка залежить від каналу, витрати на трафік і обчислення зростають з обсягом |
| Гібридно | Потрібен баланс: швидкий відгук і розумні сценарії | Складніша логіка: два контури, синхронізація результатів, розподіл за типами кадрів |
Гібридна схема зазвичай виглядає так: легка модель на пристрої розмічає основну масу знімків одразу, а спірні та рідкісні кадри надсилаються в хмару на дообогачення.
Це знижує навантаження на канал і зберігає приватність для чутливих фото, але потребує продуманого правила маршрутизації — інакше користувач побачить розбіжність між локальними та хмарними тегами.
Окремо варто закласти міграцію: зміна підходу не повинна ламати вже розмічену галерею. Ми проєктуємо схему так, щоб результати класифікації зберігалися окремо від вихідників і переіндексація проходила без втрати користувацьких правок.
Етапи впровадження: від аудиту галереї до передачі регламентів
Роботу починаємо з аудиту галереї: дивимося, що реально зберігається у користувачів — частка дублікатів і скриншотів, розкид роздільних здатностей, пошкоджені та недовантажені файли, розподіл за альбомами.
На цих даних будуємо схему таксономії: скільки класів заводимо, що йде в «інше», як обробляємо прикордонні випадки на кшталт селфі у дзеркалі або скриншота листування.
- Аудит галереї. Вивантажуємо знеособлену вибірку, рахуємо статистику за типами контенту та знаходимо класи, які класифікатор буде плутати. Результат — перелік категорій і критерії, за якими знімок належить до кожної.
- Проєктування схеми. Фіксуємо дерево категорій, правила пріоритету при збігу та поведінку при низькій впевненості: фото йде в «інше», а не у випадковий альбом.
- Налаштування класифікатора. Підбираємо модель під профіль галереї та обмеження пристрою, налаштовуємо поріг впевненості та правила групування. Частина обчислень іде на пристрої — фото не залишають телефон.
- Перевірка на реальних даних. Проганяємо класифікатор на вибірці, рахуємо частку правильних віднесень за кожною категорією та розбираємо помилки. Поріг і правила коригуємо до прийнятної точності.
- Інтеграція в застосунок. Вбудовуємо обробку у фонові задачі, щоб класифікація йшла під час заряджання і не заважала роботі інтерфейсу.
- Передача документації. Віддаємо регламенти: схему категорій, налаштування, порядок перенавчання та розбору спірних випадків.
Після передачі команда замовника може змінювати категорії та пороги без нашої участі. Опишіть задачу — повернемося з оцінкою та планом для вашої галереї.
Що замовник отримує на руки після впровадження
Впровадження AI-класифікації фотографій закінчується не демонстрацією працюючого прототипу, а передачею комплекту, за яким застосунок можна розвивати й супроводжувати без нас. Нижче — що саме фіксується в документах і репозиторіях на момент здачі.
- Конфігурації моделі та сервісу класифікації. Файли параметрів інференсу, пороги впевненості за категоріями, правила віднесення знімка до «інше» — з коментарями, чому обрано саме такі значення.
- Схеми даних. Структура зберігання ембедингів і міток, формат обміну між застосунком і сервісом, міграції при зміні таксономії категорій.
- Політики доступу. Розмежування прав на читання метаданих, вивантаження датасету для донавчання, доступ до логів обробки; окремо — правила обробки користувацьких фото та строки їх зберігання.
- Документація по моделі. Картка моделі: на яких даних навчалася, які категорії розрізняє впевнено, де помиляється, як інтерпретувати метрики якості на валідації.
- Регламенти супроводу. Порядок донавчання при появі нових категорій, періодичність перевірки якості на свіжих знімках, правила відкату на попередню версію моделі.
- Інструкції для команди замовника. Як запустити переіндексацію галереї, як читати звіти щодо частки нерозпізнаних фото, куди дивитися при зростанні часу обробки.
- План розвитку. Список покращень з оцінкою впливу на якість — від розширення таксономії до підключення пошуку за вмістом знімка.
Кожен артефакт прив'язаний до конкретного сценарію експлуатації: оновлення категорій, розбір скарг на неправильне сортування, підготовка вибірки для донавчання.
Такий комплект дозволяє вашій команді вносити зміни самостійно, а нас підключати точково — на задачах, де потрібна переробка самої моделі.
Чим відрізняється класифікація на пристрої від хмарної обробки
Межа проходить по тому, де фізично лежать дані та обчислювальні ресурси.
При класифікації на пристрої модель працює прямо в застосунку: фото не покидає пам'ять телефона, інференс іде на нейропроцесорі або графічному прискорювачі, а результат — теги, групи, пошукові індекси — залишається локально.
При хмарній обробці знімок вирушає на сервер, там проганяється через модель і повертається розміткою. Звідси й розходяться всі чотири параметри: приватність, якість, затримка, трафік.
Приватність даних — головний аргумент на користь пристрою. Знімок не перетинає межу застосунку, немає передачі по мережі, немає зберігання на чужій стороні, а отже, немає й зобов'язань щодо захисту персональних даних у тому обсязі, який тягне за собою серверна обробка.
Для галерей, де лежать документи, чеки, особисті фото, це знімає цілий клас ризиків і спрощує проходження перевірок магазинів застосунків.
Якість моделі — те, за що платять хмарі. Серверна модель більша, навчається на свіжих даних і оновлюється без випуску нової версії застосунку. Локальна модель обмежена ресурсами телефона, тому її доводиться квантувати й урізати.
На типових категоріях — люди, їжа, тварини, пейзажі — різниця майже непомітна, але на рідкісних або специфічних класах хмара виграє.
Затримка обробки та трафік пов'язані напряму. Локальний інференс дає відгук за частки секунди й не залежить від якості зв'язку: розмітка з'являється, навіть коли телефон офлайн.
Хмара додає мережеве коло — на слабкому каналі це секунди очікування, а в роумінгу ще й витрата трафіку. При галереї в тисячі знімків різниця в трафіку стає відчутною.
На практиці межу ставлять не «або-або», а гібридно: базова класифікація йде на пристрої, а важкі або рідкісні випадки — коли користувач сам ініціює пошук за змістом — вирушають у хмару з явної згоди. Так приватність залишається за замовчуванням, а якість підключається там, де вона реально потрібна.
Кейс: як галерея на 40 000 знімків перестала гальмувати
Що було до змін
До нас прийшла команда з застосунком-галереєю: 40 000 знімків у активного користувача, класифікація виконувалася на пристрої в один потік прямо при відкритті розділу.
На холодному старті галерея показувала порожні плитки 4-6 секунд, пошук за категорією «документи» віддавав результат за 3,5 секунди, а частка помилкових категорій сягала 22% — знімки чеків і візитівок потрапляли в «інше». Користувачі просто гортали стрічку вручну, бо довіри до фільтрів не було.
Що змінили
Рознесли роботу на два етапи. Важку модель інференсу винесли у фонову чергу: вона обробляє нові знімки пачками, поки застосунок не на передньому плані, і не конкурує з відрисовкою інтерфейсу.
Легкий класифікатор за метаданими та мініатюрами дає попередню категорію одразу — користувач бачить результат миттєво, а точна мітка підставляється пізніше.
Результати інференсу складаємо в локальний індекс поруч із медіатекою, тому повторний запуск не перераховує вже оброблене.
Для помилкових категорій додали поріг впевненості: якщо модель не впевнена, знімок потрапляє в «нерозібране», а не у випадкову папку — це прибрало основну масу хибних спрацювань.
Стек і модель підбирали під задачу, фінальну збірку прогнали через наших інженерів на реальних користувацьких медіатеках.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Час пошуку за категорією | 3,5 с | 0,4 с |
| Частка помилкових категорій | 22% | 6% |
| Холодний старт галереї | 4-6 с | 1,2 с |
| Навантаження на пристрій при відкритті | пікове, з просіданням кадрів | рівне, без просідань |
Окремо відстежували частку знімків у «нерозібраному» — вона тримається в межах 4-5% і слугує чесним індикатором якості моделі: зростання означає, що з'явився новий тип контенту, під який потрібне донавчання.
Обговоримо ваше завдання класифікації фотографій
Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібні вихідні дані про вашу галерею.
Розкажіть, звідки надходять фотографії (камера, месенджери, імпорт із хмари), скільки їх в активного користувача та які категорії ви хочете виділяти — люди, документи, їжа, тварини, скриншоти.
Від цього залежить, чи будуємо ми класифікацію на готовій моделі, чи дообучаємо її під ваші сценарії.
Окремо уточнимо, де саме працює класифікація: на пристрої чи на сервері. Це впливає на приватність, швидкість відгуку та вимоги до підключення. Якщо фото не повинні залишати телефон, рахуємо на пристрої — тоді розмітка з'являється миттєво й без мережі.
- Приклади фотографій із розміткою: 200-500 знімків по кожній категорії, якщо є — з поточними помилками класифікації.
- Опис категорій: що вважаємо «документом», що «скриншотом», як бути з пограничними кадрами.
- Поточний стек застосунку: платформа, мова, як влаштовано зберігання та відображення галереї.
- Сценарій користувача: де показуємо категорії — у пошуку, в альбомах, у розумних добірках.
- Обмеження: вимоги до приватності, робота офлайн, цільові пристрої.
- Метрики успіху: яку частку кадрів класифікація повинна розмічати правильно і що вважаємо промахом.
За цими даними ми прикидаємо обсяг робіт, називаємо терміни та показуємо, де класифікація дасть ефект одразу, а де потребуватиме дообучення на ваших даних. Опишіть завдання — повернемося з оцінкою та планом.
