Google stellt Open Knowledge Format vor – ein Standard zum Wissensaustausch für AI-Agenten

 (cloud.google.com)
5 Punkte von GN⁺ 3 시간 전 | 2 Kommentare | Auf WhatsApp teilen
  • Eine anbieterneutrale offene Spezifikation, mit der mehrere Agenten von verschiedenen Produzenten erstellte Wikis ohne Übersetzung nutzen können; sie formalisiert das LLM-Wiki-Muster in ein portables und interoperables Format
  • OKF v0.1 stellt Wissen als ein Verzeichnis von Markdown-Dateien mit YAML-Frontmatter dar und funktioniert ohne komplexe Komprimierungsverfahren, neue Laufzeiten oder obligatorische SDKs
  • Wissen innerhalb von Organisationen ist über fragmentierte Systeme verteilt – etwa Metadatenkataloge, Wikis, Code-Kommentare oder die Köpfe einiger Senior Engineers – sodass Agenten das gleiche Problem der Kontextzusammenstellung jedes Mal von Grund auf neu lösen müssen
  • Die Antwort ist kein neuer Wissensservice, sondern das Format selbst: Jeder kann es ohne SDK erzeugen und ohne Integration konsumieren, und es lässt sich zusammen mit Code in der Versionsverwaltung verwalten
  • Als offener Standard veröffentlicht, wird sein Wert durch die Erweiterung des Produzenten- und Konsumenten-Ökosystems bestimmt

Hintergrund: eine fragmentierte Kontextlandschaft

  • Auch wenn sich Foundation-Modelle verbessern, ist ihre Leistung – besonders beim Aufbau von Agentensystemen – durch fehlenden relevanten Kontext begrenzt
    • Code schreiben, Dokumente zusammenfassen und Datensätze analysieren können sie, doch für präzise und ausführbare Ergebnisse brauchen sie die richtigen Informationen
  • Die Informationen, die Modelle in Organisationen nutzen, sind überwiegend internes Wissen, etwa Tabellenschemata, die Bedeutung geschäftlicher Kennzahlen, Incident-Runbooks, Join-Pfade zwischen zwei Systemen oder Abkündigungen alter APIs
  • Beispiele für Systeme, in denen diese Wissenseinheiten verstreut sind
    • Metadatenkataloge mit eigener API
    • Wikis, Drittanbietersysteme, geteilte Laufwerke
    • Code-Kommentare, Docstrings, Notebook-Zellen
    • die Köpfe einiger Senior Engineers
  • Um eine Frage wie „Wie berechnet man Weekly Active Users (WAU) aus einem Event-Stream?“ zu beantworten, muss ein Agent die Antwort aus nicht kompatiblen Oberflächen zusammensetzen
    • Jeder Anbieter stellt seinen eigenen Katalog, sein eigenes SDK und sein eigenes Wissensgraph-Schema bereit, wodurch Wissen nicht zwischen Produkten und Organisationen portierbar ist
  • Das Ergebnis: Jeder Agent-Builder wiederholt dasselbe Problem der Kontextzusammenstellung, Kataloganbieter erfinden dieselben Datenmodelle neu, und Wissen bleibt in der Oberfläche eingeschlossen, in der es erzeugt wurde

Wissen als lebendiges Wiki

  • Entwicklungsteams wechseln von wiederholten Suchen nach denselben Fakten in denselben Dokumenten dazu, Agenten eine gemeinsame Markdown-Bibliothek bereitzustellen, die mit der Zeit nützlicher wird
    • Agenten übernehmen die Routinearbeit des Lesens und Aktualisierens ihrer eigenen Dateien, während Teams Inhalte kuratieren und wie Code verwalten
  • Andrej Karpathy stellte diese Idee in seinem LLM Wiki gist vor
    • Er schrieb, dass „LLMs sich nicht langweilen, nicht vergessen, Querverweise zu aktualisieren, und 15 Dateien auf einmal verarbeiten können“
    • Genau die Buchführungsarbeit (bookkeeping), die Menschen persönliche Wikis aufgeben lässt, ist etwas, worin LLMs gut sind
  • Dasselbe Wissens-Wiki-Muster taucht unter verschiedenen Namen immer wieder auf
    • ein mit Coding-Agenten verbundenes Obsidian vault
    • Konventionsdateien der Art AGENTS.md / CLAUDE.md
    • Artefaktspeicher wie index.md und log.md, auf die Agenten vor der Arbeit zugreifen
    • interne „metadata as code“-Repos von Datenteams
  • Das Muster ist mächtig, hat aber die Grenze, dass jeder Fall maßgeschneidert (bespoke) ist
    • Markdown, Frontmatter und Querverlinkungen sehen ähnlich aus, sind aber nicht für Zusammenarbeit entworfen
    • Es gibt keine Einigung darüber, welche Felder oder Dateinamen alle Dokumente haben sollten; dadurch bleibt Wissen im ursprünglichen Team siloisiert, und beim Bau neuer Agenten entsteht Doppelarbeit

Benötigt wird kein Service, sondern ein Format

  • Die Antwort ist nicht noch ein Wissensservice, sondern ein Format zur Darstellung von Wissen, das folgende Anforderungen erfüllen muss
    • Jeder muss es ohne SDK erzeugen können
    • Jeder muss es ohne Integration konsumieren können
    • Es muss beim Wechsel zwischen Systemen, Organisationen und Tools erhalten bleiben
    • Es muss zusammen mit dem beschriebenen Code in der Versionsverwaltung existieren
    • Es muss für Menschen lesbar und für Agenten parsbar sein, wobei dieselben Dateien ohne Übersetzungsschicht genutzt werden
  • OKF ist ein Format, das diese Anforderungen von Anfang an erfüllt

So funktioniert OKF: das Design auf einen Blick

  • Ein OKF-Bundle ist ein Verzeichnis von Markdown-Dateien, das Konzepte repräsentiert, also alles, was erfasst werden soll – Tabellen, Datensätze, Kennzahlen, Playbooks, Runbooks, APIs usw.
    • Jedes Konzept ist eine einzelne Datei, und der Dateipfad ist die Identität des Konzepts
    • Beispiel für die Verzeichnisstruktur: Unter sales liegen die Ordner datasets, tables, metrics sowie Dateien wie orders.md, customers.md, weekly_active_users.md
  • Jedes Konzeptdokument besteht aus einem YAML-Frontmatter-Block für strukturierte Felder und einem Markdown-Hauptteil für den Rest
    • Beispiele für Frontmatter-Felder: type (BigQuery Table), title (Orders), description, resource (Konsolen-URL), tags ([sales, revenue]), timestamp (2026-05-28T14:30:00Z)
    • Im Hauptteil können etwa Schema-Angaben (order_id, customer_id mit Typen und Beschreibungen) sowie Joins (Join auf customers über customer_id) stehen
  • Konzepte sind über normale Markdown-Links miteinander verbunden und verwandeln das Verzeichnis in einen Graphen, der reichhaltiger ist als reine Eltern/Kind-Beziehungen im Dateisystem
    • Ein Bundle kann optional die Dateien index.md (für progressive Offenlegung bei der Agenten-Navigation) und log.md (Änderungsverlauf) enthalten
  • Die vollständige Spezifikation von v0.1 passt auf eine Seite und umfasst Konformitätskriterien, Regeln für Querverlinkungen und einige reservierte Dateinamen

Drei Prinzipien des Designs

  • Minimally opinionated

    • Das Einzige, was OKF für alle Konzepte verlangt, ist das Feld type
    • Welche type-Werte es gibt, welche zusätzlichen Felder verwendet werden und welche Abschnitte im Hauptteil stehen, bleibt den Produzenten überlassen
    • Die Spezifikation definiert nur die Interoperabilitätsoberfläche, nicht das Inhaltsmodell

  • Producer/consumer independence

    • Die Instanz, die Wissen schreibt, und die Instanz, die es konsumiert, werden sauber voneinander getrennt
    • Von Menschen manuell geschriebene Bundles können von AI-Agenten konsumiert werden, von Metadaten-Exportpipelines erzeugte Bundles in einem Visualisierer durchsucht werden, und ein von einem LLM synthetisiertes Bundle kann von einem anderen LLM abgefragt werden
    • Das Format ist der Vertrag; Tools an beiden Enden lassen sich unabhängig austauschen

  • Format, not platform

    • Es ist nicht an eine bestimmte Cloud, Datenbank, einen Modellanbieter oder ein Agent-Framework gebunden
    • Für Lesen, Schreiben und Serving sind weder proprietäre Accounts noch SDKs erforderlich
    • Der Wert eines Wissensformats entsteht nicht aus Besitz, sondern daraus, wie viele Akteure es verwenden; deshalb wird es als offener Standard veröffentlicht

Was zusammen mit der Spezifikation geliefert wird

  • Um das Format greifbar zu machen, wurden Referenzimplementierungen sowohl für Produzenten als auch für Konsumenten veröffentlicht
  • Enrichment agent: Durchläuft BigQuery-Datensätze, erstellt Entwürfe von OKF-Konzeptdokumenten für alle Tabellen und Views und reichert anschließend in einem zweiten LLM-Durchlauf jedes Konzept mit Zitaten, Schemata und Join-Pfaden an, indem offizielle Dokumentation gecrawlt wird
  • Statischer HTML-Visualisierer: Wandelt ein beliebiges OKF-Bundle in eine interaktive Graph-Ansicht als eigenständige Ein-Datei-Ausgabe um; kein Backend nötig, keine Installation auf Seiten des Betrachters, und die Daten verlassen die Seite nicht
  • Drei sofort erkundbare Beispiel-Bundles: für GA4 E-Commerce, Stack Overflow und den öffentlichen Bitcoin-Datensatz; vom Referenzagenten erzeugt und als lebendige, passende Beispiele für OKF ins Repository eingecheckt
  • Diese sind bewusst Proofs of Concept
    • Der Agent zeigt nur eine Möglichkeit der OKF-Erzeugung und setzt weder ein bestimmtes Framework noch ein bestimmtes LLM voraus
    • Der Visualisierer zeigt nur eine Möglichkeit des Konsums und setzt weder HTML noch eine Graph-Ansicht voraus
    • Erwartet wird, dass das Produzenten- und Konsumenten-Ökosystem weit über das Gelieferte hinaus wächst

Ausblick

  • OKF v0.1 ist kein fertiger Standard, sondern ein Ausgangspunkt, der sich weiterentwickelt, wenn mehr Produzenten und Konsumenten entstehen und man lernt, welche Wissensrepräsentationen Agenten tatsächlich brauchen
  • Ob Wissenskatalog, Enrichment-Pipeline oder Wiki für AI-Agenten – was auch immer gebaut wird, es sollte vom ersten Tag an offen veröffentlicht werden, damit das Format seinem Namen gerecht wird
  • Empfohlene Schritte
    • Die Spezifikation lesen (kurz)
    • Produzenten (producer) für Quellsysteme, Datenbanken und Dokumentationsseiten schreiben
    • Konsumenten (consumer) wie Viewer, Suchindizes oder Agenten schreiben, die auf Bundles schlussfolgern
    • Die Referenzimplementierungen auf eigene Daten anwenden
    • Issues eröffnen, PRs senden, Erweiterungen vorschlagen (die Spezifikation ist versioniert und auf rückwärtskompatibles Wachstum ausgelegt)
  • Repository, Spezifikation und Beispiel-Bundles sind auf GitHub öffentlich verfügbar, und Google Clouds Knowledge Catalog wurde so aktualisiert, dass er OKF aufnimmt und an Agenten ausliefert
  • Der eigentliche Beitrag ist das Format; die bereitgestellten Tools dienen dazu, das Format in die Praxis zu bringen und die Einstiegskosten zu senken; OKF ist als lingua franca für künftigen Wissensaustausch konzipiert

Verwandte Beiträge

2 Kommentare

 
leothelion 1 시간 전

So etwas wie die beste Option für diejenigen, die weder .claude noch .agent nutzen konnten, oder?
 
GN⁺ 3 시간 전
Hacker-News-Kommentare

  • Mir gefällt die Einfachheit dieser OKF-Spezifikation, aber ich bin nicht sicher, ob sich wirklich alles gut als „einfach nur Markdown“ ausdrücken lässt
    In letzter Zeit interessiert mich, wie man Konzepte so ausdrücken kann, dass AI effektiv und tokeneffizient gemeinsam daran mitwirken kann, und meist geht es darum, einen Weg zu finden, etwas gut in halbstrukturiertem sequentiellem Text auszudrücken. Dabei darf man aber nicht die Erfahrung opfern, Wissen für Menschen lesbar darzustellen
    Gerade wenn auch Rollen beitragen sollen, die traditionell keine Entwickler sind, dürfte sich „seltsames Textformat + git“ deutlich schlechter anfühlen als die heutigen Autoren- und Visualisierungstools
    Ich bin gespannt, wie in den nächsten Jahren Standards entstehen werden, um verschiedene Arten von Wissen semantisch auszudrücken
    Als erfolgreiche Beispiele, an denen man sich orientieren kann, gibt es DBML für Schema/E-R, LikeC4 für Architektur und diagram-as-code-Ansätze wie Mermaid. LLMs verstehen solche Formate in der Regel auch gut, und man kann sie ihnen sogar mit einem kurzen EBNF-Prompt beibringen. Wichtig ist, dass sie auch gut lesbare Visualisierungen für Menschen haben, sich in Markdown als code block direkt neben natürlicher Sprache einfügen lassen und LLMs beim Schreiben der Syntax helfen können
    Schwieriger sind Dinge wie komplexe Tabellen oder Miro, bei denen räumliche Anordnung und Farben implizite Bedeutung tragen. Dafür habe ich noch keine gute Alternative gefunden
    Ein eigener Versuch im Bereich Data Engineering ist https://equalexperts.github.io/satsuma-lang/, damit AI und Menschen gemeinsam Source-Target-Mappings und Transformationen bearbeiten können. Es ist eine kompakte strukturierte Textdarstellung, die natürliche Sprache erlaubt, und bietet zugleich gute Visualisierungen sowie LSP-/Syntax-Tools, damit Agenten nicht große Dokumente tokenineffizient zerschneiden müssen, um über Lineage, Vollständigkeit oder undefinierte Quellen nachzudenken

    • OKF sieht ordentlich aus, ist aber an Markdown gebunden
      Ein Markdown-Dokument kann durch Hinzufügen von type im vorderen YAML zu einem OKF-Dokument werden
      Wie wäre es mit einer Knowledge-Graph-Sprache, die auch in Markdown-Prosa oder in Markdown-Codeblöcken nutzbar ist und überall dort eingesetzt werden kann, wo es Textfelder gibt?
      In der minimalistischen Sprache https://ddot.it lassen sich auch Dateien außerhalb der Markdown-Welt, URLs und einfache Labels verknüpfen. Genau wie OKF ist es einfach nur ein einziges Format
      Der Vollständigkeit halber: Diese kurze Spezifikation habe ich geschrieben
    • Ohne ein Graphformat, das beschriftete Beziehungen zwischen Entitäten zeigt, lässt sich Wissen nicht gut ausdrücken
    • Markdown ist das De-facto-Format für die Interoperabilität zwischen LLMs und Menschen
      Ich stimme zu, dass sich damit nicht alles gut ausdrücken lässt, aber das geht am Kern vorbei. Markdown gewinnt offenbar, weil es der kleinste gemeinsame Nenner für Menschen und AI-Modelle ist

  • Es macht Spaß, sich alle zehn Jahre wieder RDF/OWL-Semantic-Web-Formate anzusehen
    Irgendwann wird eines dieser Jahre das echte Jahr sein
    https://en.wikipedia.org/wiki/Semantic_Web

  • Im Originaltext gibt es mehrere kaputte Links, daher lasse ich das Repository hier
    https://github.com/GoogleCloudPlatform/knowledge-catalog
    Spezifikation: https://github.com/GoogleCloudPlatform/knowledge-catalog/blo...

  • So wie ich es verstehe, ist das im Wesentlichen eher ein Sprungbrett für Menschen, weil wir über drei Dimensionen hinaus nicht sehen können
    Wenn wir die Dinge halbwegs gut organisieren, hoffe ich, dass Agenten das Markdown nehmen und entweder eine Graph-Infrastruktur im Speicher aufbauen oder es in Neo4j speichern können

  • Ist eine Variante von Markdown festgelegt, zum Beispiel CommonMark?
    Beim schnellen Überfliegen der ersten paar Seiten habe ich dazu nichts gesehen, aber für eine Spezifikation wirkt das ziemlich wichtig

  • Was Google veröffentlicht hat, ist letztlich Markdown mit YAML-Frontmatter. Bitte Applaus. Dafür eine 15-KB-Spezifikation
    Ich wäre weniger sarkastisch, wenn alle aufhören würden, YAML zu benutzen nach dem Motto „ups, eine Einrückung vergessen“

  • Als jemand, der viele PDFs gesehen hat, die nach Markdown „übersetzt“ werden mussten, wirkt das wie eine seltsame Wahl
    Ich verstehe, dass das Hauptziel wohl ein leichterer Zugriff für AI ist, aber wenn man Modelle sowieso trainieren will, frage ich mich, warum man sie nicht gleich mit einem besseren Format trainiert
    Markdown ist ziemlich eingeschränkt und kann zum Beispiel verschachtelte Tabellen nicht rendern. Wenn der Zweck von „offenem Wissen“ AI ist, weiß ich auch nicht, ob man überhaupt ein Format verwenden sollte, das Menschen tatsächlich lesen sollen

  • Mir gefällt der Ansatz. Ich mag hierarchische Wissensorganisation sehr
    Ich halte Claudes aktuelle Wissensmanagement-Abstraktion derzeit für fast vollständig kaputt. Das zeigt sich, wenn man mehrere Coder gleichzeitig laufen lässt oder mehr als 1.000 Skills anlegen muss. Beispiel: https://news.ycombinator.com/item?id=48407998

  • Es lohnt sich, barrasindustries.com/okfind/ anzusehen
    Das ist eine Idee für ein OKF-Bundle-Register