Årets morgonpapper - 2018-utgåvan

Fortsätter i min tidshöjda tradition sedan starten sedan 2017, här är min uppfattade lista över de bästa / mest intressanta / mest relevanta / mest ögonöppnande artiklarna i The Morning Paper av den otroliga Adrian Colyer under kursen förra året.

AI och sådant

Konkreta problem och AI-säkerhet

Mellan AI-teknofutopierna och AI-dommedagsprofeterna ligger AI-nördar, bara tuggar bort och tänker på problemen. Författarna representerar några av markörinstitutionerna som arbetar inom detta område och deras rykte säkerställer att vi kommer att uppmärksamma. Taksonomier hjälper till att destillera kunskapen om ett fält i smältbara bitar, och det här uppsatsen levererar med kortfattade och lekmänniska formuleringar som "belöningshackning". (De kunde bara ta det så långt och slutligen ge efter för "bräcklighet inför distribueringsskift", när "förvirring i oväntade miljöer" skulle ha gjort det bra.) Skämt åt sidan, uppsatsen är oerhört tillgänglig och författarna gjorde en fantastisk jobb med exemplen. På tal om robotar som bryter urna så att de kan optimera rengöringsavkastningen, det roligaste för mig är att vi vet att robotar / agenter skulle ha dessa problem med enkla objektiva funktioner - trots allt har människor inte dessa problem hela tiden? (Cue-historia om utvecklare som tillåter buggar i sin kod så att de kan få felfixbonusen.)

EU-förordningar om algoritmiska beslutsfattande

När tech-pressen, mainstream-pressen och Hacker News alla talar i hysiga, respektfulla toner om en EU-reglering - en EU-förordning! - du kan vara säker på att någonting har gått ut. Nåväl, vad som är på gång är en möjlig (och möjligen helt oavsiktlig) attack i hjärtat av en outtalad regel i utvärderingen av AI-modeller: att beviset ligger i intäkterna, allt annat är fördömt. Tills förordningen är testad med en juridisk utmaning, eller kanske flera rättsliga utmaningar, förblir dess fulla omfattning en fråga om tolkning och spekulation. Att ge offren (eller ”ämnen”) av algoritmer rätten att veta varför ett beslut fattades gör dock förklarbarheten till en [m | b] illion-dollar förslag.

Samma statistik, olika grafer

Jag valde detta bara för T. Rex, för att vara ärlig.

Neurarkitektursökning med förstärkningslärande

Denna artikel var en som framhävde en del av den aktiva forskningen som skedde i skärningspunkten mellan stammarna av Pedro Domingos The Master Algoritm. Kenneth Stanley dök upp ganska ofta i den här åren med artiklar, föredrag och poddsändningar om neuroevolution.

Dynamisk dirigering mellan kapslar

En obligatorisk inkludering. Vi vet ännu inte hur påverkande detta kommer att vara, men en del av Hintons tidigare arbete har visat sig, ska vi säga med grovt underdrift, "något användbart".

Automatisk inställning av databashanteringssystem

I den tråkiga gamla världen med tråkiga gamla företagssystem övervägs administratörer rutinmässigt av konfigurationsvred. Glad att veta att människor tänker också på dessa administratörer. Hurra! ML handlar inte bara om att dela korv och gyllene retriever. Larry Ellison vände marknadsföringen till 11 med sitt meddelande om Oracle Autonomous Database Cloud på Oracle OpenWorld 2017, men det har funnits gott om pågående forskning om detta ämne.

Detta medför en betydande utmaning. Ju mer ogenomskinlig den svarta rutan blir - och de flesta företagsprogramvaror är en ganska ogenomskinlig ruta - desto fler användare kommer att missa att ha viss kontroll över den svarta rutans beteende. Detta kommer att förvärras av det faktum att till och med byggare av den svarta lådan ofta inte kan förklara på ett tillfredsställande sätt varför den svarta lådan gjorde vad den gjorde.

Så vad ska man göra? Cue-alternativ som Bayesiska metoder.

BÅT: Bygga auto-tuners med strukturerad Bayesian-optimering

Och en andra aktör till ämnet systemoptimering. En intressant aspekt av detta dokument för mig är att det verkar vara en del av ett återuppblickande intresse för Bayesiska metoder, delvis som ett svar på den starka önskan om förklarbarhet i sådana system. Det är kanske inte så intressant att "förstå" hur en modell räknade ut vad Van Goghs måleri i Starry Nights är, men det är säkert intressant om nätverksutrustningen beslutade att avsluta en viss anslutning var "bättre totalt sett" och då inte kan för att förklara för en upprörd användare hur den bestämde att detta skulle vara fallet.

Mjukvaruutveckling

För att förstå mjukvarans agility

Det säger inte riktigt det på detta sätt, men uppsatsen hävdar att vi alltför ofta hamnar i fällan av överlevnadsförspänning - restriktivt tillskriver förutsägbart värde, där inget fanns, till olika åtgärder som vidtagits eller händelser som inträffade. Snarare skulle det vara lämpligt att acceptera komplexiteten (i motsats till enbart komplicerad) av sytemet - människor, företag, teknik, kod, ... - och ta en strategi att ta små steg, observera effekterna av det steget, studera eventuella förändringar i miljön, justera efter behov och sedan ta ett litet steg. ML-personer kallar det "gradient descent". Programvaruteknik folk kallar det "Agile". För mig tillbaka till den punkt där jag instämde mest, precis i början av tidningen, som Adrian sammanfattar så:

Agils ursprungliga anda har ofta ersatts av godsodling av regler och checklistor

En dissektion av den testdrivna utvecklingsprocessen

Här är en andra artikel som studerar ett fenomen som verkar fungera ganska bra i praktiken och försöker undervisa det med teori. Jag misstänker att uppsatsen kommer att bli väl mottagen av människor på båda sidor av den religiösa klyftan kring TDD eftersom det ena de är överens om är att små partier styr (Toyota, Lean, etc.).

Hur komplexa system misslyckas

Lämpligt tillämpligt på programvarusystem även om författaren är läkare och skriver från ett hälso- och sjukvårdsperspektiv! Organiserad som en serie observationer, det är helt fantastiskt (kanske detta talar till hur begränsad min kunskap har varit) hur många av dem som tillämpas direkt på programvarusystem. Den bästa observationen av partiet enligt min åsikt är "Komplexa system körs därför i nedbrutet läge som deras normala driftssätt", men det finns flera anmärkningar, t.ex. om farorna som RCA är full av, och på producenten / operatörsbalans och vad som händer när de är samma person. Med kanske bara en liten dos med bekräftelseförlopp är det inte svårt att se alla sätt på vilka detta stöder Agile, Lean och DevOps.

Moln

Serverfri beräkning: ekonomisk och arkitektonisk inverkan

Den första av ett par papper om paradigmskiftet som så kallade serverlösa ger. För mig säger namnet: naturligtvis finns det en server någonstans som kör kod, men för utvecklaren finns det ingen server. Serverless gör molnberäkning allt om koden - utvecklaren måste oroa sig för ingenting annat. Naturligtvis är detta papper mycket muttrar och bultar, dollar och cent, för- och nackdelar. Tänk på det som en akademisk version av en presentation till en CFO och CIO eller ThoughtWorks Technology Radar. Det är inte utformat för att övertyga någon om någonting, men det placerar serverlöst inom riket, ska vi säga, rimligt väl förstått.

Ockupera molnet

Vinod Khosla, en gång Silicon Valley-royalty, sa en gång på en konferens: "Förändring är det enda värt att optimera för." Mina damer och herrar, jag ger dig: serverlösa. Den här sekunden av ett par papper som jag gillade i ämnet är mer ett bredare visionuttalande som försöker bygga stöd för påståendet att fördelarna med en mycket avkopplad arkitektur genom att fokusera på det minskande värdet av optimeringar som dator / datakolokation, att notera att ”på AWS EC2 är det snabbare att skriva till fjärrlagring än att lagra data på en enda lokal SSD”. Tidningen kommer sannolikt inte att övertyga skeptiker, men det kommer definitivt att försvaga deras motstånd. Jag tar lite problem med formuleringen "distribuerad datoranvändning för 99%". Jag skulle föredra att säga "molnberäkning för 99%" - vilket ger dessa 99% ett sätt att använda molnet utan att oroa mig (för mycket) för distribuerad datoranvändning.

Spanner

Detta var typ av obligatorisk inkludering, vad med all hype kring det. Global! Distribuerad! Inga ops! SYRA! KEPS! Atomklockor! Detta tillkännagivande hade svalt värde långt bortom databasgeekdom.

BRR: trängselbaserad trängselkontroll

För det sista uppsatsen på min lista, här är en nick till vad som betalar mina räkningar - nätverk. Så unsexy som VVS, lika viktigt och lika svårt att rensa när saker täcks. Som en snabb sida är buffertuppblåsning ett förvånansvärt dåligt förstått problem i nätverk ("sunt förnuft" och allt det), och något jag lärde mig om från expertskolleger på Citrix när jag arbetade med WAN Optimizers och sådant. Adrian levererade möjligen de bästa visualiseringarna av sina bloggar 2017 för att förklara problemet med TCP-trängselkontroll och hur BRR hanterar det.

Så där har du det. Informationsflödet fortsätter och tack vare Adrian Colyers kurationsansträngningar kan vi meningsfullt smälta en bit av den.

Ser fram emot Adrians val för 2018!

Bonuspapper

Använd "cloud-native virtualization". Hypervisor-medveten virtualisering är så passé. Även känd som "molnet är det nya operativsystemet".

Även om deras användning av webbskala är vanligt tycks räkningsfilter vara mycket användbara men grovt utnyttjade konstruktioner i nätverk. Jag undrar varför.