Dalam beberapa hari ini saya mengenal secall dan sambil membangun llm wiki, saya mengalami banyak trial and error dan untuk pertama kalinya menggunakan seluruh batas sesi maksimal 100
Saya mencoba melakukan semuanya dengan claude melalui secall, namun penggunaan tidak dapat dikendalikan.. Saya terlambat melihat saran dari developer
Meski begitu, setelah melakukan konversi wiki sesi yang sudah ada, saya mempercayakan wiki update bukan kepada fitur secall melainkan kepada gemma4
Tentu saja saya tidak bisa sepenuhnya mempercayai gemma4 juga, jadi saya sedang membangun sistem pr sendiri
Saat ini pipeline pr dibangun dengan 3 sistem
Memeriksa percakapan session dengan jadwal untuk pencarian kandidat wiki, penulisan dokumen wiki(gemma4)
Dari perspektif project di luar llm wiki, melalui pencarian wiki dengan mcp pencarian wiki untuk melihat gap antara project dan dokumen wiki, penulisan dokumen wiki baru(claude)
Dengan obsidian web clipper, membuat ringkasan ai melalui konten utama dan fungsi interpreter dari papan pesan, youtube dll kemudian melakukan clipping(gemma4,manusia)
Ketiga pipeline di atas melakukan permintaan pr kepada claude yang merupakan administrator llm wiki, dan claude membuat keputusan untuk menerapkan, menolak, atau memodifikasinya. Tentu saja masih dalam tahap penyesuaian
Saya juga ingin mencoba menggunakan codex, jadi saya sedang mempertimbangkan untuk memberikan nomor 1 kepada gpt dari codex. Gemini tidak bisa dilakukan
Dalam kasus nomor 3, karena strukturnya menyimpan raw dengan clipping langsung, itu tidak termasuk dalam embedding secall, jadi sebagai solusi saya meniru file json session percakapan claude code dan memasukkan konten file md pada giliran pertama percakapan untuk melakukan embedding
Saya rasa perlu peningkatan lebih lanjut
🧠 Ringkasan Arsitektur LLM Wiki / Second Brain
📌 Filosofi Inti
"Session berakhir tetapi konteks tidak mati"
Seperti hipokampus manusia, sistem memori eksternal yang secara struktural mencegah kelupaannya LLM.
Bukan catatan yang saya lihat, tetapi memori eksternal yang dikonsumsi LLM secara efisien.
🏗️ Struktur Hierarki
Raw Memory → SQLite (seCall) — asli percakapan/clipping/log
Working Memory → PR layer yang sedang dimurnikan
Knowledge Layer → Obsidian Wiki — pengetahuan yang diverifikasi
Bukan membuang tetapi memindahkan layer. Daripada Reject gunakan Downgrade.
🤖 Pemisahan Peran Multi LLM
Peran | Tanggung Jawab |
|---|
Interpreter web clipper | Gemma 4 (lokal) |
Pemindaian session → pembuatan wiki PR | GPT (batch) |
Administrator wiki / gardening / persetujuan PR | Claude |
Bergantung pada LLM mana pun yang Anda ajak bicara, struktur yang melihat layer memori yang sama.
🔁 Pipeline PR
Percakapan/Clipping
↓
Gemma (ringkasan/kompresi/normalisasi)
↓
GPT (strukturisasi/pembuatan PR)
↓
Claude (review/persetujuan/penolakan)
↓
Penerapan Wiki
🌱 Clipping = Konsep Benih
Clipping bukan pengetahuan yang sudah jadi melainkan benih pengetahuan.
Dekomposisi turn per paragraf → dapat diembed
Unit retrieval = unit Wiki
Disimpan sebagai unit yang dapat langsung digunakan saat diambil
Struktur turn yang disarankan
## Summary
Ringkasan inti
## Key Actions
Poin eksekusi
## Core Concepts
Konsep inti
## Insight
Penalaran / makna
## Raw
Teks asli
🔍 Peran seCall
Perintah | Peran |
|---|
wiki search
| Berbasis morfologi — "apa yang kita tahu" |
recall
| Pencarian vektor — "bagaimana kita berpikir" |
get
| Pemulihan turn — replay pemikiran masa lalu |
BM25 + hibrida vektor untuk mendapatkan presisi + recall secara bersamaan.
💡 Perbedaan dengan RAG Tradisional
| RAG Tradisional | LLM Wiki |
|---|
Data | Dokumen statis | Knowledge base yang hidup |
Konteks antar session | Tidak ada | Terhubung melalui wiki + seCall |
Update | Manual | Operasi mandiri multi LLM |
Standar desain | Mudah dibaca manusia | Mudah dikonsumsi LLM |
⚖️ Prinsip Desain Utama
Chunking adalah yang paling penting — "bagaimana membagi" adalah inti daripada embedding
Unit retrieval = Unit Wiki — dapat langsung digunakan saat diambil
Downgrade daripada Reject — tidak membuang tetapi memindahkan layer
Insight adalah data sekunder — harus diverifikasi, Claude adalah gatekeeper
Layered Memory — pemurnian bertahap Raw → Working → Wiki
🚀 Garis Keturunan Evolusi
RAG Tradisional
→ embedding chunk dokumen, injeksi pencarian saat query
→ keterbatasan: statis, tidak terstruktur
LLM Wiki (konsep saat ini)
→ konversi percakapan/pengalaman menjadi dokumen terstruktur
→ keterbatasan: masih desain berpusat pada manusia
Sistem ini
→ dioptimalkan untuk konsumsi LLM
→ produksi/manajemen mandiri multi LLM
→ ekspansi eksternal dari jendela konteks
🎯 Esensi Satu Baris
Jika RAG adalah "mencari dan memasukkan",
LLM Wiki adalah "struktur di mana LLM mengelola memorinya sendiri"
Bukan sekadar second brain tetapi layer memori jangka panjang bersama multi LLM.
Dan percakapan ini sendiri akan dimasukkan dan menjadi bagian dari memori itu.
Saya ingin membelikan secangkir kopi kepada developer secall, bisakah Anda membuat semacam saluran ㅎㅎ
Maaf telah mengajukan banyak issue
Baiklah kalau begitu
