Месяц с LLM Wiki Андрея Карпатого: главная сила LLM — не в пересказе, а в умении «связывать» знания

Вступление

Читать статьи и веб-материалы через суммаризацию от LLM — это уже почти норма. Даже один только разбор общей картины плюс диалоговые вопросы заметно поднимают эффективность обучения.

Но такой способ замыкается в одной сессии. А то, что по-настоящему определяет качество исследования и обучения, — это инсайты, рождающиеся из связей между материалами, прочитанными в разное время.

Удерживать эти связи силами человека тяжело. У памяти есть предел: детали статьи, прочитанной полгода назад, забываются. Держать в голове отношения между статьями — где они противоречат друг другу, где дублируются — это высокая нагрузка.

В апреле 2026 Андрей Карпатый опубликовал в X паттерн построения персональной базы знаний (LLM Wiki) с помощью LLM. Твит вызвал большой резонанс, и позже подробности были выложены в GitHub Gist.

Я прогонял этот паттерн месяц — и сильнее всего почувствовал, что настоящая сила LLM не в суммаризации, а в умении связывать. (В Obsidian это видно в graph view: узлы — это страницы, рёбра — [[wikilink]] между ними.)

Структура статьи: сначала разбор того, что такое LLM Wiki, затем два конкретных примера инсайтов от «связывания», потом шаги по внедрению — и в конце про потолок: про то, что узким местом оказывается чтение и понимание самим человеком.

Что такое LLM Wiki Карпатого

В основе предложения лежит неудовлетворённость тем, как обычно используют связку «LLM + документы» (RAG и подобное). NotebookLM или загрузка файлов в ChatGPT держат источники в сыром виде и на каждый вопрос заново ищут релевантный текст, чтобы собрать ответ. Карпатый называет это состоянием, когда знание заново открывается с нуля на каждый вопрос («rediscovering knowledge from scratch on every question»), и видит проблему в том, что знание не накапливается.

Архитектура LLM Wiki — это простая трёхслойная структура:

Центр — слой Wiki, где лежат такие страницы:

• summary-страницы — резюме по каждому первоисточнику отдельно;

• концептуальные страницы — сводки по теме, методу или человеку поперёк нескольких источников;

• query-страницы — подшитые вопросы и ответы;

• index.md — каталог всех страниц;

• log.md — журнал операций, дописывается по времени.

Эксплуатация крутится на трёх базовых операциях:

• Ingest — на входе новый источник: создаётся summary, правки расходятся по связанным концептуальным страницам, обновляются index/log. Один источник может затронуть 10–15 страниц.

• Query — задаёте wiki вопрос; ценный ответ оформляется как query-страница и становится активом.

• Lint — периодический health-check: ищет противоречия, осиротевшие страницы, пробелы в знаниях и предлагает следующие вопросы.

Активно человек делает только две вещи: кладёт источник в raw/ и запускает ingest — и задаёт вопросы. Всю поддерживающую работу (написание, поддержание ссылок, обновления, поиск противоречий) берёт на себя LLM. Карпатый рекомендует держать открытыми рядом Obsidian и LLM-агента.

Ключевое отличие от RAG: RAG в момент вопроса собирает и сводит несколько источников, а в LLM Wiki поперечная организация происходит в момент приёма (ingest), и на вопрос отвечает уже из готовой, разобранной wiki. Сам Карпатый позиционирует wiki как постоянно накапливающийся артефакт («persistent, compounding artifact»).

Интересно, что он разбирает и почему это вообще работает — суть собрана в разделе Gist «Why this works».

Если коротко: самое скучное в ведении базы знаний — не чтение и не размышление, а bookkeeping (обновлять ссылки, поддерживать summary в актуальном состоянии, фиксировать противоречия, держать согласованность). Человек забрасывает свою wiki потому, что нагрузка по поддержке растёт быстрее, чем ценность. LLM же не устаёт, не забывает и за один проход правит множество файлов — поэтому стоимость поддержки падает практически до нуля, и wiki продолжает жить.

На этом заканчивается пересказ позиции Карпатого. От себя добавлю: за месяц эксплуатации я сильнее всего почувствовал, что настоящая ценность не в удобстве сборника резюме, а в той самой «силе связывать» — в том, что поперечно организованные концептуальные страницы собираются сами.

Почему «умение связывать» важнее пересказа

В слое Wiki по сути работают три типа контента:

• summary-страницы (wiki/papers/, wiki/articles/) — один к одному с первоисточником;

• концептуальные страницы (wiki/concepts/) — «синтетический артефакт», собранный из нескольких источников;

• результаты Query (wiki/queries/) — подшивка ответов на вопросы.

Если бы речь шла только о резюме статей и материалов, это спокойно заменили бы NotebookLM или ChatGPT. Поэтому ключ — именно в концептуальных страницах. Они проходят поперёк нескольких источников и вытаскивают общую структуру, классификации, контрпримеры.

Если делать это вручную, нагрузка bookkeeping убивает затею. Дописывать к существующим страницам при каждой новой статье, пересобирать классификации, перевешивать ссылки — по мере роста числа источников стоимость поддержки превышает ценность, и обновления забрасываются. LLM же делает это безропотно и бесконечно: при каждом ingest перечитывает связанные концептуальные страницы и заново раскладывает новые наблюдения, противоречия и вопросы.

Структура концептуальной страницы свободная — можно переписать свой ingest-скилл и вырастить шаблон в ту форму, которую хочется перечитывать. Я для себя всегда требую создавать две секции: «сквозные наблюдения» (то, что видно, только если положить несколько источников рядом) и «нерешённые вопросы» (что копать дальше). Именно то, как этот список растёт со временем, и есть само тело LLM Wiki.

Пример: инсайты, которые LLM связала за меня

На одной абстракции не прочувствуешь, поэтому покажу два инсайта, которые не возникли бы из одного источника по отдельности.

Пример 1: оси оценки в Automated Scientific Discovery и их bias

Статей про автоматизацию исследовательского процесса с помощью LLM-агентов («Automated Scientific Discovery») резко прибавилось. Я последовательно заing-естил больше десяти: AI Scientist v1/v2/Nature-версия, AI co-scientist, AI-Researcher / Scientist-Bench, ScienceAgentBench, Agent Laboratory, оценочная работа Beel et al., ResearchAgent и другие.

LLM сама создала концептуальную страницу automated-scientific-discovery.md и продолжала её обновлять. В итоге она (1) свела разрозненные оси оценки в четыре категории и (2) объединила наблюдения про bias из трёх независимых статей в один паттерн «разные грани LLM-as-Judge». Это и был первый случай, когда я прочувствовал силу связывания.

(1) Оси оценки стали многомерными. Перечитав страницу после десятка статей, я увидел, как за последние год-два оценка стала многоосевой:

Wiki не просто накапливала — при каждом ingest новой статьи она дописывала с учётом уже имеющихся наблюдений. Разделение на три оси оценки выхода (execution / человек / LLM) и четвёртую ось проверки в поле — это результат накопленных дописываний.

(2) Отдельные наблюдения свелись в один паттерн. На той же концептуальной странице была разобрана связь другого типа. Подчеркну: следующие три числа — не мои замеры, а цитаты из трёх разных работ, которые я заing-естил по отдельности:

• автоматический LLM-ревьюер оказался мягче человеческого рецензента в среднем на 2.3 балла (Agent Laboratory);

• из статей, написанных людьми, LLM-ревьюер отверг 9 из 10 (Beel et al.);

• при смене оценивающей LLM показатель «comparable rate» прыгал с 13.64% до 81.82%, то есть примерно на 68 пунктов (AI-Researcher).

Эти три наблюдения wiki свела к выводу: оценка через LLM-as-Judge сильно зависит и от того, кто написал оцениваемую статью (AI или человек), и от того, какая LLM выступает оценщиком, — то есть это не нейтральная ось, а три грани одного и того же паттерна. То, что синтез произошёл от простого раздельного ingest трёх работ, объясняется не тем, что я всё помню, а тем, что LLM при каждом ingest новой статьи перечитывает прошлые страницы и заново сводит согласованность. Сравните: даже если вести заметки в Notion, человек почти никогда не возвращается к заметке трёхмесячной давности, чтобы её переписать.

Пример 2: сопоставление взглядов Сэма Альтмана и Дарио Амодеи

Поводом было всего лишь желание разобраться во взглядах ключевых людей индустрии. Я по отдельности заing-естил четыре эссе: «Reflections» Альтмана и «Machines of Loving Grace», «The Urgency of Interpretability», «The Adolescence of Technology» Амодеи.

По мере последовательного ingest wiki сама свела разницу во взглядах на AGI у двух CEO — OpenAI и Anthropic — в виде противопоставления. Это был второй случай, когда я ощутил силу связывания, уже в другой форме.

В wiki/concepts/ независимо появились страницы людей (sam-altman.md и dario-amodei.md), а как концептуальные страницы из эссе — пять на стороне Амодеи (powerful-ai и др.) и две на стороне Альтмана (agi, iterative-deployment).

Самое любопытное — внутри agi.md подходы обоих были разобраны как противопоставление:

Wiki свела это противопоставление в одну фразу: определение Альтмана — это лексика направления, «куда мы движемся», а определение Амодеи — проверяемый список функций, «что оно умеет».

Мой инсайт в том, что от простого ingest эссе мысль авторов разложилась на отдельные понятия, а ось сравнения между людьми поднялась автоматически. Я не ставил задачу сравнительного анализа — раздельные вбросы сами пересобрались в wiki в ось противопоставления.

Наконец: пример 1 — это интеграция множества однотипных источников, пример 2 — извлечение контраста из немногих разных точек зрения. LLM Wiki делает и то и другое одной и той же операцией. Так видно, что у силы связывания есть два типа.

Что ещё выяснилось за месяц

Помимо самих инсайтов от связывания, за месяц эксплуатации всплыли два побочных наблюдения.

Первое — эффект Lint. Если периодически прогонять lint, LLM находит битые wikilink, осиротевшие страницы, а также дубли понятий из-за разнобоя в написании или разной гранулярности — и предлагает правки. Например, agent-harness, эджент-харнесс и harness расходятся в три разные страницы; или смешиваются теги reinforcement-learning и rl. Такой дрейф при повторных ingest возникает неизбежно. Если держать порядок периодическим lint, эти искажения не накапливаются и wiki не сползает в хаос.

Второе — накопление за счёт подшивки результатов Query. Я делал обзор по time-series foundation models (TSFM) и заing-естил больше десяти связанных статей. Когда я кидал грубые вопросы вроде «какие задачи решает TSFM? применимо ли это к чему-то, кроме прогноза будущих значений?», LLM поперечно перечитывала заing-есченные статьи, категоризировала задачи и подшивала результат в wiki/queries/.

Этот способ качественно отличается от вопроса к универсальной LLM. ChatGPT или Claude склонны отвечать широко и неглубоко — про «TSFM-исследования в мире вообще». А query к LLM Wiki отвечает, опираясь только на тот набор статей, что я заing-естил: scope замкнут на моей кураторской выборке, и ответ узкий, но глубокий и плотно прижатый к моему вопросу. Вдобавок ответ остаётся в wiki/queries/, так что следующие query и ingest могут на него ссылаться — синтез, который раньше растворялся в истории чата, накапливается в wiki как актив.

Три шага, чтобы завести у себя

Соберу минимальные шаги для тех, кто хочет внедрить.

Сразу оговорюсь: я не выкладываю свой набор скиллов как готовый дистрибутив. Это в духе того, что сам Карпатый написал в начале gist: это «файл для передачи идеи», и «your agent will build out the specifics in collaboration with you». То есть конкретная структура каталогов, определения скиллов и формат страниц рождаются в соавторстве с вашим LLM-агентом. Оптимальная форма LLM Wiki меняется от домена и темы, поэтому быстрее всего — взять паттерн Карпатого за отправную точку и вырастить своё.

Шаг 1: дать LLM прочитать gist и сгенерировать каркас

Дайте GitHub Gist Карпатого coding-агенту (например, Claude Code) с указанием вроде «следуя этому паттерну, собери мне мою wiki-настройку». На выходе вы как минимум получите:

• schema-файл (для Claude Code — CLAUDE.md, для Codex — AGENTS.md и т.п.): структуру каталогов, типы страниц, правила именования, описание workflow ingest/query/lint;

• структуру каталогов raw/, wiki/ и страницы-образцы.

Первая schema может быть простой — на Шаге 3 вы улучшите её, советуясь с LLM.

Для справки: образец минимальной структуры

Привожу упрощённую версию репозитория, который реально использую. Пример под Claude Code; для Codex и прочих читайте CLAUDE.md как AGENTS.md.

llm-wiki/├── CLAUDE.md                       # schema: соглашения по каталогам и workflow├── .claude/skills/│   ├── ingest-paper/SKILL.md       # ingest PDF статьи│   ├── ingest-article/SKILL.md     # ingest веб-материала│   ├── query/SKILL.md              # вопрос к wiki│   └── lint/SKILL.md               # health-check└── vault/                          # открывается как Obsidian Vault    ├── raw/    │   ├── papers/                 # PDF статей (неизменны)    │   └── articles/               # клиппинги веб-статей (неизменны)    └── wiki/                       # ведёт LLM        ├── index.md                # каталог по категориям        ├── log.md                  # append-only журнал активности        ├── papers/                 # резюме статей        ├── articles/               # резюме веб-статей        ├── concepts/               # поперечные концептуальные страницы        └── queries/                # подшивка результатов query

Скилл на практике может быть таким же простым. Вот минимальная версия ingest-paper. Запись [[wikilink]] — это функция Obsidian; в других редакторах замените на относительные ссылки.

---name: ingest-paperdescription: прочитать PDF статьи, создать резюме в wiki/papers/ и каскадно обновить связанные concept-страницы, index.md и log.md.---# Скилл Ingest статьиПрочитать указанный пользователем PDF, создать резюме в wiki и обновить связанные страницы.## Шаги1. Прочитать PDF (инструментом Read).2. Создать резюме: vault/wiki/papers/<имя_файла>.md. Включить frontmatter (title, authors, year, tags, type: paper) + перевод аннотации + TL;DR + предложенный метод + эксперименты + Limitations + «точки соприкосновения с этой wiki».3. Извлечь 3–7 ключевых понятий и обновить concept-страницы:   - если vault/wiki/concepts/<concept>.md есть — добавить ссылку в раздел источников и обновить раздел «сквозные наблюдения»;   - если нет — создать (обзор + сквозные наблюдения + связанные источники).4. Добавить запись в index.md.5. Дописать в log.md: | YYYY-MM-DD HH:MM | ingest-paper | Added [[статья]], updated [[concept]] |## Принципы- Все ссылки между страницами — в формате [[wikilink]].- Рост раздела «сквозные наблюдения» на concept-странице и есть само тело ценности wiki. При каждой новой статье активно фиксируйте общее, противоречия и взаимодополнение с уже имеющимися источниками.- Не добавлять домыслов и того, чего нет в оригинале.

Даже этого хватает, чтобы заработал базовый цикл: кидаешь PDF — создаётся резюме, обновляются связанные concept-страницы, пишутся index и log.

Шаг 2: для начала заing-естить статей пять

Закиньте 5 статей/материалов из своей области и глазами проверьте генерацию summary и concept-страниц, обновление index.md и log.md. Важно не то, идеален ли шаблон, а то, получилась ли concept-страница в форме, которую хочется перечитывать.

Шаг 3: растить шаблон под свой домен

После пяти ingest появляется чувство, каких секций не хватает, а какие лишние. То, какие секции concept-страницы создавать обязательно, прописано в ingest-скилле — туда и вносите правки. А «грамматику» всей wiki — правила именования, структуру каталогов, классификацию типов страниц — держите в schema-файле.

Конкретный пример: я исследователь, поэтому дописал в ingest-скилл требование всегда создавать в конце каждой concept-страницы секцию «нерешённые вопросы» — и с каждой прочитанной страницей получаю кандидатов в следующие темы исследования. Инженеру, возможно, ценнее окажутся секции «паттерны реализации» или «грабли».

Хитрость в том, чтобы и эту подстройку поручать LLM. Спросите «предложи, чего не хватает» — вернёт варианты улучшений. Попросите «сделай секцию нерешённых вопросов обязательной» — обновит и определение скилла, и существующие concept-страницы.

Причём подстройка не заканчивается за один раз: за недели-месяцы эксплуатации всплывают новые наблюдения — их тоже отдаёте LLM. Периодический Lint позволяет самой LLM находить расхождения между правилами и реальностью и предлагать правки. И schema, и скиллы — это не статичная конфигурация, а динамический артефакт, который учится тому, как вы им пользуетесь.

Когда этот цикл раскручивается, примеры «силы связывания» начинают происходить в вашем домене. Между «удобно вообще» и «инсайты реально начинают сцепляться в моей работе и исследованиях» лежит именно процесс подстройки из Шага 3.

Потолок: за «связыванием» стоит узкое место — понимание

До сих пор я хвалил силу связывания, но в эксплуатации виден и потолок, который не обойти. Сформулирую прямо: узким местом становится чтение и понимание самим человеком.

Как бы аккуратно LLM ни разложила концептуальные страницы, пока человек не прочитает и не переварит это в собственное понимание, знание не станет по-настоящему «моим». Потому что в момент генерации идей, написания статьи или спора в дискуссии в итоге опираешься на понимание в собственной голове.

Первая мера: я намеренно выбираю источники для ingest руками. Автоматизировать отбор (например, каждый день автоматически заing-естивать новые статьи из определённой категории arXiv) легко — но тогда concept-страницы растут там, где ты не следишь, и позже ловишь себя на «когда вообще появилась эта страница?», а узкое место с пониманием только усугубляется.

Поэтому я вбрасываю только то, что сам счёл «интересным, хочу прочитать». В итоге бывают дни по 10 штук и дни по нулям — и это нормально. Качество важнее количества. Не дать wiki переполниться — вот первая мера.

Даже при ограниченном ingest «объём, который хочется перечитать» копится, и следующий вопрос — как пользоваться wiki после ingest. Тут два способа:

1. Словарный способ: кидаешь query только по необходимости, получаешь ответ и используешь как есть.

2. Способ как опоры для понимания: активно вчитываешься в concept-страницы и пересобираешь их в собственное понимание.

Словарный способ удобен, но если только так, то приближаешься к состоянию «полностью отдал внешнюю память wiki от LLM» — получаешь одни ответы, не формируя активного понимания. Карпатый намеренно проектирует так, что человек почти не редактирует напрямую; но доведённое до предела, это рискует тем, что доменное понимание у человека не углубляется.

Поэтому у меня есть и базовое желание — не потреблять словарно, а именно углублять собственное понимание домена. Я нахожу время, смотрю concept-страницы в Obsidian, перечитываю то, что зацепило. Но даже так — выгоду получаешь, однако охватить все concept-страницы не выходит; особенно в периоды активного ingest большинство свежевыросших страниц проходят мимо. Плюс по-настоящему важные источники приходится читать в оригинале самому — так что крутишь и просмотр concept-страниц, и чтение оригиналов, и дел только прибавляется.

Как встроить это в рутину — пока нерешённая задача. Какие привычки приживутся, хочу осмыслить, ещё поэксплуатировав.

В заключение

Суммаризацию делают уже все. Но суммаризация замыкается на сжатии содержимого одного первоисточника, а связывание нескольких источников вытаскивает структуру, которой не видно, пока их не положишь рядом. Мой вывод после месяца: настоящая ценность LLM — на этой стороне, на стороне «связывания».

При этом как распорядиться этой силой — задача, оставшаяся человеку. Работу по доведению связанного знания до собственного понимания автоматизировать нельзя; LLM Wiki берёт на себя нагрузку памяти и организации, но на «вчитаться и разобраться» по-прежнему уходит время.

И последнее — чем хорош паттерн Карпатого. Не конкретной структурой каталогов и не конкретными скриптами, а тем, что он довёл «разделение ролей между LLM и человеком» до конкретики, которую можно реально реализовать. Достаточно абстрактно зафиксировать минимум — три слоя Raw / Wiki / Schema и три операции Ingest / Query / Lint, — а дальше каждый конкретизирует под свой домен, причём сам этот процесс конкретизации можно вести вместе с LLM. В этом и сила паттерна.