ИИ

Мускриптор: Audio To MIDI Kyutai(да, те самые, с реалтаймовым голосом) вместе с MireloAI выпустили MuScriptor - открытую модель, которая превращает готовую песню в набор отдельных MIDI-партий. Она умеет «услышать» барабаны, бас, клавиши, вокал и другие инструменты прямо из финального микса, Без Исходных Дорожек. Еще раз - в отдельные MIDI-дорожки для разных инструментов. Причем ей не нужны исходные мультитреки - она работает прямо с финальным сведенным миксом. Демо: https://muscriptor.kyutai.org/ Код: https://github.com/muscriptor/muscriptor Папира: https://arxiv.org/abs/2607.08168 А теперь представим: берем трек из Суны, разбиваем на МИДИ, суваем в Суну. Аранжировщики, чо. Для Гиков:

MuScriptor обучали в три этапа. Главная проблема музыкальной транскрипции в том, что почти не существует больших наборов данных, где готовая песня идеально размечена по нотам и инструментам. Поэтому сначала исследователи использовали около **1,45 млн MIDI-файлов**, в которых вся эта информация уже содержится. Из каждого MIDI во время обучения автоматически создавались десятки вариантов звучания: менялись инструменты, темп, тональность и громкость, после чего композиция **озвучивалась с помощью более 250 различных виртуальных наборов инструментов**. Благодаря этому одна и та же мелодия каждый раз звучала по-новому, а модель училась распознавать музыку в самых разных вариантах исполнения. Но синтетическая музыка слишком отличается от реальных записей. Поэтому второй этап — дообучение на **170 тысячах настоящих треков** (более 11 тысяч часов аудио). Перед этим MIDI автоматически синхронизировали с живым исполнением, чтобы ноты максимально точно совпадали с записью. В основе MuScriptor лежит Transformer, который получает спектрограмму аудио и генерирует последовательность MIDI-событий: определяет, какие ноты звучат, когда они начинаются и заканчиваются, а также каким инструментам принадлежат. Модель также может учитывать заранее известный список инструментов в композиции, что заметно снижает количество ошибок. Финальная настройка выполнялась с помощью **reinforcement learning** на 300 тщательно проверенных композициях. Вместо оценки отдельных нот модель училась максимизировать качество всей транскрипции целиком. Именно сочетание масштабного обучения на синтетической музыке, большого объема реальных записей и RL позволило MuScriptor добиться высокой точности на сложных коммерческих треках.

@cgevent

Самая большая проблема любого AI видео - речь 😬 Картинка в аи видосах уже почти неотличима от съемки даже для меня, а вот речь - все еще главный индикатор. По возможности я стараюсь генерировать войслес видео, но иногда тестирую концепты с говорящей головой или войсовером. Делюсь лайфхаками, которые я для себя нашла (работает и для text2speech, и для text2video) 1. Эмоция + действие + реплика - вместе 🥰 эмоции делают нас живыми, так что вместо "она говорит: привет", стоит прописать "она устало улыбается, отводит взгляд и тихо говорит: привет". Модель подстраивает мимику, темп и интонацию под описание. Тоновые слова (weary voice, shouts excitedly) пожалуй самый дешевый способ убрать робовойс. Можно прописать акцент, хрипоту, особенности 2. Короткие реплики и правильный синтаксис 😎 В Veo реплика идет после двоеточия, в Seedance - в двойных кавычках, лучше это заранее проверить в документациях разных моделей. Также если задаете длину видео, прикиньте что человек успеет все это сказать - иначе получится голосовое на 4х 3. Акустика и микс прямо в промпте 🚬 "в микрофоне слышен ветер, комната 10 кв метров", "громко говорит в огромном храме со сводами 20м в высоту" - модель может прикинуть пространство вокруг по тому, что видела в обучении. Seedance 2.0 делает видео и звук одним проходом, и ей можно задать приоритет слоев по громкости: dialogue clean and prominent, music low, ambient subtle, чтобы не было каши 4. Липсинк лучше работает на крупном плане 💄 Для говорящего персонажа лучше средний/крупный план, статичная камера, лицо анфас или в три четверти. На общем плане губам не хватает разрешения и они начинают жить своей жизнью 5. Пишите как говорят, а не как пишут 😁 Никаких коротких предложений, можно вставлять слова-паразиты и мычания, вдохи/выдохи, без сложной пунктуации, но вот троеточия и тире - отлично 6. Шепот - читерский прием 😳 В ElevenLabs v3 работают аудиотеги: [whispers], [sighs], [laughs], [clears throat]. "Another long day [sighs]" звучит как живой человек. А на шепоте почти не слышно артефактов синтеза - если голос палится, переведите сцену в шепот. Аудиотэги причем анализируются можно писать кастомные, также есть режим, где модель накидывает их на текст за вас 7. Пост-обработка • срезать 2-4 кГц (тот самый AI-звон) • room reverb 5-10% wet, добавляется акустика помещения • наложить фоновый шум в зависимости от бекгрануда на примерно -50 дБ, чтобы голос не звучал как в студии • войс морферы типа телефонный звонок, плохой микрофон (но с очень маленькой интенсивностью) Я бы сказала, что промпт надо писать как художественный текст с эпитетами, а не сухой алгоритм действий - будет сочнее и натуральнее. Постпроцессинг смотреть по ситуации, но базово - убирать полированность и де-идеализировать 🤣 пару примеров скину в комментарии @neural_prosecco

💀 Половина интернета теперь пишут нейронки... умирает пацан Если мы читаем длинный пост в LinkedIn или X или ТГ или без разницы где — мы уже не уверены, человек это написал или ИИ. Хотя судя по комментариям специалистов — все всегда уверены (ведь в тексте есть ДЛИННОЕ ТИРЕ, КАВЫЧКИ и ДРУГИЕ НЕТИПИЧНЫЕ ЗНАКИ), что любой текст пишет нейронка. И в целом если делать такие предположения 100 раз, то примерно раз 50 — это будет правда... Ребята из Pangram (детектор AI-текста,который сканит ленту в X, Medium, Reddit и других ) прогнали через модель больше миллиона постов. Разбирали отдельно длинные посты (от 250 слов). Взяли калькулятор, бусы, счёты и ручки с листочками, чтобы считать в столбик. Потом всё посчитали и получились след выводы: 1. В среднем по всем площадкам — четверть длинных постов написана AI от начала до конца. Не "с помощью", а буквально без участия человека. Преславутые контент-бл.дь-заводы... 2. LinkedIn — безусловный чемпион слопа. 41% длинных постов там чистый AI, живых людей у клавиатуры — 55.2%. И что забавно: там либо чисто человек, либо чисто нейронка, гибридов почти нет (4.3%). Даже короткие посты (50-250 слов) — треть машина. 3. На Твиттере тоже четверть постов полностью AI, плюс еще 23% с его помощью. Люди пишут чуть больше половины ленты... 4. Medium — треть контента с примесью нейронки. Substack держится лучше всех, но и там почти каждый пятый пост не от человека. 5. Reddit неожиданно последний оплот человечности — постов-слопа всего 11.6%, комментарии на 98% человеческие... CEO Pangram сказал правильную штуку, что эти ваши интернеты, залитые неразмеченным AI-контентом — это грустно, но не приговор, если людям честно показывать, что сгенерено. Подобные "исследования" от компаний, выручка которых напрямую зависит от того насколько люди зохотят детектить ИИ контент, выглядят мягко говоря не объективно. Но не думаю, что эти данные далеки от правды. ссылка на статью У меня к вам вопрос. Если бы вы были всесильным и у вас было желание спасти интернет от нейрослопа — какие 2 или 3 действия вы бы сделали?

Дэвид Брукс (автор «Бобо в раю» и «Путь к характеру») написал для The Atlantic лонгрид про тип людей, которых ждёт успех в эпоху AI. Ключевым атрибутом станет потребность в познании. И, в зависимости от отношения к когнитивным усилиям, Брукс предлагает три категории: ◼ Productive Passengers Люди с низким стремлением к познанию. Они используют AI, чтобы меньше думать. Хотя их продуктивность как будто растет, их собственные интеллектуальные способности атрофируются. ◼ Reluctant Optimizers Люди со средней потребностью в познании. Они осознают риски, но часто поддаются соблазну сделать свою интеллектуальную жизнь легче и проще. Что со временем снижает их любознательность и мотивацию. ◼ Mental Marathoners Люди с высоким стремлением к познанию. Они используют AI для развития собственного потенциала. Стремятся к оригинальности и глубокой работе с информацией. И взаимодействуют с AI, в первую очередь, как с партнером для дискуссий. Перевод и аудио в комментариях. → https://www.theatlantic.com/ideas/2026/06/ai-open-ai-anthropic/687689

AI НЕ ДЕЛАЕТ ВАС ПРОДУКТИВНЕЕ Незыблемый факт: AI уже очень хорош в маленьких задачах. Написать плагин, скрипт, небольшую tool'у, UI для UnityEditor окна, вытащить текст из аудио, накидать интеграцию с Google Sheets — вот здесь он реально экономит время. У меня таких историй уже пачка: — история буфера обмена на macOS — парсинг локализаций из Google Sheets в MySQL — извлечение текста из аудиозаписей — терминальный чат для тестирования внутриигрового чата — интеграция BenchmarkDotNet в Unity И тут спорить бессмысленно: да, это ускоряет. Многие мелкие автоматизации можно сделать буквально за 1 промпт. Когда раньше, я даже не брался за это, т.к. на отладку и написание могло уйти полдня-день. 🔸Проблема - большой production Когда я работал в Playtika, уже тогда менеджмент пытался понять, как ускорить процессы разработки через AI. Но модели упирались в контекст. Они могли решить локальную задачу, но плохо держали систему целиком. Сейчас модели стали намного сильнее. Контекст вырос. Opus уже технически способен написать кусок фичи почти полностью. Но я всё равно не готов просто взять и запушить это в большой production-проект. Почему? Потому что в проекте на сотни тысяч строк AI все равно не хватит контекста, чтобы изучить и прочитать все что есть, из-за этого: 🔹Генерируется функционал, который уже есть в проекте 🔹Системы используются не правильно или не полностью 🔹Агент может посчитать, что функция в другой системе написана не правильно и "исправить". И кажется что сделано много, так много кода и анализа никто бы из нас быстро не делал. Но из-за того что это нужно потом вычитать внимательно, проверить и/или переписать, общее время на разработку может только увеличится. 🔸И это не только мое наблюдение METR проверили это на 16 опытных open-source разработчиках, которые в среднем 5 лет работали на своих репозиториях. Результат: с AI они стали медленнее на 19% 🤯 При этом ожидания до начала эксперимента были: ускорение на 24% А после, разрабы думали что AI их ускорил на 20%. Т.е. человек делает больше и из этого создается эффект ускорения. И эти результаты нужно поправлять за Echoes of AI, где:

на чужой кодобазе среднего размера AI действительно ускорял — медианное время падало на 30.7%.

Т.е. получается примерно такой парадокс: 🔹 Если проект маленький или среднего размера, то с AI можно в среднем получать +30% к продуктивности 🔹 Если проект большой или огромный, то важно выделять места, где AI может быть полезен, но не отдавать все ему на откуп. Несоблюдние баланса = +20% к времени выполнения задачи. Этот вывод я и сам ощущаю, когда иной раз проще самому написать, чем промптить, а потом ходить и все переписывать. Это может показаться бредом, если опираться на новостной фон и хайпа вокруг AI. Но это отлично согласовывается даже с тем, что я писал еще до AI хайпа:

Природа разработки ПО - это перенос информации из мира реального в мир абстрактный. Где человек играет ключевую и незаменимую роль.

А скорость переноса ограничена особенностями мозга и ростом синаптических связей. Что ограничено естественным жизненным циклом организма. И это естественное ограничение продуктивности. И даже когда скорость написания кода стремится к бесконечности, проекты НЕ стало разрабатывать быстрее или дешевле. 🔸Функция снижения AI-продуктивности Точных цифр нет, но если накидать порядок величин, кривая выглядит логарифмической. Пусть: x — текущий размер проекта в kLOC, y — прирост продуктивности в %, Smin — kLOC-min, минимальный размер проекта, когда появляется сложность, Smax — максимальный размер проекта, когда эффект от AI = 0 Тогда формула снижения влияния AI на продуктивность будет выглядеть примерно так: y ≈ Smin · ln(Smax / x)

 kLOC | эффект
------+-------
    5 | +23%
   50 | +12%
  500 |   0%

🔻Проще запомнить: продуктивность падает примерно на ~3-5% на каждое удвоение размера проекта. Ставь 👍 если тебе заходит такого рода контент! Ты знаешь кому переслать эту статью 💪 #ai@UniArchitect

Наткнулся на занятную штуку: Fable Advisor — Claude Code plugin для паттерна, который я всё чаще считаю правильным в агентной разработке. Самая сильная модель не должна писать весь код руками. Она должна быть архитектором: понять задачу, разложить её на части, написать нормальный spec, выбрать исполнителя и потом проверить результат. А само «печатающее мясо» можно отдавать более дешёвым/релевантным моделям. Вот думаю многие из вас когда юзают какой нибудь Plan Mode, выбирают самую «умную» модель, а для кодинга чаще всего используют Kimi2.7, новый Grok4.5 или Composer. Брейнрот хорошо напишет любая модель, вот я весь день юзал sol5.6 ультра, потратив все токены и какого то вау эффекта на простых задачах не было. И зачем тогда их тратить вообще, если если условно бесплатный Composer. Ещё мне нравится идея cross-vendor review. Когда Claude пишет spec, Grok или Codex делают diff, а Claude потом проверяет результат, у тебя хотя бы частично расходятся blind spots моделей. Как минимум видел пару исследований, что нельзя писать код и делать ревью одной и той же моделью — так у нее все равно есть определенный bias. Вот интуитивно возьмем идею брейншторма — суть собрать разные взгляды, разных людей с разным жизненным опытом. Почему такое не должно работать с ллмками? Ну как будто должно.

Study and learn У ChatGPT есть спрятанный и недооценённый режим - он вызывается через прописывание @Study в диалоге. Любые наши вопросы обычная модель стремится быстро упаковать в готовые ответы и шаблоны, что создаёт ощущение эффективности в моменте, но долгосрочно приводит к постепенному cognitive offloading и делегированию способности думать. Около года назад ChatGPT добавили “Study and Learn”, режим, который старается не давать нам делегировать весь процесс мышления, педагогически определяет наши задачи, задаёт хорошие вопросы (а не для галочки, как обычные модели). Последнее время всё чаще им пользуюсь. Рекомендую, если вы часто приходите с вопросами типа: • объясни концепт • как это работает? • хочу понять • хочу освоить навык • в чём отличие? Я использую этот режим в супер разных сценариях: • перед началом чтения книг, когда нужно оценить свой уровень понимания темы, особенно, когда понимаю, что книга на вырост и сложная. • когда нужно решить сложную рабочую задачу, с которой я не сталкивался + мне нужно хорошо подумать • когда нужно освоить какой-то навык. Например, недавно с ним учился писать музыку в новом для меня стиле, он хорошо помог не только механически увидеть где должна стоять бочка, где хэты, но и понять, почему оно работает именно так • самое неожиданное - когда нужно сделать саммари видео, большой статьи или даже книги. Я змечаю, что саммаризация контента языковыми моделями не особо работает, потому что создаёт только поверхностную иллюзию понимания. А когда инструмент просит сформулировать идею, мысль - становится сразу понятно, где я плаваю, а где норм. Короче, это универсальный инструмент для того, чтобы включаться в работу. И, конечно, очень показательно, что ChatGPT так глубоко спрятали этот режим в своём интерфейсе. В 2023 году казалось, что LLM изменят опыт обучения, но они довольно быстро сдались - видимо, в среднем пользователи лучше реагируют на быстрые ответы, подхалимство и понятные чек-листы на выходе. А инструмент Study and Learn только лишнее место занимал.

Поведение итогов недели или месяца — совсем не мой жанр, но тут такая неделька выдалась урожайная, что можно и повести важный итог: ChatGPT уже совсем не текстовый чат, которым его воспринимает миллиард пользователей; для тех миллионов пользователей, которые распробовали что к чему это теперь среда голосового взаимодействия с агентами. Тут огорчают, конечно два разрыва: колоссальный разрыв в уровне возможностей и разрыв на несколько порядков по численности между теми, кто этот разрыв осознает и использует новые возможности по максимуму — и того подавляющего большинства, которое все еще просто чатится и искренне верит, что возможности ИИ ограничены ответом на промпт (и на этой основе что-то себе думает про перспективы ИИ) https://help.openai.com/en/articles/6825453-chatgpt-release-notes