Pull to refresh

Comments 7

Круто! А как вы добились такой точности распознавания?

Если в одну фразу - не мешать моделям работать.

  1. Не «улучшайте» аудио до распознавания.

  2. Не режьте длинное аудио на чанки.

  3. Отключите внутренний VAD Whisper.

Сверху - дообучение под домен. У нас это coriollon/whisper-large-v3-turbo-russian, еще минус 3.82 pp к усреднённому WER.

На любом корпусе сначала меряйте улучшения на 3–5 клипах, прежде чем добавлять в прод

Вот этот момент не очень понятен. Если запланировано распознавание на лету разных конференций, то качество будет разным в зависимости от гарнитуры, локаций собеседников и еще много каких факторов. Это жене предзаписанные тексты, которые можно сложить в папку и играться с ними. Так что не понятно что заранее измерять...

Пункт чек-листа универсальный: любое «улучшение» конвейера проверяется на данных перед включением в прод.

Нет своего корпуса - берёте открытый, ближайший к задаче. Для конференций подходят SOVA RuDevices, Golos crowd. На их клипах сравниваете модель с предобработкой и без - направление видно уже на первых тестовых клипах.

Появится прод-материал - собирайте свой корпус. С разными микрофонами, локациями, любыми другими факторами - только на таком корпусе становится видно, какие фичи реально работают, а какие лишние. Сторонний бенчмарк отвечает на вопрос «какая модель/обработка сильнее в среднем», свой корпус — «какая работает у меня».

Полезная статья, спасибо, что сформулировали инсайты и поделились!

Сразу прошу прощения, что пишу тут, а не под оригинальной статьёй (https://habr.com/ru/articles/1002260/comments/), Хабр не даёт мне там писать
Заинтересовался ScribeAir настолько(скачал отсюда: https://borisovai.ru/ru/projects/scribe-air) , что зарегистрировался на Хабре, чтобы задать вопрос: смущает, что, судя по анализу файла ScribeAir.exe сервисом VirusTotal показывает:

  • Обфускация: Файл помечен тегами obfuscated, что свидетельствует о применении методов сокрытия исходного кода для усложнения реверс-инжиниринга.

  • DLL Sideloading (Подмена динамических библиотек): Файл распаковывает VCRUNTIME140.dll и другие api-ms-win-core-*.dll в свой локальный каталог или временную папку и загружает их.

  • Зафиксировано добавление нового корневого сертификата (Root/CA) в доверенное хранилище Windows.

  • Манипуляции с реестром и персистентность: Факт: Изменение ключа …\FileExts.exe\OpenWithProgids\exefile. Угроза: Перехват ассоциаций исполняемых файлов или механизмов запуска для обеспечения скрытого закрепления в системе.

Также на GitFlic и GitVerse не нашёл релизов, собственно.

P.S. Сразу отмечу, что я не специалист, просто решил проверить файл. Может, Вы подскажете, почему такая картина?

Спасибо за разбор, отвечу по пунктам кратко.

  1. Обфускация - это эвристика VT на формат PyInstaller (сжатый Python-байткод внутри EXE). Тот же тэг получает любое упакованное Python-десктоп приложение. К malware-обфускации отношения не имеет.

  2. DLL Sideloading VCRUNTIME140 и api-ms-win-core-* - PyInstaller bootstrap: при запуске EXE распаковывает собственный runtime в %TEMP%\_MEI*\ и грузит оттуда же абсолютным путём. Системные библиотеки System32-копиине трогаются. Сайдлоадинг - обратная ситуация (атакующий подменяет DLL); тут программа приносит свои.

  3. Корневой сертификат - никаких certutil, CertAddCertificateContextToStore или HKLM\...\SystemCertificates\ROOT\. Проверяется командой:
    certutil -store -enterprise root до/после запуска - содержимое идентично. Что увидел VT: в MEI*\ лежит cacert.pem от пакета certifi (примерно 155 KB, публичные CA от Mozilla), нужен Python-у для HTTPS-валидации при авто-обновлении. Приложение выставляет SSLCERT_FILE как переменную окружения своего процесса - на систему не влияет.

  4. OpenWithProgids\exefile - модифицирует Windows сам при первом запуске любого нового EXE (чтобы появилось в «Открыть с помощью»). Так делают Notepad++, OBS, Steam.

Пришлите полный VT-отчёт (SHA256) — в личку, разберу детально.

Sign up to leave a comment.

Articles