Hur påverkar rerankerns djup latensen vid privat sökning?
Rerankningsdjupet ökar latensen för privat sökning ungefär i takt med antalet poängsatta kandidater, även om batchbearbetning, sekvenslängd, modellarkitektur och maskinvara gör kurvan icke-linjär.
En retriever i första steget kan returnera 20, 100 eller 500 kandidatfragment innan en korsenkoder eller lokal LLM omordnar dem. Djupare rerankning ger den relevanta textpassagen fler chanser att överleva en svag initial rangordning, men varje kandidat medför mer arbete för tokenisering och inferens. När återkallningen av relevanta dokument har planat ut förbrukar ytterligare djup främst beräkningsresurser och kan förlänga de långsammaste interaktiva frågorna.
Djup är antalet kandidater som går in i steg två
Rerankningsdjup skiljer sig från slutligt top-k. En pipeline kan poängsätta hundra kandidater och returnera fem, så latensen styrs av hundra fråge-dokument-jämförelser även om språkmodellen bara ser några få. Kandidattextens längd avgör hur många token som behandlas per jämförelse.
Elastic:s experiment med rerankningsdjup mäter sökkvaliteten när rerankningsdjupet ändras och ger modellspecifik vägledning. Resultaten visar att ett användbart djup beror på retrievern och rerankern i första steget, snarare än på ett enda fast tal. Denna effekt bör förbli mätbar under den avsedda arbetsbelastningen på hemmaservern.
Ett svagt första steg kan kräva större djup för att inkludera svaret, medan en stark hybridretriever kan presentera bra kandidater tidigare. Rerankningsdjup kan därför inte kompensera för kandidater som aldrig hämtades. Skillnaden är viktig när flera pipelinesteg delar på samma lagrings- och minnesbudget.
Inferenskostnaden skalar med kandidaterna och deras token
Korsenkodare behandlar frågan och varje kandidat gemensamt, så en fördubbling av djupet fördubblar ungefär antalet poängsatta par innan effekterna av batchbearbetning räknas in. Större batchar kan förbättra acceleratorutnyttjandet, men kräver också mer minne och kan fördröja det första färdiga resultatet tills en batch har slutförts.
En studie av parvis rerankning rapporterar stora latensminskningar genom att begränsa mängden rerankade resultat, välja mindre modeller, sänka precisionen och kontrollera mängden utdata. Den visar att djup är ett av flera multiplikativa val vid driftsättning. Den gränsen måste testas med representativa hushållsdata i stället för att antas.
Rerankning på CPU kan visa en nästan linjär kurva, medan GPU-kurvor kan innehålla effektiva platåer följda av minnes- eller köbildningsklippor. Även svanslatensen ökar när kandidatlängderna varierar, eftersom långa textfragment dominerar batcharbetet. Denna effekt bör förbli mätbar under den avsedda arbetsbelastningen på hemmaservern.
Kvalitetsvinster planar ut före kostnaden
Ökat djup hjälper bara så länge relevant information finns under den aktuella gränsen och rerankern kan identifiera den. När återkallningen i första steget har mättats tillför fler kandidater distraktioner och kostnader, och kan ibland minska rangordningens stabilitet för tvetydiga frågor.
En kontrollerad utvärdering från början till slut jämför retriever- och reranker-konfigurationer utifrån effektivitet, genereringskvalitet, kostnad och latens. Detta stödjer att djup väljs från en avvägningskurva från början till slut, i stället för att rangordningspoäng optimeras isolerat. Skillnaden är viktig när flera pipelinesteg delar på samma lagrings- och minnesbudget.
Felgränsen uppstår när djupet väljs utifrån genomsnittlig latens för varma, enhetliga frågor. Kalla modeller, långa textfragment, samtidiga användare och NAS-läsningar kan flytta p95 eller p99 långt över medianen, även när den genomsnittliga relevansen förbättras något.
Vanliga frågor om rerankningsdjup för kandidater
Är rerankning av 100 kandidater dubbelt så långsam som av 50?
Arbetet med poängsättning kan närma sig det dubbla, men den faktiska tiden kan bli både kortare och längre beroende på batchutnyttjande, tokenlängder, minnesbegränsningar och köbildning. Mät den driftsatta modellen i stället för att anta ett helt linjärt förhållande.
Kräver ett större slutligt top-k ett större rerankningsdjup?
Vanligtvis bör kandidatpoolen vara större än antalet slutliga resultat, men den nödvändiga multiplikatorn beror på återkallningen i första steget och resultatens mångfald. Att returnera fler textpassager motiverar inte automatiskt att hundratals svaga kandidater poängsätts. Den gränsen måste testas med representativa hushållsdata i stället för att antas.
Kan cachade rerankningspoäng minska latensen?
Cachning hjälper för upprepade fråge-kandidat-par eller stabila normaliserade frågor, men privat sökning innehåller ofta unika formuleringar och dokument som ändras. Cacheogiltigförklaring måste följa dokumentversioner och modelländringar för att undvika föråldrad rangordning. Denna effekt bör förbli mätbar under den avsedda arbetsbelastningen på hemmaservern.
Hitta det minsta djupet på kvalitetsplatån
Skapa en märkt uppsättning frågor med exakta termer, parafraser, tvetydiga namn och svåra negativa exempel. Testa rerankningsdjup som 10, 25, 50, 100 och 200 samtidigt som du mäter återkallningen i första steget, slutligt nDCG eller MRR, täckning av källhänvisningar, CPU- eller GPU-tid, minne samt p50-, p95- och p99-latens.
Jämför kurvan med beslutsfaktorerna i beslutsfaktorer för rerankern. Håll genereringen av kandidater i första steget, fragmentlängd, rerankermodell, slutligt top-k, samtidighet och cachestatus konstanta, så att djupet är den enda ändrade variabeln. Skillnaden är viktig när flera pipelinesteg delar på samma lagrings- och minnesbudget.
Välj det minsta djup vars kvalitet statistiskt sett inte kan skiljas från platån och vars svanslatens uppfyller det interaktiva målet. Dirigera bakgrundsresearch till en djupare profil endast när den extra återkallningen har uppmätt värde. Den gränsen måste testas med representativa hushållsdata i stället för att antas.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Kan en lokal LLM återuppta genereringen efter att dess process startats om?
En mekanismförst-förklaring av hur LLM-generering återupptas, avvägningarna kring delade resurser, tre vanliga frågor om frågeförgrening samt ett praktiskt verifieringsprotokoll.
Kan en hemserver köra embeddings och videotranskodning på samma integrerade GPU?
En mekanismfokuserad förklaring av delade iGPU-inbäddningar och omkodning, avvägningar kring delade resurser, tre vanliga frågor om frågefanout och en praktisk verifiering.
Hur påverkar åtkomsttokenets livslängd säkerheten och besvären i hushållet?
En mekanism-först-förklaring av åtkomsttokeners livslängd, avvägningarna kring delade resurser, tre vanliga frågor om frågefanout och ett praktiskt verifieringsprotokoll.
