Второй мозг и LLM‑Wiki: Теория и практический гайд по созданию и поддержке личной базы знаний

В этой статье поговорим про концепцию «второго мозга»: что это такое, где хранить информацию и как ее использовать. Разберу, как собрать минимальную систему знаний в Obsidian, чем подход LLM‑Wiki от Andrej Karpathy отличается от классического RAG, и покажу практический пример реализации «второго мозга».

Изначально этот текст должен был стать постом в телеграм‑канале, аналогично посту про память агентов. Однако, материала получилось много, поэтому я вынес его в отдельную статью.

Пара слов обо мне

Меня зовут Евгений. Я разработчик и лид ML‑команды. На работе и в свободное время занимаюсь проектами, связанными с агентами, LLM и обработкой естественного языка в целом. В своем тг канале «В погоне за NLP» (@chasing_nlp) делюсь практическим опытом и рассказываю про техническую часть AI и ML.

Введение

В какой‑то момент у меня накопилось большое количество заметок по учебе и работе. Это был неорганизованный ужас, хаос, представленный под видом полезной информации, к которой я больше никогда не вернусь.

Что с этим делать? В интернете можно найти много решений этой проблемы. Есть целое направление — заметковедение, которое изучает способы ведения заметок и повышения продуктивности с их помощью.

Один из подходов к решению этой проблемы — концепция «второго мозга». В его реализации могут использоваться разные методы, например Zettelkasten.

Что такое второй мозг?

Второй мозг — это внешняя система для хранения, систематизации и дальнейшего использования знаний. Идея простая: не пытаться держать все в голове, а выносить заметки, идеи, задачи, выводы и полезные материалы в надежное хранилище.

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

Например, вы читаете статью про память агентов, потом заметку про RAG, потом материал про LLM‑Wiki. Если между этими заметками есть связи, постепенно появляется карта темы, а не набор разрозненных файлов.

Почему для этого часто используют Obsidian

Важная особенность Obsidian — ссылки между заметками. С их помощью можно собирать граф знаний и удобно перемещаться по материалам внутри одной темы.

Минимальный сценарий использования выглядит так:

1. Создать vault — папку, где будут лежать все заметки.

2. Завести простую структуру, например PARA: Проекты, Области, Ресурсы, Архив.

3. Складывать новые материалы в соответствующую папку.

4. Для важных идей создавать отдельные заметки и связывать их между собой.

5. Периодически проходить по заметкам и обновлять связи.

Здесь не стоит начинать со сложной методологии. Если структура будет слишком тяжелой, ей быстро перестаешь пользоваться. На старте достаточно Markdown, ссылок и привычки регулярно сохранять полезные мысли.

Что такое LLM‑Wiki

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

LLM‑Wiki предлагает часть этой рутины отдать LLM‑агенту. Вместо того чтобы просто складывать документы и каждый раз делать RAG‑поиск по сырому архиву, агент постепенно строит wiki из Markdown‑файлов. Он читает новые источники, выделяет концепты, обновляет существующие страницы, добавляет ссылки и отмечает противоречия.

То есть «второй мозг» становится не просто хранилищем, а системой, которая постепенно компилирует знания.

Об этом подходе рассказал Andrej Karpathy. Он описывает систему в три слоя:

• Raw sources — неизменяемые исходники: статьи, книги, PDF, заметки, транскрипты. Это источник истины.

• Wiki — переработанная база знаний: саммари источников, страницы по концептам, людям, компаниям, сравнения и связи между ними.

• Schema — инструкции для агента: как оформлять страницы, какие типы связей использовать, что делать при добавлении нового источника, как проверять базу. На практике это обычный набор правил, который агент подхватывает на старте сессии — AGENTS.md для Codex и Cursor, CLAUDE.md для Claude Code.

У системы есть три основные операции:

• Ingest — добавляем новый источник, агент читает его и обновляет wiki.

• Query — задаем вопрос не к набору файлов, а к уже собранной карте знаний.

• Lint — проверяем базу на битые ссылки, устаревшие утверждения, противоречия и страницы без связей.

Аналогия от Karpathy:

Obsidian — это IDE, LLM — программист, wiki — кодовая база. Человек выбирает источники и задает направление, а агент делает рутинную работу по поддержке структуры.

LLM‑Wiki vs классический RAG

LLM‑Wiki часто противопоставляют RAG, хотя это не совсем точно.

RAG — это паттерн: «retrieve → augment → generate», то есть «найди релевантный контекст, добавь в контекст модели, получи ответ».

В этом смысле использование LLM‑Wiki — тоже часть RAG: агент находит нужные страницы, подкладывает их в контекст и генерирует ответ. Просто роль векторной базы играет структурированный markdown, а роль retrieval — LLM‑навигация по индексу и [[wikilinks]].

Поэтому корректнее сравнивать не «RAG против LLM‑Wiki», а два способа хранить и искать знания внутри одного и того же паттерна:

• Классический RAG — чанки + эмбеддинги + векторная база + поиск по семантическому сходству (на практике обычно гибрид: BM25 + векторный поиск, переранжирование, перефразирование query);

• LLM‑Wiki — структурированные markdown‑страницы + [[wikilinks]] + индекс + LLM‑навигация (при росте базы поверх можно добавить тот же гибридный поиск, например через qmd).

Главное отличие — этап переработки данных

Реальная новизна LLM‑Wiki не в поиске информации, а в шаге переработки базы знаний, которого в классическом RAG просто нет.

В RAG документы хранятся как есть. Их режут на чанки, считают эмбеддинги и складывают в векторную базу. На каждый запрос система ищет top‑K похожих кусков и собирает ответ заново — из сырых фрагментов, без накопленного понимания. Связи между документами модель каждый раз определяет по семантическому сходству.

В LLM‑Wiki большая часть работы делается заранее. Агент читает источники, выделяет концепты и сущности, пишет связные страницы, расставляет ссылки, ведет индекс и журнал изменений. Запрос идет уже не к векторам, а к компилированной базе знаний — структурированному markdown с осмысленными переходами.

Karpathy в посте говорит «The knowledge is compiled once and then kept current, not re‑derived on every query». Чуть дальше эту идею обычно разворачивают в полноценную аналогию: RAG ближе к интерпретатору (каждый раз перечитывает исходники), а LLM‑Wiki — к компилятору (тяжелая работа делается один раз, дальше запросы идут к готовому артефакту).

Как устроены поиск информации и хранилище

Сам поиск в LLM‑Wiki устроен принципиально иначе. Агент не считает эмбеддинг запроса и не ищет похожие чанки — он сначала открывает index.md, который при умеренном размере базы целиком помещается в контекст и дает карту базы знаний. По этой карте агент выбирает релевантные страницы, читает их, при необходимости переходит по [[wikilinks]] к связанным концептам и только если ответа на wiki‑уровне нет — спускается в raw/ к исходникам.

По сути это навигация по знаниям, а не семантический поиск: модель работает с уже структурированной картой темы, поэтому ответ ссылается на конкретные wiki‑страницы и raw‑файлы, а не на безымянные фрагменты.

Сравнение по основным параметрам

Стоит оговориться: «markdown‑папка + LLM‑агент» — это упрощение. Чтобы LLM‑Wiki реально работала, нужен агент, который умеет ходить по файловой системе, читать и писать markdown, переходить по [[wikilinks]], обновлять индекс и журнал, а на ingest и lint выполнять многошаговый цикл вызова инструментов. Сложность здесь не в инфраструктуре, а в самом агенте и его схеме: чем аккуратнее описаны правила оформления страниц и операции ingest/query/lint, тем стабильнее ведет себя система.

По сути мы меняем сложность векторного пайплайна на сложность агента и его промпта. На практике эту часть берет на себя готовый инструмент — Cursor, Claude Code, Codex CLI или другой агент с инструментами работы с файлами, — поэтому развернуть LLM‑Wiki для личного пользования все равно сильно проще, чем поднимать RAG‑стек.

Когда какой подход выбирать

Для личного второго мозга LLM‑Wiki выигрывает почти всегда: не нужна векторная база, ответы идут не из обрывков, а из связных страниц, и со временем база не размывается, а укрепляется.

Классический RAG остается полезным там, где знаний слишком много или они меняются слишком часто, чтобы держать их в одном индексе — например, рабочая документация большой компании или поток новостей.

На практике эти подходы хорошо сочетаются: LLM‑Wiki держит ядро устойчивых знаний, а RAG добирает свежие или редкие документы из большого корпуса.

Как реализовать свой второй мозг

Начать можно с простого:

1. Создать Obsidian vault и хранить его в git.

2. Разделить raw и wiki: исходники не переписываем, wiki можно обновлять.

3. Завести index.md — карту основных страниц и содержание базы знаний.

4. Завести log.md — журнал изменений: что добавили, что обновили, какие вопросы задавали.

5. Написать промпт и правила для LLM‑агента (для старта достаточно нескольких абзацев, дальше схема дорастает по мере использования).

6. Для каждой новой статьи просить агента сделать ingest: саммари, ключевые идеи, связанные страницы и ссылки на источники.

7. Периодически запускать lint: искать битые ссылки, устаревшие страницы, дубли и противоречия.

Пример реализации LLM‑Wiki

В моем примере реализации (проект выложен на github) процесс выглядит так:

1. Собрать статьи в папку raw/ внутри созданного vault. Я делаю это с помощью Obsidian Web Clipper (веб‑расширение для добавления статьи в ваш Obsidian vault).

2. Описать правила для агента в AGENTS.md в корне vault — это единственное место со всеми правилами поведения.

3. Открыть vault в агенте (Cursor, Codex CLI, Claude Code) и попросить выполнить обработку сырых данных raw/ или согласовать изменения в raw/.

Весь список правил в AGENTS.md можно посмотреть в репозитории.

После запуска операции ingest агент сам наполняет wiki/: пишет саммари, выделяет идеи, расставляет [[wikilinks]], обновляет индекс, реестр источников и журнал. Дальше тот же AGENTS.md помогает выполнять любые операции — добавление новых статей, удаление старых, lint и ответы на вопросы.

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

Готовый vault с AGENTS.md и собранной базой знаний выложил на github. Я использовал Cursor и GPT-5.5. Тот же AGENTS.md без изменений работает и в Codex CLI, и в Claude Code.

Итог

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

• Obsidian подходит как основа: локальные markdown‑файлы, граф ссылок, vault в git. Этого уже достаточно, чтобы начать без сложной методологии.

• LLM‑Wiki — это второй мозг с агентом, который снимает самую затратную часть работы: саммаризацию источников, расстановку связей, поддержку индекса и проверку базы.

• Главное отличие от классического RAG — не в поиске информации, а в этапе переработки базыз знаний. Знания собираются заранее в связную wiki, а не пересобираются на каждый запрос из чанков. Поэтому ответ идет не из обрывков, а из готовых страниц со ссылками на источники.

• Не стоит переусложнять. Для личного использования не нужен идеальный граф знаний с первого дня — достаточно минимальной структуры (raw/, wiki/, index.md, log.md) и набора правил для агента. Схема и связи дорастают по мере использования.

В сухом остатке идея остается простой: человек выбирает источники и задает направление, а агент берет на себя рутину поддержки структуры. Так личная база знаний перестает быть свалкой ссылок и становится системой, которая со временем не размывается, а укрепляется.

Другие мои статьи:

1. Agent Harness: одна LLM, разные результаты — в чем секрет?

P. S. Спасибо за прочтение статьи. Также приглашаю в свой тг‑канал «В погоне за NLP» (@chasing_nlp). Там буду публиковать анонсы новых статей и свой опыт разработки проектов с LLM и агентами.