Halo, teman-teman developer dan mahasiswa ilmu komputer! Buat kalian yang lagi sibuk ngerjain skripsi, riset AI, atau sekadar penasaran gimana cara kerja sistem manajemen memori aplikasi skala besar, ada kabar seru nih. Baru saja, tim pengembang menutup catatan finalisasi untuk Arah 1 hingga 3 (Directions 1-3) dalam subsistem manajemen pengetahuan dan memori mereka. Update ini ngebahas pipeline inti secara menyeluruh: mulai dari proses ingestion, penyimpanan (storage), pencarian (retrieval), sampai integrasi konteks.

Di artikel ini, kita bakal bedah apa artinya arsitektur ini buat stack teknologi kamu, kenapa mereka mengambil keputusan tradeoff tertentu, dan gimana cara menerapkannya di proyek ngoding kamu selanjutnya. Jadi, pasang sabuk pengaman dan yuk kita bedah tuntas!

Memisahkan Persistensi Dokumen dari Memori Runtime

Selama ini, proyek-proyek sering kali pusing mikirin cara memisahkan persistensi pengetahuan dari memori runtime sambil tetap menjaga antarmuka query yang terpadu. Nah, Arah 1 sampai 3 ini ngebentuk fondasi yang solid banget: ada document store, vector index, dan structured memory buffer yang menggabungkan keduanya. Gak ada lagi cerita bikin caching ad hoc atau repot-repot nulis ulang retrieval loop dari nol. Semuanya sekarang udah dibungkus rapi di balik satu antarmuka tunggal bernama KnowledgeGraph.

Arah 1: Ingesting dan Penyimpanan Dokumen Mentah (Raw Document Ingestion and Storage)

Untuk urusan penyimpanan dokumen, tim pengembang memutuskan pakai partitioned document store yang didukung oleh database lokal SQLite dengan kolom blob buat konten yang diserialisasi. Setiap entri dokumen menyimpan berbagai informasi penting:

  • UUID dokumen
  • URI sumber (source URI)
  • Teks mentah atau bytes
  • Hash konten
  • Timestamp

Pipeline ingestion di sini melakukan deduplikasi berdasarkan hash dan melewati rantai ekstraksi opsional (misalnya parser PDF, pemecah markdown, atau code chunker). Keputusan desainnya sangat cerdas: memisahkan penyimpanan dari indexing secara total. Store ini sifatnya 'bodoh'—dia cuma ngurusin operasi CRUD dan metadata query. Hasilnya? Jalur ingestion jadi super simpel dan gampang banget buat di-testing.

Arah 2: Vector Index dengan Filtered Search

Daripada capek-capek bikin vector database sendiri, mereka memilih membungkus infrastruktur yang udah ada—yakni Pinecone dan fallback lokal menggunakan FAISS—di balik lapisan abstraksi. Catatan finalisasi mewajibkan adanya seperangkat metadata filter yang harus disertakan dalam setiap panggilan upsert dan query.

Setiap vector embedding membawa UUID dokumen, indeks potongan (chunk index), dan peta tags bentuk bebas. Hal ini bikin kita bisa ngejalanin query spesifik kayak “ambil semua chunk di mana modul == 'networking' dan versi >= '2.0'” tanpa harus repot scanning vector lain yang sama sekali nggak nyambung.

Catatan finalisasi ini juga menetapkan batas maksimal max-k retrieval sebanyak 50 dengan ambang batas kemiripan (similarity threshold) di angka 0.65. Di bawah angka itu, sistem bakal langsung balikin set kosong ketimbang maksain data sampah yang berisik. Menariknya lagi, embedding dihitung duluan (precompute) di dalam pipeline ingestion dan di-cache biar gak perlu ngitung ulang pas runtime. Konsekuensinya, indeks bakal agak terlambat (stale) sampai perintah sync dijalankan, tapi ini kompromi yang sangat wajar buat ngejar standar latensi yang diinginkan.

Arah 3: Structured Memory dengan Context Handles

Bagian ini adalah inti terpenting dari seluruh arsitektur. Memori sekarang bukan lagi sekadar key-value store biasa. Arah 3 memperkenalkan context handles—objek ringan yang menghubungkan sebuah query dengan jendela pengetahuan tertentu. Setiap handle memegang referensi ke sesi percakapan aktif, daftar potongan dokumen yang sudah diambil (retrieved document chunks), serta sebuah “kursor” yang nunjukin bagian mana dari potongan tersebut yang udah dikonsumsi oleh model.

Objek handle ini diserialisasi sebagai JSON dan disimpan di dalam runtime memory buffer (berupa LRU cache di dalam proses). Ketika ada request masuk, sistem bakal ngecek apakah handle yang ada masih aktif. Kalau ada, sistem langsung lanjutin dari kursor alih-alih narik data dari awal lagi. Kalau belum ada, sistem bakal bikin handle baru dari query dan hasil vector search terbaru.

Biar gak cuma teori, yuk intip cuplikan kode Python sederhana gimana context handle ini dibuat dan digunakan dalam skrip:

from knowledge_memory import ContextHandle, KnowledgeGraph

graph = KnowledgeGraph(doc_store="sqlite:///docs.db", vector_index="faiss")
handle = ContextHandle(session="session-42")

# Retrieval only fetches chunks not yet consumed
results = graph.query("Deploy L4 load balancer", handle, max_chunks=5)

if results:
    # Each result knows its position in the handle's cursor
    for chunk in results:
        print(f"Processing chunk {handle.cursor}/{handle.total_chunks}")
        process_chunk(chunk.content, chunk.metadata)
        handle.advance()  # moves internal cursor

Pendekatan ini sukses mengatasi bug klasik di mana query berulang dalam sebuah sesi obrolan sering manggil dokumen yang itu-itu lagi, yang akhirnya bikin model AI muter-muter ngulang omongan yang sama. Adanya kursor juga ngebantu banget buat proses progressive summarization: setelah tiap N chunks tertentu, sistem bisa bikin ringkasan parsial dan menyimpannya kembali ke dalam handle.

Dampak Nyata ke Pengalaman Developer (Developer Experience)

Penerapan arah baru ini sukses mangkas ukuran konfigurasi hingga setengahnya. Ketimbang harus repot nyambungin berbagai klien database, layanan embedding, dan penyimpanan memori secara terpisah, seorang developer sekarang cukup inisiasi objek KnowledgeGraph lalu lempar context handle ke dalam alur request. Semua state yang dibutuhin buat interaksi multi-turn udah dibawa langsung sama handle tersebut.

Meskipun keren, ada satu catatan penting yang wajib diingat: context handles ini default-nya belum thread-safe. Wrapper produksi biasanya pakai striped lock per session key. Selain itu, vector index sifatnya baru konsisten secara berkala (eventually consistent) terhadap document store—jadi kalau kamu hapus dokumen, kamu harus nge-sync indeksnya secara manual. Masalah ini belum beres di Arah 1-3, dan baru masuk ke dalam roadmap untuk Arah 4.

Tapi buat sekarang, fondasi arsitekturnya udah kokoh banget. Pipeline ingestion berjalan deterministik, pencarian menghormati filter, dan model memorinya ampuh nahan informasi biar gak jalan di tempat. Buat tim developer yang udah berpengalaman, pola arsitektur ini bisa banget diadopsi cuma dalam waktu satu akhir pekan saja!