Grensverleggende systemen voor diepgaand onderzoek bouwen in 2026

Een praktische blik op de data, orkestratie en evaluatie die nodig zijn om in 2026 systemen voor diepgaand bedrijfsonderzoek te bouwen.

Hoewel velen diepgaand onderzoek individueel hebben kunnen gebruiken om online informatie te zoeken en samen te vatten, hebben maar weinig mensen er binnen een bedrijfscontext van geprofiteerd. Dat komt niet doordat het niet nuttig zou zijn — integendeel — maar door bredere zorgen over betrouwbaarheid, uiteenlopende databronnen en het vermogen van een model om grote hoeveelheden context te verwerken, zoals enorme aantallen verschillende bestandstypen.

Onze ervaringen met het bouwen van professionele tools voor diepgaand onderzoek in de afgelopen twaalf maanden laten zien dat doordachte engineering deze zorgen steeds beter kan wegnemen. In dit blog bespreken we de voornaamste obstakels voor effectieve toepassingen van diepgaand onderzoek in bedrijven, hoe wij die zouden overwinnen en hoe dit domein zich volgens ons in 2026 zal ontwikkelen.

Samenvatting voor bestuurders: de stand van diepgaand onderzoek in bedrijven in 2026

  • De grens van wat uitvoerbaar is, is spectaculair opgeschoven. De komst van gpt-5 in augustus 2025 betekende een omslagpunt voor AI in het bedrijfsleven. In onze productiesystemen, waaronder een platform voor het ontdekken van aangrijpingspunten voor geneesmiddelen voor een van de grootste farmaceutische bedrijven ter wereld, zagen we bronhallucinaties dalen van 3 à 4% naar vrijwel nul. In december vergrootte gpt-5.2 vervolgens de effectieve contextlengte verder. Het praktische resultaat: we kunnen nu per onderzoeksronde opschalen van honderden naar duizenden bronnen, zonder aan betrouwbaarheid in te boeten. Het knelpunt is verschoven van de capaciteiten van het model naar waar het thuishoort: uw data, uw evaluaties en uw programmaontwerp.

  • Datastrategie: bereikbaar is beter dan uniform. De neiging om AI voor bedrijven als een probleem van data-integratie te zien, is begrijpelijk maar vaak contraproductief. Volledige uniformering is traag en politiek gevoelig, en dwingt u voortijdig een richting te kiezen voordat u weet welke vragen er werkelijk toe doen. De pragmatische keuze in 2026 is beperkte connectiviteit. Maak data bereikbaar via waardevolle ankerpunten (specificaties, beleid, SKU's, contractbepalingen) in plaats van jaren te wachten tot alles is samengevoegd. Grensverleggende modellen kunnen systemen nu tijdens inferentie 'zacht koppelen' en verwante termen verbinden zonder formele toewijzingen. U behoudt de snelheid van implementatie en de flexibiliteit om later bronnen toe te voegen.

  • Navigatie voorkomt afdwalen. Bedrijfsdata zijn niet hetzelfde als het web. Ze zijn schaars, zitten vol lokale conventies en hebben voor een bepaald feit vaak precies één juiste bron. Zonder begeleiding blijven modellen vaak eindeloos zoekopdrachten uitvoeren om nog één bron te vinden, ten koste van de responstijd en het geduld van gebruikers. Een lichte semantische laag (hashtabellen, entiteitszoekopdrachten, eenvoudige relatiegrafen) biedt het systeem snelle, goedkope routes naar de juiste context. Zie het als het advies van een ervaren collega aan een nieuwe medewerker: "Bookmark deze sites en praat met Ross als je problemen hebt met AWS." Het hoeft niet ingewikkeld te zijn. Het hoeft het systeem alleen te helpen snel te vinden wat het nodig heeft.

    • Mechanisch (bij elke zoekopdracht): kwaliteit van bronverwijzingen, correct toolgebruik, latentie en kosten. Dit zijn uw vangrails: alledaags, maar onmisbaar.

    • Analytisch (periodiek): kiest het systeem de juiste tools, volgt het zinvolle onderzoeksrichtingen, selecteert het gezaghebbende bronnen en weet het wanneer het moet stoppen? Doorgaans beoordeeld met een LLM-as-judge-methode aan de hand van gelabelde voorbeelden.

    • Gebruiker (doorlopend): voltooiingspercentages van taken, kwalitatieve feedback van intensieve gebruikers en gebruiksanalyses. De ultieme test. Hebben we iets gebouwd dat mensen nuttig vinden?

  • Rendement komt voort uit moeilijke, niet uit veilige problemen. Na berichten dat de meeste AI-projecten in het bedrijfsleven geen rendement opleveren, is er geen geduld meer voor indrukwekkende demo's die nooit in productie gaan. Bestuurders willen bewijs, en wel snel. Die druk kan teams paradoxaal genoeg tot de verkeerde keuzes aanzetten. De verleiding is groot om met taken met weinig risico te beginnen, omdat die gemakkelijk te implementeren zijn en waarschijnlijk niemand voor het hoofd stoten. Maar deze toepassingen leveren zelden genoeg op om verdere investeringen te rechtvaardigen. Systemen voor diepgaand onderzoek in bedrijven kunnen hun waarde goed bewijzen, omdat ze zich richten op werk dat al duur is: complexe workflows met grote belangen, waarbij de kosten van de huidige werkwijze zichtbaar zijn. De krachtigste toepassingen die we hebben gezien, zijn onder meer het opstellen van RFP's en offertes, analyse van het wetenschappelijke landschap en beleggingsonderzoek: domeinen waar impact wordt gemeten in winstpercentages, snellere routes naar klinische proeven en sneller overtuigde besluitvorming, niet alleen in bespaarde uren.

  • De UX-verschuiving: van chatten naar delegeren, van antwoorden naar eindproducten. Volgens ons is dit een van de veranderingen in de gebruikerservaring die 2026 zullen bepalen. Bij de recente oplossingen met de grootste acceptatie vallen een paar dingen op. Nu deze systemen betrouwbaarder zijn geworden, behandelen gebruikers ze minder als een chatbot waaraan ze vragen stellen en meer als een analist aan wie ze werk delegeren. Twee zaken maken dit mogelijk: teams kunnen sjablonen en stopcriteria afstemmen op hun workflows, en rechtstreeks exporteren naar de werkelijk benodigde indeling (een memo, presentatie, briefing enzovoort), in plaats van zelf uit een chatgesprek een eindproduct te moeten samenstellen. Als beide geregeld zijn, is het systeem niet langer een naslagwerk, maar de manier waarop het werk wordt uitgevoerd.

Diepgaand onderzoek in bedrijfsdata blijft een belangrijk aandachtspunt

Vorig jaar schreven we over de introductie van diepgaand onderzoek in het bedrijfsleven. We namen het oorspronkelijk door OpenAI gepopulariseerde, webgerichte paradigma voor diepgaand onderzoek en breidden dit uit naar bedrijfseigen databronnen, zonder verlies van herkomstinformatie of controle. We benadrukten ook dat systemen voor diepgaand onderzoek niet als een breuk met klassieke RAG-systemen moeten worden gezien, maar als een evolutie daarvan.

Richting 2026 is niet zozeer het idee van diepgaand onderzoek veranderd, maar vooral de grens van wat uitvoerbaar is.

Toen we deze systemen begin 2025 begonnen te bouwen, waren o1, gpt-4o en claude-3.5-sonnet grensverleggende modellen — we hebben in twaalf maanden echt een lange weg afgelegd — gevolgd door grote stappen met modellen als o3 en gemini-2.5-pro in de eerste maanden van het jaar. Ze waren destijds uitstekend en maakten tot op zekere hoogte zeker robuuste toepassingen voor diepgaand onderzoek mogelijk. Die grens lag doorgaans bij enkele honderden bronnen. Daarna moest de context fors worden uitgedund, anders betaalde u de prijs in de vorm van een onnauwkeurig antwoord, gebrekkige naleving van instructies of regelrechte hallucinaties.

Als u zulke systemen hebt gebouwd, herkent u waarschijnlijk enkele van deze foutpatronen.

Een concreet voorbeeld: medio 2025 begonnen we met een van de grootste farmaceutische bedrijven ter wereld een oplossing voor diepgaand bedrijfsonderzoek te bouwen. Dit systeem versnelt het ontdekken van aangrijpingspunten voor geneesmiddelen, waarbij onderzoekers zoeken naar genen, hormonen of andere onderdelen van het menselijk lichaam waarop een behandeling kan aangrijpen. Het krachtigste beschikbare model was destijds o3. Hoewel dit model sterk presteerde, bevatte 3 à 4% van de antwoorden bronnen die niet via toolaanroepen uit de bedrijfseigen databronnen van de klant aan het model waren verstrekt. We beperkten dit met broncontroles achteraf, die delen van antwoorden markeerden die niet door de aangeleverde context werden ondersteund. In de vroege proof-of-conceptfase hielp dit om het vertrouwen van belanghebbenden in de tool op te bouwen en snel vooruitgang te boeken. We bleven echter proberen deze fouten terug te dringen, door de beperkingen van de modellen te ondervangen en tegelijk tegemoet te komen aan verzoeken van belanghebbenden om meer bronnen aan het systeem toe te voegen.

Een belangrijk omslagpunt voor grensverleggende oplossingen voor diepgaand onderzoek — en meer algemeen voor agentische oplossingen — kwam met de introductie van gpt-5 in augustus. Nadat we o3 door gpt-5 hadden vervangen, bleek uit onze evaluaties dat het percentage bronhallucinaties onmiddellijk naar 0% daalde.

Om precies te zijn: deze maatstaf houdt uitsluitend bij of het model een document-ID of URL noemt die niet in de opgehaalde context voorkwam. In het tijdperk van o3 en daarvoor verzonnen modellen soms aannemelijk klinkende bestandsnamen of publicaties om kennishiaten op te vullen. Met gpt-5 konden we dit specifieke probleem vrijwel volledig elimineren.

Dit verschilt van getrouwheidsfouten, waarbij het juiste document wordt aangehaald maar de tekst verkeerd wordt geïnterpreteerd. Dat blijft een uitdaging die we met de eerder genoemde controles achteraf beheersen.

Dit nam een enorme belemmering weg. Vervolgens begonnen we het systeem te testen om te zien hoe ver we het met de nieuwe generatie modellen konden opschalen. We konden het aantal bronnen per ronde voor diepgaand onderzoek ongeveer vertienvoudigen tot circa 3.000 à 5.000. De uiteindelijke grens lag niet bij gebrekkige naleving van instructies, maar bij prestaties met lange context. De effectieve contextlengte van modellen is vaak veel kleiner dan opgegeven, vooral bij bijvoorbeeld compacte farmaceutische data.

Deze beperking werd gedeeltelijk weggenomen met de release van gpt-5.2 medio december. Onze interne benchmarks voor lange context lieten een sterke verbetering van de effectieve prestaties zien, waardoor we onze grensverleggende systemen voor diepgaand onderzoek nog verder konden opschalen. Daardoor konden we uiteindelijk meer tokens rechtstreeks doorgeven aan het model dat de uitvoer voor de gebruiker produceert, wat een rijker antwoord oplevert. Toch hopen we dat de effectieve contextlengte van grensverleggende modellen in 2026 verder blijft toenemen.

Dankzij deze vooruitgang in de basiscapaciteiten van modellen zijn de knelpunten bij het bouwen van krachtige systemen voor diepgaand onderzoek in veel opzichten teruggekeerd naar waar ze altijd al hoorden: uw data, uw evaluaties en de manier waarop u uw programma voor diepgaand onderzoek binnen uw bedrijf inricht. Bij elk van deze stappen moet u pragmatische keuzes maken over wat werkelijk verschil maakt bij de ontwikkeling van diepgaand onderzoek.

In de rest van dit artikel leggen we uit hoe wij over die beslissingen denken.

Uw data op orde brengen

Het kan verleidelijk zijn om onderzoeksprojecten voor bedrijven als een probleem van data-integratie te behandelen. Voeg de bronnen samen, normaliseer het schema en laat de modellen erop los.

Voor alle duidelijkheid: soms is dat precies de juiste aanpak. Als u actief bent in een domein waarin de kernentiteiten stabiel en de zoekopdrachten herhaalbaar zijn, en u uiteindelijk de workflow wilt industrialiseren, kan uniformering veel opleveren. Klassieke voorbeelden zijn koppelingen tussen klant- en omzetdata, marktprijsdata en alles waarvoor betrouwbare rapportage over meerdere systemen nodig is.

In de praktijk zoeken de innovatieve leiders van vandaag echter iets anders in systemen voor diepgaand bedrijfsonderzoek.

Nu er steeds meer aandacht is voor het rendement van AI-uitgaven, willen besluitvormers vooral snel waarde aantonen binnen de rommelige werkelijkheid van de bedrijfsvoering. Volledige uniformering van databronnen is een van de langzaamste manieren om tot dat eerste bewijs te komen. Het is zwaar. Het wordt politiek. En vaak dwingt het u een richting te kiezen voordat u hebt geleerd welke vragen er werkelijk toe doen.

Daarom is volgens ons het pragmatische uitgangspunt voor grensverleggende systemen voor diepgaand onderzoek in 2026 meestal: maak uw data eerst bereikbaar en pas daarna fraai.

Diagram waarin volledig samengevoegde databronnen worden vergeleken met zachte koppelingen op basis van LLM's voor diepgaand bedrijfsonderzoek.

Als u in de loop van de tijd waarschijnlijk meer bronnen toevoegt, zoals bij de meeste bedrijven, worden beperktere verbindingen onderschat. U kunt tientallen bronnen via één consistente zoekinterface ontsluiten. Het systeem kan nog steeds functioneren en, belangrijker nog, u behoudt het vermogen om snel te leveren. Wanneer u meer bronnen toevoegt, hoeft u niet alles overhoop te halen. U sluit simpelweg een nieuwe connector aan, legt het kernsysteem uit wat die is en hoe die moet worden gebruikt, en laat de modellen het verder afhandelen. Dit werkt doordat grensverleggende modellen tegenwoordig tijdens inferentie twee of meer databronnen zacht kunnen koppelen. Zo verbinden ze "Klant-ID" in het ene systeem met "Klantreferentie" in het andere, zonder dat iemand een formele toewijzing schrijft. Wij zijn niet het enige team dat er zo over denkt. Wij zijn niet het enige team dat er zo over denkt: de interne data-agent van OpenAI is ontworpen om modellen over 70.000 heterogene datasets te laten redeneren door context en verbindingen tijdens de zoekopdracht bereikbaar te maken, in plaats van vooraf volledige uniformering af te dwingen.

Een belangrijke nuance is dat beperkt niet hetzelfde hoeft te zijn als oppervlakkig.

Beperkte integratie werkt het best als de verbindingen die u wél legt betekenisvol zijn en zodanig worden uitgedrukt dat het systeem ze gemakkelijk kan benutten. Een goede benadering is om bepaalde informatie als ankerpunten te behandelen, zoals specificaties, beleid, productdefinities, SKU's en contractbepalingen. U hoeft niet elke dataset samen te voegen om deze ankerpunten krachtig te maken; een stabiele identificatiecode met enkele waardevolle verbindingen volstaat.

Stel bijvoorbeeld dat een model of gebruiker een specificatie opzoekt. In een naïef systeem eindigt de interactie daar. U haalt de specificatie op, vat die samen en verwijst er misschien naar. Bij het bouwen van nuttige datastructuren willen we die zoekopdracht echter omzetten in het begin van een beheerste uitbreiding. We kunnen de registratie van die specificatie bijvoorbeeld optioneel koppelen aan historisch relevante eindproducten. "Relevant" kan hier verschillende dingen betekenen, maar wordt doorgaans bepaald door de taak van het systeem. Het kan gaan om RFP's die naar de specificatie verwezen, eerdere antwoorden waarmee offertes voor die specificatie werden gewonnen, wijzigingsvoorstellen waarbij de juridische afdeling bezwaar maakte, enzovoort. Deze aanpak kan de kwaliteit en snelheid van antwoorden enorm verbeteren doordat de belangrijkste inzichten tijdens de zoekopdracht snel aan het systeem voor diepgaand onderzoek worden aangeboden.

Dat leidt tot de volgende vraag: als u een wereld van losjes verbonden databronnen met enkele waardevolle verbindingen hebt, hoe voorkomt u dan dat het systeem voor diepgaand onderzoek ronddwaalt als een kind in een snoepwinkel en zorgt u dat het navigeert als een ervaren analist?

Uw LLM door uw data helpen navigeren

Bedrijfsdatabronnen gedragen zich niet zoals het web. Ze zijn schaars, zitten vol lokale conventies en hebben voor een bepaald feit vaak precies één "juiste" bron, als u die kunt vinden. Bovendien proberen modellen bij zoekvragen tegenwoordig vaak de recall te maximaliseren. Ze blijven zoekopdrachten uitvoeren om nog één bron te vinden, ten koste van de responstijd en het geduld van gebruikers. Zorgvuldige prompting kan dit enigszins beperken.

De effectiefste oplossing is een lichte tool die het model helpt zich te oriënteren in het rommelige bedrijfsdatalandschap. Sommige teams noemen dit een ontologie. Andere noemen het een semantische laag, zoekservice, graaf of conceptenarchief. De naam doet er niet echt toe.

Wat telt, is dat het systeem hiermee over snelle, goedkope routes beschikt, zodat het model efficiënt tussen de juiste contextdelen kan springen in plaats van eindeloos rond te dwalen.

Een eenvoudige vergelijking: u bent net bij een nieuw bedrijf of project begonnen en uw nieuwe collega's zeggen: "Bookmark these sites, you'll use them all the time," of "any time you have an issue with AWS just speak to Ross, he'll get you the info you need," enzovoort. Ook hier proberen we het systeem voor diepgaand onderzoek simpelweg te helpen snel te vinden wat het nodig heeft.

Diagram waarin naïeve datanavigatie wordt vergeleken met een navigatielaag die rijkere context ophaalt voor diepgaand bedrijfsonderzoek.

In de praktijk hoeft dit systeem niet ingewikkeld te zijn of handmatig te worden onderhouden. De beste implementaties die we hebben gevonden, worden tijdens de gegevensinvoer door LLM's gegenereerd, waarbij entiteiten worden geëxtraheerd om de graaf automatisch te vullen, of sturen aanvragen eenvoudig door naar bestaande bronsystemen, zoals een zoekopdracht via de Salesforce-API. Enkele veelvoorkomende voorbeelden:

  • Zoekopdrachten in hashtabellen, bijvoorbeeld zoeken op productnaam en de productbeschrijving teruggeven

  • Een eenvoudige zoekfunctie voor "veelvoorkomende" relaties, bijvoorbeeld: dit gen is in onze graaf met causale genrelaties het vaakst met deze ziekten verbonden

  • Modellen voor herkenning van benoemde entiteiten, vooral nuttig in domeinen met complexe problemen rond het onderscheiden van entiteiten, zoals de farmaceutische sector

  • Voor de ingewikkeldste datarelaties kunnen lichte RDF-grafen de meest uitbreidbare oplossing voor een ontologie bieden

  • … en meer

Zodra dit is ingericht, kan het systeem efficiënt door uw databronnen bewegen. De volgende vraag is eenvoudig: hoe weet u of het bij echt gebruik consequent het juiste doet?

Evalueren, evalueren, evalueren

Nu uw data bereikbaar zijn en uw navigatielaag de kaart levert, kan uw systeem het werk uitvoeren. Maar in een bedrijfscontext is capaciteit zonder betrouwbaarheid niets waard.

Hier bevindt zich het grootste kerkhof van AI-projecten. Veel teams zijn in de val van evaluaties "op gevoel" gelopen. Ze voerden een zoekopdracht uit, lazen de uitvoer, knikten goedkeurend en brachten het systeem uit. Deze aanpak werkt niet bij een systeem voor diepgaand onderzoek dat autonoom 5.000 documenten kan doorzoeken om advies te geven over een miljoenenbesluit in de toeleveringsketen.

De belangrijke omslag is dat u niet langer een model evalueert, maar een systeem. Vraaginterpretatie, planning, toolaanroepen, interpretatie, het uitdunnen van context, herrangschikking en zelfs ogenschijnlijk saaie connectordetails zoals tijdstempels komen allemaal terug in de gebruikerservaring.

Gestructureerde, herhaalbare evaluaties helpen ons deze problemen op te lossen.

Bij het ontwikkelen van evaluaties kunnen we grofweg drie categorieën onderscheiden, van mechanisch tot subjectief.

1. Het mechanische niveau (de vangrails)

Dit onderdeel lijkt het meest op unittests en is vaak waar teams in het begin het snelst vooruitgang boeken. Deze evaluaties zijn doorgaans ook het stabielst: zodra ze zijn ingericht, blijven ze gedurende de hele looptijd van het project waarde opleveren.

"Mechanische evaluaties" zijn doorgaans controles die zonder menselijke tussenkomst bij elke zoekopdracht kunnen worden uitgevoerd. Ze geven ons vertrouwen dat het systeem zich bij daadwerkelijke gebruikersbelasting voorspelbaar en veilig gedraagt.

Enkele voorbeelden:

  • Kwaliteit van bronverwijzingen: verwijzen alle citaten naar tekstpassages die daadwerkelijk zijn opgehaald? Zijn er beweringen zonder bronvermelding? Zijn er beweringen die niet door het bronmateriaal worden ondersteund? Zijn bronverwijzingen te algemeen, bijvoorbeeld een heel document als bron voor één bewering?

  • Correct toolgebruik: heeft het systeem alle tools gebruikt die het naar eigen zeggen heeft gebruikt? Heeft het de navigatietools correct gebruikt? Heeft het toolaanvragen verkeerd opgemaakt? Heeft het bij fouten op een verstandige manier nieuwe pogingen gedaan?

  • Limieten voor latentie en kosten: bleef het binnen de beoogde tijd tot het eerste token? Overschreed het het verwachte aantal toolaanroepen of budget? Vergde het veel wachttijd en rekenkracht voor een marginale verbetering?

Dit klinkt alledaags, maar juist dit soort tests voorkomt dat een bedrijfssysteem langzaam aftakelt.

Een praktijkvoorbeeld: binnen het project voor diepgaand onderzoek naar aangrijpingspunten voor geneesmiddelen gebruikten we twee lagen met broncontroles die bij elke zoekopdracht worden uitgevoerd. Ten eerste instrueren we het model om bij het genereren van een antwoord regelmatig bronverwijzingen in de tekst op te nemen. Dat LLM's dit betrouwbaar kunnen, is eveneens een vrij recent verschijnsel dat in de eerste helft van 2025 opkwam. Wie dit eerder met aanzienlijke hoeveelheden data probeerde, weet hoe lastig het toen was. Zo kunnen we met enkele eenvoudige regex-controles bijvoorbeeld nagaan of er een artikellink wordt genoemd die niet in de aangeleverde bronnen stond.

De tweede controlelaag wordt achteraf uitgevoerd, nadat het antwoord is gestreamd. Eerst wordt het antwoord opgesplitst in delen. Daarna beoordeelt het systeem elk deel door in de opgehaalde data te zoeken naar bronnen die de daarin gedane bewering of beweringen ondersteunen. Als er geen ondersteunend bewijs wordt gevonden, wordt dit als mogelijke hallucinatie gemarkeerd.

2. Het analytische niveau (het "hoe")

Als mechanische evaluaties uw unittests zijn, zijn analytische evaluaties uw codebeoordeling.

Hier proberen we te begrijpen of het systeem zijn werk goed uitvoert. We willen doorgaans weten of het de juiste tools gebruikt, de juiste onderzoeksrichtingen volgt, de meest gezaghebbende bronnen kiest en weet wanneer het moet stoppen.

In de praktijk krijgen deze evaluaties meestal de vorm van een reeks vraag-antwoordparen waarvan bijvoorbeeld een logische volgorde van toolaanroepen bekend is, of waarbij vaststaat welke beslissing hoort bij de onderzoeksresultaten uit de eerste tool. Deze paren hoeven niet één op één overeen te komen met de invoer en uitvoer van het volledige systeem; zo kunnen ook deelprocessen worden getest. Met deze labels, opgesteld door een menselijke beoordelaar of een krachtig labelmodel, kunnen we onderzoeksrondes vervolgens via een LLM-as-judge-methode beoordelen. Door deze scores in de loop van de tijd te volgen, zien we of onze wijzigingen het systeem in de goede richting verbeteren of juist tot slechtere prestaties hebben geleid.

Omdat deze rondes meer tijd en geld kosten, moeten ze doorgaans periodiek worden uitgevoerd, volgens een vast schema of voorafgaand aan versie-updates.

Er is ook een mooi indirect voordeel: zulke analytische evaluaties kunnen rechtstreeks aangeven hoe u de eerder besproken beperkte verbindingen kunt verbeteren. Als het model herhaaldelijk dezelfde hoogwaardige sprong maakt, bijvoorbeeld van "specificatie → historisch relevante RFP-voorbeelden", terwijl mensen die eindproducten momenteel niet expliciet koppelen, is dat nuttige informatie. U kunt die sprong tot een volwaardige verbinding of snelkoppeling promoveren, zodat toekomstige rondes profiteren van een lagere latentie en grotere consistentie.

Hier ontdekt u ook een van de kostbaarste problemen van systemen voor diepgaand onderzoek: de neiging om standaard de recall te maximaliseren. Een model kan altijd nog één bron vinden. De vraag is of het dat ook moet doen. We kunnen het model aanpassen om verstandig stopgedrag te bevorderen: het systeem herkent dan wanneer extra zoekwerk de conclusie waarschijnlijk niet verandert en kiest ervoor een goed onderbouwd antwoord te geven dat de gebruikersvraag behandelt.

3. De gebruiker (de "wat heb je eraan?")

De mechanische evaluaties vertellen u dat het systeem veilig is. De analytische evaluaties vertellen u dat het competent is. Gebruikersevaluaties vertellen u of het werkelijk nuttig is.

Ook op dit vlak struikelen veel teams. Ze bouwen iets technisch indrukwekkends dat niemand een tweede keer wil gebruiken. In een bedrijfscontext is dit het verschil tussen een geslaagde implementatie en een kostbaar onderzoeksproject.

Bij gebruikersevaluaties gaat het er in wezen om te begrijpen of het systeem het juiste probleem op de juiste manier oplost. Dit betekent dat u verder moet kijken dan "was het antwoord juist?" en moet vragen: "heb ik iets gekregen waar ik mee aan de slag kan?"

In de praktijk nemen gebruikersevaluaties doorgaans een paar vormen aan:

  • Onderzoek naar taakvoltooiing: kunnen gebruikers hun echte werk met het systeem daadwerkelijk sneller of beter voltooien? Het gaat er niet om of het model een vraag zou kunnen beantwoorden, maar of een echte gebruiker binnen de daadwerkelijke workflow kreeg wat die nodig had.

  • Kwalitatieve feedbackcycli: regelmatige, gestructureerde gesprekken met intensieve gebruikers. Welke zoekopdrachten voeren ze herhaaldelijk uit? Waar verliezen ze hun vertrouwen? Wanneer geven ze het op en keren ze terug naar de oude werkwijze? Deze sessies onthullen vaak foutpatronen die nooit in uw testsets voorkomen, omdat gebruikers vragen stellen op manieren die u niet had voorzien of impliciete kwaliteitsnormen hanteren waarvan u het bestaan niet kende.

  • Gebruiksanalyses: welke zoekopdrachten worden opnieuw uitgevoerd? Welke antwoorden worden gekopieerd en elders gebruikt? Waar klikken gebruikers op het duimpje omlaag? Afnemend gebruik wijst niet altijd op een mislukking — soms hebben gebruikers hun antwoord en gaan ze verder — maar patronen in wanneer en hoe mensen zoekopdrachten afbreken, zeggen veel over waar het systeem niet aan de verwachtingen voldoet.


Samen bieden deze evaluaties een manier om het nut zonder giswerk te meten, zodat u problemen ontdekt voordat ze het vertrouwen van gebruikers aantasten.

Maar zelfs een systeem dat perfect scoort op mechanische nauwkeurigheid en de eerste gebruikers enthousiast maakt, kan nog steeds zakken voor de ultieme test: de omzet van een bedrijf verhogen. Betrouwbaarheid en gebruikerstevredenheid zijn hiervoor slechts randvoorwaarden. Om de kloof tussen een geslaagde pilot en een transformerende bedrijfscapaciteit te overbruggen, moet u verder kijken dan de werking van het systeem en u richten op waar het wordt ingezet.

Uw systeem voor diepgaand onderzoek omzetten in omzetgroei

We hebben besproken hoe u uw data voor uw systeem laat werken en vervolgens hoe u uw systeem voor uw gebruikers laat werken. Nu moeten we bespreken hoe dit systeem voor uw bedrijf kan werken.

Bedrijfsleiders besteden hier de laatste tijd terecht veel aandacht aan. Na berichten zoals de bewering van MIT dat 95% van de AI-projecten in het bedrijfsleven geen rendement oplevert, is er geen geduld meer voor indrukwekkende demo's die nooit in productie gaan. De modellen zijn er klaar voor. De architecturen hebben zich bewezen. De vraag is nu: kunt u dit daadwerkelijk implementeren op een manier die waarde creëert voor uw bedrijf?

Het goede nieuws is dat grensverleggende systemen voor diepgaand onderzoek die op de bovenstaande principes zijn gebouwd, goed toegerust zijn om aan deze norm te voldoen. Ze proberen niet alles te automatiseren of volledige functies te vervangen. Ze proberen uw beste mensen veel effectiever te maken in het waardevolle werk dat ze al doen.

Om van "technisch werkend" naar "rendement opleverend" te gaan, zijn nog enkele doorbraken nodig: keuzes rond organisatie, gebruikerservaring (UX) en metingen die bepalen of dit een alledaagse tool of een vergeten tabblad wordt.

Onze ervaring leert dat het er twee zijn.

1) Kies een startpunt: selecteer een workflow waarvan de waarde duidelijk is

De verleiding is vaak groot om te beginnen met interne taken met weinig risico, zoals "summarise this meeting". Hoewel dit veilig is, bewijzen zulke toepassingen zelden genoeg waarde om de kosten te rechtvaardigen.

Systemen voor diepgaand onderzoek komen het best tot hun recht bij grote, moeilijke taken: kostbare problemen waarbij betere kwaliteit of meer snelheid aantoonbaar extra omzet of strategisch voordeel oplevert.

We zien het hoogste rendement wanneer bedrijven kiezen voor startpunten zoals:

  • Complexe offerte- & RFP-generatie: systemen voor diepgaand onderzoek kunnen automatisch de meest vergelijkbare historische overwinningen én verliezen ophalen, bepalingen identificeren die altijd tot wijzigingsvoorstellen leiden, de sterkste bewijzen voor een vereiste vinden en dit alles omzetten in een krachtige, samenhangende positionering voor de aanbesteding. De maatstaf is hier niet de bespaarde tijd, maar het winstpercentage, behoud van marges en minder juridische of commerciële verrassingen in een laat stadium.

  • Analyse van het wetenschappelijke landschap: bij R&D-intensieve organisaties in bijvoorbeeld de farmacie, biotechnologie en halfgeleidersector is het doel weken aan literatuur en interne kennis om te zetten in een bruikbare onderzoeksrichting. Een systeem voor diepgaand onderzoek kan duizenden artikelen, octrooien, interne rapporten, laboratoriumnotities en eerdere programmabeoordelingen lezen om vast te stellen wat bekend en omstreden is en zo een onderbouwd overzicht te maken. Dit leidt tot snellere iteratiecycli, minder doodlopende investeringen en, het belangrijkst, een kortere aanloop naar de eerste klinische proef met mensen.

  • Marktinzicht: voor banken en hedgefondsen ligt de waarde in het omzetten van versnipperd intern onderzoek — notities, modellen, transcripties en commentaar van brokers — plus externe signalen zoals deponeringen, resultaten, macrocijfers en nieuws, in handelsinformatie die geschikt is voor besluitvorming. Een systeem voor diepgaand onderzoek kan voortdurend een visie op een bedrijf, thema of macrovraagstuk opbouwen en bijwerken, de belangrijkste veranderingen sinds vorige week uitlichten, tegenstrijdige bronnen met elkaar verzoenen en een beleggingsmemo of handelspakket met volledige herkomstinformatie produceren.

De gemene deler is dat dit geen chats zijn. Het zijn complexe workflows waarvoor normaal gesproken dure externe adviseurs of weken van de tijd van senior medewerkers nodig zijn. Wanneer u een systeem voor diepgaand onderzoek op deze problemen inzet, is de waarde onmiskenbaar.

2) UX: van chatten naar delegeren en van antwoorden naar eindproducten

Dit is een van de veranderingen in de gebruikerservaring die 2026 zullen bepalen.

Als uw systeem voor diepgaand onderzoek slechts een chatbot is waaraan gebruikers vragen stellen om iets te vinden, wordt het al snel slechts af en toe gebruikt. Het blijft een naslagwerk en gebruikers moeten de uitvoer uiteindelijk zelf tot het gewenste eindresultaat verwerken. Maar als het aanvoelt als een altijd beschikbare analist waaraan u werk kunt toewijzen, kan het de werkwijze van het team volledig veranderen.

We zien een verschuiving van "chatten" — korte beurten over en weer — naar delegeren: de reikwijdte, een sjabloon en het doel bepalen en het systeem vervolgens zijn werk laten doen.

Drie specifieke veranderingen maken dit mogelijk:

  • Uitvoer als eindproduct: waardevol werk bevindt zich zelden in een chatvenster, maar in documenten, memo's en presentaties. Moderne systemen voor diepgaand onderzoek moeten de chatfase overslaan en rechtstreeks het uiteindelijke bedrijfsmatige eindproduct genereren. Wanneer een gebruiker kan vragen om een "3-page investment memo in our corporate format" en een downloadbaar bestand ontvangt in plaats van een stroom tekst, daalt de tijd tot waarde spectaculair. Dit wordt ook vaak uitgebreid met geplande generaties, waarbij gebruikers kunnen vragen om automatisch e-mails of rapporten met nieuwe inzichten te genereren en onder betrokkenen te verspreiden zodra er nieuwe data beschikbaar zijn.

  • Lokale optimalisatie via aangepaste sjablonen: modellen zijn inmiddels robuust genoeg om bedrijfsonderdelen en zelfs individuele gebruikers hun eigen prompts en gedrag te laten vormgeven zonder het systeem te ontregelen. Een risicorapport ziet er in Londen anders uit dan in New York. Door teams hun eigen structurele sjablonen te laten uploaden of ontwerpen en zelf stopcriteria, zoals "always check these three specific internal databases", of een uitvoerindeling te laten bepalen, halen gebruikers veel meer waarde uit het systeem en ontstaat iets wat ze steeds vaker willen gebruiken.

  • Vertrouwen als interface: wanneer een gebruiker een taak delegeert die meer dan twintig minuten duurt, krijgt vertrouwen hoge prioriteit. U kunt geen black box presenteren. De interface moet de redeneringen en keuzes van het systeem zichtbaar maken, bijvoorbeeld door te tonen welke tools worden gebruikt en bronverwijzingen te genereren. Volgens ons toont de beste UX voor deze systemen standaard inzichten op hoofdlijnen over de voortgang van het onderzoek, met de mogelijkheid voor gebruikers om via een uitklapbare zijbalk of iets vergelijkbaars dieper in de details te duiken.


De weg vooruit

Wij voorzien een toekomst waarin elk toonaangevend bedrijf een systeem voor diepgaand onderzoek op maat inzet voor zijn belangrijkste workflows. Dit krijgt vorm als een reeks altijd beschikbare analisten die betrouwbaar duizenden interne eindproducten kunnen doorzoeken en bruikbare beslissingen en resultaten kunnen opleveren. Nu grensverleggende modellen de uitvoeringsgrens verhogen, verschuift het onderscheidend vermogen naar de basis: uw data bereikbaar maken, het systeem een kaart geven en betrouwbaarheid met evaluaties operationaliseren.

De capaciteitswinst van modellen in het afgelopen jaar is het duidelijkste signaal van de richting waarin dit zich ontwikkelt. Voor leiders ligt in 2026 de kans om vroeg in beweging te komen. Kies een startpunt met een duidelijke waarde, verdien vertrouwen met herkomstinformatie en vangrails, en verander uw oplossing voor diepgaand bedrijfsonderzoek van een pilot in een zichzelf versterkende capaciteit die het bedrijf dagelijks gebruikt.

Auteur

Douglas Adams