's Picture

Så får vi våra team att utveckla produkter med maskininlärning

Postad av Andreas Launila

På Expressens utvecklingsavdelning har vi många olika kompetenser, varav maskininlärning (ML) är en av dem. Här är en ögonblicksbild av hur vi jobbar med ML. Detta är, som allt annat, under ständig utveckling och kan mycket väl se annorlunda ut om ett år.

Sammanhanget

Hur väl något fungerar beror på sammanhanget och förutsättningarna. Bara för att det fungerar för oss här och nu, betyder inte att det skulle fungera i ett annat sammanhang. Några viktiga faktorer på Expressen som påverkar varför vi jobbar som vi gör:

  • Stor etablerad produkt med många användare
  • Korsfunktionella produktteam med hög autonomi
  • Snabbt till deploy
  • Kultur av att titta på och fokusera på resultatet

Utforskning

Expressen har en stor etablerad produkt med många användare. Alla ställen där man kan infoga en liten ML-låda som skiftar något KPI några procent kan ha betydande effekt. Problemet är mest att vi inte vet var i produkten ML kan ge värde och var det inte spelar någon roll. Av denna anledningen fokuserar vi på utforskning: att hitta var i produkten det finns ML-potential. Detta vägs i sin tur mot att spendera tid på att optimera de ställen som vi redan hittat.

I dagsläget har vi flera värdeproducerande ML-system körande kring native-annonser, videoannonser och interna verktyg. För att komma dit har vi behövt prova oss fram, ibland förkasta idéer som lät bra på pappret samt iterera tills systemen hittat sina former.

För att kunna utforska är det viktigt att förstå produkten och hur den används. Vi tror att de som har bäst förutsättningar för att hitta ställen med ML-potential är de som både kan produkten och har en grov idé om vad ML kan göra och inte kan göra.

Medlemmarna i ML-skrået (från vänster): Andreas Launila, Hans Hjelm, Eric Skoglund, Jimmy Callin
Medlemmarna i ML-skrået (från vänster): Andreas Launila, Hans Hjelm, Eric Skoglund, Jimmy Callin

Utveckling på Expressen

På Expressen finns flera produktteam. Varje produktteam fokuserar på en viss produkt och har kompetensen att ta högnivå-mål (till exempel "öka sidvisningar med 5% genom att förbättra artikelupplevelsen") och därifrån sköta resan för att uppfylla dem. Detta inkluderar att generera ideer, bearbeta dessa, gallra, testa, utveckla, iterera, följa upp och i allmänhet optimera hur mycket värde man producerar mätt i KPI:er. För att lyckas med detta innehåller teamen en stor blandning av kompetenser.

En följd av att teamen har detta breda ansvarsområde är att de måste kunna sin produkt, användare och omvärld väldigt väl. I produktteamen finns alltså kunskapen om produkten. Det är denna vi vill kombinera med kunskap om ML. Den naturliga vägen var därför att vi som håller på med ML också är del av produktteamen och ytterligare breddar kompetenspaletten. Detta tjänar tre syften:

  • De som håller på med ML får bättre koll på produkterna
  • De som inte håller på med ML får bättre koll på ML
  • De ML-saker som görs är linjerade med produktteamets behov och sinkas därför inte av behov att koordinera mellan olika team

Kunskapsspridning

Att sprida kunskap om ML i teamen är en långsiktig strategi. Vi är inte tillräckligt många som fokuserar på ML för att sitta i alla team. Om vi lyckas bra med att sprida kunskap och intresse inom ett team är förhoppningen att teamet, även utan att någon som fokuserar på ML är där, kan identifiera områden med ML-potential. Om man inte har någon med ML-erfarenhet i teamet så kan man fortfarande söka upp någon utanför teamet att bolla vidare med.

Enkelhet

En av utvecklingsavdelningens grundprinciper är enkelhet (den andra är testdrivning). Detta anammar vi genom att börja enkelt med en simpel modell eller heuristik för att först se om vi har någon påverkan över huvud taget. Google har ett dokument med best-practices för ML där man, utöver många andra användbara råd, kan läsa följande:

Rule #1: Don’t be afraid to launch a product without machine learning.

Machine learning is cool, but it requires data. Theoretically, you can take data from a different problem and then tweak the model for a new product, but this will likely underperform basic heuristics. If you think that machine learning will give you a 100% boost, then a heuristic will get you 50% of the way there. ...

När vi ser hur väl en heuristik fungerar kan vi resonera kring om vi vill investera tid i att göra en modell.

Ett annat användbart dokument är Machine Learning Yearning av Andrew Ng. Boken är inte färdig än, men man kan skriva upp sig på en mailinglista för att få kapitelutkast. Boken fokuserar på ML i praktiken. Hur man, givet ett nytt problem, snabbt får igång en feedbackloop och väljer vad man ska spendera tid på vid olika vägskäl.

Sammanhållning

Om man jämför med varianten att fokusera utvecklingen av data-produkter i ett team så finns det definitivt baksidor. Att vi är utspridda betyder att det finns mindre stöd från folk med liknande kompetensfokus. Att göra infrastrukturella insatser som gagnar alla team är inte heller enkelt. För att kompensera för detta har vi ett ML-skrå där vi möts en gång i veckan. Där kan vi prata om saker och göra gemensamma projekt. Det är helt enkelt ett sätt att skapa sammanhållning och koordinera oss trots att vi sitter i olika team.

Infrastruktur hanteras, som bloggats om tidigare, baserat på pull-requests till det team som är ägare. Det finns till exempel ett team som tar hand om data-infrastrukturen för produktteamen. Vem som helst kan prata med teamet och göra pull-requests.

Toppen av isberget

Även om vi kallar oss ML-skrået ska man komma ihåg att själva ML-modelleringen bara är toppen av isberget. Det är bara en liten bit av det som krävs för att skapa en ML-baserad produkt som skapar värde. Som många andra problem är det centralt att förstå problemet och i vilket sammanhang man befinner sig.

Mycket av det vi gör handlar om att, tillsammans med teamet, bättre förstå de områden där vi tror ML kan ge värde. Vi behöver tillsammans utforska olika möjligheter för att kunna zooma in på de lösningar som på ett bra sätt balanserar värde och komplexitet. Detta inkluderar att utföra experiment på historisk data, vid användartester, eller med en förenklad variant i en live-miljö. Detta innebär i sin tur ofta att gräva i data och/eller hitta enkla sätt att modifiera den existerande produkten för att testa antaganden.

Även när vi har tillskansat oss en god förståelse av problemet handlar mycket om att transformera den data vi har och att faktiskt infoga modellen i systemet för att skapa produkten. När kedjan väl är sluten och vi får feedback från riktiga användare i en live-miljö kan vi börja lägga tid på att iterera fram en bättre modell. I det stora hela är det dock bara en liten del av allt jobb som krävs. Lyckligtvis så är vi inte ensamma — vi har våra produktteam.

Toppbild: "D2-13+D2-50+D5-15_n40_o07_r1.33" av genekogan, CC BY-SA 2.0 / Bilden har beskurits

PS. Missa inte vår nästa bloggpost, följ oss på Twitter!

Till startsidan