Project Cedar: ці могуць AI-агенты весці вікі кампаніі ў Markdown
Выдуманы кансалтынгавы праект правярае патэрн LLM Wiki для ведаў кампаніі: што пабудаваў агент, чаму ён атрымаў 50% і чаго яшчэ не хапае ў кантролі доступу.
Obsidian можа перадаваць кантэкст між праектамі чалавека і ягоўскімі інструментамі для кодавання. Планы, рашэнні, вакаліяты і обмежэння застаюцца у часе, Claude, Codex або будзь-які іншы інструмент можа чытаць тыя ж файлы праекту, а чалавек можа пераглядаць і правіць гэтыя файлы, а таксама змінюваць мадэлі, не залішаючы інформацыю про праект у історыі чату. Гэта добра працуе ў межах праектаў аднаго чалавека, таму што гэты чалавек прымеў большасць рашэнняў і знае, як усё організавана.
У самай компаніі картына змініцца. Знанні розпыленыя між рэпазітарыямі, заявкамі, нарадамі, дакументамі і багатымі разнымі людзьмі. Джэрэла суперсачываюцца, а рашэнні можаць быць змененым. Набор прыметак нарады можа опісваць ідэю, якую команда пазней адмовілася адпрацоўваць, тады калі у затверджанам дакуменце архітэктуры зафіксавана рашэнні, якая насправдзе дыяўуе. Таму застаецца вопыт: чы можа прычыннае правіло для кожнага праекту распрастрацавацца на цэлую організацыю, і чы можа спільны Markdown служыць угодай між працавнікамі і агентамі.
Ідэя LLM Wiki
Гэты патэрн паходзіць з няўзначнага прыказу Андрэя Карпаты, які назваў яго LLM Wiki. Ён складаецца з трох слоёў:
- Сырыя джэрэлы, якія ніколі не мяняюцца
- Wiki на базе Markdown, які ўзаінтэрсоўаны і падтрымваны агентам
- Схема, якая паведамляе агента, як організаваць і падтрымваць гэты wiki
Трыя операцыі дзейнуюць над гэтымі шарамі. Функцыя Ingest прыносіць новыя джэрэлы. Функцыя Query апыляецца на збераганае ведамасць. Функцыя Lint пераканальвае вікі на наявнасць прасоў, застарэлага матэрыялу, канфліктав і пасляположнай структуры.
Серэд можлівых джэрэлаў, указаных у працэўнай прыяве, — размовы ў Slack, зустрэчы, дакументы праекта і калінкі з клёянтамі; агент складае з іх ведамасць, якая застаёцца непаралельна між адной задачай і іншай. Гэта не падобаецца да сістэмы пошуку, якая ў кожны раз, калі хтось задае запытанне, шукае кальколькі рэлевантных фрагментаў. Хутчэй агент зберагае матэрыял, які развіваецца ў меру прыходжання новых вястэй.
Першая архітэктура, якая выявілася некорэктной
Па перваму прачытанню LLM Wiki выклікае думку пра два адзеленыя шары ведамасці: вікі, створаны агентам, і файлы Obsidian, размешчаныя на яго верхній частцы. Гэта было непатрэбна, адтолькі ўжо таму, што гэта дублюець кантэнт і стварае проблемы сінхронізаціі.
Створэныя у фармаце Markdown матэрыалі самі по собі можуць быць вікі, а Obsidian – толькі вікно для ўвіду, месца для перэгляду, чытання і рэдагавання стороніц. Markdown – гэта спольнаваны контракт, а Obsidian – людській робочый стол. Як толькі змяніце вікно, інформацыя пад якім застаецца такой жа, як і раней – самэ гэта ёсць прыродай справжньяго вікі. Арганізацыя можа публікуваць затверджаныя стороніцы праз SharePoint, Confluence чыста внутршній портал, тады як інжынеры і агенты продовжуюць працаваць з підтрымуваным варыянтом крыніцы.
Практычны выклік выглядае так. Компанія абяраецца незменнымі первычнымі доказамі. Агент, які адмаўляе вікі, выкарыстоўвае схему і правіла керавання, ўбачаючы прыказы змян, а пасля перагледу затверджаныя змены потрапляюць у вікі на базе Markdown, якая падтрымвана Git. Слой служб карыстаецца механізмамі аўтэнтыфікацыі, праваў, пошуку і ведамасцю пра аўдыт. Людзі прагяжуць да інформацыі праз Obsidian або корпоратывны вікі, а агенты выкарыстоўваюць той самы слой служб за дапамогою своіх ідэнтыфікатораў і праваў.
Корпаратывная ведамасць патрабуе больш, чым толькі звязкі межаў нотак
Персональны сховішча функцыонуе часткова таму, што яго власнік памятае кантэкст файлаў: якая нотатка з заседання была спекуляatywnай, калі змянілася якая-то вакалідатывацыя, хоць не всі супаўзвязаныя старонкі былі апдэйтаваны, і якія два файлы опісваюць адну рашэнне пад разнымі назвамі. Компанія не можа рыхтавацца на тое, што адна людзінка будзе носіць усё гэта.
Яе сістэма ведамасці павінна розразняць:
- толькі прыявэнне проты рашэння, якое было затверджана
- і, што існуе сёння, проты таго, што ўжо ў історыі
- офіцыйная політыка проты карматкага заўважэння на зборах
- суперасунк, які ужо рашаны, проты таго, што ўсё яшчэ не рашаны
- празрыў у запісах проты выбору, які ніхто ўсё яшчэ не зробіў
Пашырэй гэтага існуюць адпаведныя власнікі, этапы перагляду, цытаты з аднаковых джэрэл, правілы актуальнасці, межы доступу і ход паказвае, якія змены адбылася агент. База ведамаў адзінкаго чалавека можа існаваць з неяснасцямі, таму што власнік памятае, чаго не хапае. Аднаўленая корпатыўная структура ніколі не павінна дазваляць карматкаму заўважэнню таямна ператварыцца на затверджанае рашэння.
Самэ таму схема мае значэнне. Яна робіць больш, чым проста называе папкі і файлы. Праз яе агент вывучае, як гэтая компанія кодуе своі ведамы. Метаданные на адной сторанцы 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. У рэальному жытты яны можуць буты у рызніх фарматах, але тэст допускае такій компроміс. Матэрыалі включаюць інформацыю про компаніі, політыкі і вімогі кліента, рышэння шчодо архітэктуры, протоколі зустрычэй, оцінкі мадэляў, запісі працы над впроваджэнням, справаздачы про статус і запісі рызіків.
Другій набір з восьмі дакументаў, створэніх пізнішэ, змінюе умові праекту. Посілююцца вімогі до безпекі, оцінка мадэлі спростовуе поперэдні прыпушчэння, змінююцца крытэрыі прыйнятця, а нове рышэння шчодо архітэктуры замінюе початковій дызайн; пры гэтым у неформальному протоколі зустрычы продовжуюць опісуватыся частыні старого дызайну. Ці зміні перэвіраюць, чы можа додаток еволюціонуваты, вікорыстовуючы зберэжэні знання.
Ешчы два файлы існуе толькі для адміністратара атрыбутаў. Адны з іх — гэта карта ведамасцей, якая фіксуе факты, рашэнні, суперасункі і зв’язкі, навмысна дадзеныя ў корпусе, і якая служыць аднаго з істочнаў правды. Іншы — гэта набор запітанняў для ацэнкі з прыпускаемымі адказамі і неабходнымі доказамі з істочнікаў, якія вікорыстоўваюцца для выявлення таго, чы правільна былі апдэйтаваны ведамасці. Агент, які адпавядае за адтульненне вікі, ніколі не павінен бачыць іх пад час стварэння, таму тэст пераканаецца, чы ён справды воссоздаў тое, што знала вымышленая кампанія, а не проста напісаў пераконліва выглядаючую вікі.
Эксперымент, які можа зазнаць нявяска
Запланаванный протакол складаецца з двух стадзіяў.
У стадыі А агент отрымае пачатковы корпус дадзейнаў і стварае першую вікі на Markdown. Ён павінен паведаміць, што саме стварае компанія, якія обмежэння паўстанавляюць сістэму, прычыны первачной архітэктуры, якія рызыкі застаюцца нерашанымі, якія рашэнні ўсё шчэ не прыйняты і якія джэрэлы падтрымваюць кожную адпаведзь. Вікі і яе адпаведзі зберагаюцца пры першай можлівасці, перш чым з’яўляюцца новыя доказы.
У стадыі B выпускаецца зменены корпус дадзейнаў. Цяпер агент павінен перазрэшыць кожную старонку, якая падверглася зменам, захаваць старыя рашэнні як частку історыі, зробіць відкрытыя розбіжнасці віднымі і не паддацца спокусе счытаць найняўэлівейшы дакумент канечным. Разлік у Git таксама стае доказам: ён паказвае, чыя існуючая інформацыя застала цэлісной, чы не была проста заменена ўсё тым жа падсумкам.
Гэта быў цэлы пратакол. Першая рэальная рэалізацыя пайшла іншым шляхам, адтуды ўжо таму, што яна была створана як частка іншага эксперымента, у яком агент AI развіваў програмны праект пад час дзяўнага паездкі.
Першая версія
Першая версія Cedar з’явілася ў рэзультаце таго эксперымента з паездкамі, дэталі якога не маюць значэння. Важлівае — гэта, што даў агент. Яго вхідныя даны складаліся з частак корпусу Cedar, інструкцый для праекта і набора для ацэнкі, які залішаліся поза яго ведамасцю. Праект ChatGPT, які выкарыстоўвалі, обмежыў колькасць завантажэных файлоў 25, таму толькі восем з 25 пачатковых дасяглі агента, а корпус з змянамі заставілі для пазнейшага выдачы як тэст на тое, чы можа ён уключыць змяны ў дакументы.
Вярнулася местная програма для рабочай лініі, напісаная на Python. Яна чытаўа істочнікі у фармаце Markdown і ўсю супутную інфармацыю, выдэляла доказы, пазначаныя точнымі радкамі, з якіх яны булі взяты, і аналізавала, насколькі автантыфікованым ёсць істочнік, незалежна ад часу яго публікацыі. Дакументы з прызначанымі версіямі пазначаліся як актуальныя або історычныя. Адзінак таксама мог ўтварыць справаздача у фармаце Markdown, запрашаць доказы, relevantныя да пытання, і пераглянуць вікі на наявнасць структурных праблем. Орыгінальныя дакументы знаходзіліся окрэмна ад створанай папкі wiki/, а рэпазітарый зберагаў інструкцыі для адпаведальных за адтульненне, запісі запускаў, матэрыялы для ацэнкі і рэзультаты ў сваіх окрэмых месцах. Усе 26 тэстоў працавалі праверна. Гэта была функцыональная першая версія, хоча зменшаны корпус дакументаў значыў, што можна было перапрацаваць толькі частку протаколу Cedar.
Чы могаў ён зберагчы тое, што знала компанія?
Па рэзультатах адмовленай оцэнкі сістэма пасягла 50%. Яна добра справлялася з зберагчыцтвам падтверджэнняў: канкрэтныя апыланні і інфармацыя пра месца выкарыстоўвання паказвалі адносна таго, дзе выйшлі факты. Складнасць складвалася у тым, каб знайсці і прачытаць правільныя падтверджэнні, калі з’яўлялася рэальная запытка.
Рэальныя пытанні компаніі можу выклікваць неабяжнае адзінаванне фактов з калькольных файлаў, пры чым прадалаеся перавага затверджанай рашэнцы над простым запісам; трэба бачыць, што новейшы дакумент можа мець меншую автантыя, розлічваць адкрытыя пытанні ад прасоў у запісах, а таксама падтрымліваць неяснасць, калі ўсё яшчэ не было адлучана. Зберагчыкванне доказаў выявілася эфектывнейшай за ўжоўвыбіранне доказаў. Структурны аўдыт выявіў тэхнічныя недагоднасці, такія як відсутнасць метаданых чы супярэчлівая структура, але семантычныя суперасобленні праходзілі непазірна, адтолькі што два дакументы моглі мець несумесныя позыцыі ў некалякаваных формулюваннях, і сістэма не завжды фіксавала гэтыя суперасобленні.
Корачэй кажучы, цітаты былі залучаны без жаднага розумення таго, калія з іх мае значэнне. Для корпоратыўных знанняў гэта ёсць сэрьёзныя слабасці, адколі адпаведны адказ, нават які будзе добра цітаваны, можа застацца некорэктным, калі ён апоўнюецца інформацыяй з аднаго малаважным джэрэла, ігнаруе пазнейшыя затверджаныя рашэнні або спаўнае разныя факты, якія не паслужаюць адносамі.
Непূরны корпус таксама обмежвае можлівасці выводаў. Агент ніколі не атрымаў паўнага корпуса з змянамі, таму гэты тэст не пераканаў у найскладнейшай частцы первіснага дызайну: апдэйтаванні чынных знанняў пасля змян у аўтарытэтных джэрэлах, пры чым стары стан застаецца часткай історыі. Частковы адказ такі: агент можа стварыць структураваную, прыўязаную да джэрэлаў версію корпоратыўных знанняў, але яшчэ няма достатніх доказаў таго, што ён можа надзеязліва яе падтрымліваць праз змяны ў компаніі.
У вікі трэба інтэрфейс для компаніі
Эксперымент таксама выявіў важны момент па часткі архітэктуры. Обсідыян ўжытыцьны для перагляду створанага Markdown, адкрыція спынакоў, перагляду метаданых і ручнай практыкі стороніц. Гэтага дастаткова для персональнай наладкі або пратэтапу, але жадная кампанія не можа даць кожнаму працавальніку і агенту безпосерэдній доступ да адной схованкі. Межы Markdown wiki і яго корыстувачамі рэальная сістэма патрабуе проміжнага шару, які б включаў:
- вход у сістэму, карыстаючыся прадастальнікам ідэнтыкацый кампаніі
- правіла доступу, прыязвучныя корыстувачам, командам, праектам і ролям
- разныя ідэнтыкаты з сабой правамі для кожнага агента
- этап перагляду і затверджэння кожных змян, якія пропануе агент
- рэзультаты пошуку, фільтруемыя па таму, што можа бачыць запітчык
- каментары, паведамленні і права на власнасць
- одночасныя змены і суперсечанні версый
- хроніку аўдыту, якая паказвае, хто чы ў шта зменіў кожную стороніцу
Аўтэнтыфікацыя візначае, хто выконвае запіт, а автарызацыя – што гэтае прызначэнне можа адкрыць, ў чыслах істочнаў, стораніц і операцый. Агенты таксама падпадают під гэтыя правілы. Агент фінансавага калектыва не павінен маты доступ да клінічных дакументаў толькі таму, што оба наборы дакументаў знаходзяцца ў однай вікі; таму агенты патрабуюць сваіх сабэйсных ідэнтыфікатораў, обмежаных прав і тых жа аўдытных обавязакоў, якія ёсць у людзей. Права таксама павінны адпавядаць інфармацыі, калі агент яе перэрабляе: падсумак праекта, взяты з публічнага дакумента архітэктуры, і обмежаныя перагляды безпекі могу адкрыць конфідэнцыйныя дэталі, нават якшо стораніца выглядае безнебяжнаю.
Obsidian можа застацца робочым столам для адміністратароў і тэхнічных рэвізораў, тады як большасць спавяльнікаў атрымлеюць неабходную інфармацыю праз веб-сайт у фармаце wiki або внутршній портал, які чытае тую ж інфармацыю праз кантроліруемую службу і не стварае дадзеных копій. Такія архітэктуры складаюцца з чатырох частак:
- Слой доказаў: незменныя корпаратывныя крыніцы з ўсімі первачнымі правамі доступу
- Слой знанняў: wiki у фармаце Markdown, падтрымваемы Git, і яго внутршнія зв’язкі
- Слой кантролю: ідэнтыфікацыя, права доступу, перагляд, історыя аўдыту і пошук
- Слой інтэрфейсу: Obsidian для адміністратароў wiki, корпоратывны веб-сайт для спавяльнікаў і обмежаныя API-і для агентаў
Корпаратывны інтэрфейс не стварае дублікатаў знанняў. Ён кантролюе тое, як спавяльнікі і агенты взаімаюцца з ім.
Што працаваць далей
Наступны выконанне практыкі должна включаць цэлы корпус Cedar: запісаць усе 25 пачатковых дасягненняў, оцаніць пачатковы вікі і зберагчы яго, пасля чаго дадаць вясьме змененыя дасягненняў і пераканацца, чы робат апдэйтуе кожную параболеную стороніцу, пазначае старыя рашэнні як замененыя, захоўвае історыю, якая варта зберагчыць, дазвольвае правіла аўтарытэту выканавца, праказвае нерашытыя разнакі мнэнняў, утрымваецца ад самастайных рашэнняў, і стварае дыферэнцію Git, якую можа пераглядзець чалавек.
Працэс выкарыстоўвання інформацыі таксама трэба оценяць окрэмна ад працэсу яе падтрымкі. Сістэма можа мяць правільныя знання, але выкарыстоўваць некарэктныя доказы для адпаведнага запіту, або ж даўаць правільныя адпаведзі, шукаючы ў первісных істочніках, тады калі яе падтрымваная вікі стае застарэлай; такія неудачы вымагаюць разных способаў ацэнкі. У наступным етапе ў корпус дадаць ідэнтыфікаторы карыстальнікаў і агентаў, каб запіты моглі пераканацца, што автарызаваны эксперт отрымае правільную адпаведзь, тады калі іншаму корыстніку не даецца доступу да обмежанай інформацыі. эта мера прыбліжае эксперымент да рэальнага застосоўвання ў компаніях.
Чы можа агент падтрымваць тое, што знае компанія?
Першая версія Cedar падчыржае толькі адпаведны ўтварэння. Агент створыў рабочую сістэму, якая прымала дакументы, падобныя да корпаратывных, зберагала выкладні пра адпаведныя джэрэла, пазначала версіі дакументаў, стварала вікі у фармаце Markdown і пераглядала ўсю яе структуру. Аднак ацэнка паказала, што гэтыя навыкі недастатковы, адтолькі каб падтрымваць корпаратывныя знанні, неабходна таксама правільна выбіраць доказы, разважаць пра автантыяце, выяўляць суперсечанні, карацца з неяснасцямі, а таксама здзейснюваць перагляд і кантроль даступу.
Markdown можа служыць спяльным фарматам, але компанія все рава павінна маты керованы інтэрфейс для яго. Як людзі, так і агенты павінны маты ідэнтыфікаторы, правыя на доступ павінны пераходзіць з первачальнага крыніцы на створаныя старонкі, правкі агентаў павінны працаваць пад пераглядом, а кожная заўважаная змяна павінна маты історыю. Стварэнне вікі было простай часткаю. Насправды складная частка — гэта выбір таго, што компанія прыймае як знання, хто можа яго бачыць і як агенту разрэшана яго змяніць.