LLM Wiki: готовые baseline-шаблоны и новая реализация паттерна для доказательных выводов

Паттерн LLM Wiki (предложен Андреем Карпаты, 2026) устроен так: LLM-агент не ищет фрагменты заново при каждом вопросе, а инкрементально встраивает новые источники в постоянную вики — дополняет страницы, связывает их ссылками, отмечает противоречия и поддерживает обзор.

Типичные элементы паттерна:

• Три слоя. raw/ — неизменяемые источники (курирует владелец), wiki/ — страницы под управлением агента, AGENTS.md — схема-регламент.

• Операции. ingest (один источник каскадно обновляет 10–15 страниц), query (вопрос по вики), lint (периодическая проверка здоровья: противоречия, устаревшие утверждения, страницы-сироты).

• Навигация. index.md — каталог всех страниц; log.md — append-only журнал с разбираемым префиксом: в оригинале паттерна — ## [YYYY-MM-DD] <операция> | <заголовок>, в kbt — ## <YYYY-MM-DD HH:MM> — ingest '<файл>'.

• Obsidian как просмотрщик: graph view показывает связи, Dataview читает frontmatter, Web Clipper кладёт статьи прямо в raw/.

Baseline-реализация LLM Wiki: llm-wiki-baseline

Git-репозиторий llm-wiki-baseline ^[1] предлагает готовую baseline-реализацию паттерна: шесть папок — starter-pack шаблонов «второго мозга» под разные домены:

• управление своей работой,

• управление личной и семейной жизнью,

• управление проектом,

• управление небольшой компанией,

• управление инструментами для частных инвестиций,

• исследования.

Как начать пользоваться:

1. Подготовка:

   1. Поставьте OpenCode ^[2] (или любой другой надежный LLM-агент) и настройте доступ к LLM провайдеру

   2. Опционально поставьте Obsidian ^[3] для ввода информации и аналитики через Obsidian плагины. Для OpenCode можно поставить плагин внутри Obsidian и работать с агентом также внутри Obsidian.

2. Скопируйте себе нужную папку с вики.

3. Откройте скопированную папку через OpenCode. Готово:

• OpenCode подхватит системную инструкцию из AGENTS.md в этой папке и начнет управлять вашей вики по всем правилам паттерна LLM Wiki

• добавьте документ в папку raw/ (заметки, факты, готовые/официальные документы, диалоги, статьи и информацию из браузера), дайте агенту команду ingest: агент создаёт нужные заметки и сущности, и поддерживает связи между ними;

• для всех загруженных в raw/ документов, которые не в .md формате, агент попробует сделать преобразование в .md для загрузки

• также можно загружать как заметки информацию из Интернета

• через диалог агент создаёт нужные заметки и делает нужные правки

• с агентом можно общаться в контексте заметок — он “знает” весь необходимый контекст, понимает и поддерживает схему вики

• эту вики можно открыть в Obsidian как vault и пользоваться всеми его плюшками.

Для своей семьи я создал семейную LLM Wiki, в которой мы храним детальную информацию обо всём, что касается жизни и счастья всех членов семьи: медицинские анализы (здоровье), интересы, данные для инвентаризации: точные модели техники в доме, задания для выполнения, и т.д. и т.п. Как мы раньше жили без этого?..

Реализация LLM Wiki на схемах данных для дедуктивных выводов: llm-wiki-kbt

Baseline реализация LLM Wiki интересна и полезна. Однако следующие недостатки этой реализации обращают на себя внимание ^[4]:

• baseline реализация остаётся prose-first: знание хранится как связанные markdown-страницы, а целостность держится регламентом агента и простыми проверками, средствами самой LLM — без формальной онтологии;

• в baseline инструкциях и методологии нет “оснований”, по которым можно было бы суждения разложить на правдивые и ложные, как это обычно делается в классической логике ^[5] (см. “Учебник Логики” (Г.В. Челпанов), “Логика” (С.Н. Виноградов)). Это означает, что в какой-то момент агент может сгаллюцинировать или логика агента начнет “дрифтовать”, и в вики попадет ложная по смыслу информация. Нет никакого гарантирующего способа определить и исправить такую информацию;

• все связи – одного типа. Опыт ^[6] и практика говорят, что эффективнее различать типы связей, т.к. связь соответствует отношению, которое на практике бывает разных типов;

• на одну и ту же сущность можно смотреть под разной перспективой рассмотрения: на один и тот же вопрос или предмет химик, физик и системный администратор “смотрят” по-разному.

В итоге понятно, что baseline-реализацию нельзя использовать в областях с высокой ценой ошибки ^[7], т.к. для выводов, который делает агента, нет строгого доказательства.

Проект llm-wiki-kbt ^[8] развивает идею LLM Wiki следующим образом:

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

• вместо одного типа связи — типизированные отношения (subclassOf, partOf, instanceOf и другие)

• у каждой вики явно задана перспектива рассмотрения: цель, правило, объём и точка зрения ^[9]

• консистентность проверяют программные зонды (lint), а не LLM

• структура сущностей позволяет делать дедуктивные выводы, аналогично тому как работают reasoning engine для OWL формата представления знаний

• в специальной вики по мета-онтологии (meta_ontology) выявляются все верхнеуровневые понятия из классической Логики. Используя эти термины как базовые можно представить знания из любой области знаний, включая любые научные теории.

По сравнению с LLM Wiki baseline, в llm-wiki-kbt всего два вида записей:

• сущность (entity) — понятие с определением, атрибутами и, возможно, с дополнительным описанием при необходимости (для случаев, когда сущность на данной стадии не удается представить в виде набора существенных признаков);

• отношение (relation) между сущностями, по одному на файл: subclassOf, partOf, instanceOf, disjointWith и другие.

Каждая запись подчиняется схеме, опеределяемой в настройках вики. Для всех вики общая небольшая базовая онтология wikis/meta_ontology. Кроме того, каждая вики объявляет свою перспективу рассмотрения (perspective of consideration) — цель, объём и точку зрения, с которой будет описан предмет, а также правила рассмотрения. Системный администратор и физик описывают одно и то же по-разному, и это прямо фиксируется в настройках вики.

В результате подход в llm-wiki-kbt раскладывает текстовую информацию на консистентные сущности и отношения ровно так, как на это смотрит пользователь вики.

Рабочая цель — описать каждую сущность через её существенные атрибуты, то есть свойства, без которых она перестаёт быть собой. Когда предметная область описана так, сущность опознаётся по значениям этих атрибутов, а на логические вопросы — является ли X разновидностью Y, может ли что-то быть одновременно X и Y, что следует из Z — отвечает алгоритм. LLM читает источники и предлагает записи, но перестаёт быть единственным судьёй их правильности.

Предпологается два “уровня” строгости дедуктивных выводов:

1. вывод через обработку запросов LLM (точность/строгость не гарантирована)

2. вывод через язык дедуктивного вывода (точность/строгость гарантирована).

Также в состав llm-wiki-kbt входит библиотека для базовой визуализацию для представления графа сущностей.

Возможные применения:

• Представление информации в областях с высокой ценой ошибки, для принятия решений, которые имеют строгое доказательство.

• Оцифровка и анализ научной информации, автоматический анализ научных статей.

• Память ^[10] о предметной области для агента.

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

• Проверка сгенерированного текста — утверждения из ответа модели сверяются с отношениями в вики, противоречащие помечаются.

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

Пример вики: евклидова геометрия

На основе базовой мета-онтологии в llm-wiki-kbt можно строить доменные вики-онтологии. Самый простой пример такой онтологии — вики wikis/euclidean_geometry: 33 сущности и 116 отношений.

В ней есть примитивы — point (точка), line (прямая), plane (плоскость), и фигуры — угол, окружность, отрезок, треугольник. Есть постулаты 1–5 и общие понятия из Евклида как отдельные сущности. Есть теоремы: предложения I.1 («построение равностороннего треугольника на данном отрезке»), I.15 (вертикальные углы равны), I.32 (сумма углов треугольника) и I.47 (теорема Пифагора) — сущности с определениями.

Все они связаны отношениями: subclassOf выстраивает их в дерево классов, instanceOf помещает конкретную теорему в класс, partOf описывает композицию. Перспектива рассмотрения этой вики сформулирована прямо: «плоские фигуры изучаются аксиоматически, из небольшого набора постулатов и общих понятий, дедуктивным доказательством; точка зрения — геометр, работающий от первых принципов».

Покажем оба вида записей на реальных файлах этой вики. Сущности — point (точка) и geometric primitive (геометрический примитив, подкласс геометрического объекта):

name: point
schema: geometric_primitive_schema
kind: entity
definition: That which has no part — the primitive geometric object with position but no length, area, or volume.
description: |
  - An undefined primitive; Euclid's first definition
  - [Wikipedia: "Point (geometry)"](https://en.wikipedia.org/wiki/Point_(geometry))
essentialAttributes:
  isIdentifiedByEssentialAttributes: true
  isSpatiotemporal: false
  isIdealized: true
  isMathematicallyDescribable: true
  wikidataItemIDStack:
    point:
      ID: Q44946
meta:
  entityNamespace: geometry
accidentalAttributes:
  definitionMethodStack:
    point: implicit definition

name: geometric primitive
schema: geometric_primitive_schema
kind: entity
definition: An undefined primitive geometric object — a point, a line, or a plane — introduced without definition and governed by the postulates.
description: |
  - Primitives are the starting vocabulary of the theory
  - Their behaviour is fixed only by the postulates and common notions
  - [Wikipedia: "Foundations of geometry"](https://en.wikipedia.org/wiki/Foundations_of_geometry)
essentialAttributes:
  isIdentifiedByEssentialAttributes: true
  isSpatiotemporal: false
  isIdealized: true
  isMathematicallyDescribable: true
meta:
  entityNamespace: geometry
accidentalAttributes:
  definitionMethodStack:
    geometric primitive: implicit definition

Отношение point subclassOf geometric primitive — один факт в одном файле (relations/subclassOf/point subclassOf geometric primitive.yaml):

name: point subclassOf geometric primitive
kind: relation
schema: subclassOf_schema
domain:
  - point
range:
  - geometric primitive
superclass:
  - geometric primitive
is_correct: true

Все эти записи проверяет программа: ссылка на несуществующую сущность или нарушение схемы (см. lint), а не мнение модели.

Интерактивный граф этой онтологии можно посмотреть по этой ссылке ^[11].

Как начать пользоваться

Скопировать папку с репозиторием и открыть эту папку через LLM-агент типа OpenCode. Готово:

• OpenCode подхватит системную инструкцию из AGENTS.md в этой папке и начнет управлять вашей вики по всем правилам

• создайте новую вики командой: create_wiki <область_интереса>

• добавьте документ в папку wikis/<область_интереса>/raw/documents/, дайте агенту команду ingest: агент создаёт нужные заметки и сущности, и поддерживает связи между ними

• с агентом можно общаться в контексте сущностей и отношений и выполнять любые преобразования.

Граф мета-онтологии можно посмотреть по этой ссылке ^[12].

Оба репозитория открыты — пробуйте и давайте обсудим в комментариях.