"Медицинская точность в металлургии"

Привет! :)

Хочу рассказать про наш кейс с нетипичной моделью

Место действия - прекрасная Карелия, а наши герои - железнорудные окатыши (полуфабрикат для металлургического производства чугуна). Нам требовалось считать гранулометрический состав - то есть распределение размеров наших объектов.

Мы начали с детекции, и она работала очень хорошо. Качество устраивало, модель была стабильной, в проде всё вело себя предсказуемо — редкий случай, когда хочется просто сказать “не трогаем”🔥.

Но к нам пришёл бизнес : запрос был логичный и абсолютно понятный: “Можно не только находить объекты, но ещё:

- классифицировать их
- считать распределение классов?” 🥶

И вот тут начинается классическая развилка.

Самый очевидный путь — каскад:

детекция ➡️ обрезаем регионы ➡️ классификатор ➡️ агрегация

Рабочая схема, проверенная временем. Но у неё есть минусы, которые в индустрии быстро становятся болью:

__- усложнение пайплайна
- накопление ошибок
- больше точек отказа
- сложнее сопровождать и отлаживать__

А нам очень хотелось одну модель, а не зоопарк из нескольких.
И тут мы снова вернулись к данным. Если посмотреть на задачу не как на “детекция + классификация”, а как на разбор структуры сцены, становится понятно, что на самом деле нужно:

__- разделить объекты
- понять их форму и границы
- сразу отнести к нужному классу__

То есть по сути — сегментация с семантикой, а не просто боксы.

И здесь всплыло сходство с задачами сегментации клеток: плотные объекты, соприкасающиеся границы, вариативность размеров и форм, плюс необходимость различать типы.

Мы решили попробовать модель, изначально разработанную именно под такие сценарии. Не потому что модно (точно нет 😊) а потому что она естественно покрывала новые требования бизнеса без усложнения пайплайна.

Что получилось в итоге:

__- одна модель вместо каскада
- стабильное поведение в проде
- меньше ручной логики
- возможность сразу получать и геометрию, и классы, и распределения__

Важно 🥶: детекция сама по себе никуда не делась и остаётся отличным решением для многих задач. Но этот кейс хорошо показывает, как изменение бизнес-требований может полностью поменять оптимальное техническое решение.

И главный вывод здесь тот же: не бойтесь пересматривать удачные решения, если меняется постановка задачи.

Если вы хотите еще больше - то оставляю статью, которая появилась в процессе - тут: https://arxiv.org/abs/2506.11126.

К слову, мы можем поговорить и о том, как вообще публиковать статьи на arxiv в будущих постах