samenvatting

Samenvatting

Drie factoren bepalen of een juridische AI-agent effectief is: hetonderliggende model,het omhulsel dateromheenis gebouwd(bijvoorbeeld juridisch-specifieke agenten zoals CoCounsel, Lexis+ met Protégé, Harvey, Legora en de eigen assistent van NetDocuments, of agents voor algemeen gebruik zoals ChatGPT of Claude), ende context waartoe hettijdens het werken toegang heeft — de documenten, de zoekopdracht waarmee ze worden gevonden, de kennisgrafiek die documenten met elkaar verbindt, en al het andere dat het kantoor over de zaak naar voren brengt. Er bestaan al een aantal kwaliteitsbenchmarks (zoals VLAIR van ValsenBigLaw Bench van Harvey) om de eerste twee factoren afzonderlijk of alle drie in hun totaliteit te meten. Maar voor zover wij weten, is er geen enkele die de impact en de economische aspecten van de contextlaag zelf afzonderlijk bekijkt – wat er verandert, zowel in de kwaliteit van de antwoorden als in de kosten, wanneer het model en de koppeling vastliggen en alleen de context varieert. 

Die kloof is van belang omdat elke factor — model, platform en context — zich in de loop van de tijd afzonderlijk ontwikkelt en bedrijven verschillende strategische kansen biedt. Modellen worden beter naarmate de bedrijven achter de fundamentele modellen vorderingen boeken. Platformen vormen een uiterst competitieve markt, en bedrijven gebruiken er vaak meerdere tegelijk of wisselen in de loop van de tijd tussen verschillende platforms naarmate het landschap verandert. De context is de laag die eenmalig wordt opgebouwd en bij elke modelupgrade en elke agent die een bedrijf implementeert, wordt meegenomen. Het is een van de weinige gebieden waarop de eigen investering van een bedrijf zich opstapelt in plaats van te worden gereset. 

Met dat in gedachten hebben we een benchmark ontwikkeld op basis van het eenvoudigste principe: houd het model en het harness constant, breng alleen wijzigingen aan in de contextlaag en meet wat er is veranderd op het gebied van nauwkeurigheid en kosten. Onze benchmark is bewust neutraalten aanzien van de vraag hoe de context preciesbeter zou moeten worden, aangezien rijkere metadata, nauwkeurigere zoekresultaten, aangepaste vaardigheden en een kennisgrafiek allemaal in aanmerking komen. 

Nauwkeurigheid alleen zou een verkeerde maatstaf zijn, omdat nauwkeurigheid bijna altijd kan worden gekocht door meer te investeren: een groter model, meer redeneringen, meer gegevensopvragingen. Elke eerlijke maatstaf voor een contextlaag moet daarom de kwaliteit die deze oplevert afwegen tegen de kosten die nodig zijn om die kwaliteit te verkrijgen. De eenheid waarvoor we hebben gekozen,is de kosten van een juist antwoord. De verandering in dat cijfer noemen wede Context Value Ratio (CVR). Toen we onze Legal Context Graph aan deze maatstaf toetsten, waren de resultaten doorslaggevend. Bijvoorbeeld:

Deze efficiëntie stelt bedrijven voor een keuze. Ze kunnen de besparingen opstrijken, ze herinvesteren in betere antwoorden, of beide doen. Een bedrijf dat tevreden is met de huidige nauwkeurigheid, kan de besparingen direct realiseren.Voor een bedrijf met 2.000 medewerkers dat vier miljoen vragen per jaar stelt, komt dat neer op een jaarlijkse besparing van ongeveer $940.000 bij ongewijzigde kwaliteit.Een bedrijf dat een betere nauwkeurigheid nastreeft, kan een deel van die efficiëntie herinvesteren. In de benchmark bespreken we een voorbeeld waarbij het verhogen van de redeneerinspanning van het model van gemiddeld naar hoog de nauwkeurigheid met 7% verbeterde, terwijl de kosten nog steeds 18% lager waren dan bij de basislijn. In de praktijk komt dat neer op 216.000 extra juiste antwoorden per jaar. Dit zijn geen gemakkelijke winsten: de antwoorden die een systeem nog niet goed heeft, zijn per definitie de moeilijke.

Hoewel die cijfers de aandacht trekken, gaat dit rapport diep in op de methodologie die eraan ten grondslag ligt: hoe en wat er gemeten moet worden met betrekking tot de juridische context, wat een verbetering van de kwaliteit van de antwoorden waard is in verhouding tot de kosten ervan, en waar verdere investeringen het meeste rendement opleveren. Het doel is om juridische afdelingen en advocatenkantoren een herbruikbaar kader te bieden om de impact van hun eigen contextlaag in de loop van de tijd te beoordelen. 

01 – Hoe het werkt

Hoe de LCEB — en het onderliggende raamwerk — werkt

De basisopzet van de Legal Context Engineering Benchmark is een gecontroleerde vergelijking met één enkele variabele. Eén agent – dat wil zeggen een vast model binnen een vaste testomgeving – beantwoordt dezelfde reeks vragen twee keer. Bij de eerste doorloop beschikt de agent alleen over de tools die een agent gewoonlijk tot zijn beschikking heeft: een zoekopdracht in de documenten van de zaak en de mogelijkheid om de tekst daarvan op te halen voor nader onderzoek. Bij de tweede doorloop beschikt hij over diezelfde hulpmiddelen en heeft hij bovendien toegang tot de verbeterde contextlaag die wordt getest (bijvoorbeeld een kennisgrafiek, betere metadatafilters, semantisch zoeken). Omdat het model, de instructies en de vragen bij beide doorlopen constant blijven, wordt elk verschil dat zich voordoet in de kwaliteit van de antwoorden of in de kosten waarschijnlijk rechtstreeks veroorzaakt door context engineering. 

Houd er rekening mee dat het moeilijker is om andere variabelen constant te houden dan het klinkt. Een toolbeschrijving die een agent zodanig stuurt dat deze de testdataset te nauwkeurig benadert, een aangepast systeembericht dat de agent aanstuurt om zich anders te gedragen, een zoekparameter die voor de ene kant is afgestemd en voor de andere kant ongewijzigd blijft: elk van deze factoren introduceert een tweede variabele, en elk daaruit voortvloeiend resultaat is dan niet langer een meting van de context. Ons interne testharnas vergelijkt daarom de twee tool-interfaces voordat een run begint, en kan niet doorgaan als ze op enig ander punt verschillen dan de beschikbaarheid van de Legal Context Graph zelf. 

De huidige versie van onze benchmark is gebaseerd op tien echte zaken – vijf transactiezaken en vijf proceszaken – die zijn samengesteld uit openbare regelgevingsdocumenten en gerechtelijke dossiers die geheel of gedeeltelijk buiten de afbakeningsperiode van de trainingsgegevens vallen van de modellen waarmee we hebben getest (dit helpt ervoor te zorgen dat de agents niet antwoorden op basis van hun trainingsgegevens, maar gedwongen worden om uitsluitend te vertrouwen op de inhoud van de testzaak). Samen bevatten de tien zaken 874 documenten en ongeveer 60 miljoen tekens: registratieverklaringen en volmachten die elk honderdduizenden tekens tellen, naast dossiers met moties, beschikkingen, transcripties van getuigenverklaringen en correspondentie. Niets in het documentcorpus is synthetisch gegenereerd; dit is een bewuste ontwerpkeuze die we hebben gemaakt. Keer op keer zagen we tijdens onze tests dat een synthetisch gegenereerde zaak die er van een afstand realistisch uitzag, bij nader inzien geen interne logica had of — erger nog — uitmondde in een onrealistische eenvoud. 

Elk onderdeel van het LCEB bevat ten minste vijfentwintig vragen — in totaal driehonderd over de tien onderdelen — en elk daarvan is een vraag die een jurist terecht zou stellen. Ze zijn bewust verdeeld over verschillende moeilijkheidsgraden en vraagtypes, en bij elke vraag staat aangegeven tot welk type deze behoort. 

De vragen worden opgesteld op basis van de brondocumenten door een reeks krachtige modellen in te zetten om elk document in een zaak volledig te doorlezen, wat vaak een enorm token-inefficiënte en kostbare onderneming is. De agents stellen vervolgens vraag-en-antwoordparen voor op basis van wat er tijdens deze diepgaande analyses naar voren komt. Elk paar bestaat uit drie delen: de vraag zelf, een referentieantwoord waarin wordt uiteengezet wat het dossier daadwerkelijk ondersteunt (inclusief bronvermeldingen), en een korte lijst met de specifieke elementen die een volledig antwoord moet bevatten; deze lijst vormt de beoordelingsrubriek voor die vraag. 

Ten slotte controleren we de antwoorden en beoordelingsschema’s aan de hand van deterministische validaties (bijvoorbeeld: komen de bronvermeldingen in het antwoord daadwerkelijk overeen met tekst in het documentcorpus?), evenals door middel van steekproeven door een menselijke materiedeskundige. 

De antwoorden die de agents tijdens de twee testruns hebben gegenereerd — bijvoorbeeld één keer met de Legal Context Graph ingeschakeld en één keer zonder — worden vervolgens beoordeeld door een krachtig model, dat de vraag, de criteria die daarop van toepassing zijn, het volledige gegenereerde antwoord en het overzicht van de toolaanroepen die de agent bij het opstellen ervan heeft gedaan, in ogenschouw neemt. 

Een run registreert twee dingen: of het antwoord juist was, en wat het heeft gekost om het te genereren. Elke aanroep die de agent doet, wordt geteld, en de bijbehorende tokens worden in drie categorieën ingedeeld — nieuwe invoer, in de cache opgeslagen invoer en uitvoer — omdat voor elk daarvan een ander tarief geldt. Die tarieven zijn de gepubliceerde prijzen voor het model dat het antwoord genereert, geldig op het moment van publicatie. Het resultaat is een bedrag in dollars. 

Houd er rekening mee dat, aangezien het modelbinnen eenvergelijking vast blijft, de vergelijking kan worden herhaald met een ander model en de resultaten naast elkaar kunnen worden bekeken. We hebben dit gedaan voor alle drie de leden van de GPT-5.6-familie, zodat alleen de capaciteiten veranderen en de prijsstructuur vergelijkbaar blijft: 

Alle drie hebben ze een kennisafsluitingsdatum van 16 februari 2026, waardoor de blootstelling aan het corpus tijdens de training voor alle drie identiek is. Alle drie zijn ze getest op dezelfde tien onderwerpen, dezelfde 300 vragen, dezelfde beoordelingscriteria, dezelfde backend voor live-documenten en dezelfde configuratie van het beoordelingssysteem. Het enige verschil tussen de drie scorekaarten die we later (in paragraaf 2) presenteren, is welk model de vragen heeft beantwoord. 

Er zijn twee redenen waarom deze aanvullende vergelijking de moeite waard is. Ten eerste wordt hiermee getoetst of een contextlaag een steunpilaar is voor zwakke modellen of juist een versneller voor sterke modellen — een onderscheid dat bepaalt of de investering de volgende modelupgrade overleeft. Ten tweede verdeelt CVR twee kosten die ophetzelfde modelworden gemeten, waardoor de prijs van het model zowel in de teller als in de noemer voorkomt en elkaar opheft. Wat na de opheffing overblijft, is precies wat we willen vergelijken: in hoeverre het gebruik van de contextlaag door elk model de kosten van een juist antwoord beïnvloedt. Daarom kunnen de drie ratio’s naast elkaar worden bekeken, ook al zijn de bijbehorende bedragen in dollars dat niet. 

02 – de meeteenheid

Wat een juist antwoord kost

Vroeger waren de kostenverschillen tussen verschillende agenten die op hetzelfde model draaiden in de meeste gevallen zo klein dat ze konden worden genegeerd. Toen een agent in één doorloop antwoord gaf, las en schreef hij slechts in beperkte mate; nu maakt hij plannen, roept hij hulpmiddelen op, leest hij, probeert hij het opnieuw en controleert hij zijn werk, en dat is inmiddels de grootste variabele kostenpost bij het draaien van het systeem geworden. Deze trend versnelt alleen maar. METR, dat zich richt op software- en onderzoekstaken in plaats van juridische taken, constateert dat de duur van een taak die een toonaangevende agent zonder hulp voltooit met een succespercentage van 50% inmiddels enkele uren bedraagt, en dat deze duur ongeveer elke vier maanden verdubbelt. 

Daardoor worden de kosten een meetbare grootheid, maar rijst ook de vraag in welke eenheid ze moeten worden gemeten. De kosten per zoekopdracht of per taak zijn het gemakkelijkst te berekenen, maar leveren het minste inzicht op, omdat het voor een juridisch professional uiteindelijk om het juiste antwoord gaat.De kosten per juist antwoord zijndaarom de maatstaf die we hebben gekozen: het totale bedrag dat aan een reeks zoekopdrachten is uitgegeven, gedeeld door het met het aantal juiste antwoorden gewogen aantal, wat een enkel cijfer in dollars oplevert waarbij lager beter is. 

Wat dat cijfer weergeeft, zijn de kostenvan het beantwoorden: elke modelaanroep die de agent doet bij het beantwoorden van een vraag of het uitvoeren van een taak. Het opbouwen van de context vormt op zich een aparte kostenpost, die één keer per zaak wordt berekend in plaats van één keer per vraag, en deze hoort thuis in het ‘fully-loaded’-overzicht dat in paragraaf 4 wordt besproken. 

Vervolgens:

De context-waarderatio geeft aan hoeveel keer goedkoper een juist antwoord wordt. Bij een waarde van 2,0 zorgt de contextlaag ervoor dat een juist antwoord de helft minder kost. Boven 1,0 levert het meer op dan het kost; bij 1,0 is het break-even; onder 1,0 kost het meer dan het oplevert. 

De ratio meeteen verandering, en dat is precies de vraag die een bedrijf zich stelt wanneer het een investering afweegt: is dit, gezien de huidige situatie, rendabel? Wat de ratio niet kan aangeven, is waar een bedrijf in eerste instantie staat. Daarom kijken we naast het CVR-cijfer altijd ook naar de kwaliteitsscore: in hoeverre de agent een volledig antwoord geeft, gemiddeld over alle vragen, op een schaal van 0 tot 100. 

Beide cijfers zijn absoluut essentieel, omdat een prijs altijd kan worden verbeterd door de inspanning te beperken in plaats van door verbetering, en de goedkoopste manier om de kosten van een juist antwoord te verlagen, is door te stoppen met het beantwoorden van vragen die moeilijk te beantwoorden zijn. Laten we eens kijken naar twee systemen die dezelfde honderd vragen moeten beantwoorden: 

De antwoorden van Systeem B kosten elk een derde minder, en Systeem B is het systeem dat geen enkel bedrijf zou willen hebben, aangezien het zestig van de honderd vragen onbeantwoord heeft gelaten. Op basis van de prijs alleen kunnen ze niet van elkaar worden onderscheiden. 

Dezelfde voorzichtigheid is geboden bij het vergelijken van twee verschillende systemen – of tussen verschillende documentensets – omdat een prijs het gemakkelijkst te verbeteren is als er nog ruimte over is in je benchmark: een systeem dat zes van de tien vragen beantwoordt, kan overal goedkoop verbeterd worden, terwijl een systeem dat al negen van de tien vragen beantwoordt, veel moet investeren voor elk resterend punt. De verhouding is het meest betrouwbaar wanneer deze wordt afgezet tegen de eigen eerdere uitgangswaarde van een bedrijf – dezelfde onderwerpen, dezelfde vragen, zowel met als zonder de contextlaag. 

Dat is de methode in zijn geheel. Het resultaat is de onderstaande reeks scorekaarten. Laten we er eens dieper op ingaan. 

03 – In de praktijk brengen

Wat de besparingen voor een bedrijf waard zijn

Een ratio zoals de Context Value Ratio is in theorie nuttig, maar wat voor advocatenkantoren en juridische afdelingen echt van belang is, is hoe ze deze in de praktijk kunnen brengen: hetzij om hun bedrijfsvoering te verbeteren, hetzij om de kwaliteit van hun juridische dienstverlening naar een hoger niveau te tillen. In dit hoofdstuk komt precies dat aan bod. 

Stel je een groot kantoor voor — 2.000 juristen met toegang tot een juridische AI-assistent — en vraag je af wat de Legal Context Graph hen in een jaar tijd oplevert. Er zijn drie configuraties die van invloed zijn op deze vraag, en we hebben ze alle drie gemeten aan de hand van het frontier-model op basis van dezelfde 300 vragen: 

De eerste twee rijen tonen het benchmarkresultaat van paragraaf 2, uitgedrukt per vraag: de contextlaag waarborgt kwaliteit en halveert de prijs. De derde rij staat centraal in het onderwerp van deze paragraaf. Nadat een kantoor de kosten van een vraag met bijna de helft heeft verlaagd door gebruik te maken van de Legal Context Graph, hoeft het die besparing niet letterlijk in contanten te realiseren. In plaats daarvan kan het een deel van die besparingen „herinvesteren“ in configuraties van agent-harnassen die de nauwkeurigheid verhogen — een groter model, een ruimer redeneringsbudget, een bredere informatieverzameling. Voor dit voorbeeld nemen we de eenvoudigste optie: het verhogen van de redeneringsinspanning van het modelvan „gemiddeld“ naar „hoog“, waardoor dezelfde agent langer over elke vraag kan nadenken, uitgebreider kan redeneren, meer kan verifiëren en verder kan lezen. 

Wat die upgrade betaalbaar maakt, is de contextlaag. Het verhogen van de redeneringsinspanning kost ongeveer 1,5× meer per vraag, ongeacht of de Graph aanwezig is of niet. Toegepast op de basislijn zonder ondersteuning zou dit de uitgaven van het bedrijf met ongeveer de helft doen stijgen. Toegepast bovenop een vraagprijs die al gehalveerd is, zorgt dezelfde upgrade ervoor dat het bedrijf18% minderuitgeeftdannu het geval is. De nauwkeurigheid wordt dus verkregen met uitgaven die het bedrijf al had begroot. 

Een bedrijf staat dus voor een echte strategische keuze in plaats van een financieringsverzoek, aangezien geen van beide opties vereist dat er ook maar één dollar meer wordt uitgegeven dan nu het geval is. De eerste optie is om de besparing opzij te zetten en de kwaliteit op hetzelfde niveau te houden: 73,9 tegenover 75,4. De tweede optie is om het bedrag te herinvesteren: de nauwkeurigheid stijgt van 73,9 naar 79,3, terwijl de uitgaven nog steeds dalen. De omvang van beide scenario’s hangt af van de mate waarin het bedrijf de tool inzet – de enige variabele die wij niet kunnen aangeven. Over 250 werkdagen en 2.000 professionals: 

Bij acht vragen per persoon per dag — een realistisch aantal voor een advocatenkantoor waarvan de professionals daadwerkelijk op agents vertrouwen als dagelijkse werkpartner — levert het opzijzetten van deze besparing ongeveer $940.000 per jaar op, een terugkerende opbrengst voor een capaciteit die het kantoor al heeft opgebouwd. Aan de andere kant levert herinvestering 216.000 extra juiste antwoorden op, waarbij het kantoor nog steeds zo’n 371.000 dollar per jaar beter af is dan nu het geval is. 

Het tweede punt verdient bijzondere aandacht, omdat het de gebruikelijke afweging omkeert. Nauwkeurigheid in AI-systemen wordt doorgaans bereikt door meer uitgaven: een groter model, meer redeneringen, meer gegevensopvraging – en dat kost allemaal meer. Hier is de volgorde omgekeerd. De contextlaag verlaagt eerst de prijs van een vraag, en de nauwkeurigheid wordt gefinancierd uit de opbrengsten, zodat een bedrijf het jaar zowel nauwkeurigerals financieelsterker afsluit — een combinatie die zelden voorkomt. 

Bovendien is het vooral van belang waar precies de grens van een benchmark ligt. Naarmate een systeem de bovengrens van een vragenreeks nadert, zijn de antwoorden die nog openstaan juist de kostbare: de afstemmingen tussen meerdere documenten, de vragen waarvan het antwoord slechts één keer per vijftien miljoen tekens voorkomt. Dat zijn precies de antwoorden die verdere analyse oplevert. Een bedrijf dat budget heeft vrijgemaakt, kan het zich veroorloven dat aan die ‘staart’ te besteden; een bedrijf dat dat niet heeft gedaan, kan dat niet. 

04 – Gedurende de looptijd van een zaak

Als de situatie steeds verandert

Al het bovenstaande is een momentopname: de situatie vastleggen, de context opbouwen, de vragen stellen. Daar houden de meeste benchmarks op, maar zo ziet de realiteit van de meeste juridische zaken er niet uit. Documenten komen binnen, worden herzien, worden vervangen, en er moet een contextlaag worden opgebouwd en vervolgens onderhouden. 

Het eerste gevolg is dat de Context Value Ratio beter kan worden gezien als een curve dan als een enkel getal. De context wordt één keer per zaak opgebouwd; de waarde die deze oplevert, wordt één keer per gestelde vraag of uitgevoerde taak gegenereerd. Een zaak die snel wordt afgesloten, of waarover een juridisch team nooit aanleiding heeft om vragen te stellen, zal de investering niet terugbetalen, hoe goed de context ook is opgezet. Naarmate het aantal vragen toeneemt, dalen de over die vragen afgeschreven opbouwkosten naar nul en nadert de verhouding het hierboven gerapporteerde cijfer voor ‘alleen beantwoorden’. De kernvraag is daaromhet break-even-volume per medewerker: het aantal vragen dat medewerkers per zaak beantwoorden waarbij de totale ratio — opbouwkosten samen met beantwoordingskosten — 1,0 bereikt. Het is de moeite waard om dit apart te bekijken, omdat het een vraag die een kantoor niet kan beantwoorden — is het opbouwen van context de moeite waard? — omzet in een vraag die het wel kan beantwoorden: hoe intensief werken we aan een zaak? 

Drie variabelen bepalen het break-even-volume voor agentische verwerking. De eerste is de kostprijs voor het opbouwen van de contextlaag, die wordt bepaald door de keuze van het model en door de hoeveelheid verwerkte tekst. We publiceren bewust geen eigen cijfer: bij onze tien zaken varieerde dit bij identieke instellingen met een factor zes, omdat dit wordt bepaald door de documenten zelf en niet door een beslissing van ons, en omdat één enkel getal dat van ons corpus naar dat van een ander kantoor wordt overgenomen, misleidend zou zijn. Dit is de enige input die een kantoor zelf moet meten. De tweede is de besparing per vraag, en dat is wat de benchmark meet. 

Het derde kenmerk verdient nadere bestudering: de variaties in de technieken die worden gebruikt om de contextlaag in de eerste plaats op te bouwen. Sommige benaderingen van context engineering ontlenen hun waarde bijvoorbeeld aan een structuur die zo is berekend dat elk nieuw toegevoegd of gewijzigd document hetgeen al was opgebouwd ongeldig maakt, en dat de kosten telkens opnieuw worden gemaakt wanneer er een document binnenkomt. Andere benaderingen zijn gekoppeld aan individuele documenten, zodat een nieuw document een werklast met zich meebrengt die evenredig is aan het document zelf en alles wat al is opgebouwd onaangetast laat. Op dag één kunnen deze context engineering-tactieken identiek lijken en evenveel kosten; gedurende de looptijd van een zaak waarbij wekelijks documenten binnenkomen, lopen ze echter sterk uiteen. Een verhouding gemeten op een ‘bevroren’ corpus doet het ontwerp voor het opnieuw opbouwen in een gunstig daglicht staan, dus een kantoor zou moeten vaststellen in welk type het investeert alvorens de hoofdcijfers te vergelijken. 

Er is nog een vierde overweging die door het bovenstaande tweeledige resultaat naar voren komt. De opbouwkosten en de antwoordkosten hoeven niet op hetzelfde modelniveau te worden betaald. Het opbouwen van een index op documentniveau is een begrensde, mechanische taak — een document lezen, beschrijven wat erin staat en waar — en valt vaak ruimschoots binnen de mogelijkheden van een voordelig model. Het beantwoorden van een juridische vraag binnen een zaak is dat vaak niet. Een kantoor kan daarom zijn contextlaag opbouwen met een economisch model en de daarmee gerealiseerde besparingen besteden aan een veel krachtiger model op het moment dat er vragen moeten worden beantwoord. 

Die asymmetrie heeft een grote invloed op het break-even-volume van de agent, omdat de besparing per vraag evenredig is met de prijs van het model dat door de beantwoordende agent wordt gebruikt, terwijl de ontwikkelingskosten dat niet zijn. 

Houd er rekening mee dat de huidige versie van de Legal Context Engineering Benchmark geen veranderingen in de loop van de tijd meet, maar we zijn al begonnen met het testen van uitbreidingen op de benchmark waarin rekening wordt gehouden met reeksen zaken die zich in fasen ontvouwen, waarbij elk document zijn eigen datum uit de praktijk draagt. We verwachten de komende maanden apart verslag uit te brengen over deze dataset. In de tussentijd blijft het algemene punt gelden: een contextlaag is niet iets dat eenmalig wordt opgebouwd, maar wordt in de loop van de tijd verder ontwikkeld om deze af te stemmen op wat een advocatenkantoor of juridische afdeling belangrijk vindt. 

05 – De uitnodiging

Waarom we de methode publiceren

Wat we in dit rapport hebben beschreven, is niet alleen de interne maatstaf die als leidraad dient voor de ontwikkeling van de Legal Context Graph van NetDocuments, maar ook de methodologie die aan die maatstaf ten grondslag ligt — een methodologie waarvan we hopen dat elke juridische afdeling of elk advocatenkantoor er gebruik van kan maken om investeringen in de contextlaag te beoordelen. 

Om deze methode toe te passen, hoeft u alleen maar de beschreven stappen te volgen.

1. Houd je model en je harnas op dezelfde manier vast.
2. Schrijf op wat voor soort vragen uw deskundigen daadwerkelijk stellen, en laat iemand met de juiste kwalificaties aangeven wat een volledig antwoord precies inhoudt.
3. Pas telkens slechts één techniek of vaardigheid op het gebied van contextengineering aan.
4. Geef voor en na de prijs van het juiste antwoord.
5. En lees zelf eerst een paar antwoorden door voordat je die cijfers zomaar voor waar aanneemt.
6. Als het budget het toelaat, voer de vergelijking dan uit voor meer dan één modelcategorie — dat is de goedkoopste manier om erachter te komen of wat je hebt ontwikkeld een belemmering of juist een stimulans is.