Hur vi gjorde RAG 50% snabbare

RAG förbättrar träffsäkerheten för AI-agenter genom att förankra LLM-svar i stora kunskapsbaser. I stället för att skicka hela kunskapsbasen till LLM:en bäddar RAG in frågan, hämtar den mest relevanta informationen och skickar den som kontext till modellen. I vårt system lägger vi först till ett steg för att omformulera frågan, där dialoghistoriken omvandlas till en exakt, fristående fråga före hämtningen.

För mycket små kunskapsbaser kan det vara enklare att skicka allt direkt i prompten. Men när kunskapsbasen växer blir RAG avgörande för att hålla svaren korrekta utan att överbelasta modellen.

Många system behandlar RAG som ett externt verktyg, men vi har byggt in det direkt i pipeline för förfrågningar så att det körs för varje fråga. Det ger konsekvent träffsäkerhet, men medför också en risk för latens.

Varför omformulering av frågor saktade ner oss

De flesta användarförfrågningar hänvisar till tidigare delar av samtalet, så systemet behöver omvandla dialoghistoriken till en exakt, fristående fråga.

Till exempel:

• Om användaren frågar: ”Kan vi anpassa de gränserna utifrån våra trafikmönster vid hög belastning?"
• Systemet omformulerar detta till: ”Kan API-gränserna för Enterprise-planen anpassas för specifika trafikmönster?”

Omformuleringen gör vaga hänvisningar som ”de gränserna” till fristående frågor som hämtningssystem kan använda, vilket förbättrar kontexten och träffsäkerheten i det slutliga svaret. Men beroendet av en enda externt hostad LLM skapade ett starkt beroende av dess hastighet och tillgänglighet. Bara detta steg stod för mer än 80 % av RAG-latensen.

Så löste vi det med modellkapplöpning

Vi gjorde om frågeomformuleringen till en kapplöpning:

• Flera modeller parallellt. Varje fråga skickas samtidigt till flera modeller, däribland våra självhållna Qwen 3-4B- och 3-30B-A3B-modeller. Det första giltiga svaret vinner.
• Reservlösningar som håller samtalen igång. Om ingen modell svarar inom en sekund faller vi tillbaka på användarens ursprungliga meddelande. Det kan vara mindre exakt, men undviker avbrott och säkerställer kontinuitet.

Effekten på prestandan

Den nya arkitekturen halverade medianlatensen för RAG, från 326 ms till 155 ms. Till skillnad från många system som bara aktiverar RAG selektivt som ett externt verktyg kör vi det för varje fråga. Med en medianlatens på 155 ms är omkostnaden för detta försumbar.

Latens före och efter:

• Median: 326 ms → 155 ms
• p75: 436 ms → 250 ms
• p95: 629 ms → 426 ms

Arkitekturen gjorde också systemet mer motståndskraftigt mot variationer mellan modeller. Externt hostade modeller kan bli långsammare under timmar med hög efterfrågan, medan våra interna modeller håller sig relativt konsekventa. Genom att låta modellerna tävla jämnas variationerna ut, så att oförutsägbar prestanda hos enskilda modeller blir ett stabilare systembeteende.

När en av våra LLM-leverantörer till exempel drabbades av ett avbrott förra månaden fortsatte samtalen sömlöst med våra självhållna modeller. Eftersom vi redan driver den här infrastrukturen för andra tjänster är den extra beräkningskostnaden försumbar.

Varför det är viktigt

RAG-omformulering av frågor på under 200 ms tar bort en stor flaskhals för konversationsagenter. Resultatet är ett system som både förstår kontext och fungerar i realtid, även med stora kunskapsbaser för företag. När omkostnaden för hämtning är nästintill försumbar kan konversationsagenter skalas utan att prestandan försämras.