Google revela o Open Knowledge Format, padrão de compartilhamento de conhecimento para agentes de IA

 (cloud.google.com)
5 pontos por GN⁺ 4 시간 전 | 2 comentários | Compartilhar no WhatsApp
  • Uma especificação aberta e neutra em relação a fornecedores que permite que vários agentes consumam wikis criadas por produtores diferentes sem necessidade de tradução, formalizando o padrão LLM-wiki em um formato portável e interoperável
  • O OKF v0.1 representa conhecimento como um diretório de arquivos markdown com YAML frontmatter, funcionando sem esquemas complexos de compactação, novos runtimes ou SDKs obrigatórios
  • O conhecimento interno das organizações está espalhado por sistemas fragmentados como catálogos de metadados, wikis, comentários em código e até na cabeça de alguns engenheiros sêniores, fazendo com que agentes precisem resolver do zero, toda vez, o mesmo problema de montar contexto
  • A resposta não é um novo serviço de conhecimento, mas o próprio formato, que qualquer pessoa pode produzir sem SDK, consumir sem integração e versionar junto com o código
  • Por ser publicado como padrão aberto, seu valor depende da expansão do ecossistema de produtores e consumidores

Contexto: ambiente de contexto fragmentado

  • Mesmo com a evolução dos modelos fundacionais, o desempenho continua limitado pela falta de contexto relevante, especialmente na construção de sistemas de agentes
    • Eles conseguem escrever código, resumir documentos e analisar datasets, mas precisam das informações corretas para entregar resultados precisos e acionáveis
  • As informações usadas pelos modelos dentro das organizações são, em sua maioria, conhecimento interno, como esquemas de tabelas, significado de métricas de negócio, runbooks de incidentes, caminhos de join entre dois sistemas e avisos de descontinuação de APIs antigas
  • Exemplos de sistemas onde essas unidades de conhecimento ficam dispersas
    • Catálogos de metadados com APIs próprias
    • Wikis, sistemas de terceiros e drives compartilhados
    • Comentários de código, docstrings e células de notebook
    • A cabeça de alguns engenheiros sêniores
  • Para responder a uma pergunta como “como calcular usuários ativos semanais (WAU) em um fluxo de eventos?”, o agente precisa montar a resposta a partir de superfícies incompatíveis entre si
    • Cada fornecedor oferece seu próprio catálogo, seu próprio SDK e seu próprio schema de grafo de conhecimento, e o conhecimento não é portável entre produtos nem organizações
  • Como resultado, todo criador de agentes repete o mesmo problema de montagem de contexto, fornecedores de catálogo reinventam o mesmo modelo de dados, e o conhecimento fica preso à superfície em que foi criado

Conhecimento como uma wiki viva

  • Em vez de buscar repetidamente os mesmos fatos nos mesmos documentos, equipes de desenvolvimento estão migrando para um modelo em que fornecem aos agentes uma biblioteca compartilhada em markdown que se torna mais útil com o tempo
    • Os agentes assumem o trabalho operacional de ler e atualizar seus próprios arquivos, enquanto a equipe faz a curadoria do conteúdo e o gerencia como código
  • Andrej Karpathy apresentou essa ideia no gist LLM Wiki
    • Ele descreve que “LLMs não ficam entediados, não esquecem de atualizar referências cruzadas e conseguem lidar com 15 arquivos de uma vez”
    • O trabalho de bookkeeping que faz pessoas abandonarem wikis pessoais é justamente o tipo de tarefa em que LLMs se saem bem
  • O mesmo padrão de wiki de conhecimento reaparece com vários nomes
    • Obsidian vault conectado a agentes de programação
    • Arquivos de convenção da família AGENTS.md / CLAUDE.md
    • Repositórios de artefatos como index.md e log.md, consultados por agentes antes de começar o trabalho
    • Repositórios internos de equipes de dados no estilo “metadata as code”
  • O padrão é poderoso, mas cada caso ainda é sob medida (bespoke)
    • A forma é parecida — markdown, frontmatter, links cruzados —, mas não foi projetada para colaboração
    • Não há consenso sobre quais campos cada documento deve ter nem sobre o significado dos nomes dos arquivos, então o conhecimento continua siloado dentro da equipe original e o trabalho se duplica ao construir novos agentes

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

  • A resposta não é mais um serviço de conhecimento, e sim um formato para representar conhecimento, que precisa atender aos seguintes requisitos
    • Qualquer pessoa deve poder produzi-lo sem SDK
    • Qualquer pessoa deve poder consumi-lo sem integração
    • Ele deve se preservar ao circular entre sistemas, organizações e ferramentas
    • Deve existir no controle de versão junto do código que descreve
    • Deve ser legível por humanos e analisável por agentes, usando os mesmos arquivos sem camada de tradução
  • O OKF foi projetado para atender a esses requisitos

Como o OKF funciona: um design que cabe em uma tela

  • Um bundle OKF é um diretório de arquivos markdown que representa conceitos, incluindo tudo o que se queira capturar: tabelas, datasets, métricas, playbooks, runbooks e APIs
    • Cada conceito é um arquivo, e o caminho do arquivo é a identidade do conceito
    • Exemplo de estrutura de diretório: dentro de sales, pastas datasets, tables e metrics, com arquivos como orders.md, customers.md e weekly_active_users.md
  • Cada documento de conceito é composto por um bloco de YAML front matter para campos estruturados e um corpo em markdown com o restante
    • Exemplos de campos no front matter: type (BigQuery Table), title (Orders), description, resource (URL do console), tags ([sales, revenue]), timestamp (2026-05-28T14:30:00Z)
    • O corpo pode incluir itens como Schema (colunas order_id, customer_id, com tipos e descrições), Joins (join com customers com base em customer_id) etc.
  • Os conceitos se conectam entre si por meio de links markdown comuns, transformando o diretório em um grafo mais rico do que relações pai/filho de sistema de arquivos
    • Opcionalmente, o bundle pode incluir arquivos index.md (para divulgação progressiva durante a navegação do agente) e log.md (histórico de mudanças)
  • A especificação completa da v0.1 cabe em uma página, incluindo critérios de conformidade, regras de links cruzados e um pequeno conjunto de nomes de arquivo reservados

Três princípios de design

  • Minimally opinionated

    • A única exigência que o OKF faz para todo conceito é um único campo: type
    • Quais tipos existem, quais campos adicionais usar e quais seções incluir no corpo ficam a cargo do produtor
    • A especificação define apenas a superfície de interoperabilidade, não o modelo de conteúdo

  • Independência entre produtor e consumidor

    • O formato separa com clareza quem escreve o conhecimento de quem o consome
    • Um agente de IA pode consumir bundles escritos manualmente por humanos; um visualizador pode explorar bundles gerados por pipelines de exportação de metadados; um LLM pode consultar bundles sintetizados por outro LLM
    • O formato é o contrato, e as ferramentas nas duas pontas podem ser trocadas independentemente

  • Formato, não plataforma

    • Não depende de um provedor específico de nuvem, banco de dados, modelos ou framework de agentes
    • Não exige conta proprietária nem SDK para ler, escrever ou servir
    • O valor de um formato de conhecimento não vem de quem o controla, mas de quantos participantes o utilizam, por isso ele foi publicado como padrão aberto

O que acompanha a especificação

  • Para concretizar o formato, foram publicados implementações de referência tanto do lado do produtor quanto do consumidor
  • Enrichment agent: percorre datasets do BigQuery, cria rascunhos de documentos de conceito OKF para todas as tabelas e views e depois usa uma segunda passagem com LLM para rastrear documentação oficial e enriquecer cada conceito com citações, schemas e caminhos de join
  • Visualizador HTML estático: transforma qualquer bundle OKF em uma visualização interativa em grafo contida em um único arquivo, sem necessidade de backend, sem instalação no lado do visualizador e sem que os dados saiam da página
  • Três bundles de exemplo exploráveis imediatamente: datasets públicos de GA4 e-commerce, Stack Overflow e Bitcoin, gerados pelo agente de referência e commitados no repositório como exemplos vivos de OKF válido
  • Esses itens são intencionalmente uma prova de conceito
    • O agente mostra apenas uma forma de produzir OKF e não exige nenhum framework ou LLM específico
    • O visualizador mostra apenas uma forma de consumo e não exige HTML nem visualização em grafo
    • A expectativa é que o ecossistema de produtores e consumidores cresça muito além do que foi fornecido inicialmente

Próximos passos

  • O OKF v0.1 não é um padrão finalizado, mas um ponto de partida, que deve evoluir à medida que mais produtores e consumidores surjam e que se aprenda como os agentes realmente precisam representar conhecimento
  • Seja para criar catálogos de conhecimento, pipelines de enriquecimento ou wikis para agentes de IA, tudo deve ser publicado de forma aberta desde o primeiro dia para que o formato cumpra seu propósito
  • Ações recomendadas
    • Ler a especificação (é curta)
    • Criar produtores (producers) para sistemas de origem, bancos de dados e sites de documentação
    • Criar consumidores (consumers) como visualizadores, índices de busca e agentes que raciocinam sobre os bundles
    • Aplicar a implementação de referência aos próprios dados
    • Abrir issues, enviar PRs e propor extensões (a especificação é versionada e foi desenhada para evoluir com compatibilidade retroativa)
  • O repositório, a especificação e os bundles de exemplo estão disponíveis no GitHub, e o Knowledge Catalog do Google Cloud foi atualizado para ingerir OKF e servi-lo a agentes
  • A contribuição principal é o próprio formato; as ferramentas fornecidas existem para torná-lo real e reduzir o custo de experimentação, e o OKF foi projetado para se tornar a lingua franca da troca de conhecimento no futuro

Leituras relacionadas

2 comentários

 
leothelion 1 시간 전

Talvez seja o melhor que dá para fazer para quem não conseguiu emplacar .claude e .agent.
 
GN⁺ 4 시간 전
Opiniões no Hacker News

  • Gosto da simplicidade desta especificação OKF, mas não tenho certeza se dá para expressar tudo bem como “apenas Markdown”
    Recentemente passei a me interessar por formas de expressar conceitos para que IAs possam contribuir de forma eficaz e eficiente em termos de tokens, e em geral isso significa encontrar maneiras de representar algo bem em texto sequencial semiestruturado. Mas, nesse processo, não dá para sacrificar a experiência humana de consumir a representação do conhecimento
    Especialmente se até funções tradicionalmente não ligadas a desenvolvimento precisarem contribuir, há uma boa chance de que “um formato de texto esquisito + git” pareça bem pior do que as ferramentas atuais de autoria e visualização
    Estou curioso para ver como, nos próximos anos, vão surgir padrões para expressar conhecimento semanticamente em vários tipos de domínio
    Como casos de sucesso para referência, há abordagens de diagrama como código como DBML para schema/E-R, LikeC4 para arquitetura e Mermaid. LLMs também costumam entender bem esses formatos, e dá até para ensiná-los com prompts curtos em EBNF. O importante é que eles também têm formas de visualização agradáveis para humanos, podem ser inseridos naturalmente em code block dentro de Markdown ao lado de linguagem natural, e LLMs também podem ajudar a escrever a sintaxe
    O mais difícil são coisas como planilhas complexas ou Miro, em que disposição espacial e cor carregam significado implícito. Ainda não encontrei uma boa alternativa
    Uma tentativa prática que fiz na área de engenharia de dados foi https://equalexperts.github.io/satsuma-lang/ para permitir que IA e humanos trabalhem juntos com mapeamento source-target e transformações. É uma representação textual estruturada e concisa que permite linguagem natural, além de oferecer boa visualização e ferramentas de LSP/gramática, para que agentes não precisem sair fatiando documentos grandes de forma ineficiente em tokens só para inferir linhagem, completude ou fontes indefinidas

    • OKF parece aceitável, mas está preso ao Markdown
      Um documento Markdown pode virar um documento OKF só adicionando type no YAML do topo
      E se existisse uma linguagem de grafo de conhecimento que pudesse ser usada tanto em prosa Markdown quanto dentro de blocos de código Markdown, e em qualquer lugar que aceite campos de texto?
      A linguagem minimalista https://ddot.it consegue conectar até arquivos fora do mundo Markdown, URLs e rótulos simples. Assim como OKF, é apenas um formato
      Avisando desde já: fui eu que escrevi essa especificação curta
    • Não dá para representar bem conhecimento sem um formato de grafo que mostre relações rotuladas entre entidades
    • Markdown é o formato de fato para interoperabilidade entre LLMs e humanos
      Concordo que ele não consegue expressar tudo bem, mas isso perde o ponto principal. Markdown parece vencer por ser o menor denominador comum tanto para humanos quanto para modelos de IA

  • A cada 10 anos é divertido revisitar os formatos de web semântica RDF/OWL
    Algum dia, um desses anos vai ser o ano de verdade
    https://en.wikipedia.org/wiki/Semantic_Web

  • Havia vários links quebrados no texto original, então deixo aqui o repositório
    https://github.com/GoogleCloudPlatform/knowledge-catalog
    Especificação: https://github.com/GoogleCloudPlatform/knowledge-catalog/blo...

  • Pelo que entendi, como não conseguimos enxergar além de 3 dimensões, isto é essencialmente mais um apoio para humanos
    A expectativa é que, se organizarmos isso razoavelmente bem, os agentes consigam pegar o Markdown e montar uma infraestrutura em grafo na memória, ou armazenar isso no Neo4j

  • Existe alguma variante de Markdown especificada, por exemplo CommonMark?
    Passei os olhos só nas primeiras páginas e não vi nada sobre isso, mas me parece uma parte bem importante para uma especificação

  • O que o Google anunciou no fim das contas é Markdown com front matter em YAML. Palmas para todos. E uma especificação de 15 KB para isso
    Eu seria menos sarcástico se todo mundo conseguisse parar de usar YAML no estilo “ops, errei uma indentação”

  • Como alguém que já viu muito PDF que precisou ser “traduzido” para Markdown, isso me parece uma escolha estranha
    Entendo que o objetivo principal seja facilitar o acesso por IA, mas se de qualquer forma vão treinar modelos, por que não treiná-los com um formato melhor?
    Markdown é bastante limitado e, por exemplo, nem consegue renderizar tabelas aninhadas. Se o objetivo do “conhecimento aberto” é IA, também não sei se faz sentido insistir em um formato que humanos nem necessariamente vão ler de fato

  • Gosto da abordagem. Sou muito fã de organização hierárquica do conhecimento
    Hoje considero que as abstrações de gestão de conhecimento do Claude estão quase todas quebradas. Isso fica evidente quando você tenta executar vários coders ao mesmo tempo ou precisa criar mais de 1.000 skills. Ex.: https://news.ycombinator.com/item?id=48407998

  • Vale a pena conferir barrasindustries.com/okfind/
    É uma ideia para um registro de bundles OKF