Udvikling af et generativt AI-produkt: Hvad man bør vide først

Indledning

Generativ AI er let at afprøve, men betydeligt sværere at omdanne til et produkt, som folk kan stole på. Et team kan på få dage koble en sprogmodel til en chat-grænseflade. At få denne grænseflade til at håndtere reelle kundehenvendelser, overholde adgangsrettigheder, arbejde med virksomhedens data og rette op på forkerte svar er en helt anden sag.

For virksomheder, der overvejer generativ AI til forretningsapplikationer, er den første beslutning ikke, hvilken model der skal bruges. Det er, om problemet overhovedet kræver et nyt produkt. Standard-AI-værktøjer kan dække det meste af behovet, mens en skræddersyet implementering giver mere mening, når eksisterende software ikke kan imødekomme den krævede arbejdsgang. Virksomheder, der vurderer sidstnævnte, kan konsultere SysGears’ ingeniører inden for generativ AI for at udforske de tekniske krav til et produkt, der er bygget op omkring netop deres anvendelsesscenarie.

Et generativt AI-produkt indebærer betydeligt mere end blot at placere en model bag en brugergrænseflade med virksomhedens branding. Modellen kan måske håndtere sproget, men resten af applikationen bestemmer, hvilke oplysninger den kan trække på, om den kan interagere med anden software, og hvad der sker, når svaret rammer ved siden af. Disse beslutninger påvirker produktets nytteværdi lige så meget som selve valg af model.

En intern assistent kan vildlede medarbejderne, hvis den henter et forældet politikdokument. Giver man den adgang til kunderegistrer, bliver adgangsrettigheder lige så vigtige som svarets kvalitet. Hvis applikationen også kan ændre registreringer, kan et overbevisende, men forkert svar forårsage reel skade.

Dette er ikke detaljer, man kan lappe sammen efter lanceringen. De påvirker arkitekturen, den tekniske indsats og omkostningerne ved AI-udviklingen, herunder hvad der skal til for at holde produktet kørende. En virksomhed bør gennemgå disse aspekter, inden den forpligter sig til udviklingen, mens der stadig er mulighed for at indsnævre omfanget eller beslutte, at et eksisterende værktøj kan klare opgaven.

Start med et problem, der kræver generativ AI

En overbevisende demo kan skjule et ret almindeligt forretningsproblem. Hvis medarbejderne for eksempel bruger for meget tid på at søge i intern dokumentation, kan et semantisk søgesystem være tilstrækkeligt. Hvis de har brug for at fortolke lange dokumenter, udtrække specifikke detaljer og udarbejde svar ved hjælp af oplysninger fra flere kilder, kan en sprogmodel tilføre noget mere væsentligt.

Denne skelnen er vigtig fra starten. Generativ AI tjener sig ind, når softwaren skal give mening til rodet, ustruktureret materiale eller udarbejde noget, der afhænger af konteksten. Til en opgave, der styres af faste regler, er et almindeligt script dog ofte billigere at køre og lettere at stole på.

Tag for eksempel en distributør, der håndterer en konstant strøm af produktforespørgsler. Kunderne beskriver den samme vare på alle mulige måder, så en generativ AI-applikation kunne give mening til deres anmodninger, hente de relevante specifikationer og udarbejde et svar. Lagerbeholdninger er en anden sag. De skal hentes fra aktuelle lageropgørelser, mens en angivet pris skal følge virksomhedens prisregler og ikke det tal, som modellen tilfældigvis genererer.

Det er vigtigt at holde denne arbejdsfordeling klar: Lad modellen arbejde med sproget, og overlad forudsigelige opgaver til konventionel software, hvor det er muligt.

Inden udviklingen går i gang, skal man fastlægge, hvad der rent faktisk skal forbedres. Salgspersonalet har måske brug for færre minutter til at udarbejde et tilbud; kunderne får måske et svar uden at skulle vente på en supportmedarbejder. Uanset hvad skal man dokumentere, hvordan processen fungerer i dag. Ellers kan et team ende med at fejre indførelsen af sin nye AI-grænseflade uden at vide, om den overhovedet har gjort arbejdet nemmere.

Selvudvikling eller køb: Hvor meget kontrol har du egentlig brug for?

Beslutningen om at udvikle selv eller købe præsenteres ofte som et valg mellem fuld ejerskab og bekvemmelighed. I praksis findes der flere muligheder midt imellem.

Færdige AI-værktøjer er et fornuftigt udgangspunkt, når en virksomhed har brug for velkendte funktioner såsom skrivehjælp, mødereferater, dokumentanalyse eller generel research. Disse produkter kræver normalt mindre teknisk arbejde, og leverandørerne står for en stor del af den underliggende infrastruktur. En virksomhed kan afprøve, om medarbejderne finder en funktion nyttig, uden først at skulle finansiere et dedikeret udviklingsprojekt.

Problemerne opstår, når et generisk værktøj skal tilpasses en proces, det ikke er designet til. Det kan f.eks. være, at det ikke kan kommunikere med en ældre database eller anvende de rette adgangsrettigheder, når medarbejderne har forskellige roller. Dets output skal muligvis også omformes, før et andet forretningssystem kan bruge det. API'er og konfigurationsmuligheder kan hjælpe med at bygge bro over disse huller, men de dækker ikke nødvendigvis de særlige forhold i en etableret arbejdsgang.

Et skræddersyet AI-produkt bliver mere berettiget, når selve arbejdsgangen udgør en konkurrencemæssig fordel, når eksisterende produkter ikke kan opfylde et væsentligt krav, eller når applikationen kræver tæt integration med proprietære data og interne systemer.

En tredje mulighed er at udvikle sin egen applikation omkring en model, der hostes af en ekstern udbyder. Virksomheden udvikler grænsefladen og logikken bag den, integrerer systemet i sin eksisterende software og opretter sin egen metode til at teste resultaterne. Selve modellen tilgås via et API, så der er ingen grund til at træne en grundmodel fra bunden. Dette giver virksomheden spillerum til at tilpasse produktet til sin arbejdsgang, selvom den stadig er afhængig af udbyderens priser, modellens tilgængelighed og servicebegrænsninger.

Denne sidste forskel fortjener opmærksomhed. At udvikle en skræddersyet AI-applikation og at udvikle en ny AI-model er to forskellige opgaver. Træning af en grundmodel kræver betydelige computerressourcer, specialiseret ekspertise, egnede data og løbende eksperimentering. De fleste virksomheder behøver ikke at påtage sig den byrde. En eksisterende model, suppleret med hentning af data fra virksomhedens dokumenter eller omhyggeligt designet adgang til værktøjer, kan være tilstrækkelig.

Vælg arkitekturen ud fra arbejdsgangen

Når forretningsgrundlaget er klart, er den næste udfordring at beslutte, hvordan applikationen skal fungere. Modellen er kun én komponent, og det er måske ikke den komponent, der kræver mest udviklingstid.

For en dokumentassistent er det ofte værd at overveje RAG (Retrieval-Augmented Generation). I stedet for udelukkende at stole på det, en model har lært under træningen, henter applikationen relevante passager fra en godkendt informationskilde og inkluderer dem i prompten. Modellen formulerer derefter et svar ved hjælp af dette materiale.

Svar, der er baseret på interne retningslinjer eller aktuelle produktoplysninger, kan være mere relevante, forudsat at søgningen fungerer efter hensigten. Det er dog ikke sikkert. Søgningen kan finde et forældet dokument, overse en afgørende forbehold eller give modellen et afsnit, som den derefter fortolker forkert.

Hentningen skal testes i sig selv. Hvordan dokumenter opdeles i bidder kan påvirke, hvad systemet finder, og selv et godt søgeresultat er ubrugeligt, hvis det stammer fra en kilde, som brugeren ikke bør se. En medarbejders adgangsrettigheder skal gælde i hentningsprocessen, i stedet for at blive tilsidesat, fordi en søgning tilfældigvis frembragte materiale med adgangsbegrænsninger. Applikationen selv skal håndhæve autorisationen. Man bør ikke stole på, at en model træffer den beslutning.

Finjustering tjener et andet formål. Den kan hjælpe med at tilpasse en models adfærd, svarformat eller håndtering af tilbagevendende opgavemønstre, når der er egnede træningseksempler til rådighed. Den er ikke en direkte erstatning for søgning, når hovedproblemet er adgang til skiftende fakta. En model, der er finjusteret på sidste års produktkatalog, vil ikke automatisk vide, hvad der er ændret i morges.

En prompt og en model-API kan være alt, hvad en applikation med snævert anvendelsesområde har brug for, i det mindste til at begynde med. Det afhænger af, hvor forudsigelige indgangsdataene er, og hvad systemet forventes at gøre med sit output. Hvis hvert svar skal kontrolleres op mod en stor mængde intern dokumentation, kan hentning blive nødvendig; for en enklere opgave kan det blot medføre ekstra arbejdsbyrde.

Hold den første version enkel, og afprøv den på reelle forespørgsler, ikke blot på polerede demo-inddata. Se, hvordan den håndterer et vagt spørgsmål eller manglende oplysninger. Hvis den bluffer i stedet for at indrømme en manglende viden, er det noget, der skal rettes, før der tilføjes flere bevægelige dele.