5 poin oleh GN⁺ 4 jam lalu | 2 komentar | Bagikan ke WhatsApp
  • Spesifikasi terbuka yang netral terhadap vendor ini memungkinkan banyak agen mengonsumsi wiki yang ditulis oleh produsen berbeda tanpa perlu terjemahan, dengan memformalkan pola LLM-wiki ke dalam format yang portabel dan interoperabel
  • OKF v0.1 merepresentasikan pengetahuan sebagai direktori file markdown yang menyertakan YAML frontmatter, dan dapat bekerja tanpa skema kompresi yang rumit, runtime baru, atau SDK wajib
  • Pengetahuan internal organisasi tersebar di sistem yang terfragmentasi seperti katalog metadata, wiki, komentar kode, hingga di kepala beberapa engineer senior, sehingga agen harus terus-menerus memecahkan masalah perakitan konteks yang sama dari nol
  • Jawabannya bukan layanan pengetahuan baru melainkan format itu sendiri, sehingga siapa pun bisa memproduksinya tanpa SDK, mengonsumsinya tanpa integrasi, dan mengelolanya bersama kode dalam version control
  • Karena dirilis sebagai standar terbuka, nilainya ditentukan oleh perluasan ekosistem produsen dan konsumen

Latar belakang: lingkungan konteks yang terfragmentasi

  • Meski model fondasi terus berkembang, performanya tetap dibatasi oleh kurangnya konteks yang relevan, terutama saat membangun sistem agen
    • Menulis kode, merangkum dokumen, dan menganalisis dataset memang memungkinkan, tetapi hasil yang akurat dan bisa dijalankan tetap membutuhkan informasi yang benar
  • Informasi yang digunakan model dalam organisasi sebagian besar adalah pengetahuan internal, seperti skema tabel, arti metrik bisnis, runbook insiden, jalur join antar dua sistem, atau pengumuman penghentian API lama
  • Contoh sistem tempat unit-unit pengetahuan ini tersebar
    • Katalog metadata dengan API miliknya sendiri
    • Wiki, sistem pihak ketiga, dan drive bersama
    • Komentar kode, docstring, dan sel notebook
    • Di kepala beberapa engineer senior
  • Untuk menjawab pertanyaan seperti "bagaimana menghitung pengguna aktif mingguan (WAU) dari event stream", agen harus merakit jawabannya dari permukaan yang tidak saling kompatibel
    • Setiap vendor menyediakan katalog, SDK, dan skema knowledge graph sendiri, sehingga pengetahuan tidak portabel antar produk dan organisasi
  • Akibatnya, setiap pembuat agen mengulang masalah perakitan konteks yang sama, vendor katalog menemukan kembali model data yang sama, dan pengetahuan terkurung di permukaan tempat ia dibuat

Pengetahuan sebagai wiki yang hidup

  • Tim pengembang mulai beralih dari terus mencari fakta yang sama di dokumen yang sama ke cara memberi agen pustaka markdown bersama yang makin berguna seiring waktu
    • Agen menangani pekerjaan rutin membaca dan memperbarui file mereka sendiri, sementara tim mengurasi konten dan mengelolanya seperti kode
  • Andrej Karpathy mengemukakan ide ini dalam gist LLM Wiki
    • Ia menulis bahwa "LLM tidak bosan, tidak lupa memperbarui referensi silang, dan bisa menangani 15 file sekaligus"
    • Pekerjaan bookkeeping yang membuat orang meninggalkan wiki pribadi justru merupakan hal yang dikerjakan LLM dengan baik
  • Pola wiki-pengetahuan yang sama terus muncul kembali dengan berbagai nama
    • Obsidian vault yang terhubung dengan agen coding
    • File konvensi keluarga AGENTS.md / CLAUDE.md
    • Repositori artefak index.md, log.md yang dirujuk agen sebelum bekerja
    • Repositori internal tim data untuk "metadata as code"
  • Polanya kuat, tetapi setiap kasus memiliki keterbatasan karena dibuat khusus (bespoke)
    • Bentuknya mirip, seperti markdown, frontmatter, dan tautan silang, tetapi tidak dirancang untuk saling bekerja sama
    • Tidak ada kesepakatan tentang field yang harus dimiliki setiap dokumen atau arti nama file, sehingga pengetahuan tetap tersilo di dalam tim asalnya dan pekerjaan duplikat muncul saat membangun agen baru

Yang dibutuhkan adalah format, bukan layanan

  • Jawabannya bukan layanan pengetahuan baru, melainkan format untuk merepresentasikan pengetahuan, yang harus memenuhi syarat berikut
    • Siapa pun bisa memproduksinya tanpa SDK
    • Siapa pun bisa mengonsumsinya tanpa integrasi
    • Tetap utuh saat berpindah antar sistem, organisasi, dan alat
    • Ada di version control bersama kode yang dijelaskannya
    • Bisa dibaca manusia dan diparse agen, memakai file yang sama tanpa lapisan terjemahan
  • OKF adalah format yang secara desain memenuhi syarat tersebut

Cara kerja OKF: desain dalam satu layar

  • Bundle OKF adalah direktori file markdown yang merepresentasikan konsep, mencakup apa pun yang ingin ditangkap seperti tabel, dataset, metrik, playbook, runbook, dan API
    • Setiap konsep adalah satu file, dan path file menjadi identitas konsep tersebut
    • Contoh struktur direktori: di bawah sales terdapat folder datasets, tables, metrics serta file seperti orders.md, customers.md, weekly_active_users.md
  • Setiap dokumen konsep terdiri dari blok YAML front matter untuk field terstruktur dan isi markdown untuk sisanya
    • Contoh field front matter: type (BigQuery Table), title (Orders), description, resource (URL konsol), tags ([sales, revenue]), timestamp (2026-05-28T14:30:00Z)
    • Isi dokumen dapat mencakup Schema (kolom order_id, customer_id beserta tipe dan deskripsinya), Joins (join ke customers berdasarkan customer_id), dan lain-lain
  • Konsep dihubungkan satu sama lain lewat tautan markdown biasa, mengubah direktori menjadi graf yang lebih kaya daripada relasi parent/child di file system
    • Bundle juga secara opsional dapat menyertakan file index.md (untuk pengungkapan bertahap saat agen menavigasi) dan log.md (riwayat perubahan)
  • Seluruh spesifikasi v0.1 termuat dalam satu halaman, termasuk kriteria kepatuhan, aturan tautan silang, dan sejumlah kecil nama file yang dicadangkan

Tiga prinsip desain

  • Ketentuan seminimal mungkin (Minimally opinionated)

    • Satu-satunya hal yang diwajibkan OKF untuk semua konsep hanyalah field type
    • Jenis type apa yang ada, field tambahan apa yang dipakai, dan bagian apa yang dimasukkan ke isi dokumen diserahkan kepada produsen
    • Spesifikasi hanya mendefinisikan permukaan interoperabilitas, bukan memaksakan model konten
  • Independensi produsen/konsumen (Producer/consumer independence)

    • Pihak yang menulis pengetahuan dan pihak yang mengonsumsinya dipisahkan dengan rapi
    • Bundle yang ditulis manual oleh manusia bisa dikonsumsi agen AI, bundle yang dihasilkan pipeline ekspor metadata bisa dijelajahi visualizer, dan bundle yang disintesis satu LLM bisa di-query oleh LLM lain
    • Format adalah kontraknya, sedangkan alat di kedua ujungnya bisa diganti secara independen
  • Format, bukan platform (Format, not platform)

    • Tidak bergantung pada cloud, database, penyedia model, atau framework agen tertentu
    • Tidak memerlukan akun proprietari atau SDK untuk membaca, menulis, maupun menyajikan
    • Nilai format pengetahuan tidak berasal dari siapa yang memilikinya, melainkan dari seberapa banyak pihak yang menggunakannya, sehingga ia dirilis sebagai standar terbuka

Yang disediakan bersama spesifikasi

  • Untuk membuat format ini konkret, dirilis implementasi referensi di sisi produsen dan konsumen
  • Enrichment agent: menelusuri dataset BigQuery, menyusun draf dokumen konsep OKF untuk semua tabel dan view, lalu pada pass LLM kedua merayapi dokumentasi resmi untuk memperkaya tiap konsep dengan kutipan, skema, dan jalur join
  • Visualizer HTML statis: mengubah bundle OKF apa pun menjadi tampilan graf interaktif dalam satu file mandiri, tanpa backend, tanpa instalasi di sisi penonton, dan data tidak keluar dari halaman
  • Tiga bundle sampel yang bisa langsung dijelajahi: dataset publik GA4 e-commerce, Stack Overflow, dan Bitcoin, dihasilkan oleh agen referensi dan di-commit ke repositori sebagai contoh hidup OKF yang valid
  • Semua ini sengaja dibuat sebagai proof of concept
    • Agen tersebut hanya menunjukkan satu cara memproduksi OKF, bukan mensyaratkan framework atau LLM tertentu
    • Visualizer hanya menunjukkan satu cara mengonsumsi, bukan mensyaratkan HTML atau tampilan graf
    • Harapannya, ekosistem produsen dan konsumen akan tumbuh jauh melampaui apa yang sudah disediakan

Arah selanjutnya

  • OKF v0.1 bukan standar yang sudah final, melainkan titik awal, dan akan berkembang seiring munculnya lebih banyak produsen dan konsumen serta pemahaman tentang representasi pengetahuan yang benar-benar dibutuhkan agen
  • Apa pun yang dibangun—katalog pengetahuan, pipeline enrichment, atau wiki untuk agen AI—harus dibuka sejak hari pertama agar format ini benar-benar layak disebut terbuka
  • Tindakan yang disarankan
    • Baca spesifikasinya (singkat)
    • Tulis produsen (producer) untuk sistem sumber, database, atau situs dokumentasi
    • Tulis konsumen (consumer) seperti viewer, search index, atau agen yang bernalar di atas bundle
    • Terapkan implementasi referensi ke data Anda sendiri
    • Ajukan issue, kirim PR, dan usulkan ekstensi (spesifikasi dikelola dengan version control dan dirancang untuk tumbuh dengan kompatibilitas ke belakang)
  • Repositori, spesifikasi, dan bundle sampel tersedia di GitHub, dan Knowledge Catalog milik Google Cloud telah diperbarui untuk mengindeks OKF dan menyajikannya ke agen
  • Kontribusi utamanya adalah format itu sendiri; alat yang disediakan bertujuan mewujudkan format tersebut dan menurunkan biaya eksperimen, sementara OKF dirancang sebagai lingua franca untuk pertukaran pengetahuan di masa depan

2 komentar

 
leothelion 1 jam lalu

Mungkin ini bisa dibilang pilihan terbaik bagi mereka yang tidak kebagian .claude dan .agent

 
GN⁺ 4 jam lalu
Komentar Hacker News
  • Kesederhanaan spesifikasi OKF ini bagus, tetapi saya tidak yakin semua hal bisa diekspresikan dengan baik sebagai “sekadar Markdown”
    Belakangan ini saya tertarik pada cara mengekspresikan konsep agar AI bisa berkontribusi bersama secara efektif dan efisien dalam penggunaan token, dan biasanya arahnya adalah mencari cara untuk merepresentasikan sesuatu dengan baik sebagai teks berurutan yang semi-terstruktur. Namun dalam proses itu, pengalaman representasi pengetahuan untuk manusia tidak boleh dikorbankan
    Terutama jika peran yang secara tradisional bukan developer juga harus ikut berkontribusi, “format teks aneh + git” kemungkinan akan terasa jauh lebih buruk daripada alat penulisan dan visualisasi yang dipakai sekarang
    Saya menantikan bagaimana dalam beberapa tahun ke depan akan muncul standar untuk merepresentasikan berbagai jenis pengetahuan secara semantik
    Contoh sukses yang layak dijadikan referensi antara lain DBML untuk skema/E-R, LikeC4 untuk arsitektur, dan pendekatan diagram-as-code seperti Mermaid. LLM juga cenderung memahami format-format ini dengan baik, dan bisa diberi tahu lewat prompt EBNF yang singkat. Yang penting, semuanya juga punya bentuk visualisasi yang enak dilihat manusia, bisa dimasukkan secara alami sebagai code block di dalam Markdown tepat di samping bahasa alami, dan LLM juga bisa membantu menulis sintaksnya
    Yang lebih sulit adalah hal-hal seperti spreadsheet kompleks atau Miro, di mana tata letak ruang dan warna punya makna implisit. Saya belum menemukan alternatif yang bagus
    Hal yang pernah saya coba langsung di ranah data engineering adalah https://equalexperts.github.io/satsuma-lang/ untuk menangani pemetaan sumber-target dan transformasi bersama AI dan manusia. Ini adalah representasi teks terstruktur yang ringkas dan tetap mengizinkan bahasa alami, sekaligus menyediakan visualisasi yang baik serta alat LSP/grammar, sehingga agen tidak perlu memotong dokumen besar secara tidak efisien dari sisi token hanya untuk menalar hal-hal seperti lineage, kelengkapan, atau sumber yang tidak terdefinisi

    • OKF terlihat cukup baik, tetapi terikat pada Markdown
      Dokumen Markdown bisa menjadi dokumen OKF hanya dengan menambahkan type pada YAML di bagian depan
      Bagaimana jika ada bahasa graf pengetahuan yang bisa dipakai juga di prosa Markdown maupun di dalam blok kode Markdown, dan bahkan di mana pun yang punya field teks?
      Dalam bahasa minimalis https://ddot.it, file di luar dunia Markdown, URL, bahkan label sederhana pun bisa dihubungkan. Seperti OKF, ini juga hanya satu format
      Sebagai catatan, spesifikasi singkat itu saya yang menulis
    • Tanpa format graf yang menunjukkan relasi berlabel antar entitas, pengetahuan tidak bisa direpresentasikan dengan baik
    • Markdown adalah format de facto untuk interoperabilitas antara LLM dan manusia
      Saya setuju bahwa tidak semua hal bisa diekspresikan dengan baik, tetapi itu meleset dari inti persoalannya. Markdown tampaknya menang karena ia adalah titik temu terendah yang sama-sama bisa dipakai oleh manusia dan model AI
  • Menyenangkan sekali melihat kembali format semantic web RDF/OWL setiap 10 tahun sekali
    Suatu hari nanti, salah satu dari tahun-tahun itu akan benar-benar menjadi tahunnya
    https://en.wikipedia.org/wiki/Semantic_Web

  • Ada beberapa tautan rusak di sumber aslinya, jadi saya tinggalkan repositorinya
    https://github.com/GoogleCloudPlatform/knowledge-catalog
    Spesifikasi: https://github.com/GoogleCloudPlatform/knowledge-catalog/blo...

  • Sejauh yang saya pahami, karena kita tidak bisa melihat melampaui tiga dimensi, ini pada dasarnya lebih mirip pijakan untuk manusia
    Jika kita menatanya dengan cukup rapi, saya berharap agen bisa mengambil Markdown itu lalu membangun infrastruktur graf di memori atau menyimpannya ke Neo4j

  • Apakah varian Markdown tertentu, misalnya CommonMark, ditentukan?
    Saat saya sekilas membaca beberapa halaman awal, saya tidak melihat hal terkait itu, padahal untuk sebuah spesifikasi rasanya itu bagian yang cukup penting

  • Yang diumumkan Google pada akhirnya hanyalah Markdown dengan YAML frontmatter. Tepuk tangan untuk semuanya. Spesifikasi 15KB untuk ini
    Saya mungkin tidak akan sesarkastik ini kalau semua orang bisa berhenti memakai YAML dengan gaya “ah, ada satu indentasi yang kelewat”

  • Sebagai orang yang sudah melihat banyak PDF yang harus “diterjemahkan” ke Markdown, ini terasa seperti pilihan yang aneh
    Saya paham bahwa tujuan besarnya adalah agar AI mudah mengaksesnya, tetapi kalau modelnya toh akan dilatih juga, saya bertanya-tanya kenapa tidak melatihnya dengan format yang lebih baik saja
    Markdown cukup terbatas, dan misalnya hal seperti tabel bertingkat pun tidak bisa dirender. Jika tujuan dari “pengetahuan terbuka” ini adalah AI, saya juga tidak yakin kenapa harus memaksakan format yang sebenarnya tidak akan dibaca manusia

  • Saya suka pendekatannya. Saya sangat menyukai pengorganisasian pengetahuan secara hierarkis
    Menurut saya, abstraksi manajemen pengetahuan Claude saat ini hampir semuanya rusak. Ini akan terlihat ketika menjalankan banyak coder secara bersamaan atau harus membuat lebih dari 1.000 skill. Contoh: https://news.ycombinator.com/item?id=48407998

  • Coba lihat barrasindustries.com/okfind/
    Ini adalah ide untuk registri bundel OKF