GraphRAG vastaan tavallinen vektorihaku

Haulla täydennetystä generoinnista on tullut oletustapa ankkuroida kielimalli omaan dataan, ja useimmille tiimeille se tarkoittaa yhtä: upota kaikki vektoreiksi, tallenna vektoritietokantaan ja hae lähimmät osumat jokaiseen kysymykseen. Suurelle joukolle ongelmia tämä toimii huomattavan hyvin. Mutta on toinen joukko jossa se hiljaa epäonnistuu, ja epäonnistuminen on helppo ohittaa koska järjestelmä palauttaa yhä itsevarmoja, uskottavia vastauksia — vain puutteellisia tai vääriä.

Ratkaiseva ero ei ole kumpi teknologia on uudempi tai hienostuneempi. Se on datasi muoto ja kysymysten muoto. Kun tuo diagnoosi osuu, valinta pelkän vektorihaun ja graafipohjaisen lähestymistavan välillä muuttuu itsestäänselväksi.

Missä vektorihaku on aidosti hyvä

Vektorihaku vastaa samankaltaisuuskysymyksiin. Sinulla on iso tekstimassa, joku kysyy, ja vastaus on yhdessä kappaleessa — tai muutamassa — jotka ovat semanttisesti lähellä kysymystä. Tuotedokumentaatio, tietokannat, tukiarkistot, tutkimuskirjastot: lähes täydellinen sopivuus. Fakta istuu palasessa, palanen muistuttaa kyselyä, ja haku löytää sen.

Tälle joukolle vektorihaku on nopea, halpa ja vaikea voittaa. Graafikoneiston lisääminen päälle olisi ylisuunnittelua — kompleksisuutta ilman vastinetta. Jos kysymyksesi vastaa osuvin kappale, et tarvitse mitään monimutkaisempaa, ja sanomme sen sen sijaan että myisimme suuremman järjestelmän.

Missä vektorihaku hiljaa hajoaa

Ongelma alkaa kun vastaus ei ole missään yksittäisessä kappaleessa vaan kappaleiden välisissä suhteissa. Mieti kysymystä: mitkä toimittajat kärsivät säädöksestä joka muuttaa toista säädöstä joka koskee komponenttia jota käytetään tietyn tytäryhtiön tuotelinjassa? Yksikään palanen ei sisällä vastausta. Se pitää koota seuraamalla linkkejä faktasta toiseen.

Vektorihaku ei osaa seurata linkkejä. Se hakee kyselyä muistuttavia kappaleita, mutta samankaltaisuus ei ole yhteys. Yksittäiset hypyt voivat kukin olla tekstillisesti erilaisia kuin alkukysely, joten oikeat kappaleet eivät koskaan nouse. Malli vastaa sitten siitä mitä haki — sujuvasti, itsevarmasti, väärin. Juuri tämä yllättää tiimit, koska mikään ei heitä virhettä.

Mitä tietograafi tuo lisää

Tietograafi tallentaa faktat eksplisiittisinä entiteetteinä ja suhteina: tämä säädös muuttaa tuota, tämä komponentti kuuluu tuohon tuotteeseen, tämä tuote tuohon tytäryhtiöön. GraphRAG yhdistää tämän rakenteen hakuun. Sen sijaan että löytäisi vain samankaltaista tekstiä, se voi kulkea graafin läpi — muutoslinkki, sitten komponenttilinkki, sitten omistuslinkki — ja koota vastauksen yhdistettyjen faktojen ketjusta.

Tämä avaa monihyppykysymykset joihin litteä haku ei yllä. Se tuo toisen, säännellyissä yhteyksissä valtavan tärkeän edun: jäljitettävyyden. Koska vastaus rakennettiin kulkemalla eksplisiittinen polku graafin läpi, voit näyttää tuon polun. Vastaus saapuu päättelynsä kanssa, jonka tarkastajat voivat varmentaa.

Graafin hinta

Graafit eivät ole ilmaisia. Sellaisen rakentaminen tarkoittaa entiteettien ja suhteiden poimimista datasta — mallinnustyö jonka vektorihaku ohittaa kokonaan. Sinun on päätettävä mitä entiteetit ovat, mitkä suhteet niitä yhdistävät, ja pidettävä rakenne ajan tasalla. Tekstille jonka vastaukset oikeasti ovat yksittäisissä kappaleissa tämä on puhdasta yleiskustannusta ilman tuottoa.

Juuri siksi diagnoosi tulee ensin. Graafiin tarttuminen koska se kuulostaa tehokkaammalta on yleinen ja kallis virhe. Graafi ansaitsee hintansa vain kun kysymyksesi aidosti vaativat yhteyksien seuraamista; muuten se on kompleksisuutta jota ylläpidät ikuisesti ilman hyötyä.

Hybridi joka yleensä voittaa

Käytännössä vahvimmat järjestelmät ovat harvoin puhtaita. Useimmat oikeat korpukset sisältävät molempia kysymyksiä: monia joihin yksi osuva kappale vastaa, ja joitakin jotka vaativat faktojen yhdistämistä. Oikea arkkitehtuuri käyttää vektorihakua semanttiseen palautukseen ja graafikerrosta relationaalisiin monihyppytapauksiin, reitittäen kunkin kysymyksen sopivalle mekanismille.

Tuon jaon hyvä suunnittelu — mitä mallintaa graafiksi, mitä jättää litteäksi tekstiksi, miten yhdistää nämä kyselyaikana — on missä suurin osa insinööriharkinnasta on. Oikein tehtynä maksat graafin kompleksisuudesta vain siellä missä se maksaa takaisin.

Miten tunnistaa kumman tarvitset

Voit yleensä diagnosoida tapauksesi pelkistä kysymyksistä. Kirjoita kymmenen vaikeinta kysymystä joita käyttäjäsi oikeasti kysyvät. Jos kuhunkin vastaa yksi osuvin kappale, tarvitset vektorihaun etkä muuta. Jos joihinkin voi vastata vain yhdistämällä useita faktoja jotka eivät ole tekstillisesti samankaltaisia, sinulla on monihyppykysymyksiä, ja graafikerros ansaitsee paikkansa.

Aloitamme jokaisen hakuprojektin juuri tällä harjoituksella, oikeilla kysymyksilläsi ja datallasi, ennen kuin kirjoitamme koodia. Teknologia seuraa diagnoosia, ei koskaan toisin päin — ja diagnoosi on lähes aina selvempi kuin kummankaan lähestymistavan markkinointi antaa ymmärtää.