Від RAG до LLM Wiki: як побудувати персистентну базу знань за концепцією Андрея Карпати

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Мабуть, кожен, хто працює з LLM, стикався з класичним RAG (Retrieval-Augmented Generation). Ви завантажуєте пачку PDF-файлів або підключаєте папку з документами, ставите запитання, а модель шукає релевантні шматки тексту (chunks) і генерує відповідь. Це зручно, але має фундаментальний недолік: модель щоразу відкриває Америку заново. Вона не накопичує знання. Якщо ви попросите її зіставити факти з п’яти різних документів, вона знову і знову буде шукати та склеювати ці фрагменти, не створюючи жодної стійкої структури.

Нещодавно Андрей Карпати (Andrej Karpathy), відомий дослідник ШІ та співзасновник OpenAI, запропонував альтернативний підхід — LLM Wiki. Замість того, щоб щоразу збирати відповідь «на коліні», LLM-агент бере на себе роль архіваріуса та редактора. Він поступово розбирає ваші вхідні матеріали й компілює їх у єдину, структуровану, пов’язану перехресними посиланнями базу знань на основі Markdown-файлів.

У цій публікації я хотів би детально розібрати саму концепцію LLM Wiki та розглянути її конкретну практичну реалізацію з адаптацією під українську мову.

Репозиторій проєкту: github.com/BogdanovychA/llm-wiki

У чому суть концепції LLM Wiki?

Карпати запропонував просту метафору:

• LLM-агент (наприклад, Claude Code, Antigravity чи будь-який інший CLI-агент) — це програміст.
• База знань (Wiki) — це вихідний код (codebase).
• Obsidian (або інший Markdown-редактор) — це IDE, де ви візуально переглядаєте результати, переходите за посиланнями та дивитеся на інтерактивний граф зв’язків.

Замість того, щоб просто зберігати тексти у векторній базі, LLM Wiki компілює їх. Коли ви додаєте нове джерело (статтю, замітку, транскрипт подкасту):

1. Агент уважно вивчає матеріал.
2. Створює сторінки концепцій (concepts/) та сутностей (entities/) або інтегрує нові факти в уже існуючі сторінки.
3. Оновлює покажчик (індекс) бази знань.
4. Додає перехресні посилання між сторінками.
5. Фіксує суперечності, якщо нове джерело спростовує чи доповнює старі дані.

Знання накопичуються (compounding). Коли ви пишете запит, модель не перечитує гігабайти сирих даних — вона звертається до вже структурованої та оновленої бази знань.

Архітектура української реалізації

Українська версія проєкту LLM-Wiki має таку структуру:

.
├── AGENTS.md          # Системні інструкції для ШІ-агента (Schema)
├── .agents/skills/    # Скрипти та автоматизовані навички (ingest, query, linter)
├── inbox/             # Папка для нових сирих матеріалів та зображень
├── raw/               # Незмінний архів першоджерел (групується за датами YYYY-MM-DD)
└── wiki/              # Персистентна база знань (тільки українською мовою)
    ├── concepts/      # Сторінки концепцій (теорії, технології, терміни)
    ├── entities/      # Сторінки сутностей (люди, компанії, інструменти)
    ├── archives/      # Архів складних аналітичних відповідей на запити
    ├── index.md       # Контентний каталог усіх сторінок вікі
    └── log.md         # Журнал активності та виконаних операцій

Чому обрано Markdown та Git?

• Сумісність: Markdown — це універсальний формат, який відкривається будь-чим.
• Відсутність вендор-локу: Ви не прив’язані до конкретного хмарного сервісу чи пропрієтарної БД.
• Git: База знань — це звичайний Git-репозиторій. Ви безплатно отримуєте історію змін, можливість розгалужуватися (branching) та зручно синхронізувати дані між пристроями.

Головні робочі процеси (Workflows)

В українській реалізації логіка поведінки агента автоматизована через skills (навички) у папці .agents/skills/.

Виділення окремих навичок — це важливе архітектурне рішення, яке дозволяє не тримати весь контекст роботи в «голові» (контекстному вікні) агента. Коли вам потрібно лише знайти чи проаналізувати інформацію, агент використовує навичку query і працює виключно в режимі читання, не завантажуючи інструкції для імпорту. І навпаки: під час масового додавання документів активується навичка ingest, і агенту не доводиться тримати в пам’яті правила пошуку чи лінтингу. Це суттєво економить контекст моделі та підвищує точність виконання дій.

1. Імпорт джерел (Ingest Workflow)

Ви кидаєте сирий текстовий файл (наприклад, скопійовану статтю чи нотатки) в inbox/, а медіафайли — в inbox/assets/. Після цього кажете агенту: «Оброби нові матеріали».

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

Агент-виконавець робить таке:

• Переносить сирі джерела в raw/YYYY-MM-DD/ з додаванням YAML-метаданих (дата збору, оригінальне джерело).
• Аналізує вміст. Якщо там згадується нова концепція (наприклад, «Quantum Computing») чи сутність («John Doe»), він створює відповідні файли quantum-computing.md чи john-doe.md у каталозі wiki/.
• Якщо концепція вже існує, він оновлює її, інтегруючи нові факти та вказуючи посилання на нове джерело в секції sources: у YAML-метаданих.
• Оновлює wiki/index.md та дописує хід виконання у хронологічний журнал wiki/log.md.

2. Запити та накопичення відповідей (Query Workflow)

Коли ви запитуєте агента про щось складне (наприклад: «Порівняй підходи до квантового декодування за матеріалами останніх трьох статей»), він проводить пошук по вікі, формує відповідь і зберігає її у wiki/archives/ як нову сторінку. Це надзвичайно важливий момент: ваші інтелектуальні зусилля та висновки моделі не зникають в історії чату, а стають частиною бази знань.

3. Лінтинг та здоров’я системи (Lint Workflow)

З часом у будь-якій вікі з’являються биті посилання, «сторінки-сироти» (на які ніхто не посилається) або логічні суперечності. Навичка linter дозволяє агенту регулярно сканувати базу, автовиправляти технічні помилки (наприклад, оновлювати індекс або посилання) та маркувати суперечливі твердження для вашої уваги.

Особливості адаптації під українську мову

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

1. Англійська мова для назв файлів (kebab-case): Для забезпечення максимальної сумісності з Git, Obsidian та консольними утилітами назви файлів створюються латиницею в стилі kebab-case як переклад відповідного поняття (наприклад, artificial-intelligence.md або quantum-computing.md), тоді як заголовок H1 та весь вміст всередині файлу ведуться виключно українською мовою. Це дозволяє уникнути проблем із кодуванням кирилиці у шляхах файлової системи та спрощує посилання на джерела.
2. Обхід обмежень української морфології (семантичний пошук): На відміну від традиційних пошукових систем, де відмінювання українських слів (наприклад, «квантовий», «квантових», «квантовому») вимагає складних алгоритмів лематизації чи стемінгу, LLM оперує семантикою. Вона легко знаходить взаємозв’язки між поняттями незалежно від відмінка чи форми слова, а також автоматично перекладає іншомовні терміни під час імпорту, зберігаючи оригінальні англійські відповідники в дужках для точності.
3. Локалізовані шаблони: Усі заготовки (templates/) перекладені українською та підтримують єдиний формат метаданих.

Практичні приклади використання проєкту

Приклад 1: Особистий «Другий мозок» (Personal Knowledge Management)

Ви ведете щоденники, зберігаєте замітки з прочитаних книг, посилання на цікаві доповіді та рецепти.

• Як це працює: Ви просто кидаєте хаотичні нотатки в inbox/. LLM сортує їх. Наприклад, ваша замітка про тренування актуалізує концепцію cardio.md, створить сутність coaching-app.md, зв’яже їх між собою та оновить ваші особисті цілі. Ви отримуєте структуровану картину власного життя без нудної рутини ручного сортування.

Приклад 2: Професійні дослідження (Research Deep-dive)

Ви вивчаєте нову складну технологію, наприклад, WebAssembly або CRDT.

• Як це працює: Ви налаштовуєте браузерне розширення Obsidian Web Clipper, зберігаєте цікаві статті та наукові роботи напряму в inbox/. Агент розбирає їх, створює сторінки для різних алгоритмів (наприклад, y-js.md, automerge.md), виділяє переваги та недоліки кожного підходу, зіставляє бенчмарки та формує загальну концептуальну карту.

Приклад 3: Інтерактивний супутник для читання книг або перегляду лор-насичених всесвітів

Читати складні романи чи вивчати історію вигаданих світів (на кшталт «Володаря перснів» чи «Пісні льоду й полум’я») буває непросто через сотні персонажів та географічних назв.

• Як це працює: Після прочитання кожного розділу ви надиктовуєте або записуєте короткий зміст у файл в inbox/. LLM створює та оновлює профілі персонажів у entities/ (їхній статус, родинні зв’язки, мотивацію) та локації у concepts/, будуючи величезний інтерактивний граф зв’язків. Ви отримуєте власну інтерактивну енциклопедію книги.

Приклад 4: База знань ІТ-команди або стартапу

Підтримка внутрішньої документації в актуальному стані — вічний біль команд. Confluence часто перетворюється на звалище застарілої інформації.

• Як це працює: Ви можете налаштувати імпорт із робочих каналів Slack, транскриптів мітингів та описів завдань у Jira в inbox/ проєкту. LLM-агент аналізує нову інформацію та самостійно оновлює сторінки проєктів, фіксує зміну архітектурних рішень чи відповідальних осіб у сутностях. Команда завжди має актуальну базу знань без витрат часу на її ручне оновлення.

Одночасна робота з різними завданнями (Multi-project workflow)

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

• Ви можете легко клонувати цей репозиторій в окремі папки для кожної своєї задачі (наприклад, один клон під робочий проєкт, один — для вивчення мови програмування, ще один — під особисті тренування).
• Починаєте працювати з кожним проєктом локально.
• Якщо якась робота «не пішла» або втратила актуальність — ви просто видаляєте папку без жодних наслідків.
• Навпаки, якщо проєкт розвивається круто — ви ініціалізуєте Git, налаштовуєте приватний репозиторій на GitHub і починаєте фіксувати свій прогрес комітами.

Контроль якості та масштабування

Щоб зробити роботу з LLM Wiki максимально надійною та масштабованою, використовуються перевірені часом інженерні підходи:

1. Git як механізм контролю (Human-in-the-loop): Ви не зобов’язані сліпо довіряти моделі та її генераціям. Оскільки вся база знань є Git-репозиторієм, після кожної операції імпорту чи редагування ви можете зробити git diff в консолі або улюбленій IDE. Це дозволяє наочно перевірити всі додані факти, виправлені посилання чи відредаговані концепції перед тим, як зафіксувати зміни комітом. Якщо модель десь галюцинує чи псує розмітку — ви просто відкочуєте зміни.
2. Масштабування через Ripgrep та локальний пошук: Якщо ваша вікі розростеться до тисяч сторінок, передавати весь покажчик index.md у контекст моделі під час кожного запиту стане неефективно та дорого. Для таких масштабів агент може використовувати консольну утиліту ripgrep (rg) або локальну систему пошуку на базі протоколу MCP (наприклад, qmd). Це дозволяє моделі швидко й точково знаходити потрібні файли через швидкий текстовий чи векторний пошук на вашій машині, не завантажуючи зайву інформацію в контекст.

Чому цей підхід дійсно працює?

Будь-яка система ведення нотаток (від блокнотів до Notion) зазвичай помирає через так звану «рутинну плату» (bookkeeping tax). Людині швидко набридає проставляти теги, перевіряти посилання, оновлювати зміст та стежити за актуальністю застарілих сторінок.

LLM Wiki розв’язує цю проблему кардинально: людина лише споживає інформацію та постачає нові джерела, а всю бюрократичну роботу з підтримки структури виконує ШІ.

Важливо, що правила гри ви визначаєте разом із моделлю у файлі AGENTS.md (Schema). Це «живий» документ-конфігурація: помітили, що модель десь припускається системної помилки, неправильно групує чи тегує інформацію — дописуєте туди одне-два речення з новими правилами. Наступного разу агент врахує ваші коригування, поступово адаптуючись під особливості вашого мислення та домену знань.

Якщо ви хочете спробувати побудувати свій персистентний мозок під керуванням штучного інтелекту — клонуйте репозиторій, налаштовуйте свого агента та починайте експериментувати!

Проєкт на GitHub: BogdanovychA/llm-wiki