Mencuri Pola L0 OpenViking untuk Knowledge Base Saya
Query KB cuma keluar path plus skor? Saya curi pola ringkasan L0 OpenViking: satu kalimat per dossier, tanpa instalasi baru.
Ringkasan
Setiap query ke knowledge base dulu cuma mengeluarkan path dan skor, jadi saya terpaksa membuka satu per satu dossier untuk menilai relevansi. Dari OpenViking saya curi polanya tanpa memasangnya: 40 baris Python yang menambahkan ringkasan satu kalimat wajib di tiap dossier dan menampilkannya di hasil query. Sekarang saya bisa langsung memutuskan buka atau tidak tanpa membuka file penuh.
Query knowledge base riset saya, dan yang keluar di layar cuma begini: path dossier plus skor 0.42. Itu aja. Skor 0.42 artinya apa? Isinya soal apa? Jawabannya cuma satu: buka file dossier satu-satu. Kadang dua-tiga file saya buka cuma buat nemuin satu yang relevan.
Ini kejadian berulang sampai saya muak. Knowledge base-nya sendiri sih jalan fine, 14 dossier riset dengan embedding lokal, threshold skor 0.30, hasilnya selalu relevan. Masalahnya di hasilnya: saya nggak bisa nilai relevansi tanpa membuka file penuh.
Dugaan salah pertama
Waktu lihat OpenViking, repo open-source dari volcengine yang jadi "context database for AI agents" [1] (udah 35.390 stars di GitHub [3]), dugaan saya: ini dia jawabannya, tinggal pasang. Kirain bakal ada instalasi, konfigurasi, mungkin migrasi data.
Ternyata saya nggak baca detailnya dulu. OpenViking itu virtual filesystem utuh buat agent, memory-resources-skills jadi satu, agent bisa ls/tree/find ke konteksnya sendiri. Itu infrastruktur. Yang saya butuhkan cuma satu ide dari sana.
Setelah baca dok resminya, ketemu yang saya cari: tiga tier konteks. L0 abstract sekitar 100 token buat cek relevansi cepat, L1 overview buat planning, L2 isi penuh yang dibaca kalo emang perlu [1]. Dok resminya lebih presisi: L0 itu file .abstract.md per direktori, batas default 256 karakter, gunanya buat "vector retrieval, quick filtering". L1 itu .overview.md, 4000 karakter, buat "rerank, content navigation" [2].
Satu kalimat ringkasan per arsip. Itu aja yang saya mau.
Yang akhirnya saya tulis
Nggak ada instalasi OpenViking sama sekali. Yang saya "curi" cuma polanya, lalu implement sendiri sekitar 40 baris Python di tools/research-knowledge.py yang udah ada. Infra baru? Nggak perlu. JSON index plus embedding lokal Ollama bge-m3 yang udah jalan dari artikel kemarin, cukup.
Konkritnya begini:
Setiap dossier riset sekarang punya field ringkasan: di frontmatter. Satu kalimat, maksimal 240 char. Field ini muncul di output query, jadi hasil pencarian sekarang menyertakan ringkasan satu baris yang langsung bisa saya baca buat mutusin buka atau enggak.
Kontraknya ditulis tegas di _TEMPLATE.md dan research/README.md: dossier baru wajib punya ringkasan sejak dibuat. Cron job yang arsipin halaman juga nuntut field itu. Backfill ke 14 dossier lama? Sekali aja, lalu selesai.
Katalog 14 dossier ringan. extract_l0(text) ambil bullet pertama seksi "## Temuan", bersihin markdown, potong di batas kalimat, maks 240 char. Nol LLM. Fallback doang.
Di cmd_build, file lama cuma disinkron metadata ringkasan dan mtime tanpa re-embed. File baru di-embed dari head 8000 char file. Build tetap murah.
Ada satu penyimpangan sengaja dari desain OpenViking: di sana L0/L1 itu sidecar per direktori, bukan per file. Ringkasan file individual diagregasi ke L1 direktorinya [2]. Saya pilih per dossier karena skala saya 14 file, bukan filesystem penuh. Pola bagus dari project besar nggak harus diadopsi utuh.
Kenapa ini masuk akal
Inti idenya tiered loading: jangan baca file penuh sebelum yakin relevan. Otak saya juga kerja gini pas nyari dokumen di folder. Judul dulu, baru buka yang menjanjikan.
Opini saya soal ini tegas: ringkasan itu kontrak, bukan pungutan. Yang bikin pattern L0 gagal di kebanyakan orang bukan tekniknya, tapi ringkasan yang ditulis kemudian, asal-asalan, atau nggak pernah di-update. Kalo ringkasan jadi syarat arsip dibuat, konsistensi-nya dijaga struktur, bukan niat baik. Makanya backfill saya lakuin sekali, terus field-nya jadi wajib.
Satu hal lagi yang saya suka dari implementasi sendiri: extract_l0() tanpa LLM. Kalo ringkasan nggak keisi, ambil kalimat inti dari bullet pertama seksi Temuan. Nol biaya, cukup akurat buat fallback. Saya sempat mikir pake LLM buat generate ringkasan, tapi buat apa, isi dossier-nya kan saya tulis sendiri dan bagian Temuan udah dirancang kalimat pertamanya padat.
Soal benchmark OpenViking yang katanya akurasi memory 80-83% vs native 24-57%, dengan input token turun sampai 91% [1]: itu klaim vendor, diuji pake model mereka sendiri (Doubao). Saya sitasi sebagai klaim, bukan bukti pattern L0 berhasil di KB saya. Yang saya bisa mastiin dari pengalaman sendiri: query sekarang keluar dengan ringkasan per hit, dan saya udah nggak buka dossier buat baca isinya doang.
Apakah saya akan pindah ke OpenViking utuh suatu hari? Mungkin, kalo KB-nya tumbuh jadi ratusan file dan struktur direktori makin dalam. Untuk sekarang, 40 baris di file yang udah ada ngalahin satu dependency baru. Dan itu keputusan yang saya nggak akan sesalin.