Как устроена база знаний для WikiAgent
WikiAgent опирается на знания, которые для модели выглядят как обычная рабочая папка: в ней есть личное пространство сотрудника, один или несколько подключённых git-репозиториев с документами и корпоративный файл AGENTS.md с правилами поведения. Ниже — как это устроено концептуально и зачем такое разделение.
Зачем агенту структурированная база знаний?
Когда компания внедряет ИИ-агента, часто возникает соблазн просто загрузить все корпоративные документы, регламенты и переписки в единую базу и надеяться, что нейросеть сама во всём разберётся. На практике это быстро приводит к проблемам: агент начинает путать устаревшие инструкции с актуальными, выдавать внутренние данные одного отдела другому или опираться на чьи-то личные черновики как на официальный регламент.
Чтобы ИИ-ассистент приносил реальную пользу, давал точные ответы и не галлюцинировал, ему нужен чёткий контекст и понятные границы. Он должен отличать утверждённые правила компании от рабочих материалов команды и личных заметок сотрудника.
Кроме того, в любой компании есть разные отделы — продажи, HR, разработка, финансы. У каждого из них своя специфика, свои термины и свои изолированные базы знаний (под-базы). Агент должен уметь учитывать эту структуру: понимать, к какой базе обращаться в зависимости от контекста вопроса и роли пользователя, а также строго соблюдать права доступа. Нельзя допустить, чтобы стажёр из маркетинга случайно получил выжимку из конфиденциальных документов финансового отдела.
Именно поэтому мы спроектировали базу знаний для WikiAgent не как непрозрачный «чёрный ящик», а как строгую и управляемую систему.
Почему база знаний — это файловая система
Инструменты на базе больших языковых моделей хорошо умеют читать и править текстовые файлы, искать по дереву каталогов и следовать инструкциям из markdown. Поэтому в WikiAgent база знаний представлена как файловая система в корне /workspace: так проще рассуждать о правах, версиях и границах ответственности между «моими черновиками» и «общими регламентами компании».
Что лежит в /workspace
Набор каталогов может отличаться от проекта к проекту, но типичная схема выглядит так.
Пример дерева (упрощённо)
/workspace/
personal/ ← личная зона пользователя
knowledgebase_common/ ← общая база компании
knowledgebase_sales/ ← база отдела продаж
knowledgebase_hr/ ← база HR (и т. д.)
…
AGENTS.md ← правила работы агента для организации
/workspace/personal— персональная папка: временные файлы, экспорты, черновики и структуры, которые пользователь сохраняет сам. Это не замена корпоративной базе, а контролируемое место для индивидуальной работы рядом с общими знаниями./workspace/knowledgebase_*— отдельная точка монтирования для каждого подключённого внешнего репозитория с документами. Имена отражают содержимое:knowledgebase_commonдля общей базы компании,knowledgebase_salesдля отдела продаж,knowledgebase_hrдля HR и т. д.AGENTS.md— центральный файл с логикой агента на уровне компании: стиль ответов, приоритеты источников, шаги при нехватке данных, ограничения по действиям. Он задаёт «контракт» между бизнесом и поведением модели в вашем контуре. В какую базу знаний стоит обращаться в каком случае.
Схема: агент, workspace и git
SKILLS в терминологии workspace — это навыки, которые хранятся на уровне репозитория внутри рабочего контура: переиспользуемые инструкции и сценарии, живущие рядом со знаниями и версионируемые вместе с ними. Так команда может развивать и корпоративные регламенты, и «навыки» агента в одном git-процессе.
Внешние базы как git-репозитории
Каждая корпоративная база — это git-репозиторий с папками и документами (часто markdown, PDF, таблицы — в зависимости от политики компании). Поддерживаются привычные платформы: GitHub, GitLab, размещение в облаке или в контуре организации. При необходимости Wikilect может предоставить отдельный git для базы знаний.
- Несколько репозиториев — логичный вариант, если базы ведут разные отделы: например, отдельно
/workspace/knowledgebase_salesи/workspace/knowledgebase_hr, чтобы проще делегировать владельцев и разграничивать доступ. - Один крупный репозиторий — удобен, когда границы знаний размыты или команд мало; минус — сложнее тонко настроить права только на часть материалов.
- Разграничение прав — если нужен строгий контроль «кто что видит», обычно выбирают несколько репозиториев и настраивают в настройках компании, у каких пользователей есть чтение и у кого ещё запись в каждый из них.
Рекомендуемая структура контента
Содержимое подключённого репозитория может быть любым, но мы рекомендуем ориентироваться на подход LLM Wiki Андрея Карпатого: отдельно неизменяемые исходники, слой связных markdown-страниц и явный регламент структуры (у нас это пересекается с AGENTS.md). Короткий пересказ идей — в статье «LLM Wiki Карпатого: пересказ на русском»; как поиск и ответы по документам сочетаются с платформой — на странице AI для корпоративной базы знаний.
Практический смысл
Структурированная вики и осмысленные перекрёстные ссылки уменьшают хаос при росте базы и помогают агенту опираться не только на поиск по фрагментам, но и на уже согласованные сводки.
Краткие ответы на типовые вопросы
- Где хранятся «личные» данные? В
/workspace/personal, отдельно от общих репозиториев. - Где задаётся поведение агента для всей организации? В
AGENTS.mdи политиках, которые вы подключаете к workspace. - Как подключить базу отдела? Отдельный git-репозиторий и монтирование как отдельного каталога knowledgebase с нужными правами доступа.
- Что такое SKILLS здесь? Наборы инструкций и сценариев в репозиториях workspace, версионируемые вместе со знаниями.
FAQ
Обязательно ли использовать markdown и вики-подход?
Нет: это рекомендация для устойчивой структуры. Форматы и глубина детализации согласуются с вашей ИТ- и контент-командой.
Можно ли обойтись одним репозиторием?
Да, если модель доступа простая. Когда нужны разные уровни секретности по отделам, обычно проще несколько репозиториев и явные права в настройках компании.
Хотите такую модель знаний у себя?
Поможем связать git-базы, AGENTS.md и права доступа с WikiAgent и вашим ИТ-ландшафтом.
Читайте дальше
Выберите смежное решение Wikilect, чтобы сравнить сценарии внедрения и подобрать подходящий формат AI-автоматизации.
LLM Wiki Карпатого: пересказ на русском
Три слоя, загрузка / поиск / проверка и зачем index.md и log.md — коротко и по делу.
Решение WikiAgent
Продуктовая страница: сценарии для отделов, безопасность и внедрение.
AI для корпоративной базы знаний
Как поиск и ответы по документам стыкуются с платформой Wikilect.
Документация Wikilect
Технические детали интеграций и настройки — на официальном портале документации.