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 или что-то похожее на него станет стандартом, ИИ-агенты следующего поколения получат принципиально лучший доступ к корпоративному контексту. А значит, и результаты их работы станут значительно более предсказуемыми.