Локальный ассистент после двухчасового созвона записал шутку как решение, назначил задачи отсутствующему человеку и перепутал исполнителя. Облачная модель нашла ошибки и приложила цитаты с таймкодами — но система не умела отменять уже записанные выводы.
Суть события
Автор локального ассистента для видеовстреч обнаружил архитектурную дыру в этапе после кнопки «Стоп». Быстрая локальная модель собирала минутки по ходу разговора, а большая облачная модель позже читала стенограмму целиком и проверяла результат. Проверка работала с конца июля для каждой встречи, однако оставалась лишь ещё одним читателем: она могла дописать найденное, но не снять ложное решение или поручение.
Проблема проявилась на рабочем созвоне. Из трёх решений ревизия отвергла два: шутку про бюджет и задачу соседней команды. В третьем решении оказался неверный исполнитель. Ещё три поручения были ложными, а имя ведущего распознавание определило неправильно. Несмотря на корректную ревизию, ошибочные пункты попали во вкладку задач и память ассистента.
Детали
Исправление потребовало превратить ревизию из комментария в управляющий этап. Теперь снятое поручение не удаляется бесследно: оно переносится в раздел «Снято ревизией», зачёркивается и получает причину. Один пункт ревизии может снять только одну строку. Если нечёткое сравнение находит несколько кандидатов и нет точного совпадения, код ничего не меняет и пишет о неоднозначности в лог. Выполненные человеком задачи автоматически не снимаются.
Для решений используется заметная метка: значок решения меняется на знак отмены, рядом появляется причина. Все компоненты, читающие заметку, должны понимать, что такой пункт больше не является решением. Исправления имён тоже стали машинно применимыми, но с ограничениями: нельзя сливать две дорожки, менять аппаратную метку микрофона владельца или простым последовательным поиском обменивать имена местами.
Особенно дорогой частью оказалась синхронизация со второй памятью на базе векторного поиска и Postgres. У неё не было ключа отдельного факта, поэтому ради удаления одного ошибочного решения приходилось забывать всю встречу и отправлять её заново. Сбои между этими действиями создавали долги, очереди и риск оставить память пустой. После нескольких кругов ревью автор решил отказаться от дублирующей памяти, предварительно перенеся личные факты в граф и проверив, что новый поиск отвечает на те же вопросы.
Контекст
Локальная модель не обязательно «хуже» по своей природе: во время встречи она видит лишь текущий хвост стенограммы. Смех, который объясняет шутку, или позднее уточнение исполнителя могут появиться через несколько секунд. Облачный проход получает весь разговор и поэтому лучше различает окончательные решения, контекст и говорящих. Практический вывод для команд, которые строят подобных ассистентов: качество второй модели бесполезно без права безопасно отменять результаты первой.
Это напрямую влияет на стоимость и B2B-решения. Один полный облачный проход после встречи может быть экономичнее попытки заставить крупную модель постоянно обрабатывать разговор в реальном времени. Но экономия исчезает, если компания поддерживает две несогласованные памяти, оплачивает повторные разборы или тратит рабочее время на ложные задачи. Главная инвестиция здесь — не ещё одна модель, а надёжный протокол применения, отката и повторной доставки её исправлений. При выборе рабочего инструмента полезно сопоставлять не только модели, но и способы контроля их действий — соответствующие критерии собраны в обзоре AI Digest (ai-digest.ru) об AI-ассистентах.
Что дальше
Автор планирует перенос нескольких сотен личных фактов в обычные markdown-файлы графа, подключение поиска по ним, затем дамп и остановку старых служб. Удаление намечено только после периода параллельной проверки: старая память продолжит работать, пока новая не подтвердит эквивалентные ответы.
Для разработчиков полезен и более общий чек-лист. У каждой ревизии должен быть явный статус и ограниченный повтор; таймаут не стоит автоматически запускать снова с тем же контекстом. Неоднозначное нечёткое совпадение должно останавливаться, если цена ошибки — тихая потеря данных. А тесты обязаны включать неудобные реальные значения из конфигурации, например полное имя владельца, а не только удобные однословные примеры.
