Open Knowledge Format (OKF): um padrão aberto para o conhecimento que seus agentes de IA precisam

TL;DR: O Open Knowledge Format (OKF) é uma especificação aberta que padroniza o conhecimento interno em markdown com YAML frontmatter, permitindo que agentes de IA consumam informação de diferentes fontes sem adaptações. Diferente de um serviço ou SDK, OKF é um formato minimalista que vive em versionamento, lido por humanos e máquinas. Para empresas brasileiras, isso reduz o trabalho de montar contexto manualmente para cada agente, promovendo interoperabilidade entre sistemas e times.

À medida que os foundation models evoluem, a falta de contexto relevante ainda limita seu potencial, especialmente na construção de sistemas agenticos. Embora esses modelos ajudem a escrever código, resumir documentos ou analisar dados, eles precisam da informação certa para gerar resultados precisos e acionáveis.

É por isso que o Google Cloud está lançando o Open Knowledge Format (OKF), uma especificação aberta que formaliza o padrão LLM-wiki em um formato portátil e interoperável. Trata-se de um padrão neutro, amigável para agentes e humanos, para representar metadados, contexto e conhecimento curado que sistemas modernos de IA exigem.

Na versão v0.1, OKF representa o conhecimento como um diretório de arquivos markdown com YAML frontmatter, com um pequeno conjunto de convenções que permitem que wikis escritos por diferentes produtores sejam consumidos por diferentes agentes sem tradução.

Nada de esquemas complexos de compressão, novo runtime ou SDK obrigatório. Um bundle de documentos OKF é:

• Apenas markdown — legível em qualquer editor, renderizável no GitHub, indexável por qualquer ferramenta de busca.
• Apenas arquivos — empacotável como tarball, hospedável em qualquer git repo, montável em qualquer filesystem.
• Apenas YAML frontmatter — para os poucos campos estruturados que precisam ser consultáveis: type, title, description, resource, tags e timestamp.

Se você já usou Obsidian, Notion, Hugo ou qualquer um dos padrões LLM-wiki que surgiram no último ano, a estrutura vai parecer familiar. OKF formaliza as convenções mínimas para tornar esses padrões interoperáveis.

Por que o contexto fragmentado é um problema?

Na maioria das organizações, a informação que os foundation models usam é predominantemente conhecimento interno: o schema de uma tabela, o significado de uma métrica para o negócio, o runbook de um incidente, os caminhos de join entre dois sistemas, o aviso de depreciação de uma API antiga etc.

Hoje, esses átomos de conhecimento vivem em sistemas altamente fragmentados:

• Catálogos de metadados com APIs próprias.
• Wikis, sistemas de terceiros ou drives compartilhados.
• Comentários de código, docstrings ou células de notebook.
• Na cabeça de alguns engenheiros seniores.

Quando um agente de IA precisa responder "Como calculo usuários ativos semanais a partir do meu event stream?", ele precisa montar a resposta a partir dessas superfícies dispersas e mutuamente incompatíveis. Cada vendor oferece seu próprio catálogo, SDK e schema de knowledge graph, e nenhum conhecimento é facilmente portável entre produtos ou organizações.

O resultado: todo construtor de agente resolve o mesmo problema de montagem de contexto do zero, todo vendor de catálogo reinventa os mesmos data models, e o conhecimento fica preso na superfície que o criou.

Como o conhecimento pode se tornar um wiki vivo?

Times de desenvolvimento estão mudando a forma como constroem agentes de IA. Em vez de usar modelos para buscar os mesmos documentos repetidamente, você pode dar aos seus agentes uma biblioteca markdown compartilhada que se torna mais útil com o tempo. Isso permite que os agentes assumam a tarefa tediosa de ler e atualizar seus próprios arquivos, enquanto seu time cura o conteúdo e o gerencia como código.

Andrej Karpathy, pesquisador e educador renomado em IA, articula essa ideia de forma clara em seu LLM Wiki gist. "LLMs não ficam entediados, não esquecem de atualizar uma referência cruzada e podem tocar 15 arquivos de uma vez", escreve ele. A contabilidade que faz humanos abandonarem wikis pessoais é exatamente o que LLMs fazem bem.

Padrões similares de conhecimento-como-wiki continuam aparecendo sob nomes diferentes: Obsidian vaults conectados a coding agents, a família de arquivos de convenção AGENTS.md / CLAUDE.md, repositórios cheios de artefatos index.md e log.md que agentes consultam antes de fazer trabalho real, e repositórios "metadata as code" dentro de times de dados.

O padrão é atraente e poderoso, mas cada instância é artesanal. O wiki do Karpathy e o wiki do seu time e a exportação de catálogo de um vendor podem parecer iguais (markdown, frontmatter, cross-links), mas nenhum foi intencionalmente projetado para cooperar. Não há resposta acordada sobre quais campos cada documento deve carregar ou o que os nomes de arquivo significam. Como resultado, o conhecimento codificado em wikis permanece isolado dentro dos times originais, gerando esforço redundante sempre que um novo agente é construído.

O que falta é um formato, não outro serviço

A resposta para esse problema não é outro serviço de conhecimento. Você precisa de um formato, uma forma de representar conhecimento que:

• Qualquer um possa produzir, sem SDK.
• Qualquer um possa consumir, sem integração.
• Sobreviva à movimentação entre sistemas, organizações e ferramentas.
• Viva em versionamento junto com o código que descreve.
• Seja legível por humanos e parseável por agentes: o mesmo arquivo, sem camada de tradução.

Por design, OKF é esse formato.

Como o OKF funciona? O design em uma tela

Um bundle OKF é um diretório de arquivos markdown representando conceitos: qualquer coisa que você queira capturar, incluindo tabelas, datasets, métricas, playbooks, runbooks e APIs. Cada conceito é um arquivo. O caminho do arquivo é a identidade do conceito:

Copiarsales/
├── index.md
├── datasets/
│   ├── index.md
│   └── orders_db.md
├── tables/
│   ├── index.md
│   ├── orders.md
│   └── customers.md
└── metrics/
│   ├── index.md
     └── weekly_active_users.md

Cada documento de conceito tem um pequeno bloco de YAML front matter para campos estruturados e um corpo markdown para todo o resto:

Copiar---
type: BigQuery Table
title: Orders
description: One row per completed customer order.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, revenue]
timestamp: 2026-05-28T14:30:00Z
---

# Schema

| Column        | Type      | Description                              |
|---------------|-----------|------------------------------------------|
| `order_id`    | STRING    | Globally unique order identifier.        |
| `customer_id` | STRING    | FK to [customers](/tables/customers.md). |

# Joins

Joined with [customers](/tables/customers.md) on `customer_id`.

Conceitos se conectam entre si com links markdown normais, transformando o diretório em um grafo de relacionamentos mais rico que os links pai/filho implícitos no sistema de arquivos. Bundles podem incluir opcionalmente arquivos index.md (para divulgação progressiva conforme agentes navegam na hierarquia) e arquivos log.md (para histórico cronológico de mudanças).

A especificação completa v0.1 (incluindo critérios de conformidade, regras de cross-linking e o pequeno número de nomes de arquivo reservados) cabe em uma única página.

Quais são os três princípios por trás do design?

1. Minimamente opinativo. OKF exige exatamente uma coisa de cada conceito: um campo type. Todo o resto (quais tipos existem, que outros campos incluir, quais seções o corpo tem) fica a cargo do produtor. A especificação define a superfície de interoperabilidade, não o modelo de conteúdo.

2. Independência produtor/consumidor. OKF separa claramente quem escreve o conhecimento de quem o consome. Um bundle escrito à mão por um humano pode ser consumido por um agente de IA. Um bundle gerado por um pipeline de exportação de metadados pode ser navegado em um visualizador. Um bundle sintetizado por um LLM pode ser consultado por outro. O formato é o contrato; as ferramentas em cada extremidade são intercambiáveis.

3. Formato, não plataforma. OKF não está vinculado a nenhuma nuvem, banco de dados, provedor de modelo ou framework de agente específico. Nunca exigirá conta proprietária ou SDK para ler, escrever ou servir. Estamos publicando como um padrão aberto porque o valor de um formato de conhecimento vem de quantas partes o falam, não de quem o possui.

O que está sendo lançado junto com a especificação?

Para tornar o formato concreto, estamos publicando implementações de referência tanto no lado produtor quanto no consumidor:

• Um agente de enriquecimento que percorre um dataset do BigQuery, redige um documento de conceito OKF para cada tabela e view, e executa uma segunda passagem LLM que rastreia documentação oficial e enriquece cada conceito com citações, schemas e caminhos de join.
• Um visualizador HTML estático que transforma qualquer bundle OKF em uma visualização interativa de grafo em um único arquivo autocontido; sem backend, sem instalação no lado do visualizador, sem dados saindo da página.
• Três bundles de amostra prontos para navegação: datasets públicos GA4 e-commerce, Stack Overflow e Bitcoin, produzidos pelo agente de referência e commitados no repositório como exemplos vivos de OKF conforme.

Estes são provas de conceito, deliberadamente. O agente demonstra uma forma de produzir OKF; nada no formato exige um framework de agente ou LLM específico. O visualizador demonstra uma forma de consumi-lo; nada exige HTML ou visualização em grafo. Esperamos (e queremos!) que o ecossistema de produtores e consumidores cresça muito além do que lançamos.

Para onde vamos daqui?

OKF v0.1 é um ponto de partida, não um padrão finalizado. O formato evoluirá conforme mais produtores e consumidores surgirem e aprendermos coletivamente quais representações de conhecimento os agentes realmente precisam na prática.

Estamos publicando em aberto desde o primeiro dia porque essa é a única forma de um formato de conhecimento ganhar seu nome — seja você construindo um catálogo de conhecimento, um pipeline de enriquecimento, um wiki adaptado para agentes de IA ou qualquer coisa no domínio de conhecimento de IA.

A partir daqui, incentivamos você a:

• Ler a especificação (é curta!).
• Escrever um produtor para seu sistema de origem, seu banco de dados, seu site de documentação.
• Escrever um consumidor: um visualizador, um índice de busca, um agente que raciocine sobre bundles.
• Testar a implementação de referência com seus próprios dados.
• Abrir issues, enviar PRs ou propor extensões: A especificação é versionada e projetada explicitamente para crescimento compatível com versões anteriores.

O repositório, a especificação e os bundles de amostra estão disponíveis no GitHub. Também atualizamos o Knowledge Catalog do Google Cloud para ingerir o Open Knowledge Format e servi-lo aos nossos agentes. Código e exemplos estão aqui.

O formato em si é a contribuição. As ferramentas que lançamos existem para torná-lo real e reduzir o custo de experimentá-lo. Qualquer que seja a forma do seu conhecimento hoje, OKF foi projetado para ser a língua franca pela qual ele pode ser trocado amanhã.

Perguntas Frequentes

• O que é o Open Knowledge Format (OKF)?
  OKF é uma especificação aberta e neutra para representar conhecimento — como esquemas de tabelas, runbooks e definições de métricas — em arquivos markdown com YAML frontmatter. Ele foi projetado para ser produzido e consumido por humanos e agentes de IA, sem depender de SDK ou plataforma específica.

• OKF exige o uso do Google Cloud?
  Não. O formato é vendor-neutral e pode ser usado com qualquer provedor de nuvem, banco de dados ou framework de agentes. O Google Cloud publicou implementações de referência para BigQuery e Knowledge Catalog, mas o padrão em si é aberto e independente.

• Como o OKF se diferencia de wikis tradicionais ou de repositórios de markdown?
  Enquanto wikis tradicionais são silos com estruturas proprietárias, OKF define um conjunto mínimo de convenções — campos type, title, description, resource, tags, timestamp — que tornam qualquer bundle de markdown interoperável entre diferentes produtores e consumidores. Isso elimina a necessidade de tradução manual entre sistemas.

• Como começar a usar OKF na minha empresa?
  Acesse o repositório no GitHub, leia a especificação (cabe em uma página), e crie um produtor para sua fonte de dados — um script que exporte tabelas, métricas ou runbooks no formato OKF. Use o visualizador HTML de referência para navegar os bundles e integre os arquivos ao versionamento junto com o código.

---

Artigo originalmente publicado por Amir HormatiTech Lead, BigQuery, Engineering, Data Cloud, Google Cloud em Cloud Blog.