Nästan varje gång någon vill bygga AI börjar samtalet med vilken modell man ska välja. Jag brukar försöka flytta det samtalet till något annat: vem ska faktiskt använda det här, och hur märker de om det blir fel?

”Vi vill att AI hjälper supporten” låter bra, men går inte att testa. ”Hitta rätt instruktion och föreslå ett svar som handläggaren godkänner” går att prova på en vecka.

Och ärligt talat stoppas fler projekt av att ingen kan kontrollera svaret, eller att datan inte får användas, än av modellvalet. Ibland är bättre sökning eller en enkel regel hela lösningen.

När arbetet bara känns långsamt

Det är lätt att blanda ihop att arbetet känns långsamt med att det är värt att bygga något nytt. Väntan kan bero på att ingen äger frågan, att uppgifter saknas eller att allt fastnar i en kö för godkännande. En språkmodell löser inte automatiskt något av det. Jag skulle först rita upp hur arbetet går till i dag, och se var det faktiskt krånglar.

Vad som går in, och vad som ska komma ut

När jag tittar på ett arbetsflöde vill jag veta vad som finns när arbetet börjar. Är det fält i ett system, fritext, dokument, eller kunskap som bara sitter hos en person? Och vad behöver personen få tillbaka: ett dokument, ett utkast, en klassificering, eller en ändring i ett annat system? De sakerna behöver kontrolleras på olika sätt.

Jag vill också veta vad systemet inte kan veta. Saknas produktversionen ska lösningen fråga efter den, inte gissa. Om två instruktioner säger olika saker kan rätt svar vara att lämna frågan till en människa. Ett arbetsflöde som alltid lämnar ifrån sig något som ser färdigt ut, även när underlaget saknas, är inte mer användbart. Det är bara svårare att genomskåda.

Datan, och vem som får använda den

Finns informationen någonstans där någon ansvarar för den? Går det att se om den är aktuell? Får den som ska använda verktyget läsa den, och får den användas i den miljö ni har tänkt er? Att man tekniskt kan hämta en text betyder inte att den får användas för vem som helst, eller till vad som helst.

Om de frågorna inte har svar är nästa steg att reda ut dem. Inte att välja en större modell.

Ett exempel

Ta ett konsultbolag med 40 anställda som svarar på frågor om sin egen produkt. En handläggare får en fråga om hur en inställning ändras. Den som frågar nämner produktnamnet, men inte vilken version det gäller. Instruktionerna skiljer sig åt mellan versionerna.

Det farliga är inte att utkastet blir dåligt. Det farliga är att det låter rätt men gäller fel version. Ett svar som låter säkert, med hänvisning till fel instruktion, är värre än att först be om rätt version.

Därför ska assistenten fråga, inte gissa. Ett utkast får bara luta sig mot en instruktion som gäller rätt version. Saknas versionen, eller säger två källor olika saker, ska den fråga eller lämna över till handläggaren. Ingen inställning ändras av sig själv. Det är handläggaren som granskar och skickar svaret.

Ibland räcker det att göra det lättare att hitta rätt avsnitt. Om handläggaren snabbt kan öppna rätt instruktion behövs kanske inget genererat utkast alls.

Ett enkelt sätt att skriva ner de gränserna kan se ut så här:

Saknas version: fråga, gissa inte
Två instruktioner säger olika: lämna till handläggaren
Utkast: bara med källa för rätt version
Skicka svaret: handläggaren, inte systemet

Det är ett sätt att prata om vad som får hända, inte en färdig lösning.

Fyra frågor innan ni bygger

  1. Vem ska använda det här, och hur märker de om det blir fel?
  2. Finns underlaget, är det aktuellt, och får det användas?
  3. Kan någon som kan arbetet kontrollera svaret, och vad händer om det är fel?
  4. Har vi provat den minsta varianten mot hur arbetet görs i dag, och mot något enklare, som bättre sökning eller en regel?

Om ni inte kan svara på frågorna är det för tidigt att välja modell. Om en enklare lösning redan räcker behöver ni kanske inte bygga AI alls.

Ibland är slutsatsen att ni inte ska bygga AI just nu. Kanske räcker bättre sökning. Kanske får datan inte användas. Kanske finns det ingen som kan säga när svaret är fel. Då är det bättre att stanna där än att välja en modell i alla fall.

När arbetsflödet däremot är tydligt kommer nästa fråga: behövs en språkmodell, sökning, vanliga regler, eller en blandning? Det tar jag i nästa text.

Mejla mig på hello@aidoni.se om du vill prata om ett arbetsflöde ni överväger att bygga för.