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

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 menjadikan setiap pertanyaan hidup dengan pilihan itu. Maguyva tidak memilih. 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 radius kesan.

Setiap satu kuat pada kelas soalan yang berbeza. Tipunya ialah menentukan berapa banyak untuk mempercayai setiap satu 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)
• “siapa memanggil”, “penggunaan”, “rujukan kepada” → find_references (0.90)
• “kesan”, “blast radius”, “apa yang bergantung kepada” → 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)
• “bagaimana”, “mengapa”, “terangkan”, “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” condong berat kepada 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 tepat salah 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 bertingkatnya sendiri, 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 disandarkan oleh keseluruhan pangkalan kod — sepatutnya mengatasi kedudukan sehelai daun yang kabur 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 satu fungsi kabur yang 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

Classifier niat adalah satu timbunan regex, bukan model yang dipelajari. Ia merangkumi bentuk pertanyaan yang biasa dengan baik — keputusan yang memperkenalkannya merekodkan kadar sifar-hasil menurun daripada lebih kurang 15% kepada di bawah 5% — tetapi ia heuristik, dan pertanyaan yang benar-benar kabur jatuh kepada understand_code dan campuran yang condong semantik. Itu adalah lalai yang selamat, bukan yang bijak. Kami belum menggantikannya dengan classifier terlatih kerana versi murah itu pantas dan cukup baik, dan kerana classifier yang salah-tetapi-yakin lebih teruk daripada fallback yang jujur. Pemberat itu sendiri adalah prior yang dipilih secara manual, bukan dipelajari daripada data klik yang tidak kami kumpul.

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 permukaan 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 itulah yang lebih kami mahu miliki berbanding melemparkannya kepada pemanggil.

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