Проект Cedar: тестирование способности ИИ-агентов поддерживать корпоративный Wiki в формате Markdown.

Obsidian позволяет передавать контекст между проектами человека и его инструментами для программирования. Планы, решения, требования и ограничения сохраняются дольше отдельных сессий; Claude, Codex или любой другой инструмент могут читать те же файлы проекта, а человек может проверять и корректировать эти файлы, а также менять модели без того, чтобы знания о проекте застревали в истории чатов. Это хорошо работает внутри проектов одного человека, поскольку именно он принимает большинство решений и знает, как всё организовано.

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

Идея LLM Wiki

Эта концепция возникла из недавнего предложения Андрея Карпати, который назвал её LLM Wiki. Она включает три уровня:

• Чистые исходные данные, которые никогда не изменяются
• Вики в формате Markdown, связанный между собой и поддерживаемый агентом
• Схема, которая указывает агенту, как организовывать и обслуживать этот вики

Три операции воздействуют на эти слои. Функция Ingest добавляет новые источники информации. Функция Query использует уже существующие знания. Функция Lint проверяет вики на наличие пробелов, устаревшего материала, конфликтов и плохой структуризации.

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

Первая архитектура, оказавшаяся неверной

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

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

Предлагаемая схема работы выглядит следующим образом. Компания получает неизменяемые исходные данные. Агент, отвечающий за ведение вики, использует схему и правила управления для предложения изменений, а одобренные изменения после проверки попадают в вики на основе Markdown с поддержкой Git. Слой сервисов обеспечивает аутентификацию, разрешения, поиск и историю аудита. Люди получают доступ к знаниям через Obsidian или корпоративный вики, а агенты используют тот же слой сервисов с собственными учетными данными и разрешениями.

Корпоративным знаниям нужно больше, чем просто ссылки между заметками

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

Её система знаний должна уметь различать:

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

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

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

status: verified
owner: platform-team
last-reviewed: 2026-08-02
review-after: 2026-11-02
sources:
  - adr-014
  - meeting-2026-07-29
supersedes:
  - authentication-proposal-v1

Заставить агента генерировать Markdown — это просто. Сложно определить, что он может считать организационной истиной.

Вымышленная компания в качестве тестовой площадки

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

Чтобы обойти эту проблему, в ходе эксперимента был создан проект Cedar — вымышленное сотрудничество, при котором компания Northstar AI Consulting работает на Prairie Health Network. Всё в нем является фикцией. Консалтинговая компания разрабатывает систему, преобразующую документы с политиками и записи оценок качества в проектные краткие отчеты с указанием источников, а также обеспечивающую внутренний поиск. Этот сценарий отражает реальные проблемы, такие как конфиденциальность данных, использование локальных или облачных ресурсов для обработки информации, проверка человеком, оценка моделей, выбор архитектуры, возможность отслеживания источников и постоянно меняющиеся требования.

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

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

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

Эксперимент, который может провалиться

Планируемый протокол состоит из двух этапов.

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

На этапе B публикуется обновлённый набор данных. Теперь агент должен пересмотреть каждую затронутую страницу, сохранить устаревшие решения в качестве истории, сделать видимыми нерешённые разногласия и устоять перед соблазном считать самый свежий документ окончательным. Результаты операции Git diff также становятся доказательством: они показывают, сохранялась ли согласованность существующих знаний или они были просто заменены ещё одним кратким изложением.

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

Первая версия

Первая версия Cedar возникла в результате этого эксперимента с поездкой, детали которого не имеют значения. Важно то, что смог предоставить агент. Его входными данными были элементы корпуса Cedar, инструкции по проекту и набор для оценки, скрытый от его вида. Проект ChatGPT ограничивал количество загружаемых файлов 25, поэтому к агенту дошло лишь восемь из первоначальных 25 файлов, а корпус с изменениями был отложен для последующей передачи в качестве теста на способность агента внедрять изменения в документацию.

В результате была получена местная программа командной строки, написанная на Python. Она читала исходники в формате Markdown и их метаданные, извлекала доказательства с указанием точных строк, откуда они взятысь, и оценивала авторитетность источника независимо от даты публикации. Документы с указанными версиями маркировались как актуальные или исторические. Инструмент также мог генерировать отчеты в формате Markdown, находить доказательства, релевантные конкретному вопросу, и проверять wiki на структурные ошибки. Исходные документы хранились отдельно от созданной папки wiki/, а репозиторий содержал инструкции для администраторов, записи выполнения операций, материалы для оценки и результаты в своих отдельных разделах. Все 26 тестов прошли успешно. Это была рабочая первая версия, хотя уменьшенный набор данных позволял протестировать лишь часть протокола Cedar.

Может ли он сохранять информацию, известную компании?

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

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

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

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

Вики нуждается в интерфейсе для компании

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

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

Политики хранения и удаления данных

Интерфейс, который могут использовать сотрудники без технической подготовки

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

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

1. Слой доказательств: неизменяемые корпоративные источники с их первоначальными правами доступа
2. Слой знаний: вики на основе Markdown с поддержкой Git и связи между исходными данными
3. Слой управления: идентификация, права доступа, процедуры рецензирования, история аудита и функции поиска
4. Слой интерфейса: Obsidian для сотрудников, обслуживающих вики, корпоративный вики-сайт для сотрудников, а также ограниченные API для специальных агентов

Корпоративный интерфейс не дублирует знания. Он контролирует способ взаимодействия сотрудников и агентов с этими данными.

Что проверить далее

В следующей запусковой процедуре следует использовать полный корпус Cedar: загрузить все 25 начальных документов, оценить первоначальную вики-страницу и сохранить результат, затем добавить восемь документов с изменениями и проверить, обновляет ли агент все затронутые страницы, отмечает ли старые решения как устаревшие, сохраняет ли историю, которую стоит хранить, соблюдает ли правила авторитетности источников, выделяет ли нерешенные разногласия, воздерживается ли от принятия решений самостоятельно и генерирует ли Git-различия, которые может просмотреть человек.

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

Могут ли агенты поддерживать знания компании?

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

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