Google ने Open Knowledge Format जारी किया - AI एजेंटों के लिए ज्ञान साझा करने का मानक

 (cloud.google.com)
5 पॉइंट द्वारा GN⁺ 4 시간 전 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • यह एक vendor-neutral open specification है जो अलग-अलग निर्माताओं द्वारा लिखी गई wiki को बिना अनुवाद कई agents द्वारा उपयोग करने योग्य बनाती है, और LLM-wiki pattern को portable और interoperable फ़ॉर्मैट में औपचारिक रूप देती है
  • OKF v0.1 ज्ञान को YAML frontmatter सहित markdown फ़ाइलों की directory के रूप में व्यक्त करता है, और जटिल compression scheme, नया runtime, या अनिवार्य SDK के बिना काम करता है
  • संगठन का आंतरिक ज्ञान metadata catalog, wiki, code comments, और कुछ senior engineers के दिमाग जैसी खंडित प्रणालियों में बिखरा होता है, इसलिए agents को हर बार वही context जोड़ने की समस्या फिर से हल करनी पड़ती है
  • समाधान कोई नई knowledge service नहीं बल्कि स्वयं format है, जिसे कोई भी बिना SDK के produce कर सकता है, बिना integration के consume कर सकता है, और version control में code के साथ manage कर सकता है
  • इसे open standard के रूप में जारी किया गया है, इसलिए इसका मूल्य producer-consumer ecosystem के विस्तार से तय होगा

पृष्ठभूमि: खंडित context environment

  • foundation models आगे बढ़ने के बावजूद relevant context की कमी के कारण, खासकर agent systems बनाते समय, उनकी performance सीमित रहती है
    • वे code लिख सकते हैं, documents का summary बना सकते हैं, datasets का analysis कर सकते हैं, लेकिन सटीक और actionable परिणाम देने के लिए सही जानकारी चाहिए
  • संगठन में model जिन जानकारियों का उपयोग करता है, वे अधिकांशतः आंतरिक ज्ञान होती हैं, जैसे table schema, business metrics का अर्थ, incident runbook, दो systems के बीच join path, पुराने API के deprecation notice आदि
  • ऐसे knowledge units जिन systems में बिखरे होते हैं, उनके उदाहरण
    • अपने API वाला metadata catalog
    • wiki, third-party systems, shared drives
    • code comments, docstring, notebook cells
    • कुछ senior engineers का दिमाग
  • "event stream से weekly active users (WAU) कैसे calculate किए जाते हैं" जैसे सवाल का जवाब देने के लिए agent को आपस में असंगत surfaces से उत्तर जोड़ना पड़ता है
    • हर vendor अपना catalog, अपना SDK, और अपना knowledge graph schema देता है, इसलिए ज्ञान products और organizations के बीच portable नहीं होता
  • नतीजतन हर agent builder वही context assembly समस्या दोहराता है, catalog vendors वही data model फिर से बनाते हैं, और ज्ञान उसी surface में फँसा रहता है जहाँ वह बनाया गया था

living wiki के रूप में ज्ञान

  • development teams एक ही facts को बार-बार खोजने के बजाय agents को एक shared markdown library देने की दिशा में बढ़ रही हैं, जो समय के साथ और उपयोगी होती जाती है
    • agent अपने files पढ़ने और अपडेट करने जैसे काम संभालता है, जबकि team content को curate करती है और उसे code की तरह manage करती है
  • Andrej Karpathy ने LLM Wiki gist में यह विचार रखा था
    • उन्होंने लिखा कि "LLM ऊबता नहीं, cross-reference updates भूलता नहीं, और एक साथ 15 files संभाल सकता है"
    • जो bookkeeping काम इंसानों को personal wiki छोड़ने पर मजबूर करता है, वही काम LLM बहुत अच्छी तरह करता है
  • यही knowledge-wiki pattern अलग-अलग नामों से बार-बार दिखाई देता है
    • coding agents से जुड़ा Obsidian vault
    • AGENTS.md / CLAUDE.md प्रकार की convention files
    • वे artifact repositories जिनमें index.md, log.md होते हैं और जिन्हें agent काम शुरू करने से पहले देखता है
    • data teams के भीतर "metadata as code" repositories
  • यह pattern शक्तिशाली है, लेकिन हर उदाहरण के bespoke होने की सीमा है
    • markdown, frontmatter, cross-links जैसी बनावट मिलती-जुलती है, लेकिन उन्हें मिलकर काम करने के लिए design नहीं किया गया
    • किन fields का होना ज़रूरी है या filenames का क्या अर्थ है, इस पर सहमति नहीं है; इसलिए ज्ञान मूल team के भीतर silo हो जाता है और नए agents बनाते समय काम दोहराना पड़ता है

ज़रूरत service की नहीं, format की है

  • समाधान कोई और knowledge service नहीं, बल्कि ज्ञान को व्यक्त करने वाला format है, जिसे ये शर्तें पूरी करनी चाहिए
    • कोई भी बिना SDK के produce कर सके
    • कोई भी बिना integration के consume कर सके
    • systems, organizations, और tools के बीच ले जाने पर भी बना रहे
    • जिस code को describe करता है, उसके साथ version control में मौजूद रहे
    • इंसान उसे पढ़ सकें और agents उसे parse कर सकें, और वही files बिना translation layer के इस्तेमाल हों
  • OKF design के स्तर पर इन शर्तों को पूरा करता है

OKF कैसे काम करता है: एक स्क्रीन में समाई design

  • OKF bundle एक concept को व्यक्त करने वाली markdown files की directory है, जिसमें table, dataset, metric, playbook, runbook, API जैसे हर target को शामिल किया जा सकता है
    • हर concept एक file है, और file path ही उसकी identity है
    • directory structure के उदाहरण में sales के नीचे datasets, tables, metrics folders और orders.md, customers.md, weekly_active_users.md जैसी files रखी जा सकती हैं
  • हर concept document में structured fields के लिए YAML front matter block और बाकी सामग्री के लिए markdown body होती है
    • front matter field उदाहरण: type (BigQuery Table), title (Orders), description, resource (console URL), tags ([sales, revenue]), timestamp (2026-05-28T14:30:00Z)
    • body में Schema (order_id, customer_id columns के type और description), Joins (customer_id के आधार पर customers join) जैसी चीजें शामिल हो सकती हैं
  • concepts सामान्य markdown links से एक-दूसरे से जुड़ते हैं, जिससे directory केवल file system parent/child संबंध से आगे बढ़कर एक समृद्ध graph बन जाती है
    • bundle में वैकल्पिक रूप से index.md (agent navigation के समय progressive disclosure के लिए) और log.md (change history के लिए) files हो सकती हैं
  • v0.1 की पूरी specification, जिसमें conformance criteria, cross-link rules, और कुछ reserved filenames शामिल हैं, एक पेज में समाई हुई है

design के तीन सिद्धांत

  • न्यूनतम निर्देशात्मकता (Minimally opinionated)

    • OKF हर concept के लिए केवल एक चीज़ अनिवार्य करता है: type field
    • कौन-कौन से type होंगे, कौन से fields जोड़े जाएँगे, और body में कौन से sections होंगे, यह producer पर छोड़ा गया है
    • specification केवल interoperable surface को define करती है, content model को नहीं

  • producer/consumer independence

    • ज्ञान लिखने वाले और उसे उपयोग करने वाले पक्षों को साफ़ तौर पर अलग किया गया है
    • इंसानों द्वारा हाथ से लिखे bundle को AI agents consume कर सकते हैं, metadata export pipeline द्वारा बनाए गए bundle को visualizer में explore किया जा सकता है, और एक LLM द्वारा synthesized bundle को दूसरा LLM query कर सकता है
    • format ही contract है, और दोनों सिरों के tools को स्वतंत्र रूप से बदला जा सकता है

  • platform नहीं, format

    • यह किसी खास cloud, database, model provider, या agent framework पर निर्भर नहीं है
    • इसे पढ़ने, लिखने, या serve करने के लिए proprietary account या SDK की ज़रूरत नहीं है
    • knowledge format का मूल्य उसके owner से नहीं, बल्कि इस बात से आता है कि कितने लोग उस format का उपयोग करते हैं, इसलिए इसे open standard के रूप में जारी किया गया है

specification के साथ क्या दिया गया है

  • format को ठोस रूप देने के लिए producer और consumer दोनों पक्षों की reference implementations जारी की गई हैं
  • Enrichment agent: यह BigQuery datasets को scan करता है, हर table और view के लिए OKF concept documents का draft बनाता है, फिर दूसरे LLM pass में official docs को crawl करके citations, schema, और join paths के साथ हर concept को समृद्ध करता है
  • Static HTML visualizer: यह किसी भी OKF bundle को self-contained single-file interactive graph view में बदल देता है; backend की ज़रूरत नहीं, viewer-side install की ज़रूरत नहीं, और data page से बाहर नहीं जाता
  • तुरंत explore किए जा सकने वाले 3 sample bundles: GA4 e-commerce, Stack Overflow, और Bitcoin public datasets, जिन्हें reference agent ने generate किया और उपयुक्त OKF के जीवंत उदाहरण के रूप में repository में commit किया
  • इन्हें जानबूझकर proof of concept रखा गया है
    • agent केवल OKF production का एक तरीका दिखाता है, यह किसी विशेष framework या LLM को अनिवार्य नहीं करता
    • visualizer केवल consumption का एक तरीका दिखाता है, यह HTML या graph view को अनिवार्य नहीं करता
    • उम्मीद है कि producer-consumer ecosystem दिए गए दायरे से कहीं आगे बढ़ेगा

आगे की दिशा

  • OKF v0.1 कोई पूर्ण मानक नहीं बल्कि शुरुआती बिंदु है, और जैसे-जैसे अधिक producers और consumers आएँगे तथा agents को वास्तव में किस तरह के knowledge representation की ज़रूरत है यह सीखा जाएगा, यह विकसित होगा
  • चाहे आप knowledge catalog बना रहे हों, enrichment pipeline, या AI agents के लिए wiki, format को पहले दिन से open रखना ज़रूरी है, तभी वह अपने नाम के अनुरूप होगा
  • सुझाए गए कदम
    • specification पढ़ें (छोटी है)
    • source systems, databases, और documentation sites के लिए producer लिखें
    • viewer, search index, और bundle पर reasoning करने वाले agents जैसे consumer लिखें
    • reference implementations को अपने data पर लागू करें
    • issues उठाएँ, PR भेजें, और extensions प्रस्तावित करें (specification version-controlled है और backward-compatible growth के लिए design की गई है)
  • repository, specification, और sample bundles GitHub पर public हैं, और Google Cloud का Knowledge Catalog OKF को ingest करके agents को serve करने के लिए update किया गया है
  • असली योगदान स्वयं format है; दिए गए tools का उद्देश्य format को व्यावहारिक बनाना और प्रयोग की लागत कम करना है, और OKF को भविष्य के knowledge exchange की lingua franca के रूप में design किया गया है

संबंधित पढ़ाई

2 टिप्पणियां

 
leothelion 1 시간 전

शायद यह उसी की तरफ़ से किया गया सबसे अच्छा प्रयास है, जो .claude और .agent का फ़ायदा नहीं उठा सका।
 
GN⁺ 4 시간 전
Hacker News राय

  • इस OKF spec की सादगी अच्छी है, लेकिन यह भरोसा नहीं है कि हर चीज़ को “सिर्फ Markdown” में ठीक से व्यक्त किया जा सकता है
    हाल में मेरी दिलचस्पी इस बात में बढ़ी है कि concepts को इस तरह कैसे व्यक्त किया जाए कि AI प्रभावी और token-efficient तरीके से collaborative contribution कर सके, और आम तौर पर मैं ऐसे तरीकों की तलाश में रहता हूँ जिनसे किसी चीज़ को semi-structured sequential text में अच्छी तरह व्यक्त किया जा सके। लेकिन इस प्रक्रिया में इंसानों के लिए knowledge representation का अनुभव कुर्बान नहीं होना चाहिए
    खासकर अगर पारंपरिक रूप से developers न रहे roles को भी contribute करना हो, तो “अजीब text format + git” मौजूदा authoring और visualization tools की तुलना में काफी खराब लग सकता है
    आने वाले कुछ वर्षों में अलग-अलग तरह के knowledge को semantic तरीके से व्यक्त करने वाले standards कैसे उभरते हैं, यह देखने की उत्सुकता है
    देखने लायक सफल उदाहरणों में schema/E-R के लिए DBML, architecture के लिए LikeC4, और Mermaid जैसे diagram-as-code तरीके हैं। LLM भी इन formats को अच्छी तरह समझते हैं, और छोटे EBNF prompt से इन्हें बताया भी जा सकता है। महत्वपूर्ण बात यह है कि इनके पास इंसानों के लिए अच्छी visualization form भी होती है, इन्हें Markdown के भीतर code block में natural language के ठीक बगल में रखा जा सकता है, और LLM syntax लिखने में भी मदद कर सकते हैं
    ज्यादा कठिन चीज़ें वे हैं जिनमें complex spreadsheet या Miro की तरह spatial layout और color में implicit meaning होता है। अभी तक उसका अच्छा विकल्प नहीं मिला है
    data engineering क्षेत्र में मैंने जो सीधे आज़माया है, वह AI और इंसानों के साथ मिलकर source-target mapping और transformation को संभालने के लिए https://equalexperts.github.io/satsuma-lang/ है। यह natural language की अनुमति देने वाला संक्षिप्त structured text representation है, और अच्छी visualization तथा LSP/grammar tools भी देता है, ताकि agents को lineage, completeness, या undefined sources जैसी चीज़ों पर reasoning करने के लिए बड़े documents को token-inefficient तरीके से काटना न पड़े

    • OKF ठीक लगता है, लेकिन Markdown से बँधा हुआ है
      Markdown document के front YAML में type जोड़ दें तो वह OKF document बन सकता है
      Markdown prose या Markdown code block के अंदर भी इस्तेमाल हो सके, और text field वाली कहीं भी उपयोग किया जा सके, ऐसी knowledge graph language कैसी रहेगी
      minimal language https://ddot.it में Markdown की दुनिया के बाहर की files, URLs, और simple labels तक को link किया जा सकता है। OKF की तरह यह भी बस एक format है
      स्पष्ट कर दूँ, वह छोटी spec मैंने ही लिखी थी
    • entities के बीच label लगे संबंध दिखाने वाले graph format के बिना knowledge को अच्छी तरह व्यक्त नहीं किया जा सकता
    • Markdown, LLM और इंसानों के बीच interoperability का de facto format है
      मैं इस बात से सहमत हूँ कि यह हर चीज़ को अच्छी तरह व्यक्त नहीं कर सकता, लेकिन यह मूल मुद्दे से थोड़ा हटकर है। Markdown इंसानों और AI models दोनों के लिए lowest common denominator है, इसलिए लगता है कि वही जीत रहा है

  • हर 10 साल में RDF/OWL semantic web formats को फिर से देखना मजेदार होता है
    कभी न कभी उनमें से कोई साल सचमुच उनका साल होगा
    https://en.wikipedia.org/wiki/Semantic_Web

  • मूल लेख में कई broken links थे, इसलिए repository छोड़ रहा हूँ
    https://github.com/GoogleCloudPlatform/knowledge-catalog
    spec: https://github.com/GoogleCloudPlatform/knowledge-catalog/blo...

  • मेरी समझ के अनुसार, हम 3D से आगे देख नहीं सकते, इसलिए यह मूल रूप से इंसानों के लिए एक scaffolding के करीब है
    उम्मीद है कि अगर हम चीज़ों को ठीक-ठाक ढंग से व्यवस्थित कर दें, तो agents Markdown लेकर memory में graph infrastructure बना सकेंगे या उसे Neo4j में store कर सकेंगे

  • क्या Markdown का कोई variant, जैसे CommonMark, निर्दिष्ट किया गया है?
    शुरुआती कुछ पन्ने सरसरी तौर पर देखने पर मुझे उससे जुड़ी बात नहीं दिखी, लेकिन spec के लिए यह काफी महत्वपूर्ण हिस्सा लगता है

  • Google ने आखिरकार YAML frontmatter के साथ Markdown ही घोषित किया है। कृपया तालियाँ बजाएँ। इसके लिए 15KB की spec?
    अगर सब लोग “अरे, एक indentation छूट गई” वाली YAML का इस्तेमाल बंद कर दें, तो मैं कम व्यंग्य करूँगा

  • जिसने बहुत-से ऐसे PDF देखे हों जिन्हें Markdown में “translate” करना पड़ा, उसके नज़रिए से यह अजीब चुनाव लगता है
    समझ आता है कि उद्देश्य AI के लिए आसान access देना है, लेकिन अगर models को train ही करना है, तो फिर बेहतर format पर train क्यों नहीं किया जाता, यह सवाल उठता है
    Markdown काफ़ी सीमित है, और उदाहरण के लिए nested tables जैसी चीज़ें render भी नहीं कर सकता। अगर “open knowledge” का लक्ष्य AI है, तो यह भी स्पष्ट नहीं कि ऐसा format क्यों चुना जाए जिसे इंसान वास्तव में पढ़ें ही नहीं

  • यह approach पसंद आई। hierarchical knowledge organization मुझे बहुत पसंद है
    फिलहाल Claude की knowledge management abstraction लगभग पूरी तरह टूटी हुई लगती है। जब एक साथ कई coders चलाने हों या 1,000 से अधिक skills बनानी हों, तब यह बात साफ़ दिखती है। उदाहरण: https://news.ycombinator.com/item?id=48407998

  • barrasindustries.com/okfind/ देखना अच्छा रहेगा
    यह OKF bundle registry के लिए एक idea है