Добрый день! AlexeyAB прокомментируете v5?
Что-то он вышел буквально через месяц после вашего, но проработан куда слабее. Нет всей той массы сравнительных графиков, нет примеров под Jetson | OpenVino, нет даже банального сравнения на одном графике с v4.
Я так понимаю он не от вашей команды?
Вроде с таким подходом есть всякие проблемы при перекладывании на TensorRT/OpenVino. В этих фреймворках идёт достаточно глубока оптимизация порядка выполнения и структуры выполнения сети на карте. Мне кажется что так оптимизированная сеть может даже дольше работать. Но не уверен.
Пробовали?
Очень классная аналогия про Калмана. Надо взять на вооружение.
Сами регулярно объясняем заказчикам что не надо городить Калмана где можно взять что-нибудь попроще, что на порядок лучше для задачи, да ещё и отлаживать проще будет.
Всё-таки TPU от Intel и Jetson Nano это принципиально разные штуки. Первый сильно энергоэффективнее если сеть на нём работает. Но архитектура там сильно разная, как результат — производительность может рандомно прыгать. Но да, nano под tensorrt должен быть побыстрее в большинстве случаев.
Да не суть. Всё равно хорошо что новые сети появляются и точность растёт.
1) А что с поддержкой int8? Когда вышла YOLOv3 у нас какие-то были проблемы при попытке всё это перетащить на TensorRT (вроде с tiny там тоже что-то было весьма конкурентное). В результате получалось что какие-то аналоги под int8 были пошустрее без существенной потери качества по сравнению с Yolo.
В статье у вас вижу только int16. С int8 не тестили, или какие-то ограничения архитектуры?
2) Вообще этот проект интересно весьма выглядит — github.com/ceccocats/tkDNN на который вы ссылку приводите. Что-то я нигде на формумах под Jetson ссылок не видел. Хотя он должен массу проблем решать.
Это что-то новое?
3) А сколько fps показывает на Jetson tx2 и Jetson nano? На днях читал что на nano чуть ли не 1 fps у кого-то вышло.
Если что, то оптические EyeTracker по вебкам (да даже по среднем камерам типа RealSence) очень нестабильные и хреновенькие. Если вы попробуете из положения глаза вычислить куда они смотрит — то получите ошибку в лучшем случае ~5 градусов (если учтёте все 3д параметры головы). А обычно хуже, градусов 10-15.
Монитор на стандартной дистанции это примерно 40 градусов. Для остальных применений web-камера вообще не пригодна.
Если вы посмотрите как делают хорошие производители (например tobii — www.tobii.com ) — это обязательно 3D сборка (2 камеры, чтобы точнее ориентацию головы определить), обязательно работа в активном ИК спектре около 700-800nm, чтобы зрачки отражали ИК освещение и были ярко светлыми (повышает качество детекции, добавляет контраста с радужкой, позволяет работать при плохом освещении). И обязательно узкое поле камер (сильно уже чем у вебки), чтобы добавить разрешения.
Там точность для консюмерских устройств уже одного градуса, что неплохо.
Только вот для использования на практике (контроль выкладыки на полках, внимание операторов) всё равно делаются сильно более сложные устройства.
В целом не советую использовать ML там где есть явные физические ограничения. Лучше сначала оценить теоретический предел точности, а потом уже искать более большие датасеты.
Ну и да, даже если точности хватит, то я бы при обучении пробовал использовать ориентацию головы, а GT лейблить не разметчиками а через тот же tobii.
Я недавно как раз писал статью про разные эмбедед платформы: на RPi4 скорость работы Mobilnet 300*300 примерно 110ms (если v1, или если под какими-нибудь ускоренными фреймворками то быстрее).
Понятно, что ssd чуть медленнее, чем бэкбон. Но кадров 5-6 в секунду даст.
Честно говоря не понимаю зачем вам больше. 5fps для трекинга хватит, само событие кашля тоже не длится быстрее полусекунды.
Объекты разбивали на 4 класса, поэтому кашель с рукой и без руки можно отделить от смеха, например. Ошибок 1/2 рода много, но это вопрос выборки и размерности исходного датасета.
Боюсь что нет.
Как человек по отдельному кадру кашля без руки не может понять что происходит — так и система не сможет. Или вы хотите сказать что мобилнет вытаскивает больше человека? Вам тут больше классов особо не поможет.
Человек такие штуки отличает по динамике. И вы либо будете генерировать ложняки на речь, либо будете пропускать весь кашель без руки (которого большинство).
Где вы достанете датасет реально кашляющих людей?:) Вы же понимаете что покашлять на камеру и реальный кашель — это принципиально по-разному выглядит и звучит? И тут не хватит 100-200 кадров чтобы существующий детектор оттюнинговать.
Ну и да, про ошибки первого второго рода. Вот, предположим, доведёте вы их до уровня что всего на каждом десятом говорящем будет прокать детектор. И всего десять процентов кашляющих пропустит. Скорее всего всё будет сильно хуже, конечно. И что вы с этим сделаете?:) Как вам это поможет решить реальную проблему?
Звук — сложно. Область применения: вокзалы, аэропорты. Выделить нужная частоту от шума не получится. Да и для определения звука нужен направленный микрофон и фильтрация посторонних шумов, что сильно повышает сложность изделия и его развертывание.
Да и камера вам, поди, не одна нужна. От неё человек сможет отвернуться, зайти за другого человека, разрешения не хватить уже метрах в 7-8.
— Ну и да, главное — это глобальная оправданность. Кашель есть далеко не у всех. Как я понимаю когда кашель есть, тем более постоянный — это уже всё плохо совсем. Температура куда чаще встречается.
Пару вопросов. А если человек не прикрывает рукой рот?:) А если человек разговаривает/смеётся?
Мне кажется что ошибок первого и второго рода будет дофига, что сильно понижает осмысленность такого решения.
В целом по звуку, конечно, лучше. Но и там куча проблем на реальной эксплуатации выходит. И в отличие от изображений звук сложнее позволяет эти проблемы вычленить и понять.
И несколько непонятно зачем Intel и OpenVino тащить. В них нет ничего плохого, я их сам нежно люблю для некоторых их задач, но для SSD Mobilenet хватит и RPi, и JetsonNano, это сильно дешевле, по продуктовости может даже лучше (там есть хорошие корпуса, потребления меньше).
Где-то год назад добрались с женой до выставки Репина (в Новой Третьяковке была вроде).
Её решили сделать прогрессивной и интерактивной. При входе в залы написано, что можно сфотографировать картину через Алису от Яндекса и получить рассказ про картину. Работает хорошо, не считая что у половины картин инет не ловит. Но вот есть один нюанс:
Как только какая-то смотрительница видела что я фотографирую, то со всех сил бежала в нашу сторону и орёт на весь зал:
— Мужчина! Уберите телефон! Съемка на выставке запрещена!
— У вас же написано на входе что можно использовать Алису как гида.
— Что?! А. Ну да. А у вас точно Алиса?
И как-то всем пофиг, что и картины в инете можно скачать в высоком качестве. И что Алиса, естественно, всё что фотографирует — сохраняет в галерею. Нет, надо упороться и попробовать подпортить всем настроение.
И после этого очень любопытно как реальные музеи будут воспринимать ваш подход:)
Мне кажется, что всех технических «авторов» которые используют слово ИИ или AI надо карать и отправлять на перевоспитание. Пока они не научатся отличать ML от AI.
Или открывать первоначальную статью и вычитывать термины:
Правда SSD-300?
Ни SSD-mobilnet, ни SSD-resnet, ни SSD-efficientnet, ни любой другой приличный бэкбон?:)
Вообще всё звучит максимально далеко от реального прода. Может потому что у вас СБ запретило подробные данные публиковать, не знаю. Звучит как набор экспериментов с достаточно простыми сетками. Кажется, что даже у movidius с OpenVino реализация лучше.
Реальный прод сейчас очень железо ориентированный. Под каждую железку надо оптимизировать и нейронку, и логику работы, и постановку задачи. Будь это jetson|сервак или какая-то крафтовая железяка.
И да, постановка задачи обычно достаточно сильно изменяет логику, очень редко когда видишь чистую сеть. И разметка обычно интегрируется в прод, а не отдельной софтиной делается. И у сети вход/выход костылизируются.
Они не первые. Я писал статью, где рассматривал прошлую подобную работу -https://habr.com/ru/company/recognitor/blog/474674/
Проблема этого подхода, что в маммографии нет диагноза «рак/не рак» по рентгену.
Есть сильно более обширное дерево решений, в рамках которого пока что не существуют размеченных датасетов. Когда врач однозначно говорит «рак», то обычно там уже всё плохо.
Процентах в 20 вообще по мамограмме нельзя ничего сказать, в таком случае скрининг идёт через УЗИ.
Не сказать что нельзя применять результат обучения нейронной сети в реальном скрининге. Но надо очень много думать над тем как внедрять в существующие стандарты метрику которая написана вне их рамок.
Кстати, если я правильно понимаю что Google сделал, то они сильно по более простому датасету обучали чем та работа которую упоминал я.
Вторая крутая статья за две недели! Как у вас сил хватает!:)
Главное что в текущем прогрессе смущает — что почти нет кардинально новых идей. По сути все новые алгоритмы/идей/результаты — это обсасывание идей и подходов 4-5 летней давности. Те же GAN — это 14 год.
С другой стороны наука так и должна работать. Нужно сначала сформулировать почему то что получилось не является ИИ. А когда задача будет сформулирована и понятна — тогда уже можно будет попробовать её решить.
Пока что-то всё упирается в «нужно больше хороших датасетов»/«как нам организовать разметку»:)
Добрый день!
Спасибо за статью, интересный взгляд.
Но мне кажется, что кризис жанра несколько в другом. Я не спорю, что статьи ужасны. Но это в том же ComputerVision было сильно до нейронных сетей. Я эту тему с 2008 года где-то пилю — и всегда всё одинаково. Результаты «неточны»/«не воспроизводимы»/«не имеют смысла»/" раздуты". Просто раньше это было значительно сложнее поймать (я помню сколько времени занимала сборка и установка OpenCV году в 2010...). Но вот, например, моя статья на Хабре за 2014 год, когда я показываю что алгоритм усиления движений работает на реальных данных сильно хуже чем приводят авторы. Сегодня тестировать сильно быстрее статьи в 90% случаях при наличии исходников. Есть некоторые сформировавшиеся правила приличия.
На мой взгляд текущий кризис скорее про неоднозначность постановки целевой задачи. Взять ту же медицину. Ну нет сегодня в ней задачи «найти рак по маммографии». Нет таких ответов в терминологии современных врачей. Она куда шире/богаче/неоднозначнее. И именно оттуда идёт неоднозначность датасетов/неоднозначность применения и понимания.
Нейронки это очень тонкий инструмент, которым можно очень круто решать некоторые задачи в ограниченной постановке. Но эту постановку надо сначала создать/оттестировать/понять. А это могут единицы. Это не могут инвесторы. Не могут большинство руководителей проектов. И тем более не может младое поколение нейроучёных.
И уже из этой проблемы неоднозначности + навязанного статьями мнения «всё хорошо работает» — прут все дальнейшие проблемы…
Некоторые хотят использовать в бизнесе нейросети уже только потому, что это популярно.
Проблема в том, что люди хотят использовать нейросети только потому что «популярно», или потому что «начальство требует». Видел это в десятках проявлений. «Цифровизация бизнеса», «развитие продукта», и.т.д.
Я бы не советовал брать такие проекты вообще. Проект можно брать только когда он идёт от реальной проблемы или хотя бы от гипотезы и её проверки. Тогда будет реальная работа и проект. Остальное — это раскрутка заказчика на деньги. Мерзко и некрасиво.
«Нам нужна нейросеть для решения такой-то задачи»
Если клиент может чётко обозначить проблему — это уже хорошо. Но я такое видел достаточно редко. Приходит и говорит «нам нужно распознавание того-то с такой точностью». И 99% проблемы в том чтобы объяснить заказчику что такая постановка задачи может вообще не существовать. Потому что даже человеческая разметка по тому датасету даст 70%) Я как то даже на эту тему тут статью писал.
«Мы хотим нейронную сеть которая будет по медицинским снимкам ставить человеку диагноз заболевания. Сколько времени это займет?»
Вот это хороший пример, кстати. В большинстве случаев проблема не в точности. А в том что врачи одинаковый диагноз поставить не могут обычно. По КТ, Мамографии, Флюрке, и.т.д, и.т.п. Вот и появляются на рынке 100-500-800 стартапов которые распознают мамографию на 91%. Но только внедрить это никуда нельзя, так как существующие инфраструктуры/методы работы врачей/техника — для этого не предназначена. Опять же, писал про это.
С серверами проблем не будет
Знаете. У нас в год 7-8 проектов по ML. И ни разу не было проблем в этой части. Там все риски очень хорошо считаются и расписываются. Обычно все риски лежат в плоскости «удастся ли портировать с приемлемой точностью оставаясь в рамках допустимой скорости или нет». И это просто реализуется как отдельное исследование.
Нигде никогда не видел подходов где бы нельзя было заранее всё оценить.
И, если честно, сложно представить выход на 5 миллионов классов, где бы нельзя было сделать эмбединг и искать уже в пространстве эмбедингов на инференсе. Но может чего-то не знаю.
Лучше все же игнорировать пока. РЛ иногда хорошо работает на синтетике когда очень много примеров. Была очень классная статья на эту тему: https://www.alexirpan.com/2018/02/14/rl-hard.html
С тех пор ничего не изменилось и все аргументы пока актуальны.
На Хабре где то был её перевод, а ещё неплохая такая статья — https://m.habr.com/ru/post/437020/
Спасибо!
Я в первую очередь имел ввиду проекты типа IBM Vatson и похожие штуки, котооые ближе к классическим деревьям: структуризация, поиск оптимального дерева, итд. Там много что уже внедрено, но оно редко на уровне пациента видно. При этом граница между классическим ML (svm, решающие деревья) и всякими новомодными нетривиально проходит. А учитывая что я это со стороны только видел — боюсь что могу накосячить рассуждая что как устроено. Про визуальную диагностику осанки слышал только что люди что то по выделенным скелетам пробовали делать, но давно и не помню где.
Это очень правильная архитектура! Надеюсь у вас все успешно получится. Вообще мне кажется что у вас будет очень интересный экспирианс на тему того что заключение районного и регионального врача будут разные в 50%случаев если там что то выше bi-rads-1:)
Страховая — это хороший регулятор. Но есть вариант «рынка». Самые современные по инновациям — частные клиники. Там и информационная система, и современное оборудование.
Если разбираться глубже, то даже поликлиника/больница — это бизнес единица. Сейчас многие на самоокупаемости. Деньги они получают за страховки/за платные услуги. Главврачи определяют бюджет/зарплаты. Они конкурируют за врачей. Если им выгодно поставить какой-то алгоритм — они ставят.
В Москве есть сейчас ДИТ. От него идут какие-то инновации. Но, конечно, это не самый правильный путь.
Врачам никогда не будет интересна система, которая заменяет врача, потому что она отбирает у них хлеб.
Это не совсем так. И автоматический анализ ЭКГ уже давно внедрён. И куча анализов уже давно внедрены.
Да и сами врачи в первых рядах голосуют за введение систем автоматизации документаоборота.
Просто внедрять надо аккуратно.
Это очень тонкая грань, по моему опыту врачи любят heatmap и диаграммы признаков (слой показателей перед max/softmax), им это нравится.
Пробовали внедрять и так и так. Общался с большим числом компаний, которые пробовали внедрять. Врачи говорят «да, прикольно», пока ты им прототип показываешь. Заставляешь пользоваться — отключают/не интересно/зачем мне это.
Такая штука не автоматизирует/ не помогает в работе/не несёт особого смысла.
Я понимаю почему оно может быть внедрено на уровне аппаратуры. Но это скорее инвестиция в будущее. Сегодняшние врачи будут пользоваться только тем что будет экономить их время/заполнять за них документы.
AlexeyAB прокомментируете v5?
Что-то он вышел буквально через месяц после вашего, но проработан куда слабее. Нет всей той массы сравнительных графиков, нет примеров под Jetson | OpenVino, нет даже банального сравнения на одном графике с v4.
Я так понимаю он не от вашей команды?
Пробовали?
Сами регулярно объясняем заказчикам что не надо городить Калмана где можно взять что-нибудь попроще, что на порядок лучше для задачи, да ещё и отлаживать проще будет.
Да не суть. Всё равно хорошо что новые сети появляются и точность растёт.
В статье у вас вижу только int16. С int8 не тестили, или какие-то ограничения архитектуры?
2) Вообще этот проект интересно весьма выглядит — github.com/ceccocats/tkDNN на который вы ссылку приводите. Что-то я нигде на формумах под Jetson ссылок не видел. Хотя он должен массу проблем решать.
Это что-то новое?
3) А сколько fps показывает на Jetson tx2 и Jetson nano? На днях читал что на nano чуть ли не 1 fps у кого-то вышло.
Монитор на стандартной дистанции это примерно 40 градусов. Для остальных применений web-камера вообще не пригодна.
Если вы посмотрите как делают хорошие производители (например tobii — www.tobii.com ) — это обязательно 3D сборка (2 камеры, чтобы точнее ориентацию головы определить), обязательно работа в активном ИК спектре около 700-800nm, чтобы зрачки отражали ИК освещение и были ярко светлыми (повышает качество детекции, добавляет контраста с радужкой, позволяет работать при плохом освещении). И обязательно узкое поле камер (сильно уже чем у вебки), чтобы добавить разрешения.
Там точность для консюмерских устройств уже одного градуса, что неплохо.
Только вот для использования на практике (контроль выкладыки на полках, внимание операторов) всё равно делаются сильно более сложные устройства.
В целом не советую использовать ML там где есть явные физические ограничения. Лучше сначала оценить теоретический предел точности, а потом уже искать более большие датасеты.
Ну и да, даже если точности хватит, то я бы при обучении пробовал использовать ориентацию головы, а GT лейблить не разметчиками а через тот же tobii.
Понятно, что ssd чуть медленнее, чем бэкбон. Но кадров 5-6 в секунду даст.
Честно говоря не понимаю зачем вам больше. 5fps для трекинга хватит, само событие кашля тоже не длится быстрее полусекунды.
Боюсь что нет.
Человек такие штуки отличает по динамике. И вы либо будете генерировать ложняки на речь, либо будете пропускать весь кашель без руки (которого большинство).
Да и камера вам, поди, не одна нужна. От неё человек сможет отвернуться, зайти за другого человека, разрешения не хватить уже метрах в 7-8.
— Ну и да, главное — это глобальная оправданность. Кашель есть далеко не у всех. Как я понимаю когда кашель есть, тем более постоянный — это уже всё плохо совсем. Температура куда чаще встречается.
Мне кажется что ошибок первого и второго рода будет дофига, что сильно понижает осмысленность такого решения.
В целом по звуку, конечно, лучше. Но и там куча проблем на реальной эксплуатации выходит. И в отличие от изображений звук сложнее позволяет эти проблемы вычленить и понять.
И несколько непонятно зачем Intel и OpenVino тащить. В них нет ничего плохого, я их сам нежно люблю для некоторых их задач, но для SSD Mobilenet хватит и RPi, и JetsonNano, это сильно дешевле, по продуктовости может даже лучше (там есть хорошие корпуса, потребления меньше).
Её решили сделать прогрессивной и интерактивной. При входе в залы написано, что можно сфотографировать картину через Алису от Яндекса и получить рассказ про картину. Работает хорошо, не считая что у половины картин инет не ловит. Но вот есть один нюанс:
Как только какая-то смотрительница видела что я фотографирую, то со всех сил бежала в нашу сторону и орёт на весь зал:
— Мужчина! Уберите телефон! Съемка на выставке запрещена!
— У вас же написано на входе что можно использовать Алису как гида.
— Что?! А. Ну да. А у вас точно Алиса?
И как-то всем пофиг, что и картины в инете можно скачать в высоком качестве. И что Алиса, естественно, всё что фотографирует — сохраняет в галерею. Нет, надо упороться и попробовать подпортить всем настроение.
И после этого очень любопытно как реальные музеи будут воспринимать ваш подход:)
Или открывать первоначальную статью и вычитывать термины:
Ни SSD-mobilnet, ни SSD-resnet, ни SSD-efficientnet, ни любой другой приличный бэкбон?:)
Вообще всё звучит максимально далеко от реального прода. Может потому что у вас СБ запретило подробные данные публиковать, не знаю. Звучит как набор экспериментов с достаточно простыми сетками. Кажется, что даже у movidius с OpenVino реализация лучше.
Реальный прод сейчас очень железо ориентированный. Под каждую железку надо оптимизировать и нейронку, и логику работы, и постановку задачи. Будь это jetson|сервак или какая-то крафтовая железяка.
И да, постановка задачи обычно достаточно сильно изменяет логику, очень редко когда видишь чистую сеть. И разметка обычно интегрируется в прод, а не отдельной софтиной делается. И у сети вход/выход костылизируются.
Короче очень странный рассказ…
Проблема этого подхода, что в маммографии нет диагноза «рак/не рак» по рентгену.
Есть сильно более обширное дерево решений, в рамках которого пока что не существуют размеченных датасетов. Когда врач однозначно говорит «рак», то обычно там уже всё плохо.
Процентах в 20 вообще по мамограмме нельзя ничего сказать, в таком случае скрининг идёт через УЗИ.
Не сказать что нельзя применять результат обучения нейронной сети в реальном скрининге. Но надо очень много думать над тем как внедрять в существующие стандарты метрику которая написана вне их рамок.
Кстати, если я правильно понимаю что Google сделал, то они сильно по более простому датасету обучали чем та работа которую упоминал я.
Главное что в текущем прогрессе смущает — что почти нет кардинально новых идей. По сути все новые алгоритмы/идей/результаты — это обсасывание идей и подходов 4-5 летней давности. Те же GAN — это 14 год.
С другой стороны наука так и должна работать. Нужно сначала сформулировать почему то что получилось не является ИИ. А когда задача будет сформулирована и понятна — тогда уже можно будет попробовать её решить.
Пока что-то всё упирается в «нужно больше хороших датасетов»/«как нам организовать разметку»:)
Спасибо за статью, интересный взгляд.
Но мне кажется, что кризис жанра несколько в другом. Я не спорю, что статьи ужасны. Но это в том же ComputerVision было сильно до нейронных сетей. Я эту тему с 2008 года где-то пилю — и всегда всё одинаково. Результаты «неточны»/«не воспроизводимы»/«не имеют смысла»/" раздуты". Просто раньше это было значительно сложнее поймать (я помню сколько времени занимала сборка и установка OpenCV году в 2010...). Но вот, например, моя статья на Хабре за 2014 год, когда я показываю что алгоритм усиления движений работает на реальных данных сильно хуже чем приводят авторы. Сегодня тестировать сильно быстрее статьи в 90% случаях при наличии исходников. Есть некоторые сформировавшиеся правила приличия.
На мой взгляд текущий кризис скорее про неоднозначность постановки целевой задачи. Взять ту же медицину. Ну нет сегодня в ней задачи «найти рак по маммографии». Нет таких ответов в терминологии современных врачей. Она куда шире/богаче/неоднозначнее. И именно оттуда идёт неоднозначность датасетов/неоднозначность применения и понимания.
Нейронки это очень тонкий инструмент, которым можно очень круто решать некоторые задачи в ограниченной постановке. Но эту постановку надо сначала создать/оттестировать/понять. А это могут единицы. Это не могут инвесторы. Не могут большинство руководителей проектов. И тем более не может младое поколение нейроучёных.
И уже из этой проблемы неоднозначности + навязанного статьями мнения «всё хорошо работает» — прут все дальнейшие проблемы…
Проблема в том, что люди хотят использовать нейросети только потому что «популярно», или потому что «начальство требует». Видел это в десятках проявлений. «Цифровизация бизнеса», «развитие продукта», и.т.д.
Я бы не советовал брать такие проекты вообще. Проект можно брать только когда он идёт от реальной проблемы или хотя бы от гипотезы и её проверки. Тогда будет реальная работа и проект. Остальное — это раскрутка заказчика на деньги. Мерзко и некрасиво.
Если клиент может чётко обозначить проблему — это уже хорошо. Но я такое видел достаточно редко. Приходит и говорит «нам нужно распознавание того-то с такой точностью». И 99% проблемы в том чтобы объяснить заказчику что такая постановка задачи может вообще не существовать. Потому что даже человеческая разметка по тому датасету даст 70%) Я как то даже на эту тему тут статью писал.
Вот это хороший пример, кстати. В большинстве случаев проблема не в точности. А в том что врачи одинаковый диагноз поставить не могут обычно. По КТ, Мамографии, Флюрке, и.т.д, и.т.п. Вот и появляются на рынке 100-500-800 стартапов которые распознают мамографию на 91%. Но только внедрить это никуда нельзя, так как существующие инфраструктуры/методы работы врачей/техника — для этого не предназначена. Опять же, писал про это.
Знаете. У нас в год 7-8 проектов по ML. И ни разу не было проблем в этой части. Там все риски очень хорошо считаются и расписываются. Обычно все риски лежат в плоскости «удастся ли портировать с приемлемой точностью оставаясь в рамках допустимой скорости или нет». И это просто реализуется как отдельное исследование.
Нигде никогда не видел подходов где бы нельзя было заранее всё оценить.
И, если честно, сложно представить выход на 5 миллионов классов, где бы нельзя было сделать эмбединг и искать уже в пространстве эмбедингов на инференсе. Но может чего-то не знаю.
Лучше все же игнорировать пока. РЛ иногда хорошо работает на синтетике когда очень много примеров. Была очень классная статья на эту тему:
https://www.alexirpan.com/2018/02/14/rl-hard.html
С тех пор ничего не изменилось и все аргументы пока актуальны.
На Хабре где то был её перевод, а ещё неплохая такая статья — https://m.habr.com/ru/post/437020/
Если у вас это выйдет — будет куда круче и практичнее любого машинного обучения)
Спасибо!
Я в первую очередь имел ввиду проекты типа IBM Vatson и похожие штуки, котооые ближе к классическим деревьям: структуризация, поиск оптимального дерева, итд. Там много что уже внедрено, но оно редко на уровне пациента видно. При этом граница между классическим ML (svm, решающие деревья) и всякими новомодными нетривиально проходит. А учитывая что я это со стороны только видел — боюсь что могу накосячить рассуждая что как устроено. Про визуальную диагностику осанки слышал только что люди что то по выделенным скелетам пробовали делать, но давно и не помню где.
Это очень правильная архитектура! Надеюсь у вас все успешно получится. Вообще мне кажется что у вас будет очень интересный экспирианс на тему того что заключение районного и регионального врача будут разные в 50%случаев если там что то выше bi-rads-1:)
Если разбираться глубже, то даже поликлиника/больница — это бизнес единица. Сейчас многие на самоокупаемости. Деньги они получают за страховки/за платные услуги. Главврачи определяют бюджет/зарплаты. Они конкурируют за врачей. Если им выгодно поставить какой-то алгоритм — они ставят.
В Москве есть сейчас ДИТ. От него идут какие-то инновации. Но, конечно, это не самый правильный путь.
Это не совсем так. И автоматический анализ ЭКГ уже давно внедрён. И куча анализов уже давно внедрены.
Да и сами врачи в первых рядах голосуют за введение систем автоматизации документаоборота.
Просто внедрять надо аккуратно.
Пробовали внедрять и так и так. Общался с большим числом компаний, которые пробовали внедрять. Врачи говорят «да, прикольно», пока ты им прототип показываешь. Заставляешь пользоваться — отключают/не интересно/зачем мне это.
Такая штука не автоматизирует/ не помогает в работе/не несёт особого смысла.
Я понимаю почему оно может быть внедрено на уровне аппаратуры. Но это скорее инвестиция в будущее. Сегодняшние врачи будут пользоваться только тем что будет экономить их время/заполнять за них документы.