NarrateAI: LLM-kvalitetssikring på Bedrock

NarrateAI har bygget en produktionspipeline på Amazon Bedrock, der

NarrateAI har bygget en produktionspipeline på Amazon Bedrock, der samler fem forskellige teknikker for at løse et problem, de fleste virksomheder med agentiske AI-systemer kender alt til: LLM-svar, der lyder overbevisende, men som ikke kan stå distancen i produktion. Løsningen lander på omkring 99 procent nøjagtighed, uden at brugeren mærker det på svartiden.

Pipeline

Fem teknikker samlet i én produktionsklar pipeline

Det, der gør NarrateAIs tilgang interessant, er ikke en enkelt genial teknik, men kombinationen. Cross-account failover mellem flere modeller, realtidsevaluering af streamede svar, sammensat verifikation af dataakkuratesse og et orkestreringslag, der binder det hele sammen. Hver teknik løser sit eget delproblem, men det er summen, der gør pipelinen produktionsklar.

Jeg ser det samme mønster igen og igen: man forsøger at løse pålidelighed med én foranstaltning, typisk bedre prompts eller en enkelt evalueringsmodel. Det holder i en pilot. Det holder ikke, når volumen stiger og edge cases begynder at dukke op i produktion. NarrateAIs pointe er, at pålidelighed er et lag-problem, ikke et enkeltpunkt-problem.

Pålidelighed er et lag-problem, ikke et enkeltpunkt-problem.

Infrastruktur

Cross-account multi-model failover: når én model eller konto ikke er nok

Den anden teknik handler om, at systemet skal blive ved med at virke, selv når noget fejler på infrastrukturniveau. I stedet for at binde sig til én model eller én AWS-konto, ruter pipelinen forespørgsler mellem flere modeller og flere konti på Amazon Bedrock. Rammer man en throttling-grænse, en model-outage eller en kapacitetsbegrænsning i én konto, failer systemet automatisk over til en anden kombination, uden at brugeren oplever et nedbrud.

Det er en løsning på et problem, der bliver undervurderet, indtil man rammer det. Modelkapacitet på Bedrock er ikke uendelig, og når flere agentiske workloads deler samme kvote, opstår flaskehalse, der kan lamme en produktionsservice midt i en travl periode. Cross-account routing spreder belastningen og fjerner det enkelte fejlpunkt, som mange arkitekturer stadig bygger på.

Evaluering

Realtidsevaluering af streamede svar uden at bremse brugeren

Den tredje teknik er måske den mest teknisk krævende: at evaluere kvaliteten af et svar, mens det stadig streames til brugeren, uden at tilføje mærkbar latenstid. De fleste evalueringsmetoder i dag kører efter svaret er færdigt, hvilket betyder, at man opdager fejl for sent til at rette dem, før brugeren allerede har set dem.

NarrateAIs pipeline evaluerer løbende dele af svaret, mens det genereres, og kan gribe ind, hvis kvaliteten falder under en tærskel, før det færdige svar når frem. Det kræver en evalueringsmodel, der er hurtig nok til at følge med streamingtempoet, og en arkitektur, der kan afbryde eller korrigere output uden at brugeren mærker en pause. Det er den type ingeniørarbejde, der ikke er synligt, når det virker, men som er hele forskellen mellem en demo og en produktionstjeneste.

Datakvalitet

Sammensat evaluering og verifikation af dataakkuratesse

Den fjerde og femte teknik hænger sammen: en sammensat evalueringsmetode, hvor flere signaler vejes mod hinanden i stedet for at stole på én scoringsmodel, kombineret med direkte verifikation af, at faktuelle påstande i svaret rent faktisk stemmer med de underliggende data.

Det er her, mange LLM-baserede systemer falder igennem i praksis. En model kan generere et svar, der er grammatisk perfekt og lyder autoritativt, men som indeholder en talfejl eller en påstand, der ikke findes i kildedata. Sammensat evaluering fanger inkonsistens i tone og struktur. Dataverifikation fanger den slags faktuelle afvigelser, som ren sproglig evaluering ofte overser. Sammen dækker de to forskellige fejltyper, som ellers kræver hver deres separate kontrolsystem.

Nøjagtighed

Hvad omkring 99 procent nøjagtighed betyder i praksis

Et tal som 99 procent nøjagtighed lyder imponerende isoleret, men det vigtige er, hvad de sidste procent koster, hvis de ikke bliver fanget. I en kundeservicebot er en fejlrate på en procent måske acceptabel. I en agent, der behandler finansielle transaktioner eller sundhedsdata, er samme fejlrate potentielt et compliance-problem.

Det, der gør NarrateAIs tal relevant, er ikke tallet selv, men at det er nået gennem lag af kontrol frem for et enkelt filter. Det betyder, at de resterende fejl typisk er de svære edge cases, ikke systematiske svagheder, der kunne være fanget tidligere. For virksomheder, der planlægger at sætte agentiske systemer i produktion, er det forskellen på en risikoprofil man kan leve med, og en man ikke kan.

Danmark

Hvorfor det rammer direkte danske virksomheders AI-drift

For danske virksomheder, der bygger eller drifter agentiske AI-systemer på Bedrock, er NarrateAIs tilgang en konkret skabelon, ikke bare en teoretisk øvelse. Mange danske organisationer er i gang med at flytte fra pilotprojekter til produktionsdrift lige nu, og her bliver spørgsmålet om pålidelighed ubarmhjertigt praktisk: hvad sker der, når systemet rammer sin første rigtige edge case i drift, uden en udvikler til at overvåge output i realtid?

Jeg anbefaler altid mine kunder at tænke evaluering som et lag, der er indbygget i pipelinen fra dag ét, ikke noget man lægger på bagefter. Cross-account failover er særligt relevant for virksomheder, der allerede har mærket kapacitetsbegrænsninger på Bedrock i spidsbelastning, og realtidsevaluering af streamede svar er den type detalje, der afgør, om et AI-produkt føles professionelt eller amatøragtigt for slutbrugeren.

Det, NarrateAI demonstrerer, er, at produktionsklar LLM-kvalitetssikring ikke kræver en ny model eller en ny platform. Det kræver, at man bygger flere lag af kontrol ind i den arkitektur, man allerede har, og at man designer for de fejl, der opstår i skala, ikke bare de fejl, man ser i en demo.

01 / 01

Et øjeblik…

Henter spørgsmål…

1 / 4

Vælg ydelse

Henter ydelser…