Проєкт 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 або корпоративне вікі, а агенти використовують той самий шар послуг зі своїми ідентифікаторами та правами доступу.

Корпоративні знання потребують більшого, ніж просто посилань між записами

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

Її система знань мусить розрізняти:

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

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

Ось чому схема має велике значення. Вона робить більше, ніж просто називає папки та файли. Через неї агент дізнається, як компанія кодує свої знання. Метадані на окремій сторінці wiki можуть виглядати так:

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 також стає доказом: вона показує, чи зберігалося існуюче знання цілісним, чи його просто замінили ще одним оглядом.

Це був повний протокол. Перша реальна реалізація обрала інший шлях, адже вона була створена в рамках іншого експерименту, під час якого штучний інтелект розробляв програмний проєкт під час довгої поїздки.

Перша версія

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

Те, що повернулося, — це локальна програма командного рядка, написана на Python. Вона читала вихідні тексти у форматі Markdown та їхню передмову, виділяла докази, позначені точними рядками, з яких вони походять, та оцінювала авторитетність джерела окремо від дати його публікації. Документи з чітко вказаними версіями позначалися як поточні або історичні. Цей інструмент також міг створювати звіти у форматі Markdown, знаходити докази, релевантні певному запиту, та перевіряти вікі на наявність структурних помилок. Вихідні документи зберігалися окремо від створеної папки wiki/, а репозиторій містив інструкції для адміністраторів, записи виконання, матеріали для оцінки та результати в їхніх власних місцях. Усі 26 тестів пройшли. Це була функціональна перша версія, хоча скорочений набір даних дозволяв протестувати лише частину протоколу Cedar.

Чи може він зберігати те, що знає компанія?

За оцінкою без урахування додаткових факторів система набрала 50%. Вона добре справлялася зі зберіганням доказів: посилання на джерела та інформація про походження кожної фактичної одиниці точно вказували, звідки були взяті дані. Складністю було знаходити та читати правильні докази, коли поставало реалістичне запитання.

Справжнє корпоративне запитання може вимагати об’єднання фактів з кількох файлів, надання пріоритету схваленому рішенню перед випадковою запискою, виявлення того, що новіший документ може мати меншу автентичність, розрізнення відкритого запитання від прогалини в записах, а також підтримання невизначеності, коли остаточного рішення ще немає. Збереження доказів виявилося важливішим за їх відбір. Структурний аудит виявляв механічні недоліки, такі як відсутність метаданих чи пошкоджена структура, проте семантичні суперечності проходили непоміченими легше, оскільки два документи могли містити несумісні твердження у різних формулюваннях, і система не завжди помічала цей конфлікт.

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

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

Вікі потребує інтерфейсу для компанії

Експеримент також прояснив один важливий аспект архітектури. Obsidian зручний для перегляду створеного Markdown, переходу за посиланнями, перевірки метаданих та ручної корекції сторінок. Цього достатньо для особистого використання чи прототипування, проте жодна компанія не може надати кожному співробітнику та агенту прямий доступ до одного сховища. Між Markdown-вікі та його користувачами справжня система потребує проміжного шару, який би включав:

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

Політики зберігання та видалення

Інтерфейс, який може використовувати персонал без технічних знань

Аутентифікація визначає, хто здійснює запит, тоді як авторизація вирішує, до чого може мати доступ цей користувач щодо джерел, сторінок та операцій. Агенти підпадають під ту саму класифікацію. Агент фінансової команди не повинен мати доступу до клінічних записів лише через те, що обидві колекції файлів знаходяться в одному wiki, тому агенти потребують власних ідентифікаторів сервісу, обмежених прав та обов’язків з аудиту, які є у людей. Права також мають враховувати те, як агент змінює інформацію: резюме проекту, взяте з публічного документа архітектури, та обмежений огляд безпеки можуть розкрити конфіденційні деталі, навіть якщо сторінка здається нешкідливою.

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

1. Шар доказів: незмінні корпоративні джерела з їхніми початковими правами доступу
2. Шар знань: wiki у форматі Markdown, підтримуваний Git, та його внутрішні зв’язки між джерелами
3. Шар керування: ідентифікація користувачів, права доступу, процедури рецензування, історія аудиту та функції пошуку
4. Шар інтерфейсу: Obsidian для тих, хто підтримує wiki, корпоративний сайт у форматі wiki для співробітників, а також обмежені API для агентів

Корпоративний інтерфейс не дублює знання; він контролює спосіб взаємодії людей та агентів з ними.

Що перевірити далі

Наступний запуск має використовувати повне корпус Cedar: завантажити всі 25 початкових документів, оцінити початковий вікі та зберегти його, потім додати вісім документів зі змінами та перевірити, чи агент оновлює кожну зачеплену сторінку, позначає старі рішення як устарілі, зберігає історію, яку варто зберегти, дотримується правил авторитетного джерела, виводить на видимість нерозв’язані суперечки, утримується від ухвалення рішень за власним розсудом та створює Git diff, який може переглянути людина.

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

Чи можуть агенти підтримувати те, що знає компанія?

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

Markdown може слугувати спільним форматом, але компанії все одно потрібен контрольований інтерфейс навколо нього. І людям, і агентам потрібні ідентифікатори, дозволи мають передаватися від початкового джерела до створених сторінок, редагування агентами потребують перевірки, а кожна схвалена зміна має мати історію. Створення вікі було простою частиною. Справжні зусилля вимагається для вирішення питань: що компанія вважає знанням, хто може це бачити та як агентам дозволяється його змінювати.