När du ska lägga till AI-funktioner i din app — och när du ska låta bli

Just nu vilar ett tyst tryck på varje produktägare att skruva fast AI på vad de än bygger. Investerare frågar om det. Konkurrenter sätter det i sina rubriker. En styrelseledamot vidarebefordrar en artikel. Och så får en fullt fungerande app en liten gnistrande ikon och en chattruta som ingen bad om och som nästan ingen använder. Funktionen lanseras, pressmeddelandet går ut, och sex månader senare är användningskurvorna platta. Frågan handlade aldrig om huruvida du <em>kunde</em> lägga till AI. Den handlade om huruvida du borde.

Jag bygger mjukvara och AI-funktioner åt små och medelstora företag för mitt levebröd, vilket betyder att jag har ett ekonomiskt incitament att säga åt dig att lägga AI på allt. Jag tänker göra tvärtom. Det mest värdefulla jag kan erbjuda är ett sätt att avgöra — innan du binder budget — om en AI-funktion tyst kommer att bära sin vikt eller tyst ruttna. För haveriet här är inte dramatiskt. AI-funktioner exploderar sällan. De bara sitter där, oanvända och oälskade, och kostar dig pengar vid varje API-anrop och lite trovärdighet varje gång en användare petar på dem och går därifrån.

Den här guiden är ramverket jag faktiskt använder i de samtalen. Inga modeord, inga moderiktiga modellnamn, inget låtsas om att en språkmodell är svaret på en fråga du ännu inte ställt. Bara ett praktiskt sätt att avgöra vad som hör hemma i din app, vad som hör hemma i vanlig kod och vad som hör hemma i papperskorgen.

Varför de flesta påklistrade AI-funktioner tyst misslyckas

När en AI-funktion floppar i en liten produkt floppar den nästan aldrig för att modellen inte var smart nog. Den floppar för att funktionen valdes av fel skäl. Någon ville ha AI, snarare än att vilja lösa en specifik, smärtsam sak som råkade behöva AI. Tekniken var målet, och användarens problem var en eftertanke. Användare känner det på direkten.

Det andra vanliga haveriet är mer subtilt: funktionen löser ett verkligt problem, men ett problem som vanlig kod kunde ha löst billigare och mer pålitligt. En knapp märkt ”AI-driven” som bara sorterar en lista efter datum är en belastning, inte en funktion. Du har tagit något deterministiskt, gjort det långsammare, dyrare och ibland fel, och sedan annonserat nedgraderingen. Användare märker det också.

Det tredje haveriet är förtroende. AI-funktioner är probabilistiska — de har rätt för det mesta och fel med självförtroende ibland. Om du släpper in en sådan i ett arbetsflöde där ett felaktigt svar är dyrt och användaren inte har något sätt att fånga det, har du inte lagt till en funktion, du har lagt ut en mina. Den goda nyheten är att alla tre haverityper är förutsägbara, vilket betyder att de går att undvika. Du måste bara ställa rätt frågor innan du börjar, inte efter att du lanserat.

Det ärliga testet: är detta verkligen ett AI-problem?

Här är det mest användbara filter jag känner till. För varje funktion du frestas att göra ”smart”, fråga: följer den här uppgiften fasta regler, eller kräver den förståelse av rörigt, mänskligt indata? Om uppgiften följer regler — sortera efter detta, beräkna det där, skicka en påminnelse två timmar innan — vill du ha vanlig kod. Den är billigare, snabbare, fullt förutsägbar och hallucinerar aldrig. Att kalla det AI är bara dyr marknadsföring.

AI förtjänar sin plats där indatat är genuint rörigt och människoformat: fritext som reglerna inte kan förutse, bilder, tal, dokument i hundra olika layouter, språk som behöver förstås snarare än matchas. Detta är saker som förr var helt omöjliga att automatisera. Om din funktion bor där är AI inte en gimmick — det är det enda praktiska sättet att bygga den. Skickligheten ligger i att ärligt skilja de två kategorierna åt, särskilt när det finns tryck att kalla allt för AI.

Där AI verkligen hör hemma i en app

Låt oss bli konkreta. Efter år av att bygga dessa fortsätter en kort lista mönster att bevisa sitt värde — inte för att de är moderiktiga, utan för att den underliggande uppgiften verkligen handlar om att förstå ostrukturerat indata. Det här är funktionerna som användare faktiskt återvänder till.

• Förvandla fritext till strukturerad data — läsa ett spretigt kundmejl och plocka ut beställningen, adressen, deadlinen.
• Skissa en första version — ett svar, en sammanfattning, en beskrivning — som en människa sedan redigerar, snarare än att AI:n skickar den oövervakad.
• Sök som förstår betydelse, inte bara nyckelord, så att användare hittar rätt dokument även när de formulerar det annorlunda än du arkiverade det.
• Klassificera eller dirigera en flod av inkommande poster — supportärenden, mejl, uppladdningar — så att rätt sak når rätt plats.
• Plocka ut information ur dokument och bilder: fakturor, kvitton, formulär, foton från fältet.
• Konversationshjälp över din egen data, där en användare ställer en enkel fråga och får ett svar grundat i ditt innehåll.

Lägg märke till mönstret. I var och en av dessa är indatat oförutsägbart och mänskligt, och en liten mängd fel är acceptabel eftersom en person finns med i loopen eller kostnaden för ett misstag är låg. Den kombinationen — rörigt indata, förlåtande insatser — är en AI-funktions naturliga hem. När du hittar en uppgift som passar båda halvorna har du förmodligen hittat en funktion värd att bygga.

Där du ska låta AI vara i fred

Lika viktigt är att veta var man inte ska sträcka sig efter AI, för fel placering slösar inte bara pengar — den eroderar aktivt det förtroende din produkt har förtjänat. Vissa uppgifter ser frestande ut och visar sig vara fällor.

Det finns en tystare kostnad också. Varje AI-funktion är något du nu måste övervaka, utvärdera och betala för vid varje enskilt anrop. Tre AI-funktioner som dina användare litar på är värda mer än tio som då och då gör dig generad. En modell som har fel framför en kund vid fel tillfälle kan radera ut ett år av omsorgsfullt byggd trovärdighet. Återhållsamhet här är inte feghet — det är produktkänsla.

En snabb karta: bygg den, hoppa över den eller gör det senare

För att göra detta mindre abstrakt, så här brukar en handfull vanliga ”låt oss lägga till AI”-idéer falla ut när du kör dem genom testet ovan. Betrakta det som ett vettigt utgångsläge att argumentera mot, inte som evangelium.

Tabellens form är läxan. Ja-svaren klustrar där indatat är rörigt och insatserna är förlåtande. Nej-svaren klustrar där uppgiften egentligen är regelbaserad, eller där ett felaktigt svar gör ont och ingen kontrollerar. Om du kan placera din idé på det rutnätet ärligt har du redan fattat större delen av beslutet.

Tajming: även en bra AI-funktion kan läggas till för tidigt

Ibland passar funktionen genuint och svaret är ändå inte än. AI-funktioner har en lömsk förutsättning som grundare underskattar: de är bara så bra som datan och arbetsflödet de vilar på. En semantisk sökning i dina dokument är underbar — när dina dokument faktiskt är organiserade. En assistent som svarar på frågor om din produkt är briljant — när ditt produktinnehåll inte är en motsägelsefull röra. AI förstärker allt den byggs ovanpå, kaoset inkluderat.

Så innan du lägger till det smarta lagret, se till att det tråkiga lagret under är gediget. Om din kärnapp fortfarande hittar fotfästet är det oftast att låna från fel konto att hälla ingenjörstid i en AI-funktion. Den oglamorösa sanningen är att den bästa tiden att lägga till AI ofta är efter att du spikat grunderna — när du har riktiga användare, riktig data och en tydlig, återkommande smärta som AI är unikt lämpad att ta bort.

Hur du lägger till en AI-funktion utan att ångra dig

Säg att du hittat en funktion som klarar testet: rörigt indata, förlåtande insatser, gedigen grund under, en verklig smärta att ta bort. Bra. Nu till delen där team antingen bygger något hållbart eller något de tyst river ut nästa år. Behandla det som ett omsorgsfullt experiment, inte en lansering.

1. 1
   Skriv ner uppgiften i en mening

   ”Assistenten läser ett inkommande mejl och fyller i orderformuläret, som en människa bekräftar.” Om du inte kan skriva den meningen är funktionen inte redo — du är fortfarande förälskad i tekniken, inte i uppgiften.
2. 2
   Håll en människa i loopen till en början

   Låt AI:n skissa, föreslå eller förifylla — och låt en person godkänna. Du lär dig var den är pålitlig och var den inte är det innan du någonsin litar på att den agerar ensam, om du någonsin gör det.
3. 3
   Bestäm vad som händer när den har fel

   Probabilistiska funktioner behöver ett elegant misslyckande. Hur märker användaren det? Hur rättar de det? En AI-funktion utan en synlig ”ångra”- eller ”det där är inte rätt”-väg är en funktion du inte kan lita på i produktion.
4. 4
   Mät användning, inte nyhetsvärde

   Spåra om folk faktiskt använder den efter första veckan, och om den sparar tiden du lovade. En funktion som toppar vid lansering och planar ut efteråt säger dig något. Lyssna.
5. 5
   Var beredd att ta bort den

   Om siffrorna säger att den inte gör sig förtjänt av sin plats, skär bort den. En mindre produkt som gör några få saker pålitligt slår en uppsvälld nedlusad med AI-funktioner ingen rör.

Den röda tråden genom alla fem stegen är ödmjukhet inför att ha fel. Vanlig kod antingen fungerar eller har en bugg du rättar. AI har rätt för det mesta och fel ibland, för alltid — det är dess natur, inte en defekt du kan lappa bort. Designa funktionen runt den verkligheten och den blir en tillgång. Låtsas att AI:n alltid har rätt och du har byggt den mina vi pratade om tidigare.

Den större bilden: AI är ett verktyg, inte en strategi

Ta ett steg tillbaka tillräckligt långt och hela frågan blir enklare. AI är ett verktyg, på samma sätt som en databas eller en sökruta är ett verktyg. Du bygger inte en produkt kring att ha en databas; du använder en databas där den gör produkten bättre. Samma återhållsamhet tjänar dig väl här. Företagen som får verkligt värde av AI är inte de som lade till mest av det — det är de som lade till det på exakt de få ställen där det tar bort genuin friktion, och avstod överallt annars.

Den återhållsamheten är förresten också det som får den AI du faktiskt lägger till att kännas imponerande. När varje skärm har en halvfärdig assistent känns ingen av dem speciell. När en funktion tyst läser en kunds mejl och sparar ditt team tio minuter varje gång, kommer folk ihåg den. Färre, skarpare, genuint användbara — det är den version av AI som är värd att bygga, och det är den version dina användare faktiskt kommer att tacka dig för.

Vanliga frågor