Google, Open Knowledge Format'ı duyurdu - AI ajanları için bilgi paylaşım standardı

 (cloud.google.com)
5 puan yazan GN⁺ 3 시간 전 | 2 yorum | WhatsApp'ta paylaş
  • Farklı üreticilerin hazırladığı wikilerin çeviri olmadan birden çok ajan tarafından tüketilebilmesini sağlayan satıcıdan bağımsız açık bir spesifikasyon; LLM-wiki desenini taşınabilir ve birlikte çalışabilir bir biçimde standartlaştırıyor
  • OKF v0.1, bilgiyi YAML frontmatter içeren bir markdown dosya dizini olarak ifade ediyor ve karmaşık sıkıştırma yöntemleri, yeni bir runtime ya da zorunlu SDK'lar olmadan çalışıyor
  • Kurum içi bilgi; metadata katalogları, wikiler, kod açıklamaları ve bazı kıdemli mühendislerin zihni gibi parçalanmış sistemlere dağılmış durumda olduğu için ajanlar her seferinde aynı bağlamı bir araya getirme sorununu sıfırdan çözmek zorunda kalıyor
  • Çözüm yeni bir bilgi servisi değil, formatın kendisi; böylece herkes SDK olmadan üretebilir, entegrasyon olmadan tüketebilir ve sürüm kontrolünde kodla birlikte yönetebilir
  • Açık standart olarak yayımlandığı için değeri, üretici ve tüketici ekosisteminin genişlemesiyle belirlenen bir yapıya sahip

Arka plan: parçalanmış bağlam ortamı

  • Foundation modeller gelişse bile, özellikle ajan sistemleri kurarken ilgili bağlam eksikliği nedeniyle performansları sınırlanıyor
    • Kod yazma, doküman özetleme ve veri kümesi analizi mümkün olsa da doğru ve uygulanabilir sonuçlar için doğru bilgi gerekiyor
  • Kurumlarda modellerin kullandığı bilgi çoğunlukla iç bilgi ve buna tablo şemaları, iş metriklerinin anlamı, incident runbook'ları, iki sistem arasındaki join yolları ve eski API'lerin kullanım dışı bırakılma duyuruları dahil
  • Bu bilgi parçalarının dağınık olduğu sistemlere örnekler
    • Kendi API'sine sahip metadata katalogları
    • Wikiler, üçüncü taraf sistemler ve paylaşımlı sürücüler
    • Kod açıklamaları, docstring'ler ve notebook hücreleri
    • Bazı kıdemli mühendislerin zihni
  • "Event stream'den haftalık aktif kullanıcı (WAU) nasıl hesaplanır?" sorusunu yanıtlamak için bir ajanın birbiriyle uyumlu olmayan yüzeylerden yanıtı derlemesi gerekiyor
    • Tüm satıcılar kendi kataloglarını, kendi SDK'larını ve kendi bilgi grafiği şemalarını sunuyor; bu yüzden bilgi ürünler ve kurumlar arasında taşınamıyor
  • Sonuç olarak tüm ajan geliştiricileri aynı bağlam derleme sorununu tekrar tekrar çözüyor, katalog sağlayıcıları aynı veri modelini yeniden icat ediyor ve bilgi üretildiği yüzeyin içinde kilitli kalıyor

Canlı bir wiki olarak bilgi

  • Geliştirme ekipleri, aynı dokümanda aynı olguları tekrar tekrar aramak yerine zamanla daha kullanışlı hale gelen paylaşılan bir markdown kütüphanesini ajanlara sunma yaklaşımına yöneliyor
    • Ajanlar kendi dosyalarını okuyup güncelleyen angarya işleri üstlenirken ekipler içeriği kürate ediyor ve kod gibi yönetiyor
  • Andrej Karpathy bu fikri LLM Wiki gist içinde ortaya koydu
    • "LLM'ler sıkılmaz, çapraz referansları güncellemeyi unutmaz ve aynı anda 15 dosyayla çalışabilir" diye yazdı
    • İnsanların kişisel wiki tutmaktan vazgeçmesine neden olan kayıt tutma (bookkeeping) işleri, tam da LLM'lerin iyi yaptığı alanlar
  • Aynı bilgi-wiki deseni farklı adlarla tekrar tekrar ortaya çıkıyor
    • Kodlama ajanlarına bağlı Obsidian vault
    • AGENTS.md / CLAUDE.md türü konvansiyon dosyaları
    • Ajanların işe başlamadan önce başvurduğu index.md, log.md artefact depoları
    • Veri ekipleri içindeki "metadata as code" depoları
  • Bu desen güçlü olsa da her örneğin özel tasarlanmış (bespoke) olması bir sınırlama yaratıyor
    • Markdown, frontmatter ve çapraz linkler gibi biçimler benzer olsa da birlikte çalışacak şekilde tasarlanmamışlar
    • Her dokümanda hangi alanların bulunması gerektiği ya da dosya adlarının ne anlama geldiği konusunda ortak bir uzlaşma olmadığından bilgi yine ekibin içinde silo halinde kalıyor ve yeni bir ajan kurarken tekrar iş çıkıyor

Gereken şey servis değil, format

  • Çözüm bir başka bilgi servisi değil, bilgiyi ifade eden bir format ve şu gereksinimleri karşılaması gerekiyor
    • Herkes tarafından SDK olmadan üretilebilmeli
    • Herkes tarafından entegrasyon olmadan tüketilebilmeli
    • Sistemler, kurumlar ve araçlar arasında taşınırken korunmalı
    • Açıkladığı kodla birlikte sürüm kontrolünde bulunmalı
    • İnsan tarafından okunabilir, ajan tarafından parse edilebilir olmalı; aynı dosya çeviri katmanı olmadan kullanılabilmeli
  • OKF, tasarımı gereği bu gereksinimleri karşılayan bir format

OKF nasıl çalışıyor: tek ekranda görülebilen tasarım

  • Bir OKF bundle'ı, bir concept'i ifade eden markdown dosyaları dizinidir; tablo, veri kümesi, metrik, playbook, runbook, API gibi yakalanmak istenen her şeyi kapsar
    • Her concept tek bir dosyadır ve dosya yolu, concept'in kimliğidir
    • Dizin yapısı örneği: sales altında datasets, tables, metrics klasörleri ile orders.md, customers.md, weekly_active_users.md gibi dosyalar
  • Her concept dokümanı, yapılandırılmış alanlar için bir YAML front matter bloğu ve geri kalanı içeren markdown gövdesinden oluşur
    • Front matter alan örnekleri: type (BigQuery Table), title (Orders), description, resource (console URL), tags ([sales, revenue]), timestamp (2026-05-28T14:30:00Z)
    • Gövdede Schema (order_id, customer_id sütunları ile tipleri ve açıklamaları), Joins (customer_id üzerinden customers join'i) gibi bilgiler yer alır
  • Concept'ler sıradan markdown linkleriyle birbirine bağlanır; bu da dizini dosya sisteminin üst/alt ilişkisinden daha zengin bir graph'a dönüştürür
    • Bundle, isteğe bağlı olarak index.md (ajan keşfi sırasında kademeli görünürlük) ve log.md (değişiklik geçmişi) dosyalarını içerebilir
  • v0.1'in tüm spesifikasyonu; uygunluk ölçütleri, çapraz bağlantı kuralları ve az sayıdaki ayrılmış dosya adları dahil olmak üzere tek sayfaya sığıyor

Tasarımın üç ilkesi

  • Asgari düzeyde yönlendirici (Minimally opinionated)

    • OKF'nin tüm concept'ler için zorunlu tuttuğu tek şey type alanı
    • Hangi type'ların var olacağı, hangi ek alanların ekleneceği ve gövdede hangi bölümlerin bulunacağı üreticiye bırakılıyor
    • Spesifikasyon, içerik modelini değil yalnızca birlikte çalışabilirlik yüzeyini tanımlıyor

  • Üretici/tüketici bağımsızlığı (Producer/consumer independence)

    • Bilgiyi yazan taraf ile tüketen tarafı net biçimde ayırıyor
    • İnsanların elle yazdığı bundle'ları AI ajanları tüketebilir, metadata export pipeline'larının ürettiği bundle'lar bir görselleştiricide gezilebilir, bir LLM'in sentezlediği bundle'ı başka bir LLM sorgulayabilir
    • Format sözleşmedir; iki uçtaki araçlar birbirinden bağımsız olarak değiştirilebilir

  • Platform değil format (Format, not platform)

    • Belirli bir bulut, veritabanı, model sağlayıcısı ya da ajan framework'üne bağlı değil
    • Okuma, yazma ya da servis etme için özel bir hesap veya SDK gerektirmiyor
    • Bir bilgi formatının değeri sahibinden değil, onu ne kadar çok tarafın kullandığından gelir; bu nedenle açık standart olarak yayımlandı

Spesifikasyonla birlikte gelenler

  • Formatı somutlaştırmak için hem üretici hem de tüketici tarafında referans implementasyonlar yayımlandı
  • Enrichment agent: BigQuery veri kümelerini dolaşarak tüm tablolar ve view'lar için OKF concept dokümanlarının taslağını çıkarıyor; ardından ikinci bir LLM geçişiyle resmi dokümanları crawl edip alıntılar, şemalar ve join yollarıyla her concept'i zenginleştiriyor
  • Statik HTML görselleştirici: Herhangi bir OKF bundle'ını, kendi içinde her şeyi barındıran tek dosyalık etkileşimli bir graph görünümüne dönüştürüyor; backend gerektirmiyor, görüntüleyici tarafında kurulum istemiyor ve veri sayfanın dışına çıkmıyor
  • Hemen keşfedilebilen 3 örnek bundle: GA4 e-commerce, Stack Overflow ve Bitcoin herkese açık veri kümeleri; referans ajan tarafından üretilip uygun bir OKF'nin canlı örnekleri olarak depoya commit edilmiş durumda
  • Bunlar bilinçli olarak kavram kanıtı (proof of concept) niteliğinde
    • Ajan, OKF üretmenin bir yolunu gösteriyor; belirli bir framework veya LLM'i zorunlu kılmıyor
    • Görselleştirici, tüketmenin bir yolunu gösteriyor; HTML ya da graph görünümünü zorunlu kılmıyor
    • Beklenti, üretici ve tüketici ekosisteminin sunulanların çok ötesine büyümesi

İleriye dönük yön

  • OKF v0.1 tamamlanmış bir standart değil, başlangıç noktası; daha fazla üretici ve tüketici ortaya çıktıkça ve ajanların gerçekten ihtiyaç duyduğu bilgi temsilleri öğrenildikçe evrilecek
  • İster bilgi kataloğu, ister zenginleştirme pipeline'ı, ister AI ajanları için wiki geliştiriliyor olsun; formatın adını hak etmesi için ilk günden açık olarak yayımlanması gerekiyor
  • Önerilen adımlar
    • Spesifikasyonu okuyun (kısa)
    • Kaynak sistemler, veritabanları ve doküman siteleri için producer yazın
    • Görüntüleyici, arama indeksi veya bundle üzerinde akıl yürüten ajan gibi consumer araçları yazın
    • Referans implementasyonu kendi veriniz üzerinde deneyin
    • Issue açın, PR gönderin, genişletme önerin (spesifikasyon sürüm kontrollü ve geriye dönük uyumlu büyüme için tasarlanmış)
  • Depo, spesifikasyon ve örnek bundle'lar GitHub'da açık; ayrıca Google Cloud'un Knowledge Catalog ürünü, OKF'yi toplayıp ajanlara servis edecek şekilde güncellendi
  • Asıl katkı formatın kendisi; sunulan araçlar ise bu formatı hayata geçirmek ve deneme maliyetini düşürmek için var. OKF, gelecekte bilgi alışverişinin ortak dili (lingua franca) olacak şekilde tasarlandı

İlgili okumalar

2 yorum

 
leothelion 1 시간 전

.claude ve .agent akımını kaçıranın elinden gelen en iyi şey bu herhalde
 
GN⁺ 3 시간 전
Hacker News görüşleri

  • Bu OKF spesifikasyonunun sadeliği güzel, ancak her şeyi “sadece Markdown” ile iyi ifade edip edemeyeceğinden emin değilim
    Son zamanlarda yapay zekanın etkili ve token açısından verimli şekilde birlikte katkı sunabilmesi için kavramların nasıl ifade edileceğiyle ilgileniyorum; genelde bir şeyi yarı yapılandırılmış sıralı metin olarak iyi ifade etmenin yollarını arıyorum. Ama bu süreçte insanların gördüğü bilgi ifade deneyiminden ödün verilmemeli
    Özellikle geleneksel olarak geliştirici olmayan rollerin de katkı vermesi gerekiyorsa, “garip bir metin biçimi + git” mevcut yazım ve görselleştirme araçlarından çok daha kötü hissettirebilir
    Önümüzdeki birkaç yılda çeşitli bilgi türlerini anlamsal olarak ifade eden standartların nasıl ortaya çıkacağını görmek heyecan verici olacak
    Referans alınabilecek başarılı örnekler arasında şema/E-R için DBML, mimari için LikeC4 ve Mermaid gibi diagram-as-code yaklaşımları var. LLM’ler de bu tür biçimleri genelde iyi anlıyor; hatta kısa bir EBNF prompt’u ile öğretmek de mümkün. Önemli nokta, bunların insan için okunabilir görselleştirme biçimlerine sahip olması, Markdown içinde doğal dilin yanında doğrudan code block olarak yer alabilmesi ve LLM’lerin söz dizimini yazmaya da yardımcı olabilmesi
    Daha zor olan kısım, karmaşık elektronik tablolar veya Miro gibi mekânsal yerleşim ve rengin örtük anlam taşıdığı şeyler. Bunun için henüz iyi bir alternatif bulamadım
    Veri mühendisliği alanında bizzat denediğim şey, yapay zeka ve insanların birlikte source-target mapping ve dönüşümleri ele alabilmesi için https://equalexperts.github.io/satsuma-lang/ oldu. Bu, doğal dili kabul eden özlü yapılandırılmış bir metin gösterimi; ayrıca iyi görselleştirme ile LSP/söz dizimi araçları da sunuyor, böylece ajanların soy ağacı, bütünlük veya tanımsız kaynaklar gibi şeyler hakkında akıl yürütmek için büyük belgeleri token açısından verimsiz biçimde parçalamasına gerek kalmıyor

    • OKF fena görünmüyor ama Markdown’a bağlı
      Markdown belgesi, baştaki YAML kısmına type eklenirse OKF belgesi olabilir
      Markdown düzyazısı içinde de, Markdown kod blokları içinde de kullanılabilen ve metin alanı olan her yerde çalışabilecek bir bilgi grafiği dili nasıl olurdu diye düşünüyorum
      Minimal bir dil olan https://ddot.it, Markdown dünyasının dışındaki dosyalara, URL’lere ve basit etiketlere kadar bağlantı kurabiliyor. OKF gibi o da yalnızca tek bir biçim
      Belirteyim, o kısa spesifikasyonu ben yazdım
    • Varlıklar arasındaki etiketli ilişkileri gösteren bir grafik biçimi olmadan bilgiyi iyi ifade edemezsiniz
    • Markdown, LLM ile insanın birlikte çalışabildiği fiilî biçim
      Her şeyi iyi ifade edemediğine katılıyorum, ama bu esas noktayı kaçırıyor. Markdown, insanlar ve AI modelleri için en düşük ortak payda olduğu için kazanıyor gibi görünüyor

  • Her 10 yılda bir RDF/OWL semantik web biçimlerine yeniden bakmak eğlenceli
    Bir gün o yıllardan biri gerçekten onların yılı olacak
    https://en.wikipedia.org/wiki/Semantic_Web

  • Asıl yazıda bozuk birkaç bağlantı vardı, bu yüzden depoyu bırakıyorum
    https://github.com/GoogleCloudPlatform/knowledge-catalog
    Spesifikasyon: https://github.com/GoogleCloudPlatform/knowledge-catalog/blo...

  • Benim anladığım kadarıyla, 3 boyutun ötesini göremediğimiz için bu aslında insanlar için bir iskele niteliğinde
    Biz makul ölçüde iyi organize edersek, ajanların Markdown’u alıp bellekte bir grafik altyapısı kurabilmesini veya bunu Neo4j’de saklayabilmesini umuyoruz

  • Markdown’un bir varyantı, örneğin CommonMark, belirtilmiş mi?
    İlk birkaç sayfaya göz attığımda buna dair bir şey görmedim ama bir spesifikasyon için oldukça önemli bir nokta gibi duruyor

  • Google’ın duyurduğu şey sonuçta YAML front matter eklenmiş Markdown. Alkışlarınızı alalım. Bunun için 15 KB’lık bir spesifikasyon ha
    Herkes “ah, bir girintiyi kaçırdım” türü YAML kullanımını bırakabilseydi daha az alaycı olurdum

  • Markdown’a “çevrilmesi” gereken çok PDF gördüğüm için bu bana garip bir seçim gibi geliyor
    Bunun büyük ölçüde AI’nin kolay erişebilmesi için yapıldığını anlıyorum, ama zaten modeli eğitecekseniz neden daha iyi bir biçimle eğitmiyorsunuz diye merak ediyorum
    Markdown oldukça sınırlı; örneğin iç içe tabloları bile render edemiyor. “Açık bilgi”nin amacı AI ise, insanların gerçekten okumayacağı bir biçimi kullanmakta ısrar etmenin gereği var mı, ondan da emin değilim

  • Yaklaşımı beğendim. Hiyerarşik bilgi organizasyonunu çok seviyorum
    Şu anda Claude’un bilgi yönetimi soyutlamalarının neredeyse tamamen bozuk olduğunu düşünüyorum. Aynı anda birden fazla kodlayıcı çalıştırdığınızda veya 1.000’den fazla skill oluşturmanız gerektiğinde bu ortaya çıkıyor. Örnek: https://news.ycombinator.com/item?id=48407998

  • barrasindustries.com/okfind/ adresine bakmak isteyebilirsiniz
    Bu, OKF bundle registry için bir fikir