Het idee – ETL pipelines bouwen met behulp van AI

De situatie die we regelmatig tegenkomen is dat een aantal API endpoints moeten worden uitgelezen (extract), data moet worden getransformeerd (transform) naar een matrix-formaat en dat die getransformeerde data vervolgens moet worden doorgepompt (load) naar een Business Intelligence systeem, dat zelf helaas niet in staat is de hiërarchisch georganiseerde data in het gewenste formaat in te lezen of waarbij je door hoepels moet springen om de taak voor elkaar te krijgen. Extract-Transform-Load, oftewel ETL.

Stel nu dat je deze pipeline met behulp van AI kunt maken door een aantal eenvoudige vragen te beantwoorden?

Stel nu dat je het resultaat van de pipeline via een API eenvoudig ter beschikking kunt stellen aan een afnemende partij (zoals een ander BI-systeem)?

Kernprincipes

Het systeem moet aan een aantal kernprincipes voldoen:

• gebruiksvriendelijke interface; de web interface voor het opstellen van de pipeline moet laagdrempelig zijn, duidelijk laten zien wat de feedback van de AI is, waar in het proces de gebruiker zich bevindt en wat het tot nu toe verworven resultaat is.
• afhandelen foutsituaties; het tool moet de verschillende soorten foutsituaties correct afhandelen, door een mix van verduidelijkingsvragen, opnieuw proberen (AI is immers stochastisch) en Human-in-the-Loop (HITL) als de AI er echt niet uitkomt en de mens moet het voor dat deel overnemen.
• maken met AI, runnen zonder AI; het opstellen van de pipeline gebeurt met de AI-assistent. Zodra de pipeline is opgesteld, moet het draaien van de pipeline zonder AI kunnen plaatsvinden. Het proces is daarmee volledig machinaal.
• OpenAPI documentatie als basis; de AI-assistent moet gebruik maken van de OpenAPI documentatie die veel (en steeds meer) REST API's inmiddels beschrijven. De OpenAPI documentatie is dusdanig standaard en gestructureerd dat het de best mogelijke springplank biedt. Dit betekent automatisch dat endpoints zonder OpenAPI documentatie in eerste instantie niet ondersteund worden.
• kennis van specifieke endpoints; sommige systemen vereisen meer kennis van wat OpenAPI kan bieden, zoals bijvoorbeeld de Jira Assets context of Jira custom fields. Het systeem moet weet hebben van deze constructies waar dat relevant is.
• plug-and-play; pipelines moeten eenvoudig planbaar zijn voor reguliere ophaalacties en eenvoudig te ontsluiten zijn voor consumerende partijen (zoals BI-systemen).

Proof-of-concept

We hebben tests gedraaid om te bepalen hoe goed de AI de volgende extract-stappen kan uitvoeren (voor specifieke JSON-gebaseerde API's):

• selecteren van een API endpoint
• bepalen van de request parameters voor een API endpoint
• bepalen van de paginering-strategie (ie, de wijze waarop alle resultaten opgehaald moeten worden)
• bepalen van het element waar de lijst van resultaten staat (JsonPath)
• bepalen van de benodigde velden en de locatie daarvan in het resultaat (JsonPath)

Zodra deze resultaten zijn opgehaald, heb je in de basis een pipeline voor één enkel API endpoint. De waarde van de POC schuilt erin om te bewijzen dat de AI in staat is om de juiste resultaten te genereren, met een bepaalde mate van onzekerheid, zoals gebruikelijk is bij in software ingebouwde AI agents.

Resultaten tot dusver

Het selecteren van endpoints en het bepalen van de JsonPath waarden is iets waar de AI met de juiste context goed toe in staat is. Het genereren van specifieke query language constructies (JQL, AQL) is wat lastiger, moet meer ingekaderd worden met de juiste context. Gemini 2.5 Flash-Lite is voldoende sterk om deze taken uit te voeren.

Het bepalen van de paginering-strategie werkt beter met Flash dan met Flash-Lite, dus daar hebben we voor het eerstgenoemde, iets duurdere, iets tragere Flash-model gekozen.

Het instrument om de modellen te fine-tunen is nog niet ingezet, mede omdat dit een significante investering vereist omdat daarvoor een kwalitatief sterke dataset nodig is. Vooralsnog onbenut dus, maar in het achterhoofd om een betere prestatie uit het model te halen.

Vervolgstappen

Voor alle stappen worden de flows voor foutafhandeling opgezet, waarbij gedacht wordt in drie verschillende lagen (conform de aap-machine-mens metafoor):

• fouten van de AI (aap); als de AI zelf niet het antwoord kan bepalen, dan wordt de gebruiker om opheldering gevraagd en wordt het proces nogmaals uitgevoerd.
• fouten gevonden door de machine; validaties op het verschafte antwoord, zoals of het endpoint niet gehallucineerd is, of dat een JsonPath uitvoerbaar is op het JSON-resultaat. De interventie bestaat uit opnieuw proberen, met kennis van de fout-situatie. Het aantal pogingen moet gemaximeerd worden.
• fouten gevonden door de mens; human-in-the-loop (HITL) approval met mogelijkheden tot interventie, zoals verschaffen opheldering in prompt, handmatig selecteren van de oplossing of het terugvallen & opnieuw proberen van een eerdere stap

Het is zaak de meest voorkomende fout-categorieën voor de agents goed in kaart te brengen (en te houden) en een evaluatie-harnas te bouwen om de trefzekerheid van de agents vast te stellen. Dit evaluatie-harnas dient tevens als instrument om LLM model updates te toetsen en wisselingen van het onderliggende LLM model te ondersteunen. Door middel van context engineering en het evaluatie-harnas wordt de trefzekerheid langzaam verhoogd. Gaandeweg moeten criteria opgesteld worden, bv aan de hand van gebruiker tests, die bepalen wanneer de trefzekerheid voor een agent hoog genoeg is.

Voorts zullen de transform- en load-fase verder uitgewerkt worden, waarbij een sterke voorkeur is voor machinale afhandeling, met andere woorden niet door AI-ondersteund. De reden om daar in eerste instantie toe te beperken, is dat het samenvoegen van losse, maar gekoppelde ruwe data tabellen tot één ruwe data tabel een programmeerbare handeling is. Voor de eerste fase is dat voldoende.

Voor nu zal gewerkt worden met frontier lab LLM's, zoals de Gemini 2.5 familie. Gegeven dat Open Source ongeveer 9 maanden achter de frontier labs aanloopt, houden we een schuin oog op deze ontwikkelingen. Reden om Open Source ontwikkelingen te blijven volgen is dat een lokaal gerund Open Source model een aantal beschikbaarheids-, veiligheids- en privacy-problemen oplost en daarnaast goedkoper is in de operatie. Het evaluatie-harnas helpt om waar nodig of mogelijk een switch te kunnen maken van vendor- naar OSS-modellen.

De verwachting is dat de POC tot ongeveer het einde van het jaar zal lopen.