Представлен проект нейросети для звуковой генерации HeartMuLa, которая умеет создавать треки студийного качества, клонировать голоса и вставлять их в песни, умеет также делать транскрибции треков через Whisper.
Репозиторий проекта, ссылка на Hugging Face и на портал ModelScope
О культуре чат-ботов в поддержке
Развитие технологий искусственного интеллекта принесло много нового, но где-где, а в технической поддержке новшества вызывают лишь раздражение. Пока "эффективные менеджеры" показывают красивые графики со снижением затрат на поддержку, пользователи вынуждены мириться с практически полным отсутствием помощи в действительно сложных ситуациях
Речь идёт о чат-ботах, которые бессильны помочь, но полностью уверены, что проблема в том как пользователь задаёт вопрос
И если раньше боты хотя бы понимали грубые выражения и всё-таки звали оператора, то сейчас миссия по выходу на контакт с живым человеком становится практически невыполнимой – бот может до бесконечности просить переформулировать вопрос и абсолютно не сомневается в своей правоте
Почему ни одна компания не может научить ботов звать оператора, если в базе знаний бота объективно нет ничего соответствующего вопросу, для меня остаётся загадкой
Из последних отличившихся хочется отметить поддержку в ВК, с которой состоялся примерно такой диалог
* я подробно описываю проблему в API *
– Выберите категорию вопроса
* Выдаёт кучу вариантов, ни один из которых не подходит. Я выбираю
Ни один из указанных*– Попробуйте задать вопрос иначе
– Проблемы с API
– Выберите категорию вопроса
– Ни один из указанных
– Попробуйте задать вопрос иначе
– Куда обращаться с багами в API?
– Выберите категорию вопроса
...
Стоит ли говорить, что проблему я так и не передал?
Не менее интересным образом работает поддержка Т2 (бывший Теле2). Даже если вам удастся убедить бота, что без оператора не разобраться, то ответит вам человек только в течение 4 часов (хотя может и не ответить, и такое бывало). Но не спешите радоваться, если всё-таки дождались ответа. Оператор вас ждать 4 часа не будет, и если вы не продолжаете диалог сразу (пользователи тоже бывают заняты как ни странно), то оператор просто переключит вас обратно на бота, в котором вам ждёт уже известный сценарий. Особо смешно это видеть, когда суть обращения заключалась в отказе от обслуживания
Хочется конечно верить, что компании вовремя опомнятся и что-то сделают с летящим на дно качеством поддержки клиентов, ну а пока остаётся лишь выпрашивать у ботов право на решение проблемы
А так ли надежен AI от Google?
Я публично веду исследование и собираю статистику причин провалов игровых проектов. Часто, как первичную точку для анализа того или иного игрового проекта я использую Google.
Однако, сегодня google меня немного удивил. На мой запрос: "What were the key issues with civilization vii game at the release"? Вот что сегодня, 20.01.2026 выдал Google:
AI Overview
Sid Meier's Civilization VII is scheduled for release on February 11, 2025 [1, 2]. As of today, January 20, 2026, the game has not been released, and therefore, it is impossible to identify key issues from its actual launch.
Однако, скорректировав запрос с уточнением "What were the key issues with civilization vii game at the release in 2025", я уже получил более разумный ответ:
AI Overview
Sid Meier's Civilization VII faced a rocky, "mixed" reception upon its February 2025 release, with many players describing it as unfinished and in a "rough" state. The launch was marked by complaints regarding fundamental gameplay changes, a poor user interface (UI), and missing quality-of-life features that left many long-term fans disappointed.
Обратил внимание, что часто от ИИ ожидают больше, чем он сейчас может дать. Тем более не стоит считать информацию формируемую генеративным AI полностью достоверной и не подлежащей проверке. Проводите кроссвалидацию с первоисточниками того, что вы получаете от генеративных нейросетей в форме утверждений.
Ранее я разбирал риски присущие ИИ в статье "Риски, присущие работе искусственного интеллекта".
Удачи в построении эффективных и устойчивых процессов.
С уважением,
Максим Торнов
P.S. Если вы заметили опечатку или неточность, буду искренне благодарен за сообщение об этом в личные сообщения.
RCA (Root Cause Analysis) у нас есть.
Документ есть.
Митинг был.
Причину нашли.
Инцидент повторился.
В какой момент RCA перестаёт быть инструментом
и превращается в управленческое самоуспокоение?
Читаем: RCA (Root Cause Analysis) как показатель зрелости менеджмента
Исследователи Microsoft опубликовали масштабное исследование о влиянии генеративного ИИ на рынок труда, назвав 40 профессий, наиболее подверженных автоматизации. Самыми уязвимыми оказались профессии, связанные с обработкой информации: созданием текстов, анализом данных, объяснением и передачей знаний. На вершине рейтинга — переводчики и устные интерпретаторы, писатели и авторы, историки, журналисты, политологи и специалисты по работе с клиентами. Также высокие показатели применимости ИИ зафиксированы у продавцов и сотрудников колл-центров. Только в США в этих сферах занято около 5 миллионов человек.
В исследователи подчёркивают: высокий уровень применимости ИИ не означает неизбежного исчезновения профессии. Речь идет скорее о трансформации рабочих процессов.
40 профессий, наиболее подверженных влиянию генеративного ИИ:
Переводчики;
Историки;
Бортпроводники и обслуживающий персонал;
Менеджеры по продаже услуг;
Писатели и авторы;
Специалисты службы поддержки клиентов;
Операторы станков с ЧПУ;
Телефонные операторы;
Агенты по продаже билетов и туристические клерки;
Радио- и телеведущие, диджеи;
Брокеры;
Преподаватели по управлению домашним хозяйством;
Телемаркетологи;
Консьержи;
Политологи;
Журналисты, репортеры и новостные аналитики;
Математики;
Технические писатели;
Корректоры;
Хостес;
Редакторы;
Преподаватели бизнеса;
Специалисты по связям с общественностью (PR);
Промоутеры и демонстраторы товаров;
Рекламные агенты;
Клерки по открытию новых счетов;
Ассистенты-статистики;
Сотрудники проката/аренды;
Специалисты по анализу данных (Data Scientists);
Персональные финансовые консультанты;
Архивисты;
Преподаватели экономики;
Веб-разработчики;
Бизнес-аналитики и управленческие консультанты;
Географы;
Модели;
Рыночные аналитики;
Диспетчеры экстренных служб;
Операторы коммутаторов;
Преподаватели библиотечного дела.
10 профессий, наименее подверженных влиянию генеративного ИИ
Операторы земснарядов;
Операторы шлюзов и мостов;
Операторы водоочистных сооружений;
Формовщики и изготовители литейных форм;
Операторы техники для укладки и обслуживания железнодорожных путей;
Операторы сваебойных установок;
Шлифовальщики и отделочники полов;
Санитары;
Операторы моторных лодок;
Операторы лесозаготовительной техники.
Разработчик Эван Хан спустя 13 лет практики установил все 376 параметров Vim. Его конфигурационный файл состоит из почти из 2900 строк.
Документация == антибиотики
В свете недавних обсуждений про тесты - пара слов про документацию. Я нашёл очень хорошую метафору: написание документации - это приём антибиотиков. Антибиотики спасли сотни миллионов жизней, может быть, больше миллиарда. Ценность открытия антибиотиков для человечества сложно переоценить.
Но внезапно бездумно пить антибиотики по каждому поводу и без - для организма совсем не полезно. В какой-то мере антибиотик является ядом: очень специальным, очень контролируемым, но совсем не витаминкой (хотя слишком много витаминов тоже не полезно).
С документацией дела обстоят ровно так же. Отсутствие документации не всегда == гибель проекта, но в большинстве случаев, если документации нет никакой, это довольно грустно и часто является очень существенной проблемой. С другой стороны, сама по себе документация - это накладные расходы, это не основной функционал, и она не приносит непосредственной пользы пользователю. Документацию надо поддерживать в актуальном состоянии, и чем её больше, тем это сложнее. И в этом смысле документация - это токсичный (если всё хорошо, легко токсичный) asset.
«Внезапно» не всегда документация так уж нужна. Предположим, у нас есть стандартное Spring Boot-приложение, сделанное через Spring Initializer, со, скажем, файлом build.gradle. В Gradle видна зависимость от Spring Data JDBC и от PostgreSQL базы, и в корне проекта лежит docker-compose.yaml, который стартует PostgreSQL. В src/main/resources лежит application.properties, где определены стандартные data source properties.
Вопрос - что стоит документировать в такой ситуации? Возможно, ничего. Ну, может быть, одну строку: «тут всё примерно как вы ожидаете от Spring Boot + Gradle + PostgreSQL», и, может быть, стоит на этом остановиться.
Более того, во всех случаях, когда я видел New Developer Onboarding документы на 5+ страниц, - это было признаком того, что у проекта есть проблемы того или иного сорта. Возвращаясь к метафоре с антибиотиками: если человек пьёт антибиотик каждые два месяца - с высокой вероятностью у него есть проблемы со здоровьем, которые непосредственно антибиотиком не лечатся, и надо смотреть на проблему комплексно.
Ещё раз повторю - документация - это хорошо, но чем её меньше, тем лучше. Если с проектом можно работать без документации - то это идеальный вариант, в реальной жизни, как правило, не случающийся. Чем больше документов, тем выше накладные расходы. Если архитектуру системы можно устроить так, чтобы сократить какой-то документ, то это, скорее всего, благое дело, и стоит подумать в эту сторону.
Как правило, хорошая причина для написания новых документов - это либо какое-то нестандартное решение, которое команда была вынуждена принять по какой-то причине, и тут причину и само решение стоит задокументировать. Либо это какая-то хитрая внешняя причина - например: как получить API-ключ, почему между вызовами API вдруг стоит Thread.sleep(18_500) или что-то такого же плана.
Красиво написанный, но длинный документ для какой-то области, где можно обойтись без него, - это, скорее всего, не полезный для организма проекта антибиотик, без которого можно было бы обойтись.
AI не заменяет - AI меняет роль
Спор про скорость - ловушка. Правильный вопрос: что стало узким местом?
55% компаний, которые уволили людей из-за AI, теперь жалеют (Orgvue, 2025). Исследование METR показало странное - разработчики думают что с AI работают на 20% быстрее, а объективно на 19% медленнее (METR, июль 2025).
Хинтон говорит что скоро AI будет делать за минуты работу на месяц. CEO AWS называет отказ от найма джуниоров "одной из самых глупых вещей" (MIT Tech Review).
Кто прав? Мой опыт говорит - оба мимо. AI не заменяет и не замедляет. Он меняет распределение труда.
Что отдал AI
Почти всю черновую аналитику:
Spec drafts - первые версии спецификаций по сырым требованиям
C4 диаграммы - контейнеры, компоненты, контекст
Sequence diagrams - потоки взаимодействия
Поисковые запросы - сбор контекста из документации и кодовой базы
Тест-кейсы - acceptance criteria по спецификации
Ручное кодирование сократил до точечных мест: интерфейсы, критичные участки, отладка. Всё остальное - через агента.
Звучит как будто всё отдал. Но нет.
Что не отдам
Здоровье. Доктор может использовать AI - это хорошо. Но это должен быть доктор с образованием и опытом. AI как инструмент - да. AI вместо врача - нет.
То же с психологом и коучем. Всё что связано со здоровьем и осознанностью - только к профессионалам.
В коде аналогично: security-критичные участки, интерфейсы с внешними системами, инварианты бизнес-логики - там доля ручной работы и глубокой экспертизы остаётся выше. AI ускорил черновики и сбор вариантов, но ответственность за модель и критерии - на мне.
Про "парадокс продуктивности"
Подозреваю, что люди измеряют "ощущение скорости", а система измеряет "время до принятого PR".
Не согласен с интерпретацией METR.
Раньше: пробуешь 1-2 варианта, выбираешь, идёшь. Натыкаешься на проблемы - третья версия. Четвёртая. Legacy копится.
Сейчас: пробую кучу вариантов сразу. Да, на каждый уходит больше времени. Но я не тащу три неудачных попытки. Выбираю лучший до того как закапываю в продакшн.
Микро-кейс: фича интеграции с внешним API. Раньше - 3 дня на реализацию, потом 2 дня на переделку когда выяснились edge cases. Сейчас - 1.5 дня, но 40% времени ушло в спецификацию и тест-контракты. Переделок ноль.
Это не замедление. Это сдвиг: меньше "time-to-code", больше "time-to-confident".
Джуниоры: как меняется обучение
CEO AWS: "Как это будет работать через 10 лет, когда никто ничему не научился?"
Согласен. Передача знаний должна быть. С AI можно делать сайты без образования - но индустрия не только про сайты. Есть вещи где нужна математика и computer science.
Но джуниор теперь не "пишет CRUD". Джуниор учится:
Формулировать требования так, чтобы агент понял
Писать тест-контракты до реализации
Дебажить и верифицировать результат
Понимать, когда AI галлюцинирует
Сдвиг роли
Меньше клавиатурной работы, больше постановки, проверки и ответственности за инварианты.
Раньше - исполнитель. Теперь - проектировщик и валидатор.
Причём само проектирование тоже с AI - общаешься с агентом, раскладываешь задачу, проверяешь результат. Во многих продуктовых задачах ручное написание кода - не главное узкое место. Узкое место - постановка, проверка, интеграция, риски.
Что стало важнее
Системный подход. "Герой-разработчик" и "пожаротушитель" - уходит. Ценятся люди, которые системно решают задачи.
И новый навык: строить свою систему работы с AI.
Это мой актив. Моя интеллектуальная собственность. Я трачу время не только на задачи, но и на эту систему.
Как отказ от алкоголя и каннабиса делает сны более долгими и яркими?
Многие, кто бросает пить алкоголь или курить каннабис, замечают, что сны внезапно становятся яркими, длинными, насыщенными, а порой превращаются в изматывающие кошмары. Это не просто субъективное ощущение, а вполне себе измеримое физиологическое явление, именуемое в англоязычной литературе как REM-rebound, что переводится как “возврат к фазе быстрого сна”, в фазе, где чаще всего возникают сновидения.
У здоровых взрослых фаза быстрого сна, которую также называют БДГ-фазой (фаза быстрого движения глаз), составляет около 20%-25% от общего времени сна. Она повторяется примерно каждые 90 минут и постепенно увеличивается до пробуждения.
После недосыпа или отмены веществ, подавлявших БДГ-фазу (уменьшение частоты движений глаз и/или продолжительности фазы), сон не просто возвращается к норме. Продолжительность фазы быстро сна может временно превышать обычный уровень, вплоть до 60% от общего времени сна. Яркость сновидений увеличивается еще из-за увеличения плотности БДГ-фазы, то бишь частоты движений глаз внутри этой фазы, быстрые движения глаз — это буквально процесс “рассматривания” визуальных образов во сне. Все это временная компенсаторная реакция организма.
Что подавляет БДГ-фазу:
Некоторые антидепрессанты группы СИОЗс
*C алкоголем интересная и неоднозначная история, возврат к БДГ-фазе может начаться уже через 4 часа после однократного приема этанола, во второй половине сна из-за подавления БДГ-фазы в первой половине сна (седативное действие алкоголя). По мере снижения уровня алкоголя в крови до нуля во второй половине, наблюдается компенсаторное увеличение фазы быстрого сна. У людей же с расстройствами, связанными с употреблением алкоголя, возврат к БДГ-фазе наступает только через несколько дней или даже недель после отказа от алкоголя.
Почему возврат к БДГ-фазе может вызвать кошмары?
Во время фазы быстрого сна лобные области относительно деактивированы, что препятствует регуляции лимбической системы. Таким образом, кошмары могут отражать компенсацию подавленных эмоциональных переживаний, поскольку психологическое бегство во время сна больше невозможно.
Где учиться AI и ML?
Начать 2026 год с изучения новых IT-навыков — отличная идея. Если хочется чего-то нового и актуального — присмотритесь к ИИ и машинному обучению: умение работать с этими инструментами точно пригодится в работе.
Мы выделили ключевые направления в AI и ML и собрали лучшие курсы по ним на нашей витрине, чтобы вам было проще ориентироваться и находить то, что нужно. Будет полезно и новичкам, и уже опытным специалистам.
— NLP. Обработка текста и речи: от анализа и классификации до чат-ботов, поиска, краткого изложения и создания текстов.
— Машинное обучение. Алгоритмы, которые лежат в основе рекомендаций, прогнозов и аналитики.
— Компьютерное зрение. Детекция объектов, сегментация, трекинг и OCR.
— Deep Learning. Трансформеры, CNN, RNN, обучение на больших данных.
— Нейронные сети. Фундамент AI: архитектура и принципы обучения.
→ Курсы по другим направлениям уже собраны на Хабр Карьере
Попробовал вчера Kурсор впервые:
ШОК!!!
-Сказать дорого, ничего не сказать. После всех оптимизаций какие толкьо можно было выкрутить с помощью перплексити от 1 до 16м токенов в запрос? Да ну на х…
-Молниеносное отупение. Вместо того чтобы понимать какой компонент нужно доделать руками или через чат, тупо жми кнопку все будет ок. Только плати.
Вообщем вывод:
если у тебя большой проект: плати и тупи;
если у тебя сайтик, то повезло. Радуйся и не думай.
А лично я , кроме удобного интерфейса , не увидел ни чего хоть на 1% нужного. Знаю тут ни кто не поддержит) ну и ладно)))
Как не потерять сервер в Minecraft из-за опасных модов
Уверен, что многие владельцы Minecraft-проектов сталкивались с игроками, которые хотели взломать сервер и выдать себе права администратора. Я понимаю, что подобное случается не только в играх, и из научного интереса изучаю, как и почему это происходит.
В этой статье мы рассмотрим CVE, найденную в моде Integrated Scripting.
Проект QArt Coder позволяет вставить лицо пользователя в QR Code. Многие точки в QR‑коде являются лишними, что означает, что их можно расположить в виде картинки, а не просто случайным образом. Короткие URL‑адреса и небольшие изображения с высокой контрастностью в этом проекте работают лучше всего.
Чтобы устроиться на работу в финансах, приходится попотеть. После трёх этапов собеседования соискателю на должность в компании Capital предложили решить задание на 12 страницах:
«Отправьтесь в прошлое, в 48 год до нашей эры, и заберите оригинал „Некрономикона“ из Александрийской библиотеки, прежде чем она будет сожжена римскими войсками. Затем, следуя инструкциям на странице 48 тома, воскресите царя Тутанхамона посредством ритуального жертвоприношения 5000 чёрных овец. Проконсультируйтесь с фараоном о том, как Египетская империя будет расставлять приоритеты в выплатах иностранным кредиторам и инвестициях в свою армию для отражения нападений из Атлантиды. Затем, используя эту информацию, оцените справедливую стоимость муниципальных облигаций, обеспеченных Великой пирамидой (срок погашения — 10 год до нашей эры), и дайте рекомендацию о том, покупать или продавать эти ценные бумаги. Пожалуйста, изложите свой анализ в инвестиционном отчёте на 12 страниц (срок сдачи — конец недели). Удачи! Если у вас возникнут вопросы, пожалуйста, обратитесь к прилагаемым табличкам Архимеда!»
Игровая студия Rassvet представила новый геймплейный трейлер «Размена не будет» (I Have No Change) — атмосферного сюжетного симулятора ночного киоска в постсоветской России. Игрокам «Размена не будет» достанется роль 27-летнего Матвея Зоренко, который проводит канун Нового года за прилавком ночного киоска, обслуживая самых разных покупателей — от старых знакомых до заблудших странников. «В праздничные ночи, наедине с самим собой, Матвей всё чаще задаётся вопросами. Как он оказался в этом киоске? Мечтал ли он о такой жизни? Готов ли он к переменам?» — интригуют авторы.
Релиз «Размена не будет» ожидается в 2027 году на ПК (Steam), но разработчики также надеются рано или поздно выпустить игру на PS5, Xbox Series X и S. Продолжительность составит от четырёх до шести часов.
Новый трейлер«Размена не будет» длится больше двух минут и демонстрирует рабочие будни и побочные занятия Матвея под песню «Ждать» в исполнении Рудольфа Страусова.
Про The Clean Architecture.
Конечно, говоря про Clean Architecture, нельзя обойти стороной книгу Роберта Мартина “Чистая Архитектура”.
Это замечательная книга. В ней можно найти большое количество исторического контекста, с помощью которого Мартин наглядно демонстрирует необходимость введения новых абстракций.
Но не менее полезной можно считать дистиллированную версию в блоге Clean Coder. Автор заметки — тот же Роберт Мартин. Если Вы не знакомы с Clean Architecture, то статья станет хорошей отправной точкой.
Статья в блоге Clean Coder: https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
Промпт-инженер показал способ превратить ChatGPT в гения осмысленных и живых текстов. Идея простая: на Википедии есть список признаков текста, написанного нейросетями — если показать его ИИ и сказать так не делать, это просто... сработает. Итоговый структурированный промпт получился достаточно объёмным.
Для страйкбольного оружия сделали прицел, который сам показывает, куда прилетит шарик. HUD SIGHT учитывает эффект Магнуса, гравитацию и ориентацию оружия в пространстве, после чего прямо в интерфейсе рисует точку попадания. По сути, это aimbot, но легальный и в железе.
Про воркеры простыми словами
На работе мне понадобилось реализовать воркер. Описываю, как сам эту тему разобрал.
Воркер — это сервис, который ждёт событие-триггер и по нему выполняет некий коллбэк. В отличие от фоновых задач в вашем сервисе, воркер живёт в отдельном контейнере.
Пример
Сборщик мусора в БД: пройтись раз в час, например, и удалить старые записи. Или, как у меня задача на работе: обработать xlsx-файл, который передали в ручку.
Зачем
Чтобы сделать работу приложения асинхронной. Представим задачу, которую можно обработать дольше, чем за 10 секунд. Клиент на вашем сайте не будет сидеть и смотреть в экран эти 10 секунд. Он перезагрузит страницу, сессия прервётся, и задача не выполнится. Или веб-сервер вернёт клиенту таймаут. В описанном сценарии обработка запроса — синхронная процедура. Она плохо подходит для быстрых веб-сервисов. А вот асинхронная обработка: кинули запрос, получили ответ 200 OK и пошли чилить, пока задача исполняется — это то, что нужно. Воркер как раз для этого.
Коллбэк
Коллбэком воркера может быть любая нужная функция: отправить имейл, прочитать содержимое, залить файл во временное хранилище и т. д.
Триггеры
Триггерами для воркера могут быть:
крон
таймер
событие
Очереди
Воркеры по событию обычно подписаны на очередь. В моём случае это как раз Redis Queue (библиотека rq, например https://python-rq.org/ ). Запрос в ручку получает 200 OK. Мой сервис создаёт запись в БД типа «задача id такой-то, статус processing» и публикует событие в очереди. Воркер забирает событие, чтобы другие воркеры не могли задачу задублировать, и пробует выполнить свой коллбэк. Если всё ок, воркер пишет в БД данные по выполненной задаче и подтверждает в очереди прочтение события. Иначе воркер может ретраить, может завалить задачу и вернуть её в очередь, а может и сам упасть.
Воркер-пул
Воркеров может быть несколько. Они могут выполнять как несколько разных задач, так и одну вместе. Увеличение числа воркеров требует оркестрации и иногда для этого также выделяет контейнер с оркестратором. Воркеры могут передавать задачи друг другу. Могут конкурировать за задачи, если очередь организовать неправильно. А могут вообще читать разные потоки и быть никак не связаны друг с другом.
Накладные расходы
Чем сложнее слой с воркером, тем больше необходимость следить за их хелсчеками. В отличие от вашего сервиса, воркер может тихо упасть. Ваш сервис отдаёт 200, а по факту задачи не отрабатывают. Так что воркеры накладывают дополнительные накладные расходы: связанность, обработка ошибок, логирование, алерты, ретраи, рестарты подов и т. д.
Образ
Воркер собирается из того же образа, что и ваше приложение, но у него отдельный энтри-поинт. Вместо запуска через main.py у, например, worker.py, есть строчка вида:
def main(): ... # Какая-то логика по инициализации воркера и очереди if name == '__main__': main() # Если запускают этот модуль напрямую, выполни команду main()
Из-за этого кода модуль можно вызвать напрямую python -m app.worker. В main(), как правило, скрыта логика какого-то while-true цикла и шатдауна на случай завершения работы воркера.
