sammanfattning

Sammanfattning

Tre faktorer avgör om en juridisk AI-agent är effektiv.Modellen som ligger till grund för den,det system som byggts uppkring den (till exempel juridikspecifika agenter som CoCounsel, Lexis+ med Protégé, Harvey, Legora och NetDocuments egen assistent, eller allmänna verktyg som ChatGPT eller Claude) samtdet sammanhang denhar tillgång till under arbetet – dokumenten, sökningen som hittar dem, kunskapsgrafen som kopplar samman dokumenten och allt annat som byrån tar fram om ärendet. Det finns redan ett antal kvalitetsmått (som ValsVLAIR och Harveys BigLaw Bench) för att mäta de två första faktorerna var för sig eller alla tre som en helhet. Men såvitt vi vet isolerar ingen av dem effekten och ekonomin hos själva kontextlagret – vad som förändras, både vad gäller svarens kvalitet och kostnaden, när modellen och ramverket hålls konstanta och endast kontexten varierar. 

Denna klyfta är viktig eftersom varje faktor – modell, anpassningsram och sammanhang – utvecklas separat över tid och erbjuder företagen olika strategiska möjligheter. Modellerna förbättras i takt med framstegen hos företagen som utvecklar grundläggande modeller. Anpassningsramarna utgör ett extremt konkurrensutsatt område, och företagen använder ofta flera samtidigt eller växlar mellan dem över tid allteftersom marknadslandskapet förändras. Kontexten är det lager som byggs upp en gång och bevaras genom varje modelluppgradering och varje agent som ett företag inför. Det är ett av de få områden där företagets egna investeringar ger avkastning istället för att nollställas. 

Med detta i åtanke har vi tagit fram ett jämföretest som bygger på den enklaste principen: att hålla modellen och testramverket oförändrade, endast göra ändringar i kontextlagret och mäta hur noggrannheten och kostnaden förändras. Vårt jämföretest är medvetet neutraltnär det gäller hur kontextenska förbättras, eftersom både mer omfattande metadata, mer precis informationshämtning, anpassade färdigheter och en kunskapsgraf alla är möjliga alternativ. 

Att enbart utgå från noggrannhet skulle vara fel sätt att mäta, eftersom noggrannhet nästan alltid kan köpas med större resurser: en större modell, mer resonemang, fler sökningar. Varje ärlig mätning av ett kontextlager måste därför väga den kvalitet det producerar mot vad det kostar att uppnå den kvaliteten. Den enhet vi fastnade förär kostnaden för ett korrekt svar. Förändringen i den siffran är vad vi kallarContext Value Ratio(CVR). När vi utvärderade vår Legal Context Graph mot detta riktmärke blev resultaten entydiga. Till exempel:

Denna effektivitetsvinst ställer företagen inför ett val. De kan ta ut besparingarna, återinvestera dem i bättre svar eller göra båda delarna. Ett företag som är nöjt med den nuvarande träffsäkerheten kan realisera besparingarna direkt.För ett företag med 2 000 anställda som ställer fyra miljoner frågor per år innebär det en årlig besparing på cirka 940 000 dollar vid oförändrad kvalitet.Ett företag som vill ha bättre träffsäkerhet kan återinvestera en del av denna effektivitetsvinst. I jämförelsen diskuterar vi ett exempel där en höjning av modellens resonemangsinsats från medelhög till hög förbättrade noggrannheten med 7 procent, samtidigt som kostnaden fortfarande var 18 procent lägre än baslinjen. I praktiken innebär det 216 000 ytterligare korrekta svar per år. Det här är inga enkla vinster: de svar som ett system ännu inte har lyckats få rätt är per definition de svåra.

Och även om dessa siffror är det som hamnar i rubrikerna, fokuserar denna rapport ingående på metodiken bakom dem: hur och vad man ska mäta när det gäller den juridiska kontexten, vad en förbättring av svarskvaliteten är värd i förhållande till vad den kostar, och var ytterligare investeringar ger bäst avkastning. Syftet är att förse juridiska avdelningar och advokatbyråer med ett ramverk som kan återanvändas för att utvärdera effekten av deras eget kontextlager över tid. 

01 – Så här fungerar det

Hur LCEB – och det ramverk som ligger till grund för det – fungerar

Den grundläggande utformningen av Legal Context Engineering Benchmark är en kontrollerad jämförelse med en enda variabel. En agent – det vill säga en fast modell inom en fast ram – besvarar samma uppsättning frågor två gånger. Vid det första genomgången har agenten endast de verktyg som en agent normalt har: en sökning i ärendets dokument och möjligheten att hämta texten för vidare granskning. Vid det andra genomgången har den samma verktyg och kan dessutom nå det förbättrade kontextlagret som testas (till exempel en kunskapsgraf, bättre metadatafilter, semantisk sökning). Eftersom modellen, instruktionerna och frågorna hålls konstanta under de båda genomgångarna är det troligt att eventuella skillnader i svarens kvalitet eller kostnad direkt beror på kontextingenjörsarbete. 

Observera att det är svårare än det låter att hålla andra variabler konstanta. En verktygsbeskrivning som styr en agent på ett sätt som överanpassar sig till testdatauppsättningen, ett ändrat systemmeddelande som får agenten att bete sig annorlunda, en sökparameter som är inställd för den ena sidan men lämnas oförändrad för den andra: vart och ett av dessa inför en ytterligare variabel, och det resulterande resultatet är inte längre en mätning av kontexten. Vår interna testram jämför därför de två verktygsgränssnitten innan en körning inleds och kan inte fortsätta om de skiljer sig åt i något avseende utöver tillgängligheten av själva Legal Context Graph. 

Den nuvarande versionen av vårt jämförelsetest bygger på tio verkliga ärenden – fem transaktionsärenden och fem tvisteärenden – som sammanställts utifrån offentliga myndighetshandlingar och domstolsförteckningar som antingen helt eller delvis ligger utanför tidsgränsen för träningsdata i de modeller vi testat med (detta bidrar till att säkerställa att agenterna inte svarar utifrån sina träningsdata utan istället tvingas förlita sig enbart på innehållet i testärendet). Tillsammans omfattar de tio ärendena 874 dokument och ungefär 60 miljoner tecken: registreringshandlingar och fullmakter som uppgår till hundratusentals tecken vardera, tillsammans med förteckningar över yrkanden, beslut, utskrifter av vittnesförhör och korrespondens. Inget i dokumentkorpusen var syntetiskt genererat, vilket är ett medvetet designval vi gjorde. Gång på gång under våra tester såg vi att ett syntetiskt genererat ärende som såg realistiskt ut på avstånd saknade inre logik eller – ännu värre – visade sig vara orimligt förenklat vid närmare granskning. 

Varje ämne i LCEB innehåller minst tjugofem frågor – sammanlagt trehundra för de tio ämnena – och var och en av dem är en fråga som en jurist skulle ha anledning att ställa. Frågorna är medvetet fördelade över olika svårighetsgrader och typer, och varje fråga är märkt med den typ den tillhör. 

Frågorna utformas utifrån källdokumenten genom att man använder en rad kraftfulla modeller för att läsa igenom varje dokument i ett ärende i sin helhet, vilket ofta är en oerhört token-ineffektiv och kostsam process. Agenterna föreslår sedan fråga- och svarspar utifrån vad som framkommer vid dessa djupgående analyser. Varje par består av tre delar: själva frågan, ett referenssvar som redogör för vad dokumentationen faktiskt stöder (inklusive källhänvisningar) och en kort lista över de specifika saker som ett fullständigt svar måste innehålla, vilket utgör bedömningskriterierna för den frågan. 

Slutligen kontrollerar vi svaren och bedömningskriterierna genom deterministiska valideringar (till exempel om källhänvisningarna i svaret faktiskt motsvarar text i dokumentkorpuset) samt genom stickprovskontroller utförda av en mänsklig ämnesexpert. 

De svar som agenterna genererade under de två testkörningarna – till exempel en gång med Legal Context Graph aktiverat och en gång utan – bedöms sedan av en avancerad modell, som tar hänsyn till frågan, de kriterier som gäller för den, det fullständiga svaret samt spårningen av de verktygsanrop som agenten utförde för att ta fram svaret. 

En körning registrerar två saker: om svaret var rätt och vad det kostade att generera. Varje anrop som agenten gör räknas, och dess tokens sorteras i tre kategorier – ny indata, cachelagrad indata och utdata – eftersom varje kategori debiteras enligt olika priser. Dessa priser är de offentliggjorda priserna för den modell som ger svaret, gällande vid tidpunkten för publiceringen. Resultatet blir ett belopp i dollar. 

Observera att eftersom modellen hållsoförändrad i enjämförelse kan jämförelsen upprepas på en annan modell och resultaten jämföras sida vid sida. Vi gjorde detta för alla tre medlemmarna i GPT-5.6-familjen, så att endast kapacitetsförändringarna varierar och prisstrukturen förblir jämförbar: 

Alla tre har samma kunskapsavgränsning den 16 februari 2026, vilket innebär att deras träningsexponering mot datamängden är identisk. Alla tre testades mot samma tio ämnen, samma 300 frågor, samma bedömningskriterier, samma backend för levande dokument och samma konfiguration för bedömningssystemet. Det enda som skiljer de tre resultattavlorna som vi presenterar senare (i avsnitt 2) åt är vilken modell som besvarade frågorna. 

Två egenskaper gör att denna ytterligare jämförelse är värd att genomföra. För det första testar den om ett kontextlager fungerar som en krycka för svaga modeller eller som en drivkraft för starka modeller – en distinktion som avgör om investeringen överlever nästa modelluppgradering. För det andra delar CVR upp två kostnader som mäts påsamma modell, vilket innebär att modellens pris förekommer både i täljaren och nämnaren och därmed tar ut varandra. Det som återstår efter avräkningen är just det vi vill jämföra: i vilken utsträckning varje modells användning av kontextlagret påverkar vad ett korrekt svar kostar den. Det är därför de tre nyckeltalen kan läsas sida vid sida, även om de belopp i dollar som ligger bakom dem inte kan det. 

02 – måttenheten

Vad ett rätt svar kostar

Kostnadsskillnaden mellan olika agenter som körs på samma modell brukade i de flesta fall vara så liten att den kunde ignoreras. När en agent svarade i ett enda steg läste den i måttlig utsträckning och skrev i måttlig utsträckning; numera planerar den, anropar verktyg, läser, gör nya försök och kontrollerar sitt arbete, och detta har blivit den största rörliga kostnaden för att driva systemet. Denna trend accelererar bara. METR, som mäter på mjukvaru- och forskningsuppgifter snarare än juridiska sådana, konstaterar att längden på den uppgift som en agent i framkant slutför utan hjälp med en framgångsgrad på 50 procent nu uppgår till flera timmar, och har fördubblats ungefär var fjärde månad. 

Detta innebär att kostnaden blir något som ska mätas, och väcker samtidigt frågan om vilken enhet man ska mäta den i. Kostnad per förfrågan eller per uppgift är det enklaste måttet att beräkna, men också ett av de minst informativa, eftersom det som verkligen är viktigt för en jurist är ett korrekt svar. Kostnad per korrekt svar ärdärför det mått vi valt: den totala kostnaden för en körning dividerad med det kreditviktade antalet korrekta svar inom den, vilket ger ett enda tal i dollar där lägre är bättre. 

Den siffran avser kostnadenför att svara: varje modellanrop som agenten gör när den besvarar en fråga eller utför en uppgift. Att inledningsvis bygga upp sammanhanget är en separat kostnad, som betalas en gång per ärende snarare än en gång per fråga, och den ingår i den fullständiga översikten som diskuteras i avsnitt 4. 

Sedan:

Kontextvärdeskvoten anger hur många gånger billigare ett rätt svar blir. Vid ett värde på 2,0 gör kontextlagret att ett rätt svar kostar hälften så mycket. Över 1,0 ger det avkastning; vid 1,0 går det jämnt upp; under 1,0 kostar det mer än det ger i avkastning. 

Kvoten mäteren förändring, vilket är den fråga ett företag som överväger en investering ställer sig: lönar det sig utifrån den nuvarande situationen? Vad den inte kan säga är var företaget befinner sig till att börja med. Det är därför vi, förutom CVR-siffran, alltid tittar på kvalitetsbetyget: hur fullständigt svaret från agenten är, beräknat som ett genomsnitt över alla frågor, på en skala från 0 till 100. 

Båda siffrorna är absolut nödvändiga, eftersom ett pris alltid kan förbättras genom att minska insatsen snarare än genom att förbättra prestationen, och det billigaste sättet att sänka kostnaden för ett rätt svar är att sluta försöka besvara de frågor som är svåra att besvara. Tänk dig två system som ställs inför samma hundra frågor: 

Svaren från system B kostar en tredjedel mindre styck, och system B är det alternativ som inget företag skulle vilja ha, eftersom det lämnat sextio av hundra frågor obesvarade. Priset i sig räcker inte för att skilja dem åt. 

Samma försiktighet gäller vid jämförelser mellan två olika system – eller mellan olika dokumentuppsättningar – eftersom det är enklast att förbättra ett pris när det finns utrymme kvar i jämförelsegrunden: ett system som besvarar sex av tio frågor har möjlighet till kostnadseffektiva förbättringar över hela linjen, medan ett system som redan besvarar nio av tio måste satsa stora resurser för varje återstående poäng. Förhållandet är mest tillförlitligt när det jämförs med företagets egen tidigare utgångspunkt – samma ärenden, samma frågor, både med och utan kontextlagret. 

Det är hela metoden. Resultatet blir den uppsättning resultatkort som visas nedan. Låt oss titta närmare på dem. 

03 – Att omsätta det i praktiken

Vad besparingarna är värda för ett företag

Ett mått som ”Context Value Ratio” är användbart i teorin, men det som verkligen spelar roll för advokatbyråer och juridiska avdelningar är hur man omsätter det i praktiken: antingen för att förbättra sin verksamhet eller för att höja nivån på sina juridiska tjänster. Det här avsnittet handlar just om det. 

Tänk dig en stor byrå – 2 000 jurister med tillgång till en juridisk AI-assistent – och fundera på vad Legal Context Graph är värt för dem under ett år. Tre olika konfigurationer är relevanta för frågan, och vi har mätt alla tre utifrån gränsmodellen utifrån samma 300 frågor: 

De två första raderna visar jämförelseresultatet från avsnitt 2, uttryckt per fråga: kontextlagret säkerställer kvalitet och halverar kostnaden. Den tredje raden är central för vad detta avsnitt handlar om. Efter att ha minskat kostnaden per fråga med nästan hälften med hjälp av Legal Context Graph behöver en byrå inte realisera dessa besparingar som direkta kontanter. Man kan istället ”återinvestera” en del av dessa besparingar i konfigurationer av agentens resurser som höjer noggrannheten – en större modell, en längre resonemangsbudget, bredare informationssökning. I detta exempel tar vi det enklaste av dessa alternativ: att höja modellens resonemangsinsatsfrån ”medel” till ”hög”, vilket gör att samma agent kan fundera längre på varje fråga, resonera mer ingående, verifiera mer och läsa vidare. 

Det som gör den här uppgraderingen ekonomiskt genomförbar är kontextlagret. Att öka insatsen för resonemang kostar ungefär 1,5 gånger mer per fråga, oavsett om grafen finns eller inte. Om detta tillämpas på den oassisterade baslinjen skulle det öka företagets kostnader med ungefär hälften. Om det tillämpas utöver ett frågepris som redan har halverats innebär samma uppgradering att företaget spenderar18 % mindre än vaddet gör idag. Noggrannheten köps därför med utgifter som företaget redan hade budgeterat för. 

Företaget står alltså inför ett verkligt strategiskt val snarare än en begäran om finansiering, eftersom ingen av vägarna kräver att man spenderar en dollar mer än vad man gör idag. Den första vägen är att spara in besparingen samtidigt som kvaliteten hålls på samma nivå, 73,9 jämfört med 75,4. Den andra är att återinvestera den: noggrannheten ökar från 73,9 till 79,3 samtidigt som utgifterna fortfarande minskar. Storleken på respektive alternativ beror på hur intensivt företaget utnyttjar verktyget, vilket är den enda variabeln som vi inte kan ange. Fördelat på 250 arbetsdagar och 2 000 yrkesverksamma: 

Med åtta frågor per person och dag – en realistisk siffra för en advokatbyrå vars medarbetare verkligen förlitar sig på agenterna som en del av det dagliga arbetet – ger besparingen en återbäring på ungefär 940 000 dollar per år, återkommande, för en kapacitet som byrån redan har byggt upp. Å andra sidan ger en återinvestering 216 000 ytterligare rätta svar, samtidigt som byrån fortfarande tjänar cirka 371 000 dollar mer per år än idag. 

Den andra av dessa förtjänar särskild uppmärksamhet, eftersom den vänder upp och ner på den vanliga avvägningen. Noggrannhet i AI-system uppnås vanligtvis genom högre kostnader: en större modell, mer resonemang, mer informationshämtning – och allt detta kostar mer. Här är ordningen den omvända. Kontextlagret sänker först kostnaden för en fråga, och noggrannheten finansieras med intäkterna, så att ett företag avslutar året både med högrenoggrannhet ochi en bättreekonomiskställning – en kombination som sällan förekommer. 

Det viktigaste är dessutom exakt var en referensnivå blir svår. När ett system närmar sig taket för en frågeuppsättning är de svar som återstår de kostsamma: avstämningarna mellan flera dokument, frågorna vars svar förekommer en gång per femton miljoner tecken. Det är just dessa svar som ytterligare överväganden ger utdelning på. Ett företag som har frigjort budgetmedel har råd att satsa dem på just den delen; ett företag som inte har det, har inte råd. 

04 – Under ärendets hela handläggningstid

När situationen ständigt förändras

Allt ovanstående är en ögonblicksbild: man fryser situationen, skapar sammanhanget och ställer frågorna. Det är där de flesta jämförelser slutar, men så ser inte verkligheten ut i de flesta juridiska ärenden. Dokument kommer in, revideras, ersätts, och man måste bygga upp ett sammanhangsskikt och sedan underhålla det. 

Den första konsekvensen är att kontextvärdeskvoten bäst förstås som en kurva snarare än som ett enskilt tal. Kontexten skapas en gång per ärende; det värde den ger ackumuleras en gång per ställd fråga eller utförd uppgift. Ett ärende som avslutas snabbt, eller som en juridisk avdelning aldrig har anledning att granska, kommer inte att ge avkastning på investeringen, oavsett hur väl kontexten har utformats. När antalet frågor ökar sjunker den fördelade kostnaden för att skapa kontexten mot noll och kvoten närmar sig det värde för enbart besvarade frågor som redovisas ovan. Nyckelfrågan är därförden agentvolym som motsvarar break-even: det antal frågor som besvaras av agenter per ärende vid vilket den fullt belastade kvoten – uppbyggnadskostnaden tillsammans med svarskostnaden – når 1,0. Det är värt att lyfta fram detta eftersom det omvandlar en fråga som en byrå inte kan besvara – är kontextutformning värt det? – till en fråga som den kan besvara: hur intensivt ska vi arbeta med ett ärende? 

Tre variabler avgör den agentiska volymen vid break-even. Den första är kostnaden för att bygga upp kontextlagret, vilket beror på valet av modell och på den bearbetade textvolymen. Vi publicerar medvetet inte vår egen siffra: i våra tio ärenden varierade den ungefär sexfaldigt vid identiska inställningar, eftersom det är dokumenten som påverkar den snarare än något beslut från vår sida, och en enskild siffra som överförs från vårt korpus till ett annat företags skulle vara missvisande. Detta är den enda faktorn som ett företag måste mäta själv. Den andra är besparingen per fråga, vilket är vad jämförelsetalet mäter. 

Den tredje egenskapen förtjänar en närmare granskning: variationer i de tekniker som används för att bygga upp kontextlagret från början. Vissa metoder för kontextteknik hämtar till exempel sitt värde från en struktur som beräknas på ett sådant sätt att varje nytt dokument som läggs till eller ändras ogiltigförklarar det som redan byggts upp, och kostnaden upprepas varje gång ett dokument läggs in. Andra metoder är knutna till enskilda dokument, vilket innebär att ett nytt dokument medför ett arbetsbehov som står i proportion till dokumentets omfattning och lämnar allt som redan byggts upp orört. Under den första dagen kan dessa metoder för kontextutveckling verka identiska och kosta lika mycket; men under hela ärendets löptid, då dokument tas emot varje vecka, skiljer de sig markant åt. Ett förhållande som mäts på en fastställd datamängd ger en fördelaktig bild av ombyggnadsmodellen, så en byrå bör fastställa vilken typ den investerar i innan man jämför de övergripande siffrorna. 

Det finns en fjärde aspekt som det ovanstående resultatet med två nivåer belyser. Kostnaden för att bygga upp indexet och kostnaden för att besvara frågor behöver inte betalas på samma modellnivå. Att bygga upp ett index på dokumentnivå är en avgränsad, mekanisk uppgift – att läsa ett dokument, beskriva vad det innehåller och var – och det ligger ofta väl inom räckvidden för en kostnadseffektiv modell. Att besvara en juridisk fråga som spänner över ett ärende är ofta inte det. En byrå kan därför bygga upp sitt kontextlager med en ekonomisk modell och använda de besparingar som detta ger till en betydligt mer kapabel modell när det är dags att besvara frågor. 

Denna asymmetri har stor inverkan på den agentvolym som ger nollresultat, eftersom besparingen per fråga är proportionell mot priset på den modell som den svarande agenten använder, medan utvecklingskostnaden inte är det. 

Observera att den nuvarande versionen av Legal Context Engineering Benchmark inte mäter förändringar över tid, men vi har redan börjat testa utvidgningar av benchmarken som tar hänsyn till ärendekomplex som utvecklas i etapper, där varje dokument har sitt verkliga datum. Vi räknar med att rapportera om denna datamängd separat under de kommande månaderna. Under tiden gäller den allmänna slutsatsen: ett kontextlager är inte något som byggs upp en gång för alla, utan något som utvecklas över tid för att optimeras efter vad en advokatbyrå eller en juridisk avdelning värdesätter. 

05 – Inbjudan

Varför vi publicerar metoden

Det vi har beskrivit i denna rapport är inte bara den interna riktlinjen som styr utvecklingen av NetDocuments Legal Context Graph, utan även den metodik som ligger till grund för denna riktlinje – en metodik som vi hoppas att alla juridiska avdelningar och advokatbyråer kan utnyttja för att utvärdera investeringar i kontextlagret. 

För att tillämpa denna metod följer du helt enkelt de steg som beskrivs nedan.

1. Se till att din modell och din sele förblir oförändrade.
2. Skriv ner vilka typer av frågor era experter faktiskt ställer, och be någon med relevant kompetens att specificera vad ett fullständigt svar ska innehålla.
3. Ändra en teknik eller funktion inom kontextutveckling i taget.
4. Ange rätt svar före och efter.
5. Och läs gärna några av svaren själv innan du tror på siffrorna.
6. Om budgeten tillåter det, gör jämförelsen på flera olika modellnivåer – det är det billigaste sättet att ta reda på om det du har byggt upp är ett hinder eller en drivkraft.