Carian Fusion Pelbagai-Modal: Memilih Retriever Yang Tepat Untuk Setiap Pertanyaan

Nota reka bentuk terdahulu: artikel April 2026 ini menerangkan reka bentuk penghalaan pada waktu itu, bukan tingkah laku lalai semasa. Pembetulan September di bawah hanya menangani dakwaan pengukuran. Untuk penghalaan, pratetap dan kawalan modaliti eksplisit semasa, lihat Cara Ia Berfungsi.

Satu pertanyaan carian bukanlah satu perkara sahaja.

“di mana parseConfig ditakrifkan” mahukan simbol yang tepat — satu lokasi yang jitu, pantas. “bagaimana pengesahan (authentication) berfungsi” mahukan makna — sebaran kod berkaitan yang menerangkan sesuatu konsep. “apa yang akan rosak jika saya menukar fungsi ini” mahukan graf kebergantungan. “cari string ECONNREFUSED” mahukan padanan literal, tiada yang bijak-bijak.

Grep sangat baik untuk padanan literal dan berguna untuk sesetengah pemburuan rujukan, tetapi ia bukan graf kebergantungan dan ia tidak memahami makna. Embeddings merangkumi sisi semantik, tetapi ia adalah alat yang salah untuk string tepat dan analisis kesan. Kebanyakan alat carian kod memilih satu enjin dan memaksa setiap pertanyaan menggunakan enjin yang dipilih itu. Maguyva tidak terikat pada satu enjin. Ia mengetahui jenis soalan apa yang anda ajukan, kemudian menggabungkan empat retriever dalam nisbah yang sepatutnya untuk soalan itu.

Empat modaliti

Di sebalik tabir terdapat empat cara bebas untuk mencari kod:

• semantic — carian vektor terhadap embeddings binari Voyage; mencari kod mengikut makna.
• text — padanan trigram; mencari literal, string ralat, pengecam tepat.
• structural — query AST; mencari takrifan, tandatangan (signature), dan konstruk bahasa.
• graph — graf kebergantungan; mencari caller, callee, dan lingkungan impak.

Setiap satu kuat pada kelas soalan yang berbeza. Kuncinya ialah menentukan sejauh mana setiap satu patut dipercayai untuk pertanyaan yang ada di hadapan anda.

Pengklasifikasian niat

Sebelum sebarang pengambilan berjalan, satu classifier ringan menyusun pertanyaan itu ke dalam salah satu daripada enam niat, dengan skor keyakinan. Ia sengaja dibuat murah — heuristik tersusun, padanan pertama menang — kerana ia berjalan pada laluan panas (hot path) dan hanya menambah satu atau dua milisaat:

• bermula dengan def , class , func , import … → find_definition (keyakinan 0.95)
• “who calls” (siapa memanggil), “usages of” (penggunaan), “references to” (rujukan kepada) → find_references (0.90)
• “impact” (kesan), “blast radius”, “what depends on” (apa yang bergantung pada) → impact_analysis (0.90)
• "string" yang dipetik atau token ralat seperti traceback → exact_match (0.85–0.90)
• satu pengecam CamelCase atau snake_case → find_definition (0.60–0.80)
• “how” (bagaimana), “why” (mengapa), “explain” (terangkan), “architecture” (seni bina) → understand_code (0.75)
• tiada yang sepadan → understand_code, keyakinan rendah (0.40)

Setiap niat membawa profil pemberat merentasi keempat-empat modaliti. Ini adalah angka sebenar:

Niat	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

Jadi “di mana parseConfig ditakrifkan” sangat bergantung pada AST (0.6). “bagaimana auth berfungsi” condong kepada vektor semantik (0.5). “apa yang bergantung kepada ini” hampir semuanya graf (0.7). “cari ECONNREFUSED” hampir semuanya trigram (0.9), dengan model embedding dimatikan sepenuhnya — kerana persamaan semantik adalah alat yang sama sekali tidak sesuai untuk string yang tepat.

Laluan pantas, dan laluan fusion

Apabila classifier itu yakin — skor ≥ 0.85 — dan pertanyaan itu adalah biasa, Maguyva melangkau fusion sepenuhnya dan menghalakan terus kepada satu modaliti dominan. “di mana X ditakrifkan” tidak memerlukan empat retriever; ia memerlukan indeks AST, sekarang. Laluan langsung itu dilaporkan semula sebagai fusion_strategy: "direct".

Segala yang kabur melalui fusion. Keempat-empat (atau tiga, pada preset lalai) modaliti berjalan secara selari, setiap satu memulangkan senarai hasilnya sendiri yang disusun mengikut kedudukan, dan kami menggabungkannya.

Reciprocal Rank Fusion Berpemberat

Menggabungkan retriever yang heterogen lebih sukar daripada yang kedengaran: persamaan kosinus 0.82 dan skor trigram 137 dan kesentralan graf 0.004 tidak berada pada skala yang sama, jadi anda tidak boleh sekadar menjumlahkannya. Reciprocal Rank Fusion mengelakkan masalah ini dengan membuang skor mentah dan hanya mengekalkan kedudukan (rank) yang diberikan oleh setiap enjin. Sumbangan sesuatu hasil daripada satu modaliti ialah:

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

di mana rank adalah kedudukannya dalam senarai modaliti itu dan k adalah pemalar pelicinan (smoothing constant). Sumbangan dijumlahkan merentasi modaliti untuk sebarang hasil yang ditemui oleh lebih daripada satu enjin — persetujuan antara retriever secara semula jadi terapung ke atas. Kami menggunakan k = 40 pada preset lalai dan 60 pada thorough (quick berjalan semantik-sahaja, jadi fusion tidak pernah berlaku di situ). Kajian RRF asal mencapai k = 60 untuk pengambilan tujuan umum; kami menetapkan lalai yang sedikit lebih tajam, yang memberi persetujuan berkedudukan tinggi antara modaliti sedikit lebih banyak pemberat — dan kami tidak mengesyorkan penyelarasan manual.

Selain itu, hasil membawa satu boost kepentingan graf. Satu hub — fungsi yang menjadi sandaran keseluruhan pangkalan kod — sepatutnya mengatasi kedudukan nod daun yang kurang dikenali walaupun pada relevans tekstual yang sama, jadi kami mendarab setiap sumbangan dengan:

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

Kesentralan datang daripada metrik PageRank/degree yang telah dikira lebih awal oleh pipeline, dan boost itu dihadkan pada 1.5× supaya sesuatu fungsi yang popular tidak boleh sepenuhnya mengubur fungsi yang kurang dikenali tetapi lebih relevan. Akhir sekali kami menurunkan taraf hasil daripada laluan vendor, build, dan arkib, dan dedupe kepada chunk terbaik bagi setiap fail.

Apa yang masih tidak sempurna

Pengelas niat ialah sekumpulan regex, bukan model terlatih. Ia mengendalikan bentuk pertanyaan lazim menggunakan heuristik, dan pertanyaan yang kabur kembali kepada understand_code serta gabungan yang condong kepada semantik. Versi terdahulu catatan ini menyatakan penurunan kadar carian tanpa hasil daripada sekitar 15% kepada bawah 5% sebagai peningkatan yang telah dicapai. Cadangan Disember 2025 sebenarnya menyenaraikan anggaran garis dasar dan sasaran; tiada set pertanyaan sokongan atau rekod pengukuran dibekalkan. Kami menarik balik dakwaan bahawa peningkatan itu telah dicapai; lihat bukti sumber dan pembetulan. Kami belum menggantikan pengelas dengan model terlatih kerana versi murah itu pantas dan cukup baik untuk peranan penghalaan yang dimaksudkan, dan kerana pengelas yang salah tetapi yakin lebih buruk daripada fallback yang jujur. Pemberat itu sendiri ialah prior yang dipilih secara manual, bukan dipelajari daripada data klik yang tidak kami kumpulkan.

Tanya Soalan Itu, Bukan Toolnya

Seorang ejen tidak sepatutnya perlu tahu sama ada hendak menggunakan grep atau embeddings atau graf panggilan — ia sepatutnya bertanya soalannya dalam istilah biasa dan mendapat jawapan yang betul. Fusion pelbagai-modal itulah yang membolehkan find_symbol, carian semantik, dan analisis kebergantungan berada di sebalik satu antara muka pertanyaan: sistem membaca bentuk soalan itu dan secara senyap menyusun retriever yang tepat untuknya. Model yang memberi skor kepada embeddings itu penting, tetapi begitu juga mengetahui bila tidak menggunakannya. Memilih tool yang tepat untuk setiap pertanyaan adalah satu jenis kualiti tersendiri, dan kami lebih rela memikul tanggungjawab itu daripada membebankannya kepada pemanggil.

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