Локальный ассистент для конференц-связи: как сделать так, чтобы ИИ не искажал историю

# Локальный ассистент для конференц-связи: как сделать так, чтобы ИИ не искажал историю

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

Архитектура памяти: три слоя без базы данных

Основой системы является папка с файлами Markdown, которая открывается в редакторе Obsidian. В отличие от графовых баз данных с жесткой структурой, здесь управляет человеком. Схема построена по принципу трех уровней:

1. Встречи: Сырые данные. Здесь лежат файлы с датой и временем встречи (например, 2026-07-17_1400_Платёжный провайдер.md). Они содержат стенограмму и транскрибированные минитюки. Это «эпизоды». 2. Сущности (Люди, Системы, Команды): Узлы, связанные обратными ссылками с встречами. Например, профиль сотрудника содержит список встреч, где он упоминался. 3. Ядра и Досье: Сквозные темы, хроника событий и готовые сводки. Это уровень абстракции, где собрано состояние по конкретным темам (например, «Выбор платёжного провайдера»).

Главное преимущество такого подхода — читаемость. Даже если автоматический код перестанет работать, человек сможет открыть любую папку и найти нужную информацию с помощью стандартных инструментов (grep, git).

Правило достоверности: факт живет с датами

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

Решение заключалось во введении временных меток для каждого факта. В разделе статуса сохраняется актуальное положение дел. Устаревшие статусы не удаляются, а перемещаются в раздел «Хроника» с четкими пометками: дата начала действия статуса и дата его завершения.

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

Отслеживание источников: борьба с выдуманными цитатами

Одной из самых серьезных проблем стал вопрос авторства цитат. В ранней версии системы модель могла уверенно цитировать участников, но эти цитаты отсутствовали в исходной стенограмме. Происходило это из-за того, что «ко-мышление» модели (ее внутренние заметки) ошибочно принималось за реплики человека.

После проведения внешних ревизий было выявлено, что поле «кто сказал» часто бралось из ответа самой модели, а не из текста встречи. Это привело к созданию механизма жесткой верификации:

* Источником факта стала исключительно стенограмма. * Имена спикеров и временные метки читаются автоматически из строки реплики. * Если в стенограмме нет подтверждения для цитаты, факт добавляется в граф без авторства.

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

Досье как этаж между поиском и памятью

Поиск по графу может возвращать десятков фрагментов из разных встреч, что заставляет ИИ заново синтезировать ответ каждый раз по-разному. Для решения этой проблемы введено понятие «Досье».

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

В 04:15 ночи запускается процесс ревью (прогона). Локальная модель анализирует досье и ядра, проверяя, не изменился ли состав источников. Если данные обновлялись недавно, изменения не применяются, чтобы не мешать текущим рабочим процессам. Обновление происходит инкрементально: каждый раз пересобираются только те темы, у которых изменились входные данные. Полный пересбор occurs раз в неделю.

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

Ночной режим и гигиена данных

Чтобы ночной прогон не конфликтовал с живыми встречами, он спроектирован как автономный процесс.

Правила ночи: * Приоритет живых встреч. Если созвон идет, ночной шаг приостанавливает ревизию, чтобы не разрывать запись. * Жесткие таймауты. У процесса есть лимит времени, превышение которого останавливает выполнение. * Проверка целостности. Перед стартом скрипт проверяет наличие необходимых библиотек и статус системы.

Также реализован механизм работы с облачными моделями. По умолчанию облако выключено. При его включении используется «песочница» — клон графа, где облачная модель (например, Opus) пересматривает данные. Любые изменения в песочнице не попадают в основной граф без явного подтверждения и разрешения конфликтов. Живая работа на локальной машине всегда имеет приоритет над удаленными правками.

Система также включает «доктора» для проверки здоровья графа. Ежедневно скрипт без участия ИИ проверяет битые ссылки, дубликатов узлов людей и сиротские файлы, генерируя отчет о состоянии базы знаний.

Забывание и безопасность

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

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

Заключение

Создание надежной системы памяти на основе локальных моделей требует дисциплины. Факты должны быть привязаны к датам, цитаты — к реальным источникам, а структура — подчиняться логике человека, а не алгоритмов кластеризации. Только такой подход позволяет превратить хаотичные записи из конференц-связи в полезный инструмент управления знаниями, который не теряет историю и не выдумывает правду.