>как найти автора по
Я бы брал пласт тематических текстов. Т.е. если ищем футпринт автора художественной литературы, то берем художку, причем желательно максимально близкого жанра. Считаем частотность слов и выражений по всему пласту. Затем считаем по отдельным авторам авторскую частотность. Находим разность между авторской частотностью и средней. Пики — авторские словечки. Смотрим, какие слова характерны для конкретного текста и ищем наиболее близкого автора. Хотя, конечно, внутри море подводных камней. Придется искать что-то в духе «автор чаще использует „этот“ чем „который“, „и“ чем „а“ и т.п. Важно не хватануть слов, которые относятся к сюжету, а не самому автору. Т.е. не начать считать, что маркерное для Булгакова слово — »яйцо", тк оно часто встречается в роковых яйцах.
Я похожим образом в свое время делал модуль автопоиска ключевиков для статьи на сайте. В том приложении работало хорошо.
Скорее всего, русскую морфологию не подхватит. Ну и как они сами пишут, одноразовый фан проект, который не поддерживается 6 лет. Но все равно спасибо! Нет идей что-то сделать дополнительно с вашим сабжевым проектом? Ведь наверняка из него можно выжать больше?
Интересная заготовка! А можно свести все эти и другие синтетические параметры, полученные по различным книгам одного автора, и построить нормальный такой классификатор. И в теории он сможет определять авторство текста с какой-то вероятностью. Другой вопрос, что фичи придется поискать более сложные. Частотность маркерных слов и словосочетаний, средняя частотность глаголов/существительных/прилагательных/местоимений/… и т.д.
А еще забавнее было бы прогнать, например, по массиву диссертаций и поискать кластера предположительно одного авторства.
Спасибо за интересную статью, мануалов, как начать работать с YOLO, объективно не так много, лишним точно не будет.
А не поделитесь, каких метрик качества удалось достичь?
Не думали расширить датасет фотографиями с условных гуглокартинок, хотя бы по самым интересующим и малопредставленным классам? Наверняка же что-то можно найти.
И еще, мне кажется, детекция аномалий это все-таки про другое, это про поиск «подозрительных, нетипичных» участков на изображениях, по типу головы сфинкса на Марсе. То, что ни на что не похоже. У Вас все-таки более рядовая задача детекции очень редких объектов нескольких классов. Очень похожая задача была подробно разобрана еще для 2/3 версии YOLO — там детектировали полипы/рак кишечника. Тоже очень много однотипных «пустых» изображений без единого объекта класса и редкие, но максимально важные объекты самого класса. И там перед автором вставал вопрос, какой уровень «паники» задавать для модели, чтобы не перегружать врача ложноположительными примерами, но при этом не допускать ложноотрицательных.
Тоже с этого начинали. Системное версионирование, если его разложить на физический уровень, это 2 таблицы. Одна — текущий срез данных, актуальный прямо сейчас. Другая — своеобразная лог таблица, из которой никогда ничего не удаляется, зато в ней присутствует 2 поля — данные валидны С и ПО. Вместо удаления строки просто обновляется ПО на текущее время. В принципе, ничего не мешает повторить эту структуру на неподдерживающем версионирование движке вручную. Единственное — море оберток, триггеров, доп индексов, процедур обновления данных. Для каждой таблицы, если их десятки и сотни, это тяжело поддерживать. Но для некоей итоговой таблицы датасета вполне.
Для многих баз данных есть крутая встроенная похожая штука — temporal tables, они же таблицы с системной версионностью. Работал с ними на MS SQL Server — муторно, но оно того стоит. Можно реально изолировать состояние данных на более менее любую дату. Но весь код обновления и использования данных становится объемным и надо с умом проектировать хранилище, чтобы при каждой заливке свежей порции данных не обновлялась вся таблица. Но действительно появляется возможность прогнать свежий код на старых данных "как тогда" и посмотреть, насколько лучше новая модель.
Круто! А ведь если придать основному отсеку форму крыла, оно полетит еще дальше/лучше/быстрее? Пицца должна легко влезть по-прежнему :) Плюс можно аэродинамически будет управлять в самолетном режиме.
Какая-то очень декадансная статья. Не про «оторвать свою точку и рассортировать хоть что-то», а про «никто нигде ничего не делает».
Как мне кажется, такие вещи эффективно деньгами делаются. В стоимость пакета, бутылки, пробки и памперса должна быть заложена сумма на его переработку. Продал магазин 1000 бутылок, заплатил за это 10 000р целевого налога на развитие переработки и улучшение экологии. Собрал и сдал из них 500 — получил соответствующий вычет. Собрал кто-то дугой — так же получил заработанное, пусть конкурируют за удобство сбора. Но тут важно, чтобы это было именно целевое и максимально местное финансирование. Где мусорят, там и организовывают переработку. И сколько намусорили, столько и истратили.
В теории, тестов делается более чем достаточно, больше чем в большинстве стран Мира. При том в регионах практически невозможно сделать официальный тест вовремя, тк не хватает рук. Первое разумное объяснение, что кто-то делает тесты очень регулярно, в то время как остальные получают эту возможность очень несвоевременно. В итоге у тех, у кого и так все хорошо гора отрицательных тестов, а те, кто реально болеют, тестируются уже в тот момент, когда выявить вирус невозможно.
А можете до кучи вывести число активных случаев (и на миллион жителей), в тч историчное на график? В идеале, хотя бы выборочно, где удастся найти данные, дополнительно вывести коечный фонд региона. Это поможет оценить перегруз здравоохранения и косвенно оценить риски умереть подавившись печенькой, тк все медики в ковидных госпиталях. Плюс возможность скачать сырые данные была бы нужной фичей.
В оригинальной новости приводили характеристики, теста, которые намекают на использование GPU AMD для ускорения вычислений. Но для этого, видимо, придется уйти от собственно tensorflow.
Testing conducted by Apple in October and November 2020 using a preproduction 13-inch MacBook Pro system with Apple M1 chip, 16GB of RAM, and 256GB SSD, as well as a production 1.7GHz quad-core Intel Core i7-based 13-inch MacBook Pro system with Intel Iris Plus Graphics 645, 16GB of RAM, and 2TB SSD. Tested with prerelease macOS Big Sur, TensorFlow 2.3, prerelease TensorFlow 2.4, ResNet50V2 with fine-tuning, CycleGAN, Style Transfer, MobileNetV3, and DenseNet121. Performance tests are conducted using specific computer systems and reflect the approximate performance of MacBook Pro.
Testing conducted by Apple in October and November 2020 using a production 3.2GHz 16-core Intel Xeon W-based Mac Pro system with 32GB of RAM, AMD Radeon Pro Vega II Duo graphics with 64GB of HBM2, and 256GB SSD. Tested with prerelease macOS Big Sur, TensorFlow 2.3, prerelease TensorFlow 2.4, ResNet50V2 with fine-tuning, CycleGAN, Style Transfer, MobileNetV3, and DenseNet121. Performance tests are conducted using specific computer systems and reflect the approximate performance of Mac Pro.
Вот не соглашусь. Оба сокомандника Хэмилтона очень достойно выглядят относительно него в квалификациях. Сливают по паре десятых, но мы все же считаем, что это один из лучших гонщиков в истории. То же самое с Массой/Баррикелло. Оба проигрывали Михаэлю, но проигрывали немного и на машине, которая строилась под Шумахера.
Безусловно, подходит — не подходит самая тяжелая вещь. Вроде бы 100% она существует, но как ее отделить от снижения формы/мотивации — ума не приложу. Честно — так и не смог сделать даже более простого: разделить все машины на «аэродинамические» и «прижимные». В теории все просто — делим трассы на медленные и быстрые. Какие машины выделяются на медленных — прижимные, на быстрых — аэродинамические. Но не все так просто :)
В том и суть. Берем пары пилотов, которые выступают на одной машине и на одной трассе. Смотрим, кто быстрее. Прокидываем сквозь года — в теории должны получить рейтинг всех времен и народов, который игнорирует разницу в машинах.
Думаю, тут как минимум большие вопросы в плане общечеловеческой этики. Даже если с тз закона никаких проблем, прямое разрешение «жертвы» разбора очень бы не помешало.
А кто знает, насколько легально использовать эти данные для обучения сети? Ну т.е. навряд ли в пользовательском соглашении ютуба и порносайтов оговорено, что они прямо разрешают использовать их контент в посторонних целях, пусть и для автоматизированного деперсонализированного анализа. Может быть какой-нибудь известный актер боится, что его одетые видео теперь будут баниться на одной из платформ в России, т.к. нейросеть переобучится на его бэкграунде? И совершенно не хочет, чтобы его лицо участвовало в обучении нейросетей?
Понятно, что так делают практически все, но в каком сейчас состоянии законодательство на этот счет?
Пункты есть. Есть или не есть непонятно :) С какого-то момента есть уже неохота совсем. А вот надо или не надо — загадка. С гелями вроде как советуют быть осторожным и тоже тренировать организм на них, если начать их принимать уже в гонке возможны сюрпризы. С водой тоже советуют не перебарщивать, бывали случаи, что бегуны перебирали с водой и в обморок грохались. Сколько для этого ее надо выпить не сообщается.
Вы как-то совсем забыли про роль пейсмейкеров. Эти ребята собирают вокруг себя толпу и бегут на «ровный» результат, а пейсер на 4 часа — вообще суперзвезда марафона. Но и вокруг других «ровных» времен должны быть свои пики. И у меня есть ощущение, что в категории >4 часов то ли разные времена для пейсмейкеров были в разные годы, то ли кто-то из пейсов перестарался/наоборот отстал.
Можно посмотреть, за счет каких половозрастных групп прибавилось число участников от года к году.
На средний темп также очень влияет погода. Каждый градус, минимальная разница в облачности и осадках.
Марафон вообще ни на что не похож, если вы, конечно, не бегаете 30+км регулярно.
По всем прикидкам я должен был пробежать свой марафон из 4 часов легко, но было жарко, а опыта столь длинного бега не было. И в итоге первая 20-ка за 1:54, 30-ка за 2:55, а следующие 10км уже за 1:10. Последние 2км скорость была 8-9км/ч, чаще шел чем бежал. Итого 4:20.
На последней десятке работают те мышцы, о которых просто не знаешь. Например, жутко болел пресс, потому что спина отболела и перестала держать еще после 30км. Плюс очень непонятно, что делать с водой и едой.
Я бы брал пласт тематических текстов. Т.е. если ищем футпринт автора художественной литературы, то берем художку, причем желательно максимально близкого жанра. Считаем частотность слов и выражений по всему пласту. Затем считаем по отдельным авторам авторскую частотность. Находим разность между авторской частотностью и средней. Пики — авторские словечки. Смотрим, какие слова характерны для конкретного текста и ищем наиболее близкого автора. Хотя, конечно, внутри море подводных камней. Придется искать что-то в духе «автор чаще использует „этот“ чем „который“, „и“ чем „а“ и т.п. Важно не хватануть слов, которые относятся к сюжету, а не самому автору. Т.е. не начать считать, что маркерное для Булгакова слово — »яйцо", тк оно часто встречается в роковых яйцах.
Я похожим образом в свое время делал модуль автопоиска ключевиков для статьи на сайте. В том приложении работало хорошо.
А еще забавнее было бы прогнать, например, по массиву диссертаций и поискать кластера предположительно одного авторства.
А не поделитесь, каких метрик качества удалось достичь?
Не думали расширить датасет фотографиями с условных гуглокартинок, хотя бы по самым интересующим и малопредставленным классам? Наверняка же что-то можно найти.
И еще, мне кажется, детекция аномалий это все-таки про другое, это про поиск «подозрительных, нетипичных» участков на изображениях, по типу головы сфинкса на Марсе. То, что ни на что не похоже. У Вас все-таки более рядовая задача детекции очень редких объектов нескольких классов. Очень похожая задача была подробно разобрана еще для 2/3 версии YOLO — там детектировали полипы/рак кишечника. Тоже очень много однотипных «пустых» изображений без единого объекта класса и редкие, но максимально важные объекты самого класса. И там перед автором вставал вопрос, какой уровень «паники» задавать для модели, чтобы не перегружать врача ложноположительными примерами, но при этом не допускать ложноотрицательных.
Для многих баз данных есть крутая встроенная похожая штука — temporal tables, они же таблицы с системной версионностью. Работал с ними на MS SQL Server — муторно, но оно того стоит. Можно реально изолировать состояние данных на более менее любую дату. Но весь код обновления и использования данных становится объемным и надо с умом проектировать хранилище, чтобы при каждой заливке свежей порции данных не обновлялась вся таблица. Но действительно появляется возможность прогнать свежий код на старых данных "как тогда" и посмотреть, насколько лучше новая модель.
Как мне кажется, такие вещи эффективно деньгами делаются. В стоимость пакета, бутылки, пробки и памперса должна быть заложена сумма на его переработку. Продал магазин 1000 бутылок, заплатил за это 10 000р целевого налога на развитие переработки и улучшение экологии. Собрал и сдал из них 500 — получил соответствующий вычет. Собрал кто-то дугой — так же получил заработанное, пусть конкурируют за удобство сбора. Но тут важно, чтобы это было именно целевое и максимально местное финансирование. Где мусорят, там и организовывают переработку. И сколько намусорили, столько и истратили.
Testing conducted by Apple in October and November 2020 using a preproduction 13-inch MacBook Pro system with Apple M1 chip, 16GB of RAM, and 256GB SSD, as well as a production 1.7GHz quad-core Intel Core i7-based 13-inch MacBook Pro system with Intel Iris Plus Graphics 645, 16GB of RAM, and 2TB SSD. Tested with prerelease macOS Big Sur, TensorFlow 2.3, prerelease TensorFlow 2.4, ResNet50V2 with fine-tuning, CycleGAN, Style Transfer, MobileNetV3, and DenseNet121. Performance tests are conducted using specific computer systems and reflect the approximate performance of MacBook Pro.
Testing conducted by Apple in October and November 2020 using a production 3.2GHz 16-core Intel Xeon W-based Mac Pro system with 32GB of RAM, AMD Radeon Pro Vega II Duo graphics with 64GB of HBM2, and 256GB SSD. Tested with prerelease macOS Big Sur, TensorFlow 2.3, prerelease TensorFlow 2.4, ResNet50V2 with fine-tuning, CycleGAN, Style Transfer, MobileNetV3, and DenseNet121. Performance tests are conducted using specific computer systems and reflect the approximate performance of Mac Pro.
CUDA, биологический аналог :)
Понятно, что так делают практически все, но в каком сейчас состоянии законодательство на этот счет?
Можно посмотреть, за счет каких половозрастных групп прибавилось число участников от года к году.
На средний темп также очень влияет погода. Каждый градус, минимальная разница в облачности и осадках.
Марафон вообще ни на что не похож, если вы, конечно, не бегаете 30+км регулярно.
По всем прикидкам я должен был пробежать свой марафон из 4 часов легко, но было жарко, а опыта столь длинного бега не было. И в итоге первая 20-ка за 1:54, 30-ка за 2:55, а следующие 10км уже за 1:10. Последние 2км скорость была 8-9км/ч, чаще шел чем бежал. Итого 4:20.
На последней десятке работают те мышцы, о которых просто не знаешь. Например, жутко болел пресс, потому что спина отболела и перестала держать еще после 30км. Плюс очень непонятно, что делать с водой и едой.