This is a viewer only at the moment see the article on how this works.
To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk
This is a preview from the server running through my markdig pipeline
Wednesday, 26 November 2025
"We bouwen een AI-kennisassistent die zal revolutioneren hoe onze medewerkers toegang krijgen tot informatie..."
- Elke vacature advertentie, pitch deck, en consultancy voorstel in 2024-2025
Ik heb de afgelopen maand of zo goed onderdompelen mezelf in de commerciële AI ruimte. Lees overvloedige hoeveelheden marketing bumf. Pored meer dan tientallen job advertenties. Zat door meer product demo's dan ik wil toegeven. En ik ben tot een nogal deprimerende conclusie gekomen.
Het is bijna allemaal hetzelfde.
"AI-aangedreven bedrijf kennis basis." "Intelligent document zoeken." "Klantenchatbot met enterprise kennis." Verwijder de ademloze marketing kopie en je vindt dezelfde architectuur, dezelfde falende modi, en dezelfde teleurgestelde stakeholders ongeveer zes maanden verderop.
De customer chatbot varianten zijn bijzonder vermakelijk ze kunnen PR rampen opmerkelijk snel worden wanneer ontwikkelaars die niet begrijpen vangrails laat ze los op het publiek. Niets heel zoals uw ondersteuning bot vrolijk het aanbieden van restituties die u niet geven, het maken van product functies die niet bestaan, of gaan op een filosofische raaklijn over de betekenis van het bestaan als iemand vraagt over de verzendtijden. Zonder de juiste beperkingen, deze bots zal gelukkig beloven alles, toe te geven aan misdaden uw bedrijf niet commit, of het ontwikkelen van sterke meningen over concurrenten. Het canonische voorbeeld blijft Air Canada's chatbot zelfverzekerd uitvinden van een bereavement beleid dat niet bestond ... en het bedrijf wordt gehouden aan het in de rechtbank.
Hier is het smerige geheim dat niemand in het management wil horen: De meeste commerciële AI projecten zijn niet innovatief. Ze zijn grondstoffen sanitair met een chique label.
Voordat ik verder ga, een disclaimer: Ik ben niet een "AI visionair" of wat de hype-gedreven titel van het moment is (meestal voormalige "blockchain visionairs" die handig draaide). Ik ben een software-ingenieur die dit soort systemen heeft gebouwd zoeken, kennis management, natuurlijke taalverwerking, beslissing ondersteuning . Bijna drie decennia lang . Ik heb dit beeld eerder gezien met deskundige systemen , met semantische web , met big data , met blockchain . De technologie verandert; het patroon van overbeloven en onderbestelling niet .
Verwijder de marketing onzin en je zult merken dat ongeveer 95% van de commerciële "AI" projecten vallen in een van de twee categorieën:
Dit is veruit de meest voorkomende. Elke "enterprise AI-oplossing" volgt dit patroon:
flowchart LR
A[Documents] --> B[Document Ingestion Pipeline]
B --> C[Vector Database / RAG]
C --> D[Construct Prompts]
D --> E[LLM API Call]
E --> F[Hybrid Search]
F --> G[Response to User]
style B stroke:#ff0000,stroke-width:4px
Dat rode doosje is waar alles breekt.
De toonhoogte klinkt indrukwekkend: "We hebben een AI gebouwd die de documenten van uw bedrijf begrijpt en vragen intelligent kan beantwoorden!"
De realiteit: Je hebt een zoekmachine gebouwd met extra stappen en een £ 10.000/maand OpenAI factuur.
Deze is nog dommer. De pitch: "We hebben ons eigen AI model speciaal voor uw industrie getraind!"
De realiteit: Je hebt het model van iemand anders genomen en verfijnd op een dataset die waarschijnlijk te klein is, te vuil, en te smal om een betekenisvol verschil te maken over het gebruik van het basismodel met goede prompts.
flowchart TD
A[Existing LLM] --> B[Collect Training Data]
B --> C[Clean Data - Maybe]
C --> D[Fine-tune Model]
D --> E[Deploy Model]
E --> F[Discover it's not much better than base model]
F --> G[Keep paying for inference anyway]
G --> H[Hope nobody notices]
De meeste fine-tuning projecten die ik heb gezien, zouden beter gediend zijn door hetzelfde geld uit te geven aan het verbeteren van hun prompts en zoeksystemen.
Laten we het hebben over die rode doos in het RAG diagram. Inname van documenten is het deel dat het vaakst faalt, en het is het deel dat de minste aandacht krijgt in de flitsende demo's.
Hier is wat de sales demo laat zien:
Dit is wat er echt gebeurt:
PDF's zijn een nachtmerrie. Ze zijn ontworpen voor afdrukken, niet voor het extraheren van gestructureerde gegevens. Elke PDF-parser die ik heb gebruikt heeft verschillende foutmodi:
En dat zijn gewoon PDF's.
Zodra je tekst hebt opgehaald (slecht), moet je het brokken voor je vectordatabase. Hier gebeurt meer magie denken.
"We zullen gebruik maken van semantische brokken!" Geweldig, uw 200-pagina contract is nu 500 brokken, en de AI heeft geen idee welke zijn gerelateerd of in welke volgorde ze verschijnen.
"We gebruiken fixed-size brokken met overlapping!" Perfect, je hebt net een zin in twee gedeeld en de inbedding staat nu voor onzin.
flowchart TD
A[Original Document] --> B[Chunk 1: This contract shall be governed by]
A --> C[Chunk 2: the laws of the State of California]
B --> D[Embedding: Legal stuff?]
C --> E[Embedding: Geography?]
D --> F[User asks about jurisdiction]
E --> F
F --> G[AI: Based on my knowledge, possibly California, or maybe legal governance, who knows]
Goede RAG heeft goede metadata nodig. Maar het extraheren van metadata uit documenten is moeilijk:
De meeste organisaties hebben tientallen jaren van documenten met inconsistente naamgeving conventies, mapstructuren die zinvol waren voor iemand die in 2003 vertrokken was, en metadata die ofwel ontbreken of fout zijn.
Laat ik duidelijk zijn: fine-tuning heeft zijn plaats, maar de manier waarop de meeste bedrijven het benaderen is fundamenteel gebroken.
Fine-tuning vereist kwaliteitstrainingsgegevens. De meeste bedrijven hebben het niet. Ze hebben:
"We zullen fijnafstellen op onze support tickets!" Uw support tickets zijn vol gefrustreerde klanten, onjuiste informatie van junior personeel, en rand gevallen die niet normaal gebruik vertegenwoordigen.
"We zullen onze verkoopgesprekken verfijnen!" bedoel je die waar verkopers beloftes doen die het product niet kan nakomen?
Hoe weet je of je model eigenlijk beter is? De meeste bedrijven kunnen dit niet beantwoorden omdat:
Ik heb gezien dat bedrijven zes maanden een model verfijnen en dan geen manier hebben om te bewijzen dat het beter is dan gewoon GPT-4 te gebruiken met een goede systeemprompt.
Fine-tuned modellen moeten worden bijgewerkt. Uw bedrijf verandert. Uw producten veranderen. Uw processen veranderen. Dat model dat u in januari verfijnde geeft nu antwoorden op basis van verouderde informatie.
Maar het bijwerken betekent:
De meeste bedrijven verfijnen één keer en dan gewoon leven met de drift. Het model wordt langzaam minder relevant terwijl iedereen doet alsof het nog steeds waarde toevoegt.
Begrijp me niet verkeerd, er zijn legitieme gevallen van gebruik.
flowchart TD
subgraph RAGWorks["✅ RAG Works When"]
R1[Well-structured docs]
R2[Clear metadata]
R3[Search + synthesis use case]
R4[Heavy ingestion investment]
R5[Feedback loops exist]
end
subgraph FTWorks["✅ Fine-Tuning Works When"]
F1[Large high-quality dataset]
F2[Base model truly struggles]
F3[Ongoing maintenance budget]
F4[Clear eval metrics]
F5[Already tried prompting + RAG]
end
style R4 stroke:#00aa00,stroke-width:2px
style F5 stroke:#00aa00,stroke-width:2px
De groene dozen zijn de voorwaarden voor de meeste projecten overslaan. "We hebben al geoptimaliseerd prompting en RAG" is de bar voor fine-tuning. "Zwaar inslikkende investering" Is de bar voor RAG. Sla deze over en je bouwt op zand.
Terwijl iedereen dezelfde RAG-pijpleiding bouwt, worden de eigenlijk interessante problemen in commerciële AI genegeerd:
De grootste beperking op AI effectiviteit is niet het model. Het zijn de gegevens. De meeste organisaties hebben:
Maar "data quality initiative" geeft je geen Forbes artikel zoals "AI transformation" doet.
Het neerzetten van een AI chatbot in een bestaand proces maakt het niet magisch beter. Het proces moet opnieuw worden ontworpen rond de mogelijkheden en beperkingen van de AI. De meeste bedrijven gewoon bout AI op gebroken processen en vraag je af waarom het niet helpt.
De beste AI-implementaties vergroten de menselijke capaciteiten in plaats van ze te vervangen. Maar dat is moeilijker te verkopen dan "AI dat doet X automatisch!"
Mensen + AI samenwerken vereist:
De meeste commerciële AI projecten behandelen de mens als een nagedachte.
De echt waardevolle AI toepassingen zijn niet "chatbot op uw documenten." Het zijn toepassingen die:
Maar die zijn moeilijk. RAG-pijpleidingen zijn makkelijk (goed, makkelijker). Dus dat is wat iedereen bouwt.
Een belangrijke aanjager van domme AI-projecten is het consultancy-ecosysteem:
flowchart TD
A[Big Consultancy Tells C-Suite: You Need AI!] --> B[C-Suite Panics]
B --> C[Consultancy Deploys Army of Juniors]
C --> D[Recommendations: RAG + Fine-Tuning]
D --> E[Build Same Thing as Last 20 Clients]
E --> F[Demo Goes Well]
F --> G[Reality: Real Data Breaks Everything]
G --> H[Consultancy Moves On]
H --> I[Internal Team Struggles]
I --> J[Project Quietly Fails]
J --> K[Nobody Admits It]
K --> A
style G stroke:#ff0000,stroke-width:3px
style J stroke:#ff0000,stroke-width:3px
Ik heb dit patroon tientallen keren gezien... de consultancy wordt betaald... de leidinggevenden mogen zeggen dat ze AI hebben gedaan... de ingenieurs zitten vast met iets dat nauwelijks werkt... en het echte zakelijke probleem blijft onopgelost.
Startups vallen in een iets andere val. Het is niet adviesbureaus het sturen van de disfunctie het is de financiering omgeving.
timeline
title Technology Requirements for VC Funding
2005 : Web 2.0 - "You need social features"
2010 : Mobile - "You need an app"
2015 : Cloud - "You need to be cloud-native"
2018 : Blockchain - "You need a token"
2023 : AI - "You need an AI strategy"
Klinkt bekend? Om de paar jaar, is er een nieuwe technologie die VC's beslissen is essentieel. Als uw pitch deck niet vermelden prominent, je wordt niet gefinancierd. De technologie kan irrelevant zijn voor uw werkelijke product maakt niet uit. Je hebt het buzzword nodig.
Ik zag dit gebeuren met blockchain in 2017-2018. Bedrijven die geen bedrijf op een blockchain waren schoenhorning tokens in hun producten omdat dat is wat kreeg financiering. De meeste van die blockchain functies stilletjes verdwenen zodra het geld was beveiligd.
Nu gebeurt het met Al.
Startups boutten LLM-functies op producten die ze niet nodig hebben omdat:
Het resultaat? Producten met lastige AI functies die gebruikers negeren. Verbrande start-en landingsbaan op fine-tuning experimenten die nergens heen gaan. Engineering tijd verspild aan RAG-systemen wanneer een eenvoudige database query zou beter werken.
Het ergste deel: Veel oprichters weten dat dit dom is. Ze bouwen AI functies waar ze niet in geloven omdat ze lang genoeg moeten overleven om te bouwen waar ze eigenlijk om geven. Sommigen slagen in dit spel. De meeste niet.
Als je een opstartstichter wordt geduwd om AI toe te voegen, vraag jezelf af:
Als het de laatste, bouw de minimale levensvatbare AI-functie die de doos aanvinkt, dan focus op wat er eigenlijk toe doet. Laat de financiering omgeving u niet afleiden van het bouwen van iets waardevols.
Hier is de ongemakkelijke waarheid die niemand in AI wil bespreken: Bijna iedereen in het ecosysteem heeft een financiële stimulans om de hype gaande te houden.
flowchart TD
subgraph Researchers["🔬 Frontier Labs"]
R1[Need billions for compute]
R2[Must show progress to justify spend]
R3[Hype generates investment]
end
subgraph Companies["🏢 Tech Companies"]
C1[Need AI angle for valuation]
C2[Must justify AI team costs]
C3[Hype drives stock price]
end
subgraph Investors["💰 Financial Backers"]
I1[Massive capital deployed]
I2[Need exits and returns]
I3[Hype maintains valuations]
end
subgraph Media["📰 Tech Media"]
M1[AI stories get clicks]
M2[Access depends on positive coverage]
M3[Hype drives engagement]
end
R3 --> I1
C3 --> I1
I3 --> R1
I3 --> C1
M3 --> R3
M3 --> C3
De onderzoekers bij frontier labs hebben miljarden nodig om de volgende generatie van modellen te trainen. Dat geld komt van investeerders en grote tech. Om te rechtvaardigen dat de uitgaven, moeten ze vooruitgang te demonstreren en "vooruitgang" krijgt vertaald in ademloze aankondigingen over mogelijkheden die al dan niet materialiseren in praktische toepassingen. Als de hype sterft, de financiering droogt op.
De ondernemingen (zowel de AI labs als iedereen die AI gebruikt) hebben het verhaal nodig om door te gaan. OpenAI's waardering hangt af van de overtuiging dat AGI is om de hoek. Elke "AI-aangedreven" startup's veelvoud hangt af van AI blijven de hete sector. Het moment sentiment verschuivingen, miljarden in papier rijkdom verdampt.
De investeerders Ze hebben onthutsende hoeveelheden kapitaal ingezet in AI. Ze hebben uitgangen nodig. Ze hebben de muziek nodig om lang genoeg te blijven spelen om rendementen te realiseren. Een realistische beoordeling van bijna-termijn AI mogelijkheden zou waarderingen over de hele sector krateren.
De media heeft ontdekt dat AI verhalen enorme betrokkenheid genereren. Nuanced dekking krijgt geen klikken. "AI neemt uw baan" en "AI doorbraak lost X" doen. Toegang tot AI bedrijven is vaak afhankelijk van het handhaven van positieve relaties .Wat betekent dat kritische dekking is carrière-limiting.
Het resultaat? Een zelfversterkende hypecyclus waar iedereen redenen heeft om verwachtingen op te blazen, en zeer weinig mensen profiteren van het vertellen van de waarheid.
Dit betekent niet dat AI niet echt nuttig is het absoluut is, zoals ik heb besproken in dit artikel. Maar de kloof tussen wat wordt beloofd en wat wordt geleverd is enorm, en de prikkels zijn allemaal op elkaar afgestemd om die kloof verborgen te houden.
Als iemand je vertelt dat AI je bedrijf zal veranderen, vraag jezelf dan af: wat winnen ze ervan als je dat gelooft?
Als je een AI project overweegt, hier is mijn eerlijke advies:
Vraag niet "hoe kunnen we AI gebruiken?" Vraag "Welk probleem proberen we op te lossen?" Als AI de juiste oplossing is, geweldig. Maar vaak niet.
Voordat u een RAG-pijpleiding bouwt, repareert u uw document-rommel. Voordat u uw trainingsgegevens verfijnt, reinigt u uw trainingsgegevens. De AI zal uw dataproblemen niet oplossen; het zal ze versterken.
Start geen enorme "AI transformatie." Bouw een klein bewijs van concept. Test het met echte gebruikers. Leer wat eigenlijk werkt. Breid dan uit.
De document inname pijplijn is niet sexy. De data reiniging is niet spannend. De evaluatie framework is niet iets wat je kunt demo aan de raad. Maar dit zijn wat bepalen succes of mislukking.
AI is geen magie. Huidige LLM's hallucineren. RAG-systemen missen relevante documenten. Fine-tuned modellen drijven. Stel realistische verwachtingen.
Het opbouwen van het systeem is misschien 30% van de inspanning. Het handhaven, verbeteren, en houden van het relevant is de andere 70%. Budget dienovereenkomstig.
Misschien wat je nodig hebt is gewoon beter gebruik van off-the-shelf tools. ChatGPT met een aantal aangepaste instructies kan genoeg zijn. Niet alles heeft een op maat gemaakt AI platform nodig.
Oké, ik heb een paar woorden besteed aan commerciële AI projecten. Deze projecten kunnen daadwerkelijk werken, als je ze verstandig benadert.
Het probleem is niet RAG of fine-tuning als concepten. Het probleem is luie implementatie, onrealistische verwachtingen, en het negeren van de basis. Hier is hoe het beter te doen.
De grootste fout die ik zie is het behandelen van AI als een vervanging voor bestaande processen in plaats van een verbetering. Uw bedrijf heeft al workflows die werken (meestal). In plaats van ze te rippen en te vervangen door een "AI-aangedreven" versie, haak AI in de gaten.
flowchart TD
subgraph Traditional["Traditional Workflow"]
A[Document Arrives] --> B[Human Reviews]
B --> C[Decision Made]
C --> D[Action Taken]
D --> E[Results Logged]
end
subgraph Enhanced["AI-Enhanced Workflow"]
A2[Document Arrives] --> AI1[AI: Extract Key Info]
AI1 --> B2[Human Reviews - With AI Summary]
B2 --> AI2[AI: Suggest Decision Based on History]
AI2 --> C2[Human Makes Final Decision]
C2 --> D2[Action Taken]
D2 --> AI3[AI: Auto-categorise & Log]
AI3 --> E2[Results Available for Future AI Training]
end
Let op wat er anders is:
Dit is veel robuuster dan "AI behandelt alles en soms een menselijke controle."
Hier is een vuil geheim: je hebt waarschijnlijk geen GPT-4 of Claude nodig voor de meeste taken. En je hoeft je vertrouwelijke documenten zeker niet naar OpenAI's servers te sturen.
Het kostenprobleem
Op schaal, API kosten tellen snel op. Een drukke RAG-systeem kan duizenden LLM-gesprekken per dag. Op $0,01-0,03 per 1K tokens, dat is echt geld. En als je schaalt, wordt het erger.
Het probleem van de vertrouwelijkheid
Veel organisaties kunnen hun documenten niet (of niet) naar externe API's sturen:
De oplossing: lokale modellen
Moderne open-source modellen zijn verdomd goed. Lokaal draaien betekent:
flowchart LR
subgraph Cloud["Cloud API Approach"]
A1[Your Documents] --> B1[Internet]
B1 --> C1[OpenAI/Anthropic]
C1 --> D1[£££/month]
C1 --> E1[Privacy Concerns]
end
subgraph Local["Local LLM Approach"]
A2[Your Documents] --> B2[Your Server]
B2 --> C2[Local LLM]
C2 --> D2[Fixed Hardware Cost]
C2 --> E2[Data Never Leaves]
end
Voor inbedding (de RAG vector search bit):
Voor generatie (de werkelijke "AI"-antwoorden):
Voor coderingstaken:
Deze lokaal runnen is niet zo moeilijk als je zou denken. Ollama, lama.cpp, vLLM, of tekst-generatie-invloeden maak het eenvoudig. Ik heb een aantal apps gebouwd (zie de onderkant van het artikel) die dit laten zien op consumentenhardware.
Je hoeft niet alles-of-niets te doen. Een verstandige architectuur gebruikt:
Lokale modellen voor taken met een hoog volume, lagere complexiteit
Cloud API's voor complexe redeneren indien nodig
Deze hybride aanpak geeft u de kostenvoordelen van lokale gevolgtrekkingen met de mogelijkheid van cloudmodellen wanneer u het echt nodig hebt.
flowchart LR
subgraph Waterfall["❌ The Waterfall AI Project"]
W1[Month 1-3: Requirements] --> W2[Month 4-6: Build Platform]
W2 --> W3[Month 7-9: Integration]
W3 --> W4[Month 10: Demo - Looks Great!]
W4 --> W5[Month 11: Real Users Break It]
W5 --> W6[Month 12: Project Shelved]
end
subgraph Incremental["✅ The Incremental Approach"]
I1[Week 1-2: One Small Problem] --> I2[Week 3-4: Refine + Measure]
I2 --> I3[Week 5-6: Add Capability]
I3 --> I4[Week 7-8: Refine + Measure]
I4 --> I5[Repeat...]
I5 --> I6[Continuous Value Delivery]
end
style W5 stroke:#ff0000,stroke-width:3px
style W6 stroke:#ff0000,stroke-width:3px
style I6 stroke:#00aa00,stroke-width:3px
Elke stap in de incrementele aanpak levert meetbare waarde. Elke stap leert je iets. Als iets faalt, heb je weken verloren, niet maanden.
Herinner je je die rode doos in het diagram?
Investeer in kwaliteit boven kwantiteit. Het is beter om 1000 perfect verwerkte documenten te hebben dan 100.000 slecht verwerkte documenten. Begin met uw belangrijkste documenten en zorg dat ze goed zijn.
Gebruik AI om te helpen met inname. Moderne vision-language modellen (GPT-4V, Claude, LLaVA lokaal) kunnen eigenlijk complexe documenten - tabellen, grafieken, handgeschreven notities - lezen op manieren die de traditionele OCR niet kan. Gebruik ze voor de harde documenten.
Bouw terugkoppelingslussen. Als het ophalen mislukt, log dan in. Wanneer gebruikers zeggen "dat is niet wat het document zegt," neem het op. Gebruik deze feedback om uw innamepijplijn te verbeteren.
Accepteer dat sommige documenten niet werken. Niet elke oude gescande PDF is de moeite waard om mee te vechten. Soms is het antwoord "we zullen dat type handmatig behandelen" in plaats van maanden door te brengen op rand gevallen.
Een werkende AI-oplossing vereist:
Wat de meeste projecten doen Wat werkt er eigenlijk? |-----------|----------------------|---------------------| Gegevens in beslag genomen Na de gedachte Primaire focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gegevenskwaliteit "AI zal het uitzoeken" . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Retrieval Basic vector search & Hybrid search & reranking & reranking Gestructureerde output met validatie Menselijke beoordeling optioneel geïntegreerd in de workflow Feedback Geen Oneindige verbeteringslus Controle "Het werkt" Gedetailleerde metrics & alerting Onderhoud "Versie 1 voor altijd" Regelmatige updates en omscholing
Het AI-model is misschien 20% van een werkend systeem. De andere 80% is het saaie materiaal dat het in productie laat werken.
Je kunt niet verbeteren wat je niet kunt meten. Elk AI systeem moet volgen:
Deze gegevens vertellen u waar te investeren inspanning. Misschien is uw ophalen is geweldig, maar generatie is hallucineren. Misschien bepaalde documenttypes altijd falen. U kunt niet repareren wat u niet kunt zien.
Hier is de belangrijkste verschuiving op dit moment: Het tijdperk van "gooi alles op GPT-4 en hoop op het beste" eindigt.
De 2023-2024 aanpak was eenvoudig: krijg het grootste model dat je je kunt veroorloven, vul je context venster vol van alles, en bidden. Het werkte... soort van. Voor demo's. Voor prototypes. Voor het krijgen van investeringen.
Maar het schaalt niet, het is duur, het is traag... en het wordt steeds meer overtroffen door slimmere architecturen.
De toekomst is niet één reusachtig model dat alles doet. meerdere gespecialiseerde modellen die samenwerken, elk doen waar het goed in is.
flowchart TD
subgraph OldWay["The 2023 Approach"]
A1[Everything] --> B1[GPT-4]
B1 --> C1[Hope It Works]
B1 --> D1[£££££]
end
subgraph NewWay["The 2025+ Approach"]
A2[Input] --> B2[Router Model - Small/Fast]
B2 --> C2[Specialist Model A - Extraction]
B2 --> D2[Specialist Model B - Reasoning]
B2 --> E2[Specialist Model C - Generation]
C2 --> F2[Orchestrator]
D2 --> F2
E2 --> F2
F2 --> G2[Output]
end
Dit is wat ik heb onderzocht in mijn DiSE (Directed Synthetic Evolution) werk het idee dat structuur beats briljantheid. Een zorgvuldig georkestreerde pijplijn van kleinere, gefocuste modellen overtreft een enkel massief model dat alles probeert te doen.
Hetzelfde geldt voor de Synthetische decision engine concept: het gebruik van meerdere LLM backends in volgorde, waarbij elk model verschillende sterktes brengt. Snelle modellen voor triage, nauwkeurige modellen voor validatie, creatieve modellen voor generatie. Elk doen wat het beste kan.
Als je dat nog niet gedaan hebt, kijk dan naar mijn RAG-reeks Maar hier is het belangrijkste inzicht: RAG zelf is een vorm van deze georkestreerde aanpak. U gebruikt inbeddingen (één model) om relevante inhoud te vinden en vervolgens een LLM (een ander model) te gebruiken om een antwoord te synthetiseren.
De volgende evolutie gaat verder:
Elk model is kleiner, sneller en goedkoper dan het gebruik van GPT-4 voor alles. Maar samen overtreffen ze de monolithische aanpak.
De term "agentisch" is ontleend aan psychologie mijn oorspronkelijke veld voordat ik in software viel. In psychologie, agentschap verwijst naar de capaciteit om zelfstandig te handelen, om keuzes te maken en uit te voeren in de wereld. Een agent persoon reageert niet alleen op prikkels; ze initieren actie, nastreven doelen, en passen hun gedrag op basis van resultaten.
Agent AI past dit concept toe op taalmodellen. In plaats van het traditionele patroon stel je een vraag, het model genereert tekst een agentisch systeem kan eigenlijk dingen doen. Het kan tools gebruiken, code, query databases uitvoeren, API's bellen, bestanden schrijven, en multi-step workflows orkestreren. Het is het verschil tussen iemand vragen om een routebeschrijving en iemand inhuren om je daarheen te rijden.
Dit is wat Antropic's nieuwste modellen (inclusief Claude Opus 4.5 dat ik letterlijk gebruik om dit te schrijven via Claude Code) demonstreren zo effectief.
Hier is het ding dat maakt de fine-tuning menigte ongemakkelijk: Als je tools goed genoeg beschrijft, heb je geen dure fine-tuning nodig om ze te gebruiken. Moderne funderingsmodellen zijn opmerkelijk goed in het gebruik van gereedschap uit de doos.Je hebt alleen duidelijke functieschema's en goede documentatie in de context nodig.
Dit is een enorme verschuiving van de Toolformer aanpak (fijn-tune een model om te leren wanneer te gebruiken tools door het meten van resultaten). Dat is duur, vereist gespecialiseerde training gegevens, en sluit je in een specifieke set van tools. Het alternatief? Beschrijf uw tools duidelijk, geef het model goede context, en laat het uitzoeken wanneer om ze te gebruiken.
De resultaten zijn vaak beter omdat:
flowchart TD
subgraph RAG["Traditional RAG Chatbot"]
R1[User Question] --> R2[Search Documents]
R2 --> R3[Construct Prompt]
R3 --> R4[LLM Generates Answer]
R4 --> R5[Return to User]
end
subgraph Agentic["Agentic AI Pattern"]
A1[User Task] --> A2[LLM Understands Task]
A2 --> A3[Break Into Steps]
A3 --> A4{Select Tool}
A4 --> A5[Execute Tool]
A5 --> A6{Evaluate Results}
A6 -->|Need More| A4
A6 -->|Done| A7[Return to User]
end
style A6 stroke:#00aa00,stroke-width:3px
Dit agentische patroon is fundamenteel verschillend van RAG chatbots. En het is waar de echte waarde ligt.
Frameworks als LangChain, LlamaIndex en Semantic Kernel maken dit vandaag mogelijk. U kunt systemen bouwen waar:
De bedrijven die dit uitzoeken zullen AI-systemen bouwen die echt werken. De bedrijven die nog steeds proberen hun weg naar succes te verfijnen of nog een andere RAG-chatbot te bouwen, zullen teleurgesteld blijven.
Ik heb uitgebreid geschreven over deze patronen:
Onderwerp Artikel Wat je zult leren |-------|--------------------------------------------------------------------------|-----------------------------------------------------------------| | Architectuur | DiSE vs Voyager Waarom gestructureerde orkestratie beats m unvolutionaire modellen | Multi-Model | Synthetische decision engines Bouwen van pijpleidingen van gespecialiseerde modellen | RAG Fundamentals | RAG-serie Van inbeddingen tot productiesystemen | Lokale inbeddingen | Semantisch zoeken met ONNX CPU-vriendelijke local vector search | Lokale LLM's | DiSE Een selkf evolvign workflow systeem met behulp van lokale modellen die met elkaar zijn verbonden | API Simulatie | LLMApi Met behulp van lokale LLM's om API's voor het testen te simuleren | Praktische RAG | Bouwen van een Advocaat GPT Complete uitvoering van de RVS-implementatie
De technologie bestaat. De patronen ontstaan. De vraag is of uw organisatie iets verstandigs of een ander dom AI-project zal bouwen.
Het huidige commerciële AI landschap doet me denken aan het vroege web tijdperk. Iedereen had een "webstrategie" nodig. Bedrijven bouwden websites omdat ze dat moesten, niet omdat ze wisten wat ze ermee moesten doen. De meeste van die websites waren nutteloos.
Uiteindelijk, de bedrijven die slaagden waren degenen die erachter kwamen waar het web eigenlijk goed voor was en gebouwd voor dat. Hetzelfde zal gebeuren met AI.
Op dit moment zitten we in de "bouw het omdat we moeten" fase. De meeste projecten zijn dom. De meeste zullen falen of onderleveren. Dat is normaal voor nieuwe technologie.
Maar als je een van degenen wilt zijn die erin slaagt, stop dan met het volgen van het sjabloon. Begin met echte problemen. Investeer in de saaie stukjes. En voor de liefde van God, repareer uw document inname pijplijn voordat u de schuld van de LLM.
De AI is niet het probleem. Uw gegevens zijn. Uw processen zijn. Uw onrealistische verwachtingen zijn.
Repareer die eerst, en misschien, heel misschien, zal je AI project niet dom zijn.
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.