OKF e o padrão LLM Wiki: o formato que decide se a IA vai citar a sua empresa

Gerencio o marketing de uma empresa de tecnologia industrial há alguns anos, e a parte do meu trabalho que mais mudou nos últimos dezoito meses não foi escrever conteúdo. Foi entender em que formato esse conteúdo precisa existir para que um sistema de IA consiga usá-lo como fonte. A maioria das empresas que conheço ainda trata isso como um detalhe técnico do time de TI. Não é. O formato em que você publica o seu conhecimento técnico determina, na prática, se o ChatGPT, o Gemini, Claude ou o Perplexity vão citar a sua empresa ou ignorá-la.

Em junho de 2026, o Google Cloud publicou uma especificação aberta chamada Open Knowledge Format, ou OKF, que coloca nome e regra em algo que vinha acontecendo de forma informal há um tempo: o padrão que muita gente já chamava de “LLM Wiki”. Para quem trabalha com GEO (a otimização de conteúdo para ser citado por motores generativos), OKF não é mais uma sigla de moda. É a primeira tentativa séria de padronizar como o conhecimento deve ser estruturado para ser consumido por agentes de IA. E isso muda a conversa sobre estratégia de citação.

Este artigo explica o que é OKF, qual a sua relação com o padrão LLM Wiki, e por que vale observá-lo de perto como estratégia de citação em IAs, com foco em quem precisa transformar expertise técnica em autoridade reconhecida por máquina.

O que é o Open Knowledge Format

O Open Knowledge Format é uma especificação aberta publicada pelo Google Cloud, no repositório knowledge-catalog, para representar conhecimento de uma forma que seja, ao mesmo tempo, legível por humanos sem ferramentas especiais e parseável por agentes de IA sem SDKs proprietários. A versão atual é a v0.1.

A ideia central é deliberadamente simples. Um conhecimento OKF é um diretório de arquivos Markdown com um cabeçalho de metadados em YAML. Não há banco de dados, não há formato binário, não há API obrigatória. Se você consegue abrir um arquivo de texto, consegue ler OKF. A própria spec resume o objetivo do formato em uma frase que vale guardar: conhecimento “escrito por pessoas, gerado por agentes, trocado entre organizações e consumido por ambos”.

Quatro propriedades definem o formato:

Legível por humanos, sem software dedicado.
Parseável por agentes de IA, sem integrações customizadas.
Versionável em Git, ou seja, com histórico e diffs rastreáveis.
Portável entre ferramentas, organizações e ao longo do tempo.

Repare no que isso resolve. A maior parte do conhecimento técnico de uma empresa industrial hoje vive em PDFs fechados, planilhas, apresentações e repositórios internos. Esse material é ilegível para um modelo de linguagem na hora em que ele precisa responder a uma pergunta. OKF propõe um formato em que o mesmo documento serve para o engenheiro ler e para o agente extrair, sem versão duplicada e sem perda de contexto.

A conexão com o padrão LLM Wiki

Antes de o Google Cloud publicar a spec, várias equipes já vinham organizando o conhecimento que queriam expor a agentes em repositórios de Markdown interligados, com cabeçalhos de metadados e links internos. Esse padrão informal ficou conhecido como “LLM Wiki”: uma wiki desenhada não para o leitor humano de uma intranet, mas para ser navegada e mantida por modelos de linguagem.

O OKF é a versão especificada desse padrão. É a diferença entre todo mundo escrever cartas com o endereço em lugares diferentes do envelope e existir uma norma dos Correios dizendo onde o destinatário vai. O padrão LLM Wiki dizia “organize seu conhecimento em Markdown estruturado para a IA”. O OKF diz exatamente quais campos são obrigatórios, quais arquivos têm função reservada, como os links devem ser escritos e o que torna um conjunto de documentos formalmente conforme.

Essa formalização importa por um motivo prático. Quando existe uma especificação, ferramentas, agentes e organizações diferentes podem assumir as mesmas convenções sem combinar nada entre si previamente. É o que permite que o conhecimento seja “trocado entre organizações”, como a spec coloca. Um agente que entende OKF consegue navegar o conhecimento de qualquer empresa que publique nesse formato, do mesmo jeito que um navegador renderiza qualquer site que siga o HTML.

Quem usa Obsidian, Notion ou qualquer base de Markdown com links internos já está, na prática, a um passo do OKF. O formato é compatível com essas ferramentas porque usa a mesma base: arquivos de texto e links. A diferença é a disciplina de metadados e a estrutura de pastas.

Semantic Unbaking: por que isso supera o RAG cego

O conceito mais útil para entender por que OKF é uma estratégia de citação, e não só de organização, é o que a documentação do formato chama de Semantic Unbaking, algo como “desembrulhar o significado”.

No modelo dominante hoje, o RAG (Retrieval-Augmented Generation), o agente de IA recebe a pergunta e sai vasculhando uma montanha de contexto bruto e desorganizado em tempo de resposta, tentando adivinhar como sintetizar uma resposta a partir de fragmentos espalhados. É um trabalho de garimpo feito na pressa, no momento em que o usuário está esperando.

OKF inverte isso. Em vez de deixar o agente sintetizar contexto disperso na hora, você entrega o conhecimento já “pré-digerido” em módulos que o agente pode usar imediatamente. Cada conceito é uma unidade fechada, com seu tipo declarado, seu resumo e sua estrutura interna. O trabalho de organização foi feito antes, por quem conhece o assunto, e não improvisado pelo modelo no instante da consulta.

Para GEO, a implicação é direta e é a mesma tese que defendo no meu artigo sobre GEO no marketing industrial: conteúdo estruturado de forma legível por máquina tem probabilidade de citação muito maior do que o mesmo conteúdo em prosa solta ou em PDF fechado. OKF é a expressão mais explícita desse princípio. Um documento que já chega “desembrulhado” para o agente exige menos esforço de interpretação, e o modelo tende a preferir, como fonte, aquilo que consegue extrair com mais confiança.

A anatomia de um documento OKF, peça por peça

Vale entender a estrutura, porque cada parte dela mapeia para um sinal que o agente usa na hora de decidir se cita ou não.

Bundle, Concept e Concept ID

A unidade de distribuição é o Bundle: um diretório com arquivos Markdown organizados em hierarquia. Cada arquivo .md é um Concept, uma unidade única de conhecimento. E cada conceito tem um Concept ID, que é simplesmente o caminho do arquivo sem a extensão .md. Um arquivo em tabelas/pedidos.md tem o ID tabelas/pedidos. Esse ID funciona como a chave do conceito dentro do grafo de conhecimento.

As duas metades de cada arquivo

Todo documento OKF é dividido em duas partes com públicos diferentes:

Componente	Formato	Função	Público primário
Frontmatter	YAML	Metadados: o tipo, o título, o resumo, a data	Agentes, para roteamento e filtragem
Body	Markdown	O conhecimento em si, com estrutura	Humanos e agentes

O frontmatter fica no topo do arquivo, entre delimitadores ---. Ele é o painel de controle do documento. Sem ele, o agente lê a prosa “às cegas”, sem saber se está diante de um procedimento a seguir, de uma métrica a consultar ou de uma especificação de produto.

O único campo obrigatório é o type. Ele identifica o tipo do conceito e é o que mais pesa no roteamento: diz ao agente que “tipo de coisa” ele está manuseando, como Playbook, Metric, Reference ou BigQuery Table. Não existe um registro central de tipos; a spec recomenda usar valores descritivos e ser permissivo com tipos desconhecidos.

Depois vêm os campos recomendados, em ordem de prioridade: title (nome legível), description (resumo em uma frase, usado em índices e snippets), resource (a URI canônica do ativo subjacente), tags (categorização cruzada) e timestamp (data da última alteração).

---
type: BigQuery Table
title: Pedidos
description: Uma linha por pedido completado pelo cliente.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [vendas, pedidos]
timestamp: 2026-06-20T00:00:00Z
---

O body é tudo que vem depois do frontmatter, e a recomendação é clara: prefira Markdown estrutural, com tabelas, listas, títulos e blocos de código, em vez de prosa corrida. A estrutura cria “âncoras” que permitem ao agente extrair o conhecimento com precisão. A spec sugere três títulos convencionais: # Schema para descrever campos e colunas, # Examples para exemplos concretos em blocos de código, e # Citations para as fontes externas que embasam as afirmações do documento.

Essa seção # Citations é a que mais interessa para quem pensa em GEO. Ela formaliza a procedência: cada afirmação verificável aponta para a fonte que a sustenta. É exatamente o sinal de confiabilidade que os modelos usam para decidir se uma fonte é citável.

Cross-linking: o conhecimento vira grafo

Os links entre conceitos são as arestas do grafo de conhecimento. A recomendação da spec é usar links absolutos relativos ao bundle, que começam com /, porque eles permanecem estáveis mesmo quando um documento é movido para outro subdiretório.

Veja a [tabela de clientes](/tabelas/clientes.md) para a chave de join.

Um detalhe importante: a semântica do relacionamento, se um conceito “depende de”, “se junta com” ou “referencia” outro, é expressa na prosa ao redor do link, não no link em si. E links quebrados são tolerados, porque representam conhecimento ainda não escrito. O formato foi desenhado para evoluir, não para travar quando está incompleto.

Arquivos reservados: index.md e log.md

Dois nomes de arquivo têm função reservada. O index.md é a listagem do diretório e habilita o que a spec chama de “progressive disclosure”: o agente vê o que está disponível antes de abrir cada documento, o que torna a navegação eficiente. O log.md é o histórico de mudanças, em ordem cronológica inversa, e é o que permite a um agente manter a base atualizada como um bibliotecário, sabendo o que mudou e quando.

Há uma exceção única: o index.md na raiz do bundle pode ter frontmatter, exclusivamente para declarar a versão com okf_version: "0.1".

Por que OKF é uma estratégia de citação, e não só de gestão de conhecimento

Aqui está o ponto central para quem pensa em marketing e GEO. OKF foi desenhado a partir da pergunta “como um agente de IA consome conhecimento da melhor forma possível”. Isso significa que o formato já embute, por construção, quase todos os sinais que sabemos que aumentam a probabilidade de citação.

Pense nas táticas que o paper de GEO de Princeton e parceiros, apresentado no KDD 2024, mediu como mais eficazes para aumentar a visibilidade em respostas de IA: referência a fontes credíveis, dados com atribuição, legibilidade e estrutura clara, voz autoritativa. O OKF operacionaliza cada uma delas como parte da norma. A seção # Citations é a atribuição de fonte. O type e a description são legibilidade e roteamento. A preferência por tabelas e listas é a estrutura extraível. O grafo de links é a autoridade temática conectada.

Há ainda um efeito que conversa diretamente com a lógica do GEO industrial. A pesquisa de GEO mostra que menções de marca e densidade de informação verificável pesam mais do que volume bruto de conteúdo. Em um nicho técnico onde a IA tem poucas fontes de qualidade, aquilo que chamei de thin source pool, publicar conhecimento em formato OKF é entregar ao modelo justamente o tipo de fonte que ele prefere e raramente encontra: estruturada, datada, atribuída e fácil de extrair. A escassez de boas fontes somada a um formato pensado para o agente é uma combinação difícil de perder.

Existe também a camada de descoberta. Para sinalizar a agentes externos quais recursos estão acessíveis, a spec menciona o arquivo llms.txt na raiz, uma convenção emergente que funciona como um “robots.txt para LLMs”, apontando o que está disponível para consumo por modelos. Publicar um bundle OKF e sinalizá-lo via llms.txt é tornar o seu conhecimento explicitamente disponível para ser citado.

Como aplicar isso no contexto industrial B2B

Para uma industria, a aplicação prática é menos sobre criar conteúdo novo e mais sobre dar forma ao que já existe. Datasheets, manuais de instalação, boletins técnicos, estudos de aplicação de campo e notas sobre certificações (ATEX, SIL, IECEx, NR-13) são exatamente o tipo de material denso em informação verificável que OKF foi feito para carregar.

O caminho de implementação que faz sentido é gradual:

Comece pelo material que já tem. Selecione a documentação técnica de maior valor e que hoje vive presa em PDF. Cada documento vira um conceito, um arquivo Markdown com frontmatter.
Declare o type de cada peça. Um guia de seleção é um Selection Guide. Uma página de certificação é uma Certification. Um estudo de caso é um Case Study. Esse rótulo é o que orienta o roteamento do agente.
Reescreva o corpo em estrutura, não em prosa de catálogo. Especificações em tabela, critérios de seleção em lista, exemplos em blocos. A resposta para a pergunta mais provável daquela seção deve aparecer logo no início dela.
Adicione a seção # Citations. Norma ABNT, publicação do IEC, documentação de certificadora. Atribuição na mesma página é sinal de E-E-A-T verificável.
Conecte os conceitos com links absolutos. O guia de seleção de um transmissor aponta para a página de certificação, que aponta para o estudo de caso. O grafo de conhecimento da sua expertise técnica começa a existir de forma navegável.
Mantenha um log.md e sinalize com llms.txt. O histórico mantém a base confiável ao longo do tempo, e o sinal de acesso a torna descobrível por agentes.

O ponto que insisto com qualquer equipe de marketing industrial é este: a autoria identificada continua sendo o filtro primário. Um bundle OKF tecnicamente perfeito, mas com conteúdo assinado por “equipe editorial”, perde para um conteúdo com estrutura mais simples assinado por um engenheiro com credenciais verificáveis. O frontmatter aceita campos extras livremente, então inclua o autor e as credenciais. O formato dá a estrutura; a procedência humana dá a confiança.

Conformidade: o checklist mínimo

A spec define que um bundle é conforme à OKF v0.1 se atender a três condições objetivas:

Todo arquivo .md não reservado tem um bloco de frontmatter YAML parseável.
Todo frontmatter tem um campo type não vazio.
Os arquivos index.md e log.md seguem suas estruturas definidas.

E uma quarta regra, que é mais filosofia do que condição: os consumidores devem ser permissivos. Um agente que lê OKF não deve falhar diante de um tipo desconhecido, de um campo opcional ausente ou de um link quebrado. Tudo além das três condições é “orientação leve”, não obrigação. Esse desenho permissivo é o que deixa a base de conhecimento crescer organicamente, sem que cada documento precise estar perfeito para ser útil.

Onde isso encaixa na sua estratégia de citação

OKF ainda é v0.1 e o ecossistema de ferramentas em volta dele está nascendo. Não é razoável tratá-lo como obrigação imediata para toda empresa. Mas é razoável, e na minha leitura recomendável, observá-lo como a direção para onde a estruturação de conhecimento para IA está indo, com o peso de ter sido publicado pelo Google Cloud.

A maneira de agir agora não é refazer todo o site no formato. É começar a pensar o seu conhecimento técnico como uma base de conceitos interligados, com metadados, atribuição e estrutura legível por máquina, em vez de páginas soltas escritas só para o leitor humano. Quem já organiza conteúdo dessa forma terá pouco trabalho para se tornar formalmente conforme quando o formato amadurecer. Quem continua publicando expertise técnica trancada em PDF vai continuar invisível para os agentes que, cada vez mais, são quem decide qual fornecedor entra na resposta antes de o comprador abrir o primeiro e-mail.

O conhecimento técnico real da sua empresa é o ativo. OKF e o padrão LLM Wiki são a forma de torná-lo citável. A janela para ocupar esse espaço, especialmente em nichos técnicos com poucas fontes boas, está aberta agora.