Комментарии 10
А почему не пошли по пути улучшения технологии выпекания? Ну, что бы как надо зажаривалось. Контроль рецептуры, температуры и времени - должен помочь или нет?
Привет! Технология выпекания на самом деле прописана в стандартах и периодически меняется и улучшается в зависимости от потребности.
Тут проблема в масштабировании. При более 700 точек с различными партнерами могут быть по каким-то причинам выставлены не те настройки, либо по каким-то причинам общие стандарты не подходят, либо же просто человеческий фактор.
Собственно для этого и нужен контроллинг, чтобы отслеживать такие ситуации *по конкретным пиццериям*, разбираться, что не так и помогать партнёру делать качественный продукт.
Меня всегда устраивал уровень запекания ваших пицц, поэтому я думал что все технологии выпечки уже отшлифованы. Думал что печи умные у вас, сами температуру нужную и время поддерживают.
Ну, мы стараемся) Но косяки случаются. Дело не только в пропекании, а в том числе, как раскатано тесто, как положили начинку и т.д.
И да, печи не настолько умные, скорее как кофе-машины, их надо уметь настраивать.
Так одно другому не мешает, нет? К тому же человеко-фактор все равно может напортачить в конечном результате, а все этапы создания пиццы ты не проработаешь.
Например то же "дно не прорезано". Это либо в каждую пиццерию завозить автоматы для нарезки пиццы (что звучит мягко говоря как перебор), либо как в статье - с фото быстренько прогнать через нейронку
habr.com/ru/company/ods/blog/422873
Надо сказать что в прошлый раз у вас модель была сильно лучше и адекватнее, судя по той статье:)
Оно конечно, не продуктовое небось было (в 2018 году в CV ещё не было удобного инженеринга моделей через MLFlow и Azure). Но делать для явных задач детекции классификацию — ну такое. Или у вас все же не чистая классификация, а какие-то детекторы?
Собственно, почему мы и решали эти задачи с помощью классификации:
1) потому что эти задачи действительно можно решить таким путем;
2) первоначально у нас не было датасета для детекции. Как я и писала выше, наши данные представляли собой изображения пицц с наименованием дефектов, которые на них были обнаружены. Дополнительно готовить разметку мы не стали, для начала решив попробовать решить эту задачу при помощи классификации. В случае неуспеха, безусловно, мы бы попробовали иной подход.
Также у нас остались дефекты, для обнаружения которых классификацией не обойтись, но об этом мы расскажем уже в следующий раз.
1) Дебаг классификатора и поиск его проблем и ошибок куда сложнее чем у детекционной модели. Вы видите что возрастает число ошибок на проде — но нет адекватного варианта посмотреть что вызывает эти ошибки. Остается два подхода: переобучить бездумно или угадать. И то и то не продуктовое решение.
Конечно, если у вас классификация на трансформерах, и есть нормальная attention map, то там чуть проще. Но все равно криво будет.
Если обобщить этот пункт — используя классификацию вы теряете прозрачность пайплайна работы.
2) Точность классификатора намного ниже если вы его используете для поиска мелкого дефекта, чем когда вы его используете к кропу найденной целевой области. На некоторых задачах я видел ухудшение метрик почти на порядок (например распознавание каких-нибудь деталей одежды/частей машин, и.т.д.). Да, эта разница будет минимальная если у вас обучающий датасет на много миллионов примеров, а используются в качестве бекбонов трансформеры, либо очень жирные сети. Но у меня сомнение что оно у вас так.
Ваши метрики это хорошо подтверждают, чем меньше площадь дефекта — тем хуже метрика. А уж сколько вы на этом теряете — это второй вопрос. Проще всего оценить сравнив с кроссразметкой людьми.
3) Обычно в задачах вашего плана один из основных источников ошибок — некорректные данные. Неправильный угол съемки/недостаточная видимость и.т.д.
И тут вам либо надо будет ещё один классификатор бахнуть, либо из нормального детектора/сегментатора оценивать набор параметров для работы.
Теперь что касается «не было датасета для детекции».
Сделать детекционную разметку/контейнеризировать её через какую-нибудь Толоку/MechanicalTurk — неделя (и потом просто поднимать нужные задачи по мере подхода новых данных, можно даже автоматом). Есть много фирм которые это очень дешево под заказ делают (или размечают, беря на себя ещё боль поддержания всего и вся).
В случае неуспеха, безусловно, мы бы попробовали иной подход.
Что было мерилом неуспеха?:)
И да, если не секрет, у вас работает ещё тот алгоритм который описан в статье habr.com/ru/company/ods/blog/422873? Вы сравнивали точность с ним?
Зарегистрировался, чтобы сказать: "Додо, прислушайтесь". Это очень грамотный ответ, особенно моменты про оценку модели через кросс-разметку и сравнение с предыдущей версией. Иначе получается сумбурное движение в тумане, а не решение бизнес-задачи.
Я бы ещё добавил, что можно использовать эвристику "если целевая область в среднем занимает меньше 20% изображения, стоит переходить к детекции/сегментации". 20 — это, конечно, число из головы и не стоит его воспринимать слишком серьёзно (если область интереса маленькая, контрастная и всегда находится в одной области изображения, то и классификация может работать), но всё же тут неправильный дизайн системы налицо. Предыдущее решение просто выглядят грамотнее. Пожалуйста, не воспринимайте в штыки и проконсультируйтесь со специалистами у которых есть опыт в дизайне CV-пайплайнов.
«У вашей пиццы дно белое!» Определяем дефекты с помощью компьютерного зрения