Класифікація об'єктів у мобільному додатку
Ми інтегруємо класифікацію об'єктів у мобільний додаток під ключ. На відміну від детекції, модель видає один вектор ймовірностей за класами. Здається простіше, але саме тут розробники найчастіше припускаються помилок: неправильно обирають поріг впевненості, ігнорують пост-обробку та забувають про UX. У цій статті розбираємо, як уникнути цих проблем і зробити класифікацію надійною та зручною для користувача. Досвід з Core ML, ML Kit, EfficientNet — понад 5 років у мобільній розробці.
Як обрати модель для класифікації?
Для топ-1000 класів (продукти, тварини, об'єкти побуту) підійдуть MobileNetV3-Large або EfficientNetB0/B1. Вони працюють out-of-the-box через ML Kit Image Labeling або Core ML з моделями з Apple Model Gallery. Для вузької предметної області (конкретний вид продукції, дефекти на виробництві) потрібна донавчена модель.
Порівняння популярних варіантів:
| Модель | Розмір | Точність (top-1) | Застосовність |
|---|---|---|---|
| MobileNetV3-Large | ~5 MB | 75.6% | Універсальна, швидка |
| EfficientNetB0 | ~8 MB | 77.1% | Баланс швидкості та точності |
| Кастомна (fine-tuned) | 5-10 MB | 80-90% (залежить від датасету) | Вузька предметна область |
| Тип рішення | Коли обрати | Приклад |
|---|---|---|
| Готова модель | Топ-1000 класів, швидкий старт | ML Kit Image Labeling |
| Fine-tuning | 10-50 класів, 200-500 прикладів на клас | Кастомна EfficientNet |
| Few-shot learning | Менше 50 прикладів на клас | Prototypical Networks |
Донавчання (fine-tuning) під кастомний датасет: беремо переднавчений backbone (MobileNetV2, EfficientNetB0), заморожуємо нижні шари, навчаємо лише верхні на своїх даних. Для 10–50 класів достатньо 200–500 прикладів на клас при правильній аугментації. Менше — потрібен few-shot підхід (Prototypical Networks). Після навчання конвертація в .mlmodel (iOS) або .tflite (Android), додавання metadata з іменами класів та параметрами нормалізації. EfficientNet — хороший вибір для балансу швидкості та точності.
Як обрати поріг впевненості?
Найчастіша помилка в UX — показувати результат класифікації без урахування confidence. Модель завжди повертає розподіл ймовірностей, argmax завжди видає «переможця» — навіть коли модель в нього не вірить. Якщо топ-1 клас має score 0.23 при наступному 0.21 — це не класифікація, а випадковість.
Правильний підхід: задати threshold (зазвичай 0.5–0.7 залежно від завдання). Якщо топ-1 нижче порогу — показуємо «не вдалося визначити» або просимо перезняти. Для критичних завдань (медицина, юридичні документи) — додатково перевіряємо entropy розподілу. Згідно з документацією Core ML, поріг задається через параметр confidenceThreshold у VNCoreMLRequest.
На iOS через VNCoreMLRequest:
request.imageCropAndScaleOption = .centerCrop let observations = results as? [VNClassificationObservation] let confident = observations?.filter { $0.confidence > 0.65 } На Android через ML Kit ImageLabeling:
val options = ImageLabelerOptions.Builder() .setConfidenceThreshold(0.65f) .build() Чому важлива пост-обробка результатів?
Показувати топ-3 класи з відсотками — правильно для освітніх та consumer-додатків. Для бізнес-додатків (автоматизація, склад) потрібен один впевнений результат або нічого. Пост-обробка включає не лише поріг, але й перевірку відстані між топ-1 та топ-2: якщо різниця мала — краще запросити підтвердження у користувача.
Кейс: додаток для інвентаризації на складі, класифікація 87 SKU через кастомну EfficientNetB0-модель. Початковий поріг 0.5 давав 12% хибних спрацьовувань. Після аналізу confusion matrix з’ясували: 80% помилок — між SKU зі схожою упаковкою. Додали другий рівень: якщо топ-2 та топ-3 сумарно більше 0.4, просимо оператора підтвердити вибір. Хибні спрацьовування впали до 2.1%.
UI результату: не перевантажувати користувача числами. Прогрес-бар або кольорова індикація (зелений/жовтий/червоний) сприймається краще, ніж «73.4%». Анімація появи результату через withAnimation (SwiftUI) або ObjectAnimator (Android) знижує відчуття «холодної» відповіді від моделі.
Що входить в роботу
При замовленні впровадження класифікації об'єктів ви отримуєте:
- Аналіз завдання та вибір архітектури моделі
- Fine-tuning на вашому датасеті (якщо потрібно)
- Конвертацію у формати
.mlmodel(iOS) /.tflite(Android) - Інтеграцію в додаток з налаштуванням потоку даних
- Налаштування порогів впевненості та пост-обробки
- Розробку UI для відображення результатів
- Тестування на реальних даних та виправлення помилок
- Документацію з використання та підтримку команди
Процес роботи
- Аналітика — розбираємо завдання, збираємо датасет, обираємо метрики
- Проектування — визначаємо архітектуру, pipeline обробки
- Реалізація — fine-tuning, конвертація, інтеграція
- Тестування — unit-тести, UI-тести, A/B-тести на впевненість
- Деплой — публікація в App Store / Google Play, моніторинг
Терміни та вартість
Інтеграція готової моделі в існуючий додаток — 3–5 днів. Fine-tuning кастомної моделі + інтеграція — 1–2 тижні. Вартість розраховується індивідуально — оцінимо ваш проект після первинної консультації. Ми гарантуємо якість та дотримання термінів, спираючись на понад 5 років досвіду в мобільній розробці.
Хочете впровадити класифікацію об'єктів? Зв'яжіться з нами — отримайте консультацію та попередню оцінку безкоштовно. Замовте впровадження класифікації у ваш додаток вже сьогодні.