(nog niet zo lang geleden) Toen datawetenschapper zijn betekende dat je in een notitieboekje moest leven en hyperparameters moest aanpassen alsof je leven ervan afhing, en in veel gevallen hing het hele project er inderdaad van af.
Herinnert u zich die nachtelijke zoekopdrachten in het raster nog? Of het bouwen van technische pijplijnen die meer op kunst dan op wetenschap leken? En de voldoening van het uitpersen van een extra nauwkeurigheid van 0,7% uit een XGBoost-model?
In 2019 was dat de taak van een datawetenschapper! Wat logisch was. Als je een sterk model wilde, moest je het zelf bouwen of hard werken om het goed te krijgen. De echte waarde kwam voort uit hoe goed je de gegevens kon afstemmen, optimaliseren en begrijpen.
Nu is ‘state-of-the-art’ slechts één API-aanroep verwijderd. Een toptaalmodel nodig? Klaar. Heb je inbedding of multimodaal redeneren nodig? Ook gedaan. De moeilijkste onderdelen van het modelleren worden nu afgehandeld door schaalbare eindpunten, veel verder dan wat de meeste teams zelf zouden kunnen bouwen.
De vraag is nu: als het model er al is, waar is het werk gebleven?
De waarde zit niet alleen meer in het model. Het zit in de manier waarop alle onderdelen verbinding maken, communiceren en zich aanpassen. Die verandering verandert de rol van een datawetenschapper volledig.
Hoevraag je? Dit is waar dit artikel over gaat.
Wat is er veranderd?
1. De .fit()-methode omzeilen
Als je naar de code in een modern AI-project kijkt, zul je snel merken dat er niet veel daadwerkelijke modellering plaatsvindt.
Mogelijk zie je een oproep naar een LLM of een inbeddingsmodel, maar dat is zelden de grootste uitdaging. Het echte werk zit in de gegevensopname, routering, het samenstellen van context, caching, monitoring en het afhandelen van nieuwe pogingen.
Met andere woorden, gebruiken .fit() is nu een van de minst interessante delen van de code.
2. Aanpassing aan de nieuwe componenten
Tegenwoordig assembleren we systemen uit kant-en-klare componenten, in plaats van ons te concentreren op interne modellen. Een typische modelleringsstapel bevat nu:
- Vectordatabases (bijv. Pinecone, Milvus)
- Snelle techniek.
- Geheugen lagen.
Naast functies/agentoproepen. Als we naar het grote geheel kijken, zien we dat dit geen traditionele modellering is. Het is systeemontwerp. Het is belangrijk om hier op te wijzen dat geen van deze componenten op zichzelf bijzonder nuttig is. Hun kracht komt voort uit de manier waarop ze samen zijn georkestreerd.
3. Alles op een rijtje zetten
Op dit moment gaat de meeste datawetenschapscode over het verbinden van de stukken. Het gaat niet om lineaire algebra, optimalisatie of zelfs statistiek.
Het gaat over het schrijven van code die gegevens tussen componenten verplaatst, invoer formatteert, uitvoer parseert, interacties registreert en de status over gedistribueerde systemen beheert.
Als u uw code meet, ziet u dat slechts 10 tot 20 procent wordt besteed aan het gebruik van een model (API-aanroepen, inferentie), terwijl 80 tot 90 procent wordt besteed aan orkestratie: het afhandelen van gegevensstromen, integratie en infrastructuur.
De verschuiving van Data Scientist naar AI Architect
De grootste mentaliteitsverandering van vandaag is dat je niet langer alleen maar een functie optimaliseert. Nu ontwerp je een heel systeem, waarbij je nadenkt over latentie, kosten, betrouwbaarheid en hoe mensen ermee omgaan.
In plaats van te vragen: “Hoe verbeter ik de modelprestaties?’, vragen wij nu, “Hoe werkt dit hele systeem in reële situaties?”
Ik weet wat je denkt: dit is een heel andere uitdaging! Het was voor veel mensen, inclusief mij, ongemakkelijk toen deze verschuiving voor het eerst plaatsvond.
Om de huidige stapel bij te houden, hebben we meer nodig dan alleen statistieken en machinaal leren. We moeten ons op ons gemak voelen met API’s (zoals FastAPI of Flask) voor het serveren en routeren, containerisatie (zoals Docker) voor implementatie, asynchrone programmering (met behulp van Asyncio) voor het afhandelen van meerdere verzoeken, cloudinfrastructuur voor schaling en monitoring, en basisprincipes van data-engineering voor pijpleidingen en opslag.
Als je denkt: dit lijkt veel op back-end techniekje hebt gelijk.
Deze verschuiving heeft de grens tussen datawetenschapper en ingenieur doen vervagen. De mensen die het goed doen, zijn degenen die op beide gebieden comfortabel kunnen werken.
Het oude versus het nieuwe
De belangrijkste vraag is nu: hoe ziet deze verschuiving er in code uit?
Legacy Project (2019): Sentimentanalyse
Velen van ons hebben aan dit soort projecten gewerkt. Het proces is eenvoudig:
- Verzamel een gelabelde dataset.
- Functie-engineering uitvoeren (TF-IDF, n-gram).
- Treinclassificator (logistische regressie, XGBoost).
- Hyperparameters afstemmen.
- Model implementeren.
Succes hier hangt af van de kwaliteit van uw dataset en uw model.
Modern Project (2026): Autonome klantfeedbackagent
Het proces is nu anders. Om vandaag de dag een systeem te bouwen, moet u:
- Neem klantberichten in realtime op.
- Bewaar inbedding in een vectordatabase.
- Haal relevante historische context op.
- Dynamisch construeren van aanwijzingen.
- Route naar LLM met toegang tot tools (bijv. CRM-updates, ticketingsystemen)
- Onderhoud het gespreksgeheugen.
- Bewaak de uitgangen op kwaliteit en veiligheid.
Kun jij ontdekken wat er ontbreekt? Hier is een hint: er is geen trainingslus.
Dit voorbeeld is met opzet eenvoudig, maar merk op waar we ons nu op concentreren. Ophalen is onderdeel van het systeem; het model bestaat uit slechts één stuk en de waarde komt voort uit de manier waarop alles met elkaar verbonden is en samenwerkt.
Hoe u kunt beginnen te denken als een AI-architect
Nu we weten wat er veranderd is, gaan we het hebben over wat u eigenlijk anders zou moeten doen. Hoe kun je met deze verschuiving vooruitgang boeken in plaats van achterop te raken?
Het korte antwoord: begin met het bouwen van systemen, niet alleen maar modellen.
Het langere antwoord: focus op het ontwikkelen van deze vaardigheden:
1. Bouw end-to-end, niet alleen componenten
In plaats van te denken: “Ik heb een model getraind”, mikken op, “Ik heb een systeem gebouwd dat invoer ontvangt, verwerkt en een waarde retourneert.Het gaat nu om het grote geheel, niet slechts om één taak.
2. Leer net genoeg backend om gevaarlijk te zijn
U hoeft geen fulltime backend-ingenieur te worden, maar u moet wel voldoende weten om uw systeem te bouwen. Focus op:
- Een eenvoudige API opzetten (FastAPI is voldoende)
- Asynchroon afhandelen van aanvragen
- Logboekregistratie en foutafhandeling
- Basisimplementatie (Docker + één cloudplatform)
3. Maak je op je gemak met dubbelzinnigheid
Moderne AI-systemen zijn niet deterministisch zoals traditionele modellen. Dit maakt het moeilijker om ermee te werken, omdat je nu niet alleen maar bezig bent met het debuggen van code; je bent eerder bezig met het debuggen van gedrag.
Dat betekent dat we op aanwijzingen moeten reageren, terugvalmechanismen moeten ontwerpen en de resultaten kwalitatief moeten evalueren, niet alleen kwantitatief.
4. Meet wat er werkelijk toe doet
Nauwkeurigheid is niet altijd meer de belangrijkste maatstaf. Nu zijn de latentie, de kosten per verzoek, de gebruikerstevredenheid en het voltooiingspercentage van taken belangrijker.
Een systeem dat 95% nauwkeurig is, maar onbruikbaar in de productie, is slechter dan een systeem dat 85% nauwkeurig en betrouwbaar is.
De laatste gedachte
In ons vakgebied is er altijd de verleiding om na te jagen wat het meest ’technisch’ aanvoelt: het nieuwste model, de grootste maatstaf, de meest opvallende architectuur.
Maar het meest waardevolle deel van deze baan is altijd de menselijke kant geweest en zal dat altijd blijven! Dat is het probleem begrijpen. Weten wat we proberen op te lossen is belangrijker dan de gegevens of het model dat we gebruiken.
Het stellen van vragen als: “Wat is hier de behoefte aan? Wat vindt de gebruiker belangrijk? Wat betekent ‘goed’ eigenlijk in de context?” maakt een enorm verschil in wat je bouwt.
Dat deel kun je niet uitbesteden of verbergen achter een API. En je kunt het zeker niet wegautomatiseren.
Probeer dus niet alleen de motor van een auto te bouwen. Probeer de persoon te zijn die begrijpt waar de auto heen moet en vervolgens het systeem bouwt om hem daar te krijgen.
