Паттерн построения личных баз знаний с помощью LLM.
Это файл с идеей — он рассчитан на то, что вы скопируете его в своего LLM-агента (например, OpenAI Codex, Claude Code, OpenCode / Pi и т.п.). Его задача — донести идею на верхнем уровне, а конкретику ваш агент проработает уже вместе с вами.
Опыт большинства людей с LLM и документами выглядит как RAG: вы загружаете коллекцию файлов, LLM достаёт релевантные фрагменты в момент запроса и генерирует ответ. Это работает, но LLM каждый раз заново выводит знания с нуля. Нет накопления. Задайте тонкий вопрос, требующий синтеза пяти документов, — и LLM каждый раз заново ищет и склеивает релевантные фрагменты. Ничего не накапливается. NotebookLM, загрузка файлов в ChatGPT и большинство RAG-систем работают именно так.
Идея здесь другая. Вместо того чтобы просто доставать данные из сырых документов в момент запроса, LLM инкрементально строит и поддерживает постоянную wiki — структурированную, перелинкованную коллекцию markdown-файлов, которая стоит между вами и сырыми источниками. Когда вы добавляете новый источник, LLM не просто индексирует его для последующего поиска. Он читает его, извлекает ключевую информацию и интегрирует в существующую wiki — обновляет страницы сущностей, переписывает тематические сводки, отмечает места, где новые данные противоречат старым утверждениям, усиливает или оспаривает развивающийся синтез. Знание компилируется один раз, а потом поддерживается актуальным, а не выводится заново на каждый запрос.
В этом ключевая разница: wiki — это постоянный, накапливающийся артефакт. Перекрёстные ссылки уже на месте. Противоречия уже отмечены. Синтез уже отражает всё, что вы прочитали. Wiki становится богаче с каждым добавленным источником и каждым заданным вопросом.
Вы никогда (или почти никогда) не пишете wiki сами — её пишет и поддерживает LLM. Вы отвечаете за подбор источников, исследование и постановку правильных вопросов. LLM делает всю чёрную работу — суммирование, простановку перекрёстных ссылок, раскладывание по местам и бухгалтерию, которая и делает базу знаний по-настоящему полезной со временем. На практике у меня LLM-агент открыт с одной стороны, а Obsidian — с другой. LLM делает правки на основе нашего разговора, а я просматриваю результаты в реальном времени — хожу по ссылкам, смотрю в graph view, читаю обновлённые страницы. Obsidian — это IDE; LLM — программист; wiki — это codebase.
Это применимо к самым разным контекстам. Несколько примеров:
Здесь три слоя:
Сырые источники — ваша подобранная коллекция исходных документов. Статьи, paper'ы, картинки, файлы данных. Они неизменяемые — LLM из них читает, но никогда их не модифицирует. Это ваш источник истины.
Wiki — каталог сгенерированных LLM markdown-файлов. Сводки, страницы сущностей, страницы концепций, сравнения, обзор, синтез. Этим слоем LLM владеет полностью. Он создаёт страницы, обновляет их при появлении новых источников, поддерживает перекрёстные ссылки и держит всё консистентным. Вы это читаете; LLM это пишет.
Схема — документ (например, CLAUDE.md для Claude Code или AGENTS.md для Codex), который рассказывает LLM, как устроена wiki, какие в ней соглашения и каким workflow следовать при ингесте источников, ответах на вопросы или поддержке wiki. Это ключевой конфигурационный файл — именно он делает LLM дисциплинированным мейнтейнером wiki, а не дженерик-чат-ботом. Вы и LLM коэволюционируете его со временем по мере того, как понимаете, что работает в вашем домене.
Ингест. Вы кладёте новый источник в сырую коллекцию и говорите LLM его обработать. Пример потока: LLM читает источник, обсуждает с вами ключевые выводы, пишет страницу-сводку в wiki, обновляет индекс, обновляет соответствующие страницы сущностей и концепций по всей wiki и добавляет запись в лог. Один источник может затронуть 10–15 страниц wiki. Лично я предпочитаю ингестить источники по одному и оставаться вовлечённым — читаю сводки, проверяю обновления и направляю LLM, на чём сделать акцент. Но можно и батч-ингестить много источников разом с меньшим контролем. Какой workflow подходит вашему стилю — решать вам; зафиксируйте его в схеме для будущих сессий.
Запрос. Вы задаёте вопросы по wiki. LLM ищет релевантные страницы, читает их и синтезирует ответ с цитированием. Ответы могут принимать разные формы в зависимости от вопроса — markdown-страница, сравнительная таблица, слайд-дек (Marp), график (matplotlib), canvas. Важная мысль: хорошие ответы можно складывать обратно в wiki как новые страницы. Сравнение, которое вы запросили, проведённый анализ, найденная связь — это ценно, и не должно растворяться в истории чата. Так ваши исследования накапливаются в базе знаний так же, как и ингестированные источники.
Линт. Периодически просите LLM провести health-check wiki. Искать: противоречия между страницами, устаревшие утверждения, которые перекрыты новыми источниками, страницы-сироты без входящих ссылок, важные концепции, которые упоминаются, но не имеют собственной страницы, отсутствующие перекрёстные ссылки, пробелы в данных, которые можно закрыть веб-поиском. LLM хорошо предлагает новые вопросы для исследования и новые источники для поиска. Это поддерживает wiki в здоровом состоянии по мере роста.
Два специальных файла помогают LLM (и вам) ориентироваться в wiki по мере её роста. У них разные задачи:
index.md — про контент. Это каталог всего, что есть в wiki: каждая страница с ссылкой, однострочной сводкой и опционально метаданными вроде даты или количества источников. Организован по категориям (сущности, концепции, источники и т.д.). LLM обновляет его при каждом ингесте. Отвечая на запрос, LLM сначала читает индекс, чтобы найти релевантные страницы, а потом углубляется в них. Это удивительно хорошо работает на умеренном масштабе (~100 источников, ~сотни страниц) и избавляет от необходимости в RAG-инфраструктуре на эмбеддингах.
log.md — хронологический. Это append-only запись того, что и когда происходило: ингесты, запросы, проходы линта. Полезный совет: если каждая запись начинается с консистентного префикса (например, ## [2026-04-02] ingest | Article Title), лог становится парсимым простыми unix-инструментами — grep "^## \[" log.md | tail -5 даст вам последние 5 записей. Лог даёт таймлайн эволюции wiki и помогает LLM понимать, что было сделано недавно.
В какой-то момент может захотеться построить небольшие инструменты, которые помогают LLM эффективнее работать с wiki. Поисковик по страницам wiki — самый очевидный из них: на маленьком масштабе индексного файла достаточно, но по мере роста wiki хочется нормального поиска. qmd — хороший вариант: это локальный поисковик по markdown-файлам с гибридным BM25/vector search и LLM re-ranking, всё on-device. У него есть и CLI (LLM может шеллиться к нему), и MCP-сервер (LLM может использовать его как нативный tool). Можно собрать и что-то проще самому — LLM поможет вам vibe-кодить наивный поисковый скрипт, когда возникнет нужда.
raw/assets/). Затем в Settings → Hotkeys найдите по слову «Download» команду «Download attachments for current file» и забиндьте её на хоткей (например, Ctrl+Shift+D). После клипа статьи нажимаете хоткей — и все картинки скачиваются на локальный диск. Это опционально, но полезно — позволяет LLM смотреть и ссылаться на картинки напрямую, а не зависеть от URL'ов, которые могут отвалиться. Учтите, что LLM не умеют нативно читать markdown с инлайн-картинками за один проход — обходной путь: сначала LLM читает текст, а потом отдельно смотрит часть или все упомянутые картинки, чтобы получить дополнительный контекст. Немного неуклюже, но работает достаточно хорошо.Нудная часть поддержки базы знаний — это не чтение и не размышление, это бухгалтерия. Обновлять перекрёстные ссылки, держать сводки актуальными, отмечать, когда новые данные противоречат старым утверждениям, поддерживать консистентность между десятками страниц. Люди забрасывают wiki, потому что бремя поддержки растёт быстрее, чем ценность. LLM не устают, не забывают обновить перекрёстную ссылку и могут затронуть 15 файлов за один проход. Wiki поддерживается, потому что стоимость поддержки близка к нулю.
Работа человека — подбирать источники, направлять анализ, задавать хорошие вопросы и думать о том, что всё это значит. Работа LLM — всё остальное.
Идея духом близка к Memex Ванневара Буша (1945) — личному, курируемому хранилищу знаний с ассоциативными цепочками между документами. Видение Буша было ближе к этому, чем к тому, чем стал веб: приватное, активно курируемое, со связями между документами, ценными не меньше самих документов. То, что он не смог решить, — кто делает поддержку. Это берёт на себя LLM.
Этот документ намеренно абстрактный. Он описывает идею, а не конкретную реализацию. Точная структура каталогов, соглашения схемы, форматы страниц, тулинг — всё это будет зависеть от вашего домена, ваших предпочтений и LLM на ваш выбор. Всё, что упомянуто выше, — опционально и модульно: берите то, что полезно, игнорируйте остальное. Например: ваши источники могут быть только текстовыми — тогда никакая работа с картинками вам не нужна. Ваша wiki может быть достаточно маленькой, чтобы хватило индексного файла, без поисковика. Возможно, вам не нужны слайд-деки и достаточно markdown-страниц. Возможно, вы хотите совсем другой набор выходных форматов. Правильный способ это использовать — поделиться этим с вашим LLM-агентом и вместе с ним инстанцировать версию, которая подходит вашим нуждам. Задача документа — только донести паттерн. Остальное LLM разберётся сам.