LLM Wiki: как ИИ-агент ведёт вашу базу знаний — и чем это отличается от RAG

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

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

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

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

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

SpaceX · xStockSpaceX — частная компания. Торгуй её токеном на Bybit за крипту.Торговать SpaceX →

Что такое 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-ы, заметки, изображения, выгрузки. Эти файлы неизменяемы — агент из них только читает и никогда не правит. Это ваш источник истины.

Bybit · Rewards Hubдо $30,100Внеси депозит, торгуй 14 дней — и забери награды в Rewards HubЗабрать бонус →

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 — данные не покинут машину, ценой более слабого синтеза.