Open Knowledge Format od Google Cloud

Skąd się wziął pomysł, czyli od Busha do Karpathy’ego

W 1945 roku Vannevar Bush opisał urządzenie które nazwał Memex¹. Miała to być osobista, kurowana baza wiedzy z powiązaniami między dokumentami – coś w rodzaju rozszerzonej pamięci dla badacza. Bush pisał że wartość leży w połączeniach między dokumentami. Memex nigdy nie powstał ale Bush opisał coś prywatnego i aktywnie zarządzanego. Można uznać, że pytanie Busha „kto robi obsługę?” przez 80 lat było bez odpowiedzi. Czyli kto aktualizuje odnośniki, pilnuje spójności, integruje nowe informacje z tym co już wiadomo?

W 2026 roku Andrej Karpathy – jeden z pierwszych pracowników OpenAI, były dyrektor ds AI w Tesli – napisał prostą odpowiedź: duży model językowy (LLM) 🙂

Czym jest LLM Wiki

Karpathy opublikował dokument który nazywa „plikiem z pomysłem” – opis wzorca, który można wkleić do agenta AI i powiedzieć: zbuduj mi to. Pomysł jest prosty ale odwraca standardowe myślenie o tym jak modele językowe pracują z dokumentami.

Standardowe podejście to RAG – model przy każdym pytaniu:

1. Przeszukuje dokumenty
2. Zbiera fragmenty i składa odpowiedź
3. Następnym razem model zaczyna od nowa

Nie ma uczenia się, nie ma budowania zrozumienia.

Karpathy proponuje coś innego. Zamiast kazać modelowi za każdym razem szukać odpowiedzi w dokumentach, to budujesz wiki – zbiór plików tekstowych który rośnie i dojrzewa. Gdy dodajesz nowe źródło, model nie indeksuje go do późniejszego wyszukiwania tylko:

1. czyta je
2. wyciąga najważniejsze informacje
3. integruje z tym co już jest w wiki.

Aktualizuje powiązane strony, zaznacza sprzeczności, wzmacnia lub kwestionuje dotychczasową syntezę.

Wiki staje się dokumentem, który się kumuluje. Powiązania między konceptami są już zbudowane, a sprzeczności zostały już oznaczone. Synteza odzwierciedla wszystko to, co zostało przeczytane.

Karpathy opisuje to tak:

Obsidian to IDE; LLM to programista; wiki to baza kodu.

Architektura ma 3 warstwy

1. Źródła pierwotne – dokumenty, artykuły, dane – których model czyta ale nigdy nie modyfikuje
2. Wiki – zbiór plików tekstowych generowanych utrzymywanych przez model
3. Schemat – plik konfiguracyjny który mówi modelowi jak wiki jest zorganizowana, jakie są konwencje i jakich procesów przestrzegać

To on sprawia że LLM jest zdyscyplinowanym redaktorem wiki, a nie zwykłym chatbotem.

Dodatkowo model wykonuje 3 rodzaje operacji

1. Przyjmowanie nowych źródeł – jedno nowe źródło może dotknąć kilkunastu stron wiki jednocześnie
2. Odpowiadanie na pytania – przy czym dobre odpowiedzi mogą być zapisywane z powrotem do wiki jako nowe strony, więc eksploracja też się kumuluje
3. Przegląd spójności – okresowe sprawdzanie wiki pod kątem sprzeczności między stronami, nieaktualnych twierdzeń, osieroconych stron bez odnośników, brakujących powiązań

To może działać ponieważ aktualizowanie odnośników, pilnowanie spójności, notowanie gdy nowe informacje zaprzeczają starym jest żmudne i czasochłonne. LLM’y nie nudzą się, nie zapominają zaktualizować odnośnika i mogą dotknąć kilkunastu plików w jednym przejściu. Bush nie mógł rozwiązać pytania kto robi obsługę, bo wtedy taka technologia nie istniała.

Co to jest Open Knowledge Format

LLM Wiki Karpathy’ego to wzorzec, a nie standard. Każdy kto wdraża LLM Wiki robi to po swojemu. Twoja wiki i moja wiki mogą wyglądać podobnie – pliki tekstowe, nagłówki YAML, odnośniki między stronami, etc. ale nie są zaprojektowane żeby ze sobą współpracować. Wiedza pozostaje zamknięta w oryginalnym projekcie.

12 czerwca 2026 Google Cloud ogłasza Open Knowledge Format (w skrócie: OKF), który formalizuje wzorzec LLM Wiki jako przenośny, otwarty standard.

Relacja między tymi trzema rzeczami wygląda tak:

1. LLM Wiki – idea i filozofia
2. OKF – minimalny standard interoperacyjności
3. Knowledge Catalog – implementacja w ekosystemie Google Cloud

Karpathy dał ideę. Google dało format. Google Cloud dało produkt.

OKF v0.1 jest celowo minimalistyczny. Jedyne wymaganie to pole type w nagłówku każdego dokumentu. Reszta – jakie typy istnieją, jakie inne pola dodać, jak zorganizować treść – jest pozostawiona osobie, która będzie to wdrażała.

Autorzy podkreślają jedno rozróżnienie: OKF jest formatem, a nie platformą – ma być formatem wiedzy dla systemów AI. Żeby odczytać dokument potrzebujesz tylko edytora tekstu.

Jak OKF działa w praktyce

Paczka OKF to katalog plików tekstowych. Każdy plik reprezentuje jeden koncept – tabelę w bazie danych, wskaźnik biznesowy, instrukcję operacyjną, opis API. Ścieżka do pliku jest tożsamością konceptu.

Przykładowa struktura:

sprzedaz/
├── index.md
├── zbiory-danych/
│   └── zamowienia_db.md
├── tabele/
│   ├── zamowienia.md
│   └── klienci.md
└── wskazniki/
    └── tygodniowi_aktywni_uzytkownicy.md

Każdy plik ma mały blok YAML na początku dla ustrukturyzowanych pól i treść w formacie tekstowym dla wszystkiego innego. Idąc za powyższym przykładem blok YAML może wyglądać tak:

---
type: Tabela BigQuery
title: Zamówienia
description: Jeden wiersz na ukończone zamówienie klienta.
resource: https://console.cloud.google.com/bigquery?...
tags: [sprzedaz, przychody]
timestamp: 2026-05-28T14:30:00Z
---

# Schemat

| Kolumna      | Typ    | Opis                              |
|--------------|--------|-----------------------------------|
| order_id     | STRING | Unikalny identyfikator zamówienia |
| customer_id  | STRING | Klucz obcy do tabeli klientów     |

# Powiązania

Łącz z [klientami](/tabele/klienci.md) przez customer_id.

Koncepty łączą się ze sobą zwykłymi odnośnikami tekstowymi. To zamienia katalog plików w graf relacji bogatszy niż sama struktura folderów. Paczka może zawierać pliki index.md – mapy zawartości które pomagają agentom nawigować po hierarchii oraz pliki log.md, gdzie jest chronologiczna historia zmian, czytelna dla człowieka i LLM’ów.

Jak OKF przenosi wiedzę

To jest część którą najłatwiej źle zrozumieć.

❌ OKF nie przenosi danych – tabel, rekordów, plików, etc

✔️ OKF przenosi wiedzę o danych – czyli znaczenie, relacje, kontekst biznesowy – z OKF wiedza jest w plikach, które można skopiować, wersjonować, wysłać jako spakowane archiwum, zamontować na dowolnym systemie plików.

3 konkretne scenariusze:

1. Między zespołami – zespół inżynierów danych tworzy paczkę OKF i wgrywa ją do wspólnego repozytorium. Zespół analityków klonuje repozytorium. Ich agent AI czyta pliki i wie jak używać danych – bez pytania kogokolwiek, bez spotkań wprowadzających – po prostu czyta
2. Między organizacjami – Firma A eksportuje paczkę jako spakowany folder. Wysyła go Firmie B gdzie agenty rozumieją dane Firmy A. Żadnego specjalnego oprogramowania, żadnego API czy konta.
3. Między agentami – Agent 1 odkrywa błąd w tabeli, aktualizuje odpowiedni plik i dopisuje ostrzeżenie. Agent 2, przy następnym uruchomieniu czyta zaktualizowany plik i automatycznie wie o błędzie, który znalazł Agent 1. Agenty dzielą się wiedzą przez pliki.

Co to znaczy dla SEO

Systemy AI nie czytają artykułu od początku do końca. Pobierają fragmenty – chunki – i oceniają każdy fragment osobno, w oderwaniu od reszty, bo tak system RAG, które zasilają AI Overviews, AI Mode, ChatGPT, Perplexity i inne LLM’y.

Dokument OKF który opisuje jeden koncept musi być zrozumiały w oderwaniu od reszty paczki. Dosłownie: agent powinien móc pobrać jeden plik i mieć z niego pożytek bez czytania całego katalogu. To jest wymaganie specyfikacji.

Artykuł który ma być cytowany przez AI działa dokładnie tak samo. Sekcja między dwoma nagłówkami H2 musi być zrozumiała bez kontekstu całego artykułu. Pierwsze zdanie sekcji powinno zawierać odpowiedź, a nie prowadzić do odpowiedzi. W momencie gdy zmuszasz użytkownika lub LLM do przeczytania 3 zdań, zanim dostarczysz odpowiedź – przegrywasz. Przykład „niedziele handlowe” 😀

Dokładnie tak samo działa Googlebot – dostarcz wartość użytkownikowi, bez lania wody. Google wykorzystuje technologię AI w wyszukiwarce od ponad dekady i z każdym rokiem coraz lepiej radzą sobie z semantyką.

Krytyczne spojrzenie

OKF zasługuje na kilka trudnych pytań których entuzjastyczne posty na LinkedIn zwykle nie zadają.

Czy „niezależny od dostawcy” od Google to nie oksymoron?

• Referencyjne implementacje są oparte o BigQuery. Knowledge Catalog – produkt który OKF zasila – to usługa Google Cloud. Przykładowe paczki plików pokazują dane publiczne dostępne w BigQuery. Neutralność będzie weryfikowana przez adopcję poza ekosystemem Google. Póki co jest tylko deklaracją. Oczywiście to nie dyskwalifikuje formatu 😉

Czy v0.1 jest wystarczająco szczegółowy żeby zapewnić interoperacyjność?

• Jedyne wymagane pole to type. Co oznacza że dwie organizacje mogą stworzyć całkowicie zgodne z specyfikacją paczki OKF, które są wzajemnie niezrozumiałe. Moga używać różnych konwencji dla wszystkiego innego. Dlatego uważa, że „interoperacyjność” na chwile obecną może być bardziej teorią niż praktyką.

Jak zawsze na początku – wartość formatu rośnie z liczbą użytkowników. OKF musi osiągnąć naprawdę sporą ilość adopcji żeby stać się prawdziwym standardem, a nie kolejnym projektem Google który dobrze się zapowiadał, a trafił na cmentarz Google²

Alternatywy dla OKF

AGENTS.md i CLAUDE.md, to ten sam wzorzec co OKF – stosowany przez deweloperów od miesięcy. OKF formalizuje coś, co już istnieje ale musi przekonać tych, którzy mają własne nieformalne rozwiązania żeby przestawili się na standard.

Dla kogo i od

Uważam, że sam pomysł jest świetny ale to jest wersja 0.1 więc totalny świeżak. Natomiast już można mogę stwierdzić że:

Obserwuj OKF jeśli – budujesz lub planujesz budować wewnętrzne systemy agentowe. Masz problem z nieobejmującą całości wiedzą w organizacji i agenty, które nie mogą jej złożyć w całość. OKF jest odpowiedzią na dobrze postawione pytanie – tylko że pytanie zadają dziś głównie duże organizacje z zespołami inżynierskimi takimi jak Google. Między dużymi działami OKF może być game changerem.

Sygnałem który warto przede wszystkim śledzić jest adopcja poza ekosystemem Google. Jeśli za rok na przykład OpenMetadata i DataHub będą eksportować do OKF – to znak że format staje się prawdziwym standardem. Jeśli nie – pozostanie w niszy.

Zignoruj (póki co) OKF jeśli – jesteś twórcą treści, agencją SEO lub właścicielem strony / sklepu bez rozbudowanych systemów agentowych.

Wnioski dla specjalistów SEO

Dla Specjalistów SEO najważniejsza lekcja jest koncepcyjna. AI nie czyta stron, a pobierają wiedzę. Wiedza która jest dobrze opisana, faktograficzna, samodzielna znaczeniowo i zrozumiała w oderwaniu od kontekstu – jest wiedzą którą AI może wykorzystać. To co OKF opisuje jako wymaganie dla plików w katalogu, to właśnie dobre treści robiły od zawsze. Propozycja Google Cloud nadała temu tylko nazwę.

1. Teoretyczny komputer analogowy z możliwością tworzenia powiązań i ich śledzenia [Wikipedia] ↩︎
2. Cmentarz Google – gcemetery.co ↩︎