Hvornår du skal tilføje AI-funktioner til din app — og hvornår du skal lade være

Lige nu hviler der et stille pres på enhver produktejer om at skrue AI fast på alt, hvad de bygger. Investorer spørger til det. Konkurrenter sætter det i deres overskrifter. Et bestyrelsesmedlem videresender en artikel. Og sådan får en fuldt fungerende app et lille glimtende ikon og en chatboks, som ingen bad om, og som næsten ingen bruger. Funktionen lanceres, pressemeddelelsen sendes ud, og seks måneder senere er brugskurverne flade. Spørgsmålet handlede aldrig om, hvorvidt du <em>kunne</em> tilføje AI. Det handlede om, hvorvidt du burde.

Jeg bygger software og AI-funktioner til små og mellemstore virksomheder for at leve, hvilket betyder, at jeg har et økonomisk incitament til at sige til dig, at du skal tilføje AI til alt. Jeg vil gøre det modsatte. Det mest værdifulde, jeg kan tilbyde, er en måde at afgøre — før du binder budget — om en AI-funktion stille bærer sin vægt eller stille rådner. For nederlaget her er ikke dramatisk. AI-funktioner sprænger sjældent i luften. De sidder bare der, ubrugte og uelskede, og koster dig penge ved hvert API-kald og en smule troværdighed, hver gang en bruger prikker til dem og går videre.

Denne guide er den ramme, jeg faktisk bruger i de samtaler. Ingen buzzwords, ingen moderigtige modelnavne, intet foregivende om, at en sprogmodel er svaret på et spørgsmål, du endnu ikke har stillet. Bare en praktisk måde at beslutte, hvad der hører hjemme i din app, hvad der hører hjemme i almindelig kode, og hvad der hører hjemme i skraldespanden.

Hvorfor de fleste påklistrede AI-funktioner stille fejler

Når en AI-funktion flopper i et lille produkt, flopper den næsten aldrig, fordi modellen ikke var klog nok. Den flopper, fordi funktionen blev valgt af de forkerte grunde. Nogen ville have AI frem for at ville løse en bestemt, smertefuld ting, der tilfældigvis krævede AI. Teknologien var målet, og brugerens problem var en eftertanke. Brugere kan lugte det med det samme.

Det andet almindelige nederlag er mere subtilt: funktionen løser et reelt problem, men et problem, som almindelig kode kunne have løst billigere og mere pålideligt. En knap mærket ”AI-drevet”, der bare sorterer en liste efter dato, er en belastning, ikke en funktion. Du har taget noget deterministisk, gjort det langsommere, dyrere og af og til forkert, og så reklameret for nedgraderingen. Brugere bemærker også det.

Det tredje nederlag er tillid. AI-funktioner er probabilistiske — de har ret det meste af tiden og tager selvsikkert fejl en gang imellem. Hvis du slipper en sådan ind i et arbejdsflow, hvor et forkert svar er dyrt, og brugeren ikke har nogen måde at fange det på, har du ikke tilføjet en funktion, du har lagt en mine. Den gode nyhed er, at alle tre nederlagstyper er forudsigelige, hvilket betyder, at de kan undgås. Du skal bare stille de rigtige spørgsmål, før du begynder, ikke efter du har lanceret.

Den ærlige test: er dette virkelig et AI-problem?

Her er det mest nyttige filter, jeg kender. For enhver funktion, du fristes til at gøre ”smart”, så spørg: følger denne opgave faste regler, eller kræver den forståelse af rodet, menneskeligt input? Hvis opgaven følger regler — sortér efter dette, beregn det der, send en påmindelse to timer før — vil du have almindelig kode. Den er billigere, hurtigere, fuldt forudsigelig og hallucinerer aldrig. At kalde det AI er bare dyr markedsføring.

AI fortjener sin plads, hvor inputtet er ægte rodet og menneskeformet: fritekst, reglerne ikke kan forudse, billeder, tale, dokumenter i hundrede forskellige layouts, sprog der skal forstås frem for matches. Det er ting, der før var fuldstændig umulige at automatisere. Hvis din funktion bor der, er AI ikke en gimmick — det er den eneste praktiske måde at bygge den på. Færdigheden ligger i ærligt at skelne de to kategorier, især når der er pres for at kalde alt for AI.

Hvor AI virkelig hører hjemme i en app

Lad os blive konkrete. Efter års bygning af disse bliver en kort liste af mønstre ved med at bevise sit værd — ikke fordi de er moderigtige, men fordi den underliggende opgave virkelig handler om at forstå ustruktureret input. Det er de funktioner, brugere faktisk vender tilbage til.

• Forvandle fritekst til strukturerede data — læse en vidtløftig kundemail og trække ordren, adressen, deadlinen ud.
• Udkast til en første version — et svar, et resumé, en beskrivelse — som et menneske derefter redigerer, frem for at AI’en sender den uovervåget.
• Søgning, der forstår mening, ikke kun nøgleord, så brugere finder det rigtige dokument, selv når de formulerer det anderledes, end du arkiverede det.
• Klassificere eller dirigere en strøm af indkommende elementer — supportsager, mails, uploads — så det rigtige når det rigtige sted.
• Trække information ud af dokumenter og billeder: fakturaer, kvitteringer, formularer, fotos fra marken.
• Samtalebaseret hjælp over dine egne data, hvor en bruger stiller et almindeligt spørgsmål og får et svar forankret i dit indhold.

Læg mærke til mønstret. I hver eneste af disse er inputtet uforudsigeligt og menneskeligt, og en lille smule fejl er acceptabel, fordi et menneske er med i loopet, eller omkostningen ved en fejl er lav. Den kombination — rodet input, tilgivende indsats — er en AI-funktions naturlige hjem. Når du finder en opgave, der passer til begge halvdele, har du sandsynligvis fundet en funktion værd at bygge.

Hvor du skal lade AI være i fred

Lige så vigtigt er det at vide, hvor man ikke skal gribe ud efter AI, for den forkerte placering spilder ikke bare penge — den nedbryder aktivt den tillid, dit produkt har optjent. Nogle opgaver ser fristende ud og viser sig at være fælder.

Der er også en mere stille omkostning. Enhver AI-funktion er noget, du nu skal overvåge, evaluere og betale for ved hvert eneste kald. Tre AI-funktioner, dine brugere stoler på, er mere værd end ti, der en gang imellem gør dig forlegen. En model, der tager fejl foran en kunde på det forkerte tidspunkt, kan slette et års omhyggeligt opbygget troværdighed. Tilbageholdenhed her er ikke frygtsomhed — det er produktsans.

Et hurtigt kort: byg den, spring den over, eller gør det senere

For at gøre dette mindre abstrakt, så her er, hvordan en håndfuld almindelige ”lad os tilføje AI”-idéer plejer at falde ud, når du kører dem gennem testen ovenfor. Betragt det som et fornuftigt udgangspunkt at argumentere imod, ikke som evangelium.

Tabellens form er lærestregen. Ja’erne klynger sig sammen, hvor inputtet er rodet, og indsatsen er tilgivende. Nej’erne klynger sig sammen, hvor opgaven i virkeligheden er regelbaseret, eller hvor et forkert svar gør ondt, og ingen tjekker. Hvis du ærligt kan placere din idé på det gitter, har du allerede truffet størstedelen af beslutningen.

Timing: selv en god AI-funktion kan tilføjes for tidligt

Nogle gange passer funktionen ægte, og svaret er stadig ikke endnu. AI-funktioner har en lumsk forudsætning, som stiftere undervurderer: de er kun så gode som de data og det arbejdsflow, de hviler på. En semantisk søgning i dine dokumenter er vidunderlig — når dine dokumenter faktisk er organiserede. En assistent, der besvarer spørgsmål om dit produkt, er strålende — når dit produktindhold ikke er et modsigelsesfyldt rod. AI forstærker alt, hvad den bygges oven på, kaosset inklusive.

Så før du tilføjer det smarte lag, så sørg for, at det kedelige lag nedenunder er solidt. Hvis din kerneapp stadig finder fodfæste, er det som regel at låne fra den forkerte konto at hælde ingeniørtid i en AI-funktion. Den uglamourøse sandhed er, at det bedste tidspunkt at tilføje AI ofte er efter, du har sømmet grundlaget — når du har rigtige brugere, rigtige data og en klar, gentagen smerte, som AI er enestående egnet til at fjerne.

Hvordan du tilføjer en AI-funktion uden fortrydelse

Lad os sige, du har fundet en funktion, der består testen: rodet input, tilgivende indsats, solidt fundament nedenunder, en reel smerte at fjerne. Godt. Nu kommer den del, hvor teams enten bygger noget holdbart eller noget, de stille river ud næste år. Behandl det som et omhyggeligt eksperiment, ikke en lancering.

1. 1
   Skriv opgaven i én sætning

   ”Assistenten læser en indkommende mail og udfylder ordreformularen, som et menneske bekræfter.” Hvis du ikke kan skrive den sætning, er funktionen ikke klar — du er stadig forelsket i teknologien, ikke i opgaven.
2. 2
   Hold et menneske i loopet til at begynde med

   Lad AI’en lave udkast, foreslå eller forudfylde — og lad en person godkende. Du lærer, hvor den er pålidelig, og hvor den ikke er, før du nogensinde stoler på, at den handler alene, hvis du nogensinde gør.
3. 3
   Beslut, hvad der sker, når den tager fejl

   Probabilistiske funktioner har brug for et elegant nederlag. Hvordan bemærker brugeren det? Hvordan retter de det? En AI-funktion uden en synlig ”fortryd”- eller ”det er ikke rigtigt”-vej er en funktion, du ikke kan stole på i produktion.
4. 4
   Mål brug, ikke nyhedsværdi

   Hold øje med, om folk faktisk bruger den efter den første uge, og om den sparer den tid, du lovede. En funktion, der topper ved lancering og fladlinjer bagefter, fortæller dig noget. Lyt.
5. 5
   Vær villig til at fjerne den

   Hvis tallene siger, at den ikke gør sig fortjent til sin plads, så skær den væk. Et mindre produkt, der gør få ting pålideligt, slår et oppustet et fyldt med AI-funktioner, ingen rører.

Den røde tråd gennem alle fem trin er ydmyghed over for at tage fejl. Almindelig kode enten virker eller har en fejl, du retter. AI har ret det meste af tiden og tager fejl en gang imellem, for altid — det er dens natur, ikke en defekt, du kan lappe væk. Design funktionen omkring den virkelighed, og den bliver et aktiv. Lad som om AI’en altid har ret, og du har bygget den mine, vi talte om tidligere.

Det store billede: AI er et værktøj, ikke en strategi

Træd langt nok tilbage, og hele spørgsmålet bliver enklere. AI er et værktøj, på samme måde som en database eller en søgelinje er et værktøj. Du bygger ikke et produkt omkring at have en database; du bruger en database, hvor den gør produktet bedre. Den samme tilbageholdenhed tjener dig godt her. De virksomheder, der får reel værdi af AI, er ikke dem, der tilføjede mest af det — det er dem, der tilføjede det præcis de få steder, hvor det fjerner ægte friktion, og afstod alle andre steder.

Den tilbageholdenhed er i øvrigt også det, der får den AI, du rent faktisk tilføjer, til at føles imponerende. Når hver skærm har en halvbagt assistent, føles ingen af dem særlig. Når én funktion stille læser en kundes mail og sparer dit team ti minutter hver gang, husker folk den. Færre, skarpere, ægte nyttige — det er den version af AI, der er værd at bygge, og det er den version, dine brugere rent faktisk vil takke dig for.

Almindelige spørgsmål