Att utveckla en produkt med generativ AI: Vad man bör veta från början

Inledning

Generativ AI är lätt att prova på, men betydligt svårare att omvandla till en produkt som människor kan lita på. Ett team kan koppla en språkmodell till ett chattgränssnitt på några dagar. Att få det gränssnittet att hantera riktiga kundförfrågningar, respektera åtkomstbehörigheter, arbeta med företagsdata och återhämta sig från felaktiga svar är en helt annan sak.

För företag som överväger generativ AI för affärsapplikationer är det första beslutet inte vilken modell som ska användas. Det handlar om huruvida problemet överhuvudtaget kräver en ny produkt. Färdiga AI-verktyg kan täcka större delen av behovet, medan en skräddarsydd implementering är mer lämplig när befintlig programvara inte kan hantera det nödvändiga arbetsflödet. Företag som utvärderar det senare alternativet kan rådfråga SysGears ingenjörer inom generativ AI för att utforska de tekniska kraven för en produkt som är byggd kring just deras specifika användningsfall.

En produkt med generativ AI innebär betydligt mer än att bara placera en modell bakom ett gränssnitt med företagets varumärke. Modellen kanske hanterar språket, men resten av applikationen avgör vilken information den kan utgå ifrån, om den kan interagera med annan programvara och vad som händer när svaret inte träffar rätt. Dessa beslut påverkar produktens användbarhet lika mycket som själva valet av modell.

En intern assistent kan vilseleda medarbetarna om den hämtar ett föråldrat policydokument. Ger man den tillgång till kundregister blir åtkomstbehörigheterna lika viktiga som svarens kvalitet. Om applikationen dessutom kan ändra register kan ett övertygande men felaktigt svar orsaka verklig skada.

Det här är inte detaljer som kan åtgärdas i efterhand efter lanseringen. De påverkar arkitekturen, det tekniska arbetet och kostnaderna för AI-utvecklingen, inklusive vad som krävs för att hålla produkten igång. Ett företag bör gå igenom dessa frågor innan man satsar på utveckling, medan det fortfarande finns utrymme att begränsa omfattningen eller besluta att ett befintligt verktyg skulle klara uppgiften.

Börja med ett problem som kräver generativ AI

En övertygande demonstration kan dölja ett ganska vanligt affärsproblem. Om medarbetarna till exempel lägger för mycket tid på att söka i intern dokumentation kan ett semantiskt söksystem räcka. Om de behöver tolka långa dokument, extrahera specifika detaljer och utforma svar med hjälp av information från flera källor kan en språkmodell tillföra något mer väsentligt.

Denna distinktion är viktig redan från början. Generativ AI visar sitt värde när programvaran måste tolka rörigt, ostrukturerat material eller utarbeta något som är beroende av sammanhanget. För en uppgift som styrs av fasta regler är dock ett vanligt skript ofta billigare att köra och lättare att lita på.

Ta till exempel en distributör som hanterar en stadig ström av produktförfrågningar. Kunderna beskriver samma artikel på alla möjliga sätt, så en generativ AI-applikation skulle kunna tolka deras förfrågningar, hämta fram relevanta specifikationer och utforma ett svar. Lagernivåer är en annan sak. De måste hämtas från aktuella lagerregister, medan ett angivet pris måste följa företagets prissättningsregler, inte vilken siffra modellen råkar producera.

Denna arbetsfördelning är värd att hålla tydlig: låt modellen hantera språket och överlåt förutsägbara arbetsuppgifter till konventionell programvara där det är möjligt.

Innan utvecklingen påbörjas, fastställ vad som faktiskt ska förbättras. Säljpersonalen kanske behöver mindre tid för att sammanställa en offert; kunderna kanske får svar utan att behöva vänta på en supportmedarbetare. Oavsett vilket, dokumentera hur processen fungerar idag. Annars kan ett team hamna i en situation där de firar införandet av sitt nya AI-gränssnitt utan att veta om det verkligen har underlättat arbetet.

Bygga eller köpa: Hur mycket kontroll behöver du egentligen?

Beslutet om att bygga eller köpa framställs ofta som ett val mellan fullständig äganderätt och bekvämlighet. I praktiken finns det flera alternativ däremellan.

Färdiga AI-verktyg är en rimlig utgångspunkt när ett företag behöver välbekanta funktioner som skrivhjälp, mötesreferat, dokumentanalys eller allmän forskning. Dessa produkter kräver vanligtvis mindre tekniskt arbete, och leverantörerna sköter en stor del av den underliggande infrastrukturen. Ett företag kan testa om medarbetarna tycker att en funktion är användbar utan att först finansiera ett särskilt utvecklingsprojekt.

Problemen uppstår när ett generiskt verktyg måste anpassas till en process som det inte är utformat för. Det kanske till exempel inte kan kommunicera med en äldre databas eller tillämpa rätt åtkomstbehörigheter när medarbetarna har olika roller. Resultatet kan också behöva omformas innan ett annat affärssystem kan använda det. API:er och konfigurationsalternativ kan hjälpa till att överbrygga dessa luckor, men de täcker inte nödvändigtvis alla särdrag i ett etablerat arbetsflöde.

En skräddarsydd AI-produkt blir mer motiverad när arbetsflödet i sig utgör en konkurrensfördel, när befintliga produkter inte kan uppfylla ett väsentligt krav eller när applikationen kräver tät integration med företagsspecifika data och interna system.

Ett tredje alternativ är att bygga en egen applikation kring en modell som drivs av en extern leverantör. Företaget utvecklar gränssnittet och logiken bakom det, kopplar in systemet i sin befintliga programvara och sätter upp sitt eget sätt att testa resultaten. Modellen nås via ett API, så det finns inget behov av att träna en basmodell från grunden. Detta ger företaget utrymme att anpassa produkten efter sitt arbetsflöde, även om det fortfarande är beroende av leverantörens prissättning, modellens tillgänglighet och tjänstens begränsningar.

Den sista distinktionen förtjänar uppmärksamhet. Att utveckla en anpassad AI-applikation och att utveckla en ny AI-modell är två olika saker. Att träna en basmodell kräver betydande datorkraft, specialiserad expertis, lämpliga data och kontinuerligt experimenterande. De flesta företag behöver inte ta på sig den bördan. En befintlig modell, kompletterad med hämtning från företagets dokument eller noggrant utformad åtkomst till verktyg, kan vara tillräcklig.

Välj arkitekturen utifrån arbetsflödet

När affärsnyttan är klar är nästa utmaning att bestämma hur applikationen ska fungera. Modellen är bara en komponent, och det är kanske inte den komponent som tar mest utvecklingstid i anspråk.

För en dokumentassistent är det ofta värt att överväga RAG (retrieval-augmented generation). Istället för att enbart förlita sig på vad en modell lärt sig under träningen hämtar applikationen relevanta avsnitt från en godkänd informationskälla och inkluderar dem i prompten. Modellen formulerar sedan ett svar med hjälp av det materialet.

Svar som grundar sig på interna riktlinjer eller aktuell produktinformation kan vara mer relevanta, förutsatt att informationshämtningen fungerar som den ska. Det är dock inte säkert. Sökningen kan hämta ett föråldrat dokument, missa en viktig reservation eller ge modellen ett utdrag som den sedan tolkar felaktigt.

Sökfunktionen måste testas för sig. Hur dokument delas upp i delar kan påverka vad systemet hittar, och även ett bra sökresultat är värdelöst om det kommer från en källa som användaren inte ska se. En anställds åtkomsträttigheter måste gälla även i sökprocessen, istället för att åsidosättas bara för att en sökning råkade visa material med begränsad åtkomst. Applikationen själv måste se till att behörigheten efterlevs. Man bör inte lita på att en modell fattar det beslutet.

Finjustering tjänar ett annat syfte. Den kan hjälpa till att anpassa en modells beteende, svarsformat eller hantering av återkommande uppgiftsmönster när lämpliga tränings exempel finns tillgängliga. Det är inte en direkt ersättning för informationshämtning när huvudproblemet är åtkomst till föränderliga fakta. En modell som finjusterats utifrån förra årets produktkatalog kommer inte automatiskt att veta vad som ändrats i morse.

En prompt och ett modell-API kan vara allt som en applikation med snävt omfång behöver, åtminstone till en början. Det beror på hur förutsägbara indata är och vad systemet förväntas göra med sina utdata. Om varje svar måste kontrolleras mot en stor mängd intern dokumentation kan informationshämtning bli nödvändig; för en enklare uppgift kan det bara innebära extra arbetsbörda.

Håll den första versionen enkel och testa den på riktiga förfrågningar, inte bara på polerade demodata. Se hur den hanterar en vag fråga eller saknad information. Om den bluffar istället för att erkänna en brist är det något som måste åtgärdas innan fler rörliga delar läggs till.