Den første AI-opgave starter ved indgangen

Den første AI-opgave i en virksomhed bliver lettest at afgrænse, hvis I begynder med det, der kommer ind, og ikke med det, I håber kommer ud. Vi anbefaler, at I vælger en opgave med én fast indgang, typisk en formular, hvor I selv bestemmer, hvilke oplysninger der er obligatoriske, og hvilke der er valgfrie.

Grunden er enkel. En mail kan indeholde hvad som helst, i hvilken som helst rækkefølge. En formular sætter rammen, før modellen eller medarbejderen går i gang. Dermed bliver det også muligt at aftale, hvem der svarer for resultatet, og hvordan I tester, om opgaven bliver løst.

Kort og enkelt er et krav til inputtet

W3C's vejledning om tilgængelige formularer siger, at formularer bør være enkle og korte og kun bede om de oplysninger, der er nødvendige, så brugerne ikke opgiver undervejs. Vejledningen er skrevet til udviklere, men princippet passer direkte på en første AI-opgave: hvert felt I tilføjer, er et felt, nogen skal udfylde, og som nogen skal bruge til noget.

Samme vejledning deler emnet op i syv dele. Fire af dem er nyttige, når I afgrænser opgaven: tydelige feltnavne, instruktioner til de enkelte felter, kontrol af det indtastede med mulighed for at rette, og besked til brugeren om, at noget lykkedes eller fejlede. Lange formularer kan ifølge vejledningen deles i logiske trin med en visning af, hvor langt man er nået.

Vores egen estimatside er et eksempel på den afgrænsning. Den har tre trin: en beskrivelse med jeres egne ord, en opgavetype med mulighed for vedhæftede filer, og kontaktoplysninger. Kun beskrivelse, navn og e-mail er påkrævet. Virksomhed, telefon og budgetramme er valgfrie. Bagefter stiller en AI-medarbejder et par opfølgende spørgsmål på siden.

Skriv hvad opgaven ikke dækker

Den anden halvdel af afgrænsningen er at sige, hvad opgaven lader ligge. Vores hjemmeside-eftersyn er bygget på den måde. Kunden sender adresse, navn og e-mail og kan valgfrit beskrive et problem. Gennemgangen dækker kun offentligt indhold, og siden skriver selv, at faktiske frafald og konverteringstal kræver adgang til analysedata og ikke indgår.

Den slags sætning sparer en diskussion senere. Når grænsen står skrevet, ved begge parter, hvad et resultat kan bygge på. Vi anbefaler, at I skriver en tilsvarende sætning for jeres første opgave, fx at modellen kun læser selve henvendelsen og ikke kundens historik i jeres system.

Eftersynet viser også, hvordan output kan afgrænses. Hvert forslag består af en observation, en anbefaling, den del af kunderejsen der påvirkes, og en prioritet. Et fast format gør det muligt at vurdere resultatet punkt for punkt i stedet for at bedømme en samlet tekst.

Tre aftaler før den første prøve

Når indgang og grænse er på plads, mangler der tre aftaler. De er vores anbefaling og ikke hentet fra en kilde, men de bygger direkte på de to ovenstående punkter.

1. Ansvar: én navngiven medarbejder ejer opgaven og afgør, hvad der sker, når modellen er i tvivl eller et påkrævet felt mangler.
2. Fejlbesked: afsenderen får besked, hvis noget ikke kan behandles, og ved hvad der skal rettes. Det følger W3C's anbefaling om at give besked om både succes og fejl.
3. Prøve: I samler et antal rigtige henvendelser fra jeres egen arbejdsgang, lader opgaven køre på dem og sammenligner resultatet med det, medarbejderen selv ville have gjort.

Prøven skal foregå på jeres egne sager og ikke på en demo. Det er først der, I ser, om felterne passer til de henvendelser, I faktisk får.

Ofte stillede spørgsmål