Semble - Ajanlar için grep'e kıyasla %98 daha az token kullanan kod arama

• Semble, ajanların doğal dil ve kod sorgularıyla yalnızca ihtiyaç duydukları kod parçalarını anında bulması için geliştirilmiş bir kod arama kütüphanesidir
• grep+read ile karşılaştırıldığında yaklaşık %98 daha az token kullanır ve tüm dosyayı okumak yerine yalnızca ilgili parçaları döndürür
• Ortalama bir depoyu yaklaşık 250 ms içinde indeksler ve sorgulara yaklaşık 1.5 ms'de yanıt verir; CPU üzerinde API anahtarı, GPU veya harici hizmetler olmadan çalışır
• Benchmark, 19 dilde 63 depo üzerinde yaklaşık 1.250 sorguyla gerçekleştirildi; Semble'ın CodeRankEmbed Hybrid kalitesinin %99'una ulaştığı ve indekslemede 218 kat daha hızlı olduğu belirtiliyor
• Token verimliliği benchmark'ında Semble ortalama %98 daha az token kullandı ve yalnızca 2k token ile %94 recall seviyesine ulaştı; grep+read ise 100k bağlam penceresiyle %85 recall'a ulaştı
• MCP sunucusu olarak Claude Code, Cursor, Codex, OpenCode ve MCP uyumlu ajanlarda kullanılabilir; depolar gerektiğinde clone edilip indekslenir ve indeks oturum boyunca cache'lenir
• Bash tabanlı kullanım da desteklenir; AGENTS.md veya CLAUDE.md içine semble search ve semble find-related iş akışları eklenebilir; Claude Code ve Codex CLI alt ajanlarında bu yöntem gereklidir
• CLI hem yerel yolu hem de https:// Git URL'sini kabul eder ve path atlanırsa varsayılan olarak mevcut dizini kullanır
• Python kütüphanesi olarak da kullanılabilir; SembleIndex.from_path, SembleIndex.from_git, search, find_related ile arama özel araçlara entegre edilebilir
• İçeride tree-sitter ile dosyaları kod farkındalıklı parçalara ayırır, Model2Vec'in potion-code-16M embedding'i ile BM25'i birleştirir ve puanları Reciprocal Rank Fusion ile bir araya getirir
• Sıralama; sembolik sorgular için sözcüksel ağırlıklandırma, tanım parçalarını öne çıkarma, tanımlayıcı kök eşleştirme, aynı dosya içindeki ilgililik ve test, legacy, örnekler ile .d.ts için aşağı yönlü ayarlamalar kullanır
• Statik embedding modeli kullandığı için sorgu sırasında transformer forward pass gerekmez; bu da CPU üzerinde milisaniye düzeyinde aramayı mümkün kılar
• semble savings, her aramada dönen parçaların ait olduğu benzersiz dosyaların toplam karakter sayısı ile dönen snippet karakter sayısını karşılaştırarak tasarruf edilen token miktarını tahmin eder; istatistikler ~/.semble/savings.jsonl içine kaydedilir
• Paket, PyPI'de semble olarak kurulabilir; MCP kullanımında uvx --from "semble[mcp]" semble biçimi kullanılır
• Lisans MIT'tir

[GN⁺]

Hacker News yorumları

• Bu tür araçları kullanınca, geliştiriciler AI araçlarına fazla bağımlı olduğunda aptallaşıyorsa, AI’ın kendisinin de aptallaştığını gördüğümü düşünüyorum
  Ajan tipi AI zaten kod gezintisi ve aramada oldukça optimize yollar bulacak kadar akıllı, ama buna benzer araçlar eklenince arama sonuçları neredeyse her zaman tüm ayrıntılar yerine yalnızca işaretçiler verdiği için fazla agresif davranma eğilimi oluyor
  Basitçe Pi ile, belli ölçüde karmaşık bir projede tam toplama·arama yolunu izlettim; codebase-memory-mcp 85k/4.4k giriş·çıkış tokenı kullandı, normal kurulumum 67k/3.2k, hiçbir araç olmadığında ise 80k/3.2k idi
  Sonuç kalitesi ve bilgi miktarı aynıydı; bu araç büyük fark yaratmadı, hatta biraz daha kötüydü
  Benim normal kurulumum, AGENTS.md ve CLAUDE.md içine yalnızca “önce PROJECT.md dosyasını oku” diye tek satır yazmak
  PROJECT.md içinde projenin 2-3 satırlık açıklaması, ilgili dosyalar ve tek satırlık açıklamaları, dikkat edilmesi gereken noktalar ve ayrıca LLM için yalnızca şu ifade bulunuyor: “değiştirmeye değerse bu dosyayı güncelle. Bu dosyanın amacı projeye dair kabaca bir his vermek ve gerekirse oradan daha fazla keşif yaptırmaktır”

  • “Ajan tipi AI zaten kod gezintisi ya da aramada yüksek derecede optimize yollar bulacak kadar akıllı” ifadesi benim deneyimimle uyuşmuyor
    İş yerinde eskiden Augment Code kullanıyorduk; onda önceden indekslenmiş kod üzerinde doğal dil sorgularını yanıtlayan, MCP benzeri bir Context Engine vardı
    Sonra Claude Code’a geçtik ama garip biçimde, aralık okuma aracı olmasına rağmen belleğinde kalan satır aralıklarına göre sed ile dosya okumaya çalışıyor
    Bunun gerçekten yüksek derecede optimize bir yol anlamına gelip gelmediğinden emin değilim
  • codebase-memory-mcp ile semble tam olarak aynı şey değil ama ilginç bir karşılaştırma; kontrol edilecek işler listeme ekleyip mümkünse benchmark’a dahil edeceğim
    Aynı karşılaştırmayı semble ile yapma şansın olursa bu gerçekten faydalı geri bildirim olur. Çünkü bu tür “gerçek” senaryoları benchmark etmek ya da yeniden üretmek zor

• İlginç. Ben de bu alanda çalışıyorum ama yaklaşımım farklıydı
  İndeks oluşturmak yerine, tüm kod tabanı ve genel metin üzerinde sıralama ile kod yapısı farkındalığı eklenmiş daha akıllı bir grep yaptım; zamanımın çoğunu performans sorunlarıyla geçirdiğim için de çok hızlı çalışıyor
  Bunu https://github.com/boyter/cs ile karşılaştırma listesine ekleyip, benim sorduğum türden sorularda LLM’lerin neyi tercih ettiğine bakmalıyım
  Bu da MCP sunuyor ama arama için indeks oluşturmuyor. Varsayılan BM25 yerine koda özgü semantik varyasyonlar kullandığı için sıralamanın nasıl çıkacağını merak ediyorum
  Bu araç “kimlik doğrulama nasıl çalışıyor” gibi sorgulara daha uygun görünüyor; cs ise authenticate --only-declarations yaptıktan sonra dosya içeriğine, yani eşleşen konumun kod mu yorum mu olduğuna ve dosyanın genel karmaşıklığına göre sonuçları ağırlıklandırıyor
  Yıldız verdim, takip edeceğim

• Bu aracın AI için olduğunu biliyorum ama benim daha çok ilgimi çeken şey, yeni bir kod tabanını ya da kendi kod tabanımı keşfederken bunu bizzat kullanmak
  Bir şeyi refactor etmeye çalışırken nereleri değiştirmek gerektiğine dair genel çerçeveyi görmek istediğinde faydalı görünüyor
  LSP de böyle şeyler yapıyor ama bu araç bir adım daha ileri gidebilir gibi

• Pi ve GPT 5.5 ile birkaç değerlendirme yaptım
  RTK açık / headroom açık / ikisi de açık / ikisi de kapalı durumlarını test ettim; hepsinde standart Pi sistem yönergeleri kullanıldı ve AGENTS.md yoktu
  Tam olarak hangi testler olduğunu unuttum ama insanların kullandığı bazı standart ajan değerlendirmeleriydi; biri kullandığım dil olan Python, diğeri de TypeScript idi
  Bunun kapsamlı ya da iyi bir test olduğunu iddia etmiyorum. Bir gün kadar AGENTS.md ile Pi sistem promptu·araç yönergelerini ayarlasaydım daha iyi sonuçlar çıkabilirdi. Değerlendirmeleri çalıştırırken öğrendiğim şeylerden biri, bu tür ince farkların sonucu ciddi biçimde değiştirebilmesi oldu
  Ama ikisinin de kapalı olduğu durum bariz şekilde daha iyiydi ve 3 turun ardından testi hemen durduracak kadar netti
  Sorun şuydu: bağlam kullanımı bazen azalsa da tamamlanana kadar geçen tur sayısı artıyordu; bu yüzden toplam konuşma maliyeti daha yüksek oluyordu
  Bu tür araçları paylaşan çok insan var ama değerlendirme ya hiç olmuyor ya yeniden üretmesi şüpheli derecede zor oluyor ya da bu araçta olduğu gibi çok benchmark yapılıp yanlış şey ölçülüyor
  Bu aracın grep’ten daha az token kullandığı doğru ve benchmark’lar da bunu gösteriyor, ama önemli olan bu değil. Önemli olan, ajanın bu aracı kullanarak aynı kalitedeki işi daha hızlı ve daha düşük maliyetle yapıp yapamadığı

  • Şu anda genel olarak AI sektöründe test eksikliği var
    Bu sadece bu araca özgü bir sorun değil; kod tabanına ya da geliştirme akışına AI ekleyen her şeyin sorunu
    AI’dan önce de “bu ne kadar hızlı ve ne kadar iyi geliştirildi”yi ölçen testler yoktu, şimdi de eklenmiş değil
  • AI’da “yapabildiğimiz için yaptık, yapmalı mıyız diye düşünmedik” durumu çok sık yaşanacak gibi görünüyor

• Gerçek ajan benchmark’ları görmek isterim. Örneğin Claude Code ya da Copilot CLI’de grep kaldırılıp yerine bu aracın konması gibi
  RTK ve çeşitli LSP uygulamalarına baktım; modeller grep için o kadar güçlü biçimde RL ile şekillendirilmiş ki başka tür sonuçlara güvenmeyip sürekli yeniden deniyor ya da tekrar okuyorlar
  Bu yüzden model diğer araç sonuçlarına güvenmediği için token tasarrufunun tamamı kayboluyor

  • Global CLAUDE.md içine (~/.Claude altında) grep yerine LSP kullanmasını yazdım; o zamandan beri bu sorun kalmadı
  • Codex CLI, RTK’yi oldukça iyi çalıştırıyor. En azından GPT 5.5 xhigh ile öyleydi
    Yalnız find için belirli CLI bayraklarını desteklemediğinde, komutun tam çıktısını göndermek yerine hata mesajı vermesi sinir bozucu
    Böyle olunca ajan token harcayarak yeniden deniyor ya da daha kötüsü, prompt yüzünden RTK olmadan komut çalıştırmaması gerektiğinden korkup hiç denemiyor
  • Biz de bu tür benchmark’larla ilgileniyoruz; modellerin daha rahat kullanabilmesi için prompt ve açıklama optimizasyonu ile birlikte yol haritamızda var
    Anekdot düzeyinde ama tabii ki biz de bu aracı bizzat kullanıyoruz ve şu ana kadar oldukça iyi çalışıyor
    Anthropic modelleri bu aracı çağırıyor ve sonuçlara güveniyor gibi görünüyor
  • Token tasarrufu giderek daha önemli hâle geliyor ama ajanın sonuçlara güvenip aramayı durdurup durdurmadığı da önemli
    Sadece arama çıktısına değil, tam ajan döngüsüne bakmak ve onu ölçmek gerekiyor
  • En azından Codex, grep bazen çok yavaş olduğu için rg kullan denince dinliyor; ama RTK eklenince bu kez RTK üzerinden grep kullanıyor, bu da biraz sinir bozucu

• Fikir iyi göründüğü için biraz kurcaladım
  Testi browsercode(https://github.com/browser-use/browsercode) deposunda yaptım ve prompt şuydu: “yalnızca semble CLI kullanarak, Browsercode’un varsayılan OpenCode araçlarına ek olarak ajana sunduğu araçların ne olduğunu yanıtla. Araç giriş·çıkışlarının tam şemasını ve ne yaptıklarını, nasıl çalıştıklarını kısaca özetle.”
  Buna https://github.com/MinishLab/semble#bash-integration içindeki AGENTS.md parçasını ekledim
  Semble kullanılmayan testte ise aynı soruyu yalnızca rg ve fd CLI kullanacak şekilde değiştirdim
  Her iki durumda da Pi ve gpt-5.4 medium kullandım; diğer ayarlar çok minimaldi. Gerçekten bir tarafta sadece rg ve fd, diğer tarafta sadece semble kullanıldığını da doğruladım
  Semble olmadan model bağlamının %10.9’u ve $0.144 API kredisi kullanıldı; Semble ile %9.8 ve $0.172 kullanıldı
  Sonuç yanıtları da neredeyse aynıydı, yani çok yakındılar
  OpenCode deposunda da bir kez daha test ettim; soru şuydu: “OPENCODE_EXPERIMENTAL_EXA ortam değişkeninin 1 olarak ayarlandığı noktadan başlayıp bunun OpenCode ajanına sunulan sistem promptu ya da araçlarda görülen sonuca kadar olan yolu izle.”
  Yukarıdakiyle aynı yönergeleri ve dokümanları dahil ettim
  Semble olmayan sürüm biraz daha ayrıntılıydı ve web arama sağlayıcısı olarak Exa ya da Parallel’in etkin olup olmamasına göre araç çağrı yolunun Exa’yı çağırıp çağırmadığını da ele alıyordu; ancak gerçek soruya verilen yanıt her iki sürümde de doğruydu
  Semble sürümü bağlamın %14.7’sini / $0.282 API maliyetini kullandı, Semble olmayan sürüm ise %19.0 / $0.352 kullandı
  Bağlam verimliliği açısından Semble açıkça kazandı ama Semble olmayan sürümün yaklaşık iki kat daha hızlı bitmesi dikkat çekici
  Tabii bu sadece benim biraz kurcalamam; sonuçlar değişebilir

• “grep’ten %98 daha az token kullanıyor” denirken, grep o kadar savurgan ki modelin her seferinde %98 oranında işe yaramaz çöp okuduğuna mı inanmamız bekleniyor?
  Bu iddia ya temsili değil ya da modele verilecek bağlamın çoğunu atarken başka bir şeyi kaçırıyor gibisiniz

  • %98, yalnızca grep çıktısıyla değil, grep+read döngüsüyle karşılaştırma
    Ajan tanımadığı bir kod tabanıyla karşılaşınca genelde önce cat file yapıyor ya da dosyanın tamamını okuyor. En azından benim deneyimim böyleydi
    Ajanı güvenilir şekilde yalnızca grep -C N yapıp orada durdurabiliyorsanız kurulumunuzu gerçekten merak ediyorum. Bence bunun sonuç kalitesi yararlı bağlam olarak kullanmak için fazla düşük
  • Claude’un node_modules içindeki eşleşmeler yüzünden yüzlerce kilobayt çıktı okuması gibi bir sorun vardı
    ripgrep yardımcı olduğu için, bir bellek dosyasına bunu kullanmasını söyleyen tek satır eklemek mantıklı geliyor
  • grep, eşleşen tüm satırları çıktılar
    LLM bir arama yaptığında ciddi miktarda gürültü olabilir; ayrıca spesifik arama yapamıyorsa böyle aramalar yapmak zorunda da kalabilir
    Hedef odaklı arama, token sayısını azaltabilir
    Ama bu karşılaştırma sanki yalnızca gereken parçaları almak ile tüm kod tabanını okumayı karşılaştırıyor

• Geri bildirim olarak söyleyeyim, codex-cli bunu MCP üzerinden çağırdığında takılıyor
  semble süreci de zombi gibi kalıp sonsuza dek askıda duruyor. Nedenini bilmiyorum, loglarda da hiçbir şey yok
  Skill üzerinden CLI çağrısı yöntemiyle çağırınca GPT 5.5, ripgrep’e alışkınmış gibi aşırı sayıda arama sorgusu atmaya çalışıyor
  Bunun ne kadar etkili olduğundan emin değilim; GitHub’daki kısa dokümantasyon ve ajan yönergeleriyle neyin en iyi olduğu pek net değil
  Son olarak bash için kurarken GitHub dışı bağlantılarla ilgili birkaç hata da aldım. Bunun takılmayla ilişkili olup olmadığını bilmiyorum
  Ayrıca ajanım sonrasında ripgrep de kullanmaya çalıştı; bu da yinelenen bir davranış gibi görünüyor. Sanki güven sorunu varmış gibi davranıyor
  Daha ayrıntılı ajan skill açıklamaları olursa ajana doğru kullanım şeklini yönlendirmek mümkün olabilir

  • Ayrıntılı geri bildirim için teşekkürler
    Hata için, kurulum ayrıntılarıyla birlikte bir issue açabilirsen çok iyi olur. Bu kesinlikle araştırıp düzeltmek istediğimiz bir şey
    Birden fazla sorgu atma sorunu da gerçekten çok iyi geri bildirim; bunun olmaması için prompt ve yönergeleri güncelleyip ilgili testleri de eklemeye çalışacağız
    Kurulum sırasındaki dış bağlantı hataları büyük ihtimalle uv’nin bağımlılıkları PyPI’dan çekmesinden kaynaklanıyordu; takılmanın sebebi o değildir

• Güzel görünen bir fikir
  İlgili başka bir sorun da şu: küçük kod tabanlarında Claude bazen tüm kod tabanını tek seferde bağlama koyup çok az tokenla işleyebilecekken bile, bir şey bulmak için çok zaman harcıyor
  Fena olmayan bir geçici çözüm, başlangıç hook’u ile tüm dizini bağlama enjekte etmek
  Böylece Claude her görevdeki “karanlıkta el yordamıyla ilerleme” bölümünü atlıyor
  Daha büyük depolarda modele stub içeren bir genel bakış veren harika bir proje de görmüştüm ama adını unuttum

  • Belki aider’dır? https://aider.chat/2023/10/22/repomap.html
  • Haklısın. Ajanlar, baktıkları şeyler hakkında; örneğin dosya sayısı veya dosya boyutu gibi bilgiler konusunda pek farkındalık sahibi değil
    Ama küçük bir kod tabanında aradığın şeyi bulmak da daha kolaydır; bu yüzden arama yine de maliyet düşürmeye yardımcı olabilir

• Bu tür çözümlerin daha büyük sorunu, çoğu AI’ın eğitim sayesinde zaten grep ve aramayı çok iyi kullanıyor olması
  AI’a yeni bir araç verirseniz, bu tür araçlar AI’ın bilişsel kapasitesinin bir kısmını elinden alır
  İnsanlar normalde bu araçları kullanmayı “öğrenir”, ama LLM’in eğitimi sabittir ve zaten grep gibi mevcut araçlarda çok derin bir uzmanlığa sahiptir
  Örneğin AI zaten tree gibi Linux komutlarıyla bir kod tabanını nasıl keşfedeceğini biliyor ve bu da yeterince öğrenilmiş durumda
  Bir diğer sorun, bu araçların faydasını gösteren örnekler üretmenin kolay olması ama bu araçların yol açtığı bilişsel eksikliğin uzun çalışmalarda faydayı dengelediğini gerçekten kanıtlamanın zor olması
  İlk sezgim, uzun çalışmalarda kullanıma sunulabilir zekanın net biçimde azalacağı ve ajanın mevcut araçları kullandığı duruma kıyasla daha kötü performans göstereceği yönünde
  Bunun tersini kanıtlamak kolay bir problem değil ama belki de üstlenmeye değer bir meydan okuma olabilir