Microsoft предлагает использовать speech-LLM для оценки качества синтетической речи. Идея практичная, стандартные протоколы типа MOS и A/B тестов трудозатратны, а на выходе получаем оценку без качественных инсайтов, что именно пошло не так

🔗SpeechLLM-as-Judges: Towards General and Interpretable Speech Quality Evaluation

🐯 SQ-LLM

Авторы собрали датасет SpeechEval: 32к аудио (реальных и синтетики, включая коммерческие TTS), 128к аннотаций на 4 языках (en/zh/ja/fr). Аннотации включают оценки по 8 измерениям: overall quality, intelligibility, distortion, speech rate, dynamic range, emotional impact, artistic expression, subjective experience, а также развернутое текстовое описание «что не так».

Модель SQ-LLM на базе Qwen2.5-Omni-7B. Файн-тьюн LLM через LoRA, аудио энкодер не трогали. Обучали на 4: speech quality assessment (краткий текстовый разбор по 8 измерениям), парные сравнения A/B по тем же аспектам, генерация советов по улучшению, и детекция дипфейков.

Добавили CoT (это самое важное): модель предсказывает сами численные оценки по 8 измерениям ❕(см. картинку), затем текстовое описание и итоговый скор

Эксперименты в статье не совсем убедительны. Но есть все же несколько инсайтов 🌸

🌀Без доп. файн-тюна все speech-LLM дают слабую корреляцию с человеческими оценками (zero-shot не в деле). Эмерджентности не наблюдается, speechLLM, обычно крайне чувствительны к out-of-domain задачам. ‼️ Между их SQ-LLM и их же кастомными бейзлайнами (Whisper+Qwen3-8B, WavLM+Qwen3-4B) большой разницы тоже не вижу...

😎Чтобы быть хорошим судьей, не нужно уметь генерить речь, важно глубоко понимать акустические характеристики. Бейзлайны с Whisper в среднем опережают остальных (особенно на deepfake detection), что подсказывает важность мощного энкодера. Было бы интересно проверить, даст ли до-обучение энкодера с головами предсказания отдельных метрик бОльший буст

🐈CoT улучшает метрики, логично: 8 промежуточных численных предсказаний дают модели доп. сигналы помимо текста. Это мотивирует модель выучить отдельно факторы влияющие на качество и численно их оценивать, подкрепляя ответ. Полагаю, CoT еще снижает кол-во связных и красивых, но фактически некорректных формулировок

RL в виде GRPO даёт прирост по всем задачам, особенно на детекции дипфейков: модель достигает EER 6.2% и точности 89.4% против 15-18% у спец. систем типа RawNet2 (EER 15.84%, ACC 72.04%)

В своих проектах пришла к похожим выводам: учим LLM’ку извлекать и предсказывать количественные и качественные характеристики аудио внутри цепочки CoT (даже те, которые лишь косвенно связаны с down-stream) — получаем лучшее качество на основной задаче. Правда, это лишь мое эмпирическое наблюдение.

Что не понравилось в статье 😭

🟡Система якобы решает проблему интерпретируемости, но ни одного человеческого исследования нет, было бы круто прогнать на какую-нибудь TTS и проанализировать отзывы модели

🔴SQ-LLM показывает, что speech-LLM можно адаптировать для оценки качества речи со средней точностью.. Pearson correlation 0.476 на оценке качества это скромно (хотелось бы 0.7+). Точность 67% в парных сравнениях, что всего на 17 п. выше угадывания

🟡Непонятно, как файн-тюнили кастомные бейзлайны: была ли LoRA, был ли CoT? Не хватает сравнения разных аудио-энкодеров и LLM-декодеров

Самое главное: датасет не выпущен. Авторы собрали ценный ресурс, 128к качественных аннотаций, но пока не зарелизили

Выводы?

Я все еще скептически отношусь к LLM as a judge. Но для частичной автоматизации оценивания, почему бы и нет, например, чтобы выловить сложные примеры и углубиться в их анализ уже вручную.

P.S.: В этом году вела проект аннотации данных: подготовка, дизайн UI, правила для аннотаторов, обработка edge cases. Впечатление, что компании, специализирующиеся на данных, уже чаще вовлекают людей только для проверки и исправления ошибок ML пайплайнов. Это оптимизация и ускорение, но критически важна due diligence аннотаторов, не кликнуть на «тут все верно, идем дальше», если есть ошибки

Пока дописывала пост, релизнули 🔗OmniVinci. Идём читать 🤓

🐹 ARC-Encoder от Kyutai: plug-and-play компрессия для LLM

На прошлой неделе вышла крутая статья от Kyutai Labs (да, я им симпатизирую): 🔗ARC-Encoder learning compressed text representations for large language models

Почему-то осталась относительно незамеченной, хотя на мой взгляд работа хорошо сделана и достойна deep-dive чтения. Как уже видно из названия, эта статья даже не про TTS & STT, здесь авторы придумали универсальный энкодер для сжатия длинных контекстов в LLM'ках в х4-8 раз практически без потерь качества ответов на различных downstream задачах (QA, text summarization, перевод), включая ICL

ARC-Encoder сжимает контекст в короткую последовательность эмбеддингов, которые напрямую подставляются в LLM декодер (после embedding layer), при этому саму LLM не до-обучают❕. И в дополнение, ARC-Encoder можно легко адаптировать к нескольким разным декодерам через небольшие MLP модули

🍅 Немного про context compression

LLM-пайплайны (RAG, multi-document QA) нуждаются в длинных контекстах. Но pre-fill на длинных промптах стоит дорого и быстро упирается в лимиты контекстного окна. Можно просто дропнуть наименее важные токены, или кратко суммаризировать промпт. Это hard compression. Альтернативный подход, soft compression, подразумевает извлечение смысловых эмбеддингов из пассажей контекста (инструкции промпта или документы). Часто такие методы также подразумевают fine-tune LLM декодера, ведь ему нужно еще научиться использовать эти сжатые репрезентации. ARC-Encoder же тем хорош, что никак не трогает decoder LLM, таким образом модель никак не будет менять своего поведения на других задачах 💲🤩


☕️ Архитектура

⭐️В недавней работе (тут) показали, что LLM декодер можно успешно использовать для компресси текста. Поэтому авторы взяли за основу LLaMA‑3.2‑3B, убрав output head и cаusal mask (чтобы энкодер видел весь контекст сразу, а не только влево)

⭐️Поверх последнего self-attention блока применяют pooling (average) с фактором сжатия от 4 до 8, но только для queries, в то время keys & values остаются полноразмерными. Авторы пишут, что пробовали пулить на разных слоях, но эффективнее всего на последнем, что логично, репрезентации на последнем слое семантически богаче

⭐️Далее MLP слой (без активации🌸) отображает encoder outputs в размерность латентного пространства LLM. Получившиеся эмбеддинги просто подставляются в латентное пространство LLM декодера (на вход transformer layers)

Как и что тренили?

1️⃣ Pre-training на Common Crawl на двух задачах (см. картинку): реконструкция последовательности (а) и продолжение последовательности (б), что оказалось критично, так как это по сути та же задача, что и любой downstream task

2️⃣ Fine-tuning делали на миксе синтетических и реальных QA, summarization и др. датасетах. При этом сжатые эмбеддинги перемежаются с обычными токенами, что сохраняет few-shot способности модели

Понравился оценочный сетап. Модели‑декодеры: Llama‑3.1‑8B и Mistral‑7B (base). Бейзлайны авторы ре-имплементили сами на базе тех же декодеров, данных и задачах. Дополнительно оценили open book (весь промпт вместе с документами для QA у модели в контексте) и closed book сетапы. Тренировочные сеты бенчмарков предусмотрительно не включали в тренировки.

🟣На всех бенчах context compression ARC держится близко к open‑book на Llama‑3.1‑8B и обгоняет closed‑book и большинство бейзлайнов; на Mistral‑7B отставание от open‑book небольшое, что ожидаемо (архитектурно декодер Mistral дальше от Llama-3.2 энкодера)

🔴Также круто: удалось увеличить эффективнй контекст Llama2-chat с 4 до 32k обогнав по некоторым метрикам Llama2-32k Instruct (специально до-трененную на длинных последовательностях)

🥹 А что же дальше?

На мой взгляд вся идея хорошо ложится на речевые и аудио модели, в которых проблема длинных контекстов стоит еще острее. Как думаете, является ли эта работа своего рода proof of concept и увидим ли мы эту идею в следующем Moshi? Также интересно, как далеко можно зайти с multi-decoder подходом: один универсальный энкодер для сжатия + мини адаптеры под каждую LLM

В далеком 2020 году вывели степенные законы масштабирования для pre-training. Теперь команда Meta (и партнеры из академии) попытались сделать то же самое для RL

🔗«The Art of Scaling RL Compute for LLMs» показывает, что это предсказуемая сигмоида и предлагает ScaleRL рецепт стабильного RL проверенный на 100k GPU‑часов

😑 Почему не power law, а sigmoid?

В отличие от pre-training, где cross-entropy loss следует степенному закону, в RL метрики обычно ограничены сверху (accuracy, pass@k) и ведут себя как sigmoid. Логично: в начале модель исследует пространство, учится базовым навыкам, рост медленный. Затем наступает начинает собирать атомарные навыки в сложные стратегии, и точность взлетает. Ближе к потолку прогресс снова замедляется, образуя S-кривую.

Зачем это нужно? 💵 Чтобы на малом compute 10k GPU-часов предсказать, что будет на 100k, и не тратить бюджет на алгоритм, который рано упрется в потолок

Авторы выяснили, что компоненты рецепта влияют на два параметра: асимптотический потолок (достижимая точность) и крутизну кривой (скорость обучения)

А теперь три самых важных параметра в RL тренировочном рецепте:

💪 Pipeline-RL off-policy архитектура

Обычный PPO синхронный. Генераторы создают роллауты, ждут, пока тренирующиеся обновят веса, получают новые веса, повторяют. Получается, что половину времени кто-то ожидает

А вот PipelineRL‑k стримит роллауты и делает на лету обновление весов генераторам даже посреди генерации последовательности (со старым KV‑кэшем); тренирующиеся инстансы ждут, если ушли вперёд более чем на k шагов. При схожей верхней асимптотике PipelineRL‑k значительно ускоряет обучение

🕺 Loss функция: CISPO vs DAPO

Сравнили лоссы основанные на GRPO: DAPO (GRPO с asymmetric DAPO clipping) CISPO (из Minimax) и GSPO. И вот у DAPO верхнюю границу оценили гораздо ниже (см. картинку), что критично на практике

GRPO в свое время запустил всю эту волну reasoning моделей (см. картинку). Идея такая: давайте избавимся от critic model и будем считать для каждого сэмпла advantage в зависимости от того, какой реворд он получил относительно всех других кандидатов в группе.

Последующие работы документировали недостатки алгоритма. Например была такая тема с fork токенами ("однако", "но", "следует", …), которые в базовой модели получали низкую вероятность, но они важны в рассуждениях и в RL получают высокий реворд, а из-за clipping’а не могут особо повлиять на тренировку и сдвинуть output distribution в верном направлении

CISPO возвращается к REINFORCE, но клипает только importance sampling ratio, оставляя градиент по самим токенам: sg(clip(π_new/π_old, ε)) × Â. Stop-gradient делает это коэффициентом. GSPO в отличие от GRPO (и DAPO) переходит к importance sampling на уровне всей последовательности и стабильнее на длинных ответах

❕FP32 для LM головы

FP32 precision для LLM лоджитов. Это третий столп стабильного RL. Проблема в том, что генераторы и тренирующиеся используют разные compute kernels, к небольшим численным отличия в лоджитах. В importance sampling расхождения дестабилизируют, а FP32 для финального слоя почти устраняет проблему

Авторы вывели рецепт самых «оптимальных решений для RL». Там множество трюков: исключение промптов, где все генерации имеют одинаковый реворд, форсирование ответа на длинных цепочках и др.

Так как эксперименты ограничены проверяемыми задачами с бинарным ревордом (математика, кодинг), то я бы пока просто приняла к сведению идеи. Непонятно, будет ли ScaleRL скейлиться на непроверяемых задачах, например prosody в TTS, мало абляций на downstream задачах.

На мой взгляд инсайт в том, что алгоритмические выборы значительно влияют не только на скорость, но и на потолок реально достижимой производительности; а в совокупности составляют мощный рецепт, где влияние каждого отдельного выбора уже не ломает систему

😎 P.S.: О precision в RL давно спорят, в x идет движ по этой статье. Предлагают переходить с bf16 на fp16. Оба типа занимают 16 бит, но fp16 аллоцирует больше бит под мантиссу, дает большую точность (при меньшем диапазоне) и помогает избежать коллапса тренировки