# Çok Modlu Füzyon Arama: Her Sorgu için Doğru Getiriciyi Seçmek

Canonical source: https://maguyva.ai/tr/blog/multi-modal-fusion-search

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Date: 2026-04-15 · Author: Maguyva Team

> 'parseConfig nerede tanımlanmış' gibi bir sorgu, 'kimlik doğrulama nasıl çalışıyor' sorgusundan farklı bir arama ister. Maguyva niyeti sınıflandırır, dört getirim modalitesini buna göre ağırlıklandırır ve sonuçları ağırlıklı Reciprocal Rank Fusion ile birleştirir.

> Geçmiş tasarıma ilişkin not: Nisan 2026 tarihli bu makale, o dönemdeki yönlendirme tasarımını açıklar; güncel varsayılan davranışı değil. Aşağıdaki Eylül düzeltmesi yalnızca bir ölçüm iddiasını ele alır. Güncel yönlendirme, hazır ayarlar ve açık modalite kontrolleri için [Nasıl çalışır](https://maguyva.ai/tr/docs/how-it-works) sayfasına bakın.

Bir arama sorgusu tek bir şey değildir.

"`parseConfig` nerede tanımlanmış" tam bir sembol ister — tek, kesin bir konum, hızlıca. "kimlik doğrulama nasıl çalışıyor" anlam ister — bir kavramı açıklayan ilgili kodun yayılımı. "bu fonksiyonu değiştirirsem ne bozulur" bağımlılık grafını ister. "`ECONNREFUSED` dizesini bul" tam bir eşleşme ister, akıllı bir numara değil.

Grep, tam eşleşmeler için mükemmeldir ve bazı referans aramaları için yararlıdır, ama bir bağımlılık grafı değildir ve anlamı anlamaz. Gömme (embedding) vektörleri semantik tarafı kapsar, ama tam dizeler ve etki analizi için yanlış araçtır. Çoğu kod arama aracı tek bir motor seçer ve her sorguyu bu seçimle yaşamaya zorlar. Maguyva seçmez. Sorulan sorunun türünü çözer, sonra dört getiriciyi o sorunun hak ettiği oranda harmanlar.

## Dört modalite

Kaputun altında kod bulmanın dört bağımsız yolu vardır:

- **semantic** — Voyage ikili gömmeleri üzerinden vektör araması; kodu anlamıyla bulur.
- **text** — trigram eşleştirme; tam dizeleri, hata mesajlarını, tam tanımlayıcıları bulur.
- **structural** — AST sorguları; tanımları, imzaları ve dil yapılarını bulur.
- **graph** — bağımlılık grafı; çağıranları, çağrılanları ve etki yarıçapını bulur.

Her biri farklı bir soru sınıfında güçlüdür. Zor olan kısım, karşınızdaki sorgu için her birine ne kadar güveneceğinize karar vermektir.

## Niyet sınıflandırması

Herhangi bir getirim çalışmadan önce, hafif bir sınıflandırıcı sorguyu bir güven puanıyla birlikte altı niyetten birine ayırır. Kasıtlı olarak ucuzdur — sıralı sezgisel yöntemler, ilk eşleşme kazanır — çünkü yoğun yolda çalışır ve sadece bir iki milisaniye ekler:

- `def `, `class `, `func `, `import ` ile başlar… → **find_definition** (güven 0.95)
- "who calls", "usages of", "references to" → **find_references** (0.90)
- "impact", "blast radius", "what depends on" → **impact_analysis** (0.90)
- tırnaklı bir `"string"` veya `traceback` gibi bir hata belirteci → **exact_match** (0.85–0.90)
- bir `CamelCase` veya `snake_case` tanımlayıcısı → **find_definition** (0.60–0.80)
- "how", "why", "explain", "architecture" → **understand_code** (0.75)
- hiçbiri eşleşmez → **understand_code**, düşük güven (0.40)

Her niyet, dört modalite genelinde bir ağırlık profili taşır. Bunlar gerçek sayılardır:

| Niyet | semantic | text | structural (AST) | graph |
|---|---|---|---|---|
| find_definition | 0.2 | 0.1 | **0.6** | 0.1 |
| find_references | 0.1 | 0.2 | 0.2 | **0.5** |
| understand_code | **0.5** | 0.2 | 0.2 | 0.1 |
| find_similar | **0.4** | 0.3 | 0.2 | 0.1 |
| impact_analysis | 0.1 | 0.1 | 0.1 | **0.7** |
| exact_match | 0.0 | **0.9** | 0.1 | 0.0 |

Yani "`parseConfig` nerede tanımlanmış" AST'ye ağır bir şekilde dayanır (0.6). "kimlik doğrulama nasıl çalışıyor" semantik vektörlere dayanır (0.5). "buna ne bağımlı" neredeyse tamamen graf'tır (0.7). "`ECONNREFUSED` bul" neredeyse tamamen trigram'dır (0.9), gömme modeli tamamen devre dışı bırakılmış olarak — çünkü semantik benzerlik, tam bir dize için tam olarak yanlış araçtır.

## Hızlı yol ve birleşik arama yolu

Sınıflandırıcı emin olduğunda — puan ≥ 0.85 — ve sorgu normal bir sorguysa, Maguyva füzyonu tamamen atlar ve doğrudan baskın tek modaliteye yönlendirir. "X nerede tanımlanmış", dört getiriciye ihtiyaç duymaz; şu anda AST dizinine ihtiyaç duyar. Bu doğrudan yol `fusion_strategy: "direct"` olarak geri raporlanır.

Belirsiz olan her şey füzyondan geçer. Dört (veya varsayılan ön ayarda üç) modalite paralel çalışır, her biri kendi sıralı listesini döndürür ve biz bunları birleştiririz.

## Ağırlıklı Reciprocal Rank Fusion

Heterojen getiricileri birleştirmek göründüğünden zordur: 0,82'lik bir kosinüs benzerliği, 137'lik bir trigram puanı ve 0,004'lük bir graf merkeziliği aynı ölçekte değildir, bu yüzden bunları toplayamazsınız. Reciprocal Rank Fusion, ham puanları atıp yalnızca her motorun atadığı **sıralamayı** tutarak sorunu bertaraf eder. Bir sonucun tek bir modaliteden gelen katkısı şudur:

```text
contribution = weight × 1 / (k + rank + 1)
```

burada `rank` o modalitenin listesindeki konumudur ve `k` bir yumuşatma sabitidir. Katkılar, birden fazla motorun bulduğu herhangi bir sonuç için modaliteler arasında toplanır — getiricilerin üzerinde uzlaştığı sonuçlar doğal olarak üst sıralara çıkar. Varsayılan ön ayarda **k = 40**, `thorough`'te ise 60 kullanırız (`quick` yalnızca semantik çalışır, bu yüzden füzyon orada hiç devreye girmez). Orijinal RRF çalışması genel amaçlı getirim için k = 60'ta karar kıldı; biz varsayılan olarak biraz daha keskin bir değer kullanırız, bu da modaliteler arasındaki üst sıralardaki ortak sonuçlara biraz daha fazla ağırlık verir — ve bunu elle ayarlamanızı önermiyoruz.

Bunun üzerine, sonuçlar bir **graf önem artışı** taşır. Bir merkez (hub) — tüm kod tabanının dayandığı bir fonksiyon — aynı metinsel alaka düzeyinde bile az bilinen bir yaprak düğümünü geride bırakmalıdır, bu yüzden her katkıyı şununla çarparız:

```text
boost = min(1 + 0.3 × ln(1 + centrality), 1.5)
```

Merkezilik, hattın önceden hesaplanmış PageRank/derece metriklerinden gelir ve artış 1,5 kat ile sınırlandırılmıştır, böylece popüler bir fonksiyon daha alakalı ama az bilinen bir fonksiyonu tamamen gömemez. Son olarak, vendor, build ve arşiv yollarından gelen sonuçları geriye düşürürüz ve dosya başına en iyi parçaya göre tekilleştiririz.

## Hâlâ kusurlu olan

Niyet sınıflandırıcı, eğitilmiş bir model değil, bir düzenli ifade yığınıdır. Yaygın sorgu biçimlerini sezgisel yöntemlerle işler; belirsiz bir sorgu ise `understand_code` ve semantik ağırlıklı bir karışıma yönelir. Bu yazının önceki bir sürümünde sonuçsuz sorgu oranının yaklaşık %15’ten %5’in altına düşürülmesi gerçekleşmiş bir iyileşme olarak anlatılmıştı. Oysa Aralık 2025 tarihli öneri, tahmini bir başlangıç değeri ve bir hedef içeriyordu; destekleyici bir sorgu kümesi veya ölçüm kaydı sunulmamıştı. İyileşmenin sağlandığına ilişkin bu iddiayı geri çekiyoruz; [kaynak kanıtlara ve düzeltmeye (İngilizce)](https://maguyva.ai/evidence/search-quality.md) bakın. Sınıflandırıcıyı eğitilmiş bir modelle değiştirmedik; çünkü düşük maliyetli sürüm, amaçlanan yönlendirme görevi için hızlı ve yeterince iyi, ayrıca yanlış ama kendinden emin bir sınıflandırıcı dürüst bir yedek yöntemden daha kötü. Ağırlıklar, toplamadığımız tıklama verilerinden öğrenilen değerler değil, elle seçilmiş önsel değerlerdir.

## Aracı Değil, Soruyu Sorun

Bir ajanın grep'e mi, gömmelere mi, yoksa çağrı grafına mi başvuracağını bilmesi gerekmemeli — sorusunu düz bir dille sormalı ve doğru yanıtı almalı. Çok modlu füzyon, `find_symbol`'in, semantik aramanın ve bağımlılık analizinin tek bir sorgu yüzeyinin arkasında oturmasını sağlayan şeydir: sistem sorunun biçimini okur ve sessizce onun için doğru getiriciyi bir araya getirir. Gömmeleri puanlayan model önemlidir, ama onları *ne zaman kullanmayacağını* bilmek de önemlidir. Her sorgu için doğru aracı seçmek kendi başına bir kalite türüdür ve bunu çağırana devretmek yerine sahiplenmeyi tercih ederiz.

`// you bring the question. it brings the tools.`