Второй мозг для ИИ-агента: проектирование базы знаний компании в Obsidian

Второй мозг для ИИ-агента: проектирование базы знаний компании в Obsidian

Внедрение ИИ-агентов и цифровых сотрудников в бизнес-процессы часто сталкивается с проблемой низкой точности ответов. Когда автономы подключаются к хаотично организованным базам знаний — сканам регламентов, тяжелым PDF-файлам или разрозненным документам в сервисах совместной работы, — модели начинают «галлюцинировать», путать тарифные сетки и выдавать клиентам устаревшие коммерческие условия. Кроме того, передача многостраничных документов в каждом запросе приводит к перерасходу токенов API.

Для решения этой проблемы корпоративную базу знаний проектируют в виде так называемого «второго мозга» (Second Brain) на базе локального хранилища Obsidian. Использование атомарных файлов в открытом текстовом формате Markdown, строго размеченных метаданных и карт навигации MOC (Maps of Content) позволяет создать структурированную среду, в которой ИИ-агенты безошибочно находят канонические факты с минимальными затратами вычислительных ресурсов.

Почему Obsidian и формат Markdown превосходят классические базы

Выбор Obsidian в качестве корпоративного стандарта обусловлен тремя архитектурными преимуществами:

• Открытый формат данных. Заметки хранятся в виде обычных локальных файлов с расширением .md (Markdown). Это устраняет зависимость от проприетарных облачных платформ и позволяет подключать к базе любых языковых агентов, локальные модели или скрипты автоматизации без конвертации.
• Минимальный расход токенов. В отличие от тяжелых документов PDF или DOCX, содержащих служебную разметку и стили, файлы Markdown представляют собой чистый текст. При поисковой выдаче и передаче контекста языковая модель считывает только полезные символы, что сокращает расходы на API-запросы в разы.
• Двунаправленные ссылки и графические связи. Встроенная поддержка связей между документами позволяет выстраивать семантическую сеть компании, где каждая услуга, продукт или регламент жестко привязаны к ответственным лицам и регламентирующим документам.

Официальная процедура: создание хранилища (Vault) в Obsidian

Создание и первичная настройка корпоративной базы знаний регламентированы официальной документацией Obsidian Vault Help. Хранилище (vault) представляет собой локальную папку на диске компьютера или корпоративного сервера.

Официальный порядок создания хранилища выполняется через пользовательский интерфейс приложения:

1. Запуск и выбор режима. При старте приложения в приветственном окне выберите вариант Create new vault и нажмите кнопку Create. Если корпоративная папка с заметками уже сформирована на сервере, выберите Open folder as vault и нажмите Open.
2. Назначение имени и директории. В поле Vault name введите название корпоративной базы знаний. В поле Location нажмите Browse, укажите абсолютный путь к локальной или сетевой директории и подтвердите создание кнопкой Create.
3. Проверка успешного развёртывания. В выбранной директории автоматически создаётся скрытая системная папка .obsidian, содержащая плагины и настройки приложения. С этого момента любые текстовые файлы .md, сохранённые в этой директории, становятся частью единой базы знаний.

Метаданные и свойства заметок (Properties)

Для того чтобы ИИ-агент мог отличать действующий регламент от черновика или устаревшего прайса, каждая заметка базы знаний должна снабжаться структурированными метаданными (Properties).

Официальная справка Obsidian Properties Help описывает добавление свойств через палитру команд (Add file property), меню заметки More actions или вручную в виде YAML-блока в самом начале файла. YAML-блок отделяется тремя дефисами --- сверху и снизу:

---
status: canonical
owner: "Александр Иванов"
reviewed_on: 2026-08-01
effective_from: 2026-08-01
valid_until: 2027-01-01
source_url: "https://internal.company.ru/docs/price-2026"
client: "B2B-сегмент"
product: "Корпоративный аудит"
access_level: restricted
canonical: true
---

Свойства поддерживают следующие официальные типы данных: текст, список, число, дата, время, логический флажок (checkbox) и теги. Технические ограничения: справка подчеркивает, что вложенные структурированные объекты не поддерживаются — свойства должны быть плоскими атомарными значениями. Также внутри полей Properties не поддерживается синтаксис разметки Markdown.

Для работы ИИ-агентов ключевым является поле canonical: true. Агенту задаётся жесткое правило: при формировании ответов использовать только те документы, которые имеют подтверждённый канонический статус.

Навигационные карты MOC и визуальный граф (Graph View)

По мере роста базы знаний прямое дерево папок теряет навигационную эффективность. Для структурирования контента используются карты навигации MOC (Maps of Content) — центральные узловые заметки, содержащие каталогизированные ссылки на атомарные файлы по конкретному направлению (например, MOC_Продажи.md или MOC_Продукты.md).

Для диагностики полноты базы и поиска изолированных файлов используется встроенный инструмент визуализации Graph View. Согласно документации Obsidian Graph View Help, плагин активируется в разделе Settings → Core plugins → Graph view и открывается кнопкой на боковой панели или командой Open graph view.

В окне графа текстовые заметки отображаются в виде узлов (кругов), а внутренние ссылки вида [[Имя заметки]] — в виде связывающих линий. С помощью фильтров граф позволяет мгновенно находить «сиротские» заметки (orphaned notes) — документы, не имеющие ни одной входящей или исходящей ссылки. Если документ по тарифам оказался изолирован от MOC-карты, ИИ-агент с высокой вероятностью пропустит его при контекстном поиске.

Трехслойная архитектура папок корпоративного хранилища

Для разделения сырой информации и проверенных фактов в Obsidian настраивается строгое разделение по трем папкам:

1. Inbox/ (Свалка / Входящие). Директория для первичного сохранения черновиков, расшифровок звонков, заметок со встреч и сырых выгрузок. ИИ-агентам категорически запрещено использовать файлы из этой папки в качестве источника истинных данных.
2. Notes/ (База знаний). Директория атомарных проверенных заметок. Каждая заметка посвящена одному регламенту, тарифу или регламенту и содержит заполненный блок YAML-свойств.
3. MOC/ (Карты контента). Директория навигационных узлов, объединяющих заметки по смысловым кластерам.

RAG без галлюцинаций: правила интеграции ИИ-агента

Подключение языкового агента к Obsidian выполняется по технологии RAG (Retrieval-Augmented Generation — генерация с привлечением извлечённых данных). Чтобы исключить галлюцинации и ошибки в клиентских коммуникациях, в промт агента закладываются следующие алгоритмические ограничения:

• Поиск только по каноническим свойствам. Агент обращается к индексу заметок и фильтрует файлы по значению canonical: true и актуальной дате valid_until.
• Обязательное ссылание на источник. В каждом ответе агент обязан указать заголовок заметки и поле source_url, из которого взята информация.
• Приоритет отказа при конфликте. Если в базе обнаружены два противоречащих документа с одинаковым статусом, агент не пытается угадать верный ответ, а эскалирует вопрос на ответственного сотрудника (owner), указанного в свойствах.

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

Пошаговый порядок развёртывания базы знаний в Obsidian

1. Формулировка регламента и ролей. Определить перечень канонических документов компании и назначить ответственных за их актуализацию.
2. Создание хранилища. Развернуть папку vault по официальной процедуре Obsidian и настроить бэкапы.
3. Создание структуры папок. Сформировать директории Inbox/, Notes/ и MOC/.
4. Заполнение YAML-шаблона. Разработать единый стандарт свойств для документов с обязательными полями status, owner, canonical и valid_until.
5. Создание базовых MOC-карт. Завязать ключевые заметки на навигационные карты и проверить связи через Graph View.
6. Настройка прав доступа агента. Подключить слой RAG-поиска с ограничением доступа только к каноническим Markdown-файлам.
7. Тестирование на контрольном наборе вопросов. Провести серию проверочных запросов на знание цен, сроков и условий, оценив точность ссылок на источники.
8. Внедрение регламента актуализации. Настроить регулярный аудит устаревающих заметок по полю valid_until.