LLM Wiki против Open Knowledge Format (OKF) – разбор и гайд по миграции

В июне 2026 года Команда Data Cloud из Google и выпустила спецификацию Open Knowledge Format (OKF) – открытый стандарт, который формализует подход LLM Wiki и превращает его в понятный контракт между системами.

Если у вас уже настроена работа агента поверх папки с Markdown-файлами, не стоит рассматривать OKF как чужеродный инструмент, заменяющий привычный рабочий процесс. LLM Wiki – это методология создания базы знаний, а OKF – спецификация, которая ее стандартизирует. OKF – это просто логичная стадия зрелости концепции LLM Wiki.

Чем на самом деле является LLM Wiki

Когда Андрей Карпаты в начале 2026 года опубликовал свой знаменитый gist с описанием LLM Wiki, он предложил изящную ментальную модель: «Obsidian – это IDE, LLM – программист, а вики – кодовая база».

Думаю, что все пытались вести личные базы знаний в Notion, Obsidian или Logseq, но быстро забрасывали их, не выдерживая рутины. Если меняется схема базы данных или появляется один новый документ, приходится вручную править десятки связанных страниц. Человек от этого быстро устает. Для LLM же такая работа не составляет труда.

Трехуровневая архитектура

В LLM Wiki чётко разделены три уровня:

1. Исходники (sources/): Неизменяемые входные данные (PDF-документы, SQL-скрипты, транскрипции, статьи), которые агент только читает.

2. База знаний (wiki/): Небольшие атомарные файлы Markdown с плотной сетью ссылок. Модель сама создает, обобщает и актуализирует их.

3. Управляющие файлы (index.md и log.md): Навигационные карты, которые ведут агента по графу знаний, и хронологический журнал аудита с записями о каждой загрузке, запросе и фоновой проверке.

В чем преимущество перед RAG-системами

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

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

Где кроется предел возможностей

Паттерн LLM Wiki отлично работает в изолированной среде. Но когда вы выходите за рамки работы одного пользователя или локального агента, возникают препятствия:

• Нет единой структуры: В одной базе знаний используется заголовок ## Определение, в другой – **Резюме**, в третьей – кастомные списки.

• Нет явных типов: Страница с описанием API-эндпоинта структурно ничем не отличается от страницы с бизнес-стратегией или таблицей в БД.

• Низкая переносимость: Промпты приходится затачивать под структуру каталогов конкретного проекта.

Назначение OKF и новшества версии v0.2

Спецификацию Open Knowledge Format (OKF) разработали как раз для того, чтобы решить проблему фрагментации.

OKF – это не SaaS-платформа, не облачный сервис и не СУБД. Это открытый стандарт, опирающийся на три простых правила:

• Только Markdown: Легко читать в любом текстовом редакторе, нативно поддерживает GitHub, их без проблем разбирают стандартные NLP-инструменты.

• Только файлы: Данные хранятся в обычных папках, которые можно упаковать в tar-архив, отправить в Git или пробросить в Docker-контейнер.

• Только YAML-метаданные (frontmatter): Минимальный набор полей (type, title, description, resource, tags) делает файлы доступными для поиска и запросов без чтения документа целиком.

YAML

---
type: metric
title: Monthly Active Users (MAU)
description: Уникальные аутентифицированные пользователи, совершившие хотя бы одно действие за последние 30 дней.
resource: bigquery://analytics-prod.users.active_monthly
tags: [metrics, core, retention]
---

В спецификации нет реестра схем, центрального сервера авторизации или обязательных SDK. Если агент умеет выполнять команду cat или читать файловый поток, он сможет работать с OKF.

Механизмы контроля доверия в v0.2

В версии OKF v0.1 авторы сосредоточились на базовой структуре, а в v0.2 добавили явные сигналы доверия (trust signals).

Когда документацию создает человек, за её достоверность отвечают по умолчанию. Но когда автономные агенты за ночной прогон генерируют или обновляют тысячи страниц, фактор доверия исчезает.

В OKF v0.2 эту проблему решили, добавив пять необязательных метаполей. С их помощью агенты отфильтровывают документы еще до того, как начнут читать основной текст:

1. Происхождение (generated): Показывает, как создавался документ (например, by: agent/data-catalog-v2 с временной меткой).

2. Проверка (verified): Фиксирует подтверждения от специалистов или автоматических проверок (например, by: user/data-lead, at: 2026-07-20).

3. Актуальность (stale_after): Точный срок годности данных, который предупреждает, что информацию пора проверить снова.

4. Жизненный цикл (status): Четко задает статус документа (draft, stable или deprecated).

5. Подтвержденные вычисления (Attested Computation): Отдельный тип документа (type: computation), где записан алгоритм расчета и прикреплены маркеры аттестации, подтверждающие, что вычисления выполнены верно.

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

Сравнительный анализ

Параметр	LLM Wiki	Open Knowledge Format (OKF v0.2)
Суть	Практический подход / ментальная модель	Открытая интероперабельная спецификация
Происхождение	Gist Андрея Карпаты (апрель 2026)	Google Data Cloud (v0.2, июль 2026)
Структура	Произвольная иерархия папок и заголовков	Стандартизированная структура, YAML-метаданные, строгий index.md
Типизация	Неявная (описывается в тексте статьи)	Явная (обязательное поле type в каждом документе)
Переносимость	Низкая (зависит от конкретных промптов и окружения)	Высокая (читается любым агентом, поддерживающим стандарт)
Происхождение и доверие	Неструктурированные логи (записи вручную в log.md)	Структурированные поля generated, verified, status и stale_after
Инструменты	Не требуются (работает в Obsidian, терминале, VS Code)	Не требуются (доступны утилиты CLI для валидации и визуализации)
Основная область	Личный «второй мозг», быстрые индивидуальные исследования	Корпоративные каталоги данных, межкомандный обмен, продакшн-конвейеры

Концептуальные отличия

Сравнение двух подходов подсвечивает важные компромиссы в архитектуре ИИ-систем управления знаниями.

Цикл генерации против контракта обмена

Подход LLM Wiki оптимизирует внутренний цикл создания (authoring loop). Его задача – максимально снизить процент ошибок, пока один агент добавляет источники, редактирует страницы и ведет журнал.

OKF проектировали как контракт обмена (exchange contract). Он определяет, как запаковать структурированные знания, чтобы агент Команды Б мог спокойно использовать базу данных, которую собрал агент Команды А.

Как типизация меняет поведение агентов

В нетипизированной LLM Wiki агенту при поиске информации о выручке приходится открывать и анализировать несколько файлов, чтобы понять, что перед ним: описание таблицы SQL, спецификация API или стратегическая заметка.

В OKF тип документа явно задается в метаданных:

YAML

type: metric

Считывая type: metric, агент сразу ищет обязательные атрибуты – например, calculation_query или business_owner. Если же он видит type: runbook, то переключается на поиск пошаговых инструкций. Явная типизация экономнее расходует токены и защищает от ошибочных интерпретаций.

Доверие как корпоративное требование

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

В OKF v0.2 контроль доверия сделали программным. Агент может предварительно отфильтровать файлы по метаданным:

YAML

status: stable
verified:
  - by: user/finance-lead

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

Реальные издержки стандартизации

Переход от свободного формата LLM Wiki к строгому репозиторию OKF требует дополнительных усилий:

• Обязательное заполнение метаданных: В начале каждого файла должен стоять корректный YAML-блок.

• Поддержка индекса в актуальном состоянии: Главный файл index.md обязан точно отражать пути к документам и связи между ними.

• Следование схемам: Свободные заметки приходится адаптировать под предопределенные типы сущностей.

Объективные слабые места OKF

• Ограничения формата Markdown: Хранить структурированные корпоративные метаданные в Markdown-файлах с YAML-заголовками бывает громоздко – особенно если сравнивать с классическими базами данных или специализированными API метаданных.

• Избыточность соглашений: Скептики отмечают, что OKF – это по сути просто набор привычных ключей frontmatter, который красиво оформили в виде спецификации.

• Ранняя стадия внедрения: Версия OKF v0.2 вышла в середине 2026 года, и её экосистема только формируется. Повсеместное внедрение стандарта за пределами Google Cloud – пока вопрос времени.

Так что же выбрать?

Оставайтесь на LLM Wiki, если:

• Вы ведете личную базу знаний («второй мозг»), которую обслуживает один локальный агент.

• Заметки и источники быстро меняются, а тратить время на поддержку схем не имеет смысла.

• Данные не читают сторонние команды, внешние агенты или автоматические скрипты.

Переходите на OKF, если:

• Базу данных читают и обновляют разные команды, агенты или программы.

• Системный контекст хранится вместе с кодом в Git-репозиториях.

• Нужен прозрачный аудит проверок, отслеживание устаревания и контроль статусов документации.

Гибридная модель

Выбирать только один подход не обязательно. Самая эффективная схема – рассматривать LLM Wiki как среду разработки, а OKF – как артефакт.

Как перевести LLM Wiki на OKF

Чтобы перевести существующую базу знаний формата LLM Wiki на стандарт OKF v0.2, нужно выполнить пять шагов:

Шаг 1. Аудит и классификация

Проанализируйте содержимое папки wiki/ и сопоставьте файлы со стандартными типами сущностей OKF (metric, dataset, table, runbook, api или concept).

Шаг 2. Добавление YAML-метаданных

Добавьте в начало каждого Markdown-файла заголовок по спецификации OKF.

Исходный документ LLM Wiki

Markdown

# Monthly Active Users

Эта метрика отслеживает наше основное удержание на веб- и мобильных платформах.

Рассчитывается как любой пользователь с зарегистрированной сессией за последние 30 дней.

SQL:
SELECT COUNT(DISTINCT user_id) FROM events.user_sessions WHERE session_time >= CURRENT_DATE() - INTERVAL 30 DAY

Документ по стандарту OKF v0.2

Markdown

---
type: metric
title: Monthly Active Users
description: Количество уникальных аутентифицированных пользователей с хотя бы одной сессией за последние 30 скользящих дней.
resource: bigquery://analytics-prod.events.user_sessions
tags: [metrics, core, retention, user-growth]
status: stable
stale_after: 2026-12-31
generated:
  by: agent/wiki-builder-v1
  at: 2026-07-28T10:00:00Z
verified:
  - by: user/analytics-lead
    at: 2026-07-28T10:30:00Z
---

# Monthly Active Users

Эта метрика отслеживает наше основное удержание на веб- и мобильных платформах.

## Методология расчета

```sql
SELECT COUNT(DISTINCT user_id) 
FROM events.user_sessions 
WHERE session_time >= CURRENT_DATE() - INTERVAL 30 DAY

### Шаг 3. Преобразование `index.md` в манифест OKF
Замените простой список заметок на навигационный манифест с указанием типов сущностей и путей к файлам.

```markdown
---
type: index
title: Primary Data Knowledge Index
updated_at: 2026-07-28T11:00:00Z
---

# Индекс каталога знаний

## Ключевые метрики
* [Monthly Active Users](metrics/mau.md) – `type: metric` | Статус: `stable` | Проверено

## Системные ресурсы
* [User Sessions Table](datasets/user_sessions.md) – `type: table` | Статус: `stable`

Шаг 4. Донастройка

Для документов, которые задают критические бизнес-метрики, конфигурации инфраструктуры или правила автоматизации, добавьте поля verified и stale_after.

Шаг 5. Проверка

Запустите ИИ-агента (без истории диалога и контекста вашего проекта) и укажите ему путь к обновленному каталогу. Попросите его прочитать index.md и ответить на конкретный вопрос. Если агент свободно ориентируется в базе без дополнительных наводящих промптов – миграция прошла успешно.

Повышение доступности данных для ИИ-агентов как новый стандарт

Переход к стандартизированным форматам знаний отражает важный тренд в архитектуре ПО – повышение доступности данных для ИИ-агентов (agentic accessibility).

В свое время веб-разработчики начали верстать страницы с помощью семантического HTML, ARIA-атрибутов и микроразметки schema.org, чтобы контент легко читали поисковые роботы и скринридеры. Точно так же инженеры сегодня проектируют внутреннюю документацию с расчетом на машинную обработку ИИ-агентами.

Здесь стоит развеять популярное заблуждение: формат OKF создавался не для внешней SEO-оптимизации или индексации страниц в публичном веб-поиске. Его главная задача – управление знаниями: стандартизация схем таблиц, регламентов (runbooks), метрик и системных интерфейсов между разными отделами компании.

Когда автономные агенты станут полноценными участниками рабочих процессов, с репозиториями знаний начнут работать так же, как с исходным кодом: с контролем версий, CI/CD-валидацией и сборкой в скомпилированные пакеты контекста.

Заключение

Концепция LLM Wiki доказала, что ИИ-агенты способны эффективнее людей накапливать и поддерживать контекст. В свою очередь, Open Knowledge Format дает необходимый стандарт, чтобы безопасно обмениваться этим контекстом внутри всей компании.

Вам не нужно экстренно переписывать всю документацию. Выберите пять ключевых Markdown-файлов в своем репозитории. Добавьте в них YAML-метаданные стандарта OKF (укажите type, title, description и status) и направьте нового агента на эту папку. Вы увидите, как благодаря четкой структуре разрозненные заметки превращаются в понятный и предсказуемый контекст.