VoyageAI by MongoDB: rerank-2.5-lite

rerank-2.5-lite är den lätta medlemmen i Voyage AI:s 2.5-utgåva av omrangordnare. Tillverkaren beskriver den som en generalistmodell som balanserar latens och relevanskvalitet, med instruktionsföljning på naturligt språk och flerspråkigt stöd. Indata är en fråga och kandidattexter och utdata är en förfinad ordning av kandidaterna med relevanspoäng.

Ett lätt relevansbeslut i andra steget

Lite-modellen bearbetar varje fråga–dokument-par gemensamt som en korsenkodare. Den kan följa ett första embedding- eller lexikalt söksteg och förfina textavsnitten som det steget valde. Detta skiljer sig från att förbereda ett återanvändbart embeddingindex: omrangordnaren granskar den inskickade frågan och dokumenttexten tillsammans för det aktuella relevansbeslutet.

För en interaktiv hjälpsökning skickar du in kandidatförklaringarna som kan besvara användarens fråga. Behåll tillräckligt av varje textavsnitt för att förmedla beteendet och dess villkor och bevara kopplingen mellan indataindex och källobjekt. En avgränsad kandidatuppsättning hjälper till att göra omrangordningsuppgiften tydlig samtidigt som de hämtade beläggen förblir användbara för visning eller ett senare svar.

Instruktioner uttrycker vad användaren vill prioritera

Liksom rerank-2.5 accepterar Lite instruktioner på naturligt språk före eller efter frågan. Tillverkarens exempel använder dem för att betona dokumentdelar, välja en önskad källtyp eller ge kontext åt ett tvetydigt ord. En applikation kan tillhandahålla ett stående relevansönskemål eller den aktuella frågan kan innehålla ett mer specifikt sådant.

En illustrativ supportfråga kan fråga vilket textavsnitt som förklarar ett fel, med en instruktion att prioritera felsökningssteg framför allmänna produktbeskrivningar. En dokumentsökning kan efterfråga den ursprungliga policyformuleringen snarare än en diskussion om policyn. Beskriv det avsedda underlaget och håll instruktionen kort. Instruktioner påverkar relevanspoängen; förbered eventuella strikta versions-, datum- eller behörighetsbegränsningar vid kandidaturvalet i stället för att behandla ett relevansönskemål som ett garanterat filter.

Läs rangordningen och returnera källavsnittet

Utdata sorteras efter fallande relevans. Varje resultat innehåller det ursprungliga dokumentindexet och en flyttalspoäng; den valfria inställningen return-documents returnerar även motsvarande indatatext. Alternativet top-k avgör hur många ledande resultat som returneras, medan utelämnat alternativ ger rangordningen för alla inskickade kandidater.

Använd indexen för att återfinna källavsnittet och dess identifierare. En omrangordnad kandidat kan bli ett sökresultat eller belägg för nästa RAG-steg, men utdata är en ordning av tillhandahållen text snarare än ett omskrivet svar. Bedöm om de ledande avsnitten uppfyller både frågan och relevansinstruktionen, även för de språk och dokumenttyper som faktiskt finns i samlingen.

Gränser och en praktisk kandidatbudget

2.5 Lite-utgåvan har ett dokumenterat frågemaximum på 8 000 token och en gräns på 32 000 token för frågan plus varje enskilt dokument. Den skiljer sig från den tidigare rerank-2-lite-modellen och dess mindre kontext. Högst 1 000 dokument kan skickas in och totala indata begränsas till 600 000 token enligt formeln: frågetoken multiplicerat med antalet kandidater plus summan av kandidatdokumentens token.

För latenskänslig användning rekommenderar tillverkarens FAQ rerank-2.5-lite med högst 200 000 token totalt per förfrågan. Detta är praktisk vägledning under det angivna maximumet, inget annat fönster per dokument. En längre fråga eller instruktion räknas en gång för varje kandidatpar, så både kandidatantal och frågelängd påverkar totalen.

Trunkering är aktiverad som standard och kortar för långa fråga-/dokumentindata så att de ryms; att stänga av den returnerar ett fel för en för lång fråga eller ett för långt par. Förbered medvetet kompakta kandidater som innehåller svaret så att användbara belägg inte hamnar bortom en trunkeringsgräns. Att välja färre utdataresultat genom top-k tar inte bort de övriga inskickade kandidaterna från tokenberäkningen. Granska de returnerade källavsnitten och förfina indataberedningen utifrån de faktiska frågor som sökgränssnittet behöver besvara.