RAG-kaskade sænker inferensomkostninger 6x

Princippet er enkelt, men det kræver, at man tør designe systemet anderledes end den typiske RAG-pipeline. Fremfor at sende alle forespørgsler direkte til en LLM, deler kaskaden opgaven op i tre lag, der hver især filtrerer sagerne, før de eventuelt går videre til det næste og dyrere lag. Første lag er deterministiske regler. Andet lag er retrieval, altså søgning i det eksisterende datagrundlag. Tredje og sidste lag er LLM'en, som kun ser de sager, ingen af de forrige lag kunne afgøre med sikkerhed.

Resultatet af den arbejdsdeling er markant: når kun en lille andel af forespørgslerne rammer den dyre model, falder den samlede inferensomkostning med en faktor på omkring seks, sammenlignet med at sende alt gennem LLM'en. Det er ikke en marginal optimering. Det er en anden måde at tænke systemarkitektur på.

Det første lag i kaskaden er bevidst kedeligt. Klare, forudsigelige regler, ofte simple betingelser eller opslag i strukturerede data, afgør en stor del af sagerne uden nogensinde at røre en model. Er beløbet under en given grænse? Matcher dokumentet et kendt mønster? Er afsenderen på en godkendt liste? Den slags spørgsmål kræver ikke sproglig forståelse, og de bør derfor aldrig belaste en LLM.

Den deterministiske del er også den del, der er lettest at revidere. Reglerne er eksplicitte, de kan læses af et menneske, og de giver samme svar hver gang på samme input. I brancher med tilsynskrav, som finans eller sundhed, er den forudsigelighed ikke bare en bekvemmelighed, det er en forudsætning for overhovedet at kunne dokumentere systemets beslutninger over for en revisor eller et tilsyn.

De sager, reglerne ikke kan afgøre, går videre til retrieval-laget. Her handler det ikke om at generere et svar, men om at finde lignende, tidligere afgjorte sager i det datagrundlag, systemet har adgang til. Hvis en ny sag ligner et allerede klassificeret tilfælde tæt nok, kan systemet arve klassifikationen derfra, uden at en model behøver generere noget nyt.

Det er her kaskaden virkelig sparer penge, fordi retrieval er markant billigere end en generativ forespørgsel. Samtidig er det et lag, der bliver bedre over tid: jo flere sager der er klassificeret og gemt, desto flere fremtidige sager kan retrieval-laget selv løse, uden at nogensinde nå frem til LLM'en. Det skaber en form for indbygget selvforstærkning i systemet.

Det, der er tilbage, når regler og retrieval har filtreret, er de sager, hvor der reelt er tvivl, hvor konteksten er ny, eller hvor sproget er tvetydigt nok til, at hverken en fast regel eller en lighedssøgning giver et sikkert svar. Det er præcis den type opgaver, en sprogmodel er god til, og det er derfor rimeligt, at det er dem, den bruges på.

Den praktiske konsekvens er, at LLM'en typisk kun ser en lille brøkdel af den samlede mængde forespørgsler, måske ti til tyve procent afhængigt af domænet. Resten er allerede afgjort, billigt og forudsigeligt, længe før nogen model overhovedet bliver kaldt. Det er den forskydning, der driver omkostningsbesparelsen.

Når en sag først når LLM'en, er den per definition en af de sværere. Her giver det mening at prompte modellen anderledes, end man ville i en generel chatbot. Et princip, vi bruger i vores egne kaskadedesign, er asymmetrisk risikoprompting: modellen bliver instrueret til at behandle falske negativer og falske positiver forskelligt, alt efter hvad den faktiske forretningsrisiko er. En forkert klassificering, der lukker en legitim sag, koster typisk mere end en forkert klassificering, der sender en tvivlsom sag videre til manuel gennemgang. Prompten skal afspejle den asymmetri, ikke behandle alle fejltyper som lige alvorlige.

Det stiller også krav til, hvordan man evaluerer systemet. Fordi hvert lag i kaskaden har sin egen fejlprofil, giver det ikke mening kun at måle den samlede nøjagtighed. Man er nødt til at kunne se, hvor mange sager der blev afgjort af regler, hvor mange af retrieval, og hvor mange der endte hos LLM'en, samt fejlraten i hvert lag for sig. Den granularitet er, hvad der gør systemet revisionsklart: man kan pege på præcis, hvilket lag der traf en given beslutning, og hvorfor.

Vi driver større AI-projekter for danske virksomheder, fra problemafklaring til drift, og det mønster, vi ser oftest, er, at virksomheder starter med at sende alt gennem én model, fordi det er den hurtigste vej til et fungerende system. Det er en fornuftig start. Men når volumen vokser, og omkostningerne begynder at gøre ondt, er kaskaden ofte det næste naturlige skridt, ikke en ny model, ikke en dyrere model, men en anden arbejdsdeling mellem regler, søgning og sprogforståelse.

For virksomheder i regulerede brancher er gevinsten ikke kun økonomisk. En kaskade gør det muligt at vise, hvorfor en given sag blev klassificeret, som den blev, fordi de fleste afgørelser aldrig involverede en sort boks til at begynde med. Det er en arkitektur, der passer godt til dansk og europæisk tilsynspraksis, hvor kravet om forklarlighed sjældent forsvinder, uanset hvor god modellen bliver.

Det kræver et ekstra lag arbejde at bygge kaskaden rigtigt, at definere reglerne præcist, at bygge et retrieval-lag der faktisk rammer relevante sager, og at instrumentere systemet, så man kan se, hvad der sker i hvert trin. Men for virksomheder, der allerede kører RAG i produktion og mærker regningen stige med volumen, er det en investering, der typisk betaler sig hurtigt tilbage, både i kroner og i den ro, det giver at kunne dokumentere sine beslutninger.