Heartbeat Thinking учит голосовых агентов работать, пока вы ещё говорите: задержка −36,4%

Голосовые агенты с инструментами обычно ведут себя одинаково: пользователь договорил, и только после этого начинается пауза. Модель собирает аргументы, вызывает API, ждёт ответа и формулирует реплику. Новая работа с Hugging Face Daily Papers, Heartbeat Thinking, пытается забрать это время себе. На бенчмарке FDBench v3 подход поднял охват инструментов на 16 процентных пунктов и сократил среднюю задержку финального ответа на 36,4% по сравнению с базовой схемой в стиле SHANKS.

Почему спекулятивный запуск ломается на полуслове

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

Представьте запрос: «Найди мне рейс в Стамбул на пятницу… и заодно проверь, нужна ли виза». Город и дата прозвучали в первой половине фразы. Окно, которое перезапускается на каждом новом слове, рискует выбросить уже начатый вызов, хотя информации для него хватало.

Как работает «сердцебиение»

Авторы меняют логику обработки обновлений. Новый кусок речи не отменяет текущую работу, а запускает отдельный вызов Thinker. Уже идущие вызовы и отправленные инструменты спокойно доделываются. Thinker стартует периодически, как пульс, отсюда и название. Каждый запуск читает два источника: свежий частичный транскрипт и общую запись о завершённых рассуждениях и результатах инструментов.

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

Что показали тесты

Систему сравнивали с окнами в стиле SHANKS на трёх наборах: SpeechFCEval, FDBench v3 и AudioCRAG. Метрики разные. Для задач с вызовом функций считали спекулятивное покрытие инструментов, для AudioCRAG, где важен поиск, считали повторное использование найденного.

• Метод повышает агрегированное покрытие инструментов или переиспользование retrieval относительно оконной базы.
• FDBench v3: охват инструментов +16 п.п.
• FDBench v3: средняя задержка финального ответа −36,4%.
• Влияние на итоговое качество задачи зависит от бенчмарка: прирост есть не везде одинаково.

Последний пункт важен. Авторы не утверждают, что схема улучшает ответы всегда. Главный выигрыш лежит в скорости и в доле работы, выполненной до конца реплики. Качество при этом в основном не страдает, хотя величина эффекта различается по наборам данных.

Что менять в продакшене голосовых агентов

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

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