LLM Wiki и MemPalace: персональная база знаний и система памяти для AI-агентов

Первая немного запоздалая новость про LLM Wiki от Андрея Карпаты, одного из основателей OpenAI.

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

Главное преимущество этого подхода — в качестве знаний и в том, что их легко воспринимать человеку. Также при наполнении данными проще находить противоречия за счет связей.

Очень хорошо ложится на идею Second Brain и Obsidian, хотя, конечно, можно просто свой сайт поднять и не заморачиваться с Obsidian.

Skill, созданный энтузиастом. И самый популярный готовый репозиторий, который я смог найти.

И вторая интересная новость: Милла Йовович в роли архитектора вместе с Беном Сигманом (криптовалютный эксперт) в роли инженера создали MemPalace — систему памяти для AI-агентов, заточенную в первую очередь под разговоры, решения, контекст работы AI и историю взаимодействий AI.

Из реальных плюсов — здесь нет суммаризации, из-за чего данные сохраняются в первоначальном виде. По бенчмарку LongMemEval (оценка способности агентов к долгосрочному запоминанию) он на первом месте.

Также не нужна векторная база данных, не нужны дополнительные API-ключи, все построено на ChromaDB. Напрямую сравнивают с Mem0, Mastra, OpenViking и заявляют, что их решение — топ по всем фронтам.

Интересное время, актрисы вайбкодят проекты с криптанами.

LLM Wiki — персональная база знаний с LLM

LLM Wiki Паттерн для создания персональных баз знаний с помощью LLM.

Это файл с идеей. Он задуман так, чтобы его можно было скопировать и вставить в своего LLM-агента — например, в OpenAI Codex, Claude Code, OpenCode / Pi и т. п. Его задача — передать идею на высоком уровне, а конкретную реализацию агент уже выстроит вместе с вами.

Основная идея

Для большинства людей работа LLM с документами выглядит как RAG: вы загружаете набор файлов, модель находит релевантные фрагменты во время запроса и генерирует ответ. Это работает, но при каждом новом вопросе LLM заново переоткрывает знание с нуля.

Если вы задаёте тонкий вопрос, требующий синтеза пяти документов, модели приходится каждый раз заново находить нужные куски и склеивать их вместе. Ничего не накапливается. NotebookLM, загрузки файлов в ChatGPT и большинство RAG-систем работают именно так.

Здесь идея другая. Вместо простого поиска по сырым документам во время запроса LLM постепенно строит и поддерживает постоянную wiki — структурированную, взаимосвязанную коллекцию markdown-файлов, которая находится между вами и исходными материалами.

Когда вы добавляете новый источник, LLM не просто индексирует его на будущее. Она читает его, извлекает главное и встраивает это в уже существующую wiki: обновляет страницы сущностей, пересматривает тематические сводки, отмечает, где новые данные противоречат старым утверждениям, усиливает или оспаривает развивающийся синтез.

Знание компилируется один раз и затем поддерживается в актуальном состоянии, а не выводится заново при каждом запросе.

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

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

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

Это можно применять во множестве контекстов. Например:

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

• Исследование: глубокое погружение в тему на протяжении недель или месяцев — чтение статей, научных работ, отчётов и поэтапное создание полной wiki с развивающимся тезисом.

• Чтение книги: разбор каждой главы по мере чтения, создание страниц по персонажам, темам, сюжетным линиям и их связям. К концу у вас появляется насыщенная companion wiki. Можно представить себе фанатские вики вроде Tolkien Gateway — тысячи взаимосвязанных страниц о персонажах, местах, событиях и языках. Вы можете строить нечто подобное лично для себя во время чтения, а LLM возьмёт на себя все перекрёстные ссылки и обслуживание.

• Бизнес / команда: внутренняя wiki, которую поддерживают LLM и в которую попадают Slack-треды, транскрипты встреч, проектные документы и разговоры с клиентами. Возможно, с участием людей, которые утверждают обновления. Wiki остаётся актуальной, потому что её поддерживает LLM, а не перегруженная команда.

• Конкурентный анализ, due diligence, планирование поездки, конспекты курса, глубокие хобби-исследования: подходит всё, где знание накапливается со временем и его хочется видеть организованным, а не раскиданным по чатам и заметкам.

Архитектура

Здесь есть три слоя:

Raw sources — ваша курируемая коллекция исходных документов: статьи, научные работы, изображения, файлы данных. Они неизменяемы: LLM читает их, но никогда не правит. Это источник истины.

The wiki — каталог markdown-файлов, сгенерированных LLM: сводки, страницы сущностей, страницы понятий, сравнения, обзорные материалы, синтез. Этим слоем полностью владеет LLM. Она создаёт страницы, обновляет их при появлении новых источников, поддерживает перекрёстные ссылки и следит за согласованностью. Вы это читаете; LLM это пишет.

The schema — документ вроде CLAUDE.md для Claude Code или AGENTS.md для Codex, который объясняет LLM, как устроена wiki, какие в ней приняты соглашения и какие workflow использовать при ingest, ответах на вопросы и поддержке базы. Это ключевой конфигурационный файл: именно он превращает LLM из общего чат-бота в дисциплинированного хранителя wiki. Вы и LLM дорабатываете его со временем, по мере того как понимаете, что лучше работает в вашей предметной области.

Операции

Ingest. Вы кладёте новый источник в raw-коллекцию и просите LLM его обработать. Примерный поток: LLM читает источник, обсуждает с вами ключевые выводы, пишет summary page в wiki, обновляет индекс, обновляет связанные страницы сущностей и понятий по всей wiki и дописывает запись в лог. Один источник может затронуть 10–15 страниц.

Лично я предпочитаю ingest по одному источнику за раз и оставаться в процессе: читаю summaries, проверяю обновления и направляю LLM в том, что именно стоит подчеркнуть. Но можно и батчить много источников сразу, с меньшим надзором. Workflow зависит от вас — главное задокументировать его в schema, чтобы будущие сессии работали так же.

Query. Вы задаёте вопросы к wiki. LLM находит релевантные страницы, читает их и собирает ответ с цитатами. Ответы могут быть разными по форме: markdown-страница, сравнительная таблица, слайд-дек на Marp, график на matplotlib, canvas. Ключевой инсайт здесь в том, что хорошие ответы можно сохранять обратно в wiki как новые страницы.

Сравнение, которое вы запросили, анализ, обнаруженная связь — всё это ценно и не должно исчезать в истории чата. Так ваши исследования накапливаются в базе знаний точно так же, как и ingested-источники.

Lint. Периодически просите LLM проверить здоровье wiki. Что искать: противоречия между страницами, устаревшие утверждения, которые перекрыли новые источники, orphan pages без входящих ссылок, важные понятия без собственной страницы, отсутствующие перекрёстные ссылки, пробелы в данных, которые можно заполнить веб-поиском. LLM хорошо умеет предлагать новые вопросы для исследования и новые источники. Это помогает wiki оставаться здоровой по мере роста.

Индексация и журналирование

Два специальных файла помогают и LLM, и вам ориентироваться в wiki по мере её роста. У них разные роли:

index.md ориентирован на содержимое. Это каталог всего, что есть в wiki: каждая страница указана с ссылкой, однострочным summary и, при желании, метаданными вроде даты или количества источников. Всё организовано по категориям: сущности, концепты, источники и т. д. LLM обновляет его при каждом ingest. При ответе на запрос она сначала читает индекс, находит нужные страницы и только потом углубляется в них. На умеренном масштабе — примерно 100 источников и сотни страниц — это работает удивительно хорошо и избавляет от необходимости разворачивать embedding-based RAG-инфраструктуру.

log.md — хронологический файл. Это append-only история того, что произошло и когда: ingest, queries, lint-проходы. Полезный приём: если каждая запись начинается с единого префикса вроде ## [2026-04-02] ingest | Article Title, лог можно разбирать простыми unix-инструментами — например, grep "^## \[" log.md | tail -5 покажет последние пять записей. Лог даёт вам временную шкалу эволюции wiki и помогает LLM понимать, что происходило недавно.

Опционально: CLI-инструменты

В какой-то момент вам, возможно, захочется написать небольшие утилиты, которые помогут LLM эффективнее работать с wiki. Самый очевидный пример — поиск по страницам. На маленьком масштабе хватает index-файла, но по мере роста wiki уже нужен полноценный search.

qmd — хороший вариант: это локальный поисковый движок по markdown-файлам с гибридным BM25/vector search и LLM re-ranking, причём всё работает на устройстве. У него есть и CLI (так что LLM может вызывать его из shell), и MCP server (так что LLM может использовать его как нативный инструмент). Можно и сделать что-то попроще самому — LLM вполне может помочь вам быстро собрать наивный поисковый скрипт, когда возникнет необходимость.

Советы и приёмы

• Obsidian Web Clipper — браузерное расширение, которое преобразует веб-статьи в markdown. Очень удобно для быстрого добавления источников в raw-коллекцию.

• Скачивайте изображения локально. В настройках Obsidian → Files and links можно задать фиксированную папку для вложений — например, raw/assets/. Затем в Settings → Hotkeys найдите команду Download attachments for current file и повесьте её на горячую клавишу, например Ctrl+Shift+D. После клипа статьи нажимаете хоткей — и все изображения скачиваются локально. Это опционально, но полезно: LLM сможет смотреть на картинки напрямую, а не зависеть от внешних URL, которые могут сломаться. Важно помнить, что LLM не умеют в один проход нативно читать markdown вместе со встроенными изображениями; рабочий обходной путь — сначала читать текст, а потом отдельно просматривать часть или все изображения для дополнительного контекста. Немного неловко, но на практике работает.

• Graph view в Obsidian — лучший способ увидеть форму вашей wiki: что с чем связано, какие страницы являются хабами, а какие — сиротами.

• Marp — markdown-формат для слайд-деков. В Obsidian для него есть плагин. Полезно, если вы хотите генерировать презентации прямо из содержимого wiki.

• Dataview — плагин Obsidian, который выполняет запросы по frontmatter страниц. Если LLM добавляет в wiki-страницы YAML frontmatter с тегами, датами и количеством источников, Dataview сможет строить динамические таблицы и списки.

• Вся wiki — это просто git-репозиторий из markdown-файлов. А значит, вы бесплатно получаете историю версий, ветвление и совместную работу.

Почему это работает

Самая утомительная часть поддержки базы знаний — это не чтение и не мышление, а бухгалтерия: обновлять перекрёстные ссылки, держать summaries актуальными, отмечать, где новые данные противоречат старым, и поддерживать согласованность между десятками страниц.

Люди бросают wiki, потому что нагрузка на поддержку растёт быстрее, чем полезность. LLM не скучает, не забывает обновить перекрёстную ссылку и может затронуть 15 файлов за один проход. Wiki остаётся живой, потому что стоимость поддержки становится почти нулевой.

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

По духу эта идея родственна Memex Вэнивара Буша (1945) — персональному, курируемому хранилищу знаний с ассоциативными тропами между документами. Видение Буша было ближе именно к этому, чем к тому, чем в итоге стал веб: приватное, активно курируемое пространство, где связи между документами столь же ценны, как и сами документы. Единственное, чего он не мог решить, — кто будет заниматься поддержкой. Эту часть и берёт на себя LLM.

Примечание

Этот документ намеренно абстрактный. Он описывает идею, а не конкретную реализацию. Точная структура директорий, conventions в schema, форматы страниц, инструменты — всё это зависит от вашей предметной области, ваших предпочтений и выбранной LLM.

Всё описанное выше необязательно и модульно: берите то, что полезно, и игнорируйте то, что не подходит. Например, ваши источники могут быть только текстовыми — значит, обработка изображений вам вообще не нужна. Ваша wiki может быть достаточно маленькой, чтобы index-файла было полностью достаточно и никакой search engine не требовался. Вам могут быть не нужны слайд-деки — только markdown-страницы. А может быть, вам вообще нужен другой набор выходных форматов.

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