Файловая система - уже графовая база данных
- title
- Файловая система - уже графовая база данных
- type
- summary
- summary
- Markdown-vault с wikilink'ами - уже графовая база данных; расширения PARA, масштабируемые до 52k файлов
- tags
- pkm, llm, graph-database, context-engineering
- sources
- filesystem-is-graph-database
- created
- 2026-04-09
- updated
- 2026-04-09
- lang
- ru
- translation_of
- filesystem-is-graph-database
- source_updated
- 2026-04-09
- translated
- 2026-09-01
- translator
- lllm/antigravity/gemini-3.7-flash-high
В посте Rumproarious за апрель 2026 года утверждается, что обычная папка с markdown-файлами и wikilink'ами - это уже полноценная графовая база данных для личных знаний. Упрощение прямолинейное: файлы - это узлы, wikilink'и - рёбра, а папки - таксономия. Никаких векторных хранилищ, никакой Neo4j, никакого RAG-конвейера. В связке с LLM, умеющей читать эти файлы, получается интерфейс естественно-языковых запросов к собственной базе знаний.
Автор использует этот подход в серьёзном масштабе - порядка 52 447 markdown-файлов. Структура расширяет PARA несколькими практическими соглашениями:
/projects/{name}- активные проекты, стандарт PARA/areas/{topics}- постоянные зоны ответственности/people/{slack_handle}- по файлу на человека с ключом в виде его ника в Slack/daily/{year}/{month}/{day}/- ежедневные журналы/meetings/{year}/{month}/{day}/- заметки со встреч
Главные нововведения здесь - директория /people/ и временной каркас (/daily/, /meetings/). В самом методе PARA нет очевидного места для "заметок о коллеге" или "того, что произошло в этот день" - расширенная структура даёт понятный путь для обоих случаев. Поскольку ники в Slack внутри компании стабильны и уникальны, использование их в качестве ключей для файлов людей позволяет тривиально ставить wikilink'и прямо из заметок со встреч.
Самый интересный смысловой сдвиг в посте - называть всё это "системой context engineering", а не базой знаний. Суть не в поиске информации. Дело в том, что любое взаимодействие с LLM по умолчанию начинается с чистого листа: без прошлых решений, без истории встреч, без архитектурного контекста. Если всё это время вести заметки со встреч и логи решений, то в новый диалог можно скормить нужный срез графа и получить ощутимо лучший результат. Ценность графа проявляется в следующем диалоге, а не в текущем. Это перекликается с философией llm-wiki-pattern - накапливаемый эффект даёт именно долгоживущий артефакт.
Автор честно признаёт то, что не работает: автоматическая обработка входящих. Чёткие правила для того, "что делать с этой сохранённой заметкой", постоянно ломаются о разнообразие типов контента. Было множество попыток, но стабильного решения нет. Это совпадает с опытом этой самой wiki: рабочий процесс inbox/ по-прежнему опирается на участие человека для каждой заметки, а полной автоматизации сознательно избегают.
Рецепт для старта минимален: создать папки, неделю писать заметки со встреч со ссылками на людей и проекты, а затем использовать получившийся граф как основу для реального текста или проекта. Графу не обязательно быть всеобъемлющим, чтобы приносить пользу, - достаточно покрывать конкретные решения и людей, которые всплывут в следующем диалоге с LLM.
Для этой конкретной Second Brain данный пост подтверждает ключевую ставку: связки markdown + wikilink'и + поддерживающая граф LLM вполне достаточно. Он также предлагает два конкретных дополнения, над которыми стоит подумать: директорию /people/ и датированные заметки со встреч / ежедневные логи, которых сейчас в структуре нет. Базовую концепцию см. в files-as-graph-database, а более широкий взгляд на контекст - в context-engineering.