Een generatief AI-product ontwikkelen: wat je eerst moet weten

Inleiding

Generatieve AI is eenvoudig uit te proberen, maar aanzienlijk moeilijker om om te zetten in een product waarop mensen kunnen vertrouwen. Een team kan binnen enkele dagen een taalmodel koppelen aan een chatinterface. Ervoor zorgen dat die interface echte verzoeken van klanten kan verwerken, toegangsrechten respecteert, met bedrijfsgegevens werkt en zich herstelt na verkeerde antwoorden, is een heel ander verhaal.

Voor bedrijven die generatieve AI overwegen voor zakelijke toepassingen, is de eerste beslissing niet welk model ze moeten gebruiken. Het gaat erom of het probleem überhaupt om een nieuw product vraagt. Kant-en-klare AI-tools kunnen in de meeste gevallen volstaan, terwijl een maatwerkoplossing zinvoller is wanneer bestaande software de vereiste workflow niet kan ondersteunen. Bedrijven die het laatste overwegen, kunnen de generatieve AI-ingenieurs van SysGears raadplegen om de technische vereisten te verkennen van een product dat is afgestemd op hun specifieke gebruikssituatie.

Een generatief AI-product omvat aanzienlijk meer dan alleen het plaatsen van een model achter een interface met het bedrijfslogo. Het model kan weliswaar de taal verwerken, maar de rest van de applicatie bepaalt op welke informatie het kan terugvallen, of het kan communiceren met andere software en wat er gebeurt als het antwoord de plank misslaat. Die beslissingen zijn net zo bepalend voor het nut van het product als de modelkeuze zelf.

Een interne assistent kan medewerkers op het verkeerde been zetten als hij een verouderd beleidsdocument ophaalt. Geef hem toegang tot klantgegevens, en dan worden toegangsrechten net zo belangrijk als de kwaliteit van de antwoorden. Als de applicatie ook gegevens kan wijzigen, kan een overtuigend maar onjuist antwoord echte schade veroorzaken.

Dit zijn geen details die je na de lancering nog even kunt bijwerken. Ze beïnvloeden de architectuur, de benodigde technische inspanningen en de ontwikkelingskosten van de AI, inclusief wat er nodig is om het product draaiende te houden. Een bedrijf moet deze zaken grondig doornemen voordat het zich vastlegt op ontwikkeling, zolang er nog ruimte is om de reikwijdte te beperken of te besluiten dat een bestaande tool de klus wel kan klaren.

Begin met een probleem waarvoor generatieve AI nodig is

Een overtuigende demo kan een vrij alledaags bedrijfsprobleem verhullen. Als medewerkers bijvoorbeeld te veel tijd besteden aan het doorzoeken van interne documentatie, kan een semantisch zoeksysteem wellicht volstaan. Als ze lange documenten moeten interpreteren, specifieke details moeten extraheren en antwoorden moeten opstellen op basis van informatie uit verschillende bronnen, kan een taalmodel wellicht een substantiële meerwaarde bieden.

Dit onderscheid is vanaf het begin van belang. Generatieve AI bewijst zijn nut wanneer software orde moet scheppen in rommelig, ongestructureerd materiaal of iets moet opstellen dat afhankelijk is van de context. Voor een taak die aan vaste regels onderworpen is, is een gewoon script echter vaak goedkoper in gebruik en betrouwbaarder.

Neem bijvoorbeeld een distributeur die te maken heeft met een gestage stroom van productvragen. Klanten beschrijven hetzelfde artikel op allerlei manieren, dus een generatieve AI-toepassing zou hun verzoeken kunnen begrijpen, de relevante specificaties kunnen opzoeken en een antwoord kunnen opstellen. Voorraadniveaus zijn een ander verhaal. Die moeten afkomstig zijn uit actuele voorraadgegevens, terwijl een opgegeven prijs moet voldoen aan de prijsregels van het bedrijf, en niet aan het cijfer dat het model toevallig produceert.

Het is de moeite waard om die taakverdeling duidelijk te houden: laat het model met taal werken en laat voorspelbare handelingen waar mogelijk over aan conventionele software.

Bepaal, voordat de ontwikkeling begint, wat er daadwerkelijk moet verbeteren. Verkoopmedewerkers hebben misschien minder tijd nodig om een offerte op te stellen; klanten krijgen misschien een antwoord zonder te hoeven wachten op een medewerker van de klantenservice. Leg in ieder geval vast hoe het proces nu verloopt. Anders kan een team uiteindelijk de invoering van de nieuwe AI-interface vieren zonder te weten of het werk daadwerkelijk gemakkelijker is geworden.

Zelf bouwen of kopen: hoeveel controle heb je eigenlijk nodig?

De afweging ‘zelf bouwen of kopen’ wordt vaak voorgesteld als een keuze tussen volledig eigendom en gemak. In de praktijk zijn er verschillende tussenliggende opties.

Kant-en-klare AI-tools zijn een verstandig startpunt wanneer een bedrijf vertrouwde functies nodig heeft, zoals schrijfhulp, vergaderverslagen, documentanalyse of algemeen onderzoek. Deze producten vereisen doorgaans minder ontwikkelingswerk en de leveranciers zorgen voor een groot deel van de onderliggende infrastructuur. Een bedrijf kan testen of medewerkers een functie nuttig vinden zonder eerst een speciaal ontwikkelingsproject te financieren.

De problemen beginnen wanneer een generieke tool moet worden ingepast in een proces waarvoor deze niet is ontworpen. Het kan bijvoorbeeld zijn dat de tool geen koppeling heeft met een verouderde database, of dat de juiste toegangsrechten niet worden toegepast wanneer medewerkers verschillende rollen hebben. De output moet mogelijk ook worden aangepast voordat een ander bedrijfssysteem er gebruik van kan maken. API’s en configuratieopties kunnen helpen deze hiaten te overbruggen, maar ze bieden niet noodzakelijkerwijs een oplossing voor de eigenaardigheden van een gevestigde workflow.

Een op maat gemaakt AI-product is beter te rechtvaardigen wanneer de workflow zelf een concurrentievoordeel vormt, wanneer bestaande producten niet aan een wezenlijke vereiste kunnen voldoen, of wanneer de toepassing een nauwe integratie met eigen gegevens en interne systemen vereist.

Een derde optie is om je eigen applicatie te bouwen rond een model dat door een externe aanbieder wordt gehost. Het bedrijf ontwikkelt de interface en de logica erachter, koppelt het systeem aan zijn bestaande software en zet zijn eigen manier op om de resultaten te testen. Het model zelf is toegankelijk via een API, dus het is niet nodig om een basismodel helemaal vanaf nul te trainen. Dit geeft het bedrijf de ruimte om het product af te stemmen op zijn workflow, hoewel het nog steeds afhankelijk is van de prijsstelling van de aanbieder, de beschikbaarheid van het model en de servicelimieten.

Dat laatste onderscheid verdient aandacht. Het ontwikkelen van een op maat gemaakte AI-applicatie en het ontwikkelen van een nieuw AI-model zijn twee verschillende ondernemingen. Het trainen van een basismodel vereist aanzienlijke rekenkracht, gespecialiseerde expertise, geschikte data en voortdurend experimenteren. De meeste bedrijven hoeven die last niet op zich te nemen. Een bestaand model, aangevuld met het ophalen van gegevens uit bedrijfsdocumenten of zorgvuldig ontworpen toegang tot tools, kan voldoende zijn.

Kies de architectuur op basis van het werk

Zodra de businesscase duidelijk is, is de volgende uitdaging om te bepalen hoe de applicatie zal werken. Het model is slechts één onderdeel, en het is misschien niet eens het onderdeel dat de meeste ontwikkelingstijd in beslag neemt.

Voor een documentassistent is ‘retrieval-augmented generation’ (RAG) vaak het overwegen waard. In plaats van uitsluitend te vertrouwen op wat een model tijdens de training heeft geleerd, haalt de applicatie relevante passages op uit een goedgekeurde informatiebron en neemt deze op in de prompt. Het model formuleert vervolgens een antwoord aan de hand van dat materiaal.

Antwoorden die zijn gebaseerd op intern beleid of actuele productinformatie kunnen relevanter zijn, mits het ophalen van informatie naar behoren verloopt. Dat is echter geen zekerheid. De zoekopdracht kan een verouderd document opleveren, een cruciale kanttekening over het hoofd zien of het model een passage aanreiken die het vervolgens verkeerd interpreteert.

Het ophalen van informatie moet op zichzelf worden getest. Hoe documenten in stukken worden opgedeeld, kan van invloed zijn op wat het systeem vindt, en zelfs een goed zoekresultaat is nutteloos als het afkomstig is van een bron die de gebruiker niet mag zien. De toegangsrechten van een medewerker moeten ook gelden voor het ophaalproces, in plaats van te worden genegeerd omdat een zoekopdracht toevallig beperkt toegankelijk materiaal aan het licht bracht. De applicatie zelf moet de autorisatie afdwingen. Een model mag niet worden vertrouwd om die beslissing te nemen.

Fijnafstemming dient een ander doel. Het kan helpen bij het aanpassen van het gedrag van een model, de responsindeling of de afhandeling van terugkerende taakpatronen wanneer er geschikte trainingsvoorbeelden beschikbaar zijn. Het is geen rechtstreekse vervanging voor het ophalen van informatie wanneer het hoofdprobleem de toegang tot veranderende feiten is. Een model dat is afgestemd op de productcatalogus van vorig jaar, weet niet automatisch wat er vanochtend is veranderd.

Een prompt en een model-API zijn wellicht alles wat een toepassing met een beperkte reikwijdte nodig heeft, in ieder geval in het begin. Dat hangt af van hoe voorspelbaar de invoer is en wat er van het systeem wordt verwacht met de uitvoer. Als elk antwoord moet worden getoetst aan een grote hoeveelheid interne documentatie, kan het ophalen van informatie noodzakelijk worden; voor een eenvoudigere taak zou het alleen maar extra werk kunnen opleveren.

Houd de eerste versie eenvoudig en test deze op echte verzoeken, niet alleen op gepolijste demo-invoer. Kijk hoe het omgaat met een vage vraag of ontbrekende informatie. Als het bluft in plaats van een leemte toe te geven, is dat iets wat moet worden opgelost voordat er meer bewegende onderdelen worden toegevoegd.