Open Knowledge Format (OKF)
Что такое Open Knowledge Format
Заголовок раздела «Что такое Open Knowledge Format»Open Knowledge Format (OKF) — открытая спецификация от Google Cloud (v0.1, июнь 2026), которая формализует паттерн LLM Wiki в портативный, интероперабельный формат. OKF — вендорно-нейтральный стандарт для представления метаданных, контекста и курированных знаний, которые нужны современным AI-системам.
В основе OKF — простая идея: знание как директория Markdown-файлов с YAML frontmatter. Без сложных схем сжатия, без рантаймов, без обязательных SDK.
Бандл OKF-документов — это:
- Просто Markdown — читается в любом редакторе, рендерится на GitHub, индексируется поиском
- Просто файлы — распространяется как tarball, хранится в git, монтируется в файловую систему
- Просто YAML frontmatter — минимальный набор полей для структурированных запросов:
type,title,description,resource,tags,timestamp
Требуется только одно обязательное поле — type. Всё остальное оставлено на усмотрение автора.
Проблема, которую решает OKF
Заголовок раздела «Проблема, которую решает OKF»В большинстве организаций знание, необходимое AI-агентам, разбросано по разрозненным системам:
- Каталоги метаданных с собственными API
- Вики, сторонние системы, общие диски
- Комментарии в коде, docstring, ячейки ноутбуков
- Головы старших разработчиков
Каждый вендор предлагает свой каталог, свой SDK, свою схему графа знаний — и ни одно знание не портативно между продуктами и организациями. Каждый строитель агентов решает одну и ту же проблему сборки контекста с нуля.
OKF решает эту проблему через формат, а не сервис: знание, которое можно производить без SDK, потреблять без интеграции, перемещать между системами и хранить в системе контроля версий.
Три принципа OKF
Заголовок раздела «Три принципа OKF»1. Минимальная опциональность
Заголовок раздела «1. Минимальная опциональность»OKF требует ровно одного поля от каждого concept-документа: type. Всё остальное (какие типы существуют, какие ещё поля включать, какие секции содержит тело) оставлено на усмотрение производителя. Спецификация определяет поверхность интероперабельности, а не модель контента.
2. Независимость производителя и потребителя
Заголовок раздела «2. Независимость производителя и потребителя»OKF чётко разделяет того, кто пишет знание, от того, кто его потребляет. Человеческий бандл может потреблять AI-агент. Бандл, сгенерированный пайплайном экспорта метаданных, может просматриваться в визуализаторе. Бандл, синтезированный одной LLM, может запрашиваться другой. Формат — контракт; инструменты на каждом конце независимо заменяемы.
3. Формат, а не платформа
Заголовок раздела «3. Формат, а не платформа»OKF не привязан к конкретному облаку, базе данных, провайдеру моделей или фреймворку агентов. Он никогда не потребует проприетарного аккаунта или SDK. Ценность формата знаний — в том, сколько сторон его понимают, а не в том, кто им владеет.
Как устроен OKF
Заголовок раздела «Как устроен OKF»Бандл OKF — это директория Markdown-файлов, каждый из которых представляет концепт (concept): таблицу, датасет, метрику, плейбук, ранбук, API. Один файл = один концепт. Путь файла — идентификатор концепта.
Каждый concept-документ содержит:
- YAML front matter — для структурированных полей (
type,title,description,tags) - Markdown тело — для всего остального (описание, примеры, примечания)
Концепты связываются обычными Markdown-ссылками, превращая директорию в граф отношений. Бандлы могут опционально включать:
index.md— для прогрессивного раскрытия при навигации агентовlog.md— для хронологии изменений (что есть и в нашей базе знаний)
Новая терминология
Заголовок раздела «Новая терминология»OKF вводит термин «концепт» (concept) вместо «страница» — это любая сущность, которую можно задокументировать: таблица БД, метрика, плейбук, API-эндпоинт. Путь к файлу служит уникальным идентификатором, что упрощает организацию и поиск.
Что Google Cloud зашиппили с релизом
Заголовок раздела «Что Google Cloud зашиппили с релизом»- Enrichment agent — обходит датасет BigQuery, создаёт OKF concept-документ для каждой таблицы и представления, затем вторым проходом LLM обогащает концепты цитатами, схемами и join-путями
- Static HTML visualizer — превращает любой OKF бандл в интерактивный граф в одном self-contained HTML-файле; не требует бэкенда
- Три sample bundles — GA4 e-commerce, Stack Overflow, Bitcoin public datasets, подготовленные reference agent
- Knowledge Catalog — Google Cloud обновил свой каталог знаний для поддержки OKF
Связь с архитектурой LLM Wiki и Second Brain
Заголовок раздела «Связь с архитектурой LLM Wiki и Second Brain»OKF — это формальная спецификация того, что в экосистеме AI-агентов уже стихийно сложилось как паттерн LLM Wiki. Наша база знаний DDPA KB по своей структуре (директория Markdown-файлов с frontmatter, index.md, log.md, cross-ссылки) следует OKF-подходу, хотя и с собственными конвенциями.
По шкале 5 уровней зрелости AI Second Brain:
- OKF соответствует Уровню 2 (LLM Wiki) — но добавляет формальную интероперабельность
- Это мост между Level 2 и Level 3: стандартные поля (
type,tags) позволяют строить автоматическую индексацию и семантический поиск поверх OKF-бандлов - Принцип «boring is beautiful» из Level 2 полностью совпадает с философией OKF
Ключевое преимущество OKF перед ad-hoc LLM Wiki: если несколько команд/проектов договорятся об OKF, их знания становятся портативными — агент из одного проекта может читать wiki другого проекта без дополнительной адаптации.
Что это значит для DDPA KB
Заголовок раздела «Что это значит для DDPA KB»Наша база знаний уже близка к OKF:
- Markdown + YAML frontmatter ✅
- Категоризация по папкам ✅
index.mdс навигацией ✅log.mdс хронологией изменений ✅- Cross-ссылки между страницами ✅
- «Материалы и источники» → соответствует
resourceв OKF ✅
Потенциальные улучшения в сторону OKF:
- Добавить поле
type:в frontmatter (напримерtype: guide,type: comparison,type: tool-review) - Унифицировать prologue frontmatter и мануальный cross-reference layout
- OKF-совместимость позволила бы не только людям, но и внешним AI-агентам легко индексировать нашу KB