Når du bør legge til AI-funksjoner i appen din — og når du bør la være

Akkurat nå hviler det et stille press på enhver produkteier om å skru AI fast på hva enn de bygger. Investorer spør om det. Konkurrenter setter det i overskriftene sine. Et styremedlem videresender en artikkel. Og slik får en fullt fungerende app et lite glitrende ikon og en chatboks som ingen ba om, og som nesten ingen bruker. Funksjonen lanseres, pressemeldingen går ut, og seks måneder senere er brukskurvene flate. Spørsmålet handlet aldri om hvorvidt du <em>kunne</em> legge til AI. Det handlet om hvorvidt du burde.

Jeg bygger programvare og AI-funksjoner for små og mellomstore bedrifter for å leve, noe som betyr at jeg har et økonomisk insentiv til å si til deg at du skal legge AI på alt. Jeg skal gjøre det motsatte. Det mest verdifulle jeg kan tilby, er en måte å avgjøre — før du binder budsjett — om en AI-funksjon stille bærer sin egen vekt eller stille råtner. For nederlaget her er ikke dramatisk. AI-funksjoner sprenger sjelden i luften. De bare sitter der, ubrukte og uelskede, og koster deg penger ved hvert API-kall og litt troverdighet hver gang en bruker pirker borti dem og går videre.

Denne guiden er rammeverket jeg faktisk bruker i de samtalene. Ingen moteord, ingen moteriktige modellnavn, ingen forestilling om at en språkmodell er svaret på et spørsmål du ennå ikke har stilt. Bare en praktisk måte å avgjøre hva som hører hjemme i appen din, hva som hører hjemme i vanlig kode, og hva som hører hjemme i søpla.

Hvorfor de fleste påklistrede AI-funksjoner stille feiler

Når en AI-funksjon floppet i et lite produkt, floppet den nesten aldri fordi modellen ikke var smart nok. Den floppet fordi funksjonen ble valgt av feil grunner. Noen ville ha AI, snarere enn å ville løse en bestemt, smertefull ting som tilfeldigvis trengte AI. Teknologien var målet, og brukerens problem var en ettertanke. Brukere lukter det med en gang.

Det andre vanlige nederlaget er mer subtilt: funksjonen løser et reelt problem, men et problem som vanlig kode kunne ha løst billigere og mer pålitelig. En knapp merket «AI-drevet» som bare sorterer en liste etter dato, er en belastning, ikke en funksjon. Du har tatt noe deterministisk, gjort det tregere, dyrere og av og til feil, og så reklamert for nedgraderingen. Brukere legger merke til det også.

Det tredje nederlaget er tillit. AI-funksjoner er sannsynlighetsbaserte — de har rett mesteparten av tiden og tar selvsikkert feil av og til. Hvis du slipper en slik inn i en arbeidsflyt der et feil svar er dyrt og brukeren ikke har noen måte å fange det på, har du ikke lagt til en funksjon, du har lagt ut en mine. Den gode nyheten er at alle tre nederlagstypene er forutsigbare, noe som betyr at de kan unngås. Du må bare stille de riktige spørsmålene før du begynner, ikke etter at du har lansert.

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

Her er det mest nyttige filteret jeg kjenner. For enhver funksjon du fristes til å gjøre «smart», spør: følger denne oppgaven faste regler, eller krever den forståelse av rotete, menneskelig input? Hvis oppgaven følger regler — sorter etter dette, beregn det der, send en påminnelse to timer før — vil du ha vanlig kode. Den er billigere, raskere, fullt forutsigbar og hallusinerer aldri. Å kalle det AI er bare dyr markedsføring.

AI fortjener plassen sin der inputen er genuint rotete og menneskeformet: fritekst reglene ikke kan forutse, bilder, tale, dokumenter i hundre forskjellige oppsett, språk som må forstås snarere enn matches. Dette er ting som før var fullstendig umulige å automatisere. Hvis funksjonen din bor der, er AI ikke en gimmick — det er den eneste praktiske måten å bygge den på. Ferdigheten ligger i å ærlig skille de to kategoriene, særlig når det er press for å kalle alt for AI.

Der AI virkelig hører hjemme i en app

La oss bli konkrete. Etter år med å bygge disse fortsetter en kort liste med mønstre å bevise verdien sin — ikke fordi de er moteriktige, men fordi den underliggende oppgaven virkelig handler om å forstå ustrukturert input. Dette er funksjonene brukere faktisk vender tilbake til.

• Gjøre fritekst om til strukturerte data — lese en vidløftig kunde-e-post og trekke ut bestillingen, adressen, fristen.
• Lage et utkast til en første versjon — et svar, et sammendrag, en beskrivelse — som et menneske deretter redigerer, snarere enn at AI-en sender det uten tilsyn.
• Søk som forstår mening, ikke bare nøkkelord, slik at brukere finner det riktige dokumentet selv når de formulerer det annerledes enn du arkiverte det.
• Klassifisere eller dirigere en strøm av innkommende elementer — supportsaker, e-poster, opplastinger — slik at det riktige når det riktige stedet.
• Trekke informasjon ut av dokumenter og bilder: fakturaer, kvitteringer, skjemaer, bilder fra felten.
• Samtalebasert hjelp over dine egne data, der en bruker stiller et enkelt spørsmål og får et svar forankret i innholdet ditt.

Legg merke til mønsteret. I hver eneste av disse er inputen uforutsigbar og menneskelig, og litt feil er til å leve med fordi et menneske er med i loopen eller kostnaden ved en feil er lav. Den kombinasjonen — rotete input, tilgivende innsats — er en AI-funksjons naturlige hjem. Når du finner en oppgave som passer begge halvdeler, har du sannsynligvis funnet en funksjon verdt å bygge.

Der du bør la AI være i fred

Like viktig er det å vite hvor man ikke bør strekke seg etter AI, for feil plassering sløser ikke bare penger — den bryter aktivt ned tilliten produktet ditt har opptjent. Noen oppgaver ser fristende ut og viser seg å være feller.

Det finnes en stillere kostnad også. Enhver AI-funksjon er noe du nå må overvåke, evaluere og betale for ved hvert eneste kall. Tre AI-funksjoner brukerne dine stoler på, er mer verdt enn ti som av og til gjør deg flau. En modell som tar feil foran en kunde på feil tidspunkt, kan slette et år med omhyggelig oppbygd troverdighet. Tilbakeholdenhet her er ikke feighet — det er produktsans.

Et raskt kart: bygg den, hopp over den, eller gjør det senere

For å gjøre dette mindre abstrakt, så her er hvordan en håndfull vanlige «la oss legge til AI»-idéer pleier å falle ut når du kjører dem gjennom testen over. Betrakt det som et fornuftig utgangspunkt å argumentere mot, ikke som evangelium.

Tabellens form er lærepengen. Ja-ene klynger seg der inputen er rotete og innsatsen er tilgivende. Nei-ene klynger seg der oppgaven egentlig er regelbasert, eller der et feil svar gjør vondt og ingen sjekker. Hvis du ærlig kan plassere idéen din på det rutenettet, har du allerede tatt størstedelen av beslutningen.

Timing: selv en god AI-funksjon kan legges til for tidlig

Noen ganger passer funksjonen genuint, og svaret er likevel ikke ennå. AI-funksjoner har en lurvete forutsetning som gründere undervurderer: de er bare så gode som dataene og arbeidsflyten de hviler på. Et semantisk søk i dokumentene dine er fantastisk — når dokumentene dine faktisk er organiserte. En assistent som svarer på spørsmål om produktet ditt, er strålende — når produktinnholdet ditt ikke er et selvmotsigende rot. AI forsterker alt den bygges oppå, kaoset inkludert.

Så før du legger til det smarte laget, sørg for at det kjedelige laget under er solid. Hvis kjerneappen din fremdeles finner fotfeste, er det som regel å låne fra feil konto å helle ingeniørtid i en AI-funksjon. Den uglamorøse sannheten er at det beste tidspunktet å legge til AI ofte er etter at du har spikret grunnlaget — når du har ekte brukere, ekte data og en klar, gjentakende smerte som AI er unikt egnet til å fjerne.

Hvordan du legger til en AI-funksjon uten å angre

La oss si du har funnet en funksjon som består testen: rotete input, tilgivende innsats, solid fundament under, en ekte smerte å fjerne. Bra. Nå kommer delen der team enten bygger noe holdbart eller noe de stille river ut neste år. Behandle det som et omhyggelig eksperiment, ikke en lansering.

1. 1
   Skriv oppgaven i én setning

   «Assistenten leser en innkommende e-post og fyller ut bestillingsskjemaet, som et menneske bekrefter.» Hvis du ikke kan skrive den setningen, er ikke funksjonen klar — du er fortsatt forelsket i teknologien, ikke i oppgaven.
2. 2
   Hold et menneske i loopen til å begynne med

   La AI-en lage utkast, foreslå eller forhåndsutfylle — og la en person godkjenne. Du lærer hvor den er pålitelig og hvor den ikke er det før du noensinne stoler på at den handler alene, hvis du noensinne gjør det.
3. 3
   Bestem hva som skjer når den tar feil

   Sannsynlighetsbaserte funksjoner trenger et elegant nederlag. Hvordan legger brukeren merke til det? Hvordan retter de det? En AI-funksjon uten en synlig «angre»- eller «det er ikke riktig»-vei er en funksjon du ikke kan stole på i produksjon.
4. 4
   Mål bruk, ikke nyhetsverdi

   Følg med på om folk faktisk bruker den etter den første uken, og om den sparer tiden du lovet. En funksjon som topper ved lansering og flater ut etterpå, forteller deg noe. Lytt.
5. 5
   Vær villig til å fjerne den

   Hvis tallene sier at den ikke gjør seg fortjent til plassen sin, så kutt den. Et mindre produkt som gjør noen få ting pålitelig, slår et oppblåst et fylt med AI-funksjoner ingen rører.

Den røde tråden gjennom alle fem trinnene er ydmykhet overfor å ta feil. Vanlig kode enten fungerer eller har en feil du retter. AI har rett mesteparten av tiden og tar feil av og til, for alltid — det er dens natur, ikke en defekt du kan lappe vekk. Design funksjonen rundt den virkeligheten, og den blir et aktivum. Lat som om AI-en alltid har rett, og du har bygd den minen vi snakket om tidligere.

Det større bildet: AI er et verktøy, ikke en strategi

Tre langt nok tilbake, og hele spørsmålet blir enklere. AI er et verktøy, på samme måte som en database eller en søkelinje er et verktøy. Du bygger ikke et produkt rundt det å ha en database; du bruker en database der den gjør produktet bedre. Den samme tilbakeholdenheten tjener deg godt her. Selskapene som får ekte verdi av AI, er ikke de som la til mest av det — det er de som la det til på akkurat de få stedene der det fjerner ekte friksjon, og avsto overalt ellers.

Den tilbakeholdenheten er for øvrig også det som får AI-en du faktisk legger til, til å føles imponerende. Når hver skjerm har en halvferdig assistent, føles ingen av dem spesielle. Når én funksjon stille leser en kundes e-post og sparer teamet ditt ti minutter hver gang, husker folk den. Færre, skarpere, ekte nyttige — det er den versjonen av AI som er verdt å bygge, og det er den versjonen brukerne dine faktisk vil takke deg for.

Vanlige spørsmål