Jeg er en stor fan af Isaac Asimov, og har nydt at læse mange af hans historier. Et af mine yndlingscitater om videnskab stammer faktisk fra Asimov: “The most exciting phrase to hear in science, the one that heralds new discoveries, is not ‘Eureka!’ but ‘That’s funny…'” – men det er en helt anden historie.
Asimov opfandt de tre robotlove, som spillede en central rolle i mange af hans historier, og som tjente til at sikre menneskeheden mod at blive overvundet af vores egne skabninger (hvilket ellers tit bliver vores skæbne). Disse love er på paradoksal vis på samme tid mere relevante og irrelevante end nogensinde før: Vi har semi-autonome robotter (krigsdroner) som bruges til at slå folk ihjel, men vi har ingen robotter som tilnærmelsesvis er på et intellektuelt niveau hvor Asimov’s tre love giver mening. Hvis vi taler generelt anvendelige kunstige intelligenser, er vi måske tilnærmelsesvis på insektniveau (hvilket dog ikke er helt skidt, insekter er ret seje). Men der er altså lang vej endnu, til at kunne forholde sig til, hvorvidt ens handlinger skader et menneske.
I mellemtiden kan vi så til gengæld forholde os til det som jeg vil kalde “robotteknologiens tre love”, som omhandler hvordan det er at udvikle software til robotteknologi. Disse love er frit opfundet på basis af mine foreløbige erfaringer med at arbejde med software til robotter: formskiftende robotter, lidt træningsrobotter, og efterhånden også markrobotter. Jeg er uddannet datalog, jeg arbejdede før med leksikalsk blokstruktur og partiel evaluering. At udvikle software til robotter har været utroligt lærerigt, og jeg mener at dataloger, software ingeniører og hvad de ellers hedder altid burde konfronteres med noget lignende. Det gælder både under uddannelsen, og hver eneste gang der skal designes et nyt software system!
Robotteknologiens tre love bliver hermed rystet ud af ærmet, som følger:
- Du kan ikke stole på de underliggende teknologier.
- Du kan ikke stole på at input eller output kommunikeres korrekt.
- Det har alvorlige konsekvenser hvis dit program fejler.
OK, det er nok farvet af at jeg har arbejdet med eksperimentelle robotter, som vi selv har flikket sammen. Men en robot bevæger sig ud i den virkelige verden hvor der kan ske ubehagelige ting: en markrobot kan tage vand ind hvor der burde være tørt, og din hund kan tisse på din robotstøvsuger (1). En robot benytter sensorer og aktuatorer til at interagere med den omkringliggende verden, og de er aldrig perfekte: der kan for eksempel være fejl i en sensor således at den konsekvent giver forkerte værdier (2). Hvis du skriver dit program rigtigt kan du godt kompensere, hvis ikke så kører robotten i cirkler når den skulle have kørt ligeud. Endelig så er mindre robotter som regel ufarlige for andre, men fejl i programmet kan ødelægge robotten selv (3). Store robotter kan slå mennesker ihjel hvis der er fejl i programmet.
Hvad har disse såkaldte love at gøre med software udvikling? Hvad nu hvis man blot skal udvikle et administrativt system, så er det vel ikke relevant, vi har jo vores gode datalogiske lærdom om programmering og datastrukturer, og har vel også styr på at indfange brugerens krav, som videreudvikles i en iterativ proces? Problemet er at vi uværgeligt bliver fanget i illusionen om det fejlfrie program, det beviseligt korrekte program med den rette software arkitektur, som netop sikrer de rette egenskaber. Men store, komplekse programmer vil i praksis næsten altid indeholde fejl, og efterhånden som programmer udvikler sig over tid, stiger risikoen for at en fejlagtig antagelse sniger sig ind et eller andet sted, og som en virus spreder inkonsistent data rundt i programmet. Kommunikation med den ydre verden gør det så blot endnu værre: netværkskommunikation ender alt for tit med at være en Akilleshælhvor programmet går i stå, mister data, eller stoler blindt på alt hvad der kommer ind over netværket såldes at det er trivielt at hacke.
Betyder det noget? Ja for pokker! Vi lægger vores liv og vores samfunds ve og vel i software tilsyneladende udviklet af det firma som mente de kunne gøre det billigst (eller var det dyrest? man kan godt komme lidt i tvivl nogle gange). Vi ser alt for mange eksempler, såsom at kritisk data omkring sygdomme og medicin ikke bliver kommunikeret korrekt rundt mellem diverse IT-systemer (mere om det senere).
Kan vi gøre noget? Ja! Vi kan som IT-professionelle (eller hvad det nu hedder) udvise et større samfundsansvar: vi må hjælpe vores politikere med at forstå hvad der er vigtigt (betragte vigtig software som et sikkerhedskritisk system: ja; elektronisk folkeafstemning og faste “bredbånd”sgarantier til alle: nej), og vi må hjælpe lærerne rundt omkring på landets skoler med at lave spændende og relevant IT-undervisning så den næste generation om ikke andet får en bedre forståelse for hvilke krav man skal stille til fremtidens software.
Disse emner vil blive diskuteret i denne blog, krydret med diverse praktiske og/eller skøre forskningsmæssige ideer til hvordan vi kan lave robust software til menneskeheden, samt ikke mindst en ordentlig diskussion af hvad man lærer om datalogi og software ved at udvikle software til (rigtige) robotter.
Jeg bryder mig ikke om den tredie “lov”. “Alvorlig” er et vagt udtryk, og det har vel heller ikke altid konsekvenser hvis systemet fejler. Synes hellere det skulle være “Du må antage at dit program ikke er fejlfrit”
Jeg er indstillet på at lovene nok skal masseres lidt før de er helt perfekte, så tak for kommentaren! “Alvorlig” er måske nok lidt vagt, ja. Vi kan jo starte med at stryge ordet, så bliver 3. lov: “Det har konsekvenser hvis dit program fejler.” – hvilket efter min mening er noget andet end antagelser om fejlfrihed eller ej. Jeg kunne jo godt være klar over at mit program nok ikke er perfekt, og derfor måske indeholder fejl, men det er ikke sikkert jeg laver en grundig analyse af de mulige konsekvenser af en fejl. Hvis mit program skal overføre data til det fælles medicin kort, skal jeg helst gøre mig klart hvad konsekvenserne er hvis der opstår fejl i dataoverførslen. I dette tilfælde kan folk dø af det – så man bør derfor f.eks. bruge teknikker kendt fra sikkerhedskritiske systemer (fremtidigt blogindlæg).
mvh Ulrik
Selvom det kan virke lidt pedantisk at diskutere formulering af den tredje lov for udvikling af robotteknologi, så synes jeg alligevel, det har sin berettigelse. Der ligge tydeligvis en del erfaring bag formuleringen af de tre love.
Jeg er ikke enig med dig i at “alvorlig” er forkert at bruge i denne sammenhæng. Vi kan muligvis finde på et mere præcist ord, men at negligere at konsekvenserne kan være alt andet end ubetydelige, tror jeg er en farlig undervurdering for fremtidens robotter. Du behøver blot at se på hvad konsekvenserne er af fejl i software som NemID, IC4-tog, og hvis vi en dag skulle få e-valg. Når vi en dag laver robotter til at udføre missionkritiske opgaver, så vil en fejl i robotten uværgeligt en dag få alvorlige konsekvenser.
Jeg vil dog gå med til at bøde sætningen lidt op, for det er ikke alle fejl, der hver gang får alvorlige konsekvenser, så et forslag er:
3. Det kan få alvorlige konsekvenser hvis dit program fejler.
Det er derfor en væsenlig pointe at skrive sig bag øret og ind i sine programmer.
Tak Jens jeg sætter pris på din sans for detaljerne (og tak også til “biffen” for at have taget fat i det til at begynde med): Formuleringen af denne her slags “love” er jo utroligt vigtig, noget af det stærke hvis Asimovs 3 love var jo også at de var meget præcist formulerede. Derfor var det også lidt fristende simpelthen at fjerne “alvorlige”, for at reducere og nå ind til essensen. (En overgang var “den virkelige verden” også blandet ind i det, men det forsvandt igen.) Noget andet som er godt ved Asimovs 3 love er, at de er formuleret parallelt, alle 3 starter på samme måde, hvilket heller ikke helt lykkedes for mig ovenover. Så hvad med:
3. Du kan skade dine medmennesker hvis dit program fejler
“Skade” skal her forstås i generel forstand, ikke kun fysisk men f.eks. også økonomisk. Denne formulering tager fat i det ansvar jeg mener vi har, og som vi så tit ikke tager alvorligt – ikke kun for robotter, tog, og atomkraftværk, men også for administrative systemer som indeholder vigtig data for mennesker i det danske samfund.
mvh Ulrik
Jeg foretrækker den oprindelige formulering “alvorlige konsekvenser”.
Det er korrekt at den underliggende observation er at vores software indeholder fejl, men formålet er at vi skal fokuserere på hvordan vi håndterer fejl således at alvoren af konsekvenserne minimeres. Hvis formuleringen bare monotont messer at vi laver fejl, så tror jeg lige så vel at resultatet kan blive en trækken på skuldren fordi vi tilsyneladende alligevel ikke kan gøre noget ved det.
Efter min mening skal en regl som den tredje skal vise rum for forbedringer for at virke motiverende frem for demotiverende. Og forhåbentlig vil vores opfattelse af “alvorligt” ændre sig til at det er mindre skadelige konsekvenser vi anser som alvorlige.
…og hvad siger du til alternativet “3. Du kan skade dine medmennesker hvis dit program fejler”, Peter? Der ligger jo en implicit alvorlig konsekvens i at skade ens medmennesker, og som forhåbentligt ikke er taget for langt ud (men det er jo det som det drejer sig om). Derudover så er det helt rigtigt: det vigtige er at håndtere fejl, både i programmets logik, i forhold til hvis andre dele af et større system fejler osv.
mvh Ulrik
Det er måske fint i din konkrete kontekst om robotteknologi. Men gælder de tre bud egentlig ikke al softwareudvikling?
I min dagligdag kan jeg let nikke genkendende til de to første bud, men “skade dine medmennesker” (jeg laver blandt andet backup-systemer). Jo, måske kan jeg godt se at det er skadeligt hvis en backup pludselig forsvinder, men jeg vil nok være meget tilbøjelig til at fokuserer på fysisk skade hvis jeg bare læser det.
Jeg kan egentlig godt lide at det er lidt abstrakt, da jeg tror at det opfordrer mere til at man reflekterere over tingene istedet for bare hurtigt per refleks svare ja eller nej. Det gør også budet lidt mere fleksibelt. Forestil dig at skulle lave et system der redder folk der falder ned på sporet fra togperronnen. Det skal gå hurtigt, tilgengæld er der en høj risiko for at personen brækker et par knogler. Her er den alvorlige konsekvens måske ikke at folk kommer til skade, bare de kommer væk fra sporet.
Selvfølgelig skal det heller ikke være for abstrakt og subtilt. Hvor grænsen ligger er jeg ikke sikker på, men hvis vi breder os lidt ud over “robotter med nærkontakt til mennesker”, så er “du kan skade dinne medmennesker” måske lidt mere subtilt og abstrakt end alternativet.
Jo du har ret, tanken var jo netop at de tre love skulle gælde al (vigtig) softwareudvikling (næsten).
Backup-systemer er et godt eksempel på vigtige systemer, det har ikke altid alvorlige konsekvenser hvis de fejler, men det kan det tit have – det kunne endda være livsvigtige data som var gået tabt og skulle hentes frem fra backup-systemet før man kunne behandle en patient. Min tanke med “Du kan skade dine medmennesker…” var, at der for rigtigt mange vigtige IT-systemer er scenarier hvor det er til reel skade hvis systemet fejler. Men det duer jo selvfølgelig ikke hvis loven lyder forkert i forhold til softwareudvikling generelt (hvor jeg jo gerne vil have den til at være relevant).
Så er vi måske tilbage igen til udgangspunktet, med de alvorlige konsekvenser (som du også foreslår), måske:
3. Du kan skabe alvorlige problemer for dine medmennesker hvis dit program fejler
For stadig at have fokus på det personlige ansvar (som jeg gerne vil vende tilbage til senere, jeg syntes ikke at vi som IT-professionelle gør os det helt klart).
mvh Ulrik
Som før skrevet er udtrykket “alvorligt” vagt, eller kontekstafhængigt om du vil, hvorfor det ikke egner sig til at beskrive en lov. Hvis du ser på andre videnskabelige love er disse som regel meget eksakte og skal ikke tolkes i en kontekst. Er der undtagelser til loven er disse også nøje beskrevet.
Den konkrete situation må afgøre hvordan vi sikrer os hvis programmet fejler. Det er svært at sige noget generelt om det.
Du har ret, hvilket er lidt frustrerende, for det er svært at få formuleringen helt på plads 🙂
Problemet er (som Peter også bemærker) at meget software faktisk kan ende med at være kritisk i en given situation, og det gør vi os ikke altid klart. Omvendt er der jo åbenlyst også software for hvilken det ikke er tilfældet, f.eks. spil ville nok meget sjældent være i den “alvorlige” kategori. Så der mangler en afgrænsning af hvilken type software det drejer sig om, men jeg har svært ved at ramme det helt præcist, det bliver let vagt. Men omvendt er jeg sikker på at der er noget vigtigt i netop den 3. lov, i forhold til det ansvar man har som software udvikler (måske det endda burde være den første lov?).
mvh Ulrik (tænker videre)
Jeg synes Asimovs robot-love er meget misforståede.
Asimov skelnede meget tydeligt imellem computere, som kom med et output som mennesker handlende på og “robotter” der kunne handle selv, uden mellemmand.
Det første sted vi har brug for at anvende Asimovs love, er på de store transnationale “swarm-intelligences” vi idag kender som f.eks Monsanto, JP Morgan, IBM, Google osv.
Disse “firmaer” opfylder alle Asimovs kriterier for at være robotter: De vælger deres egne mål autonomt, de forfølger disse mål autonomt og de påvirker strategisk deres omgivelse, med henblik på at fremme deres egne mål.
Det faktum at den bagvedliggende AI er en sværm af Homo Sapiens forandrer ikke på kalkulen, medlemmerne af sværmen arbejder ofte hen imod sværmens mål, selvom det skader deres egne mål, f.eks socialdemokrater der arbejder i firmaer som støtter Venstre eller LA med en del af overskudet.
Hvis man derefter ser på indflydelsen på politik i den vestlige verden, er det meget svært ikke at nå den konklusion at “singularity” er bag os.
Poul-Henning
Det vigtige ved Asimovs love var ikke desto mindre at de definerer reglerne for en interaktion mellem mennesket og dets tjenere, i form af robotter (vi holder lige den 0. lov ude af billedet her). Lovene er faktisk lidt ekstreme i forhold til, at robotterne er en form for intelligensvæsner: det er fair nok at menneskeliv prioriteres højere end robotter, men det at adlyde et menneske prioriteres også højere end robotterns selvopretholdelse!
Men hvordan tænker vi om den globale økonomi? Det globale økonomiske system kan betragtes som noget levende, fordi det faktisk opfylder visse nogenlunde anerkendte kriterier for hvad det betyder at være levende (metabolisme, selfopretholdelse, reproduktion).
Spørgsmålet kunne derfor være om vi vil opfatte de transnationale firmaer som robotter, der ifølge den 2. lov skal adlyde det enkelte menneske, i så høj en grad at det kan betyde deres egen selvudslettelse. Eller om vi opfatter dem som noget levende som derfor har visse rettigheder? Ikke nødvendigvis flere rettigheder end et slagtesvin, men det har jo også visse rettigheder, og vi forventer ikke at det lægger sig til at dø selv bare fordi vi beder den om det – ja det er vel OK og i dens natur at kæmpe for sit liv?
Jeg er ikke sikker på om Asimovs love giver mening for liv, og derfor specifikt ikke i dette tilfælde.
mvh Ulrik
[…] virker igen. Det er helt klart et skridt i den rigtige retning (se også mit tidligere indlæg om robotteknologiens 3 love og deres betydning for softwareudvikling). Efter sigende er det heller ikke det bagvedliggende system som skaber problemer. Det kører på […]