VoyageAI by MongoDB: rerank-3

Voyage rerank-3 är en omrangordnare för text utformad för att förbättra kvaliteten på hämtade underlag. Med en fråga och en lista med kandidatdokument granskar den varje par tillsammans och returnerar kandidaterna ordnade efter relevans. Embeddings och nyckelordssökning kan först begränsa en stor samling till ett hanterbart urval; rerank-3 tillämpar sedan en mer detaljerad relevansbedömning på urvalet. Utdata är poängsatta sökunderlag som en applikation kan visa eller skicka vidare till ett separat svarsgenereringssteg.

Kvalitetsinriktad Rerank 3 Tillverkaren positionerar rerank-3 som den noggrannhetsinriktade utgåvan och rerank-3-lite som utgåvan för latenskänslig sökning. Den tredje generationen uppdaterar basarkitekturen och träningsblandningen, med särskilda förbättringar för hämtning av långa dokument och källkod jämfört med motsvarande 2.5-föregångare. Tillverkaren utvärderar den över teknisk dokumentation, kod, flerspråkigt material och andra dokumentdomäner. Dessa resultat stöder dess hämtningsroll; välj utgåva utifrån de frågor och kandidatdokument som spelar roll i din egen samling.

Långa dokument med tillräcklig kontext En lång kandidat kan innehålla användbar kontext långt bortom det inledande stycket. Tillhandahåll ett sammanhängande avsnitt eller dokument med titel och relevant omgivande material så att modellen kan bedöma hur den faktiska frågan hänger ihop med innehållet. För en sökning om produktpolicy bevarar du rubriker och undantag kring det intressanta avsnittet. Om flera hämtade avsnitt kommer från samma källa behåller du deras dokument- och avsnittsidentifierare; applikationen kan då visa var det valda underlaget kom ifrån.

Kontextfönstret delas av frågan och varje kandidat. Tillverkarens aktuella guide anger 32 000 token för paret, inklusive en fråga på högst 8 000 token. En fråga på 3 000 token lämnar därför högst 29 000 token för varje dokument. Förbered indata så att det väsentliga innehållet ryms, särskilt när en lång inledning eller upprepad standardtext annars skulle förbruka fönstret. Det dokumenterade trunkeringsalternativet är aktiverat som standard och kan korta för stor fråge- eller dokumenttext före poängsättningen. Granska vad som behålls när avsnittets placering spelar roll.

Kod och teknisk hämtning För en kodassistents hämtningssteg kan kandidater innehålla funktionsimplementationer, API-dokumentation eller tekniska förklaringar som text. Ta med symboler, signaturer och kontext som behövs för att skilja liknande kandidater åt. En fråga som ”Hitta funktionen som normaliserar sökvägar och samtidigt bevarar en avslutande avgränsare” ger ett konkret beteende att matcha. Lägg till eventuella relevanta språk-, plattforms- eller versionskrav. Efter rangordning granskar du den valda koden och dess beroenden innan den används som kontext; en relevanspoäng bevisar inte att en implementation uppfyller varje angivet krav.

Instruktioner definierar relevans Modellen behåller den instruktionsföljande omrangordningsförmåga som infördes i Rerank 2.5. Lägg en kort instruktion före eller efter frågan när användarens avsikt behöver förtydligas. För sökning i forskningsdokument förklarar du om fokus ligger på titeln, en viss metod eller ett tillämpningsområde. För en intern katalog anger du om förfrågan gäller installation, felsökning eller kompatibilitet. Håll instruktionen i linje med frågan; extra önskemål som står i konflikt med huvudförfrågan kan ändra vad rangordningen försöker optimera.

Förbered kandidatdokument och budgetar Indata är en lista med textsträngar. Extrahera användbar text ur källdokumenten, bevara meningsfulla avsnittsgränser och behåll en ordnad postkarta tillsammans med listan. Tillverkaren tillåter upp till 1 000 dokument i en förfrågan. Den anger även ett sammanlagt indatatak på 600 000 token: frågetoken multiplicerat med antalet dokument plus summan av alla dokumenttoken. Detta skiljer sig från kontextgränsen per par. Att minska överflödig frågetext kan bevara både parkapacitet och total förfrågningsbudget.

Räkna token för den relevanta modellen i stället för att anta att ett ord- eller teckenantal är ett tokenantal. För stora kandidater väljer du sammanhängande textavsnitt eller delar materialet efter användbara rubriker samtidigt som information om överordnad källa behålls. Omrangordning är mest användbar när den första sökningen redan har hittat rimliga kandidater: den kan inte rangordna en saknad källa som aldrig kom med i listan.

Rangordnade resultat och efterföljande användning Resultatet innehåller relevanspoäng och index som hänvisar till de ursprungliga indatadokumenten, sorterade i fallande relevansordning. Alternativet top_k begränsar antalet rangordnade resultat som returneras; annars returneras alla indatakandidater. Tillverkarens REST-gränssnitt tillåter även att dokumenttexten inkluderas. Använd varje ursprungligt index för att återfinna titel, källidentifierare och eventuella metadata som applikationen behöver och presentera sedan de valda objekten eller lägg den relevanta texten i svarets beläggskontext.

Granska toppresultaten mot frågan och håll källidentiteten synlig. En hög relativ placering verifierar inte ett dokuments faktiska korrekthet och ett urval med bara dåliga kandidater får ändå ett förstaplacerat objekt. Skilj relevansurval från beslutet om huruvida det valda underlaget är tillräckligt för att besvara användaren.

Migrering mellan utgåvor Tillverkaren beskriver rerank-3 som en direkt ersättare till rerank-2.5, med samma API-semantik och poäng kalibrerade mot motsvarande föregångares fördelning. Kompatibiliteten stöder att behålla ett befintligt hämtningssteg och postkoppling. Jämför meningsfulla resultatordningar och eventuella poängtrösklar på den aktuella samlingen innan du förlitar dig på migreringen. Håll rerank-3 och rerank-3-lite som separata val: gemensamma gränser och instruktionsföljning gör inte deras kvalitets- och latensprioriteringar identiska.