Hybridihaku: BM25 vs vektori (ja miksi tarvitset molemmat)

Hybridihaku: BM25 vs vektori (ja miksi tarvitset molemmat)

Tukihenkilö kirjoittaa "SKU-4471" RAG-chatbottiisi. Neljä tulosta tulee takaisin. Kaikki ovat itsevarmasti väärin. Yleiskäyttöisellä upotusmallilla ei ole mitään syytä sijoittaa juuri tuota merkkijonoa lähelle itseään vektoriavaruudessa. Juuri tämä virhetila on syy siihen, miksi hybridihaku on olemassa, ja siksi tiimit kysyvät yhä uudestaan yhtä tiettyä kysymystä: miten BM25 ja vektorihaku oikeasti yhdistetään ilman, että joudut ikuisesti vääntämään säätönuppia?

Jos arvioit RAG-työkaluja laajemmin, parhaiden RAG-työkalujen katsauksemme käy läpi ympäröivän pinon.

Keskeisimmät opit

• BM25 löytää tarkat avainsanaosumat (SKU-tunnukset, virhekoodit); vektorihaku löytää käsitteellisesti samankaltaista tekstiä, ei identtisiä merkkijonoja.
• Hybridihaku yhdistää molemmat, tyypillisesti Reciprocal Rank Fusionin (RRF) avulla, ja voittaa kumman tahansa menetelmän yksinään sekamuotoisilla kyselykuormilla.
• WANDS-benchmarkissa pelkkä RRF saa 0,7068 NDCG:n (BM25:n 0,6983:a vastaan); säätö nostaa sen 0,7497:ään, eli 7,4 % parannukseen.
• Postgres/pgvector pystyy ajamaan hybridihakua natiivisti ts_rank + pgvector-yhdistelmällä ilman erillistä vektoritietokantaa.

Mikä on hybridihaku? (BM25 + vektori yhdistettynä)

Hybridihaku ajaa BM25:n ja vektorihaun kahtena erillisenä hakukierroksena saman kyselyn yli ja yhdistää sitten kaksi järjestettyä tuloslistaa yhdeksi tulokseksi fuusioalgoritmilla, useimmiten Reciprocal Rank Fusionilla. Se ei ole kolmas hakumenetelmä; se on orkestrointikerros kahden olemassa olevan päällä.

Erotuksella on väliä, koska huomattava osa tähän aiheeseen liittyvästä hakuliikenteestä sekoittaa BM25:n ja vektorihaun toisiinsa ikään kuin ne olisivat sama asia. Ne eivät ole. BM25 on harva, avainsanapohjainen pisteytysfunktio, jonka juuret ovat 1970-luvun tiedonhaussa. Vektorihaku on tiheä, upotuksiin perustuva samankaltaisuushaku, joka tuli käytännölliseksi suuressa mittakaavassa vasta viime vuosikymmenenä. Hybridihaku käsittelee niitä toisiaan täydentävinä syötteinä, ei kilpailevina tekniikoina, ja yhdistää niiden tulokset sen sijaan että valitsisi voittajan etukäteen.

BM25 vs vektori vs hybridihaku: pikavertailu

WANDS-verkkokaupan benchmarkissa pelkkä BM25 sai 0,6983 NDCG:n ja pelkkä vektorihaku 0,6953 (lähes tasan). Pelkkä RRF-fuusio ilman korpuskohtaista säätöä pääsi 0,7068:aan, vaatimattomaan 1,2 % parannukseen BM25:stä. Doug Turnbullin benchmark testasi myös säädettyä muunnelmaa, joka lisää tuotenimiboostin RRF:n päälle, ja se versio ylsi 0,7497:ään, eli 7,4 % parannukseen. Kannattaa olla rehellinen siitä, kumpaa lukua lainaa: pelkkä RRF antaa pienen mutta todellisen edun suoraan laatikosta; isompi 7,4 % luku vaati ylimääräistä toimialakohtaista säätöä, jonka useimmat tiimit jättävät ensimmäisenä päivänä väliin. Kumpikaan, BM25 tai vektorihaku, ei hallitse yksinään; ne kattavat eri virhetiloja, ja niiden yhdistäminen sulkee molemmat aukot kerralla.

BM25:n mekaniikka: miten avainsanahaku oikeasti pisteyttää osuvuutta

BM25 pisteyttää dokumentit termifrekvenssin perusteella, painottaen termin harvinaisuutta koko korpuksessa, ja normalisoi sitten pisteen dokumentin pituuden mukaan. Robertson ja Zaragoza esittivät tämän formalisoinnin vuoden 2009 paperissaan "The Probabilistic Relevance Framework: BM25 and Beyond". Se on TF-IDF:n jalostus, ei sen korvaaja.

Kaksi parametria hallitsee suurinta osaa BM25:n käyttäytymisestä. k1 (tyypillisesti 1,2–2,0) hallitsee termifrekvenssin kyllästymistä: se rajoittaa, kuinka paljon sanan toistaminen nostaa pistettä, jotta dokumentti, jossa "invoice" esiintyy 40 kertaa, ei automaattisesti ohita dokumenttia, jossa sama sana esiintyy 4 kertaa tiiviimmässä ja osuvammassa kohdassa. b (oletus 0,75) hallitsee dokumentin pituuden normalisointia: se päättää, kuinka ankarasti BM25 rankaisee pitkiä dokumentteja siitä, että niissä on luonnostaan enemmän termiosumia.

b:n väärin asettaminen on todellinen ja yleinen säätövirhe. Lyhyet tekniset dokumentit (virhelokit, tuotenimet) kaipaavat matalampaa b:tä, koska pituusvaihtelu on pientä; pitkät sisällöt (dokumentaatiosivut, artikkelit) haluavat yleensä oletusta lähempänä olevan b:n. BM25:n perusheikkous on sanastoristiriita: jos käyttäjä kysyy "miten saan rahani takaisin" ja dokumentissa lukee vain "palautuskäytäntö", BM25 ei löydä yhtään yhteistä tokenia eikä palauta mitään hyödyllistä.

Tiheän vektorihaun mekaniikka (ja missä se hajoaa)

Vektorihaku kuvaa tekstin kiinteäulotteisiksi upotuksiksi mallin avulla ja etsii sitten lähellä olevia vektoreita kosinisen samankaltaisuuden tai pistetulon perusteella, tyypillisesti likimääräisen lähimmän naapurin indeksin kiihdyttämänä. HNSW on hallitseva algoritmi Weaviatessa, Qdrantissa ja Milvuksessa; se vaihtaa pienen osan kattavuudesta merkittäviin nopeushyötyihin suuressa mittakaavassa.

Tämä korjaa BM25:n sanastoristiriitaongelman: "saan rahani takaisin" ja "palautuskäytäntö" päätyvät lähelle toisiaan upotusavaruudessa, vaikka yhteisiä tokeneita ei olisi yhtään, koska malli tallentaa merkityksen eikä pintamuotoa. Oikean mallin valinnalla on tässä paljon väliä. Katso oppaamme oikean upotusmallin valinnasta ja erittelymme siitä, miten vertailimme Voyage-, OpenAI- ja Cohere-upotuksia, jos punnitset vaihtoehtoja.

Mutta tiheällä haulla on oma sokea pisteensä, ja se on BM25:n peilikuva. Kun rakennamme asiakkaille RAG-järjestelmiä, yleisin kohtaamamme tarkkojen osumien epäonnistuminen ei ole eksoottinen. Kyse on tukihenkilöstä, joka etsii tiettyä tilausnumeroa tai SKU-tunnusta, ja vektori-indeksi palauttaa itsevarmasti jotain semanttisesti samankaltaista mutta väärää. Yleiskäyttöisellä upotusmallilla ei ole syytä sijoittaa "SKU-4471:tä" tai "ERR_CONN_RST:tä" lähelle itseään vektoriavaruudessa suhteessa läheiseen mutta väärään tokeniin, koska tuollaiset merkkijonot esiintyvät harvoin erillisinä, itsenäisinä käsitteinä harjoitusdatassa. BigData Boutique dokumentoi juuri tämän virhekuvion omissa SKU- ja virhekoodiesimerkeissään. Kyse on vakiintuneesta, itsenäisesti vahvistetusta ilmiöstä RAG-järjestelmissä, ei yksittäisestä erikoisuudesta.

Miten BM25 ja vektorihaku yhdistetään: RRF vs alfa-painotettu fuusio

On olemassa kaksi todellista tapaa yhdistää BM25:n ja vektorin tulokset, ja lähes kukaan hybridihausta kirjoittava ei vertaa niitä selkeästi. Reciprocal Rank Fusion (RRF), Cormackin, Clarken ja Buettcherin vuoden 2009 SIGIR-paperista, operoi sijoituksilla: score = sum(1 / (k + rank_i)) kunkin tuloslistan yli, k:n ollessa tyypillisesti 60. Koska se välittää vain sijainnista eikä raaoista pisteistä, RRF käsittelee BM25:n rajaamattomien pisteiden ja kosinisen samankaltaisuuden 0–1-välin mittakaavaerot valittamatta, eikä se vaadi korpuskohtaista säätöä.

Alfa-painotettu (konveksi) fuusio toimii eri tavalla: final = alpha * dense_score + (1 - alpha) * sparse_score, ja se operoi normalisoiduilla pisteillä sijoitusten sijaan. Se voi heijastaa luottamuksen suuruutta paremmin (vektoriosuma 0,95:n samankaltaisuudella näyttää aidosti vahvemmalta kuin 0,61:n osuma), mutta se vaatii alpha:n säätöä korpuskohtaisesti, ja se säätö hajoaa hiljaa, kun pistejakaumasi muuttuu (uusi upotusmalli, uudelleenindeksoitu korpus, erilainen kyselysekoitus).

Käytännössä valinta palautuu siihen, kuinka paljon luotat pisteidesi kalibrointiin. Kun ajat perus-BM25:tä yhtä vakaata upotusmallia vastaan, alfa-painotus voi puristaa hieman paremman järjestyksen, koska se käyttää todellista piste-eroa eikä vain sijaintia. Mutta se kalibrointi ajautuu harhaan useammin kuin ihmiset odottavat. Vaihda upotusmallin versio, palastele dokumentit uudelleen tai lisää reranking-vaihe ylävirtaan, ja tiheiden pisteiden jakauma muuttuu. Kukaan ei saa hälytystä, kun alpha=0,6 lakkaa olemasta oikea arvo; järjestys vain hiljalleen huononee hieman, ja se on helppo missata, ellet aja hakuarviointeja säännöllisesti. RRF kiertää tämän kokonaan, koska se ei koskaan katso raakoja pisteitä, vain sijoitusta, joten uudelleenindeksointi tai mallinvaihto ei voi rikkoa sitä hiljaa samalla tavalla kuin alfa-painotuksen.

RRF ei vaadi korpuskohtaista säätöä; alfa-painotus tarvitsee jatkuvaa vahtimista datan muuttuessa.

Moottorit ovat eri mieltä oletuksista. Weaviate tarjoaa sekä RRF:n että alpha-parametrin, jonka asetat itse. Elasticsearch toimittaa natiivin RRF:n retriever-API:nsa kautta (tarkista tarkka versiorajaus omassa asennuksessasi; tämä tuli 8.x-linjaan). Qdrant tukee RRF:ää natiivisti Query API:nsa kautta. Pineconen hybriditoiminto nojaa tyypillisesti alfa-painotettuun konveksiin yhdistelmään sen sijaan, että se tarjoaisi RRF:n suoraan. Jos et ole varma, kumman valitset, aloita RRF:stä. Se on vähemmän huoltoa vaativa oletus.

RRF alusta asti: toimittajariippumaton Python-esimerkki

Jokainen kilpailevissa oppaissa löytämämme RRF-koodiesimerkki on lukittu yhden toimittajan SDK:han: Weaviaten asiakas, Qdrantin asiakas, Pineconen asiakas. Tässä on framework-vapaa versio, jonka voit pudottaa mihin tahansa pinoon, k=60 standardioletuksena:

def reciprocal_rank_fusion(result_lists, k=60):
    """
    result_lists: list of ranked lists, each a list of document IDs
                  ordered from most to least relevant.
    k: RRF constant (60 is the standard default from Cormack et al., 2009).
    Returns: list of (doc_id, fused_score) sorted descending by score.
    """
    scores = {}
    for result_list in result_lists:
        for rank, doc_id in enumerate(result_list, start=1):
            scores[doc_id] = scores.get(doc_id, 0.0) + 1.0 / (k + rank)
    return sorted(scores.items(), key=lambda item: item[1], reverse=True)

# Example usage:
bm25_hits = ["doc_9", "doc_2", "doc_14", "doc_1"]
vector_hits = ["doc_2", "doc_1", "doc_9", "doc_30"]

fused = reciprocal_rank_fusion([bm25_hits, vector_hits])
for doc_id, score in fused:
    print(f"{doc_id}: {score:.4f}")

Siinä on koko algoritmi. Ei SDK:ta, ei toimittajalukkoa, ja se toimii riippumatta siitä, tulivatko kaksi järjestettyä listaasi Elasticsearchista ja Faiss-indeksistä vai Postgresin ts_rank:stä ja pgvectorista. Jos ajat malleja itse API:n kutsumisen sijaan, katso upotusmallien paikallinen ajaminen Ollamalla.

Postgres + pgvector: hybridihakua ilman erillistä vektoritietokantaa

Et tarvitse erillistä vektoritietokantaa hybridinhaun ajamiseen. Kehittäjä Pedro Alonson pg_textsearch/pgvector-benchmarkin mukaan (Postgres 17, pg_textsearch 1.3.0, pgvector 0.8.2, nomic-embed-text-upotukset, BEIR SciFact -datasetti) yksi Postgres-instanssi, joka ajaa natiivia ts_rank:ä, sai vain 0,07 NDCG@10:n, kauas BM25:n 0,69:stä, pgvectorin 0,66:sta ja hybridin 0,70:stä, kaikki yhdessä instanssissa, hybridin RRF:n laskeutuessa noin 11,5 ms mediaaniin.

Tuo 0,07 luku on paljastava: Postgresin sisäänrakennettu ts_rank on kattavuustiheyspohjainen järjestäjä, ei todellinen BM25. Jos haluat oikeaa BM25-pisteytystä Postgresissa, tarvitset laajennoksen. pg_textsearch, VectorChord ja ParadeDB lisäävät kaikki kunnollisen BM25-tyylisen järjestelyn, jota natiivi ts_rank ei tarjoa. Yhdistä jokin niistä pgvectoriin tiheää samankaltaisuutta varten, fuusioi kaksi järjestettyä listaa yllä olevalla RRF-funktiolla, ja sinulla on hybridihaku yhdessä Postgres-instanssissa ilman erillistä infrastruktuuria.

Tässä on suunnilleen miltä tuo yhdistelmä näyttää yhdessä kyselyssä, kun BM25-kykyisen laajennoksen leksikaalinen järjestys yhdistetään pgvectorin vektorietäisyyteen:

WITH lexical AS (
  SELECT id, ts_rank_cd(body_tsv, query) AS rank
  FROM documents, plainto_tsquery('english', 'refund policy') query
  WHERE body_tsv @@ query
  ORDER BY rank DESC LIMIT 50
),
semantic AS (
  SELECT id, embedding <=> '[0.012, -0.045, ...]' AS distance
  FROM documents
  ORDER BY distance LIMIT 50
)
SELECT * FROM lexical
FULL OUTER JOIN semantic USING (id);

Syötä molemmat tulosjoukot yllä olevaan RRF-funktioon, ja sinulla on hybridihaku yhdessä Postgres-instanssissa. Rehellinen raja: tämä toimii hyvin muutaman miljoonan rivin kokoluokkaan asti, mutta Postgresia ei ole rakennettu erilliseksi hakukoneeksi. Vastaat itse indeksien säädöstä, pelkkä ts_rank_cd ei vieläkään ole oikeaa BM25:ttä ilman laajennosta, etkä saa sisäänrakennettua rerankingia tai monivektoritukea, jotka Weaviate tai Milvus toimittavat natiivisti. Jos korpuksesi on pieni tai keskikokoinen ja ajat jo Postgresia, tämä säästää sinulta kokonaan toisen infrastruktuuripalan. Kymmenien miljoonien dokumenttien jälkeen, tai jos tarvitset edistynyttä rerankingia, erillinen moottori ansaitsee paikkansa.

Jos punnitset Qdrantia, Chromaa tai pgvectoria pinoosi laajemmin, se on erillinen päätös itse fuusiomenetelmästä. Katso Qdrantin, Chroman ja pgvectorin vertailumme kompromisseista.

Mitkä vektoritietokannat tukevat natiivia hybridihakua?

Useimmat modernit vektoritietokannat toimittavat nykyään hybridihakua suoraan laatikosta, mutta niiden oletuksena käyttämä fuusiomenetelmä eroaa merkittävästi.

Tarkista tarkat versiorajaukset ennen kuin sitoudut. Hybriditoiminnot ovat rantautuneet nopeasti näihin moottoreihin vuoden 2026 aikana, ja API-muodot muuttuvat julkaisusta toiseen. Laajempaa ostopäätöstä varten fuusiomekaniikan ulkopuolella katso täysi parhaiden vektoritietokantojen katsauksemme.

Onko hybridihaku monimutkaisuuden arvoinen?

Hybridihaku on arkkitehtonisesti oikein, kun korpuksessasi on sekä tarkkojen osumien kuvioita (SKU-tunnukset, tunnukset, harvinaiset termit) että käsitteellisiä, parafrasoituja kyselyjä. Jos korpuksessasi ei ole kumpaakaan (puhdas kerronnallinen sisältö, ei tunnisteita, joilla kukaan hakee kirjaimellisella merkkijonolla), saatat lisätä fuusion monimutkaisuutta saadaksesi parannuksen, jota tuskin huomaat.

Mieti, miltä "vain kerronnallinen" oikeasti näyttää: yrityksen blogiarkisto, sisäinen tekninen wiki täynnä proosaraskaita runbookeja, dokumentaatiosivusto, jolta kukaan ei hae tuotetunnuksella tai tikettinumerolla. Noissa korpuksissa pelkkä vektorihaku antaa yleensä suurimman osan arvosta, ja fuusiovaihe lisää vain toisen hakukierroksen ja parametrin, josta joku on nyt vastuussa, tuottaen parannuksen, joka pyöristyy kohinaksi. Vertaa sitä tukitikettijärjestelmään tai verkkokaupan kataloogiin, joissa SKU-tunnukset, tilausnumerot ja mallikoodit esiintyvät oikeissa käyttäjäkyselyissä jatkuvasti. Se on todellinen testi: ota kymmenen oikeaa kyselyä omista lokeistasi ja laske, kuinka moni sisältää tarkan tunnisteen, jota parafrasiopohjainen upotusmalli ei koskaan sijoita oikein. Nolla, jätä hybridihaku väliin. Yksi tai kaksi enemmän, rakenna se.

Hybridihaku ei ole yleispätevä päivitys; jos korpuksessasi ei ole SKU-tunnuksia, tunnuksia tai harvinaisten termien hakuja, saatat lisätä fuusion monimutkaisuutta saadaksesi parannuksen, jota et koskaan huomaa.

Kustannus on todellinen mutta rajallinen: toinen hakukierros, fuusiovaihe ja painotusparametri, josta joku on nyt vastuussa. Emme tarkoituksella lainaa viivelukua tässä, koska liikkuvat luvut tulevat nimeämättömistä asennuksista nimeämättömällä laitteistolla, ja omasi tulee eroamaan. Mittaa se omalla korpuksellasi ennen kuin päätät. Kaksi Hacker News -ketjua tavoittaa todellisen käytännön toimijoiden jännitteen: "Hybrid Search Is Just the Beginning: Optimizing the R in RAG" ja "Better RAG Results with Reciprocal Rank Fusion and Hybrid Search". Molemmat ketjut vastustavat hybridin omaksumista cargo-cult-parhaana käytäntönä tarkistamatta ensin, onko korpuksessasi edes niitä kyselykuvioita, joita se on tarkoitettu ratkaisemaan. Ennen kuin rakennat sen, kannattaa ymmärtää, miten haun laatua oikeasti mitataan: NDCG- ja recall@k-luvut merkitsevät jotain vain omaa korpuksesi vasten, ei benchmark-datasettiä.

Meidän näkemyksemme: oletuksena hybridihaku jokaisessa RAG-järjestelmässä, joka palvelee käyttäjille suunnattua tukea, verkkokauppaa tai tikettikyselyjä. Nuo kuormat sekoittavat lähes aina tunnisteita ja luonnollista kieltä. Jätä se väliin vain kerronnallisissa korpuksissa (pitkät dokumentit, kerronnalliset wikit), kunnes olet mitannut todellisen aukon, jonka yhden menetelmän haku jättää auki.

Tietoja kirjoittajasta

Mert Batur on Techsy.io:n perustajajäsen, ja hänen tiiminsä toimittaa tekoälyagentteja, automaatiojärjestelmiä ja ääni-/SDR-pipelineja B2B-asiakkaille. Hän kirjoittaa LLM-työkalupinosta, jota Techsyn tiimi oikeasti käyttää tuotannossa. Yhdistä LinkedInissä.

Usein kysytyt kysymykset

Mikä on hybridihaku RAG:ssa?

Hybridihaku ajaa BM25- (avainsana) ja vektorihaun (semanttinen) erillisinä kierroksina saman kyselyn yli ja yhdistää sitten kaksi järjestettyä listaa fuusioalgoritmilla, yleensä Reciprocal Rank Fusionilla. Se tavoittaa sekä tarkat osumakyselyt että parafrasoidut käsitteelliset kyselyt, joita kumpikaan menetelmä ei yksinään hallitse.

Onko BM25 sama asia kuin vektorihaku?

Ei. BM25 on harvaa leksikaalista hakua, joka pisteyttää tarkan termipeiton ja harvinaisuuden. Vektorihaku on tiheää semanttista hakua, joka käyttää upotuksia ja samankaltaisuuslaskentaa. Ne ovat kaksi eri hakumenetelmää, joilla on vastakkaiset vahvuudet; hybridihaku yhdistää eikä korvaa kumpaakaan.

Miten BM25 ja vektorihaku yhdistetään?

Aja molemmat hakumenetelmät itsenäisesti samalla kyselyllä ja yhdistä sitten kaksi järjestettyä tuloslistaa, useimmiten Reciprocal Rank Fusionilla, joka laskee yhteen 1 / (k + rank) kunkin listan yli. Alfa-painotettu pisteyhdistelmä on vaihtoehto, mutta se vaatii korpuskohtaista säätöä, jota RRF ei vaadi.

Mikä on Reciprocal Rank Fusion (RRF)?

RRF on fuusioalgoritmi Cormackin, Clarken ja Buettcherin vuoden 2009 SIGIR-paperista, joka yhdistää useita järjestettyjä listoja laskemalla yhteen 1 / (k + rank) kullekin dokumentille, k:n ollessa tyypillisesti 60. Se toimii sijoituksella eikä raaoilla pisteillä, joten se pysyy vakaana hakumenetelmien välisissä mittakaavaeroissa.

Mitä eroa on RRF:llä ja alfa-painotetulla fuusiolla?

RRF yhdistää sijoituksia eikä vaadi korpuskohtaista säätöä. Alfa-painotettu fuusio yhdistää normalisoituja pisteitä käyttäen säädettävää alpha-parametria, mikä voi heijastaa luottamuksen suuruutta paremmin, mutta vaatii jatkuvaa uudelleensäätöä aina, kun pistejakaumat muuttuvat, kuten uudelleenindeksoinnin tai mallinvaihdon jälkeen.

Milloin minun kannattaa käyttää hybridihakua pelkän vektorihaun sijaan?

Käytä hybridihakua, kun kyselysi sekoittavat tarkkoja tunnisteita (SKU-tunnukset, tilausnumerot, virhekoodit) ja luonnollisen kielen käsitteellisiä kysymyksiä; tuki, verkkokauppa ja tikettijärjestelmät tekevät niin tyypillisesti. Jätä se väliin vain kerronnallisessa sisällössä ilman tunnisteita, jossa lisätty fuusion monimutkaisuus ei todennäköisesti näy mitattavana parannuksena.

Miksi vektorihaku missaa tarkat osumat kuten SKU-tunnukset tai virhekoodit?

Upotusmallit oppivat yleisistä kielikuvioista, ja "SKU-4471:n" tai "ERR_CONN_RST:n" kaltaiset merkkijonot esiintyvät harvoin erillisinä, itsenäisinä käsitteinä harjoitusdatassa. Mallilla ei ole vahvaa syytä sijoittaa juuri tuota merkkijonoa lähemmäs itseään kuin semanttisesti läheistä mutta väärää tokenia.

Mitkä vektoritietokannat tukevat hybridihakua natiivisti?

Weaviate, Qdrant, Elasticsearch, OpenSearch, Vespa ja Milvus toimittavat kaikki natiivin hybridinhaun vuodesta 2026 alkaen, vaikka niiden oletusfuusiomenetelmät eroavat (RRF vs alfa-painotettu vs normalisointi). Postgres pgvectorin kanssa pystyy myös ajamaan hybridihakua, mutta se tarvitsee BM25-laajennoksen, koska natiivi ts_rank ei ole oikeaa BM25:ttä.

Onko hybridihaku lisätyn monimutkaisuuden arvoinen?

Korpuksille, jotka sekoittavat tarkkoja osumia ja käsitteellisiä kyselyjä, kyllä. Pelkkä RRF voittaa jo kumman tahansa yksittäisen menetelmän WANDS-benchmarkissa (0,7068 vs BM25:n 0,6983), ja säädetty muunnelma yltää 7,4 % parannukseen (0,7497). Vain kerronnallisille korpuksille ilman tunnisteita toinen hakukierros ja sen tarvitsema fuusion säätö voivat painaa enemmän kuin parannus, jota et huomaa. Mittaa ennen kuin sitoudut.

Voiko Postgres/pgvector tehdä hybridihakua ilman erillistä vektoritietokantaa?

Kyllä. Yhdistä pgvector tiheää samankaltaisuutta varten todelliseen BM25-laajennokseen kuten pg_textsearch, VectorChord tai ParadeDB (pelkkä natiivi ts_rank sai vain 0,07 NDCG@10:n Pedro Alonson pg_textsearch/pgvector-benchmarkissa, hybridiä vastaan 0,70), ja fuusioi sitten kaksi järjestettyä listaa RRF:llä, kaikki yhden Postgres-instanssin sisällä.

Molemmat hakumenetelmät jättävät todellisia aukkoja yksinään ajettuina: BM25 missaa parafrasoinnin, vektorihaku missaa tarkat tunnisteet, ja niiden yhdistäminen RRF:llä on vähemmän huoltoa vaativa tapa sulkea molemmat. Jos punnitset, rakennatko tämän itse vai otatko mukaan tiimin, joka on toimittanut RAG-hakua aiemmin, täysi oppaamme RAG-sovelluksen rakentamiseen kattaa seuraavan askeleen, tai ota yhteyttä, jos haluat Techsyn rakentavan sen kanssasi.