Ідея «LLM Wiki» Андрія Карпаті — це спроба вирватися з пастки одноразових чатів з ШІ та перетворити великі мовні моделі на постійного «редактора знань», який пам’ятає, що вже читав, і нарощує базу знань з кожним новим документом. Канал Teacher’s Tech у детальному туторіалі показує, як реалізувати цю концепцію з нуля, використовуючи безкоштовний Obsidian як в’ювер і Claude Code як агента, що читає й записує файли.
Ключ до всієї конструкції — чітка архітектура з трьох шарів: сирі джерела, власне вікі та schema‑файл, який керує поведінкою ШІ. На перший погляд це просто набір папок і один markdown‑документ, але саме така дисципліна перетворює «чат з файлами» на керовану, відтворювану систему знань.
Три шари LLM‑вікі: від «сирих» документів до керованої бази знань
Архітектура LLM‑вікі навмисно проста й прозора. Вона складається з трьох логічних рівнів, кожен з яких має свою роль і свої обмеження.
Перший шар — це «raw sources», сирі джерела. Тут зберігаються оригінальні документи: PDF‑файли, статті, конспекти зустрічей, веб‑сторінки, збережені у форматі markdown. У демонстраційному проєкті це, наприклад, тревел‑блог про Токіо чи гастрономічний гід по Японії. Принципово важливо, що ці файли розглядаються як read‑only: ШІ може їх читати, але ніколи не змінює. Це «джерело істини», до якого завжди можна повернутися, якщо виникають суперечності чи потрібно перевірити інтерпретацію.
Другий шар — власне вікі. Це окрема папка з markdown‑файлами, які створює й підтримує вже не людина, а модель. Тут з’являються індексні сторінки, сторінки понять, сутностей, порівнянь, оглядів. У випадку з подорожжю до Японії це можуть бути окремі сторінки для районів Токіо, списки місць, що варто відвідати, узагальнення по темах на кшталт «транспорт у Токіо» чи «вулична їжа». Усі ці сторінки між собою пов’язані посиланнями, і саме ця мережа посилань поступово перетворюється на повноцінну базу знань.
Третій шар — schema‑файл. Це не черговий конспект, а «конституція» всієї системи: документ з правилами, який визначає, де лежать сирі джерела, куди писати вікі‑сторінки, як відбувається інжест документів, як форматуються сторінки та як ШІ має відповідати на запитання, спираючись на вже побудовану вікі. У туторіалі цей файл називається claude.md і лежить у корені проєкту. Саме він перетворює набір папок на керовану систему.
Разом ці три шари створюють чіткий поділ обов’язків: сирі дані залишаються недоторканими, вікі є робочим простором для ШІ, а schema‑файл — контрактом, який пояснює моделі, що саме від неї очікується. Завдяки цьому LLM‑вікі не розповзається у хаос і залишається прозорою для користувача.
«Raw» як недоторканий архів: навіщо ШІ заборонено змінювати джерела
Окрема папка raw у структурі LLM‑вікі — не просто зручність, а принципова архітектурна вимога. Усі вихідні документи потрапляють саме сюди, і з цього моменту для ШІ вони стають лише для читання.
У практичній реалізації це виглядає максимально просто: користувач створює в Obsidian новий «vault» (у прикладі — з назвою «LLM wiki»), а всередині — папку raw. Сюди можна перетягувати markdown‑файли, збережені через веб‑кліпер Obsidian, PDF‑документи, текстові файли. Claude Code вміє читати всі ці формати нативно, тому немає потреби конвертувати їх у якийсь спеціальний формат.
Коли в raw з’являється новий файл, роль ШІ полягає лише в тому, щоб прочитати його, витягти ключові ідеї, поняття, сутності, зв’язки — і вже на їх основі оновити вікі‑шар. Оригінал при цьому залишається недоторканим. Це важливо з кількох причин.
По‑перше, зберігається можливість аудиту. Якщо в узагальненні чи порівнянні з’являється сумнівний висновок, завжди можна повернутися до вихідного документа й перевірити, чи не спотворила модель зміст. По‑друге, це захищає від накопичення помилок: ШІ не «переписує історію», а лише створює надбудову у вигляді вікі‑сторінок. По‑третє, такий підхід дозволяє безболісно змінювати правила обробки: schema‑файл можна оновити, а потім переіндексувати вікі, не ризикуючи втратити чи пошкодити джерела.
У демонстрації це добре видно на прикладі тревел‑блогу про Токіо. Стаття зберігається в raw як є, а вся «магія» — розбиття на сторінки про окремі райони, формування списків місць, побудова посилань — відбувається вже у папці wiki. Якщо пізніше додати PDF‑гайд по японській кухні, він так само потрапить у raw, а модель оновить відповідні сторінки у вікі, не торкаючись оригіналів.
Вікі‑шар: як ШІ будує та підтримує мережу markdown‑сторінок
Другий ключовий елемент архітектури — папка wiki. Це простір, де ШІ має повне право створювати, змінювати, доповнювати файли. Саме тут формується та сама «LLM‑вікі» у вигляді стійкої мережі markdown‑сторінок.
Після того як у raw з’являється новий документ, користувач дає моделі інструкцію на кшталт: «Я щойно додав нове джерело в папку raw. Будь ласка, прочитай його й онови вікі». Claude Code читає файл, аналізує його зміст і, керуючись правилами з claude.md, починає будувати або оновлювати структуру у wiki.
У прикладі з подорожжю до Японії перший тревел‑блог про Токіо призводить до створення низки сторінок: загального огляду, окремих сторінок для районів міста, списків активностей. Кожна сторінка містить короткий підсумок, деталізацію, посилання на пов’язані сторінки. Якщо подивитися на це в Obsidian у режимі graph view, стає видно, як із одного документа виростає ціла мережа вузлів і зв’язків.
Коли до raw додається друге джерело — наприклад, гастрономічний гід по Японії, — модель не просто створює нові сторінки про страви чи ресторани. Вона повертається до вже існуючих сторінок у wiki й оновлює їх. Сторінки районів Токіо доповнюються інформацією про локальні заклади, з’являються нові посилання між поняттями. Таким чином, вікі не просто розширюється, а й ущільнюється: зв’язки між темами стають дедалі щільнішими.
Це і є принципова відмінність від класичного підходу, коли кожен запит до ШІ — це «чиста сторінка». У LLM‑вікі модель працює з уже організованою базою знань, яку вона сама ж і підтримує. Кожен новий документ не просто додає ще один «шматок тексту», а змінює конфігурацію всієї мережі: оновлюються індекси, уточнюються узагальнення, з’являються нові перетини між темами.
Markdown як формат тут відіграє важливу роль. Це простий, прозорий, текстовий формат, який легко редагувати як людині, так і моделі. Він добре інтегрується з Obsidian, дозволяє використовувати внутрішні посилання, заголовки, блокові цитати. У результаті вікі‑шар залишається повністю «людинозчитуваним»: користувач у будь‑який момент може відкрити будь‑яку сторінку, відредагувати її вручну, додати власні нотатки чи виправити помилки.
Schema‑файл claude.md: невидимий диригент системи
Якщо raw — це архів, а wiki — робочий простір, то schema‑файл — це інструкція, за якою ШІ має працювати з обома. У реалізації з Claude Code цей файл називається claude.md і лежить у корені Obsidian‑сховища. Коли Claude Code відкриває проєкт, він автоматично читає цей файл і на його основі визначає свою поведінку.
У готовому шаблоні CLAUDE.md, який використовується в туторіалі, є кілька ключових блоків.
Перший — «purpose», тобто призначення вікі. Це одна коротка фраза, яка описує, про що саме має бути база знань. У демонстрації вона звучить як «планування подорожі до Японії». Автор підкреслює, що для старту це фактично єдина строка, яку користувачеві потрібно змінити під себе: можна вказати дослідження відновлюваної енергетики, систематизацію прочитаних книжок чи будь‑яку іншу тему. Усе інше в шаблоні може залишатися без змін.
Другий блок описує структуру папок. Тут явно вказується, де шукати сирі джерела (raw), куди записувати вікі‑сторінки (wiki), які ще папки можуть бути задіяні. Це дозволяє моделі не «вгадувати», а чітко знати, куди класти результати обробки й де шукати вхідні дані.
Третій блок задає «ingest workflow» — послідовність дій при додаванні нового документа. У шаблоні це виглядає як чіткий сценарій: прочитати документ, виділити ключові поняття, створити або оновити відповідні сторінки у вікі, оновити індекс, зафіксувати, що саме змінилося. Завдяки цьому кожне «з’їдання» нового джерела відбувається за повторюваним, передбачуваним алгоритмом.
Четвертий блок стосується правил форматування сторінок. Тут визначається, що кожна сторінка має починатися з короткого резюме, що твердження мають посилатися на джерела, що сторінки повинні містити посилання на пов’язані поняття. Це не просто естетика: такі правила підвищують якість навігації, полегшують аудит і роблять вікі кориснішою як для людини, так і для самої моделі.
П’ятий блок описує поведінку при відповіді на запитання. Модель має спочатку звертатися до вікі, а не до сирих документів, посилатися на джерела, чітко позначати невизначеність, якщо інформації бракує. Це знову ж таки зміщує акцент з «одноразового пошуку по файлах» на роботу з уже структурованою базою знань.
Важливий момент: schema‑файл не є чимось раз і назавжди зафіксованим. Автор туторіалу прямо говорить, що це живий документ, який можна й потрібно уточнювати в міру зростання вікі. Але завдяки стартовому шаблону поріг входу мінімальний: достатньо змінити одну строку з описом призначення, і система вже готова до роботи.
Obsidian і Claude Code: як інструменти перетворюють концепцію на робочу систему
Щоб LLM‑вікі не залишилася абстрактною ідеєю, потрібні конкретні інструменти. У демонстрації використовується зв’язка Obsidian + Claude Code, яка добре ілюструє, як тришарова архітектура втілюється на практиці.
Obsidian у цій схемі виконує роль в’ювера й органайзера файлів. Це безкоштовний застосунок для нотаток, який працює з plain‑text markdown‑файлами й пропонує потужний graph view — візуалізацію зв’язків між нотатками. У контексті LLM‑вікі це особливо корисно: коли модель створює й оновлює сторінки у папці wiki, користувач може буквально побачити, як зростає й ускладнюється мережа знань.
Структура Obsidian‑сховища в туторіалі мінімалістична, але продумана. У корені — файл claude.md із правилами. Поруч — папки raw і wiki. Додатково створюється опційна папка templates, де можна зберігати шаблони нотаток для ручного створення записів. У цьому конкретному сценарії вона не є обов’язковою, оскільки більшість сторінок генерує Claude, але її наявність підкреслює, що система не забороняє людині втручатися й доповнювати вікі вручну.
Claude Code виступає в ролі «агента‑програміста», який працює з цим файловим деревом. Коли він відкриває проєкт, автоматично читає claude.md і на його основі визначає, де шукати сирі джерела, куди писати вікі‑сторінки, як поводитися при інжесті нових документів і при відповіді на запитання. Користувачеві достатньо вказати правильну директорію й дати зрозумілу інструкцію («я додав нове джерело в raw, прочитай і онови вікі»), далі модель діє самостійно.
У демонстрації добре видно, як ця зв’язка працює в динаміці. Після додавання першого markdown‑файла з тревел‑блогом до raw Claude Code, керуючись schema‑файлом, створює низку сторінок у wiki. Користувач відкриває Obsidian, бачить нові файли, переходить у graph view і спостерігає, як з’являються перші вузли й зв’язки. Після додавання другого джерела й повторної команди на інжест модель не тільки створює нові сторінки, а й оновлює вже існуючі, збагачуючи їх новою інформацією.
Важливо, що Obsidian тут не є єдино можливим інструментом. Автор прямо зазначає, що з технічної точки зору це просто папка з markdown‑файлами, яку можна відкрити у VS Code чи будь‑якому іншому текстовому редакторі. Однак саме Obsidian із його graph view робить процес наочним і зрозумілим, особливо для користувачів без глибокого технічного бекграунду.
Висновок: проста структура як основа «пам’ятливого» ШІ
Архітектура LLM‑вікі, запропонована Андрієм Карпаті й реалізована в туторіалі Teacher’s Tech, вражає не стільки складністю, скільки дисципліною. Усе тримається на трьох простих ідеях: сирі джерела мають бути недоторканими, вікі‑шар — окремим простором, де ШІ може вільно працювати, а schema‑файл — єдиним джерелом правил, яке модель читає щоразу при старті.
У поєднанні з такими інструментами, як Obsidian і Claude Code, ця структура перетворює роботу з документами на процес поступового нарощування й уточнення бази знань. Кожен новий файл у raw не губиться в безодні одноразових чатів, а стає приводом для оновлення мережі сторінок у wiki. А один‑єдиний claude.md у корені проєкту гарантує, що вся ця діяльність відбувається за зрозумілими, прозорими правилами.
Для користувача це означає, що побудувати власну LLM‑вікі — не складніше, ніж створити кілька папок і відредагувати один markdown‑файл. Але за цією простотою стоїть важливий зсув: від «ШІ як одноразового відповідача» до «ШІ як постійного редактора вашої особистої вікі».