Развитие Google Open Knowledge Format до v0.2: Сигналы доверия ИИ-агентов

Когда я впервые документировал внедрение формата Open Knowledge Format от Google в статье Implementing Google's Open Knowledge Format (OKF) in Practice, главной целью было решение проблемы изоляции контекста для ИИ-агентов. Организация простых файлов Markdown в связный граф с метаданными YAML позволила агентам рекурсивно обходить узлы документации вместо использования неточного векторного поиска.

OKF v0.1 создал надежную основу: стандартный Markdown, легкие метаданные YAML (type, title, description, tags) и явные относительные ссылки.

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

Документация, написанная человеком, содержит неявную гарантию доверия — разработчик написал ее и несет ответственность за точность. Когда агент автоматически генерирует 10 000 описаний таблиц, метрик и инструкций, эта гарантия исчезает.

Для решения этой проблемы Google Cloud выпустила спецификацию Open Knowledge Format (OKF) v0.2. Это обновление вводит структурированные сигналы доверия агентов и заверенные вычисления (Attested Computations) непосредственно в метаданные YAML без нарушения обратной совместимости с v0.1.

От описания контекста к принятию решений о доверии

В OKF v0.1 метаданные YAML отвечали на описательные вопросы: Что это за узел, какие теги его описывают и куда он ведет?

OKF v0.2 вводит решающие поля (deciding fields) — метаданные, предназначенные для оценки происхождения, актуальности и авторитетности узла до того, как агент потратит токены на чтение основного текста Markdown.

Чтение полного текста тысяч узлов документации для оценки доверия требует больших вычислительных ресурсов. Вынос сигналов доверия в заголовок YAML позволяет агентам и детерминированным системам недорого отфильтровывать непроверенные, устаревшие или выведенные из эксплуатации концепты во время обхода графа.

OKF Concept Frontmatter
├── Describing Fields (v0.1)  ──> type, title, description, resource, tags
└── Deciding Fields   (v0.2)  ──> generated, verified, status, stale_after, sources

5 ключевых сигналов доверия в OKF v0.2

OKF v0.2 определяет пять стандартизированных семейств метаданных, отвечающих на важные вопросы о любом концепте знаний:

1. Происхождение (`sources`)

Вместо присвоения произвольной оценки доверия OKF v0.2 записывает исходные сигналы происхождения в массив sources. Записи могут указывать на внешнюю документацию, относительные пути внутри пакета или области баз данных, дополненные маркерами надежности (author, usage_count, last_modified).

Внутри текста конкретные утверждения ссылаются на эти источники с помощью стандартных сносок Markdown (например, [^warehouse-schema]):

sources:
  - id: warehouse-schema
    resource: https://wiki.acme.internal/data/warehouse/schemas/sales
    title: Acme Retail Warehouse Schema
    author: team:data-platform
    usage_count: 1240
    last_modified: 2026-06-15
  - id: revenue-policy
    resource: policies/revenue-recognition.md
    title: Revenue Recognition Policy (FY2026)
    author: human:jsmith@acme
    last_modified: 2026-06-15

2. Уровни доверия (`generated` против `verified`)

OKF v0.2 четко разделяет того, кто создал концепт, и того, кто его подтвердил:

generated: { by, at }: Записывает сущность-создателя (например, reference_agent/gemini-2.5-pro) и время создания.
verified: [ { by, at } ]: Записывает независимые проверки автоматическими процессами или людьми.

На основе этих полей системы выделяют три уровня доверия (Trust Tiers):

Непроверенный (Unverified): Ключ verified отсутствует.
Подтвержден машиной (Machine-Confirmed): Проверен автоматическими фоновыми инструментами (например, ночными линтерами CI/CD).
Проверен человеком (Human-Reviewed): Подтвержден человеком (например, human:kliu@acme).

generated: 
  by: reference_agent/gemini-2.5-pro
  at: 2026-06-30T14:00:00Z
verified:
  - by: human:jsmith@acme
    at: 2026-07-01T09:00:00Z

Система отчетов для руководства может фильтровать только метрики human-reviewed, тогда как тестовая среда может принимать концепты machine-confirmed.

3. Актуальность (`stale_after`)

Вместо относительных сроков TTL (например, «действителен 30 дней») OKF v0.2 использует точную дату ISO-8601 (например, stale_after: 2026-12-31).

Относительные TTL зависят от момента чтения концепта, что приводит к недетерминированному поведению агента. Точные даты позволяют использовать простое сравнение: если текущее время превышает stale_after, концепт отправляется на повторную проверку.

4. Жизненный цикл (`status`)

Концепты проходят через четкие состояния жизненного цикла: draft → stable → deprecated (по умолчанию stable).

При изменении бизнес-логики (например, обновлении формулы распределения расходов) предыдущее определение получает статус status: deprecated. Это сохраняет возможность воспроизведения старых запросов и предотвращает применение устаревших метрик к новым задачам:

type: Metric
title: Gross Margin (Legacy, pre-FY2026)
status: deprecated

Заверенные вычисления: Защита от импровизации SQL агентами

Происхождение и проверка подтверждают, что определение метрики соответствует регламенту компании. Однако когда агент вычисляет финансовый показатель (например, годовую выручку), остается риск: агент может придумать собственный SQL-запрос.

OKF v0.2 вводит новый тип концепта: Attested Computation. Он определяет как разрешенное вычисление, так и механизм проверки того, что выполненный запрос точно соответствует утвержденному определению.

      ┌─────────────────────────────────────────────────────────┐
      │               Attested Computation Node                 │
      │  - runtime: bigquery                                    │
      │  - parameters: [year]                                   │
      │  - executor: skills/run-on-bq.md                        │
      │  - attester: attesters/sql_equality.py                  │
      └──────────────────────────┬──────────────────────────────┘
                                 │
                 1. Binds declared parameters
                 2. Executes sanctioned SQL
                                 ▼
                      ┌─────────────────────┐
                      │ Execution Receipt   │
                      │ - job_id            │
                      │ - executed_sql      │
                      │ - result            │
                      └──────────┬──────────┘
                                 │
                 3. Deterministic AST verification
                                 ▼
                      ┌─────────────────────┐
                      │  Attester Verdict   │
                      │  - OK / REJECTED    │
                      └─────────────────────┘

Пример в продакшене: Заверение выручки в BigQuery

Ниже представлен узел Attested Computation в OKF v0.2 для расчета годовой выручки в BigQuery:

---
type: Attested Computation
title: Revenue for a Fiscal Year
runtime: bigquery
parameters:
  - { name: year, type: integer, required: true }
executor:
  resource: skills/run-on-bq.md
receipt: [job_id, executed_sql, result]
attester:
  resource: attesters/sql_equality.py
generated:
  by: reference_agent/gemini-2.5-pro
  at: 2026-06-30T14:00:00Z
verified:
  - by: human:jsmith@acme
    at: 2026-07-01T09:00:00Z
status: stable
stale_after: 2026-12-31
sources:
  - id: revenue-policy
    resource: policies/revenue-recognition.md
    title: Revenue Recognition Policy (FY2026)
    author: human:jsmith@acme
    last_modified: 2026-06-15
---

# Computation

```sql
SELECT
  SUM(
    CASE 
      WHEN o.currency = 'USD' THEN o.net_amount
      ELSE o.net_amount * fx.rate_to_usd
    END
  ) AS revenue_usd
FROM `acme.sales.orders` AS o
LEFT JOIN `acme.finance.fx_daily_rates` AS fx
  ON fx.currency = o.currency 
 AND fx.rate_date = DATE(o.order_ts)
WHERE o.order_status = 'delivered'
  AND DATE_DIFF(CURRENT_DATE(), DATE(o.order_ts), DAY) >= 30
  AND EXTRACT(YEAR FROM o.order_ts) = @year

Как работает заверение

Передача только заявленных параметров: Агент может передавать только объявленные параметры (@year). Он не может изменять текст SQL или добавлять собственные условия WHERE.
Квитанция об исполнении: Слой исполнения возвращает подписанную квитанцию с job_id, executed_sql и результатом (result).
Детерминированная проверка: Внешний скрипт Python (sql_equality.py) разбирает целевой SQL и executed_sql в абстрактные синтаксические деревья (AST). Если ключевые слова, соединения таблиц или условия фильтрации отличаются, проверка не проходит и результат отклоняется.

Обратная совместимость и миграция

OKF v0.2 разработан как дополняющая и полностью обратимо совместимая версия. Существующие пакеты v0.1 остаются действительными без изменений.

Основные изменения схемы:

Поле timestamp заменено на generated.at.
Разделы цитирования в тексте (# Citations) заменены структурированным массивом sources в заголовке YAML.
В обоих случаях парсеры v0.2 используют поля v0.1, если новые ключи отсутствуют.

// Резервный шаблон парсера OKF v0.2
const creationTime = frontmatter.generated?.at ?? frontmatter.timestamp;
const documentSources = frontmatter.sources ?? parseLegacyCitations(markdownBody);

Главные выводы

Спецификация Google OKF v0.2 превращает простые базы знаний Markdown в проверяемые графовые сети для ИИ-агентов:

Решение вместо описания: Метаданные в заголовке позволяют недорого фильтровать данные по уровню доверия до загрузки текста.
Явные уровни доверия: Четкое разделение generated и verified для выявления человеческих проверок на фоне автоматических.
Детерминированная актуальность: Точные даты stale_after предотвращают ошибки оценки срока службы.
Заверенные вычисления: Сочетание параметров и AST-проверки исключает галлюцинации ИИ в SQL-запросах.

Внедряя стандарты OKF v0.2, команды разработки могут безопасно масштабировать автономные процессы ИИ с сохранением строгого контроля и аудита данных.