Monimodaalinen fuusiohaku: oikean hakukoneen valinta jokaiselle kyselylle

Hakukysely ei ole yksi asia.

“missä parseConfig on määritelty” haluaa tarkan symbolin — yhden täsmällisen sijainnin, nopeasti. “miten todennus toimii” haluaa merkityksen — liittyvän koodin levittäytymän, joka selittää käsitteen. “mitä hajoaa, jos muutan tätä funktiota” haluaa riippuvuusgraafin. “etsi merkkijono ECONNREFUSED” haluaa kirjaimellisen osuman, ei mitään nokkelaa.

Grep on erinomainen kirjaimellisiin osumiin ja hyödyllinen joissakin viittausmetsästyksissä, mutta se ei ole riippuvuusgraafi eikä ymmärrä merkitystä. Upotukset kattavat semanttisen puolen, mutta ne ovat väärä työkalu tarkoille merkkijonoille ja vaikutusanalyysille. Useimmat koodihakutyökalut valitsevat yhden moottorin ja pakottavat jokaisen kyselyn elämään sen valinnan kanssa. Maguyva ei valitse. Se selvittää, minkälainen kysymys esitit, ja sekoittaa sitten neljä hakukonetta suhteessa, jonka kysymys ansaitsee.

Neljä modaliteettia

Konepellin alla on neljä riippumatonta tapaa löytää koodia:

• semanttinen — vektorihaku Voyage-binääriupotusten yli; löytää koodia merkityksen perusteella.
• teksti — trigrammivastaavuus; löytää kirjaimellisuudet, virhemerkkijonot, tarkat tunnisteet.
• rakenteellinen — AST-kyselyt; löytää määrittelyt, allekirjoitukset ja kielirakenteet.
• graafi — riippuvuusgraafi; löytää kutsujat, kutsuttavat ja vaikutusalueen.

Jokainen on vahva erilaisessa kysymysluokassa. Temppu on päättää, kuinka paljon luottaa kuhunkin edessäsi olevaan kyselyyn.

Tarkoituksen luokittelu

Ennen minkään haun ajamista kevyt luokitin lajittelee kyselyn yhteen kuudesta tarkoituksesta, luottamuspisteellä. Se on tarkoituksella halpa — järjestettyjä heuristiikkoja, ensimmäinen osuma voittaa — koska se ajetaan kuumalla polulla ja lisää vain millisekunnin tai pari:

• alkaa sanoilla def , class , func , import … → find_definition (luottamus 0.95)
• “kuka kutsuu”, “käyttökohteet”, “viittaukset kohteeseen” → find_references (0.90)
• “vaikutus”, “blast radius”, “mikä on riippuvainen tästä” → impact_analysis (0.90)
• lainausmerkeissä oleva "string" tai virhetunniste kuten traceback → exact_match (0.85–0.90)
• CamelCase- tai snake_case-tunniste → find_definition (0.60–0.80)
• “miten”, “miksi”, “selitä”, “arkkitehtuuri” → understand_code (0.75)
• mikään ei täsmää → understand_code, matala luottamus (0.40)

Jokaisella tarkoituksella on painoprofiili neljän modaliteetin yli. Nämä ovat todelliset luvut:

Tarkoitus	semanttinen	teksti	rakenteellinen (AST)	graafi
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

Joten “missä parseConfig on määritelty” nojaa vahvasti ASTiin (0.6). “miten todennus toimii” nojaa semanttisiin vektoreihin (0.5). “mikä on riippuvainen tästä” on lähes kokonaan graafia (0.7). “etsi ECONNREFUSED” on lähes kokonaan trigrammia (0.9), upotusmallin ollessa kokonaan pois päältä — koska semanttinen samankaltaisuus on juuri väärä työkalu tarkalle merkkijonolle.

Nopea polku ja yhdistetty polku

Kun luokitin on varma — pisteet ≥ 0.85 — ja kysely on tavallinen, Maguyva ohittaa fuusion kokonaan ja reitittää suoraan yhteen hallitsevaan modaliteettiin. “missä X on määritelty” ei tarvitse neljää hakukonetta; se tarvitsee AST-indeksin, heti. Tuo suora polku raportoidaan takaisin nimellä fusion_strategy: "direct".

Kaikki epäselvä kulkee fuusion läpi. Neljä (tai kolme, oletusesiasetuksella) modaliteettia ajetaan rinnakkain, kukin palauttaen oman järjestetyn listansa, ja yhdistämme ne.

Painotettu Reciprocal Rank Fusion

Heterogeenisten hakukoneiden yhdistäminen on vaikeampaa kuin miltä kuulostaa: kosinisamankaltaisuus 0.82 ja trigrammipisteet 137 ja graafin keskeisyys 0.004 eivät ole samalla asteikolla, joten niitä ei voi vain laskea yhteen. Reciprocal Rank Fusion kiertää ongelman heittämällä pois raakapisteet ja säilyttämällä vain kunkin moottorin antaman sijoituksen. Tuloksen panos yhdestä modaliteetista on:

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

jossa rank on sen sijainti kyseisen modaliteetin listalla ja k on tasoituskonstantti. Panokset summataan yli modaliteettien mille tahansa tulokselle, jonka useampi kuin yksi moottori löysi — hakukoneiden välinen yksimielisyys nousee luonnollisesti pintaan. Käytämme k = 40 oletusesiasetuksella ja 60 thorough:ssä (quick ajaa vain semanttisen haun, joten fuusio ei koskaan käynnisty siellä). Alkuperäinen RRF-työ päätyi arvoon k = 60 yleiskäyttöiselle haulle; me oletamme hieman terävämmän, mikä antaa modaliteettien väliselle kärkijärjestyksen yksimielisyydelle hieman enemmän painoa — emmekä suosittele sen käsivaraista säätämistä.

Tämän lisäksi tulokset kantavat graafin tärkeyden korotusta. Solmupisteen — funktion, johon koko koodikanta nojaa — pitäisi ylittää epäselvä lehti jopa samalla tekstuaalisella relevanssilla, joten kerromme jokaisen panoksen luvulla:

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

Keskeisyys tulee putken esilaskettuista PageRank/aste-metriikoista, ja korotus rajataan 1.5×:ään, jotta suosittu funktio ei voi täysin hautaa relevantimpaa epäselvää funktiota. Lopuksi alennamme tuloksia vendor-, build- ja arkistopoluista ja poistamme duplikaatit parhaaksi palaksi tiedostoa kohti.

Mikä on yhä epätäydellistä

Tarkoitusluokitin on pino regexejä, ei opittu malli. Se kattaa hyvin kyselyn yleiset muodot — päätös, joka toi sen käyttöön, kirjasi nollatulossuhteen laskun noin 15 %:sta alle 5 %:iin — mutta se on heuristinen, ja aidosti epäselvä kysely putoaa understand_code:ään ja semanttisesti painottuneeseen sekoitukseen. Se on turvallinen oletus, ei nokkela. Emme ole korvanneet sitä opetetulla luokittimella, koska halpa versio on nopea ja tarpeeksi hyvä, ja koska väärässä mutta itsevarma luokitin on pahempi kuin rehellinen varajärjestely. Painot itsessään ovat käsin valittuja prioreja, ei opittu klikkausdatasta, jota emme kerää.

Kysy kysymys, älä työkalua

Agentin ei pitäisi tarvita tietää, tarttuuko grepiin, upotuksiin vai kutsugraafiin — sen pitäisi esittää kysymyksensä yksinkertaisin sanoin ja saada oikea vastaus. Monimodaalinen fuusio on se, mikä antaa find_symbol:n, semanttisen haun ja riippuvuusanalyysin istua yhden kyselypinnan takana: järjestelmä lukee kysymyksen muodon ja kokoaa hiljaa oikean hakukoneen sitä varten. Malli, joka pisteyttää upotukset, merkitsee, mutta niin merkitsee myös tietäminen, milloin ei käyttää niitä. Oikean työkalun valitseminen jokaiselle kyselylle on omanlaistaan laatua, ja se on sellaista, jonka mieluummin omistamme kuin työnnämme kutsujalle.

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