Az Open Knowledge formátum v0.2 a felelős bizalmat kezeli.

Amikor 2026 júniusában bevezettük a Nyílt Tudásformátumot (OKF), kijelentettük, hogy a kontextus, amire az ügynököknek szüksége van (táblázatsémák, metrikadefinitiák, futási könyvek), formátumban kell élnie, nem pedig egy tulajdonosi szolgáltatásban, és nem egyenetlenül szétszórva strukturálatlan szöveges tömbök között. Ennek megfelelően az OKF v0.1 egyszerűen indult: csupán markdown, YAML elülső rész és néhány konvenció. A fejlesztői közösség erőteljes válasza és hozzájárulásai tájékoztatták a következő verzióra vonatkozó fókuszunkat. A bevezetés óta a közreműködők bővítési javaslatokat nyitottak (tipizált kapcsolati él, ügynök-útmutatás jelzőmezők, opcionális törlés-harmónia profil, .okfignore konvenció és még sok más), új minta csomagokat küldtek, és elkezdtek katalogizálni az OKF ökoszisztéma eszközeit, amelyeket a Google-n kívül építettek. Ezek a hozzájárulások és a közreműködői visszajelzések egy nagyobb problémára is reflektáltak az OKF-fel kapcsolatban: ha az ügynökök írnak a korpuszba, akkor valóban megbízható-e? A legértékesebb OKF csomagokat nem írják kézzel egyszer és olvassák örökké. Ezeket folyamatosan írják, ügynökök által, és egy másik ügynöksorozat fogyasztja. Egy ember által írt wiki oldal implicit garanciát jelent: egy személy írta, és felelősségre vonható, ha hibás. Amikor egy ügynök ezer koncepciót generál egy éjszaka alatt, ez a garancia eltűnik. A felelősségvállalás érdekében egy fogyasztónak (gyakran egy másik ügynöknek) minden koncepciót explicit jelek alapján kell megítélnie, és öt kérdésre kell válaszolnia: Miből készült? (származás) Mennyire bízhatok benne? (bizalom) Még mindig igaz? (frissesség) Ez a jelenlegi verzió? (életciklus) Ezt a számot úgy állították elő, ahogy mondtuk, hogy kell? (megerősítés) Az OKF v0.2-ben most már lehetséges, hogy mind az öt kérdésre választ adjunk az elülső rész alapján, míg a formátum továbbra is minimálisan véleményalkotó, mint a v0.1. Szókincset ad hozzá, nem szabályokat: a típus továbbra is az egyetlen kötelező mező, minden új mező választható, a testreszabott kulcsok továbbra is megmaradnak, nem elutasítva, és egy csomag, amely nem fogadja el a kiegészítéseket, pontosan olyan érvényes, mint a v0.1 alatt volt. Minden új dolog az alábbiakban opcionális, de most már van értelme a hiányának: egy nem ellenőrzött koncepció megkülönböztethető egy ellenőrzöttől (bár a különbség miatt soha nem utasítják el). Az ábrázolás a v0.1-ben már tartalmazta a metainformációkat az elülső részben: típus, cím, leírás, forrás, címkék. Ezek a mezők egy koncepciót írnak le: mi az, és mire mutat. A v0.2 hozzáad egy második típusú elülső rész mezőt, amelyet arra használnak, hogy döntsön valamiről egy koncepcióval kapcsolatban, mielőtt elolvassa: ki állította elő, ellenőrizték-e, hogy még aktuális-e, és hogyan kell kiszámítani a jelentett értéket. Azért tartoznak ezek a mezők az elülső részhez, mert a koncepcióval való legtöbb interakció soha nem terjed ki a fájl törzsének információira. Egy fogyasztónak, legyen az egy személy, determinisztikus kód vagy ügynök, aki keresés és felfedezés közben átvizsgál, először el kell döntenie, hogy egy koncepció egyáltalán releváns-e. Minden koncepcióban tömörnek kell lennie, de az elülső résznek szűkebb feladata van, hogy pontosan a szükséges jeleket kiemelje a relevancia és megbízhatóság döntéséhez, így olcsón és gyakran elkészíthető, anélkül, hogy kódexet költene a prózára. A tartalom, amelyet teljes terjedelemben el kell olvasni, a törzsben marad, és csak akkor érhető el, ha a koncepciót választották. A bizalom olyan dologgá válik, amelyre szűrhetné, mielőtt elkezd olvasni. Az alábbi részeket a konkrétumok érdekében minden példa egy kicsi OKF v0.2 csomagból származik, amelyet a poszt kísérőjeként készítettünk: acme_retail, egy fiktív amerikai kiskereskedelmi cég közös tudása az AI-támogatott analitikához a BigQuery-n keresztül: kód_blokk )])]> Minden következő szakasz bemutatja a megfelelő fájlt. Itt van a tables/orders.md, egy koncepció, amely az új jeleket hordozza: kód_blokk )])]> Mindegyik család válaszol az öt kérdés egyikére. Származás: források, nem pontszám Az új forrásmező rögzíti azokat az anyagokat, amelyekből egy koncepció származik: egy külső dokumentum, egy csomag-viszonyított útvonal, vagy akár egy terjedelem leírója, mint például az X projekt összes lekérdezése. Ugyanakkor egy bejegyzés objektív hitelességi jeleket hordozhat: szerző, használati_ szám, legutóbbi_módosítás. Itt az tudatos választás az, amit nem adtunk hozzá. Az OKF a jeleket rögzíti, nem egy hitelességi pontszámot. A pontszám szubjektív, nem terjeszthető át a fogyasztók között, és elavul a pillanatban, ahogy rögzítik. Ehelyett a hitelességet a jelekből vezetik le, akármennyire is fogyasztanak; ugyanúgy, ahogy jobban bíznál egy gyakran használt, nemrég frissített, hitelesen írt forrással, mint egy névtelen forrással. És amikor a törzs egy konkrét forrást idéz, ezt egy szokásos markdown lábjegyzetek segítségével teszi, amely a forrás azonosítójához ( [^export-schema] ) van kulcsolva, így az attributions minden állítás után van, nem pedig egy lógó lista az alján. Bizalom: generált, ellenőrzött A bizalmat két mezővel állítják fel, szándékosan elkülönítve, mivel aki ír valamit, az nem feltétlenül az, aki megerősíti: generált: { by, at }: hogyan készült a jelenlegi tartalom, és mikor változott lényegesen utoljára. ellenőrzött: [ { by, at } ]: a forrásokkal vagy az alapul szolgáló erőforrással szembeni független megerősítések listája; egy emberi jóváhagyás, egy éjszakai pénzügyi folyamat, vagy mindkettő. Az ellenőrzöttekből a fogyasztó egy bizalmi szintet derivál: egyetlen ellenőrzött kulcs sem ellenőrzött; csak gépi szereplők általi megerősítés gépi megerősített; ember általi megerősítés: a szereplő emberi felülvizsgálaton esett át. A szintek tanácsadó jelek, nem hozzáférési vezérlés, de lehetővé teszik a fogyasztónak, hogy csak a felszíni emberi felülvizsgálati metrikákat mutassa az ügyvezető irányítópulton, mint elülső rész szűrőt. Az acme_retail: metrics/revenue.md a referencia ügynök által írt és a pénzügyi alelnök által ellenőrzött, ami a human-reviewed szintbe helyezi. Az ügyvezetői irányítópult fogyasztója, amely bizalmi szintű szűrővel van konfigurálva, megjeleníti; egy ideiglenes tesztkörnyezet alacsonyabb szintű koncepciókat fogadhat: kód_blokk )])]> Frissesség és életciklus: elavult_ után, státusz Az OKF v0.2 a frissességet és az életciklust az elavult_ után és státusz mezőkkel állapítja meg. státusz egy koncepciót vezet végig: vázlat → stabil → elavult (a hiányzó státusz stabil). elavult_ után egyetlen abszolút dátum. Szándékosan választottunk egy abszolút dátumot a relatív TTL ellen: az elavultság egy egyszerű dátum-összehasonlítássá válik, anélkül, hogy a koncepció olvasásának idejére hivatkoznánk, ami pontosan az a fajta determinizmus, amire egy nem-LLM fogyasztónak szüksége van. Az acme_retail: metrics/revenue.md és metrics/gross-margin.md mindkét elavult_ után dátumot hordoz: 2026-12-31, mert az Acme pénzügyi csapata minden januárban újbóli jóváhagyásra keresi az alapvető politikákat. 2027-01-01-én mindkét koncepcióújra ellenőrzés nélkül kiszolgálás előtt megköveteli a FY2027 politikát. És a metrics/gross-margin-legacy.md státusz: elavult. Az Acme 2026 februárjában megváltoztatta a költségallokációs standardját (a régi formula kizárta a szállítást és a teljesítést az eladott termékek költségéből). A hagyományos definíciót a történelmi lekérdezés reprodukálhatóságának megőrzésére őrzik meg, de nem kerül bemutatásra az új munkákban: kód_blokk )])]> Megerősítés: Ezt a számot a jóváhagyott módon számolták-e ki? A származás válaszol arra, hogy honnan származott egy állítás. A megerősítés egy nehezebb kérdésre válaszol, amely azonnal fontos, amikor egy ügynök dollárértéket jelent: ezt a számot a módon állították-e elő, ahogy mondtuk, hogy kell lennie, vagy az ügynök improvizált a saját SQL-jével? Az OKF v0.2 bevezeti az új koncepciótípust, a Megerősített Számítást. Ez nemcsak azt hordozza, hogy egy érték mit jelent, hanem egy jóváhagyott módot is a kiszámítására, és az eszközöket arra, hogy ellenőrizzük, hogy a jóváhagyott dolog valóban működött. Íme: acme_retail/computations/revenue-ytd.md: kód_blokk = 30\r\n AND EXTRACT(YEAR FROM o.order_ts) = @year), (’language’, ‘’), (‘caption’, )])]> Az ügynök csak a deklarált paramétereket töltheti ki; soha nem szerkesztheti vagy írhatja a számítást. Egy fogyasztó futtatja a számítást az végrehajtón keresztül, amely visszaad egy nyugtát (itt: egy BigQuery job_id, az SQL, amelyet valóban végrehajtottak, és az eredmény). Ezt követően egy determinisztikus, nem-LLM megerősítő megvizsgálja ezt a nyugtát és visszaadja az ítéletet: a futott lekérdezés egyenlő volt-e az állítólagos paraméterekkel rendelkező jóváhagyott számítással, és a megjelenített érték megegyezik-e a nyugta hiteles forrásával? Mivel az összehasonlítás mechanikus, egy átdolgozott lekérdezés, egy kicserélt számítási fájl vagy egy módosított függőség nem teljesíti a tesztet. Az acme_retail: a megerősítő a attesters/sql_equality.py-k szinten kanonizálja mindkét SQL-t (levágja a megjegyzéseket, összeomlasztja a szóközöket, nagybetűsre állítja a tudott kulcsszavakat) és megtagadja az ok visszaadását, ha a kanonikus formák eltérnek. Egy kicserélt táblanév, egy hozzáadott szűrő, egy eltávolított JOIN mind elutasítja a megerősítést. A fogyasztó megtagadja az érték megjelenítését, amikor az ítélet hamis. Míg ebben a példában a BigQuery-t (és SQL-t) használtuk, az elv szándékosan rugalmas. A megerősített számítások megfelelhetnek a szemantikus modellek meghívásának (Looker, AtScale, vagy más rendszerekben), strukturált tudásgrafikonok lekérdezésének, vagy akár tetszőleges API-hívásoknak. Lényeges, hogy az OKF rögzíti a számítást és annak ellenőrzésének módját; soha nem végrehajt semmit önmagában. A megerősítés megkülönböztethető az ellenőrzéstől: az ellenőrzött megerősíti, hogy a definíció még mindig megfelel a politikának (lassú, dokumentum-szintű, a csomagban tárolva); a megerősítés megerősíti, hogy egyetlen futás helyesen állította elő az értéket (minden egyes hívás, futási idő, soha nem tárolódik a csomagban). Egy elavult definíció még mindig tisztán tud megerősíteni; egy frissen ellenőrzött definíció minden futásnál megerősítést igényel. Ezért létezik mindkettő. Amit v0.2-vel kiadunk Az OKF v0.1-hez hasonlóan a referencia megvalósítások szándékosan bizonyítékok a fogalomra; semmi az OKF-ban nem követeli meg őket. Íme, mi változik a Github repóban: a reference_agent most az állam és a bizalom családokat generálja, ahogyan generál, így egy frissen elindított csomag generált forrásokkal és már helyrajzi hivatkozásokkal érkezik. A statikus vizualizáló a bizalmi szintet, státuszt és elavultságot emeli ki a koncepció grafikon mellett, így ezek a jelek láthatóak, nem csupán értelmezhetőek. Frissített mintacsomagok (GA4 e-kereskedelem, Stack Overflow, Bitcoin és az acme kiskereskedelmi példa, amelyet ebben a blogbejegyzésben használtunk) tartalmazzák a v0.2 mezőket. A Tudás Katalógus demója megmutat egy csomagot, amely körbe-körbe halad a Google Cloud Tudás Katalógusán (korábban Dataplex néven ismert): tiszta OKF a lemezen, bizalom és származási jelek megőrízve a katalóguson keresztül és vissza. Kompatibilitás a v0.2 egy kisebb verzióemelés, amely kiegészítő, visszafelé kompatibilis, két szándékos átnevezéssel: a timestamp helyébe a generated.at lép, és a body # Citations lista helyét a források veszik át; mindkét esetben egy v0.2-es fogyasztó vissza tud térni a v0.1-es formához. A v0.1-es csomag változatlanul beépíthető. Hová megyünk innen Olvasd el a specifikációt (még mindig rövid). Írj egy előállítót, amely bizalmi jeleket bocsát ki a forrásszerkezetedhez. Írj egy fogyasztót, amely szűr ezekre. Próbálj ki egy Megerősített Számítást a saját pénzügyi definícióid ellen. Készítsd el a problémákat, küldj PR-t, javasolj bővítéseket. Egy lingua franca csak annyira jó, amennyien beszélnek róla, és most már ők is ellenőrizhetik egymás munkáját. OKF v0.2 specifikáció, minták és referencia megvalósítások: github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf