Wawancara data engineering: Bagaimana Anda mengelola kepercayaan pada pengetahuan yang dihasilkan agen dengan OKF v0.2?

Prompt dan cakupan

Beberapa agen secara terus-menerus menghasilkan definisi metrik, runbook, dan skema tabel. Rancang katalog pengetahuan OKF v0.2 yang mencatat sumber, generator, verifikator, masa kedaluwarsa, dan bukti komputasi dengan tetap dapat dibaca oleh konsumen v0.1.

Google Cloud memperkenalkan OKF v0.2 pada Juli 2026. Open Knowledge Format menggunakan file Markdown dan frontmatter YAML untuk pengetahuan yang dikelola oleh manusia dan agen. Versi 0.2 membuat provenansi, kepercayaan, siklus hidup, dan atestasi dapat di-query sembari tetap bersifat aditif dan kompatibel ke belakang. Ini adalah format data dan konvensi tata kelola, bukan runtime terpusat atau sistem kontrol akses.

Hal yang dievaluasi oleh pewawancara

Pewawancara menginginkan pemisahan yang jelas antara pihak yang membuat dan pihak yang memverifikasi konten, atribusi per klaim melalui ID sumber yang stabil, pemfilteran kesegaran dan siklus hidup yang dapat dieksekusi, serta pemahaman bahwa tingkatan kepercayaan adalah sinyal penasihat (advisory) yang diturunkan oleh konsumen, bukan otorisasi. Cakup juga fallback v0.1, penulisan idempoten, migrasi, konten berbahaya, dan batas verifikasi dari atestasi komputasi.

Pertanyaan klarifikasi sebelum menjawab

• Produsen mana yang menulis bundle, dan siapa yang memegang kendali atas tinjauan manusia akhir?
• Apakah konsumen harus memfilter konten yang belum diverifikasi, basi, usang, atau hanya tingkatan kepercayaan tertentu yang dipilih?
• Haruskah sources mendukung URL eksternal, jalur relatif terhadap bundle, dan deskriptor cakupan?
• Lingkungan eksekusi, versi input, dan sumber daya komputasi ulang apa yang mendukung komputasi teratestasi?
• Apakah konsumen v0.1 hanya dapat membaca bidang lama, atau mereka juga harus menerima peringatan migrasi?

Kerangka jawaban 30 detik

“Saya akan memperlakukan file OKF sebagai fakta pengetahuan berversi dan memisahkan proses produksi, verifikasi, pengindeksan, dan konsumsi. Setiap konsep mencatat sumber, generator beserta waktunya, catatan verifikasi independen, status, dan kedaluwarsa; klaim menggunakan atribusi sources[].id yang stabil. Konsumen memfilter frontmatter berdasarkan status, tingkatan kepercayaan, dan kesegaran sebelum membaca badan dokumen. Semua penambahan v0.2 bersifat opsional, pembaca mempertahankan kunci yang tidak dikenal, dan melakukan fallback dari timestamp ke generated.at serta dari konvensi sitasi lama ke sources. Tingkatan kepercayaan diturunkan oleh konsumen, bukan digunakan sebagai otorisasi; bukti komputasi mengikat input, kode, dan bukti yang dapat direproduksi.”

Pembahasan mendalam langkah demi langkah

1. Rancang file konsep terkecil

Pertahankan satu konsep yang mudah dikelola per file dengan bidang dasar seperti type, judul, deskripsi, sumber daya, dan tag. Tempatkan metadata yang dapat diindeks dan difilter di frontmatter serta penjelasan, skema, dan kueri contoh di badan dokumen. Direktori di Git menyediakan peninjauan perubahan dan rollback tanpa memerlukan registri terpusat saat runtime.

2. Tetapkan sumber dan atribusi per klaim

sources mencatat dokumen eksternal, jalur relatif terhadap bundle, atau deskriptor cakupan yang menjadi asal usul suatu konsep, bersama sinyal objektif seperti penulis, jumlah penggunaan, dan waktu terakhir dimodifikasi. Klaim pada badan dokumen menggunakan catatan kaki yang dikaitkan dengan ID sumber stabil alih-alih sources[0] posisional; pengurutan ulang tidak dapat secara diam-diam salah mengatribusikan klaim, dan konsumen dapat menghitung kredibilitas secara lokal.

3. Pisahkan antara yang dihasilkan dan yang diverifikasi

generated menyatakan siapa yang menghasilkan konten saat ini dan kapan; verified menyatakan siapa yang mengonfirmasinya terhadap sumber atau sumber daya dan kapan. Ketiadaan verified berarti belum diverifikasi (unverified); konfirmasi khusus mesin dapat menghasilkan machine-confirmed; verifikator manusia dapat menghasilkan human-reviewed. Tingkatan ini adalah sinyal penasihat yang diturunkan oleh konsumen, bukan keputusan otorisasi atau kepatuhan langsung.

4. Kelola kesegaran dan siklus hidup

Gunakan status untuk status siklus hidup stable, draft, atau deprecated dan stale_after atau waktu yang setara untuk tenggat waktu peninjauan. Pengindeks menggabungkan waktu saat ini, pembaruan sumber, dan kebijakan bisnis untuk menghitung kesegaran. Basi (stale) bukan berarti salah: konsumen memutuskan apakah akan menyembunyikan, menurunkan peringkat, atau memverifikasi ulang serta mencatat alasannya.

source -> generated -> verified -> trust tier
      -> status/stale_after -> consumer filter -> body read

5. Tangani komputasi teratestasi

Untuk metrik dan klaim terkomputasi, catat definisi, versi sumber daya input, pelaksana, waktu eksekusi, dan hasil verifikasi. Atestasi membuktikan bahwa suatu nilai dihasilkan oleh metode yang dideklarasikan; atestasi tidak membuktikan bahwa input atau interpretasi bisnisnya benar. OKF tidak menentukan pelaksana atau pemaketan tertentu, sehingga tata kelola harus mengunci lingkungan, dependensi, dan bukti replay.

6. Pertahankan kompatibilitas v0.1

Versi 0.2 adalah versi minor aditif yang kompatibel ke belakang; bundle v0.1 yang tidak mengadopsi bidang baru tetap valid. Pembaca mempertahankan kunci kustom dan yang tidak dikenal, memprioritaskan generated.at, melakukan fallback ke timestamp lama, dan dapat membaca konvensi # Citations lama ketika sources tidak ada sambil mengeluarkan peringatan migrasi. Penulis harus menyediakan migrasi berversi alih-alih menulis ulang riwayat secara diam-diam.

7. Bangun pipeline konsumsi yang dapat dipercaya

Produsen melakukan commit file, validator memeriksa frontmatter, ID sumber, dan stempel waktu, verifikator menulis konfirmasi independen, pengindeks mematerialisasi bidang filter, dan konsumen memfilter sebelum memuat badan dokumen. Gunakan ID konsep dan hash konten untuk keidempotenan serta antrean peninjauan untuk pembuatan berulang. Lakukan escaping dan allow-list terhadap tautan jarak jauh, Markdown, catatan kaki, dan konten yang dibuat oleh agen, disertai jejak audit.

Contoh jawaban berkualitas tinggi

Saya akan memperlakukan bundle OKF sebagai fakta pengetahuan yang dapat ditinjau di Git. Setiap file berisi satu konsep, dengan metadata yang dapat difilter di frontmatter dan penjelasan di badan dokumen. sources memiliki ID yang stabil dan catatan kaki di badan dokumen mengatribusikan klaim individual. generated dan verified secara terpisah mencatat produsen dan pengonfirmasi; konsumen menurunkan tingkatan unverified, machine-confirmed, atau human-reviewed tanpa memperlakukannya sebagai otorisasi. status dan stale_after menggerakkan pemfilteran siklus hidup dan kesegaran, sementara konsep yang basi dapat diturunkan peringkatnya atau dikirim untuk ditinjau. Klaim terkomputasi menyertakan versi input, lingkungan eksekusi, metode, dan bukti, dengan batasan eksplisit bahwa atestasi tidak membuktikan kebenaran input. Pembaca v0.2 mempertahankan kunci yang tidak dikenal, mendukung fallback dari generated.at ke timestamp dan dari sources ke konvensi sitasi lama, serta mengeluarkan peringatan migrasi untuk kompatibilitas v0.1. Commit yang idempoten, hash, antrean peninjauan, dan rendering yang aman kemudian memisahkan produksi, verifikasi, pengindeksan, dan konsumsi.

Kesalahan umum

• Menggabungkan generator dan verifikator → konfirmasi independen hilang → catat generated dan verified secara terpisah.
• Menggunakan tingkatan kepercayaan sebagai izin → sinyal penasihat menjadi kontrol keamanan → pertahankan otorisasi dalam sistem identitas, kebijakan, dan sumber daya.
• Menggunakan sources[0] untuk atribusi → pengurutan ulang daftar salah mengatribusikan klaim → gunakan ID sumber yang stabil dan kunci catatan kaki.
• Memperlakukan basi sebagai salah → kebijakan konsumen menjadi terlalu kasar → biarkan konsumen menyembunyikan, menurunkan peringkat, atau memverifikasi ulang.
• Mengklaim atestasi membuktikan kebenaran → input dan semantik diabaikan → ikat versi input, metode, dan cakupan verifikasi.
• Menghapus bidang lama secara diam-diam selama migrasi → merusak konsumen v0.1 → gunakan fallback, peringatan, dan penulisan berversi.

Pertanyaan lanjutan dan tanggapan

Mengapa tidak menetapkan satu skor kepercayaan universal dalam format ini?

Skor bergantung pada domain, konsumen, dan waktu; menyimpan satu skor membuatnya menjadi basi dan tidak portabel. Format ini mencatat sinyal yang dapat diverifikasi, dan setiap konsumen menurunkan kebijakan lokal dari kepenulisan, kesegaran, verifikasi, dan penggunaan.

Bagaimana jika dua verifikator independen mengonfirmasi satu konsep?

Simpan beberapa catatan verified dengan subjek dan waktu. Konsumen dapat menggabungkan kebijakan manusia, mesin, domain, atau kebaruan tanpa menimpa bukti sebelumnya.

Bagaimana Anda mencegah perpanjangan sewenang-wenang atas stale_after?

Batasi siapa yang dapat mengubahnya, wajibkan persetujuan sumber atau pemilik bisnis, dan lakukan audit terhadap nilai lama, nilai baru, alasan, dan bukti verifikasi. Memperbarui tenggat waktu bukanlah peninjauan konten.

Bagaimana jika konsumen v0.1 tidak memahami bidang baru?

Konsumen tersebut harus mengabaikan bidang yang tidak dikenal dan terus membaca bidang dasar. Sediakan penulisan kompatibilitas, fallback bidang lama, dan peringatan migrasi; jangan membuat ekstensi v0.2 wajib di setiap bundle lama.

Bagaimana metrik yang dihasilkan agen mencapai tingkatan kepercayaan tinggi?

Catat sumber pembuatannya dan bukti komputasi, lalu verifikasi input, metode, dan hasilnya secara independen. Hanya setelah peninjauan manusia atau proses bisnis berhasil, konsumen boleh menurunkan tingkatan kepercayaan yang lebih tinggi.