Tät kontra gles informationshämtning: avvägningar

Moderna system för hämtning använder två distinkta signaler: tät hämtning kodar betydelse i kontinuerliga vektorrum, medan gles hämtning räknar exakta termförekomster. Dessa signaler kompletterar varandra och kan inte ersätta varandra. Att förstå deras individuella styrkor och svagheter är det första steget mot att bygga ett system som använder båda effektivt.

Tät hämtning mappar både frågan och varje dokument till en högdimensionell vektor med hjälp av en neural encoder. Likheten mäts med cosine distance eller skalärprodukt mellan vektorerna. Eftersom encodern har tränats på stora textkorpusar hamnar semantiskt relaterade fraser nära varandra i vektorrummet även om de inte delar några ord – detta är den täta hämtningens viktigaste fördel.

Täta modeller har svårt för sällsynta termer som förekom sparsamt under träningen av encodern. En fråga som innehåller ett specifikt produktmodellnummer som RTX-4090-Ti-OC, ett medicinskt läkemedelsnamn eller en intern identifierare för företagets eget bruk misslyckas ofta med att matcha rätt dokument, eftersom encodern saknar en inlärd representation för den tokenföljden. Vektorn hamnar helt enkelt på en ohjälpsam plats i embeddingrymden.

BM25 (Best Matching 25) är en probabilistisk rankningsfunktion som poängsätter dokument utifrån hur ofta frågans termer förekommer i dokumentet. Poängen normaliseras efter dokumentlängd och dämpas när termfrekvensen mättas. Resultatet är en gles poängvektor – de flesta dimensionerna är noll eftersom dokument bara innehåller en liten del av hela ordförrådet.

BM25 är särskilt bra på frågor som innehåller exakta tekniska termer, produktnamn, felkoder och numeriska identifierare som ska matchas precis. En fråga efter ORA-01017 (en Oracle-felkod) rankar dokument som innehåller exakt den strängen långt högre än dokument som bara handlar om databasautentisering i allmänhet. Detta är omöjligt för en tät modell som aldrig har sett just den koden.

BM25 kan inte hantera semantiska parafraser. Ett dokument om ”reparation av bilmotorer” får poängen noll för en fråga om ”underhåll av fordonsmotorer” om inga exakta ord överlappar. Detta problem med ordförrådsmismatch, som ibland kallas lexikalt gap, innebär att ren nyckelordssökning missar stora mängder relevant innehåll som helt enkelt använder andra ord för att uttrycka samma idé.

Benchmarktester på BEIR, MS MARCO och företagsdataset för frågor och svar visar konsekvent att hybrid hämtning presterar bättre än enbart tät eller gles hämtning, med 5–15 procents förbättring på NDCG@10. Förbättringen är störst i dataset med en blandning av faktasökningar (där BM25 hjälper) och parafrasfrågor (där täta embeddingar hjälper). Ingen enskild hämtningsmetod dominerar för alla frågetyper.

Ni kan förutsäga vilken hämtare som presterar bäst genom att analysera frågetypen. Tät hämtning vinner för konceptuella frågor, parafraser och breda ämnesfrågor. BM25 vinner för frågor som innehåller egennamn, versionsnummer, kodfragment, akronymer och sällsynta tekniska termer. Hybrid hämtning vinner alltid när frågetypen inte är känd i förväg – vilket nästan alltid är fallet i produktion.

Att kombinera täta och glesa resultat är inte trivialt eftersom deras poäng ligger på oförenliga skalor. Cosinuslikhet ger värden mellan -1 och 1, medan BM25 ger obegränsade positiva poäng som beror på korpusens storlek. Ni kan inte bara addera dem. Standardlösningen är att använda rankbaserad fusion i stället för poängbaserad fusion – att slå samman rankade listor i stället för råa poäng.

Använd enbart tät hämtning när er korpus tillhör ett smalt domänområde med konsekvent vokabulär och ni behöver semantisk generalisering över parafraser. Använd enbart BM25 när frågor huvudsakligen är uppslagsfrågor med exakta identifierare och datauppsättningen är tillräckligt liten för att brute force ska vara genomförbart. Använd hybrid hämtning i alla RAG-system i produktion där frågetyperna varierar – kostnaden är måttlig och förbättringen av återkallningen är betydande.

Tät hämtning kräver GPU-accelererad approximerad sökning efter närmaste grannar eller en vektordatabas, vilket ökar kostnaden för infrastrukturen. BM25 körs helt på CPU med ett inverterat index och är extremt snabbt. Hybrid hämtning kräver båda infrastrukturkomponenterna samt ett fusionssteg. Den ökade komplexiteten motiveras av den förbättrade återkallningen i de flesta produktionsanvändningsfall, men måste vägas mot er infrastrukturbudget.

I den här lektionen lärde ni er att tät hämtning fångar semantisk betydelse men misslyckas med sällsynta exakta termer, att gles BM25-hämtning hanterar exakta nyckelord men missar parafraser, och att hybrid hämtning konsekvent överträffar båda metoderna var för sig för varierande frågetyper. Deras poäng är oförenliga och måste slås samman med rankfusion i stället för genom att addera poäng. Nästa steg är att implementera BM25-baserad nyckelordssökning i Python.