Semble - pencarian kode untuk agen yang memakai token 98% lebih sedikit daripada grep

• Semble adalah library pencarian kode yang dibuat agar agen bisa langsung menemukan potongan kode yang dibutuhkan melalui kueri bahasa alami maupun kode
• Dibandingkan grep+read, Semble menggunakan sekitar 98% lebih sedikit token dan mengembalikan hanya chunk yang relevan alih-alih membaca seluruh file
• Repositori rata-rata dapat diindeks dalam sekitar 250ms dan kueri dijawab dalam sekitar 1.5ms, serta berjalan di CPU tanpa API key, GPU, atau layanan eksternal
• Benchmark dilakukan pada 63 repositori dalam 19 bahasa dengan sekitar 1.250 kueri, dan Semble diklaim mencapai 99% dari kualitas CodeRankEmbed Hybrid sambil melakukan pengindeksan 218 kali lebih cepat
• Dalam benchmark efisiensi token, Semble rata-rata menggunakan 98% lebih sedikit token dan mencapai recall 94% hanya dengan 2k token, sementara grep+read mencapai recall 85% dengan jendela konteks 100k
• Tersedia sebagai server MCP untuk digunakan di Claude Code, Cursor, Codex, OpenCode, dan agen kompatibel MCP; repositori akan di-clone dan diindeks bila perlu, lalu indeksnya di-cache selama sesi berlangsung
• Penggunaan berbasis Bash juga didukung sehingga workflow semble search dan semble find-related bisa dimasukkan ke AGENTS.md atau CLAUDE.md; pendekatan ini diperlukan untuk subagen di Claude Code dan Codex CLI
• CLI dapat menerima path lokal maupun Git URL https://, dan jika path dihilangkan maka direktori saat ini digunakan sebagai default
• Dapat juga dipakai sebagai library Python, sehingga pencarian bisa diintegrasikan ke alat kustom melalui SembleIndex.from_path, SembleIndex.from_git, search, dan find_related
• Secara internal, file dipecah menjadi chunk yang memahami struktur kode dengan tree-sitter, lalu menggabungkan embedding potion-code-16M dari Model2Vec dan BM25, kemudian menyatukan skor dengan Reciprocal Rank Fusion
• Proses ranking memakai pembobotan leksikal untuk kueri berbasis simbol, boost untuk chunk definisi, pencocokan stemming identifier, relevansi dalam file yang sama, serta penurunan bobot untuk test, legacy, contoh, dan .d.ts
• Karena memakai model embedding statis, tidak ada transformer forward pass saat kueri, sehingga pencarian dalam hitungan milidetik di CPU dimungkinkan
• semble savings memperkirakan penghematan token dengan membandingkan jumlah karakter total dari file unik tempat chunk hasil berada dengan jumlah karakter snippet yang dikembalikan pada tiap pencarian, dan statistik disimpan di ~/.semble/savings.jsonl
• Paket ini bisa diinstal dari PyPI sebagai semble, dan untuk penggunaan MCP digunakan bentuk uvx --from "semble[mcp]" semble
• Lisensinya adalah MIT

[GN⁺]

Komentar Hacker News

• Saat mencoba alat seperti ini, saya melihat bahwa seperti halnya coder bisa menjadi bodoh ketika terlalu bergantung pada alat AI, AI itu sendiri juga menjadi bodoh
  AI berbasis agen sebenarnya sudah cukup pintar untuk menemukan jalur yang lumayan optimal dalam penelusuran atau pencarian kode, tetapi ketika diberi alat seperti ini, ia cenderung bergerak terlalu agresif karena hasil pencariannya hampir selalu hanya memberi pointer, bukan detail lengkap
  Sebagai percobaan sederhana dengan Pi, saya memintanya melacak seluruh jalur pengumpulan/pencarian pada proyek yang agak kompleks, dan codebase-memory-mcp menghasilkan 85k/4.4k token input/output, konfigurasi biasa saya 67k/3.2k, dan tanpa alat apa pun 80k/3.2k
  Kualitas hasil dan jumlah informasinya sama, dan alat ini tidak jauh lebih buruk, tetapi tetap saja malah lebih buruk
  Konfigurasi biasa saya hanya menambahkan satu baris di AGENTS.md dan CLAUDE.md: “baca PROJECT.md terlebih dahulu”
  Di PROJECT.md, saya hanya menaruh deskripsi proyek 2–3 baris, file-file terkait dengan penjelasan satu baris, hal-hal yang perlu diperhatikan, serta kalimat untuk LLM: “jika ada perubahan yang layak dicatat, perbarui file ini. Tujuan file ini adalah memberi gambaran kasar tentang proyek, lalu mendorong eksplorasi lebih lanjut bila perlu”

  • Pernyataan bahwa “AI berbasis agen sudah cukup pintar untuk menemukan jalur yang sangat optimal untuk penelusuran atau pencarian kode” berbeda dengan pengalaman saya
    Di kantor dulu kami memakai Augment Code, dan di sana ada Context Engine mirip MCP yang menjawab kueri bahasa alami terhadap kode yang sudah diindeks sebelumnya
    Setelah itu kami pindah ke Claude Code, dan anehnya meskipun ada alat baca-rentang, ia tetap mencoba membaca file dengan sed berdasarkan rentang baris yang diingatnya
    Saya tidak yakin itu benar-benar bisa disebut jalur yang sangat optimal
  • codebase-memory-mcp dan semble memang tidak persis sama, tetapi perbandingan ini menarik, jadi saya akan memasukkannya ke daftar hal yang ingin saya cek dan kalau bisa saya tambahkan ke benchmark
    Kalau ada kesempatan melakukan perbandingan yang sama dengan semble, itu akan jadi masukan yang sangat berguna. Skenario “dunia nyata” seperti ini sulit dibenchmark atau direproduksi

• Menarik. Saya juga bekerja di area ini, tetapi pendekatannya berbeda
  Alih-alih membuat indeks, saya membuat grep yang lebih pintar dengan pemeringkatan dan pemahaman struktur kode untuk seluruh codebase dan teks umum, dan karena sebagian besar waktu dihabiskan untuk menangani masalah performa, alat ini berjalan sangat cepat
  Saya harus menambahkannya sebagai pembanding dengan https://github.com/boyter/cs dan melihat apa yang lebih disukai LLM untuk jenis pertanyaan yang saya ajukan
  Ini juga menyediakan MCP, tetapi tidak membuat indeks pencarian. Karena ia memakai varian semantik kode, bukan BM25 bawaan, saya penasaran bagaimana hasil pemeringkatannya
  Alat ini tampaknya lebih cocok untuk kueri seperti “bagaimana autentikasi bekerja”, sementara cs menjalankan authenticate --only-declarations lalu memberi bobot pada hasil berdasarkan isi file, yaitu apakah lokasi kecocokan itu kode atau komentar, serta kompleksitas keseluruhan file
  Sudah saya bintangi dan akan saya pantau

• Saya tahu alat ini ditujukan untuk AI, tetapi saya justru lebih tertarik memakainya sendiri saat menjelajahi codebase baru atau codebase saya sendiri
  Saat ingin merombak sesuatu dan perlu tahu bagian mana saja yang harus diubah, alat ini tampak berguna untuk melihat gambaran besarnya
  LSP juga melakukan hal seperti itu, tetapi alat ini rasanya bisa melangkah satu tingkat lebih jauh

• Saya sudah menjalankan beberapa evaluasi dengan Pi dan GPT 5.5
  Saya menguji RTK aktif / headroom aktif / keduanya aktif / keduanya nonaktif, semuanya memakai instruksi sistem Pi standar dan tanpa AGENTS.md
  Saya lupa persisnya tes apa saja, tetapi itu beberapa evaluasi agen standar yang biasa dipakai orang, satu untuk Python dan satu untuk TypeScript, yaitu bahasa yang saya gunakan
  Saya tidak mengklaim ini pengujian yang menyeluruh atau bagus. Bisa saja hasilnya lebih baik kalau saya menghabiskan sekitar satu hari menyetel AGENTS.md serta prompt sistem dan instruksi alat Pi. Salah satu hal yang saya pelajari saat menjalankan evaluasi adalah bahwa perbedaan halus seperti itu bisa sangat mengubah hasil
  Tetapi saat keduanya dimatikan hasilnya jelas lebih baik, sampai saya cukup yakin untuk menghentikan tes setelah 3 putaran
  Masalahnya, walaupun penggunaan konteks kadang turun, jumlah turn sampai selesai meningkat, sehingga biaya percakapan total justru lebih tinggi
  Ini membuat saya makin sadar bahwa banyak orang membagikan alat seperti ini, tetapi hampir tidak ada evaluasi sama sekali, atau sangat sulit direproduksi sampai mencurigakan, atau seperti alat ini, melakukan banyak benchmark tetapi mengukur hal yang salah
  Memang benar alat ini memakai token lebih sedikit daripada grep, dan benchmark-nya membuktikan itu, tetapi itu bukan hal yang penting. Yang penting adalah apakah agen bisa memakai alat ini untuk menyelesaikan pekerjaan dengan kualitas yang sama, lebih cepat, dan dengan biaya lebih rendah

  • Saat ini industri AI secara keseluruhan memang kekurangan pengujian
    Ini bukan masalah khas alat ini saja, melainkan masalah semua hal yang menempelkan AI ke codebase atau alur pengembangan
    Bahkan sebelum AI pun tidak ada tes untuk mengukur “seberapa cepat dan seberapa baik ini dikembangkan”, dan sekarang pun belum ditambahkan
  • Dalam AI, rasanya kasus “bisa dilakukan, jadi tidak dipikirkan apakah seharusnya dilakukan” akan sangat sering terjadi

• Saya ingin melihat benchmark agen yang nyata. Misalnya menghapus grep dari Claude Code atau Copilot CLI lalu menggantinya dengan alat ini
  Saya sudah melihat RTK dan beberapa implementasi LSP, dan model-model tampaknya terlalu kuat dilatih lewat reinforcement learning untuk grep, sehingga mereka tidak percaya bentuk hasil lain dan terus mencoba lagi atau membaca ulang
  Akibatnya, semua penghematan token hilang karena model tidak percaya pada hasil alat lain

  • Saya menaruh instruksi di CLAUDE.md global (~/.Claude) agar memakai LSP alih-alih grep, dan sejak itu masalah ini hilang
  • Codex CLI menjalankan RTK dengan cukup baik. Setidaknya begitu pada GPT 5.5 xhigh
    Hanya saja agak mengganggu ketika ia tidak mendukung flag CLI tertentu pada find, karena alih-alih mengirim seluruh output perintah, ia justru memberi pesan error
    Lalu agen membuang token untuk mencoba lagi, atau lebih buruk lagi, malah takut mencoba sama sekali karena prompt membuatnya merasa tidak boleh menjalankan perintah tanpa RTK
  • Kami juga tertarik pada benchmark seperti ini, dan ini sudah masuk roadmap bersama optimasi prompt dan deskripsi agar model lebih mudah memakainya
    Memang baru sebatas anekdot, tetapi kami tentu juga memakai alat ini sendiri, dan sejauh ini kerjanya cukup baik
    Model Anthropic tampaknya benar-benar memanggil alat ini dan memercayai hasilnya
  • Penghematan token makin penting, tetapi yang juga penting adalah apakah agen memercayai hasilnya dan berhenti mencari
    Jangan hanya melihat output pencarian; yang harus diukur adalah seluruh loop agen
  • Setidaknya Codex akan menuruti kalau diberi tahu bahwa grep sering terlalu lambat jadi pakailah rg, tetapi kalau RTK ditambahkan, ia malah memakai grep lewat RTK, yang cukup menjengkelkan

• Idenya tampak bagus, jadi saya sempat mencobanya sedikit
  Pengujiannya saya lakukan pada repositori browsercode(https://github.com/browser-use/browsercode), dan prompt-nya adalah “gunakan hanya CLI semble, lalu jawab alat apa saja yang diberikan Browsercode kepada agen selain alat OpenCode bawaan. Sertakan skema input/output alat yang tepat, serta ringkas secara singkat apa fungsinya dan bagaimana cara kerjanya”
  Saya menempelkan potongan AGENTS.md dari https://github.com/MinishLab/semble#bash-integration di sini
  Untuk pengujian tanpa Semble, saya mengubah pertanyaannya menjadi hanya boleh memakai CLI rg dan fd
  Dalam kedua kasus saya memakai Pi dan gpt-5.4 medium, dan pengaturan lainnya dibuat seminimal mungkin. Saya juga memastikan apakah masing-masing sisi benar-benar hanya memakai rg dan fd, atau hanya semble
  Tanpa Semble, model memakai 10.9% konteks dan kredit API sebesar $0.144, sedangkan dengan Semble 9.8% dan $0.172
  Jawaban hasilnya juga nyaris sama, jadi sangat berdekatan
  Saya melakukan satu tes lagi pada repositori OpenCode, dengan pertanyaan “lacak jalur dari titik saat environment variable OPENCODE_EXPERIMENTAL_EXA diset ke 1 sampai dampaknya muncul di system prompt atau alat yang diberikan ke agen OpenCode”
  Saya menyertakan instruksi dan dokumen yang sama seperti di atas
  Versi non-Semble sedikit lebih rinci, dan juga membahas apakah jalur pemanggilan alat memanggil Exa tergantung apakah Exa atau Parallel diaktifkan sebagai penyedia pencarian web, tetapi kedua versi sama-sama menjawab pertanyaan yang sebenarnya dengan benar
  Versi Semble memakai 14.7% konteks / biaya API $0.282, sedangkan versi non-Semble memakai 19.0% / $0.352
  Dari sisi efisiensi konteks, Semble jelas menang, tetapi patut dicatat bahwa versi non-Semble selesai kira-kira dua kali lebih cepat
  Tentu saja ini cuma saya utak-atik sedikit, jadi hasilnya bisa saja berubah

• Pernyataan bahwa “memakai 98% lebih sedikit token dibanding grep” itu maksudnya saya harus percaya bahwa grep memang seboros itu sampai model setiap kali membaca 98% sampah tak berguna?
  Rasanya entah klaim ini tidak representatif, atau ada hal lain yang terlewat saat membuang sebagian besar konteks yang akan diberikan ke model

  • Angka 98% itu dibandingkan bukan hanya dengan output grep, tetapi dengan loop grep+read
    Saat agen menghadapi codebase yang tidak familiar, biasanya ia lebih dulu melakukan cat file atau membaca seluruh file. Setidaknya itu pengalaman saya
    Kalau Anda berhasil membuat agen secara konsisten hanya menjalankan grep -C N lalu berhenti di sana, saya benar-benar penasaran dengan konfigurasinya. Menurut saya kualitas hasil seperti itu terlalu rendah untuk dipakai sebagai konteks yang berguna
  • Ada masalah Claude membaca output ratusan kilobyte gara-gara hasil yang tertangkap di node_modules
    Karena ripgrep membantu, masuk akal menambahkan satu baris di semacam file memori agar ia memakainya
  • grep menampilkan semua baris yang cocok
    Saat LLM melakukan pencarian, bisa muncul banyak noise, dan terkadang ia harus mencari seperti itu karena tidak bisa mencari dengan cukup spesifik
    Pencarian berorientasi tujuan bisa mengurangi jumlah token
    Tetapi perbandingan ini tampaknya seperti membandingkan menerima hanya bagian yang diperlukan dengan membaca seluruh codebase

• Sebagai masukan, codex-cli macet saat memanggil ini lewat MCP
  Proses semble juga tetap tinggal seperti zombie dan macet selamanya. Saya tidak tahu kenapanya, dan tidak ada apa pun di log
  Kalau dipanggil lewat skill dengan cara pemanggilan CLI, GPT 5.5 tampaknya ingin melempar sangat banyak kueri pencarian, seolah-olah sudah terbiasa dengan ripgrep
  Saya tidak tahu seefektif apa itu, dan dari dokumentasi singkat di GitHub serta instruksi agen, tidak jelas apa yang paling optimal
  Terakhir, saat instalasi untuk bash saya juga beberapa kali mendapat error terkait koneksi keluar di luar GitHub. Saya tidak tahu apakah itu berkaitan dengan kemacetan tadi
  Selain itu, agen saya tetap mencoba memakai ripgrep juga setelahnya, jadi terasa duplikatif. Ia bertingkah seolah ada masalah kepercayaan
  Kalau ada penjelasan skill agen yang lebih rinci, mungkin agen bisa diarahkan ke cara pakai yang benar

  • Terima kasih atas masukan yang detail
    Untuk bug-nya, akan bagus kalau Anda bisa membuka issue beserta detail konfigurasinya. Ini jelas sesuatu yang ingin kami telusuri dan perbaiki
    Soal melempar banyak kueri juga masukan yang sangat bagus, dan kami akan mencoba memperbarui prompt serta instruksi agar ini tidak terjadi, juga menambahkan tes terkait
    Error koneksi keluar saat instalasi kemungkinan terjadi karena uv mengambil dependensi dari PyPI, dan seharusnya itu bukan penyebab kemacetan

• Ini tampak seperti ide yang bagus
  Ada satu masalah terkait juga: pada codebase kecil, Claude kadang sebenarnya bisa langsung memasukkan seluruh codebase ke konteks sekaligus dan menanganinya dengan token yang sangat sedikit, tetapi ia malah menghabiskan banyak waktu untuk mencari sesuatu
  Solusi sementara yang lumayan adalah memakai start hook untuk langsung memasukkan seluruh direktori ke konteks
  Dengan begitu Claude bisa melewati fase “meraba-raba dalam gelap” di setiap tugas
  Saya juga pernah melihat proyek bagus yang memberikan model gambaran umum berbentuk stub untuk repositori yang lebih besar, tetapi saya lupa namanya

  • Mungkin aider? https://aider.chat/2023/10/22/repomap.html
  • Benar juga. Agen tidak terlalu tahu informasi tentang apa yang sedang dilihatnya, misalnya jumlah file atau ukuran file
    Namun untuk codebase kecil, hal yang ingin dicari juga biasanya mudah ditemukan, jadi pencarian masih bisa membantu penghematan biaya

• Masalah yang lebih besar dari solusi-solusi seperti ini adalah bahwa sebagian besar AI, berkat pelatihannya, sudah sangat mahir memakai grep dan pencarian
  Ketika Anda memberi AI alat baru, alat seperti itu justru mengambil sebagian dari kemampuan kognitif AI
  Manusia biasanya akan “mempelajari” cara memakai alat semacam ini, tetapi pembelajaran LLM itu tetap, dan mereka sudah punya kemahiran yang sangat dalam pada alat-alat lama seperti grep
  Misalnya AI sudah tahu cara menjelajahi codebase dengan perintah Linux seperti tree, dan itu juga sudah sangat terlatih
  Masalah lain adalah contoh yang menunjukkan kegunaan alat seperti ini mudah dibuat, tetapi jauh lebih sulit membuktikan secara nyata bahwa kekurangan kognitif yang ditimbulkannya di eksekusi jangka panjang benar-benar terimbangi oleh manfaatnya
  Intuisi awal saya justru mengatakan bahwa dalam eksekusi jangka panjang, kecerdasan yang bisa dikerahkan akan mengalami kerugian bersih, sehingga agen akan menjadi lebih buruk dibanding saat memakai alat yang sudah ada
  Membuktikan kebalikannya bukan soal sepele, tetapi mungkin justru tantangan yang layak dicoba