Google Cloud wydaje Open Knowledge Format. Markdownowy standard wiedzy dla agentow AI

Google Cloud opublikowal Open Knowledge Format (OKF) w wersji 0.1, otwarta i neutralna wobec dostawcow specyfikacje, ktora opisuje wiedze organizacji jako katalog plikow Markdown z naglowkiem YAML. Standard zadebiutowal 12 czerwca 2026 roku, a kilka dni pozniej, 15 i 16 czerwca, obieg branzowy oblegly go komentarzami, bo to pierwsza powazna proba ujednolicenia tego, jak strony i firmy podaja kontekst agentom AI. Dla specjalistow SEO i AIO to sygnal, ze format tresci pod modele jezykowe przestaje byc luzna konwencja, a zaczyna byc opisana, wersjonowana umowa.

OKF nie jest nowa platforma ani kolejnym panelem do logowania. To zestaw regul: katalog, pliki, kilka pol w naglowku. Wlasnie ta prostota sprawia, ze pomysl jest grozny dla starego porzadku, w ktorym kazdy katalog danych mial wlasne API, a kazda wiki swoj format. Ponizej tlumaczymy, co dokladnie ogloszono, jak zbudowany jest standard i dlaczego osoby zajmujace sie widocznoscia w wyszukiwarkach oraz w odpowiedziach generatywnych powinny potraktowac go priorytetowo.

Kontekst: dlaczego akurat teraz

Rok 2026 uplywa pod znakiem agentow. Modele jezykowe przestaly byc tylko czatbotami, ktore odpowiadaja na pytania, a staly sie wykonawcami zadan, ktorzy czytaja dokumentacje, lacza dane i podejmuja kroki w tle. Problem w tym, ze agent jest tak dobry, jak kontekst, ktory dostanie. Wiedza firmy lezy rozsypana po katalogach metadanych z wlasnymi API, po wiki, dyskach wspoldzielonych, komentarzach w kodzie, komorkach notatnikow i, jak ujmuje to dokumentacja Google, w glowach starszych inzynierow. Model moze napisac kod albo strescic raport, ale bez wlasciwych informacji wyprodukuje odpowiedz pewna siebie i bledna.

W tym samym czasie rynek dorobil sie wlasnych, oddolnych prob standaryzacji. Konwencja llms.txt, pliki kontekstu w repozytoriach, wewnetrzne wiki pisane pod modele: wszystkie te wzorce powstaly, bo zespoly intuicyjnie czuly, ze agentom trzeba podac wiedze w formie, ktora rozumie czlowiek i maszyna naraz. Andrej Karpathy spuentowal to zjawisko zdaniem, ze modele jezykowe nie nudza sie, nie zapominaja zaktualizowac odsylacza i potrafia dotknac pietnastu plikow w jednym przebiegu. OKF bierze ten emergentny wzorzec, nazywany czasem wiki dla LLM, i zamienia go w przenosny standard.

Dla branzy SEO i AIO to wazny moment, bo dyskusja o optymalizacji pod modele przez dlugi czas obracala sie wokol domyslow. Nie bylo wiadomo, czy liczy sie schema.org, czy llms.txt, czy moze czysty Markdown. Wejscie duzego dostawcy z opisana specyfikacja porzadkuje pole gry i daje punkt odniesienia, do ktorego beda sie ustawiac kolejne narzedzia.

Kluczowe fakty

Najwazniejsze parametry premiery zbieramy w tabeli, zeby latwo bylo wrocic do konkretow.

Sercem standardu jest katalog. Wyobrazmy sobie folder o nazwie sales, w nim podkatalogi datasets, tables i metrics, a w kazdym pliki Markdown opisujace pojedyncze pojecia: tabele, zbiory danych, metryki biznesowe. Kazdy taki plik sklada sie z dwoch czesci. Naglowek YAML niesie pola strukturalne, na przyklad type, title, description, resource, tags oraz timestamp. Tresc pod naglowkiem to zwykly Markdown: schemat tabeli, opisy kolumn, sposob laczenia danych.

Jedynym polem wymaganym jest type. To celowa decyzja projektowa, ktora autorzy nazywaja minimalna opinia. Specyfikacja nie narzuca, jakie typy maja istniec, jakie dodatkowe pola dodac ani z jakich sekcji ma sie skladac tresc. Definiuje powierzchnie wymiany, a nie model tresci. Dzieki temu OKF moze opisac tabele BigQuery rownie dobrze jak runbook awaryjny, definicje metryki czy notatke o wycofaniu API.

Druga cecha jest graf wiedzy budowany przez odsylacze. Pojecia linkuja do siebie zwyklym skladnikiem Markdown, na przyklad odnosnikiem do pliku customers.md z tabeli orders.md. W ten sposob katalog plikow zamienia sie w siec zaleznosci bogatsza niz prosta hierarchia folderow. Plik index.md sluzy do stopniowego ujawniania wiedzy, kiedy agent schodzi w glab struktury, a plik log.md przechowuje chronologiczna historie zmian.

Co Google dolozyl oprocz specyfikacji

Sama specyfikacja to za malo, zeby przekonac zespoly do adopcji, dlatego Google wydal trzy narzedzia referencyjne. Pierwsze to agent wzbogacajacy: przechodzi po zbiorze danych BigQuery, tworzy projekt dokumentu OKF dla kazdej tabeli i widoku, a nastepnie uruchamia drugi przebieg modelu, ktory crawl uje autorytatywna dokumentacje i uzupelnia kazda koncepcje o cytowania, schematy oraz sciezki laczenia danych. Drugie narzedzie to statyczny wizualizator HTML, pojedynczy samowystarczalny plik, ktory zamienia dowolny pakiet OKF w interaktywny widok grafu bez zaplecza serwerowego i bez instalacji po stronie ogladajacego. Trzeci element to trzy przykladowe pakiety oparte na publicznych zbiorach: e-commerce GA4, Stack Overflow oraz Bitcoin, dolozone do repozytorium jako zywe przyklady zgodne ze standardem.

Co to znaczy dla SEO i AIO

Na pierwszy rzut oka OKF wyglada na narzedzie dla zespolow danych i inzynierii, a nie dla marketingu. Komunikat Google nie wspomina wprost o pozycjonowaniu. Trzeba jednak czytac miedzy wierszami, bo standard dotyka samego rdzenia tego, czym staje sie optymalizacja pod odpowiedzi generatywne, czyli GEO i AEO. Jesli agenci AI maja w sposob przewidywalny siegac po wiedze, to wygra ten, kto poda im te wiedze w formacie, ktory rozumieja bez tlumaczenia.

Pierwszy wniosek dotyczy tresci jako infrastruktury. Branza coraz glosniej mowi, ze wygraja firmy traktujace tresc nie jak wypelniacz, lecz jak fundament dzialania maszyn. OKF daje temu pogladowi techniczny ksztalt: wiedza zyje w kontroli wersji obok kodu, ktory opisuje, jest czytelna dla czlowieka i parsowalna dla agenta z tego samego pliku, bez warstwy posredniej. To dokladnie ta sama filozofia, ktora od miesiecy zalecamy w analizach formatu wpisu pod cytowania w modelach AI: porzadek, jednoznaczne pola, jawne powiazania.

Drugi wniosek dotyczy grafu wiedzy. OKF buduje siec pojec przez odsylacze, co jest bliskim krewnym tego, co w SEO nazywamy semantyka, encjami i linkowaniem wewnetrznym. Strona, ktora ma czytelna strukture encji i jawne relacje miedzy tematami, jest latwiejsza do przelozenia na pakiet zgodny z OKF. Kto poukladal juz architekture tematyczna zgodnie z zasadami semantycznego SEO, ten ma przewage, bo mysli kategoriami pojec i zaleznosci, a nie pojedynczych slow kluczowych.

Trzeci wniosek dotyczy standaryzacji jako takiej. Przez ostatni rok zespoly eksperymentowaly z roznymi konwencjami podawania kontekstu modelom. Pojawienie sie opisanego standardu od duzego dostawcy nie znaczy, ze inne podejscia znikna, ale daje punkt odniesienia. To istotne w kontekscie wczesniejszych ruchow Google, ktory oficjalnie uznal GEO i AEO w wytycznych Search Central. Widac spojny kierunek: firma porzadkuje zarowno strone widocznosci w odpowiedziach, jak i strone dostarczania wiedzy agentom.

Praktyczne pytanie: czy to zastapi schema i llms.txt

Krotka odpowiedz brzmi: na razie nie, bo OKF rozwiazuje inny problem. Dane strukturalne schema.org opisuja pojedyncza strone dla wyszukiwarki, llms.txt wskazuje modelom, gdzie szukac tresci, a OKF porzadkuje cala biblioteke wiedzy jako przenosny pakiet, ktory agent moze przegladac, laczyc i odpytywac. Te warstwy moga wspolistniec. Mozna sobie wyobrazic przyszlosc, w ktorej strona publikuje schema dla klasycznych wynikow, llms.txt jako wskazowke nawigacyjna i pakiet OKF jako uporzadkowane zrodlo kontekstu dla agentow. Warto sledzic, czy kolejne wersje standardu zaczna te swiaty laczyc.

Scenariusz z zycia: jak to dziala w praktyce

Wezmy zespol e-commerce, ktory chce, by wewnetrzny asystent AI bezblednie liczyl tygodniowa liczbe aktywnych uzytkownikow. Dzis odpowiedz zalezy od tego, czy model trafi na wlasciwa definicje metryki, ktora moze tkwic w wiki, w komentarzu do kodu albo w glowie analityka. W swiecie OKF ta definicja zyje w pliku weekly_active_users.md, ma typ metryki, opis, znacznik czasu i odsylacze do tabel zdarzen, na ktorych sie opiera. Agent nie zgaduje, lecz idzie po grafie: od metryki do tabeli, od tabeli do sciezki laczenia danych. Pytanie w stylu jak policzyc tygodniowych aktywnych uzytkownikow z naszego strumienia zdarzen przestaje byc loteria, bo kontekst jest jawny i przenosny.

Ten sam mechanizm dotyczy tresci publicznej. Wydawca, ktory opisze swoje filary tematyczne jako pojecia z jawnymi powiazaniami, daje agentom mape, po ktorej te poruszaja sie bez bledu. To zbieznosc nieprzypadkowa, bo standard pojawil sie w tygodniu, w ktorym Google uruchomil w wyszukiwarce agentow informacyjnych monitorujacych sieci dla subskrybentow planu Ultra. Im wiecej agentow dziala w tle, tym wazniejsze staje sie podanie im wiedzy w formacie, ktory rozumieja od reki. OKF i agentowa wyszukiwarka to dwie strony tego samego trendu: konsumentem tresci coraz czesciej jest maszyna, nie czlowiek z przegladarka.

Reakcje branzy

Odbior byl zywy i podzielony, co przy specyfikacji w wersji 0.1 jest naturalne. Czesc komentatorow przyjela OKF z entuzjazmem, podkreslajac, ze format, a nie platforma, to wlasciwa odpowiedz na rozdrobnienie narzedzi. Autorzy ze strony Google, Sam McVeety i Amir Hormati, sformulowali to wprost: sam format jest wkladem, a narzedzia istnieja po to, by go urealnic i obnizyc koszt sprobowania. Ich zdaniem, niezaleznie od tego, jaki ksztalt ma dzisiaj wiedza organizacji, OKF ma byc wspolnym jezykiem, na ktory bedzie ja mozna wymienic jutro.

Pojawily sie tez glosy sceptyczne. W jednym z komentarzy padlo pytanie, czy OKF to faktycznie standard, czy po prostu uporzadkowany folder z plikami Markdown. To zarzut, ktory warto potraktowac powaznie, bo sila standardu nie tkwi w jego zlozonosci, lecz w adopcji. Jesli wystarczajaco wielu producentow i konsumentow wiedzy zacznie go uzywac, prostota stanie sie zaleta. Jesli nie, zostanie ciekawostka. Sami autorzy podkreslaja, ze wartosc bierze sie z szerokosci adopcji, a nie z wlasnosci, dlatego format wydano jako otwarty.

Niezaleznie od oceny wszyscy zgadzaja sie co do jednego: kierunek jest sluszny. Modele potrzebuja kontekstu, kontekst jest rozsypany, a wspolny, czytelny format to rozsadny sposob, by te dwie rzeczy spotkac. Trzy zasady projektowe, czyli minimalna opinia, niezaleznosc producenta od konsumenta oraz format zamiast platformy, sprawiaja, ze OKF nie zamyka nikogo w jednym ekosystemie. Pakiet napisany przez czlowieka moze byc konsumowany przez agenta, pakiet wyeksportowany z katalogu metadanych moze byc przegladany w wizualizatorze, a pakiet stworzony przez jeden model moze byc odpytywany przez inny.

Co dalej

OKF v0.1 to deklaracja, ze format bedzie ewoluowal. Google zapowiada rozwoj w miare, jak pojawia sie kolejni producenci i konsumenci wiedzy oraz jak branza nauczy sie, jakie reprezentacje wiedzy agenci faktycznie potrzebuja w praktyce. Dla zespolow SEO i contentu oznacza to kilka konkretnych ruchow, ktore mozna zaplanowac juz teraz, bez czekania na wersje 1.0.

• Przejrzec wlasna architekture tresci pod katem encji i jawnych powiazan, bo to one przekladaja sie na czytelny graf wiedzy.
• Sprawdzic przykladowe pakiety w repozytorium Google, zwlaszcza ten oparty na GA4, by zrozumiec, jak wyglada zgodny z OKF opis tabeli i metryki.
• Potraktowac dokumentacje wewnetrzna jak produkt: spojne pola, daty zmian w log.md, jednoznaczne typy pojec.
• Obserwowac, czy narzedzia SEO i platformy AIO zaczna eksportowac wiedze w OKF, bo to pierwszy sygnal, ze standard wychodzi poza Google Cloud.
• Nie porzucac dotychczasowych warstw, czyli danych strukturalnych i sygnalow widocznosci w odpowiedziach generatywnych, bo OKF ich nie zastepuje.

Najwazniejszy wniosek dla branzy jest taki, ze granica miedzy tworzeniem tresci a przygotowaniem danych dla maszyn zaciera sie coraz szybciej. Jeszcze niedawno SEO konczylo sie na tytule, naglowkach i danych strukturalnych. Dzis trzeba myslec o tym, czy nasza wiedza da sie spakowac, przeniesc i odczytac przez agenta, ktory nigdy nie odwiedzi strony w przegladarce. Open Knowledge Format jest pierwsza powazna proba opisania, jak taki pakiet ma wygladac, i wlasnie dlatego warto miec go na radarze, nawet jesli dzis nosi numer 0.1.

FAQ