Sådan vælger du vector store til Amazon Bedrock Knowledge Bases
Amazon Bedrock Knowledge Bases kan køres fuldt administreret eller kunde-administreret. I den kunde-styrede variant vælger du en konkret vektorlager-backend, og det valg er afgørende. AWS’ egen gennemgang viser, at det påvirker både performance og omkostninger i Retrieval Augmented Generation (RAG). Udgangspunktet her er de tre dokumenterede backends og deres praktiske konsekvenser.
Fokus er den kunde-styrede vej: Amazon OpenSearch Service, Amazon Aurora PostgreSQL med pgvector og Amazon S3 Vectors. AWS’ tekniske blog sammenligner dem for RAG-brug. Nedenfor oversættes forskellene til drift og arkitektur — det, der afgør brugeroplevelse, kvalitet og regning.
Hvad er en vector store i en RAG-arkitektur
RAG gør modellen aktuel ved at hente domænespecifik viden i realtid. Arbejdsgangen: dokumenter deles i bidder (chunking), embeds til vektorer (embeddings) og lagres i et vektorindeks. Forespørgslen konverteres til en embedding, og systemet henter de mest semantisk ens stykker — typisk top-n (fx fem) — som kontekst til modellen.
Vektorsøgning fanger semantisk lighed bedre end nøgleordretrieval. Det er kernen i AWS’ tekniske beskrivelser: et vektorrum afspejler betydning, ikke kun string-match. Vektorindeks er bygget til høj-dimensionelle søgninger og skal være hurtige, ellers forsvinder gevinsten. Derfor betyder backenden noget.
De tre backends kortlagt
OpenSearch Service: Hastighed først. AWS fremhæver højhastighedssøgning med data i hukommelsen, understøttelse af høj-dimensionelle embeddings samt managed clusters og serverless. OpenSearch kan lave k-NN og hybrid-søgning (leksikal + vektor). Stærk til interaktive workloads med lav latenstid som krav. Ulempen er omkostninger til RAM og klyngedrift.
Aurora PostgreSQL med pgvector: Relationel motor med vektorudvidelse. pgvectors similarity-søgning kører oven på en database, mange teams allerede kan drifte. Understøtter indeksmetoder som IVFFlat og HNSW samt afstandsmetrikker som L2, cosine og inner product. Fordelen er tæt integration med eksisterende dataflows og transaktioner. Ulempen kan være lavere rå vektorsøgehastighed end et specialiseret in-memory-setup under hårdt pres.
S3 Vectors: Objektlager med native vektorunderstøttelse. AWS beskriver sub-sekund-søgning og markant lavere lagringspris — op til 90% lavere lageromkostning end traditionelle vektordatabaser, ifølge deres blog. Passer til meget store, “kolde” vektormængder, hvor pris pr. embedding er vigtigt. Latency- og query-mønstre skal dog matche.
Performance vs omkostninger
Datapaden fra forespørgsel til embedding, fra embedding til vektorsøgning og videre til kontekst afgør latenstiden. OpenSearch vinder ofte på søgelatenstid, især når indeks og cache holder varme data i hukommelsen — men RAM skalerer dyrt. Aurora+pgvector giver fordele, når vektorsøgning skal kobles tæt på relationelle opslag, joins og transaktioner — færre systemhop, mere forudsigelig drift — men typisk lidt højere søgelatenstid under spidsbelastning uden målrettet tuning.
S3 Vectors prioriterer massiv skala og lav lagerpris. Ved store korpora, lav til moderat samtidighed og krav om sub-sekund, ikke lavt-cifret millisekunder, tipper TCO ofte i S3’s favør. Match workload til backend: realtidskundesupport og høj RPS kræver noget andet end natlig batch-berigelse.
Arkitekturens små beslutninger der bliver store
Embedding-model og -dimensioner påvirker både indeksstørrelse og nøjagtighed. Valget af distance-metric (fx cosine vs L2) ændrer resultatrækkefølgen. Chunk-størrelse balancerer mellem støj (for små bidder) og irrelevant ballast (for store). Top-n, reranking og evt. hybrid med BM25 kan hæve relevansen med ekstra CPU og latenstid. Opdateringsstrategien (løbende vs batch re-embed) påvirker også økonomien markant.
Shardning og replikering er centrale. I OpenSearch påvirker sharding parallelisme og cache-hit-rate. I Aurora spiller valg af indeks (HNSW er hurtigere ved søgning, men dyrere at bygge og holde i hukommelse) og brug af read-replicas ind. For S3 Vectors handler det om adgangsmønstre og partitionering, der afgør, om “sub-sekund” opleves som hurtigt eller blot acceptabelt.
Drift, skalering og operationalisering
OpenSearch kræver overvågning af noder, skaleringspolitikker, snapshots og opgraderinger. Modne værktøjer findes, men de skal bruges. Aurora ligger i velkendt DBA-territorium: parametergrupper, failover, backup/restore og Postgres-ekspertise. Det matcher teams, der allerede kører Postgres i skala.
S3 Vectors fjerner meget klassisk databasedrift og flytter arbejdet til datamodellering, batchrutiner og styring af adgangs- og omkostningsprofiler. Skalering er sjældent problemet — adgangsmønstret er. Et system, der går fra lav til pludselig høj RPS, kræver plan for cache, partitionering og kapacitetsreserver.
Sikkerhed, governance og compliance
Tre grundspørgsmål: datalokation, kryptering og adgang. Alle tre backends understøtter kryptering in transit og at rest i AWS-tjenester, men styring og praksis varierer. IAM-roller og granulær adgang styrer meget i OpenSearch- og S3-baserede løsninger, mens Aurora supplerer IAM med klassiske database-roller og privileges.
Audit-logs, regionsvalg og nøglehåndtering (KMS) er vigtige for compliance. I regioner med stram datalokation afhænger valget også af servicetilgængelighed i regionen og nøglestyring. Involver sikkerhed tidligt: fejlsvar er pinlige, datalæk er dyre.
Hvad kilderne siger — og ikke siger
AWS’ blog slår fast, at vektorlager-valget påvirker performance og pris, og beskriver RAG-arbejdsgangen med chunking, embeddings og top-n retrieval. De tre backends og deres styrker er dokumenteret og konsistente med AWS’ øvrige dokumentation om vektorindeks og RAG-principper.
Der mangler derimod uafhængige benchmarks for throughput, median- og p99-latenstid samt pris pr. forespørgsel under realistisk last. Tilsvarende savnes konkrete TCO-eksempler (fx 10 mio. vektorer ved en kendt forespørgselsrate) og åbne erfaringer med den reelle driftsindsats i kunde-styrede set-ups. Egen måling er nødvendig.
Hvornår passer hvilken backend
OpenSearch: lav latenstid, høj RPS, behov for hybrid-søgning og god cache-synergi. Aurora+pgvector: når vektorsøgning skal tæt på relationelle transaktioner, adgangsmønstre og eksisterende BI/ETL — én platform, færre systemhop. S3 Vectors: meget store korpora, uforudsigelig trafik og fokus på lagringspris, hvor sub-sekund er tilstrækkeligt. Kombinationer er oplagte, fx tiered storage.
Praktiske faldgruber der koster
Over-embedding: for høje dimensioner og tunge modeller øger latenstid og pris. Start konservativt. Forkert chunking: for store bidder giver irrelevant kontekst, for små mister mening. Test på rigtige spørgsmål. Og manglende observability: uden målinger for recall, MRR/nDCG, latency og cost pr. query bliver styringen gætværk.
Indeksvedligehold er reelt arbejde. HNSW og IVFFlat opfører sig forskelligt ved opdateringer. Ved hyppige dokumentændringer kan rebuilds eller delta-indeks være nødvendige og bør planlægges.
Anbefalet, jordnær fremgangsmåde
Start småt. Kør en afgrænset POC på en managed Knowledge Base for hurtig læring, før kunde-styret drift. Fastlæg målepunkter fra dag ét: latenstid pr. forespørgsel, top-n relevans mod et kendt spørgesæt, cost pr. 1000 queries og en enkel SLA. Brug data til at styre næste skridt.
- Definér query-profiler: interaktiv chat, batch-berigelse, rapportering.
- Vælg embeddings-model og distance-metric tidligt, og frys dem til POC.
- Test to backends side om side på samme datasæt, queries og målinger.
- Planlæg migrationskriterier: hvornår giver OpenSearch vs Aurora mening, og hvornår flyttes kolde embeddings til S3 Vectors.
- Lav en kort driftsbog: backup, reindex, skalering og cost-alarmer.
Migrering og hybrid uden drama
Start med én backend som primær og læg et read-through cache-lag foran. Det gør det muligt at introducere en sekundær vector store i baggrunden og gradvist flytte trafik. Asynkron reindeksering uden for spidslast reducerer nedetid — forudsætter versionsstyring af embeddings og indeksparametre.
Enkel hybrid: top-n kandidater i OpenSearch, reranking mod et billigere S3-baseret korpus. Eller omvendt. Hold det målbart og reversibelt.
Hvor efterlader det beslutningstageren
OpenSearch, hvis lav latenstid og høj RPS er afgørende, og RAM-regningen er accepteret. Aurora+pgvector, hvis nærhed til relationelle data og kendt drift vejer tungere end maksimal vektorydelse. S3 Vectors, hvis skala og lagerpris dominerer, og sub-sekund er nok. Kombinationer er legitime.
Ofte afgøres valget af arbejdsproces og ejerskab: hvem kan drifte hvad, og hvor hurtigt kan kvalitet måles. Teknologien er moden nok til, at praksis styrer.
Konklusion
Valget af vector store i Bedrock Knowledge Bases er et strategisk knudepunkt. Kilderne er klare på mekanikken: embeddings, vektorindeks og similarity search driver præcision og hastighed. Det, de ikke leverer, er jeres egne tal. Start der: test to backends, mål på det, der koster jer noget, og vælg det, der holder i drift.
