Пылесос? Нет, это скорее громкий клаксон, который "перекричит" соседнюю машину на перекрестке. И включают такой клаксон все кому ни попадя в любое время суток. :-(
Поддерживаю. Имею несколько скриптов на Питоне, которые запускаются по расписанию: каждый раз с диска читаются десятки и сотни мегабайт (при этом сам скрипт десяток строк). То же самое, написанное на C++, C# или Делфи потребует намного меньше ресурсов.
При переносе питоновского скрипта на другой PC нужно довольно много телодвижений. А вот скомпилированный бинарник зачастую нужно просто скопировать.
Добавим - "на данный момент". Если на Firefox будет лучше блокироваться реклама, то есть вероятность, что 69% могут быстро превратиться в 30%. Если бы под Хром вообще не было бы блокировщиков рекламы, то это произошло бы быстрее (или заставило бы Гугл откатиться к V2).
Но откуда взялись эти "11 миллиардов миль"? Я думаю очень многое зависит от оборудования, схемы обучения, конфигурации нейронной сети (причем все три компонента важны, непонятно что важнее). Кстати: "Программное обеспечение Tesla было обучено на основе 3 миллиардов миль, пройденных автомобилями Tesla по дорогам общего пользования, по состоянию на апрель 2020 года ." (https://hmong.ru/wiki/Tesla_Autopilot)
Я бы, видимо, начал с бюджетного варианта, описанного тут https://habr.com/ru/company/yandex/blog/574466/ т.е. создание максимально децентрализованной отказоустойчивой системы (понятно, что КПД не будет 100%).
В ходе разработки pytorch я наталкивался на упоминания, что вроде можно тензоры загонять асинхронно в память GPU. Т.е. загнали маленький минибатч, запустили обучение и тут же загоняем второй минибатч не дожидаясь окончания обучения (но сам не делал, т.к. видеопамяти у меня катастрофически мало). И в этом случае узким местом вполне может стать CPU.
PCIe 1.x x1 (это самая младшая версия) в теории может прогонять 600 картинок/сек (320x320 RGB пикселей). SSD диски на ней показывают скорости порядка 200 МБ/сек. PCIe 2.0 — вдвое быстрее.
В современных реалиях данных очень много и они не влезут в память видеокарты (представьте какое-нибудь обучение на видео, к примеру вождение машины). Поэтому обучение идет мини-порциями (mini batch), как правило скорости шины вполне хватает (время работы нейросети намного больше времени передачи данных), и только на крошечных нейросетях мы увидим, что GPU почти простаивает. Хотя я тут на Хабре читал, что и для нормальных нейросетей могут быть проблемы (отследили по аномально низкой температуре GPU).
Про этап создания моделей вы написали "поиск аномалий (в случаях, например, некорректной работы датчиков)". Т.е. часть данных вы выкинули? А предусмотрели, что при реальной работе часть датчиков может забарахлить (выдавать всегда -1, или завышать показания на 1000, или вообще хаотически меняться)? Что будет с результатами модели, если один из ключевых датчиков начнет себя неадекватно вести?
В данном случае мы обязаны использовать только судна на подводных крыльях и предполагаю, что там будут проблемы (неспроста судна на подводных крыльях не очень популярны). Сама идея запасать энергию в виде чистого водорода очень соблазнительна и перспективна. Закачивать в баллоны можно, тем более на морских судах с хорошей грузоподъемностью.
Давно существуют вертикальные ветрогенераторы. +Были варианты с воздушными змеями (правда думаю там технических проблем много). Т.е. доплываем до места, где хороший ветер, там подтормаживаем (якорь, плавучий водный якорь) и вырабатываем водород, а потом возвращаемся в порт.
-- Вот есть у тебя лист металла толщиной 1 мм, а ты штампом будешь вытягивать её по кривой - какая толщина получится у новой формы? -- Проектируешь какую-нибудь подвесную цепь и знаешь формулу, по которой будет висеть цепь - как оценить массу цепи?
Перекрытие 3 - это 300% работы? На первый взгляд далеко от идеала.
Я вижу фразу " предсказание хорошей нейронкой", но не могу в контексте понять что именно нейронка делала. Я бы создал выборку без перекрытия. Потом часть выборки преднамеренно испортил и обозначил бы как "false" и таким образом сделал бы обучающую выборку для нейросети, которая определяет качество разметки (возможно две итерации обучения: обучение, чистка выборки только что созданной нейросеткой и дообучение). Спорные и все false результаты на валидацию. Подозреваю, что перекрытие было бы намного меньше (10-50%).
Другое дело размер этих кодов - представьте большую статую и рядом QR код размером с табуретку - думаю не пойдет. Аналогично маленькая марка и QR-код как сама марка. Т.е. эстетически может быть неудобно (но из-за отказа от QR точность падает).
" эти снимки не должны участвовать в тренировке" - типичной практикой является разделение всех данных на три части: обучающая (60-80%), проверочная (20-10%) и валидационная (20-10%). Первая активно влияет на обучение, вторая пассивно (смотрим момент начала переобучения), третья вообще не участвует в обучении. Это нормальная практика.
" снимки делаются только после того, как врач уже направил на обследование" - уже было сказано, что снимки делаются всегда с ведома врача. Тут важно другое: убедиться, что снимки делаются в одинаковых условиях/качестве. При обучении можно пытаться имитировать разные условия (вносить шум, изменять резкость, контрастность, добавлять посторонние предметы), но это не будет гарантией устойчивости нейронки к изменению условий съемки. Проблема обучения на несбалансированном наборе данных известна давно и существуют способы бороться с этим. Так что потенциально нужны только большие массивы размеченных исторических данных (хотя как показывает практика, иногда можно использовать и не размеченные данные! Semi-Supervised learning).
Тут сразу стали говорить про точность (и это правильно).
90% accuracy на нашем несбалансированном наборе данных может быть очень плохо (тут лучше F1 мера). Особенно плохи ложно-отрицательные предсказания (ложно-положительные увеличат нагрузку на медиков, но не должны ухудшить здоровье).
Никто не запрещает сделать нейронку, которая будет оценивать надежность прогноза. К примеру нейронка на 99.5% уверена, что рака нет - откладываем снимок до момента, когда врач освободится. Если уверенность нейронки 70%, то кладем снимок поближе - сортируем снимки по степени важности/срочности. Я думаю с банальными случаями нейронка спокойно справится (даже если это 50%, то врачу уже намного легче).
Другой вариант применения. Нейронка говорит 90% вероятность, а живой врач - "здорова". Это может быть причиной отправить снимок еще одному-двум врачам (или как минимум попросить пациента повторно обследоваться через 6 месяцев).
Почему так странно? У нас ведь есть исторические данные. Берем снимки 5-летней давности и смотрим истории болезни (или здоровья). И с высокой степенью точности определяем сколько ошибается врач (к примеру 5 лет назад врач сказал "здорова", а спустя год-другой выявили рак) и как часто ошибается нейронка. Я надеюсь качество снимков 5 лет назад было сопоставимым с сегодняшним днем?
Другое дело, что многое упирается в приватность мед. инфы. В сложности найти в электронном виде историю. Но сейчас с каждым годом цифровизации больниц это должно быть проще.
А еще у Huawei: "на телефонах и планшетах с EMUI 9.0, Magic UI 2.1 или более поздней версией функции Умная зарядка и Умная емкость батареи добавлены в модуль управления питанием." (Вроде как с 2019 года, видел на одном бюджетном смартфоне.)
Пылесос? Нет, это скорее громкий клаксон, который "перекричит" соседнюю машину на перекрестке. И включают такой клаксон все кому ни попадя в любое время суток. :-(
Поддерживаю. Имею несколько скриптов на Питоне, которые запускаются по расписанию: каждый раз с диска читаются десятки и сотни мегабайт (при этом сам скрипт десяток строк). То же самое, написанное на C++, C# или Делфи потребует намного меньше ресурсов.
При переносе питоновского скрипта на другой PC нужно довольно много телодвижений. А вот скомпилированный бинарник зачастую нужно просто скопировать.
Добавим - "на данный момент". Если на Firefox будет лучше блокироваться реклама, то есть вероятность, что 69% могут быстро превратиться в 30%. Если бы под Хром вообще не было бы блокировщиков рекламы, то это произошло бы быстрее (или заставило бы Гугл откатиться к V2).
А тут мы начинаем изучать бинарные отравляющие вещества и остаемся какое-то время живы.
Но откуда взялись эти "11 миллиардов миль"? Я думаю очень многое зависит от оборудования, схемы обучения, конфигурации нейронной сети (причем все три компонента важны, непонятно что важнее).
Кстати: "Программное обеспечение Tesla было обучено на основе 3 миллиардов миль, пройденных автомобилями Tesla по дорогам общего пользования, по состоянию на апрель 2020 года ." (https://hmong.ru/wiki/Tesla_Autopilot)
Я бы, видимо, начал с бюджетного варианта, описанного тут https://habr.com/ru/company/yandex/blog/574466/ т.е. создание максимально децентрализованной отказоустойчивой системы (понятно, что КПД не будет 100%).
В ходе разработки pytorch я наталкивался на упоминания, что вроде можно тензоры загонять асинхронно в память GPU. Т.е. загнали маленький минибатч, запустили обучение и тут же загоняем второй минибатч не дожидаясь окончания обучения (но сам не делал, т.к. видеопамяти у меня катастрофически мало). И в этом случае узким местом вполне может стать CPU.
PCIe 1.x x1 (это самая младшая версия) в теории может прогонять 600 картинок/сек (320x320 RGB пикселей). SSD диски на ней показывают скорости порядка 200 МБ/сек. PCIe 2.0 — вдвое быстрее.
В современных реалиях данных очень много и они не влезут в память видеокарты (представьте какое-нибудь обучение на видео, к примеру вождение машины). Поэтому обучение идет мини-порциями (mini batch), как правило скорости шины вполне хватает (время работы нейросети намного больше времени передачи данных), и только на крошечных нейросетях мы увидим, что GPU почти простаивает. Хотя я тут на Хабре читал, что и для нормальных нейросетей могут быть проблемы (отследили по аномально низкой температуре GPU).
Про этап создания моделей вы написали "поиск аномалий (в случаях, например, некорректной работы датчиков)". Т.е. часть данных вы выкинули? А предусмотрели, что при реальной работе часть датчиков может забарахлить (выдавать всегда -1, или завышать показания на 1000, или вообще хаотически меняться)? Что будет с результатами модели, если один из ключевых датчиков начнет себя неадекватно вести?
В данном случае мы обязаны использовать только судна на подводных крыльях и предполагаю, что там будут проблемы (неспроста судна на подводных крыльях не очень популярны). Сама идея запасать энергию в виде чистого водорода очень соблазнительна и перспективна. Закачивать в баллоны можно, тем более на морских судах с хорошей грузоподъемностью.
Давно существуют вертикальные ветрогенераторы. +Были варианты с воздушными змеями (правда думаю там технических проблем много). Т.е. доплываем до места, где хороший ветер, там подтормаживаем (якорь, плавучий водный якорь) и вырабатываем водород, а потом возвращаемся в порт.
Я бы облицовал старыми телефонными справочниками :-)
https://youtu.be/_xqMsQPyQJA
а лучше облицовать быстро съемными каменными плиточками https://youtu.be/t2K94sxnfUE?t=374
-- Вот есть у тебя лист металла толщиной 1 мм, а ты штампом будешь вытягивать её по кривой - какая толщина получится у новой формы?
-- Проектируешь какую-нибудь подвесную цепь и знаешь формулу, по которой будет висеть цепь - как оценить массу цепи?
"Выбери единственное верное утверждение про Random Forest." - судя по ответу имеется в виду стадия обучения.
(Получил 10. Мог бы 11. Часть вопросов, как пример выше, не совсем понятна.)
Перекрытие 3 - это 300% работы? На первый взгляд далеко от идеала.
Я вижу фразу " предсказание хорошей нейронкой", но не могу в контексте понять что именно нейронка делала. Я бы создал выборку без перекрытия. Потом часть выборки преднамеренно испортил и обозначил бы как "false" и таким образом сделал бы обучающую выборку для нейросети, которая определяет качество разметки (возможно две итерации обучения: обучение, чистка выборки только что созданной нейросеткой и дообучение). Спорные и все false результаты на валидацию. Подозреваю, что перекрытие было бы намного меньше (10-50%).
кто мешает сделать QR-коды с разных сторон?
Другое дело размер этих кодов - представьте большую статую и рядом QR код размером с табуретку - думаю не пойдет. Аналогично маленькая марка и QR-код как сама марка. Т.е. эстетически может быть неудобно (но из-за отказа от QR точность падает).
" эти снимки не должны участвовать в тренировке" - типичной практикой является разделение всех данных на три части: обучающая (60-80%), проверочная (20-10%) и валидационная (20-10%). Первая активно влияет на обучение, вторая пассивно (смотрим момент начала переобучения), третья вообще не участвует в обучении. Это нормальная практика.
" снимки делаются только после того, как врач уже направил на обследование" - уже было сказано, что снимки делаются всегда с ведома врача. Тут важно другое: убедиться, что снимки делаются в одинаковых условиях/качестве. При обучении можно пытаться имитировать разные условия (вносить шум, изменять резкость, контрастность, добавлять посторонние предметы), но это не будет гарантией устойчивости нейронки к изменению условий съемки. Проблема обучения на несбалансированном наборе данных известна давно и существуют способы бороться с этим. Так что потенциально нужны только большие массивы размеченных исторических данных (хотя как показывает практика, иногда можно использовать и не размеченные данные! Semi-Supervised learning).
Тут сразу стали говорить про точность (и это правильно).
90% accuracy на нашем несбалансированном наборе данных может быть очень плохо (тут лучше F1 мера). Особенно плохи ложно-отрицательные предсказания (ложно-положительные увеличат нагрузку на медиков, но не должны ухудшить здоровье).
Никто не запрещает сделать нейронку, которая будет оценивать надежность прогноза. К примеру нейронка на 99.5% уверена, что рака нет - откладываем снимок до момента, когда врач освободится. Если уверенность нейронки 70%, то кладем снимок поближе - сортируем снимки по степени важности/срочности. Я думаю с банальными случаями нейронка спокойно справится (даже если это 50%, то врачу уже намного легче).
Другой вариант применения. Нейронка говорит 90% вероятность, а живой врач - "здорова". Это может быть причиной отправить снимок еще одному-двум врачам (или как минимум попросить пациента повторно обследоваться через 6 месяцев).
Почему так странно? У нас ведь есть исторические данные. Берем снимки 5-летней давности и смотрим истории болезни (или здоровья). И с высокой степенью точности определяем сколько ошибается врач (к примеру 5 лет назад врач сказал "здорова", а спустя год-другой выявили рак) и как часто ошибается нейронка. Я надеюсь качество снимков 5 лет назад было сопоставимым с сегодняшним днем?
Другое дело, что многое упирается в приватность мед. инфы. В сложности найти в электронном виде историю. Но сейчас с каждым годом цифровизации больниц это должно быть проще.
Гораздо проще поднять температуру на несколько десятков градусов выше. Медленно поднимаем температуру и рано или поздно будет сбой.
А еще у Huawei: "на телефонах и планшетах с EMUI 9.0, Magic UI 2.1 или более поздней версией функции Умная зарядка и Умная емкость батареи добавлены в модуль управления питанием." (Вроде как с 2019 года, видел на одном бюджетном смартфоне.)