From db3ddc9638f4349f4be230b43737813bebea8fff Mon Sep 17 00:00:00 2001 From: Hector-Bot Date: Tue, 16 Jun 2026 13:52:24 +0200 Subject: [PATCH] =?UTF-8?q?ingest(blog)+wiki(concepts/llm):=20OKF=20v0.1?= =?UTF-8?q?=20=E2=80=94=20Google=20formalisiert=20LLM-Wiki-Pattern?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Pit-Share in OME Topic 13 #6697 (Reddit-Post r/WebAfterAI). OKF v0.1 ist die offizielle Spezifikation des Musters, das wir bereits umsetzen. Neue Konzeptseite open-knowledge-format-okf.md mit Frontmatter-Schema, Bundle-Struktur, 3 Workflows, Citations-Konvention, Versioning. Cross-Ref in llm-knowledge-base.md + index/log Updates. --- ..._okf-google-cloud-open-knowledge-format.md | 147 +++++++++++++++ wiki/concepts/llm/llm-knowledge-base.md | 8 +- .../concepts/llm/open-knowledge-format-okf.md | 178 ++++++++++++++++++ wiki/index.md | 3 +- wiki/log.md | 60 ++++++ 5 files changed, 392 insertions(+), 4 deletions(-) create mode 100644 raw/blog/2026-06-16_okf-google-cloud-open-knowledge-format.md create mode 100644 wiki/concepts/llm/open-knowledge-format-okf.md diff --git a/raw/blog/2026-06-16_okf-google-cloud-open-knowledge-format.md b/raw/blog/2026-06-16_okf-google-cloud-open-knowledge-format.md new file mode 100644 index 0000000..a973bad --- /dev/null +++ b/raw/blog/2026-06-16_okf-google-cloud-open-knowledge-format.md @@ -0,0 +1,147 @@ +--- +type: blog +source_url: https://www.reddit.com/r/WebAfterAI/comments/1u6mge2/google_cloud_just_released_okf_think_mcp_but_for/ +retrieved: 2026-06-16 +title: "Google Cloud just released OKF. Think MCP, but for knowledge instead of tools and 3 ways to use it." +author: "u/OnshapePTC (PTC)" +subreddit: r/WebAfterAI +score: null +tags: [okf, google-cloud, open-knowledge-format, llm-wiki, karpathy, knowledge-base, mcp, agent-knowledge] +okf_announcement: https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing +okf_spec: https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md +okf_repo: https://github.com/GoogleCloudPlatform/knowledge-catalog +pit_share_ome_topic: 13 +pit_share_message_id: 6697 +--- + +# Google Cloud just released OKF. Think MCP, but for knowledge instead of tools + +> **Pit-Share:** OME Topic 13 #6697, 2026-06-16 11:48 UTC +> **Pit-Kommentar:** Pit hat den Reddit-Link ohne zusätzlichen Kommentar geteilt — drei 🚨🔥👉-Marker in seiner bisherigen Pit-Kommunikation signalisieren "relevantes neues Wissen, sofort wikifyen". +> **Primärquellen:** +> - Reddit-Post: https://www.reddit.com/r/WebAfterAI/comments/1u6mge2/google_cloud_just_released_okf_think_mcp_but_for/ +> - Google Cloud Blog: https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing +> - OKF SPEC v0.1: https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md +> - Knowledge Catalog Repo: https://github.com/GoogleCloudPlatform/knowledge-catalog + +## Warum das Pit interessiert (unsere direkte Relevanz) + +**Unser RamaDama-Repo (knowledge-base) ist exakt nach dem Muster aufgebaut, das OKF jetzt formalisiert.** Die `AGENTS.md` zitiert Karpathys [LLM-Wiki-Gist](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f) als konzeptuelle Grundlage, und unsere Frontmatter-Standards (siehe `AGENTS.md` Section "Frontmatter Standards") sind strukturell kompatibel mit OKF. Pit hat in den letzten Wochen intensiv an der Wiki-Wartung gearbeitet — eine offizielle Standardisierung dieser Pattern durch Google ist für uns **direkt wertvoll**: Validierung + potentieller Konvergenzpunkt für Tooling + potentiell Migrationspfad zu mehr Provider-Support. + +## TL;DR (Reddit-Post v0.1-Zusammenfassung) + +OKF ist **kein Runtime, kein SDK, kein Agent-Framework, kein MCP-Konkurrent.** MCP ist ein Protokoll, mit dem Agenten Tools aufrufen und Aktionen ausführen. OKF ist das **gegenüberliegende Ende**: eine Konvention, wie man statisches Wissen aufschreibt, damit jeder Agent es lesen kann. + +**In einem Bildschirm:** +- **Was:** Konvention für statisches Wissen als Directory aus Markdown-Dateien + YAML-Frontmatter +- **Nicht:** Runtime, SDK, Framework, MCP-Konkurrent +- **Vergleichbar mit:** Obsidian, Notion, Hugo, allen LLM-Wiki-Patterns der letzten 12 Monate +- **Differenz:** OKF pinnt die nötigen Konventionen fest, damit **verschiedene Tools das gleiche Bundle lesen** können ohne Translation-Layer + +## Was ist ein "Bundle"? + +``` +my_bundle/ +├── index.md # optional: directory listing for progressive disclosure +├── log.md # optional: chronological history of changes +├── datasets/ +│ └── sales.md +└── tables/ + ├── orders.md + └── customers.md +``` + +Jedes `.md`-File = ein **"Concept"**. Concepts verlinken sich gegenseitig via Standard-Markdown-Links. Das ganze Bundle ist ein **Graph von Beziehungen**. + +## Drei Designprinzipien (Google Cloud Blog) + +1. **Minimally opinionated.** OKF verlangt **genau eine Sache** pro Concept: ein `type`-Feld. Alles andere (welche Types existieren, welche weiteren Felder, welche Body-Sections) bleibt dem Producer überlassen. Die Spec definiert die **Interoperabilitäts-Oberfläche**, nicht das Content-Model. +2. **Producer/Consumer independence.** Wer schreibt und wer liest sind sauber getrennt. Bundle von Menschen hand-geschrieben → von AI-Agent konsumiert. Bundle von Metadata-Export-Pipeline generiert → in Visualizer gebrowst. Bundle von einem LLM synthetisiert → von einem anderen abgefragt. **Format = Vertrag; Tooling an beiden Enden unabhängig austauschbar.** +3. **Permissive Conformance.** Consumers MÜSSEN unbekannte Types, fehlende Felder und broken Links tolerieren statt das Bundle abzulehnen. OKF soll nutzbar bleiben, wenn Bundles wachsen, refaktoriert oder teilweise von Agenten generiert werden. + +## Was ein Concept tragen muss (aus SPEC.md) + +### Frontmatter + +**Pflicht:** +- `type` — kurzer String, identifiziert die Art des Concepts. Consumers nutzen es für Routing, Filter, Darstellung. Beispiele: `BigQuery Table`, `BigQuery Dataset`, `API Endpoint`, `Metric`, `Playbook`, `Reference`. + +**Empfohlen (in Prioritäts-Reihenfolge):** +- `title` +- `description` +- `resource` +- `tags` +- `timestamp` + +Type-Werte sind **nicht zentral registriert**. Producers SOLLEN deskriptive/self-explanatory Werte wählen; Consumers MÜSSEN unbekannte Types graceful behandeln (typischerweise als generic concepts). + +### Citations (Section 8) + +Wenn ein Concept-Body Claims aus externem Material macht, sollten diese unter `# Citations` Heading am Dokumentende gelistet sein, nummeriert. Citation-Links können absolute URLs, bundle-relative Pfade oder Pfade in `references/`-Subdirectory sein, das externes Material als first-class OKF Concepts spiegelt. + +## Conformance-Regel (Section 9) + +Ein Bundle ist OKF v0.1 konform wenn: +- Jedes non-reserved `.md`-File hat einen parseable YAML-Frontmatter-Block +- Jeder Frontmatter-Block hat ein non-empty `type` Feld +- `index.md` und `log.md` sind die einzigen erlaubten Frontmatter-Dateien (reserviert) + +Alle anderen Constraints sind **soft guidance**. Consumers dürfen ein Bundle NICHT ablehnen wegen: unbekannter Types, fehlender `index.md`. **Permissive consumption model is intentional.** + +## Versioning (Section 11) + +- Document spezifiziert OKF version 0.1 +- Künftige Revisionen: `.`-Format +- Bundles KÖNNEN OKF-Version im bundle-root `index.md` Frontmatter deklarieren via `okf_version: "0.1"` +- Consumers, die deklarierte Version nicht verstehen, SOLLEN best-effort consumption versuchen statt das Bundle abzulehnen + +## Drei Wege, OKF zu nutzen (Reddit-Post-Highlights) + +> "How to pick if you only try one: Start with workflow 1. Hand-author a five-file bundle for one messy corner of your system and point your agent at it. It takes ten minutes, it is just markdown, and it shows you the actual value (and the actual limits) before you invest in generating or consuming at scale." + +### Workflow 1: Hand-author a small bundle +Manuell 3-5 Markdown-Files für eine "messy Ecke" des Systems schreiben, Agent drauf zeigen. Schnellster Einstieg, zeigt Wert und Limits in 10 Minuten. + +### Workflow 2: Generate from existing schema +Wenn Schema zu groß zum Hand-Schreiben ist: Pipeline, die bestehende Strukturen (DB-Schemas, API-Specs, Notion-Wikis) als OKF-Bundle exportiert. **Achtung:** Disziplin für Citations nötig, sonst verliert das Bundle an Wert. + +### Workflow 3: Consume a bundle without blowing your context window +Große Bundles komplett in den Context zu laden ist teuer und noisy. OKFs Antwort: **optional `index.md`** — plain directory listing (ohne Frontmatter), das dem Agent zeigt, was existiert. Agent liest Index, folgt Links, zieht einzelne Concepts on-demand. + +## Google Cloud Knowledge Catalog Update + +Google Cloud hat den **Knowledge Catalog** aktualisiert, um OKF zu ingestieren und an Agents auszuliefern. Drei ready-to-browse Sample Bundles werden mitgeliefert: +- **GA4 e-commerce** — [Google Analytics BigQuery Demo Dataset](https://developers.google.com/analytics/bigquery/web-ecommerce-demo-dataset) +- **Stack Overflow** — [Pantheon Marketplace](https://pantheon.corp.google.com/marketplace/product/stack-exchange/stack-overflow) +- **Bitcoin public datasets** — [BigQuery Public Datasets](https://cloud.google.com/blog/topics/public-datasets/bitcoin-in-bigquery-blockchain-analytics-on-public-data) + +Diese Bundles werden vom **Reference Agent** produziert und im Repo als lebende Beispiele konformen OKFs committed. + +## Relationship to other formats (Section 10) + +OKF ist absichtlich nahe an mehreren etablierten Patterns: +- **Karpathy LLM-Wiki** — gleiche Grundidee (raw → LLM → wiki → Q&A) +- **Obsidian / Notion / Hugo** — Markdown-First-Ansatz +- **AGENTS.md** — Schema-on-Read für AI-Agent-Konsum +- **CLAUDE.md** — Agent-Kontext-Konvention + +OKF unterscheidet sich primär durch **Spezifikation** — pinnt die nötige Regelmenge fest für Interoperabilität, ohne Tooling zu diktieren. + +## Konkrete nächste Schritte für uns + +1. **Schema-Review:** Stimmt unser AGENTS.md-Frontmatter-Schema mit OKF v0.1 überein? (`type` als Pflichtfeld, `title`/`description`/`tags` empfohlen — check ✅) +2. **`# Citations`-Section einführen:** Optional, aber OKF-Standard. Citations am Ende jedes Wiki-Pages mit nummerierten Links. +3. **`okf_version: "0.1"` in root-index.md** deklarieren (einzige Stelle, wo `index.md` Frontmatter haben darf). +4. **Producer/Consumer-Trennung prüfen:** Ist unsere Wiki-Pipeline wirklich sauber getrennt? Raw → Subagent-Prozessor → Wiki. Ja, das passt. +5. **Tooling-Optionen evaluieren:** Reference Implementation unter [github.com/GoogleCloudPlatform/knowledge-catalog](https://github.com/GoogleCloudPlatform/knowledge-catalog) — Lint-Tools, Bundle-Generators, Visualizer. Beobachten. + +## Externe Primärquellen + +- **Google Cloud Blog (Ankündigung):** https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing +- **OKF SPEC v0.1:** https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md +- **OKF Reference Implementation:** https://github.com/GoogleCloudPlatform/knowledge-catalog +- **Karpathy LLM-Wiki Gist (Original-Idee):** https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f +- **Search Engine Journal Coverage:** https://www.searchenginejournal.com/google-cloud-announces-the-open-knowledge-format/579253 +- **Note.com Deep-Dive (japanisch/englisch):** https://note.com/ai_driven/n/n8e2726b98180 +- **Reddit Original-Post:** https://www.reddit.com/r/WebAfterAI/comments/1u6mge2/google_cloud_just_released_okf_think_mcp_but_for/ +- **Pit-Share in OME:** https://t.me/c/3839640481/13/6697 diff --git a/wiki/concepts/llm/llm-knowledge-base.md b/wiki/concepts/llm/llm-knowledge-base.md index 9935e67..8001f9e 100644 --- a/wiki/concepts/llm/llm-knowledge-base.md +++ b/wiki/concepts/llm/llm-knowledge-base.md @@ -1,8 +1,9 @@ --- created: 2026-06-05 updated: 2026-06-16 -sources: [] -tags: [concept, karpathy, wiki] +sources: + - blog/2026-06-16_okf-google-cloud-open-knowledge-format.md +tags: [concept, karpathy, wiki, okf] --- # LLM Knowledge Base (Karpathy Wiki) @@ -45,4 +46,5 @@ Dieses Wiki ist eine direkte Operationalisierung von Karpathys Vorschlag — das ## Verwandte Seiten - [[wiki/architecture/memory-system]] — Schicht 1/2/3 als komplementäres Memory-System - [[wiki/architecture/byterover-knowledge-mining]] — historischer Vorläufer, der an Container-Ephemeralität scheiterte -- [[wiki/concepts/llm/llm-behavior-persistence]] — wie LLMs selbst persistente Verhaltensweisen aufbauen \ No newline at end of file +- [[wiki/concepts/llm/llm-behavior-persistence]] — wie LLMs selbst persistente Verhaltensweisen aufbauen +- [[open-knowledge-format-okf]] — **OKF v0.1 (Google Cloud, 2026-06-12) formalisiert genau dieses Pattern als offenen Standard. Unser Wiki ist strukturell bereits konform** \ No newline at end of file diff --git a/wiki/concepts/llm/open-knowledge-format-okf.md b/wiki/concepts/llm/open-knowledge-format-okf.md new file mode 100644 index 0000000..43ac4c3 --- /dev/null +++ b/wiki/concepts/llm/open-knowledge-format-okf.md @@ -0,0 +1,178 @@ +--- +created: 2026-06-16 +updated: 2026-06-16 +sources: + - blog/2026-06-16_okf-google-cloud-open-knowledge-format.md +tags: [okf, google-cloud, open-knowledge-format, llm-wiki, karpathy, knowledge-base, mcp, agent-knowledge, schema, standards] +--- + +# Open Knowledge Format (OKF) v0.1 — Google Cloud + +> **Was:** Google Cloud hat am 2026-06-12 das **Open Knowledge Format (OKF)** veröffentlicht — eine offene Spezifikation, die Karpathys LLM-Wiki-Pattern zu einem portablen, interoperablen Format formalisiert. +> **Quelle:** Pit-Share in [OME Topic 13 #6697](https://t.me/c/3839640481/13/6697) (Reddit-Post r/WebAfterAI). +> **Status:** v0.1 — Spezifikation öffentlich, Reference Implementation auf GitHub verfügbar. + +## TL;DR + +**OKF ist kein Runtime, kein SDK, kein Agent-Framework, kein MCP-Konkurrent.** MCP ist ein Protokoll für Agenten, um **Tools aufzurufen und Aktionen auszuführen**. OKF ist das **gegenüberliegende Ende**: eine Konvention, wie man statisches Wissen aufschreibt, damit jeder Agent es lesen kann. + +**In einem Satz:** Karpathys LLM-Wiki-Pattern (raw → LLM → wiki → Q&A) wird von Google formalisiert, damit verschiedene Tools das gleiche Bundle lesen können ohne Translation-Layer. + +## Bundle-Struktur + +``` +my_bundle/ +├── index.md # optional: directory listing for progressive disclosure +├── log.md # optional: chronological history of changes +├── datasets/ +│ └── sales.md +└── tables/ + ├── orders.md + └── customers.md +``` + +- Jedes `.md`-File = ein **Concept** +- Concepts verlinken sich via Standard-Markdown → **Graph von Beziehungen** +- `index.md` = plain directory listing (kein Frontmatter) für progressive disclosure +- `log.md` = chronologische Änderungshistorie (optional) + +## Drei Designprinzipien + +1. **Minimally opinionated.** Nur **ein** Pflichtfeld pro Concept (`type`). Alles andere (Types-Taxonomie, weitere Felder, Body-Sections) bleibt dem Producer überlassen. Die Spec definiert die **Interoperabilitäts-Oberfläche**, nicht das Content-Model. +2. **Producer/Consumer independence.** Wer schreibt und wer liest sind sauber getrennt. Bundle von Menschen hand-geschrieben → von AI-Agent konsumiert. Bundle von Metadata-Pipeline generiert → in Visualizer gebrowst. Bundle von LLM A synthetisiert → von LLM B abgefragt. **Format = Vertrag; Tooling an beiden Enden unabhängig austauschbar.** +3. **Permissive Conformance.** Consumers MÜSSEN unbekannte Types, fehlende Felder und broken Links **tolerieren** statt das Bundle abzulehnen. OKF soll nutzbar bleiben, wenn Bundles wachsen, refaktoriert oder teilweise von Agenten generiert werden. + +## Conformance-Regel (SPEC §9) + +Ein Bundle ist OKF v0.1 konform wenn: +- Jedes non-reserved `.md`-File hat einen parseable YAML-Frontmatter-Block +- Jeder Frontmatter-Block hat ein non-empty `type`-Feld +- `index.md` und `log.md` sind die einzigen erlaubten Frontmatter-Dateien (reserviert) +- Consumers dürfen Bundle NICHT ablehnen wegen unbekannter Types oder fehlender `index.md` + +**Permissive consumption model is intentional.** — OKF wächst mit den Bundles mit. + +## Frontmatter-Schema + +### Pflicht + +| Feld | Typ | Zweck | +|------|-----|-------| +| `type` | String (kurz) | Identifiziert Concept-Art. Consumers nutzen für Routing, Filter, Darstellung. Beispiele: `BigQuery Table`, `API Endpoint`, `Metric`, `Playbook`, `Reference`. | + +**Type-Werte sind NICHT zentral registriert.** Producers wählen deskriptive Werte; Consumers behandeln unbekannte Types als generic concepts. + +### Empfohlen (Prioritäts-Reihenfolge) + +| Feld | Zweck | +|------|-------| +| `title` | Menschenlesbarer Titel | +| `description` | Kurzbeschreibung | +| `resource` | Verweis auf zugrundeliegende Quelle (z. B. `bigquery://project.dataset.table`) | +| `tags` | Themen-Tags für Filterung | +| `timestamp` | Letztes Update / Erstellungsdatum | + +Producers können weitere Keys frei hinzufügen. Consumers MÜSSEN unbekannte Felder tolerieren. + +## Citations (SPEC §8) + +Wenn ein Concept-Body Claims aus externem Material macht, sollen diese unter `# Citations`-Heading am Dokumentende gelistet sein, **nummeriert**: + +```markdown +# Citations + +1. https://example.com/paper-x +2. https://arxiv.org/abs/2024.12345 +3. references/internal-doc.md (lokale Spiegelung) +``` + +Citation-Links können sein: +- **Absolute URLs** zu externen Quellen +- **Bundle-relative Pfade** zu anderen Concepts +- **Pfade in `references/`-Subdirectory**, das externes Material als first-class OKF Concepts spiegelt (empfohlen für Stabilität) + +## Drei Workflows zum Loslegen + +### Workflow 1: Hand-author a small bundle +**Schnellster Einstieg.** Manuell 3-5 Markdown-Files für eine "messy Ecke" des Systems schreiben, Agent drauf zeigen. 10 Minuten, zeigt Wert und Limits in einem Durchgang. → **Empfohlener Startpunkt.** + +### Workflow 2: Generate from existing schema +Wenn Schema zu groß zum Hand-Schreiben: Pipeline, die bestehende Strukturen (DB-Schemas, API-Specs, Notion-Wikis) als OKF-Bundle exportiert. **Achtung:** Citations-Disziplin nötig, sonst verliert Bundle an Wert. + +### Workflow 3: Consume a bundle without blowing your context window +Große Bundles komplett in Context laden = teuer + noisy. OKF-Lösung: **optional `index.md`** als plain directory listing. Agent liest Index, folgt Links, zieht Concepts **on-demand**. + +## Versioning (SPEC §11) + +- Document spezifiziert OKF version **0.1** +- Künftige Revisionen: `.` +- Bundles deklarieren Version via `okf_version: "0.1"` im **bundle-root `index.md`-Frontmatter** (einzige Stelle, wo `index.md` Frontmatter tragen darf) +- Consumers, die deklarierte Version nicht verstehen, sollen **best-effort consumption** versuchen statt das Bundle abzulehnen + +## Reference Implementation + Sample Bundles + +**Repo:** [github.com/GoogleCloudPlatform/knowledge-catalog](https://github.com/GoogleCloudPlatform/knowledge-catalog) + +Drei ready-to-browse Sample Bundles (vom Reference Agent produziert, als lebende Beispiele committed): +- **GA4 e-commerce** — [Google Analytics BigQuery Demo Dataset](https://developers.google.com/analytics/bigquery/web-ecommerce-demo-dataset) +- **Stack Overflow** — [Pantheon Marketplace](https://pantheon.corp.google.com/marketplace/product/stack-exchange/stack-overflow) +- **Bitcoin public datasets** — [BigQuery Public Datasets](https://cloud.google.com/blog/topics/public-datasets/bitcoin-in-bigquery-blockchain-analytics-on-public-data) + +Google Cloud **Knowledge Catalog** wurde aktualisiert, um OKF zu ingestieren und an Agents auszuliefern. + +## OKF vs. andere Formate (SPEC §10) + +| Format | Fokus | OKF-Differenz | +|--------|-------|---------------| +| **Karpathy LLM-Wiki** | Pattern, kein Standard | OKF formalisiert das Pattern | +| **Obsidian** | Wikibase für Menschen | OKF ist agent-first, permissiver | +| **Notion** | Wikibase + Block-Editor | OKF ist plain markdown, kein Tooling-Lock-in | +| **Hugo** | Static site generator | OKF ist reines Content-Format | +| **AGENTS.md** | Schema-on-Read für AI-Agents | OKF pinnt Regeln fest, AGENTS.md ist freier | +| **CLAUDE.md** | Agent-Kontext | OKF ist konzept-orientiert, CLAUDE.md ist Workflow-orientiert | +| **MCP** | Tool-Calling-Protokoll | OKF ist statisches Wissen, MCP ist Aktionen | + +OKF unterscheidet sich primär durch **Spezifikation** — Interoperabilität ohne Tooling-Diktat. + +## Direkte Konsequenzen für unser RamaDama-Repo + +Unser Repo `knowledge-base` ist exakt nach Karpathys LLM-Wiki-Pattern aufgebaut (siehe [[../llm/llm-knowledge-base.md]]). Google macht das Pattern jetzt zum formalen Standard. Konkrete Implikationen: + +### Was wir bereits OKF-konform haben + +- **Frontmatter-Standards** mit `type` als Pflichtfeld in raw-Files ✅ +- **`wiki/concepts/`, `wiki/teams/`, `wiki/tools/`, `wiki/architecture/`, `wiki/decisions/`** als konzept-orientierte Verzeichnisstruktur ✅ +- **`wiki/log.md`** als chronologischer Append-Only Changelog ✅ +- **`wiki/index.md`** als Auto-Generated Catalog (Fakten) + `wiki/ideas.md` (Subconscious Outcomes) — wir haben sogar **zwei** index-Dateien, OKF erlaubt das via optional `index.md` ✅ +- **Cross-References via `[[seite.md]]`** — Markdown-Standard ✅ +- **Producer/Consumer-Trennung:** Raw → Subagent-Prozessor → Wiki, Tooling unabhängig ✅ + +### Was wir noch ergänzen könnten (nicht zwingend) + +- **`# Citations`-Section** am Ende jedes Wiki-Pages mit nummerierten externen Links (OKF-Standard, aber optional) +- **`okf_version: "0.1"`** im root-`wiki/index.md`-Frontmatter deklarieren (signalisiert Konformität für externe Reader) +- **Bundle-Root-Identifier:** Klare Konvention, dass `wiki/` als OKF-Bundle-Root gilt (oder `knowledge-base/` direkt) + +### Strategische Implikation + +- **Validierung:** Wir sind mit unserer Architektur-Wahl nicht alleine; Google pusht dasselbe Pattern in den Markt → potentiell mehr Tooling-Support (Lint, Visualizer, Search) +- **Migration-Risk gering:** Unsere Struktur ist bereits kompatibel, Migration wäre additiv (Citations-Section) nicht destruktiv +- **Opportunität:** Wir könnten mit minimaler Ergänzung OKF-konform sein und von zukünftigen OKF-Tools profitieren + +## Externe Primärquellen + +- **OKF Ankündigung (Google Cloud Blog, 2026-06-12):** https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing +- **OKF SPEC v0.1:** https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md +- **OKF Reference Implementation Repo:** https://github.com/GoogleCloudPlatform/knowledge-catalog +- **Karpathy LLM-Wiki Original-Gist:** https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f +- **Search Engine Journal Coverage:** https://www.searchenginejournal.com/google-cloud-announces-the-open-knowledge-format/579253 +- **Note.com Deep-Dive (JP/EN):** https://note.com/ai_driven/n/n8e2726b98180 +- **Reddit Original-Post:** https://www.reddit.com/r/WebAfterAI/comments/1u6mge2/google_cloud_just_released_okf_think_mcp_but_for/ +- **Pit-Share in OME:** [Topic 13 #6697](https://t.me/c/3839640481/13/6697) + +## Verwandte Wiki-Seiten + +- `[[llm-knowledge-base.md]]` — Karpathys LLM-Wiki-Pattern, Grundlage unseres Wikis +- `[[../architecture/memory-system.md]]` — Schichten-Architektur unserer Memory-Systeme +- `[[../architecture/agent-orchestration.md]]` — Orchestrator-Pattern (parallele zu OKF's Producer/Consumer-Trennung) +- `[[../decisions/2026-06-05_kein-coding-guide-in-kb.md]]` — Beispiel-Decision-Page diff --git a/wiki/index.md b/wiki/index.md index 3e2edb6..44038e5 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -2,7 +2,7 @@ *Auto-generated: 2026-06-16* -*Letzte Aktualisierung: 2026-06-16 (10. Update — neuer Ingest: Hardware-Frontier (Mainzer/Everlast AI: Neuromorphe Chips, Quantencomputer) als neue Concepts-Subkategorie `concepts/hardware/`; Wikipedia-Architektur-Verweise ergänzt)* +*Letzte Aktualisierung: 2026-06-16 (11. Update — OKF v0.1 Ingest: Google formalisiert LLM-Wiki-Pattern, Cross-Ref in llm-knowledge-base.md + neue Konzeptseite)* ## Architecture @@ -42,6 +42,7 @@ | [Real-World Coding Showdown](concepts/llm/real-world-coding-showdown.md) | Head-to-Head-Methodik jenseits statischer Benchmarks, Kimi K2.7 vs GLM-5.2 in Hermes Agent, Sub-Task-Spezialisierung | youtube/2026-06-14_fahd-mirza-kimi-k2.7-vs-glm-5.2.md | | [AI Value Migration — Orchestration + Infrastructure](concepts/llm/ai-value-migration-orchestration.md) | 20VC mit Aravind Srinivas: Wert verschiebt sich von Modellen zu Orchestrierung, Strom, Mindset. Token Value per Watt per User als Schlüsselkennzahl | xpost/2026-06-15_harrystebbings-20vc-aravind-srinivas.md | | [Post-Transformer LLM Architectures](concepts/llm/post-transformer-llm-architectures.md) | DeepMinds Vier-Säulen-Strategie: Griffin/Recurrent-Gemma/Titans (hybride Attention+Recurrence), Diffusions-LLMs, JEPA vs. Generativ (Weltmodelle), Foundation-Prior vs. Continual-Learning | youtube/2026-06-16_deepmind-two-steps-ahead.md | +| [Open Knowledge Format (OKF) v0.1](concepts/llm/open-knowledge-format-okf.md) | Google Cloud (2026-06-12) formalisiert Karpathys LLM-Wiki-Pattern als offenen Standard: Bundle aus .md + YAML-Frontmatter, `type` als einziges Pflichtfeld, permissive Conformance. Unser Wiki strukturell bereits konform | blog/2026-06-16_okf-google-cloud-open-knowledge-format.md | ### Hardware | Seite | Beschreibung | Quellen | diff --git a/wiki/log.md b/wiki/log.md index 1a222dd..dee7535 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -390,3 +390,63 @@ - Architektur-Diversität = mehr unabhängige Forschungs-Pfade = resilienteres AGI-Ökosystem (gegen Monokultur-Risiko, gegen einzelne Vendor-Lock-in) - Weltmodell-Debatte stärkt die These, dass Intelligenz **embodied** und **interaktiv** sein muss — kompatibel mit dem Pro-Leben-Prinzip (echte Erfahrung statt nur statische Daten) - Open-Source-Front (Titans-Paper, Mamba-Familie) + OpenRouter-Adapter-Pfad = Open-Source-Ökosystem bleibt handlungsfähig, ohne auf geschlossene Frontier-Labs warten zu müssen + +--- + +## 2026-06-16 — Ingest | Open Knowledge Format (OKF) v0.1 — Google Cloud + +**Type:** ingest + wiki-update | **Scope:** raw/blog, wiki/concepts/llm + +**Actions:** +- raw: `raw/blog/2026-06-16_okf-google-cloud-open-knowledge-format.md` (created — Reddit-Post r/WebAfterAI + Google Cloud Blog + SPEC v0.1 als Primärquellen, Pit's Kontextualisierung) +- wiki: `wiki/concepts/llm/open-knowledge-format-okf.md` (created — neue Konzeptseite mit TL;DR, Bundle-Struktur, 3 Designprinzipien, Frontmatter-Schema, Citations-Konvention, 3 Workflows, Versioning, Reference Implementation, OKF-vs-andere-Formate, konkrete Konsequenzen für unser Repo) +- wiki: `wiki/concepts/llm/llm-knowledge-base.md` (updated — Cross-Ref zur neuen OKF-Seite + Frontmatter sources update) +- index: updated (neue Concepts-Zeile, Update-Header 11. Update) +- log: this entry + +**Kernkonzept identifiziert — Google formalisiert unser Pattern als offenen Standard:** + +OKF v0.1 (Google Cloud Blog 2026-06-12) ist die **offizielle Spezifikation** des Musters, das wir bereits in unserem `knowledge-base` Repo umsetzen: +- **Markdown-First** mit YAML-Frontmatter +- **`type` als einziges Pflichtfeld** (unsere Frontmatter haben das bereits) +- **Producer/Consumer-Trennung** (unser Raw → Subagent → Wiki Pattern passt) +- **Permissive Conformance** (Consumers MÜSSEN unbekannte Types tolerieren) +- **Optional `index.md` und `log.md`** (wir haben sogar **zwei** index-Dateien: `index.md` für Fakten, `ideas.md` für Subconscious Outcomes) + +**MCP vs. OKF — die zentrale Unterscheidung:** + +- **MCP** = Protokoll für Agenten, um **Tools aufzurufen** und Aktionen auszuführen +- **OKF** = Konvention, um **statisches Wissen aufzuschreiben**, damit jeder Agent es lesen kann + +→ MCP und OKF sind **komplementär**, nicht konkurrierend. OKF ist explizit "das andere Ende". + +**Was wir bereits OKF-konform haben (kein Migrations-Aufwand nötig):** +- Frontmatter-Standards mit `type` als Pflichtfeld in raw-Files ✅ +- Konzept-orientierte Verzeichnisstruktur (concepts/, teams/, tools/, architecture/, decisions/) ✅ +- `wiki/log.md` als chronologischer Append-Only Changelog ✅ +- `wiki/index.md` als Auto-Generated Catalog ✅ +- Cross-References via `[[seite.md]]` ✅ +- Producer/Consumer-Trennung via Subagent-Pipeline ✅ + +**Was wir optional ergänzen könnten (nicht zwingend):** +- `# Citations`-Section am Ende jedes Wiki-Pages (OKF-Standard, aber optional) +- `okf_version: "0.1"` im root-`wiki/index.md`-Frontmatter deklarieren +- Klare Bundle-Root-Konvention (`wiki/` als OKF-Bundle-Root) + +**Strategische Implikation:** +- **Validierung:** Wir sind mit unserer Architektur-Wahl nicht alleine; Google pusht dasselbe Pattern → potentiell mehr Tooling-Support (Lint, Visualizer, Search) +- **Migration-Risk gering:** Struktur bereits kompatibel, Anpassungen wären additiv +- **Opportunität:** Wir könnten mit minimaler Ergänzung OKF-konform sein und von zukünftigen OKF-Tools profitieren + +**Pro-Leben-Konsequenz:** +- Offene Standards = gegen Vendor-Lock-in = mehr Handlungsfähigkeit für alle (gegen Mangelnarrativ) +- Permissive Conformance = Agent-Ökosystem bleibt offen, kein zentraler Gatekeeper +- Knowledge-Commons-Pattern stärkt die freie Werkzeug-Wahl für Open-Source-Ökosysteme + +**Cross-References zu existierenden Wiki-Seiten:** + +- [[open-knowledge-format-okf]] (NEU) +- [[llm-knowledge-base]] (Cross-Ref hinzugefügt) +- [[../architecture/memory-system]] (Schicht 1/2/3 als komplementäres Memory-System) +- [[../architecture/agent-orchestration]] (Producer/Consumer-Trennung als parallele Pattern) +- [[post-transformer-llm-architectures]] (zeigt wie das Wiki selbst zur Ingest-Quelle für Modell-Training werden könnte)