Мне удалось скопировать в Google Drive практически все данные с Яндекс Диска. Осталось только 3 файла, которые всё ещё недоступны.
Изначально файлов с ошибками было 54. Но вчера утром я написал в техподдержку. Там оперативно ответили и устранили проблему. За это, конечно, огромная благодарность. Вообще, шутки про собесы Яндекса — это забавно, но инженерам Яндекса сейчас можно только посочувствовать и выразить уважение.
НО! Это всё было вчера.
А сегодня ночью Яндекс потерял ещё один ДЦ во Владимире. И сегодня я наблюдаю, что многие файлы недоступны уже через web-интерфейса Диска. Раньше такого не было.
И ещё, Яндекс вчера обновил своё пользовательское соглашение и включил БПЛА в список причин, по которым он снимает с себя ответственность. Короче, спасение фоточек только в наших руках.
Изначально файлов с ошибками было 54. Но вчера утром я написал в техподдержку. Там оперативно ответили и устранили проблему. За это, конечно, огромная благодарность. Вообще, шутки про собесы Яндекса — это забавно, но инженерам Яндекса сейчас можно только посочувствовать и выразить уважение.
НО! Это всё было вчера.
А сегодня ночью Яндекс потерял ещё один ДЦ во Владимире. И сегодня я наблюдаю, что многие файлы недоступны уже через web-интерфейса Диска. Раньше такого не было.
И ещё, Яндекс вчера обновил своё пользовательское соглашение и включил БПЛА в список причин, по которым он снимает с себя ответственность. Короче, спасение фоточек только в наших руках.
🫡4👀3😱2👍1
Что не так с маркировкой ИИ от Яндекс Музыки
На прошлых выходных появилось настроение поработать над Slopless. Как раз в GitHub предложили в расширении учитывать маркировку от Яндекса. Этим я и занялся.
За выходные я сравнил разметку Slopless и Яндекс для всех треков начиная с 2024 года, у которых есть хотя бы один лайк.
По оценке Slopless, 27% из проверенных треков созданы с помощью ИИ, а по оценке Яндекса — таких треков не более 18%.
Оценка Яндекса более комплексная. Там есть 3 категории:
- возможно ИИ;
- частично ИИ;
- полностью ИИ.
Две последние категории основаны на данных от дистрибьюторов. Некоторые из них добровольно собирают и передают информацию о том, как был использован ИИ при создании музыки: для аранжировки, для вокала или же трек сгенерирован полностью. Категория «возможно, ИИ» — это результат работы детектора ИИ от Яндекса.
Но, как я уже писал ранее, дистрибьюторы не обязаны передавать информацию об использовании ИИ, и многие этого не делают. В особенности создатели виртуальных ИИ-артистов.
Детектор ИИ от Яндекса не маркирует всю музыку таких исполнителей. А из-за того что маркировка Яндекса спрятана в метаданных треков, для пользователей эта информация труднодоступна.
Вот примеры некоторых таких исполнителей:
- Детские колыбельные
- Музыка для сна
- Музыка для сна младенцев
- Музыка для сна малыша
- КОЛЫБЕЛЬНЫЕ
- Музыка для медитации
- Спокойная фоновая музыка
- Iren Lullaby
Попробуйте там найти промаркированные треки.
#нейромузыка@yet_another_dev
На прошлых выходных появилось настроение поработать над Slopless. Как раз в GitHub предложили в расширении учитывать маркировку от Яндекса. Этим я и занялся.
За выходные я сравнил разметку Slopless и Яндекс для всех треков начиная с 2024 года, у которых есть хотя бы один лайк.
По оценке Slopless, 27% из проверенных треков созданы с помощью ИИ, а по оценке Яндекса — таких треков не более 18%.
Оценка Яндекса более комплексная. Там есть 3 категории:
- возможно ИИ;
- частично ИИ;
- полностью ИИ.
Две последние категории основаны на данных от дистрибьюторов. Некоторые из них добровольно собирают и передают информацию о том, как был использован ИИ при создании музыки: для аранжировки, для вокала или же трек сгенерирован полностью. Категория «возможно, ИИ» — это результат работы детектора ИИ от Яндекса.
Но, как я уже писал ранее, дистрибьюторы не обязаны передавать информацию об использовании ИИ, и многие этого не делают. В особенности создатели виртуальных ИИ-артистов.
Детектор ИИ от Яндекса не маркирует всю музыку таких исполнителей. А из-за того что маркировка Яндекса спрятана в метаданных треков, для пользователей эта информация труднодоступна.
Вот примеры некоторых таких исполнителей:
- Детские колыбельные
- Музыка для сна
- Музыка для сна младенцев
- Музыка для сна малыша
- КОЛЫБЕЛЬНЫЕ
- Музыка для медитации
- Спокойная фоновая музыка
- Iren Lullaby
Попробуйте там найти промаркированные треки.
#нейромузыка@yet_another_dev
👍7
Статический анализ кода и ИИ-разработка
Мы все уже не раз видели, как какая-то компания переписала проект с языка X на Rust при помощи ИИ. За примерами ходить не надо:
1. Microsoft переписали рантайм Copilot CLI с TypeScript на Rust.
2. Anthropic переписали рантайм Bun с Zig на Rust.
После моей истории с исправлением ошибок SonarQube при помощи ИИ, я начал догадываться почему для переписывания выбирают Rust – у него очень строгий компилятор, который просто не даст собраться проекту, если что-то не так.
Но похожего поведения можно добиться и с C#, например, а затем использовать такой подход не только для переписывания существующих проектов, но и для написания нового кода.
После исправления ошибок SonarQube я поэкспериментировал с возможностями .NET: добавил .editorconfig, указал там правила и сделал так, чтобы они вызывали ошибку при сборке.
Например, сейчас Microsoft рекомендует использовать LoggerAttribute для высокопроизводительного логирования. Но если жёстких ограничений нет, то ИИ всё равно может писать про старому.
Включив проверку правила CA1873, можно добиться от агента нужного кода. У него просто не будет другого выбора, кроме как писать правильный код.
Иначе говоря, детерминированность кода зависит от строгости анализаторов. Чем больше правил выбрасывают ошибки при сборке, тем более детерминированный будет результат.
Но такие проверки кода помогают определить только «форму» кода и не влияют на «смысл», то есть бизнес логику. Проверка бизнес логики – другая задача и должна решаться следующим уровнем проверок, а именно тестами.
#программирование@yet_another_dev
Мы все уже не раз видели, как какая-то компания переписала проект с языка X на Rust при помощи ИИ. За примерами ходить не надо:
1. Microsoft переписали рантайм Copilot CLI с TypeScript на Rust.
2. Anthropic переписали рантайм Bun с Zig на Rust.
После моей истории с исправлением ошибок SonarQube при помощи ИИ, я начал догадываться почему для переписывания выбирают Rust – у него очень строгий компилятор, который просто не даст собраться проекту, если что-то не так.
Но похожего поведения можно добиться и с C#, например, а затем использовать такой подход не только для переписывания существующих проектов, но и для написания нового кода.
После исправления ошибок SonarQube я поэкспериментировал с возможностями .NET: добавил .editorconfig, указал там правила и сделал так, чтобы они вызывали ошибку при сборке.
Например, сейчас Microsoft рекомендует использовать LoggerAttribute для высокопроизводительного логирования. Но если жёстких ограничений нет, то ИИ всё равно может писать про старому.
Включив проверку правила CA1873, можно добиться от агента нужного кода. У него просто не будет другого выбора, кроме как писать правильный код.
Иначе говоря, детерминированность кода зависит от строгости анализаторов. Чем больше правил выбрасывают ошибки при сборке, тем более детерминированный будет результат.
Но такие проверки кода помогают определить только «форму» кода и не влияют на «смысл», то есть бизнес логику. Проверка бизнес логики – другая задача и должна решаться следующим уровнем проверок, а именно тестами.
#программирование@yet_another_dev
👍5✍2🔥1
😁9
Пока половина интернета сходит с ума из-за критической уязвимости в PHP, напомню, что не так давно была похожая по масштабам уязвимость в Log4j - в популярной Java библиотеке для логирования.
Уязвимость позволяла выполнять произвольный код (RCE). Для этого достаточно было послать определенный запрос на сервер.
И тогда на полном серьёзе предлагалось эксплуатировать саму уязвимость чтобы пропатчить библиотеку.
Так что в шутке на картинке лишь доля шутки.
#программирование@yet_another_dev
Уязвимость позволяла выполнять произвольный код (RCE). Для этого достаточно было послать определенный запрос на сервер.
И тогда на полном серьёзе предлагалось эксплуатировать саму уязвимость чтобы пропатчить библиотеку.
Так что в шутке на картинке лишь доля шутки.
#программирование@yet_another_dev
👍2😁2