Перейти к содержанию

На этой странице

LLM Wiki Карпати: создание/запрос взаимосвязанной базы знаний в формате Markdown.

Метаданные навыка

Источник
Путь
Версия
Автор
Лицензия
Теги
Связанные навыки

Справочник: полный SKILL.md

Информация Ниже приведено полное определение навыка, которое Hermes загружает при активации этого навыка. Это инструкции, которые видит агент, когда навык активен.

LLM Wiki Карпати

Создавайте и поддерживайте персистентную, накапливающуюся базу знаний в виде взаимосвязанных markdown-файлов. Основано на паттерне LLM Wiki Андрея Карпати.

В отличие от традиционного RAG (который заново извлекает знания с нуля для каждого запроса), вики компилирует знания один раз и поддерживает их в актуальном состоянии. Перекрёстные ссылки уже существуют. Противоречия уже отмечены. Синтез отражает всё, что было поглощено.

Разделение труда: Человек курирует источники и направляет анализ. Агент обобщает, создаёт перекрёстные ссылки, систематизирует и поддерживает согласованность.

Когда активируется этот навык

Используйте этот навык, когда пользователь:

  • Просит создать, построить или запустить вики или базу знаний
  • Просит ингестировать, добавить или обработать источник в свою вики
  • Задаёт вопрос, и существующая вики находится по указанному пути
  • Просит проверить, проаудировать или выполнить health-check своей вики
  • Упоминает свою вики, базу знаний или «заметки» в исследовательском контексте

Расположение вики

Расположение: Задаётся через переменную окружения WIKI_PATH (например, в ~/.hermes/.env).

Если не задана, по умолчанию используется ~/wiki.

[code] WIKI="${WIKI_PATH:-$HOME/wiki}"

[/code]

Вики — это просто директория с markdown-файлами — открывайте её в Obsidian, VS Code или любом редакторе. Никакой базы данных, никаких специальных инструментов не требуется.

Архитектура: Три слоя

[code] wiki/ ├── SCHEMA.md # Соглашения, правила структуры, конфигурация домена ├── index.md # Каталог содержимого по разделам с однострочными сводками ├── log.md # Хронологический журнал действий (только добавление, ротация по годам) ├── raw/ # Слой 1: Неизменяемый исходный материал │ ├── articles/ # Веб-статьи, вырезки │ ├── papers/ # PDF, статьи с arXiv │ ├── transcripts/ # Записи встреч, интервью │ └── assets/ # Изображения, диаграммы, используемые в источниках ├── entities/ # Слой 2: Страницы сущностей (люди, организации, продукты, модели) ├── concepts/ # Слой 2: Страницы концепций/тем ├── comparisons/ # Слой 2: Сравнительные анализы └── queries/ # Слой 2: Сохранённые результаты запросов, которые стоит сохранить

[/code]

Слой 1 — Исходные источники: Неизменяемые. Агент читает, но никогда не изменяет их. Слой 2 — Вики: Файлы Markdown, принадлежащие агенту. Создаются, обновляются и связываются перекрёстными ссылками агентом. Слой 3 — Схема: SCHEMA.md определяет структуру, соглашения и таксономию тегов.

Возобновление существующей вики (ВАЖНО — делайте это каждую сессию)

Когда у пользователя есть существующая вики, всегда сначала ознакомьтесь с ней, прежде чем что-либо делать:

Прочитайте SCHEMA.md — поймите домен, соглашения и таксономию тегов. ② Прочитайте index.md — узнайте, какие страницы существуют и их краткие сводки. ③ Просмотрите недавний log.md — прочитайте последние 20-30 записей, чтобы понять недавнюю активность.

[code] WIKI="${WIKI_PATH:-$HOME/wiki}" # Ознакомительное чтение в начале сессии read_file "$WIKI/SCHEMA.md" read_file "$WIKI/index.md" read_file "$WIKI/log.md" offset=<последние 30 строк>

[/code]

Только после ознакомления следует производить ингестирование, запросы или проверку. Это предотвращает:

  • Создание дублирующихся страниц для уже существующих сущностей
  • Пропуск перекрёстных ссылок на существующий контент
  • Противоречие соглашениям схемы
  • Повторение уже залогированной работы

Для больших вики (100+ страниц) также выполните быстрый search_files по интересующей теме перед созданием чего-либо нового.

Инициализация новой вики

Когда пользователь просит создать или запустить вики:

  1. Определите путь к вики (из переменной окружения $WIKI_PATH или спросите пользователя; по умолчанию ~/wiki)
  2. Создайте структуру директорий выше
  3. Спросите пользователя, какой домен охватывает вики — будьте конкретны
  4. Напишите SCHEMA.md, адаптированный под домен (см. шаблон ниже)
  5. Напишите начальный index.md с заголовками разделов
  6. Напишите начальный log.md с записью о создании
  7. Подтвердите, что вики готова, и предложите первые источники для ингестирования

Шаблон SCHEMA.md

Адаптируйте под домен пользователя. Схема ограничивает поведение агента и обеспечивает согласованность:

[code] # Схема вики

## Домен
[Что охватывает эта вики — например, «исследования AI/ML», «личное здоровье», «разведка стартапов»]

## Соглашения
- Имена файлов: строчные буквы, дефисы, без пробелов (например, `transformer-architecture.md`)
- Каждая страница вики начинается с YAML-фронтматера (см. ниже)
- Используйте `[[вики-ссылки]]` для связывания страниц (минимум 2 исходящие ссылки на страницу)
- При обновлении страницы всегда обновляйте дату `updated`
- Каждая новая страница должна быть добавлена в `index.md` в правильный раздел
- Каждое действие должно быть добавлено в `log.md`
- **Маркеры происхождения:** На страницах, синтезирующих 3+ источника, добавляйте `^[raw/articles/source-file.md]`
  в конце абзацев, утверждения которых происходят из конкретного источника. Это позволяет читателю проследить каждое
  утверждение обратно без повторного чтения всего исходного файла. Опционально на страницах с одним источником, где
  фронтматер `sources:` достаточен.

## Фронтматер
  ```yaml
  ---
  title: Заголовок страницы
  created: ГГГГ-ММ-ДД
  updated: ГГГГ-ММ-ДД
  type: entity | concept | comparison | query | summary
  tags: [из таксономии ниже]
  sources: [raw/articles/source-name.md]
  # Опциональные сигналы качества:
  confidence: high | medium | low        # насколько хорошо подтверждены утверждения
  contested: true                        # установите, если на странице есть неразрешённые противоречия
  contradictions: [other-page-slug]      # страницы, с которыми эта конфликтует
  ---

[/code]

confidence и contested опциональны, но рекомендуются для тем со спорными или быстро меняющимися мнениями. Проверка выявляет страницы с contested: true и confidence: low для рецензирования, чтобы слабые утверждения не закреплялись молча как принятый факт вики.

Фронтматер raw/

Исходные источники ТАКЖЕ получают небольшой блок фронтматера, чтобы повторные ингестирования могли обнаруживать расхождения:

[code] --- source_url: https://example.com/article # оригинальный URL, если применимо ingested: ГГГГ-ММ-ДД sha256: <hex-дайджест содержимого под фронтматером> ---

[/code]

sha256: позволяет будущему повторному ингестированию того же URL пропустить обработку, если содержимое не изменилось, и сигнализировать об изменении, если оно изменилось. Вычисляется только по телу (всё после закрывающего ---), а не по самому фронтматеру.

Таксономия тегов

[Определите 10-20 тегов верхнего уровня для домена. Добавляйте новые теги здесь ПЕРЕД их использованием.]

Пример для AI/ML:

  • Модели: model, architecture, benchmark, training
  • Люди/Организации: person, company, lab, open-source
  • Техники: optimization, fine-tuning, inference, alignment, data
  • Мета: comparison, timeline, controversy, prediction

Правило: каждый тег на странице должен присутствовать в этой таксономии. Если нужен новый тег, сначала добавьте его сюда, затем используйте. Это предотвращает расползание тегов.

Пороговые значения страниц

  • Создавайте страницу, когда сущность/концепция встречается в 2+ источниках ИЛИ является центральной для одного источника
  • Добавляйте в существующую страницу, когда источник упоминает то, что уже освещено
  • НЕ создавайте страницу для мимолётных упоминаний, незначительных деталей или того, что вне домена
  • Разделяйте страницу, когда она превышает ~200 строк — разбивайте на подтемы с перекрёстными ссылками
  • Архивируйте страницу, когда её содержимое полностью устарело — перемещайте в _archive/, удаляйте из индекса

Страницы сущностей

Одна страница на каждую заметную сущность. Включает:

  • Обзор / что это такое
  • Ключевые факты и даты
  • Связи с другими сущностями ([[вики-ссылки]])
  • Ссылки на источники

Страницы концепций

Одна страница на каждую концепцию или тему. Включает:

  • Определение / объяснение
  • Текущее состояние знаний
  • Открытые вопросы или дискуссии
  • Связанные концепции ([[вики-ссылки]])

Страницы сравнений

Сравнительные анализы. Включают:

  • Что сравнивается и почему
  • Измерения сравнения (предпочтительно табличный формат)
  • Вердикт или синтез
  • Источники

Политика обновления

Когда новая информация конфликтует с существующим содержимым:

  1. Проверьте даты — более новые источники обычно заменяют старые
  2. Если действительно противоречиво, отметьте обе позиции с датами и источниками
  3. Отметьте противоречие во фронтматере: contradictions: [page-name]
  4. Отметьте для проверки пользователем в отчёте проверки

[code]

### Шаблон index.md

Индекс разделён по типам. Каждая запись — одна строка: вики-ссылка + сводка.

```markdown
# Индекс вики

> Каталог содержимого. Каждая страница вики перечислена под своим типом с однострочной сводкой.
> Сначала читайте это, чтобы найти релевантные страницы для любого запроса.
> Последнее обновление: ГГГГ-ММ-ДД | Всего страниц: N

## Сущности
<!-- В алфавитном порядке в пределах раздела -->

## Концепции

## Сравнения

## Запросы

[/code]

Правило масштабирования: Когда любой раздел превышает 50 записей, разделите его на подразделы по первой букве или поддомену. Когда индекс превышает 200 записей в сумме, создайте _meta/topic-map.md, который группирует страницы по темам для более быстрой навигации.

Шаблон log.md

[code] # Журнал вики

> Хронологическая запись всех действий вики. Только добавление.
> Формат: `## [ГГГГ-ММ-ДД] действие | субъект`
> Действия: ingest, update, query, lint, create, archive, delete
> Когда этот файл превышает 500 записей, произведите ротацию: переименуйте в log-ГГГГ.md, начните новый.

## [ГГГГ-ММ-ДД] create | Вики инициализирована
- Домен: [домен]
- Создана структура с SCHEMA.md, index.md, log.md

[/code]

Основные операции

1. Ингестирование

Когда пользователь предоставляет источник (URL, файл, вставку текста), интегрируйте его в вики:

Сохраните исходный источник: * URL → используйте web_extract для получения markdown, сохраните в raw/articles/ * PDF → используйте web_extract (работает с PDF), сохраните в raw/papers/ * Вставленный текст → сохраните в соответствующую поддиректорию raw/ * Называйте файл описательно: raw/articles/karpathy-llm-wiki-2026.md * Добавьте фронтматер raw (source_url, ingested, sha256 тела). При повторном ингестировании того же URL: пересчитайте sha256, сравните с сохранённым значением — пропустите, если идентично, отметьте расхождение и обновите, если отличается. Это достаточно дешёво для выполнения при каждом повторном ингестировании и ловит незаметные изменения источников.

Обсудите ключевые выводы с пользователем — что интересно, что важно для домена. (Пропускайте в автоматизированных/cron-контекстах — переходите сразу.)

Проверьте, что уже существует — просмотрите index.md и используйте search_files для поиска существующих страниц по упомянутым сущностям/концепциям. Это разница между растущей вики и кучей дубликатов.

Напишите или обновите страницы вики: * Новые сущности/концепции: Создавайте страницы только если они соответствуют пороговым значениям страниц в SCHEMA.md (2+ упоминаний в источниках или центральны для одного источника) * Существующие страницы: Добавляйте новую информацию, обновляйте факты, обновляйте дату updated. Когда новая информация противоречит существующему содержимому, следуйте Политике обновления. * Перекрёстные ссылки: Каждая новая или обновлённая страница должна ссылаться как минимум на 2 другие страницы через [[вики-ссылки]]. Проверьте, что существующие страницы ссылаются обратно. * Теги: Используйте только теги из таксономии в SCHEMA.md * Происхождение: На страницах, синтезирующих 3+ источника, добавляйте маркеры ^[raw/articles/source.md] к абзацам, утверждения которых прослеживаются до конкретного источника. * Уверенность: Для спорных, быстро меняющихся или основанных на одном источнике утверждений устанавливайте confidence: medium или low во фронтматере. Не ставьте high, если утверждение не подтверждено несколькими источниками.

Обновите навигацию: * Добавьте новые страницы в index.md в правильный раздел, в алфавитном порядке * Обновите счётчик «Всего страниц» и дату «Последнее обновление» в заголовке индекса * Добавьте запись в log.md: ## [ГГГГ-ММ-ДД] ingest | Заголовок источника * Перечислите каждый созданный или обновлённый файл в записи журнала

Сообщите, что изменилось — перечислите пользователю каждый созданный или обновлённый файл.

Один источник может вызвать обновления на 5-15 страницах вики. Это нормально и желательно — это накопительный эффект.

2. Запрос

Когда пользователь задаёт вопрос о домене вики:

Прочитайте index.md для определения релевантных страниц. ② Для вики с 100+ страницами также выполните search_files по всем .md файлам для ключевых терминов — одного индекса может быть недостаточно. ③ Прочитайте релевантные страницы с помощью read_file. ④ Синтезируйте ответ из собранных знаний. Ссылайтесь на страницы вики, из которых взяли информацию: «На основе [[page-a]] и [[page-b]]...» ⑤ Сохраните ценные ответы обратно — если ответ представляет собой существенное сравнение, глубокое погружение или новый синтез, создайте страницу в queries/ или comparisons/. Не сохраняйте тривиальные запросы — только ответы, которые было бы больно восстанавливать заново. ⑥ Обновите log.md записью о запросе и о том, был ли он сохранён.

3. Проверка

Когда пользователь просит проверить, выполнить health-check или аудит вики:

Страницы-сироты: Найдите страницы, на которые нет входящих [[вики-ссылок]] с других страниц.

[code] # Используйте execute_code для этого — программное сканирование всех страниц вики import os, re from collections import defaultdict wiki = "" # Сканировать все .md файлы в entities/, concepts/, comparisons/, queries/ # Извлечь все [[wikilinks]] — построить карту входящих ссылок # Страницы с нулём входящих ссылок — сироты

[/code]

Битые вики-ссылки: Найдите [[ссылки]], которые указывают на несуществующие страницы. ③ Полнота индекса: Каждая страница вики должна быть в index.md. Сравните файловую систему с записями индекса. ④ Валидация фронтматера: Каждая страница вики должна содержать все обязательные поля (title, created, updated, type, tags, sources). Теги должны быть в таксономии. ⑤ Устаревшее содержимое: Страницы, чья дата updated старше 90 дней по сравнению с самым новым источником, упоминающим те же сущности. ⑥ Противоречия: Страницы на одну тему с конфликтующими утверждениями. Ищите страницы, которые имеют общие теги/сущности, но содержат разные факты. Выводите все страницы с contested: true или contradictions: во фронтматере для проверки пользователем. ⑦ Сигналы качества: Перечислите страницы с confidence: low и любые страницы, которые ссылаются только на один источник, но не имеют установленного поля confidence — это кандидаты либо для поиска подтверждения, либо для понижения до confidence: medium. ⑧ Расхождение источников: Для каждого файла в raw/ с sha256: во фронтматере пересчитайте хэш и отметьте несовпадения. Несовпадения указывают на то, что исходный файл был изменён (не должно происходить — raw/ неизменяем) или был ингестирован с URL, который с тех пор изменился. Не критичная ошибка, но стоит сообщить. ⑨ Размер страницы: Отметьте страницы более 200 строк — кандидаты на разделение. ⑩ Аудит тегов: Перечислите все используемые теги, отметьте любые, отсутствующие в таксономии SCHEMA.md. ⑪ Ротация журнала: Если log.md превышает 500 записей, произведите ротацию. ⑫ Сообщите результаты с конкретными путями к файлам и предложенными действиями, сгруппированными по серьёзности (битые ссылки > сироты > расхождения источников > спорные страницы > устаревшее содержимое > проблемы стиля). ⑬ Добавьте в log.md: ## [ГГГГ-ММ-ДД] lint | Найдено N проблем

Работа с вики

Поиск

[code] # Поиск страниц по содержимому search_files "transformer" path="$WIKI" file_glob="*.md"

# Поиск страниц по имени файла
search_files "*.md" target="files" path="$WIKI"

# Поиск страниц по тегу
search_files "tags:.*alignment" path="$WIKI" file_glob="*.md"

# Недавняя активность
read_file "$WIKI/log.md" offset=<последние 20 строк>

[/code]

Массовое ингестирование

При ингестировании нескольких источников одновременно, группируйте обновления:

  1. Сначала прочитайте все источники
  2. Определите все сущности и концепции во всех источниках
  3. Проверьте существующие страницы для всех них (один проход поиска, а не N)
  4. Создайте/обновите страницы за один проход (избегает избыточных обновлений)
  5. Обновите index.md один раз в конце
  6. Напишите одну запись в журнале, охватывающую весь пакет

Архивирование

Когда содержимое полностью устарело или область домена изменилась:

  1. Создайте директорию _archive/, если её нет
  2. Переместите страницу в _archive/ с её исходным путём (например, _archive/entities/old-page.md)
  3. Удалите из index.md
  4. Обновите любые страницы, которые ссылались на неё — замените вики-ссылку на обычный текст + «(в архиве)»
  5. Запишите действие архивирования

Интеграция с Obsidian

Директория вики работает как хранилище Obsidian из коробки:

  • [[вики-ссылки]] отображаются как кликабельные ссылки
  • Графовое представление визуализирует сеть знаний
  • YAML-фронтматер поддерживает запросы Dataview
  • Папка raw/assets/ содержит изображения, на которые ссылаются через ![[image.png]]

Для лучших результатов:

  • Установите в Obsidian папку вложений на raw/assets/
  • Включите «Вики-ссылки» в настройках Obsidian (обычно включено по умолчанию)
  • Установите плагин Dataview для запросов типа TABLE tags FROM "entities" WHERE contains(tags, "company")

Если вы используете навык Obsidian вместе с этим, установите OBSIDIAN_VAULT_PATH на ту же директорию, что и путь к вики.

Obsidian Headless (серверы и машины без графического интерфейса)

На машинах без дисплея используйте obsidian-headless вместо настольного приложения. Он синхронизирует хранилища через Obsidian Sync без GUI — идеально для агентов, работающих на серверах, которые пишут в вики, пока Obsidian Desktop читает её на другом устройстве.

Настройка:

[code] # Требуется Node.js 22+ npm install -g obsidian-headless

# Вход (требуется аккаунт Obsidian с подпиской Sync)
ob login --email <email> --password '<password>'

# Создать удалённое хранилище для вики
ob sync-create-remote --name "LLM Wiki"

# Подключить директорию вики к хранилищу
cd ~/wiki
ob sync-setup --vault "<vault-id>"

# Первоначальная синхронизация
ob sync

# Непрерывная синхронизация (на переднем плане — используйте systemd для фона)
ob sync --continuous

[/code]

Непрерывная фоновая синхронизация через systemd:

[code] # ~/.config/systemd/user/obsidian-wiki-sync.service [Unit] Description=Obsidian LLM Wiki Sync After=network-online.target Wants=network-online.target

[Service]
ExecStart=/path/to/ob sync --continuous
WorkingDirectory=/home/user/wiki
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

[/code]

[code] systemctl --user daemon-reload systemctl --user enable --now obsidian-wiki-sync # Включите linger, чтобы синхронизация сохранялась после выхода: sudo loginctl enable-linger $USER

[/code]

Это позволяет агенту писать в ~/wiki на сервере, пока вы просматриваете то же хранилище в Obsidian на ноутбуке/телефоне — изменения появляются в течение секунд.

Подводные камни

  • Никогда не изменяйте файлы в raw/ — источники неизменяемы. Исправления вносятся на страницах вики.
  • Всегда сначала ознакамливайтесь — читайте SCHEMA + index + недавний лог перед любой операцией в новой сессии. Пропуск этого приводит к дубликатам и пропущенным перекрёстным ссылкам.
  • Всегда обновляйте index.md и log.md — пропуск этого приводит к деградации вики. Это навигационный хребет.
  • Не создавайте страницы для мимолётных упоминаний — следуйте пороговым значениям страниц в SCHEMA.md. Имя, появившееся один раз в сноске, не заслуживает страницы сущности.
  • Не создавайте страницы без перекрёстных ссылок — изолированные страницы невидимы. Каждая страница должна ссылаться как минимум на 2 другие страницы.
  • Фронтматер обязателен — он обеспечивает поиск, фильтрацию и обнаружение устаревания.
  • Теги должны быть из таксономии — свободные теги превращаются в шум. Сначала добавляйте новые теги в SCHEMA.md, затем используйте их.
  • Держите страницы просматриваемыми — страница вики должна читаться за 30 секунд. Разделяйте страницы длиннее 200 строк. Переносите подробный анализ на выделенные страницы глубокого погружения.
  • Спрашивайте перед массовым обновлением — если ингестирование затронет 10+ существующих страниц, сначала подтвердите объём с пользователем.
  • Производите ротацию журнала — когда log.md превышает 500 записей, переименуйте его в log-ГГГГ.md и начните новый. Агент должен проверять размер лога во время проверки.
  • Обрабатывайте противоречия явно — не перезаписывайте молча. Отмечайте оба утверждения с датами, помечайте во фронтматере, отмечайте для проверки пользователем.

Связанные инструменты

llm-wiki-compiler — это Node.js CLI, который компилирует источники в концептуальную вики с тем же вдохновением от Карпати. Он совместим с Obsidian, поэтому пользователи, желающие иметь планируемый/CLI-управляемый пайплайн компиляции, могут направить его на то же хранилище, которое поддерживает этот навык. Компромиссы: он владеет генерацией страниц (заменяет суждение агента о создании страниц) и настроен на небольшие корпуса. Используйте этот навык, когда хотите курирование с участием агента; используйте llm-wiki, когда хотите пакетную компиляцию директории источников.