Влад Костянецкий

Феномен Егоровой

Sat, 22 Aug 2026 22:23:03 +0000

Последние полгода постоянно использую Whisper для расшифровки встреч. Заметил забавный эффект: чем толще модель, тем лучше она распознаёт речь и тем увереннее несёт бред там, где речи нет.

Например, такое бывает в начале вебинара или встречи, пока участники собираются. Тихо, все молчат, разве что кто-нибудь шумно тянет кофе. И Whisper внезапно начинает выдавать что-то такое:

Редактор субтитров А.Синецкая Корректор А.Егорова
Редактор субтитров А.Синецкая Корректор А.Егорова
Редактор субтитров А.Синецкая Корректор А.Егорова
Редактор субтитров А.Синецкая Корректор А.Егорова

И что хуже, продолжает выдавать это даже тогда, когда начинается уже вполне разборчивая речь.

Это здорово раздражало, так что пришлось разобраться.

Почему тишина так распознается?

Под капотом у Whisper — мощная языковая модель, которая пытается подобрать наиболее вероятный текст с учётом аудио и уже распознанного контекста. В общем случае это работает как надо: модель хорошо понимает речь, контекст, имена и сложные фразы.

Но если на входе тишина, шум или что-то невнятное, звук почти перестаёт быть ей полезен. И вот тут модель начинает гадать: какой текст здесь вообще мог бы быть, хм? Обучена она на гигантском датасете аудио с текстовыми расшифровками, которые OpenAI натаскала со всего интернета (порядка 700 тысяч часов, если не путаю).

Среди этого добра, полагаю, было полным-полно видео с субтитрами — а это штука такая, грязная. Во время тишины в сабах вполне может мелькать имя переводчика, редактора, название студии, «спасибо за просмотр» и прочий мусор, которого в аудио вообще нет.

Вот так, думаю, Синецкая с Егоровой и вошли в историю. Над чем они работали, я найти не смог, но, видимо, надпись с отсылкой на них маячила в сабах достаточно часто, чтобы Whisper поставил знак равенства между ними и тишиной.

Почему так распознаётся не только тишина?

Угу, если бы всего лишь получали шум во время пауз, это вообще не было бы проблемой: мусорный фрагмент текста известен и его можно просто выкидывать из выдачи. Хуже всего тут то, что ошибка распознавания портит контекст модели — упрощая, Whisper распознаёт тишину как Егорову, подсовывает этот результат себе же как контекст следующего куска и едет дальше с этим знанием.

Следующий кусок, допустим, опять Егорова, и потом тоже, и потом... Когда спикер наконец-то начинает говорить, ему нужно начать ОЧЕНЬ внятно, чтобы модель согласилась, что да, это уже речь, а не Егорова, набравшая силу на двадцати кусках до него. В результате модель способна застрять в этом состоянии очень надолго.

Проблеме сто лет (ну ладно, четыре года) и она существует для множества языков. Русский, кстати, выбивается из общего ряда — если итальянцы, французы и испанцы видят скучное «Субтитры созданы сообществом Amara.org», то у нас, так сказать, свой фэндом.

Как бороться?

Вообще считается, что надо тюнить инференс: сбрасывать контекст после длинных пауз, играться с no_speech_threshold, condition_on_previous_text, предварительно отрезать тишину с помощью VAD и так далее. До VAD я не добрался, но остальные варианты пробовал — действительно можно добиться вполне сносного результата на конкретном проблемном видео.

Однако мне этот вариант не подошел: мне нужно распознавать самые разные видео — записи встреч, лекции, телефонные разговоры, что угодно. Комбинация приёмов, подобранная для одного видео, не работает для другого. Из инженерного азарта я пробовал собирать обвязку в духе «прогнать видео через три разные комбинации приёмов, а потом проанализировать результат и выбрать тот, где концентрация Егоровой пожиже», но это всё равно работало так себе.

Так что я выбрал другое решение: использовать модель поглупее!

Серьёзно, это работает. По крайней мере на моих видео Whisper Small сваливается в repetition loop на тишине сильно реже. Видимо, более слабой модели сложнее уверенно вывести мусорный паттерн, поэтому на тишине она просто не выводит ничего.

Упрощая,

Whisper Small: Эээ... Ничего не слышу. Непонятно.
Whisper Medium: Эээ... Ничего не слышу... (напрягает свои параметры) А! Знаю! (вступают фанфары) Это ж Егорова!

:D Горе от ума, буквально.

Качество расшифровки у Whisper Small получается, конечно, пониже — больше криво распознанных слов, менее связно, но ~~это лучше, чем когда треть звука слопано Синецкой, а остальное поглодала Егорова~~ результат в среднем более предсказуем.

Кроме того, его все равно нужно потом загнать в условный ChatGPT, чтобы собрать саммари, а для этого гигачада восстановить контекст диалога вообще не вопрос, даже если фрагменты реплик потеряны.

Мику-питомец для Codex

Tue, 18 Aug 2026 09:17:10 +0000

В десктопном Codex есть питомцы — пиксельные персонажи, которые рендерятся поверх UI и показывают, чем занят агент: работает — идёт, ждёт ответа — зовёт пользователя, застрял — жмурится и так далее. Общая идея в том, что пользователь запускает какой-нибудь флоу, переключается на свои дела и краем глаза видит, как там всё идёт.

Фича не особенно полезная, но забавная. Правда, встроенные питомцы мне не зашли; полез смотреть работы сообщества и внезапно на ровном месте разогнался сделать своего — на базе дизайна Хацуне Мику из Miku'n POP, старого-престарого платформера.

Оказалось, не особенно сложно. Спрайты я взял из MikuPet (автор использует тот же дизайн из Miku'n POP), а формат самого питомца довольно понятный (да и благодаря тому же Codex копаться в нём особо не пришлось). Дольше разбирался, чей там арт, на каких условиях его можно переиспользовать и так далее.

Питомца можно скачать с GitHub, там же скриншот и подробные описания того, что внутри барабанчика.

Бесплатный бонус: сборщик релизов в таком проекте можно назвать «Release pet» :)

Obsidian Property Organizer

Sun, 09 Aug 2026 14:41:26 +0000

Что точно стало лучше с появлением ИИ в инструментарии разработчиков — наконец-то появилась реальная возможность доделывать мелкие проекты. Я про всякие тулкиты, MVP-шки и идеи, которые раньше почти всегда отправлялись в стол: делать вроде хочется, но тратить несколько вечеров на очередную маленькую утилиту просто-напросто влом.

Например, на прошлой неделе я навайбкодил себе плагин для Obsidian, который приводит в порядок свойства заметок. Если вкратце: для разных папок можно задать, какие свойства должны быть у заметок и в каком порядке. Плагин добавляет недостающие, убирает лишние и переставляет всё как положено — вместо того бардака, который я когда-то накидал на скорую руку и забыл поправить.

В репозитории на Github есть подробное описание, как это работает.

Вроде бы мелочь, да? Поглаживание внутреннего перфекциониста. Но мне нравится порядок, а за три дня плагин успели скачать семьдесят человек.

Привет вам, собратья по навязчивой любви к чистоте :)

Автообновление для Timesheet

Sun, 26 Jul 2026 12:37:00 +0000

Спонтанно вернулся к своему старому плагину для Obsidian, который по daily notes за какой-то день выдаёт список задач и время, потраченное на каждую.

В его коде был первородный баг: при изменении текста заметки блок плагина не перерисовывался самостоятельно. То есть добавляешь задачу, меняешь потраченное время или исправляешь описание, а отчёт продолжает показывать старые данные. Приходилось либо переоткрывать саму заметку, либо начинать редактирование блока, а потом отменять, чтобы затриггерить его рендер вручную. Это раздражало (и пахло велосипедом).

Теперь блок плагина автоматически рендерится после изменений (только он, не вся заметка). Плюс есть небольшая задержка после ввода и проверка: если отчёт фактически не изменился, то рендера не будет вообще.

Хотел ещё сразу обновить зависимости, всё-таки год прошёл, но... В NPM, знаете ли, всё тот же образцовый порядок. Каждая крошечная библиотека для сложения двух чисел непременно ссылается на десять соседних, каждый пакет соседскому забору двоюродный плетень и ни один просто так не заменишь: npm audit ругается на любой чих. В общем, как надежно обновить зависимости так, чтобы не сломать сам плагин — я с наскока не понял.

Ладно, это задача для завтрашнего меня.

Если кто-то его создаст

Sun, 28 Jun 2026 22:00:00 +0000

В Corpus вышла на русском языке книга «Если кто-то его создаст — все погибнут» Элиезера Юдковского и Нейта Соареса. Оба — известные исследователи в области безопасности ИИ, AI alignment и рисков сверхинтеллекта.

В книжке авторы внятно и последовательно объясняют, почему её название — не истерика, не преувеличение и не байт на лайки. Тезис простой и неприятный: если кто-нибудь на планете действительно создаст AGI или ASI на технологиях, близких к нынешним — человечеству хана.

Соареса я раньше не читал, а вот в Юдковском всегда сочетались два редких качества: экспертность в теме и способность рассуждать о ней человеческим языком, не проваливаясь в заумь каждые тридцать секунд. То есть вам не обязательно иметь профильный бэкграунд: тут явно проделана куча работы просто для того, чтобы текст был понятен аудитории без кандидатской по прикладной математике.

Короче, книжка классная. Забыл уже, когда в последний раз читал что-то запоем, на одном дыхании. Есть на Озоне, в Читай-городе, есть даже в пиратских бухтах (осуждаю, но если ваш фрегат с черным флагом уже припаркован у подъезда, то что я могу поделать) :)

Номер года в литерале типа дата превышает 3999

Sat, 28 Mar 2026 19:42:53 +0000

Про ошибку в названии заметки я уже как-то писал. Напомню суть: платформа не переваривает даты позже 3999 года (на практике начинает стрелять с 3999-12-01). Теоретически такие даты вообще нельзя записать, но ~~если очень хочется~~ из-за ошибок в прикладном коде (и в коде самой платформы) это всё-таки возможно и время от времени случается.

Обычные симптомы — перестают работать какие-то отчёты, не проводятся какие-то документы, падает пересчёт итогов. В общем, страдает любой код, который трогает записи с проблемными датами.

Способ лечения, который я рамочно описал в заметке по ссылке выше — рабочий, но сравнительно медленный: нужно настроить ТЖ, собрать и распарсить результаты. Между тем, платформа падает на первом же обращении к битой дате, а их может быть много и валяться они могут в разных таблицах. То есть может потребоваться несколько подходов к снаряду: проверили, получили ошибку, исправили, проверили, получили следующую...

Желая решать проблему как-нибудь побыстрее, несколько лет назад я написал запрос для PostgreSQL. Общая идея:

Ищем в базе данных все поля с датами.
Строим мегазапрос к таким полям (ищем даты, которые выходят за лимит 1С).

То есть этот запрос генерирует другой запрос, да. Выполняем его и получаем полную картинку проблемы: список таблиц с некорректными датами. Дальше уже дело техники — смотрим, что за таблицы и решаем, как быть. В нашем случае проблемные даты иногда возникают в итогах и оборотах, так что их можно просто удалять и пересчитывать итоги через штатные инструменты.

Почему действуем на уровне СУБД? Ну, средствами 1С такой номер не отколоть — напомню, платформа падает при попытке потрогать проблемные записи. Это касается любого взаимодействия, включая чтение. Кроме того, в данном случае работать напрямую быстрее и удобнее.

На днях я переписал этот запрос для MS SQL. Вышло длиннее (в силу особенностей этой СУБД), но идея та же.

Если будете использовать, имейте в виду, что:

Поле _Fld626 в тексте запроса — разделитель для фреша. В вашей базе может называться по-другому или вообще отсутствовать.
Запрос написан для базы со сдвигом в 2000 лет. Если в вашей базе сдвига нет, нужно скорректировать условие (см. функцию DATEADD()).
Трюк с выводом в XML (см. FOR XML) я добавил, чтобы не дать SSMS обрезать текст мегазапроса (показалось быстрее, чем возиться с приведением типов). Побочный эффект: в получившемся мегазапросе нужно заменить > на >, прежде чем выполнять его.

С побочным эффектом

Sun, 15 Mar 2026 12:24:12 +0000

В последнем релизе нашей ERP мы оптимизировали несколько тяжелых динамических списков (заказы, инвойсы, проформа инвойсы и так далее). Там накопился приличный техдолг, в основном — горы вспомогательных таблиц, прикрученных к основным запросам (контактная информация, технические реквизиты, остатки, обороты и так далее). В итоге даже в сравнительно небольших приложениях оптимизатор СУБД начинал выдавать бредни вместо планов запроса и мало-помалу платить за это ресурсами стало совсем неприятно.

В общем, запатчили через несколько разных подходов, один из них — подгрузка дополнительных данных в обработчике ПриПолученииДанныхНаСервере() (я про него недавно вспоминал, кстати). Написали удобный фреймворк вокруг фичи, внедрили, потестировали и... В общем, сидим с кислыми минами.

Нет, с производительностью и правда стало сильно лучше. Запрос к тяжелым виртуальным таблицам можно затюнить просто идеально. Проблема в другом: значения полей, которые заполняет этот обработчик, не пробрасываются в стандартные механики динамического списка. То есть для них не работает поиск, сортировка и группировка.

Например, вводим значение, которое видим в колонке, а строка не находится. Или находятся не все строки. Или находятся строки, которые не должны были найтись. Для пользователя это выглядит отвратительно, ну баг и баг же: визуально-то такие поля никак не отличаются. Как ты ему объяснишь, что это особенность работы механизма платформы™?

Исключишь такое поле из механизмов, которые с ними работать не могут — будет ещё чище. Например, попытаешься отсортировать — получишь здоровенную ошибку. Опять же, объяснить, почему на этой колонке с суммой вылетает ошибка, а на соседней сортировка прекрасно работает — задача со звездочкой.

Блин, вот как можно было разработать такой замечательный концепт обработчика и настолько заруинить реализацию на уровне платформы?

Неожиданно вспомнил Реддит. В некоторых сообществах популярны треды «придумай суперсилу, но с побочным эффектом». Типа, кто-то пишет в комментариях: я могу бегать со скоростью ветра! Ему отвечают: да, но не можешь тормозить. И так далее. Местами получается забавно.

Вот и мы с разработчиками платформы в таком же диалоге. Вы можете разогнать динамические списки (но UI будет вызывать у пользователей бешенство). Вы можете автоматом слать двоичные данные в бакет S3 (но потеряете их в один неосторожный клик). Вы можете телепортироваться куда угодно (но тратите столько времени, словно шли пешком). Вы можете превращаться (но только в пожилого мопса). У вас пышные, шелковистые волосы (но на заднице).

Икигай

Mon, 09 Mar 2026 22:01:43 +0000

В японском языке есть замечательное слово «икигай». Это что-то вроде смысла жизни, но не в большом экзистенциальном понимании, а в более приземлённом и конкретном: источник внутренней энергии, источник радости. Ради чего хочется вставать по утрам, короче.

Таких опор у человека может быть несколько, и у всех они свои. Кофе, кот, любимое ремесло, забота о близких, сад, прогулки, видеоигры...

Я это к чему. Наткнулся на канал «Алёшкино своё». Его автор, насколько я понял, питерский юрист, который разводит породистых курочек и регулярно записывает видео то про конкретные породы, то про нюансы инкубации, то про кормление.

Я вообще не в теме и птицами не интересуюсь, но поймал себя на том, что минут двадцать просто сидел и заворожённо слушал, не отрываясь. Работает почти как терапия, ей-богу. И, кажется, это вполне такой солидный икигай: дело, которое будешь любить так, как этот мужик любит своих курочек.

Автосаммари

Sun, 08 Feb 2026 09:53:48 +0000

Записывать все встречи я, судя по моим же заметкам, начал ещё в 2020-м. Видео всегда точнее памяти, а ткнуть на «Start Recording» в OBS — самый дешёвый способ не потерять какую-нибудь ценную инфу.

Минусы, впрочем, очевидны — с видео нельзя быстро ухватить суть встречи, по нему невозможен быстрый поиск, оно много весит, в нём легко засветить что-то личное и так далее. Чтобы частично компенсировать это, я в течение встреч тезисно помечал ключевые моменты, а потом либо перекидывал в задачник, либо делал себе что-то вроде саммари: с кем встречался, что обсуждали, какие решения подобрали. Если что-то забыл или упустил детали — сверялся с видео.

Однако этот метод тоже не идеален. Создание конспекта (даже тезисного) отъедает фокус от самой встречи. Кроме того, про какие-нибудь забытые по ходу дела подробности можно узнать слишком поздно.

Короче, пришёл к тому, что хороший вариант — просто извлекать из видео аудио разговора, превращать его в текст (нейронкой), а текст разговора — в детальное саммари по встрече (опять нейронка).

Аудио проще всего выдрать через ffmpeg (консольная утилита для работы с аудио и видео). Ниже пример вызова (один аудиоканал, дискретизация 16 кГц + нормализация громкости):

ffmpeg.exe -y -i "D:\video.mkv" -vn -ac 1 -ar 16000 -af loudnorm -c:a pcm_s16le "D:\audio.wav"

Что до извлечения текста — я экспериментировал с Vosk в связке с recasepunc, но про это без слёз не вспомнить. Даже комментировать не хочу. А вот ~~Боромир~~ Whisper (нейросеть от OpenAI, умеющая распознавать голос) ставится в фоне за 10 минут:

py -3.10 -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install setuptools wheel
pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118
pip install openai-whisper

Пример вызова:

whisper "D:\audio.wav" --model small --language Russian --output_format txt

На выходе получится текстовый файл с расшифровкой, который можно запихать в любой чатбот и получить вполне связное саммари. Его, конечно, всё ещё нужно вычитать — убрать ошибки и фантазии, что-то переформулировать — но это всё ещё сильно лучше создания конспекта на ходу.

Вот, в общем-то, и весь метод. Остаётся написать простой скрипт, чтобы не дергать две команды вручную. Если вы тоже на Windows и вам лень вайбкодить, можете взять мой скрипт и подогнать под себя.

Скрипт ищет в своей папке первый попавшийся .mkv, прогоняет через ffmpeg + Whisper и сохраняет результат в ту же папку. Если будете использовать — обратите внимание, что он работает через CUDA (на CPU тоже можно, но будет сильно медленнее) + скачанные модели Whisper он сохраняет не в дефолтный кэш, а в папку с текущим Python-окружением.

(при желании можно прикрутить к нему вызов API или обращение к какой-нибудь модели в локальной LM Studio, но персонально для себя я решил — не, уже перебор)

Новый UI в блоге

Sat, 17 Jan 2026 18:18:43 +0000

На новогодних праздниках внезапно закусился и переписал UI блога. Хотел всего-то прикрутить поиск по заметкам: их уже довольно много и время от времени нужно что-то быстро выудить из кучи написанного (например, ссылку коллеге скинуть).

Блог живёт на Github Pages, так что выбор решений небогат: либо слать запрос в гугл, либо делать свой статический индекс и отдавать в браузер пользователя (пусть сам в нём роется). Я пошёл по второму пути: быстрее, управляемее ~~и можно самому покодить~~. При первом поиске файл индекса, правда, нужно скачать, но что такое 200 Кб в современном интернете? Смешно.

Ну а там как-то, знаете ли, пошло-поехало... Сначала не удавалось прикрутить к полю поиска Tachyons — разозлился и переделал всё на Tailwind (всё равно хотел попробовать, а случая всё никак не представлялось). Пока писал код для поиска — подумал, что логично сразу вкрутить в него теги, чтобы два раза не вставать. Очнулся с облаком тегов над заметками и сообразил, что тогда уж надо и с проектником то же самое сделать, только там не теги нужны, а стеки...

В общем, получилось как в том меме из «Страха и отвращения в Лас-Вегасе». Сложно было остановиться. Осталось заставить себя писать в новый проектник: работы всегда дофига, и работа интересная, но если не писать о ней — кофе, всё тонет в кофе.