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

Автор серии, Игорь Градов из dzen.guru, документирует сборку локального ассистента, который записывает рабочие созвоны, раскладывает их в граф знаний (структуру связей между людьми, решениями и задачами) и генерирует минутки. Материал опубликован на этой неделе как четвёртая часть цикла. В центре внимания: двадцать пять минут после нажатия кнопки «Стоп», когда на экране ничего не происходит, а на диске разворачивается полный конвейер обработки.

Что делает конвейер за 25 минут после звонка?

• Пересборка стенограммы. Живой черновик, собранный из трёхсекундных кусков по ходу встречи, после остановки записи проходит заново: диаризация (разделение речи по говорящим) по каналам, удаление эха микрофона, угадывание имён по обращениям в разговоре. Старая версия стенограммы уходит в скрытую папку на случай, если человек правил текст руками.

• Граф. Локальная модель на 35 миллиардов параметров с архитектурой MoE (Mixture of Experts, когда модель активирует только часть своих «экспертов» под каждую задачу), запущенная через Ollama, разбирает стенограмму в JSON: люди, системы, решения, поручения. Из этого собираются заметка встречи, узлы графа и факты в память.

• Ревизия. Если включён облачный слой, отдельный процесс отдаёт стенограмму, минутки и контекст графа большой облачной модели через CLI (интерфейс командной строки) по подписке. Модель пишет отчёт: где локальная ошиблась, что пропустила.

• Доставка. Ревизия сохраняется рядом со стенограммой, минутки перечитываются во вкладку «Задачи».

• Ночной цикл. Досье, ревизия ядер графа, утренний бриф.

Ошибка, которая жила с июля

Ревизия работала с конца июля, каждый день, по каждой встрече. Но её выводы никуда не доходили. Второй проход был устроен как наблюдатель без права вмешиваться.

На конкретном двухчасовом созвоне в пятницу это выглядело так. Локальная модель записала в минутки три решения и список поручений. Облачная ревизия, прочитав стенограмму целиком, два решения из трёх отвергла:

• Одно оказалось шуткой про бюджет («один токен на всех, следующий запрос в следующем году»).
• Второе было задачей соседней команды, а не участников звонка.
• У третьего решение верное, но не тот исполнитель.

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

Всё это лежало в файле ревизии с цитатами и таймкодами. Но шутка оставалась в заметке с пометкой «решение», ложные факты уходили в память за двадцать минут до того, как ревизия успевала их опровергнуть. Поиск по памяти потом отдавал «единый токен для всех команд» как принятое решение.

Почему нельзя просто сделать локальную модель умнее?

Локальная модель пишет минутки каждые две с половиной минуты, видя только хвост стенограммы. Шутка про бюджет выглядит как решение, потому что смех через десять секунд модель ещё не видела. Человек, упомянутый трижды, выглядит как участник. Слово «текучка» в разговоре про бюджет читается как «текучесть кадров», и в рисках встречи появляется «остановка разработки из-за увольнений».

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

Как теперь работает снятие ошибок?

Ревизия говорит с кодом не прозой, а строгими разделами: «Восстановленные поручения», «Снятые поручения», «Исправления имён». Раньше работал только первый раздел, два новых добавлены на этой неделе.

Ключевой принцип: цена ошибок несимметрична. Съеденное поручение человек не увидит никогда, лишний дубль увидит и снимет одним кликом. Отсюда жёсткие правила сопоставления:

• Один пункт ревизии снимает ровно одну строку.
• Если подходят несколько строк и нет точного совпадения, не снимается ничего, в лог записывается: «подходит к двум пунктам, не гадаем».
• Вложение засчитывается от двух общих значимых слов: одно слово «позвонить» не снимает «позвонить в банк».
• Пункт, отмеченный человеком как сделанный, не снимается никогда.
• Снятая строка не удаляется, а переезжает в раздел «Снято ревизией» зачёркнутой, с причиной.

Внешний ревьюер за пятнадцать минут показал, что первая версия кода сопоставления работала с ошибкой: «подготовить отчёт» вкладывалось в «подготовить отчёт по бюджету» и заодно сносило «отчёт по срокам».

Как попробовать?

1. Прочитайте все четыре части серии на dzen.guru: в них описан полный конвейер от записи звонка до ночного цикла обновления графа.
2. Для запуска локальной части потребуется Ollama и модель на 35 миллиардов параметров с архитектурой MoE. Автор использует именно такую конфигурацию, конкретное название модели в публикации не указано.
3. Для облачной ревизии нужна подписка на CLI-доступ к большой модели. Какой именно сервис используется, автор также не уточняет.
4. Код конвейера публикуется в серии по частям, готового репозитория для установки «в один клик» пока нет.

Есть ли аналоги в России?

Среди крупных российских сервисов YandexGPT и GigaChat умеют работать с текстом, но готового локального ассистента для созвонов с графом знаний и двухступенчатой ревизией ни один из них не предлагает. Это авторская сборка из нескольких моделей, а не коробочный продукт.

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

Что это меняет для вас?

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

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

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

Частые вопросы

Нужен ли мощный компьютер для локального ассистента?

Автор использует модель на 35 миллиардов параметров через Ollama. Для комфортной работы такой модели обычно нужна видеокарта с большим объёмом памяти или мощный процессор. Точные системные требования в публикации не указаны, но это не ноутбук начального уровня.

Можно ли обойтись без облачной ревизии?

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

Это готовый продукт, который можно скачать?

Нет. Это авторская сборка, которую Игорь Градов документирует по частям в серии публикаций. Готового установщика или репозитория для запуска «из коробки» пока нет. Серия полезна как карта архитектурных решений и ошибок для тех, кто строит подобные конвейеры самостоятельно.