Google Cloud OKF: все корпоративные знания — в Markdown для ИИ-агентов

Когда ИИ-агент тонет в корпоративном хаосе

Представьте: ваш ИИ-агент получает задачу написать SQL-запрос к конкретной таблице в BigQuery. Казалось бы, что проще? Но вот он начинает рыскать по вики-страницам, которые никто не обновлял с 2023 года, копается в комментариях к коду, ищет описание схемы в Confluence, пытается разобраться в notebook-ячейках аналитика, который уволился полгода назад. Итог — либо галлюцинация, либо вопрос к человеку, которого агент, по идее, должен был заменить. Google Cloud решила, что с этим пора что-то делать.

Open Knowledge Format (OKF) — новый открытый стандарт от Google Cloud, который превращает этот зоопарк корпоративных знаний в упорядоченный набор Markdown-файлов с YAML-заголовками. Звучит скромно, но за этой скромностью скрывается попытка решить одну из самых больных проблем энтерпрайз-ИИ.

Что такое OKF и почему это не очередной велосипед

Спецификация OKF v0.1 устроена намеренно просто. Каждый документ знания — это Markdown-файл. В YAML-заголовке обязательно только одно поле: `type`. Всё остальное — `title`, `description`, `resource`, `tags`, временные метки — опционально. Тело документа — свободный Markdown. Концепты связываются между собой через обычные Markdown-ссылки, образуя граф знаний.

Эта минимализм — не лень разработчиков, а осознанное архитектурное решение. Производитель и потребитель данных полностью разделены: человек пишет документ в Obsidian, агент его читает через API, визуализатор рендерит в браузере — и всем хорошо. Никаких проприетарных форматов, никакого vendor lock-in.

Честно говоря, идея витала в воздухе давно. Андрей Карпатый несколько месяцев назад популяризировал концепцию «LLM Wiki» — структурированных текстовых баз знаний, оптимизированных под потребление языковыми моделями. Google по сути взяла этот паттерн, формализовала его и добавила корпоративной серьёзности в виде официальной спецификации на GitHub.

Проблема, которую все решали по-своему

Вот что меня реально впечатляет в этой истории — не сама технология, а диагноз, который она ставит индустрии. Сейчас каждая команда разработчиков ИИ-агентов изобретает собственный способ кормить агента контекстом. Кто-то подключает Obsidian Vault к coding-агенту. Кто-то использует файлы `AGENTS.md` или `CLAUDE.md` в корне репозитория — Anthropic, кстати, активно продвигает этот паттерн для Claude. Кто-то строит «metadata as code» репозитории на командах данных.

Каждое решение работает в своей экосистеме и категорически отказывается работать в чужой. Знания остаются заперты внутри системы, которая их создала. OKF пытается стать тем общим языком, которого не хватает.

Параллель с форматами данных очевидна: до появления Parquet каждая аналитическая система хранила данные по-своему. До JSON API каждый сервис придумывал собственный протокол обмена. OKF претендует на роль «JSON для корпоративных знаний».

Что Google уже поставляет вместе со спецификацией

Примечательно, что Google не ограничилась публикацией spec-документа и ушла в закат. Вместе с OKF выходит несколько практических инструментов.

Первый — агент обогащения для BigQuery: он сканирует датасеты и автоматически создаёт OKF-документ для каждой таблицы. Это решает конкретную боль дата-инженеров — документация к таблицам либо отсутствует, либо устарела.

Второй — статический HTML-визуализатор для просмотра OKF-бандлов в браузере. Третий — три готовых примера бандлов: для GA4 e-commerce данных, Stack Overflow и Bitcoin-датасетов. И наконец, обновлённый Knowledge Catalog от Google Cloud, который теперь умеет принимать OKF и отдавать его агентам.

Всё это лежит на GitHub с открытым кодом. Для российских разработчиков хорошая новость: GitHub доступен без VPN, спецификацию и референсные реализации можно забрать свободно. Другой вопрос, что сам Google Cloud Knowledge Catalog — платный сервис, и с оплатой российскими картами традиционно возникают сложности.

Что это значит для рынка ИИ-агентов

Я слежу за развитием ИИ-агентов уже несколько лет, и одна вещь бросается в глаза: большинство провалов агентных систем в продакшне связаны не с качеством модели, а с качеством контекста. GPT-4o и Claude 3.5 Sonnet прекрасно пишут SQL — если понимают схему данных. Они прекрасно отвечают на вопросы о продукте — если знают актуальную документацию.

Контекст — это новый код. И если код мы научились версионировать, тестировать и деплоить с помощью Git, то с корпоративными знаниями до сих пор царит феодальная раздробленность.

OKF предлагает применить к знаниям те же практики, что GitOps применил к инфраструктуре: «знания как код», хранимые в репозитории, версионируемые, проверяемые, портируемые. Это концептуально правильное направление.

Другой вопрос — сможет ли Google продавить этот стандарт как индустриальный. Microsoft уже продвигает собственные конвенции через экосистему Copilot. Anthropic де-факто стандартизировала `CLAUDE.md`. Конкуренция форматов неизбежна, и победит тот, кто наберёт критическую массу тулинга и интеграций.

Скептический взгляд

При всём уважении к идее, у меня есть вопросы. Markdown — формат для людей, и его выразительности может не хватить для сложных корпоративных онтологий. Граф знаний через обычные ссылки — это красиво, но очень примитивно по сравнению с тем, что умеют специализированные графовые базы данных.

Кроме того, самая сложная часть любой системы управления знаниями — не формат хранения, а поддержание актуальности. Агент обогащения BigQuery звучит круто, но кто будет обновлять OKF-документы, когда схема таблицы изменится? Автоматизация этого процесса — отдельная нетривиальная задача.

Тем не менее направление верное. Если OKF или что-то похожее на него станет стандартом, ИИ-агенты следующего поколения получат принципиально лучший доступ к корпоративному контексту. А значит, и результаты их работы станут значительно более предсказуемыми.