Если вы как-то ориентируетесь на разработку TTS решений, то обратите внимание на интересный тест точности нового Apple API SpeechAnalyzer (iOS/macOS 26) с моделями Whisper. На корпусе LibriSpeech в тесте встроенный движок Apple показал 2,12% ошибок на чистой речи против 3,74% у Whisper Small, работая примерно втрое быстрее. Устаревший SFSpeechRecognizer занял последнее место с 9,02%, уступив даже Whisper Tiny размером 40 МБ. Учитывайте, конечно, что тест шел на английском, да и количество языков в движке Apple заметно меньше — 30 против 100+ у Whisper. Кстати, сегодня стали доступны публичные беты новых операционных систем, а могу сказать, что на iOS распознавание очень даже неплохое. https://get-inscribe.com/blog/apple-speech-api-benchmark.html

/Для этой роли пока не существует общепринятого названия/ Именно так начинается одна из вакансий, на которую я наткнулась во время ресерча. И мне кажется, одной этой фразы достаточно, чтобы описать рынок труда в 2026 году. Мы только-только привыкли к тому, что более-менее устаканились роли разработчиков, продактов, бизнес- и системных аналитиков. Появились понятные ожидания, карьерные треки, наборы навыков, даже показалось, что рынок наконец договорился, кто есть кто. Но в этом году я все чаще вижу вакансии с названиями, которых еще год назад практически не существовало. ИИ не мог не навести шороху и тут - меняется и работа, и названия.   Компании начинают искать людей, которые умеют одновременно понимать пользователя, быстро собирать рабочие прототипы с помощью AI, проверять гипотезы и только потом масштабировать решение. Все чаще встречаются вакансии с такими названиями: ⭐️ AI Builder / AI Product Engineer - из реальной вакансии: «Turn raw ideas into real working products fast» - может сам навайбкодить первую версию продукта, показать ее пользователям и только потом решать, что имеет смысл масштабировать ⭐️AI Agent Engineer - такие инженеры строят AI-агентов: учат их пользоваться инструментами, работать с памятью, выполнять длинные цепочки задач и взаимодействовать между собой ⭐️Applied AI Engineer - «You're an AI builder who doesn't wait for permission» - пишут в вакансиях - берет уже существующие модели и превратить их в продукт, которым будут пользоваться люди Разумеется, еще несколько лет рынок будет калиброваться и договариваться о названиях таких ролей - так всегда с молодыми профессиями - помните, сколько было разных вариаций вокруг продуктовых ролей? Product Owner, Digital Product Manager, Internet Product Manager, Growth Product Manager... Со временем все это стало гораздо понятнее. Ну вот сейчас мы наблюдаем ровно такой же момент, только уже в эпоху AI.

Одну важную вещь я поймал на днях с AI консилиумами: когда вы просите консилиум дать свое мнение по определенному вопросу, то важно правильно ограничить видимость агентов; в противном случае - они прочитают факт/вывод в папке проекта и выдадут один и тот же, уже известный ответ. И тогда вся идея разнообразия мнений разбивается о стенку Что у меня произошло: Я в течение 4 дней исследовал одну проблему на пару с дружбаном - why-tree, просмотр сессий и тп. И на какой-то из итераций с консилиумом я заметил, что они стали оперировать фактами, которые им не должны были быть известны. Тут можно было подумать, что они или гении, или нагаллюцинировали... Начал копать и заметил, что у некоторых участников подозрительно много вызовов тулов —> выяснилось, что поскольку у них были тулы, чтобы читать файлы - то они решили, прежде чем дать свое мнение, почитать все что есть в проекте, ну и наткнулись на этот контекст, а далее уже было достаточно сложно их мнение "разнообразить". К слову, цитата из моего поста 3 года назад:

В Empatika Open, посвященной моему обучению в Stanford, я рассказывал про неприятный феномен групповых обсуждений, когда участники фокусируются на общем знании, теряя уникальное знание каждого. Как снизить вероятность такого поведения?

Собственно, именно таким неосторожным загрязнением (contamination) контекста мы и можем предопределить однообразие мнений участников консилиума - как человеческих, так и AI. Как лечится? 1) можно ограничить тулы, что даете субагентам (не давать им читать файлы) 2) явно попросить закарантинить файлы, которые им не должны быть доступны 3) давать разные задачи участникам - "опровергни", "найди чего не хватает", "перепроверь цифры", "скажи, что тебя переубедит" Attention is all you need 😉 P.S. Скилл я, разумеется, по мотивам проапдейтил, но пару седых волос точно прибавилось

Подборка об RL и ризонинге Рассказываем об улучшении RL для сложных задач, оптимизация в RLVR одной строкой кода (!) и обучении компактной модели для дипресёрча. Reuse your FLOPs: Scaling RL on Hard Problems by Conditioning on Very Off-Policy Prefixes При обучении RL на сложных задачах есть две основные проблемы: 1. Большинство роллаутов — wrong, поэтому положительные примеры для основной части задач не появляются. 2. Сложно дообучать модель, когда так мало положительного сигнала. Улучшение происходит скорее за счёт роста общей «умности» модели на более простых тасках. Авторы предлагают метод Prefix-RL, который как раз направлен на решение сложных задач: 🔴Для них семплируются ответы, и из всех семплов выбирается правильный ответ. 🔴Собираются prefixed problems: промпт + префиксы правильного ответа. 🔴На обучении модель видит исходную задачу и набор prefixed problems и учится продолжать хорошую цепочку. Получается метод, который консистентен с on-policy RL, обладает высоким sample efficiency и может ускорять self-improvement. По замерам авторов, Prefix-RL в сравнении с mid-training SFT + GRPO прокрашивает AIME 2025 больше чем на 12 пунктов при том же компьюте на обучении. Проводят аблейшен на Llama, добавляя в prefixed problems генерации Qwen. Это даёт около +5% при том же компьюте относительно Prefix-RL на prefixed problems инит-модели. Получается что-то похожее на эффективную дистилляцию во время RL. Back-generalization — один из важных выводов статьи. Обучение на цепочках с префиксами улучшает решение задач без них, то есть модель при обучении не попадает в зависимость от подсказок. При этом back-generalization позволяет модели писать начало ответа не той стратегией, что была в префиксах на обучении. Хотя автор сказал, что в агентском обучении аналогичный метод они не пробовали, он хорошо обобщается на агентский сетап: в роли префикса выступает часть траектории. Maximum Likelihood Reinforcement Learning Кликбейт: поменяйте строчку в расчёте advantage, замените std в нормировке на mean в своём RLVR — и всё полетит. Проблема в целом стандартная: GRPO учит модель максимизировать среднюю награду (pass@1), а не вероятность успеха. Из-за этого он «залипает» на лёгких задачах и почти не учится на сложных. В RLVR средний reward — это аппроксимация вероятности правильного ответа (так как награда 0/1). Предлагают взять log p (логарифм вероятности правильного ответа) и разложить его в ряд Маклорена по pass@k — вероятности получить «хотя бы один верный из k независимых семплов». Получается бесконечная сумма вкладов от одной, двух, трёх попыток и так далее с весами 1/k. MaxRL берёт усечение этого ряда до вычислительного бюджета g, то есть размера группы в GRPO. Чем больше семплов N на инференсе, тем выше truncation T ряда и тем ближе к точному ML. Если на пальцах, метод даёт меньше внимания группам, где решаемость уже высокая, и больше смотрит на сложные. MaxRL даёт до 20× прирост эффективности test-time scaling относительно GRPO, Pareto-доминирование по pass@1 и pass@k и лучше масштабируется с данными и вычислениям. Попробовать метод можно дёшево: если уже есть RLVR, достаточно поменять одну строчку в расчёте advantage. Но работ, которые пытаются решить эту проблему, много, и пока непонятно, какая идея окажется лучшей. DR Tulu: Reinforcement Learning with Evolving Rubrics for Deep Research Популярный постер на конференции. Ребята смогли получить лёгкую модель дипресёрча с крутым качеством за счёт генерации и обновления рубрик. Изначально при обучении модели давали небольшое количество хорошо написанных рубрик. После каждой итерации обучения смотрели на изменения в ответах, для них генерировали дополнительные рубрики и джаджем оценивали их качество. При этом генерация рубрик и оценка тоже выполнялись лёгкой моделью. За счёт этого цикла получилось обучить модель собирать больше полезной информации и не галлюцинировать. В итоге сделали лёгкую модель (8B), которая по качеству сравнима с топовыми моделями дипресёрча. Увидели интересное ❣ Даниил Кириллов, Тимофей Смирнов, Иван Дёгтев #YaICML2026 Душный NLP

Окупаемость видеокарты для локальных нейросетей Я покупал свою карту 4090 без каких-либо экономических расчетов и подсчетов. Просто решил провести этот эксперимент и попробовать на себе такую дорогую покупку для ИИ. Видеокарта может выдавать в среднем 50 токенов в секунду для Qwen 3.6 27b q8_0. Если переводить в месяц и стоимость такой же модели на openrouter, то получается такая модель обходилась бы мне в 28к рублей (при работе модели 24/7). Электричество на такую видеокарту в моем офисе сожжет 3500 рублей при тарифе 11.5р за квт-ч. То есть, при работы 24/7 у меня экономится 24 тыс рублей в месяц. Окупаться 330 тыс рублей будет минимум пару лет. За эти пару лет видеокарта ощутимо износится, выйдут новые видеокарты и модели, что снизит ценность видеокарты кратно. В конечном счете выходит, что покупка экономически идиотична и не целесообразна. Но я все равно планирую расширять парк видеокарт и раскрывать для себя мир локальных нейросетей дальше. Есть внутреннее ощущение, что нужно дальше двигаться в эту сторону, но нет никакого нормально обоснование зачем тратить сотни тысяч рублей на видеокарту, когда подписки на облачные варианты стоят кратно дешевле. В худшем случае я смогу поделиться с вами своими результатами и отговорить от идиотских покупок несколько тысяч своих подписчиков :)