Sådan kan query-aware compression skære RAG-omkostninger på Amazon Bedrock
AWS har udgivet et teknisk blogindlæg, der beskriver et enkelt men potent greb til RAG på Bedrock: brug en lille model til at filtrere de hentede dokumentbidder, før hovedmodellen kaldes. Målet er at reducere input-tokens, som ofte udgør en stor del af omkostningen ved RAG i skala. Det er ikke magi – bare nøgtern token-husholdning.
Hvorfor betyder det noget nu? Mange RAG-opsætninger har optimeret for høj recall og henter mange tekststykker for at være sikre på, at den rette viden er med. Det føles trygt, men koster, især når hver forespørgsel sender tusinder af tokens til en dyr model.
Hurtigt overblik
Konceptet er query-aware compression: Efter retrieval kigger en mindre, billigere model på både brugerens spørgsmål og de hentede chunks og sender kun de mest relevante tekststumper videre. AWS viser mønsteret med en AWS Lambda-implementering og drøfter cost-model og latency-afvejninger.
Bloggen fremhæver også, at mønsteret kan kombineres med Bedrock-funktioner som Knowledge Bases, Rerank API, prompt caching og Intelligent Prompt Routing. Overvej dem – men mål effekten, før lagene stables.
Hvor store er token-omkostningerne i RAG?
RAG-retrieval henter ofte top-k mellem 5 og 20 stykker tekst, ifølge AWS’ beskrivelse. Kombineret med typiske chunk-størrelser lander mange tekniske og juridiske workloads i spændet “flere tusinde input-tokens pr. query”. Det er intervaltal, ikke facit, men de matcher praksis mange steder. Sørg for en uafhængig reference eller et benchmark, der bekræfter tallene for netop jeres datatyper og modeller.
Pointen er enkel: Jo flere tokens du sender ind i en dyr model, jo højere regning. Og det løber hurtigt op ved tusindvis af forespørgsler om dagen.
Hvad gør query-aware compression konkret?
Mønstret indsætter et filtertrin efter retrieval. En mindre model, i AWS’ eksempel Anthropic Claude Haiku på Bedrock, læser både spørgsmålet og de hentede chunks og udvælger kun de mest relevante passager. Derefter kaldes hovedmodellen – i eksemplet Anthropic Claude Sonnet – med den trimmede kontekst.
Effekten er ligetil: færre tokens rammer den dyre model, fordi irrelevant tekst skæres væk af den billige model først. AWS beskriver en mulig sidegevinst: mindre irrelevant kontekst kan reducere fladen for hallucination. Det bør dog valideres empirisk.
Arkitekturillustration
Dataflowet ligner et klassisk RAG-forløb – med et ekstra filtertrin:
- Embed spørgsmålet og hent top-k fra indekset, fx via Bedrock Knowledge Bases. Rerank kan indgå her som et valgfrit skridt.
- Kald den lille filtermodel i en Lambda-funktion og behold kun de relevante tekstuddrag.
- Send den komprimerede kontekst til hovedmodellen og generér svaret.
- Overvej prompt caching for gentagne eller overlappende prompter. Intelligent Prompt Routing kan i nogle opsætninger vælge en mindre hovedmodel på lette spørgsmål.
Hele kaskaden kan – som i AWS’ eksempel – køre i en enkelt Lambda. Det gør koblingen mellem logik og målepunkter enkel, men kræver omtanke for timeouts og koldstart.
Kostmodel: hvornår sparer man penge?
Bytteforholdet er klart: Du betaler for et ekstra modelkald, men reducerer antallet af tokens, som rammer den dyre model. Om det betaler sig, afhænger af:
- Tokens pr. query før og efter filteret.
- Pris pr. token for både den lille og den store model.
- Lambda-kørslernes pris og varighed.
- Andelen af queries med stor nok kontekst til, at filtrering giver effekt.
Ved kontekster på flere tusinde tokens er potentialet tydeligt. Er konteksten lille, forsvinder gevinsten. Lav en break-even-beregning – ikke en mavefornemmelse.
Latency og brugeroplevelse
Ekstra kald betyder ekstra ventetid: filtermodellens inferens, netværksrunden og Lambda-tid. I vidensarbejdsflows er et par hundrede millisekunder ofte acceptable; i kundevendte chatoplevelser kan det mærkes.
Mulige greb: batch filtrering i ét kald, asynkrone svar, caching af uændrede dele af konteksten, og at rute simple spørgsmål uden om filteret. Mål 95- og 99-percentiler på end-to-end latency før og efter.
Kvalitetskontrol og hallucinationsrisiko
AWS anfører, at mindre irrelevant kontekst kan dæmpe hallucination. Fornuftigt – men dokumentér det. Et realistisk eval-setup kan indeholde:
- Et hold-out sæt af spørgsmål med kendte svar.
- Metrikker som EM og F1, suppleret af menneskelig annotering på relevans og faktuel korrekthed.
- En simpel “hallucinationsrate” eller et R-indeks før/efter filtrering, målt over gentagne kørsler.
Hold især øje med to fejltyper: at filteret kasserer kritisk evidens (ufuldstændige svar), og at det omvendt lader for meget fyld passere (ingen besparelse). Balancen kræver tuning.
Bedrock-specifikke overvejelser
Mønstret er kompatibelt med Bedrocks retrievers, herunder Knowledge Bases, ifølge AWS. Implementering kræver en aktiv AWS-konto og en IAM-rolle, der giver Lambda adgang til Bedrock. Derudover kræves modeladgang i den valgte region – i eksemplet til to modeller i samme familie: Claude Haiku som kompression og Claude Sonnet som primær. Adgang anmodes i Bedrock-konsollen under Model access.
Tilgængelighed varierer pr. region. Tjek konsol eller dokumentation tidligt, hvis miljøet har stramme regionkrav.
Implementationsnoter: Lambda-eksemplet
Blogindlægget viser en kerne-implementering i en AWS Lambda-funktion: den modtager retrieved chunks, kalder den lille model for at udtrække relevante tekstuddrag og sender derefter den komprimerede kontekst til hovedmodellen. Ét flow, der returnerer det endelige svar.
Ved drift bør man instrumentere: tokens ind/ud per trin, model-latency, Lambda-varighed og koldstart-rate samt fejlkoder ved Bedrock-kald. Uden de tal bliver optimering et gæt.
Sikkerhed, compliance og drift
Filtrering fungerer som dataminimering – mindre tekst sendes til den dyre model. Til gengæld bør der være auditspor: hvilke chunks kom ind, hvad blev kasseret, og hvorfor. Gem mindst id’er og korte checksums frem for fulde tekstmængder.
Stram adgangskontrol på IAM-rollen, og undgå at logge følsomme data. Overvåg throttling og retries mod Bedrock. Bursttrafik kan ellers give spikes i både latency og omkostning.
Hvornår bør man ikke gøre det
Hvis svar skal leveres på under et halvt sekund i interaktive flows, er et ekstra modelkald en høj pris. Og hvis domænet kræver meget lang kontekst, hvor næsten alt kan være relevant – fx komplekse kontrakter – kan et aggressivt filter give blinde vinkler.
Hvis jeres pipeline allerede sender få hundrede tokens til hovedmodellen, er gevinsten sandsynligvis for lille. Det behøver ikke være “smartere”, hvis det allerede er billigt.
Hvad man bør måle før og efter
For at vurdere effekten er disse datapunkter centrale:
- Tokens pr. query før og efter filtrering.
- Omkostning pr. 1.000 queries før/efter, fordelt på filtermodel, hovedmodel og platform.
- End-to-end latency på 50./95./99.-percentiler samt andel af timeouts.
- Kvalitet: EM, F1 og menneskelig vurdering af korrekthed og kildebrug.
- Fejlrate på Lambda og Bedrock-kald, inkl. throttling og retries.
De tal er det, der tæller – ikke overskrifterne.
Hvad mangler der af dokumentation?
Der er få uafhængige benchmarks, der kvantificerer besparelser og latency-penalty bredt. Der efterlyses målinger fra mindst én tredjepart på tværs af datasæt: tokens før/efter, cost pr. 1k queries, latency-overhead for Lambda + filtermodel og kvalitetsmålinger med både automatiske og menneskelige scorer.
Der mangler også sammenligninger af små filtermodeller. AWS viser Haiku i eksemplet, men ikke en komparativ analyse på tværs af modeltyper eller parametre. Det er et oplagt sted at starte egne tests.
Praktiske, valgfrie optimeringer
AWS peger på flere lag, som kan kombineres med filtrering: prompt caching for gentagne mønstre, Intelligent Prompt Routing for at nedskalere modellen på lette spørgsmål samt Rerank API for at skærpe rækkefølgen af konteksten, før filteret kører.
“Kompoundede besparelser” er en god idé i teorien – men test dem enkeltvis først, og mål derefter i kombination.
Baggrundsposition om helhedsoptimering
En separat analyse fra Snilld anbefaler et holistisk spor: kortlæg token-flow, finjustér embeddings og vektorsøgning, og tilpas promptdesign. Query-aware compression er ét håndtag. Det er en position – ikke en AWS-udmelding – og bør vurderes på egne målinger.
Hvem bør tale med hvem
For at komme fra blog til produktion: tal med en Bedrock-ingeniør om model- og regionsdetaljer, en uafhængig cloudarkitekt om omkostningsregnestykket, en slutbruger med reel RAG-trafik og gerne en modeludbyder (fx Anthropic) om små-modellers styrker og svagheder som filtre.
Og få en benchmarkpakke på plads – offentlig og reproducerbar. Det savnes stadig.
Konklusion
Query-aware compression på Amazon Bedrock er et nøgternt, anvendeligt mønster. AWS’ blogpost lægger sporene: et Lambda-eksempel, en cost-model og latency-overvejelser samt kompatibilitet med Knowledge Bases, Rerank, prompt caching og Intelligent Prompt Routing. De estimerede tal for top-k og tokenmængder passer med praksis, men bør bekræftes af uafhængige tests.
Det lovende? At skære irrelevante tokens fra, før den dyre model ser dem. Hullerne? Manglen på brede benchmarks og klare retningslinjer for valg af filtermodel. Næste skridt er ikke flere slides – det er målinger i egen pipeline, med stopur og regneark.
