LLM Wiki: як ШІ-агент веде вашу базу знань — і чим це відрізняється від RAG

Коротко (TL;DR)

LLM Wiki — це патерн роботи з персональною вікі на базі ШІ (особистою базою знань), який Андрій Карпаті описав у короткій замітці-гісті 4 квітня 2026 року. Ідея проста: замість того щоб щоразу видобувати потрібні шматки з вороху файлів (як це робить RAG), ви доручаєте ШІ-агенту вести за вас постійну зв’язану вікі з markdown-файлів. Агент читає нові джерела, витягує головне, оновлює сторінки, розставляє перехресні посилання і стежить за протиріччями. Знання не збирається заново на кожне питання — воно один раз «скомпільоване» і далі підтримується в актуальному стані.

Ключова фраза Карпаті про механіку паттерну (у форматі, який передали в українському розборі на DOU): «LLM-агент — програміст, база знань — вихідний код, Obsidian — IDE». Ви відповідаєте за джерела і правильні питання, вся рутина (саммарі, лінкування, бухгалтерія посилань) — на моделі.

Замітка миттєво стала вірусною: твіт-анонс Карпаті зібрав, за різними оцінками, від 16 до 21+ млн переглядів (dev.to, remio.ai; точну метрику X не розкриває), а сам він підтвердив вірусність окремим твітом 5 квітня 2026 року. Ажіотаж — не через код: коду немає, це навмисний «файл-ідея», який ви копіюєте своєму агенту і добудовуєте під себе. Зачепило інше: особиста research-вікі самого Карпаті на той момент виросла приблизно до 100 статей і 400 тис. слів — більше за середню PhD-дисертацію, — які він не писав руками (за незалежними розборами).

Підсумок одразу: LLM Wiki — не «вбивця RAG», а перевірена альтернатива RAG на LLM для іншого діапазону завдань. Він хороший там, де ви місяцями накопичуєте знання по темі і вам важливіші накопичення й прозорість, ніж швидкість пошуку по мільйонах документів. Поки вікі вкладається приблизно в ~100–200 джерел — це працює без жодної векторної бази. Далі починаються реальні обмеження, і про них нижче ми поговоримо так само детально, як про плюси. Що потрібно для старту: будь-який агент з доступом до файлів (Карпаті називає Claude Code, OpenAI Codex, OpenCode), папка з markdown і git.

Що таке LLM Wiki і чим він відрізняється від RAG

RAG (retrieval-augmented generation) — це звичний сценарій: ви завантажуєте набір файлів, а модель на кожне питання знаходить релевантні фрагменти (чанки) і генерує за ними відповідь. Так працюють NotebookLM, завантаження файлів у ChatGPT і більшість корпоративних «чатів із документами». Проблема в тому, що модель щоразу відкриває Америку заново — як влучно сформулювали в українському розборі на DOU. Нічого не накопичується: поставте тонке питання, що вимагає звести п’ять документів, — і модель щоразу заново шукає й склеює фрагменти.

Meta Muse Spark 1.1: дешевий агент, який не претендує на корону кодингу

Cursor після SpaceX: що вміє ШІ-редактор і на чиїх моделях працює

GPT-5.6 (Sol, Terra, Luna): що вміє нова модель OpenAI і чи варто переходити з Claude

NVIDIA показала, як влаштований CPU Vera — процесор для агентного ШІ

ШІ нібито зламав мережу сам — але людина в ланцюжку таки була

LLM Wiki перевертає момент синтезу. Синтез відбувається один раз — коли ви додаєте джерело, а не на кожному запиті. Агент не просто індексує новий файл «на потім»: він читає його, витягує суть і вбудовує в уже наявну вікі — оновлює сторінки-сутності, править саммарі теми, позначає, де нові дані суперечать старим. Результат Карпаті називає «артефактом, що постійно накопичується» (persistent, compounding artifact): перехресні посилання вже розставлені, протиріччя вже позначені, синтез вже відображає все, що ви прочитали. З кожним новим джерелом і кожним заданим питанням вікі стає багатшою.

Гарна аналогія з практичних розборів (dev.to) — компілятор: raw/ (сировина) — це вихідний код, LLM — компілятор, wiki/ — зібраний виконуваний файл, lint — тести, а запити — рантайм. Для програмістської аудиторії це точніше, ніж «другий мозок».

Ось порівняння за осями — включно зі слабкими місцями кожного підходу:

Зверніть увагу на останній рядок — він задає всю подальшу логіку статті. У кожного підходу своє слабке місце, і вибір йде не «що краще взагалі», а «що краще під ваше завдання і масштаб».

Архітектура: raw → wiki → schema

В основі патерну — три шари. Розібравшись у них, ви зрозумієте 80% ідеї.

1. Raw sources (сировина). Ваша курована колекція джерел: статті, PDF-файли, нотатки, зображення, вигрузки. Ці файли незмінювані — агент з них лише читає і ніколи не редагує. Це ваше джерело істини.

2. Wiki (сама вікі). Каталог markdown-файлів, які пише і веде виключно LLM: саммарі, сторінки-сутності (люди, компанії, продукти), сторінки-концепти (ідеї, теми), порівняння, огляд. Модель створює сторінки, оновлює їх при нових джерелах, тримає перехресні посилання і стежить за консистентністю. Ви це читаєте — пише модель.

3. Schema (схема). Документ-конфіг (CLAUDE.md для Claude Code, AGENTS.md для Codex), який пояснює моделі, як влаштована вікі, які домовленості й які процедури запускати при додаванні джерела, відповіді на питання чи перевірці. Саме схема перетворює загального чат-бота на дисциплінованого редактора вікі. Ви доопрацьовуєте її разом з моделлю в міру того, як розумієте, що працює під вашу тему.

Локальна база знань ШІ-агента в markdown зазвичай виглядає так — це готовий приклад дерева каталогів, який можна скопіювати під себе:

my-wiki/
├── CLAUDE.md              # схема: правила, домовленості, воркфлоу
├── raw/                   # незмінювані джерела (агент лише читає)
│   ├── 2026-04-04-attention-paper.md
│   └── assets/            # локальні зображення до джерел
├── wiki/                  # усе, що пише агент
│   ├── index.md           # каталог сторінок з однорядковими саммарі
│   ├── log.md             # хронологія: ingest / query / lint
│   ├── entities/          # сторінки-сутності
│   ├── concepts/          # сторінки-концепти
│   └── comparisons/       # порівняння і синтези
└── .git/                  # версії, відкат, diff

А ось скорочений, але робочий приклад схеми CLAUDE.md — серце всієї конструкції. Саме від її точності залежить, чи буде модель акуратним архіваріусом, чи почне діяти на власний розсуд:

# Схема вікі

Ти — дисциплінований редактор цієї бази знань, а не чат-бот.

## Шари
- `raw/` — джерела. Тільки читаєш, НІКОЛИ не редагуєш.
- `wiki/` — твоя зона. Створюєш і оновлюєш сторінки тут.
- `wiki/index.md` — каталог. Онови при кожному ingest.
- `wiki/log.md` — журнал. Дописуй рядок `## [ГГГГ-ММ-ДД] ingest | Назва`.

## Ingest (коли я кажу «проковтни <файл>»)
1. Прочитай джерело з `raw/`.
2. Назви 3–5 ключових висновків, запитай, що виділити.
3. Створи або онови сторінки-сутності й -концепти, яких він стосується.
4. Розстав двосторонні [[wiki-посилання]] між пов'язаними сторінками.
5. Нові дані суперечать старим — не видаляй, познач «конфлікт: …».
6. Онови `index.md` і допиши рядок у `log.md`.

## Query (коли я задаю питання)
- Спочатку прочитай `index.md`, знайди релевантні сторінки, потім відповідай —
  з посиланнями на сторінки, з яких узяв факти.
- Цінну відповідь запропонуй зберегти окремою сторінкою в `wiki/`.

## Lint (коли я кажу «перевір вікі»)
- Шукай: протиріччя, застарілі тези, сторінки-сироти без вхідних
  посилань, важливі концепти без своєї сторінки, відсутні крос-посилання.
- Видай список правок, але не застосовуй без мого «ок».

## Формат сторінки
- YAML-фронтматтер: `tags`, `updated`, `confidence: high|med|low`, `sources`.
- Пиши стисло: один факт — один рядок. Немає даних — «н/д», не вигадуй.

Нічого специфічного для однієї моделі тут немає — той самий файл під іменем AGENTS.md зрозуміє Codex, під CLAUDE.md — Claude Code. Це і є «переносимість» патерну: правила лежать текстом поряд із даними.

Три операції: ingest, query, lint

Увесь патерн LLM Wiki тримається на трьох операціях — ingest, query, lint. Це не команди CLI, а сценарії розмови з агентом, які ви описуєте в схемі один раз.

Ingest — «проковтнути» джерело. Ви кладете новий файл у raw/ і кажете агенту його обробити. Типовий потік: агент читає джерело, проговорює з вами ключові висновки, пише сторінку-саммарі, оновлює index.md, править пов’язані сторінки-сутності й -концепти по всій вікі і дописує запис у log.md. За оцінкою самого Карпаті, одне джерело зачіпає 10–15 сторінок вікі — саме цю рутину людині лінько робити, а модель робить за один прохід. Приклад запиту:

«Проковтни raw/2026-04-04-attention-paper.md. Заведи сторінку концепту attention, зв’яжи з transformers і напиши, де це змінює мої попередні нотатки про RNN».

Query — запитати у вікі. Ви ставите питання, агент спочатку читає index.md, знаходить потрібні сторінки, читає їх і синтезує відповідь із посиланнями на сторінки-джерела. Форма відповіді залежить від питання — markdown-сторінка, порівняльна таблиця, слайди (через Marp), графік (matplotlib), канвас. Важлива деталь, яку легко упустити: вдалу відповідь можна зафайлити назад у вікі новою сторінкою. Порівняння, яке ви попросили, знайдений зв’язок, розбір — усе це цінне і не повинно розчинятися в історії чату. Так ваші роздуми теж накопичуються, а не лише завантажені джерела:

«Що мої джерела кажуть про вартість навчання трансформерів? Збери таблицю і збережи як wiki/comparisons/training-costs.md».

Lint — перевірити здоров’я вікі. Періодично ви просите агента прогнати «техогляд»: шукати протиріччя між сторінками, застарілі тези, перебиті новими джерелами, сторінки-сироти без вхідних посилань, важливі концепти без своєї сторінки, відсутні крос-посилання і прогалини в даних, які варто закрити веб-пошуком. Модель добре пропонує нові питання для вивчення і нові джерела — це і тримає вікі здоровою в міру зростання.

Навігацію забезпечують два службові файли. index.md — контент-каталог: кожна сторінка з посиланням, однорядковим саммарі й метаданими, розбитий за категоріями; агент читає його першим за будь-якого запиту. За словами Карпаті, такий підхід «на диво добре працює на помірному масштабі (~100 джерел, ~сотні сторінок)» і знімає потребу в embedding-based RAG-інфраструктурі. log.md — хронологічний журнал операцій (append-only). Якщо кожен запис починається з єдиного префіксу штибу ## [2026-04-02] ingest | Назва, журнал парситься звичайним grep: grep "^## \[" log.md | tail -5 покаже п’ять останніх дій.

Як побудувати вікі на Claude Code та Obsidian: покроково за вечір

Окремий плюс патерну — його можна підняти за один вечір, без сервера і векторної БД. Нижче — відтворюваний мінімум на Claude Code та Obsidian (той самий порядок працює з Codex і будь-яким CLI-агентом із доступом до файлів).

1. Створіть репозиторій. Порожня папка → git init. Вікі — це просто git-репозиторій markdown-файлів, тому історія версій, гілки й відкат дістаються вам безкоштовно.
2. Розкладіть каркас. Створіть raw/, wiki/, wiki/entities/, wiki/concepts/, порожні wiki/index.md і wiki/log.md (дерево вище).
3. Напишіть схему. Покладіть у корінь CLAUDE.md — можна взяти шаблон із цієї статті і підправити під свою тему. Це найважливіший файл: він робить агента дисциплінованим.
4. Підключіть Obsidian як «IDE». Відкрийте папку вікі як vault. Тепер у вас є граф зв’язків, попередній перегляд сторінок і переходи за [[посиланнями]] — ви читаєте, агент пише, ви бачите правки в реальному часі.
5. Наповнюйте raw/ швидко. Встановіть розширення Obsidian Web Clipper — воно конвертує веб-статті в markdown прямо в raw/. Для картинок у налаштуваннях Obsidian задайте фіксовану папку вкладень (наприклад, raw/assets/) і повісьте на хоткей «Download attachments for current file», щоб зображення завантажувалися локально. Нюанс: моделі не читають markdown із вбудованими картинками за один прохід — спочатку агент читає текст, потім за потреби дивиться потрібні зображення окремо.
6. Перший ingest. Скажіть Claude Code: «Проковтни ось цей файл за схемою з CLAUDE.md». Прочитайте, що він запропонував, поправте акценти — на перших джерелах ви фактично донавчаєте схему.
7. Перший query і lint. Поставте питання по темі і попросіть зберегти відповідь сторінкою. Через кілька джерел прогоніть lint, щоб побачити перші сироти й протиріччя.

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

Інструменти екосистеми: qmd, Dataview, Marp, готовий плагін

Поки вікі невелика, вистачає index.md. Коли вона виросте, знадобляться додаткові інструменти — усі опціональні й модульні.

• qmd — локальний пошуковик по markdown, який Карпаті називає прямо в гісті. Автор — Tobi Lütke, CEO Shopify; ліцензія MIT, близько 28 тис. зірок на GitHub (на 9 липня 2026). Він поєднує повнотекстовий пошук BM25 (класичне ранжування за збігом слів), векторний семантичний пошук і LLM-переранжування — усе на пристрої (через node-llama-cpp і GGUF-моделі). У qmd є і CLI (агент може смикнути його з шелу), і MCP-сервер (агент використовує його як нативний інструмент). Потрібен він, коли вікі переростає ~100 джерел і index-файлу стає мало.
• Dataview — плагін Obsidian, що виконує запити за YAML-фронтматтером сторінок. Якщо агент проставляє метадані (tags, updated, confidence), Dataview будує динамічні таблиці. Наприклад, запит TABLE confidence FROM "concepts" WHERE confidence = "low" виведе всі ваші найменш упевнені сторінки — чудовий спосіб побачити, де знання слабке і що варто перевірити.
• Marp — markdown-формат для слайдів (в Obsidian є плагін). Дає презентацію прямо із вмісту вікі без окремого редактора.
• Готовий плагін — якщо не хочеться збирати все руками, є green-dalii/obsidian-llm-wiki («Karpathy LLM Wiki»): 254 зірки, Apache-2.0, офіційний рейтинг Obsidian 95/100, останній реліз 5 липня 2026. Цікава деталь — замість ембедингів він ранжує сторінки через Personalized PageRank за wiki-посиланнями (той самий принцип, що в Google: важливіші сторінки, на які посилаються частіше), тобто залишається в дусі «зв’язки важливіші за вектори».

Окремо варто сказати про MCP: qmd як MCP-сервер — гарний приклад того, як патерн стикується з агентною екосистемою. Якщо вам цікава механіка автономних асистентів поруч, подивіться розбір особистого ШІ-агента OpenClaw — там та сама логіка «агент + інструменти + реальна собівартість».

Живий приклад: українська реалізація патерну

Абстрактну ідею простіше зрозуміти на конкретній реалізації. Український розробник Андрій Богданович описав на DOU робочу версію LLM Wiki українською мовою і виклав репозиторій (BogdanovychA/llm-wiki, створений 1 липня 2026) — патерн задокументований і в статті, і в самому коді, тож структуру можна звірити з репозиторієм безпосередньо.

Каталог у нього трохи багатший за базовий і добре показує, куди патерн еволюціонує на практиці:

AGENTS.md               # схема (роль Codex/CLI-агента)
.agents/skills/         # навички ingest / query / linter — ізолюють
                        # контекст агента під конкретне завдання
inbox/                  # черга нових сирих матеріалів (+ inbox/assets/)
raw/YYYY-MM-DD/         # незмінюваний архів з YAML-метаданими
wiki/
├── concepts/
├── entities/
├── archives/
├── index.md
└── log.md

Дві деталі тут особливо корисні. Перша: імена файлів — латиницею в стилі kebab-case, хоча вміст вікі українськомовний. Це усвідомлений компроміс заради сумісності з git та Obsidian і заради того, щоб семантичний пошук ішов за змістом, а не спотикався об морфологію мови. Друга, і головна: git як механізм довіри. Уся база — git-репозиторій, тому після кожного ingest можна зробити git diff і побачити рівно ті факти й зв’язки, що додала модель, до коміту. Якщо модель десь нагалюцинувала або зіпсувала розмітку — ви просто відкочуєте зміни. Це той самий human-in-the-loop, якого бракує «магічним» чорним скринькам. Той самий прийом незалежно спливав і в англомовних реалізаціях: у проєкті WUPHF агент комітить під окремою git-ідентичністю, щоб походження кожної правки було видно в git log.

Скільки це коштує: економіка токенів

Євангелісти патерну рідко рахують гроші, тому тут наш information gain — чесна собівартість. Прямі витрати на інфраструктуру майже нульові, уся змінна вартість сидить у токенах на ingest.

Єдиний знайдений відтворюваний замір дає порядок величини. Користувач HN під ніком vbarsoum прогнав патерн на трьох бізнес-книгах (~155 тис. слів, 68 файлів, гранулярність по розділах) у квітні 2026 року: вийшло 210 сторінок-концептів із 4 597 перехресними посиланнями (у середньому 19,2 посилання на сторінку), витрати — ~12 млн токенів і 10–15 хвилин. Показовіше за самі цифри те, що зв’язка знайшла неочевидне протиріччя між двома книгами, яке жодна з них не формулює явно, — саме той синтез, заради якого патерн і затівається. За цінами середини 2026 року (порядку кількох доларів за 1 млн токенів у моделей середнього класу) такий разовий прогін — це одиниці-десятки доларів; цифра сильно залежить від обраної моделі, тому вважайте її орієнтиром, а не кошторисом.

Практичний висновок із цих чисел важливіший за самі долари: дорога операція — саме ingest, і вона повторюється в міру зростання вікі. Що більша база і що частіше lint переписує сторінки, то вищий рахунок. У RAG цього синтезу при завантаженні немає — і це одна з причин, чому LLM Wiki вигідний не завжди (детальніше — у розділі про межі).

Ризики та межі: де патерн ламається

Це не реклама, тому слабкі місця розбираємо так само детально, як можливості. Усі ризики нижче — з атрибуцією до конкретних обговорень квітня-липня 2026 року.

• Деградація знань (аналог model collapse). Коментатор HN devnullbrain попередив: багаторазове переписування валідної інформації моделлю може її вихолощувати — замінювати точні формулювання більш загальними й розмитими. Контраргумент (gojomo, той самий тред): у 2026-му навчання на власних виходах уже дає виграші, тож страхи 2024 року не показові. Правда десь посередині — ризик реальний, але керований, якщо lint не переписує все підряд.
• Контекстна стеля. Попри вікна 1M+ токенів, практична деградація («модель забуває, плутає зв’язки») починається вже на 200–300 тис. токенів — тобто велика вікі впирається рівно в ту стелю, яку мала обійти (lelanthran, HN). Рятує дисципліна: не завантажувати всю вікі, а читати index.md і лише релевантні сторінки.
• Масштабування lint. Пошук протиріч між N сторінками формально вимагає N×N порівнянь (Covenant0028, HN) — на тисячах сторінок це дорого. Обхід — лінтити вибірку або підмножину, а не всю базу цілком.
• Економіка на масштабі. Як показано вище, ingest дорожчає разом із вікі; для великої бази (за оцінкою MindStudio, вікі понад ~30 тис. токенів) добре налаштований RAG може вийти дешевшим.
• Приватність. При хмарному ingest ви згодовуєте всі джерела зовнішній моделі — для чутливих даних це стоп-фактор. Мітигація — ганяти ingest через локальну LLM на своєму залізі; якість синтезу буде нижчою за хмарні флагмани, але дані не покидають машину.
• Філософська ціна делегування. Найнесподіваніший аргумент прозвучав незалежно на HN (qaadika: «чорнова робота і Є навчання») і в есеї на Habr із посиланням на поняття hypomnemata у Фуко: теза «письмо = мислення» руйнується, якщо вікі пише модель замість вас. Впізнавання зв’язків між нотатками — це і є акт мислення, а не побічний продукт, який можна віддати агенту. Якщо ваша мета — розібратися самому, а не отримати готовий довідник, автогенерація може позбавити вас головного.

Окремо — про гучну цифру. Маркетингове «економія до 95% токенів» (MindStudio, на 9 липня 2026) правильне лише проти наївного завантаження цілих документів, а не проти оптимізованого RAG; для великих вікі різниця може обнулитися або піти в мінус. Джерело — вендор, що продає агентну платформу, тож цифру беремо з цим застереженням.

Зведено — де патерн ламається і чим це лікується:

Кому підходить, а кому ні

Звести все воєдино допомагає простий критерій: що вам важливіше — накопичення і прозорість чи швидкість пошуку по великому обсягу.

Підходить, якщо ви місяцями накопичуєте знання по темі (research deep-dive, конспекти книг, командна вікі, конкурентний аналіз, due diligence), база вкладається в ~100–200 джерел, і вам цінні прозорість через git diff і відсутність інфраструктури. Командний варіант — вікі, яку агент наповнює зі Slack-тредів, дзвінків і документів, — це та сама ідея персистентної пам’яті команди, що й у Claude як постійного ШІ-колеги в Slack, тільки винесена в git-репозиторій. Ранні користувачі це підтверджують: на r/ObsidianMD людина після двох тижнів на зв’язці Obsidian + Claude Code відзначила, що фокус змістився зі структурування нотаток на збір інформації — структуру й лінкування взяв ШІ.

Не підходить, якщо у вас тисячі документів і потрібен швидкий семантичний пошук на масштабі (тоді RAG або гібрид), якщо ви вчитеся саме через письмо (філософський аргумент вище), або якщо ви вже дисципліновано ведете нотатки самі — тоді, як влучно зауважили на HN (panarky) і на DOU, ніхто поки не показав доведеної переваги над звичайним markdown + простий індекс + ripgrep. Ретрив можна робити grep-ом без жодних ембедингів, а основна вартість (токени на синтез) у старому підході просто не потрібна.

Ось як патерн виглядає поряд з альтернативами:

За тиждень після публікації гіста на Hacker News з’явилося одразу кілька паралельних реалізацій-«компіляторів» (WUPHF, AtomicMemory та інші) — екосистема росте швидше, ніж закріплюється термінологія. Це добрий знак інтересу, але і привід не прив’язуватися до конкретного інструменту: сам патерн важливіший за будь-яку зі своїх реалізацій.

FAQ

LLM Wiki — це заміна RAG? Ні. Це патерн для іншого класу завдань. RAG виграє на швидкому пошуку по тисячах документів, LLM Wiki — на накопиченні й прозорості за помірного масштабу. На великих базах їх часто комбінують: вікі для синтезу, вектор для ретриву.

Скільки джерел витримає вікі без окремого пошуку? За оцінкою самого Карпаті — приблизно 100 джерел і сотні сторінок: на такому масштабі достатньо читати index.md, векторна база не потрібна. Далі підключають qmd або гібрид з RAG.

На якому агенті й моделі це запускати? На будь-якому агенті з доступом до файлів: Карпаті називає Claude Code, OpenAI Codex, OpenCode. Схема лежить текстом (CLAUDE.md або AGENTS.md), тому патерн переносний між моделями. Для приватних даних ingest можна ганяти через локальну LLM.

Чи не буде ШІ галюцинувати прямо в базі знань? Ризик є, і головна страховка — git. Уся вікі версіюється, після кожного ingest ви робите git diff, бачите додані факти й зв’язки до коміту і відкочуєте зайве. Плюс операція lint спеціально шукає протиріччя і застарілі тези.

Чим це краще за звичайний markdown + grep? Доведеної переваги в самому ретриві немає — grep дешевший і швидший. Цінність LLM Wiki не в пошуку, а в тому, що модель бере на себе синтез, крос-посилання і підтримання консистентності, які вручну ніхто вести не хоче. Якщо цю рутину ви готові вести самі — grep вам і справді достатньо.

Чи можна тримати все локально заради приватності? Так. Obsidian, qmd і git працюють на пристрої; чутливе лише хмарне читання джерел агентом. Замініть хмарну модель на локальну LLM для ingest — дані не покинуть машину, ціною слабшого синтезу.