Александр Петров
Второй мозг, который не гниёт: как мы дали ИИ писать в базу знаний — и почему через месяц отобрали автономию
Какую задачу решаем
Компании заводят «второй мозг» — базу знаний в Notion, Obsidian или графе — и сажают туда ИИ, чтобы он наполнял её сам: разбирал встречи, доставал решения и договоренности, обновлял проекты. Через несколько месяцев база превращается в мусор. Структура разваливается, данные противоречат друг другу, один и тот же человек живёт в трёх местах, а любой отчёт поверх этого приходится править руками. Обычно это списывают на недисциплинированность команды или на слабую модель. Кажется, дело не в этом: причина архитектурная. ИИ дали свободную запись в базу знаний, а энтропию гонит мультидеятельность — ситуация, когда одни и те же знания нужны сразу нескольким направлениям работы. В докладе показываю, где именно течёт и какой слой между ИИ и базой знаний эту течь закрывает.
Как будем работать
- Отталкивались не от болей, а от дерева сценариев менеджмента знаний (83 узла на KM-методологии): дерево — это уже систематизированные боли, поэтому покрытие дерева = покрытие болей, а проверка дизайна становится инженерной.
- Выбрали топологию «общее ядро + линзы» вместо силосов по проектам: сущность живёт в стволе один раз, направления ссылаются на неё, дублей и противоречий нет. Решение проверено на Common Room (Person360), Glean и RDF named graphs.
- Главный принцип: сценарий работы со знанием — это операция над графом, а не промпт. Как в СУБД: не правим файлы таблиц руками, а работаем через узкий набор операций в транзакционном контексте. В типовой ИИ-обвязке этого слоя нет — модель пишет через сырой CRUD, и именно здесь течёт энтропия.
- Собрали алгебру из 9 операций на жизненный цикл знания: взять линзу, вспомнить, захватить, свести, утвердить через «детект-затем-разрешение», продвинуть из личного контура в общий, вывести устаревшее, эволюционировать схему, провести фоновую прополку.
- Схема-на-запись вместо уборки после: данные не по схеме не сохраняются молча, а уходят в очередь на разбор; дедупликация — по расстоянию в эмбеддинг-пространстве, а не по имени.
- Первый сценарий — конвейер «звонок → знание»: запись встречи → транскрибация на своём сервере → извлечение решений, рисков и обещаний → атомы в проекте.
- Автономную запись агентам выдали и через месяц откатили в очередь приёмки с обязательным подтверждением человеком. Разбор ошибки и критерий выдачи автономии — отдельный блок доклада.
- Инструменты: Whisper, Claude, собственный граф знаний с векторным поиском, MCP и самописная очередь приемки. Всё разбирается на уровне архитектуры и переносится на Notion, Obsidian или любую другую базу.
Результат
Через конвейер «звонок → знание» прошло 176 встреч (2–3 в день): разбор, который раньше делался руками или не делался вовсе, приходит готовым черновиком и подтверждается за минуты. Поверх одной базы работают четыре сценария — разбор встреч, трекинг клиентов, мониторинг профильных чатов и ежедневные скауты, — а не четыре бота со своими базами, которые пришлось бы синхронизировать. Главный эффект не в сэкономленных часах: знание перестало жить в головах и переписках, новый сотрудник и новый ИИ-агент читают одну базу вместо того, чтобы расспрашивать руководителя. Обратная сторона: месяц автономной записи агентов дал столько правок задним числом, что ручная приемка вышла дешевле, — после этого архитектуру пересобрали.