Utvikling av et generativt AI-produkt: Det du bør vite først

Innledning

Generativ AI er lett å prøve ut, men betydelig vanskeligere å gjøre om til et produkt folk kan stole på. Et team kan koble en språkmodell til et chat-grensesnitt på få dager. Å få dette grensesnittet til å håndtere ekte kundeforespørsler, respektere tilgangstillatelser, arbeide med bedriftsdata og rette opp feilaktige svar er en helt annen sak.

For bedrifter som vurderer generativ AI til forretningsapplikasjoner, er den første avgjørelsen ikke hvilken modell de skal bruke. Det er om problemet i det hele tatt krever et nytt produkt. Ferdige AI-verktøy kan dekke det meste av behovet, mens en skreddersydd implementering gir mer mening når eksisterende programvare ikke kan tilpasses den nødvendige arbeidsflyten. Bedrifter som vurderer det siste, kan rådføre seg med SysGears’ ingeniører innen generativ AI for å utforske de tekniske kravene til et produkt bygget rundt deres spesifikke bruksområde.

Et generativt AI-produkt innebærer betydelig mer enn å plassere en modell bak et grensesnitt med bedriftens merkevare. Modellen kan kanskje håndtere språket, men resten av applikasjonen avgjør hvilken informasjon den kan hente fra, om den kan samhandle med annen programvare, og hva som skjer når svaret ikke treffer blink. Disse beslutningene påvirker produktets nytteverdi like mye som selve valg av modell.

En intern assistent kan villede ansatte hvis den henter frem et utdatert retningslinjedokument. Gir man den tilgang til kundedata, blir tilgangstillatelser like viktige som svarets kvalitet. Hvis applikasjonen også kan endre oppføringer, kan et overbevisende, men feilaktig svar forårsake reell skade.

Dette er ikke detaljer man kan fikse i etterkant av lanseringen. De påvirker arkitekturen, det tekniske arbeidet som kreves og utviklingskostnadene for AI, inkludert hva som trengs for å holde produktet i drift. En bedrift bør gå gjennom disse før den forplikter seg til utvikling, mens det fortsatt er rom for å begrense omfanget eller bestemme at et eksisterende verktøy vil gjøre jobben.

Start med et problem som krever generativ AI

En overbevisende demo kan skjule et ganske vanlig forretningsproblem. Hvis ansatte for eksempel bruker for mye tid på å søke i intern dokumentasjon, kan et semantisk søkesystem være tilstrekkelig. Hvis de trenger å tolke lange dokumenter, hente ut spesifikke detaljer og utarbeide svar ved hjelp av informasjon fra flere kilder, kan en språkmodell tilføre noe mer substansielt.

Dette skillet er viktig helt fra starten av. Generativ AI viser sin verdi når programvaren må gi mening til uoversiktlig, ustrukturert materiale eller utarbeide noe som avhenger av konteksten. For en oppgave som styres av faste regler, er imidlertid et vanlig skript ofte billigere å kjøre og lettere å stole på.

Tenk for eksempel på en distributør som håndterer en jevn strøm av produktforespørsler. Kundene beskriver den samme varen på alle mulige måter, så et generativt AI-verktøy kan forstå forespørslene deres, hente frem de relevante spesifikasjonene og utarbeide et svar. Lagerbeholdningen er en annen sak. Den må hentes fra sanntids lageroppføringer, mens en oppgitt pris må følge selskapets prisregler, ikke et hvilket som helst tall modellen tilfeldigvis kommer frem til.

Det er verdt å holde denne arbeidsdelingen klar: la modellen arbeide med språk og overlat forutsigbare operasjoner til konvensjonell programvare der det er mulig.

Før utviklingen starter, må du avklare hva som faktisk skal forbedres. Salgspersonalet trenger kanskje færre minutter på å sette sammen et tilbud; kundene kan kanskje få svar uten å måtte vente på en kundeservicemedarbeider. Uansett bør du dokumentere hvordan prosessen fungerer i dag. Ellers kan et team ende opp med å feire innføringen av det nye AI-grensesnittet uten å vite om det faktisk har gjort arbeidet enklere.

Bygg eller kjøp: Hvor mye kontroll trenger du egentlig?

Valget mellom å bygge selv eller kjøpe ferdig presenteres ofte som et valg mellom fullstendig eierskap og bekvemmelighet. I praksis finnes det flere alternativer mellom disse to ytterpunktene.

Ferdige AI-verktøy er et fornuftig utgangspunkt når en bedrift trenger kjente funksjoner som skrivehjelp, møtereferater, dokumentanalyse eller generell forskning. Disse produktene krever vanligvis mindre utviklingsarbeid, og leverandørene tar seg av mye av den underliggende infrastrukturen. En bedrift kan teste om ansatte finner en funksjon nyttig uten først å finansiere et dedikert utviklingsprosjekt.

Problemene oppstår når et generisk verktøy må tilpasses en prosess det ikke er utviklet for. Det kan for eksempel hende at det ikke kommuniserer med en eldre database, eller at det ikke tildeler riktige tilgangstillatelser når ansatte har ulike roller. Resultatene kan også måtte bearbeides før et annet forretningssystem kan bruke dem. API-er og konfigurasjonsalternativer kan bidra til å fylle disse hullene, men de vil ikke nødvendigvis dekke alle særegenhetene i en etablert arbeidsflyt.

Et skreddersydd AI-produkt blir mer forsvarlig når selve arbeidsflyten utgjør et konkurransefortrinn, når eksisterende produkter ikke kan oppfylle et vesentlig krav, eller når applikasjonen krever tett integrasjon med proprietære data og interne systemer.

Et tredje alternativ er å bygge din egen applikasjon rundt en modell som driftes av en ekstern leverandør. Bedriften utvikler grensesnittet og logikken bak det, kobler systemet til sin eksisterende programvare og setter opp sin egen måte å teste resultatene på. Selve modellen nås via et API, så det er ikke nødvendig å trene en grunnmodell fra bunnen av. Dette gir bedriften rom til å tilpasse produktet til sin egen arbeidsflyt, selv om det fortsatt avhenger av leverandørens priser, modellens tilgjengelighet og tjenestebegrensninger.

Dette siste skillet fortjener oppmerksomhet. Å utvikle en tilpasset AI-applikasjon og å utvikle en ny AI-modell er to forskjellige oppgaver. Å trene en grunnmodell krever betydelige databehandlingsressurser, spesialisert kompetanse, egnede data og kontinuerlig eksperimentering. De fleste bedrifter trenger ikke å påta seg den byrden. En eksisterende modell, supplert med henting av data fra bedriftens dokumenter eller nøye utformet tilgang til verktøy, kan være tilstrekkelig.

Velg arkitekturen ut fra arbeidsflyten

Når forretningsgrunnlaget er klart, er den neste utfordringen å bestemme hvordan applikasjonen skal fungere. Modellen er bare én komponent, og det er ikke sikkert at det er den komponenten som krever mest utviklingstid.

For en dokumentassistent er det ofte verdt å vurdere «retrieval-augmented generation» (RAG). I stedet for å stole utelukkende på det en modell har lært under opplæringen, henter applikasjonen relevante utdrag fra en godkjent informasjonskilde og inkluderer dem i spørsmålet. Modellen formulerer deretter et svar ved hjelp av dette materialet.

Svar som er forankret i interne retningslinjer eller aktuell produktinformasjon kan være mer relevante, forutsatt at søkefunksjonen fungerer som den skal. Det er ikke sikkert. Søket kan hente frem et foreldet dokument, overse en avgjørende forbehold eller gi modellen et utdrag som den deretter tolker feil.

Gjenfinning må testes for seg selv. Hvordan dokumenter deles opp i deler kan påvirke hva systemet finner, og selv et godt søkeresultat er ubrukelig hvis det kommer fra en kilde brukeren ikke skal se. En ansattes tilgangsrettigheter må gjelde også i gjenfinningsprosessen, i stedet for å bli overstyrt fordi et søk tilfeldigvis avdekket begrenset materiale. Applikasjonen selv må håndheve autorisasjonen. Man bør ikke stole på at en modell tar den avgjørelsen.

Finjustering tjener et annet formål. Den kan bidra til å tilpasse modellens atferd, svarformat eller håndtering av gjentakende oppgavemønstre når egnede treningseksempler er tilgjengelige. Det er ikke en direkte erstatning for gjenfinning når hovedproblemet er tilgang til fakta i endring. En modell som er finjustert på fjorårets produktkatalog, vil ikke automatisk vite hva som har endret seg i dag morges.

En prompt og et modell-API kan være alt en applikasjon med smalt anvendelsesområde trenger, i hvert fall i begynnelsen. Det avhenger av hvor forutsigbare inndataene er og hva systemet forventes å gjøre med utdataene. Hvis hvert svar må sjekkes opp mot en stor mengde intern dokumentasjon, kan gjenfinning bli nødvendig; for en enklere oppgave kan det bare føre til ekstra belastning.

Hold den første versjonen enkel og prøv den på ekte forespørsler, ikke bare på polerte demo-inndata. Se hvordan den håndterer et vagt spørsmål eller manglende informasjon. Hvis den bløffer i stedet for å innrømme en mangel, er det noe du må fikse før du legger til flere bevegelige deler.