Nasıl ölçüyoruz

Bu kategorideki herkes özenle seçilmiş bir doğruluk sayısı gösterir. Biz sana metodolojiyi ve gerçek-repo sonuçlarını göstermeyi tercih ederiz — düşük görünenler dahil. İşte neyi, nasıl ölçüyoruz ve ne elde ediyoruz.

Hafıza getirme

Asıl ayırt edici olan. Bir sorgu verildiğinde, doğru hafıza ilk sırada geri geliyor mu? Etiketli bir sorgu → doğru-not çiftleri kümesinde değerlendirir ve standart getirme metriklerini raporlarız.

precision@1, en üstteki sonucu doğru not olan sorguların oranıdır; MRR ise doğru cevap ilk değilken onun sırasını kredilendirir. İkisi de ürünün gönderdiği aynı kaynaşık lexical + semantic getirmeden gelir.

Kod arama

search_codebase, doğru-hedefleri bilinen bir fixture'a karşı: her sorgu için, amaçlanan sembol en üstteki isabet mi?

Fixture'da %100 güçlü ve dürüst bir sonuç: bu bir fixture, tüm dünya değil. Sana getirmenin bizim derlediğimiz vakalarda sağlam olduğunu söyler — bunu “makine çalışıyor” diye oku, “senin repo'nda kusursuz” diye değil.

Token maliyeti — harita vs dosyaları yeniden okuma

Tüm mesele, kodun hakkındaki soruları her oturumda yeniden okumadan cevaplamak. Yani önemli olan sayı, bir sorunun gerçekte ne kadara mal olduğu. Bunu adil yolla ölçeriz: bir dizi gerçek soru için, hibrit arama en-alakalı top-6 dosyayı seçer; SecondOS onların harita kartlarını besler (path + imzalar + doc yorumları, asla gövdeler değil — K‑S23), soğuk bir ajan ise aynı dosyaların tüm kaynağını okur. Aynı dosyalar, harita vs gövde.

Bu repo'da soru-başına oran 4.7×; 1,600-dosyalık bir üretim uygulamasında 5.6× (soru başına ≈2,200 token kart vs ≈12,500 kaynak). Soru-başına ~5× ile öne çıkıyoruz çünkü bir şeyi cevaplamak için ödediğin bu — en iyi durum değil. 193× ise altındaki dürüst yapısal gerçek: tüm harita bir özet, yani tüm repo kaynağından ~193× daha küçük. İkisini de kendi repo'nda üret: bun scripts/benchmark-context.ts <repo> (soru-başına) veya bun scripts/benchmark-tokens.ts <repo> (tüm harita).

Üç koşul, beş gerçek repo

Bir repo tek bir veri noktasıdır. İşte aynı oryantasyon maliyeti — bir ajanın bir codebase'de yönünü bulmak için yüklemesi gereken token'lar — beş gerçek repository'de, üç koşul altında: ajan (hafıza yok, kaynağı baştan okur), ajan + hafıza (bir ekibin tuttuğu el-yazımı docs — indekssiz, toptan yüklenir, çabuk çürür) ve ajan + SecondOS (harita: yalnızca yapı, K‑S23, otomatik-üretilmiş ve sorgu-kapsamlı).

Harita sınırlı kalır — repo boyutu ne olursa olsun ~2–2.6k token (51 dosya ya da 2,302), oysa hem kaynak hem el-yazımı docs sınırsız büyür. Ve docs'un aksine, harita sorgu-kapsamlıdır ve kod hareket ettikçe taze kalır; el-yazımı bir CONTEXT.md, birileri güncellemeyi unuttuğu an bayatlar. Soru başına, gerçek getirme yolundan, bu aynı dosyaları soğuk okumaya kıyasla 4.7× (secondos) · 5.6× (gurulu) · 8.8× (tcg-terminal) daha az token — tcg-terminal buluta push edildi ve ürün üzerinden canlı cevaplandı. Kendi repo'larında üret: bun scripts/benchmark-3way.ts <repo…>.

Gerçek repo'larda ilişki grafiği

who_uses ve impact_of, “bunu kim çağırıyor?” ve “değiştirirsem ne kırılır?” sorularını cevaplar. Onları yedi gerçek açık-kaynak repository'ye karşı çalıştırdık ve grafiğin çözdüğü karara-bağlanabilir iç çağrıların oranını ölçtük.

Bunları bir hassasiyet duruşu olarak oku, bir kapsam açığı olarak değil. who_uses / impact_of, kanıtlayabildikleri çağrıları çözer ve asla tahmin etmez; gerisi, hiçbir statik aracın kodunu çalıştırmadan çözemeyeceği dinamik ve örnek-metot dağıtımı — ve sana yanlış bir çağıran göstermektense “bilinmiyor” demeyi tercih ederiz. Buradaki düşük bir sayı daha az bulduğumuz anlamına gelmez; yalnızca arkasında durabileceğimizi iddia ettiğimiz anlamına gelir. Çözülen her kenar bir güven basamağı taşır — exact, resolved, heuristic — böylece hangisinin hangisi olduğunu hep bilirsin.

Yelpazenin geniş olmasının sebebi bu. Python, PHP, Rust ve Java daha çok statik olarak karara-bağlanabilir çağrı yeri sunar; Go'nun arayüzleri ve Ruby'nin ağır dinamik dağıtımı, programı çalıştırmadan gerçekten karara-bağlanamaz daha çok çağrı bırakır. Kanıtlanabilir kesri, güvendiğin an impact_of'unu kıracak tahminlerle şişirmek yerine olduğu gibi raporlarız.

Kendi repo'nda kanıtla

Sayılarımıza güvenmekten iyisi: onları kendi kodunda üret. Yukarıdaki her şey iki açık script'ten çalışır — elde ettiğin sayı bizim değil, senin.

bunx @secondos/cli push .              # map your repo (source stays local)
bun scripts/benchmark-context.ts .     # tokens/question — the map vs re-reading files
bun scripts/benchmark-tokens.ts .      # the whole map vs the whole source

Neden bir standart göstermek yerine kendi metodolojimizi yayımlıyoruz? Çünkü standart hafıza benchmark'ları (LOCOMO, DMR) konuşmasal getirmeyi ölçer — bir sohbetin ne dediğini hatırlamayı. Bu farklı bir kategori. “AI'ın bu codebase'i yeniden okumadan anlıyor mu” için kimsede bir standart yok — bu yüzden birini biz tanımlarız, açıkta, gerçek repo'larda ve bizi kontrol etmen için script'leri sana veririz. Gerçekten yaptığın şey için benchmark'a sahip ol; başka bir iş için yapılmış birini ödünç alma.

Sonraki

Bu sayıların tarif ettiği araçlar için MCP sunucusu'na, grafiğin ve hafızanın nasıl uyuştuğu için ürün genel bakışı'na veya güven sınırı için güvenlik'e bak.