Локальный ассистент для созвонов: как технические дыры в протоколе привели к реформе оговорки о записи

# Локальный ассистент для созвонов: как технические дыры в протоколе привели к реформе оговорки о записи

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

Невидимая тишина: анализ инцидента 15 сентября

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

Система захвата звука на базе ScreenCaptureKit сталкивалась с проблемами: поток кадров останавливался, процессор пытался перезапустить устройство, но часто зависал или возвращал ошибку "device unplugged" (устройство извлечено). Эти циклы проваливания и перезапуска происходили регулярно, создавая в коде события типа "крик демона", но не оставляя четких следов в финальной транскрипции.

Для локальной модели, генерирующей резюме встречи, полная тишина отсутствующего канала звукозаписи была неотличима от отсутствия возражений. Модель, следуя правилу «записывай только то, что прозвучало», корректно интерпретировала паузы как периоды молчания слушателей или технические перерывы, которые не требуют фиксации в тексте. В результате, из 65 минут реального времени в итоговом документе на шесть разделов (темы, решения, поручения и риски) ни слова не говорилось о том, что половина встречи вообще не была записана.

Разрыв между метаданными и итоговой стенограммой

Инцидент выявил критическую уязвимость в цепочке передачи данных между слоями системы. В сырых данных, доступных непосредственно разработчикам, существовали четкие события: пропал сигнал, начались попытки перезапуска, вернулся сигнал, снова пропал. Эти данные фиксировались в сайдкаре (служебном JSON) встречи.

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

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

Реформа оговорки и паспорт документа

Две внешние команды, проводившие ревью кода (DeepSeek и GLM), независимо друг от друга обнаружили тот же дефект, который две тысячи внутренних тестов не увидели. Они отметили, что входные данные для модели не были структурированы достаточно четко. Было принято решение ввести строгое разделение источников.

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

Если модель пересказывает эту оговорку своими словами, каноническая строка все равно дописывается в конец документа автоматически. Это гарантирует прозрачность: пользователь всегда увидит, что протокол является неполным, и сможет счесть решения, принятые в тишину, как потенциально сомнительные.

Система также引入了 «паспорт» документа. Это хеш, вычисляемый на основе финальной версии документа и его источника, включая новые оговорки. Если в стенограмме появлялись технические сбои, менявшие состояние канала, паспорт документа обновлялся, сигнализируя, что старые версии протокола устарели и должны быть пересобраны. Это защищает от ситуаций, когда изменения в коде захвата звука меняли бы смысл уже созданных отчетов.

Выводы и дальнейшие шаги

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

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

*Автор: Umine Nagi, редактор ИИ-новостей.*