Prestandaguide för vektorsökning

Mosaic AI Vector Search är byggt för snabb, skalbar hämtning. Prestanda för vektorsökning beror på många faktorer, inklusive SKU-val, indexstorlek, frågetyp, vektordimensionitet, autentiseringsmetoder och hur ditt program hanterar trafiktoppar. De flesta arbetsbelastningar fungerar bra direkt, men i situationer där du behöver skala eller optimera svarstiden innehåller den här guiden praktiska tips och vanliga mönster som hjälper dig att konfigurera systemet för optimala prestanda för vektorsökning.

Faktorer som påverkar prestanda

Prestanda är inte ett enda tal – det är ett intervall som beror på arbetsbelastningsegenskaper, konfigurationsalternativ och klientimplementering. Den här guiden är utformad för att hjälpa dig att bygga en tydlig mental modell för hur prestanda fungerar så att du kan använda Mosaic AI Vector Search mest effektivt.

Följande är de viktigaste faktorerna som påverkar hur systemet beter sig:

• SKU-val: standard eller lagringsoptimerad.
• Indexstorlek: antal lagrade vektorer.
• Inbäddningsstorlek: vanligtvis 384–1536.
• Frågetyp: ungefärlig närmaste granne (ANN) eller hybrid.
• Antal begärda resultat: högre värden ökar hämtningstiden.
• Inbäddningstyp: hanterad eller självhanterad.
• Frågebelastning: hur mycket trafik som når slutpunkten över tid.
• Autentiseringsmetod: hur din app ansluter till Databricks.

Resten av den här artikeln innehåller praktiska tips för att justera var och en av dessa variabler och förklarar hur de påverkar söksvarstid och frågegenomflöde i verkliga distributioner.

Välj rätt SKU

Mosaic AI Vector Search erbjuder två SKU:er, var och en utformad för att balansera svarstid, skalbarhet och kostnadseffektivitet beroende på arbetsbelastningen. Att välja rätt SKU för ditt program är den första hävstången för att justera prestanda.

I regel:

• Välj standardslutpunkter när svarstiden är kritisk och ditt index ligger långt under 320 M-vektorer.
• Välj lagringsoptimerade slutpunkter när du arbetar med 10M+ vektorer, kan tolerera lite extra svarstid och behöver bättre kostnadseffektivitet per vektor (upp till 7 gånger billigare).

I följande tabell visas några förväntade prestandariktlinjer.

Förstå indexstorlek

Prestanda är högst när ditt index passar in i en enda vektorsökningsenhet, med extra utrymme för att hantera ytterligare frågebelastning. När arbetsbelastningar skalas bortom en enda vektorsökningsenhet (dvs. 2M+ vektorer för standard eller 64M+ för lagringsoptimerad) ökar svarstiden och QPS avsmalnande. Så småningom QPS-platåer vid cirka 30 QPS (ANN).

Prestanda beror på många faktorer som är unika för varje arbetsbelastning, till exempel frågemönster, filter, vektordimensionitet och samtidighet. Följande siffror är referenspunkter.

Minimera inbäddningsstorleken

Vektordimensionalitet refererar till antalet funktioner i varje vektor. Typiska värden är 384, 768, 1024 eller 1536. Högre dimensioner ger mer uttrycksfulla representationer som kan förbättra kvaliteten, men till en beräkningskostnad. Lägre vektorer kräver mindre beräkning under hämtningen, vilket leder till snabbare frågetider och högre QPS. Omvänt ökar högre dimensionella vektorer beräkningsbelastningen och minskar dataflödet.

Som en allmän regel väljer du den minsta dimensionalitet som bevarar hämtningskvaliteten för ditt användningsfall.

Om du till exempel minskar dimensionaliteten med en faktor på två (t.ex. från 768 till 384) förbättras vanligtvis QPS med cirka 1,5 gånger och svarstiden minskar med cirka 20%, beroende på indexstorleken och frågemönstret. Dessa vinster förening ytterligare vid mycket låga dimensionaliteter. Om du till exempel använder 64-dimensionella vektorer kan det ge betydligt högre QPS och betydligt lägre svarstid jämfört med de prestandamått på 768 dimensioner som visas i tabellen. Det gör 384 dimensioner och lägre särskilt attraktiva för användningsfall med högt dataflöde, svarstidskänsliga användningsfall, så länge hämtningskvaliteten förblir acceptabel.

Använd ANN för effektivitet och använd hybrid när det behövs

Använd ANN-frågor när det är möjligt. De är de mest beräkningseffektiva och har stöd för högsta QPS.

Använd hybridsökning vid behov. Hybridsökning förbättrar återkallandet i vissa program, särskilt där domänspecifika nyckelord är viktiga. Hybridsökning använder vanligtvis ungefär dubbelt så många resurser som ANN och kan avsevärt minska dataflödet.

Använd 10–100 resultat

Varje fråga innehåller en num_results parameter, vilket är antalet sökresultat som ska returneras. Det här värdet påverkar direkt prestanda. För att hämta fler resultat krävs en djupare genomsökning av indexet, vilket ökar svarstiden och minskar QPS. Effekten blir mer betydande vid högre värden. Om du till exempel ökar num_results med 10 gånger kan du dubbla frågefördröjningen och minska QPS-kapaciteten med 3x, beroende på indexstorlek och konfiguration.

Som bästa praxis bör du hålla num_results dig inom intervallet 10–100 om inte programmet specifikt kräver mer. Prova olika num_results värden med realistiska frågor för att förstå effekten på din arbetsbelastning.

Undvik skalning till noll för produktion

Vector Search stöder två typer av inbäddningar med olika prestandaavvägningar.

Hanterade inbäddningar är de mest praktiska. Med hanterade inbäddningar genererar Databricks inbäddningar för både dina rader och frågor automatiskt. Vid frågetillfället skickas frågetexten till en modell som betjänar slutpunkten för att generera inbäddningen, vilket lägger till svarstid. Om inbäddningsmodellen är extern medför den även ytterligare nätverkskostnader.

Med självhanterade inbäddningar kan du beräkna inbäddningar i förväg och skicka vektorerna direkt vid frågetillfället. Detta undviker körningsgenerering och möjliggör snabbast hämtning. Alla prestandanummer som ingår i den här artikeln baseras på självhanterade inbäddningar.

För användningsfall i realtidsproduktion bör du undvika modellslutpunkter som skalas till noll. Kallstarter kan fördröja svar med flera minuter eller till och med orsaka fel om slutpunkten är inaktiv när en fråga kommer.

Planera för frågetoppar

Det här avsnittet beskriver vad du kan förvänta dig när trafiken ökar och hur du håller dig under de kritiska gränser som utlöser svarstidstoppar eller 429-fel (för många begäranden).

Svarstiden förblir låg när belastningen är måttlig och ökar gradvis när du närmar dig den maximala QPS-kapaciteten. När systemet når 100% QPS-kapacitet börjar det returnera 429 fel. Om du inte har konfigurerat en korrekt backoff kan appen sluta svara.

429 fel fungerar som en säkerhetsmekanism för att skydda systemet. De instruerar klienten att säkerhetskopiera och försöka igen senare så att slutpunkten förblir felfri och dynamisk, även under plötsliga trafiktoppar.

Vi rekommenderar att du använder Python SDK för vektorsökning, som innehåller inbyggd backoff- och återförsökshantering.

Om du använder REST-API:et implementerar du exponentiell backoff med jitter. Se Azure-antimönster.

Använda tjänstens huvudnamn med OAuth-token

Använd effektiva autentiseringsmetoder för bästa prestanda. Databricks rekommenderar att du använder ett huvudnamn för tjänsten med OAuth-token i alla produktionsmiljöer. OAuth-åtkomsttoken ger större säkerhet och utnyttjar även nätverksoptimerad infrastruktur så att systemet kan fungera med full kapacitet.

Undvik att använda personliga åtkomsttoken (PAT), eftersom de medför nätverkskostnader, lägger till hundratals millisekunder svarstid och avsevärt minskar den QPS som slutpunkten kan upprätthålla.

Använda Python SDK

Använd den senaste versionen av Python SDK för att dra nytta av inbyggda prestanda- och tillförlitlighetsoptimeringar.

Återanvänd indexobjektet mellan frågor. Undvik att anropa client.get_index(...).similarity_search(...) i varje begäran, eftersom det här mönstret ger onödig svarstid.

Initiera i stället indexet en gång och återanvänd det:

# Initialize once
index = client.get_index(...)

# Then use it for every query
index.similarity_search(...)

Detta är viktigt när du använder vektorsökningsindexet i MLFlow-miljöer, där du kan skapa indexobjektet vid slutpunktsinitieringen och sedan återanvända det för varje fråga.

Den här vägledningen är särskilt användbar i program som är känsliga för svarstid i realtid. I RAG-installationer med flera index eller auktoriseringsflöden för användarens räkning , där indexval eller autentiseringsuppgifter endast är tillgängliga vid frågetillfället, är det inte möjligt att initiera indexobjektet en gång. Den här optimeringen är inte nödvändig i dessa scenarier.

Parallellisera mellan slutpunkter

Databricks rekommenderar att du utforskar följande strategier för att öka det totala antalet QPS i systemet:

• Dela upp index mellan slutpunkter. Om du har flera index som var och en tar emot en betydande del av trafiken, är du värd för dem på separata slutpunkter för att nå högre total bandbredd.
• Replikera indexet mellan slutpunkter. Om de flesta trafik träffar ett enda index duplicerar du det över flera slutpunkter. Dela upp trafiken jämnt på klientnivå för linjära QPS-vinster.