Vad räknas som bevis när maskinen är probabilistisk?
Sannolikhet är ingen dom
När en maskin returnerar 0,87 är den första frågan oftast för liten. Människor frågar om 0,87 är högt. Högt jämfört med vad, för vilket utfall, över vilka fall och för vilket beslut? En siffra som skrivs ut bredvid ett resultat ser ut som en egenskap hos det resultatet. Ofta är den inte det. Den är ett försök att beskriva en relation mellan en modell, en definierad population av fall och ett utfall som observerats över tid. Den relationen kan vara användbar. Den kan styra en granskningskö, sätta ett tröskelvärde eller tala om för en operatör när ett resultat förtjänar en andra titt. Men den gör inte en enskild förutsägelse till ett faktum med en decimal bifogad.
Detta är den besvärliga punkten i mitten av probabilistiska system. Deras resultat är ofta mer informativa än en ren etikett, eftersom de kan uttrycka grader av stöd eller osäkerhet. De är också lättare att övertolka. En poäng kan behandlas som ett vittnesmål, en juridisk slutsats, en diagnos eller ett tillstånd. Den är inget av detta som standard. Bevis börjar när organisationen kan säga vad siffran representerar, hur den kontrollerades, var den kontrollen gäller och vilken åtgärd siffran tillåts ändra.
Den distinktionen spelar roll långt innan ett system möter en tillsynsmyndighet. Ett team kan besluta om ett föreslaget dokument behöver en mänsklig kontroll. En köpare kan jämföra två leverantörer som båda marknadsför konfidensmått. En operatör kan ställa in en eskaleringsregel. En offentlig myndighet kan fråga om en rangordnad lista är tillräckligt bra för att påverka var uppmärksamheten riktas först. I varje fall är en lyckad körning bevis på en sak: att den körningen producerade ett resultat. Det är ännu inte bevis på att systemet förtjänar den auktoritet som fästs vid det.
Det förnuftiga svaret är inte att förbjuda sannolikheter i konsekvensrikt arbete. Det är att ge dem en ordentlig arbetsbeskrivning. En sannolikhet kan stödja ett beslut när den är knuten till en definierad händelse, en relevant population, en observationsmetod, en osäkerhetsgräns och en regel för vad som händer när bevisen är svaga. Detta är långsammare än att beundra en enskild siffra och mycket snabbare än att senare upptäcka att ingen kan förklara vad siffran var tänkt att göra.
Bevisen måste namnge sin fråga
Bevis finns aldrig bara där. Det är bevis för ett påstående. Ett testresultat kan stödja påståendet att en komponent producerar ett visst resultat för en viss indata under en viss konfiguration. Det kan stödja påståendet att en modell rangordnar exempel väl på en separat testmängd. Det kan stödja påståendet att en sannolikhetsuppskattning stämmer rimligt väl överens med observerade frekvenser i en definierad utvärderingsmängd. Dessa påståenden är olika. Disciplinen börjar med att skriva ner påståendet innan man väljer mätetal.
Betrakta det till synes enkla påståendet att ett system är korrekt. Korrekt på vilket sätt? En klassificeringsnoggrannhet kan beskriva hur ofta den högst poängsatta klassen matchade en etikett. Den säger inte om den angivna sannolikheten var väl kalibrerad. Ett rangordningsmått kan beskriva ordning, inte kvaliteten på poängskalan. Ett lågt genomsnittligt fel kan samexistera med ett skadligt felmönster i en undergrupp eller vid ett tröskelvärde som utlöser en åtgärd. Mätetalet är inte fel. Det är steget från mätetal till operativ slutsats där problemen oftast börjar.
OECD:s arbete med utvärderingsinstrument är värdefullt just för att det överger fantasin att en enda poäng kan bära hela förklaringen. Dess ramverk skiljer mellan aspekter som täckning, syfte, realism, tillförlitlighet, reproducerbarhet, objektivitet och partiskhet. Dessa är inte byråkratiska utsmyckningar kring ett riktmärke. De beskriver om resultatet har rätt relation till den fråga som ställs. En forskningsjämförelse, en bedömning av överensstämmelse och ett operativt lanseringsbeslut kan alla använda tester. De ställer inte samma krav på dessa tester.
Börja därför med en mening som går att invända mot. Till exempel: detta system kan skicka ärenden vidare för mänsklig granskning när dess dokumenterade sannolikhetsuppskattning för ett definierat utfall överstiger ett angivet tröskelvärde, förutsatt att indatan matchar den validerade omfattningen och att granskaren har befogenhet att avvisa förslaget. Det är ett diskutabelt operativt påstående. Det namnger åtgärden, villkoret och gränsen. Det låtsas inte att en poäng själv har valt sin roll i världen.
Den motsatta meningen är bekant eftersom den är bekväm: modellen är 87 procent säker. Även om en modell verkligen avger en sannolikhet, utelämnar meningen händelsen, kalibreringsbevisen, populationen, perioden och beslutet. Den förvandlar en relation till ett personlighetsdrag. Maskiner behöver inte beskrivas som blyga eller säkra. De behöver beskrivas som system vars utdata har definierade betydelser och definierade gränser.
Självsäkerhet är inte detsamma som korrekthet
Ett system kan vara självsäkert och ha fel. Det kan också vara korrekt samtidigt som det uttrycker låg självsäkerhet. Dessa två fakta är inte förvånande när termerna hålls åtskilda. Korrekthet frågar om ett utfall matchade den valda referensen för ett enskilt fall. Självsäkerhet är ett uttalande som kopplas till en utdata, ofta härlett från en modellpoäng eller en transformation av en sådan. Kalibrering ställer en ytterligare fråga över många fall: när systemet tilldelar liknande sannolikheter, inträffar utfallen då ungefär i den angivna takten? Dessa är relaterade frågor, men ett bra svar ger inte de andra.
Tänk dig en uppsättning fall där en klassificerare rapporterar en sannolikhet på 0,80 för en definierad händelse. Om händelsen, över en adekvat beskriven och tillräckligt stor uppsättning jämförbara fall, inträffar ungefär åtta gånger av tio, kan uppskattningen kallas väl kalibrerad för den populationen och det villkoret. Det betyder inte att nästa fall med 0,80 har ett öde på åttio procent. Det betyder att poängen har visat en relation till observerade utfall över den angivna samlingen. Uttrycket över den angivna samlingen bär det mesta av det intellektuella arbetet.
Kalibrering är inte heller något universellt kvalitetsmärke. Ett resultat kan vara väl kalibrerat på en historisk datamängd och dåligt kalibrerat efter att inmatningskällan, användargruppen, arbetsflödet, märkningsprocessen eller driftsförhållandena ändras. Det kan vara väl kalibrerat överlag men bete sig annorlunda inom en del av populationen som är viktig för tjänsten. Det kan se bra ut i en bred kategori samtidigt som det döljer en brant skillnad nära beslutströskeln. Ett kalibreringsdiagram är inte ett diplom inramat ovanför produktionssystemet. Det är en daterad observation med en avgränsning.
Litteraturen om modellkalibrering gör åtskillnaden konkret. Guo och kollegor studerade konfidenskalibrering i moderna neurala nätverk och visade att noggrannhet ensamt inte avgör om konfidensuppskattningar motsvarar observerade sannolikheter för korrekthet. Deras arbete utvärderar också kalibreringsmetoder efter bearbetning. Den viktiga operativa lärdomen är snävare än ett recept: ett modellresultat ska inte antas ha en lämplig sannolikhetsbetydelse bara för att det levereras i ett bekvämt intervall mellan noll och ett.
En noggrann organisation dokumenterar därför tre olika saker. Den dokumenterar uppgiftsprestanda, så att den kan fråga om resultaten uppfyller den definierade uppgiften. Den dokumenterar kalibrering eller en annan explicit osäkerhetsegenskap, så att den kan fråga vad resultatet betyder i praktiken. Och den dokumenterar konsekvensen av att agera vid en given tröskel, så att den kan fråga om beslutsregeln är lämplig. Att kombinera de tre till en enda grön indikator kan förenkla en instrumentpanel. Det förenklar inte världen.
Kalibrering har en nämnare
Varje påstående om kalibrering har en nämnare. Nämnaren är inte bara antalet poster i en fil. Det är samlingen av fall som var berättigade att räknas, hur de grupperades, definitionen av utfallet, tidsperioden, undantagen och processen som producerade referensmärkningarna. Ta bort dessa villkor och ett tillförlitlighetsdiagram blir en trevlig kurva utan jurisdiktion över ett beslut.
Anta att en utvärdering grupperar förutsägelser efter angiven konfidens. Den observerade frekvensen i varje grupp beror på vilka fall som togs in i gruppen och på utfallsdefinitionen. Uteslöts tvetydiga fall? Behandlades avstående som fel, säkra avvisanden eller något annat? Representerade märkningen en omedelbar händelse, en senare granskning eller ett slutligt överklagande? Behålls dubbletter? Inkluderade utvärderingen bara poster som klarade ett tidigare valideringssteg? Varje svar kan vara rimligt. Varje svar ändrar vad det resulterande kalibreringspåståendet betyder.
Det är därför en modell kan ha ett respektabelt globalt kalibreringsresultat och ändå vara olämplig för en specifik användning. Det globala resultatet kan slå samman språk, inmatningslängder, regioner, enhetstyper, kundresor eller driftslägen som inte delar samma felstruktur. En sammanslagen siffra kan vara en ärlig sammanfattning och ändå vara otillräckliga bevis för ett lokalt beslut. Rätt svar är inte att kräva en separat modell för varje person. Det är att testa de grupperingsantaganden som beslutet självt gör relevanta.
OECD:s utvärderingsramverk kallar detta täckning. Ramverket frågar om ett utvärderingsinstrument täcker en snedvriden eller representativ fördelning av det som det är avsett att mäta, och det skiljer uppgiftsprestanda från ett bredare kapacitetspåstående. Dessa åtskillnader är användbara för sannolikhetsbevis. Ett resultat kan vara bevis på prestanda över en uppgiftsfördelning. Det bör inte tyst bli bevis på en kapacitet, en påverkad population eller en framtida kontext som utvärderingen inte täckte.
Nämnaren har också en social sida. När en organisation avgör vilka ärenden som är tillräckligt enkla att automatisera och vilka som måste vänta på en människa, är det definitionerna som avgör vem som bär den kvarvarande osäkerheten. Ett sammanvägt resultat kan dölja att en mindre grupp har färre exempel, mindre stabila etiketter eller en annan operativ kontext. Det är inte ett skäl att lova jämförbar statistik där underlaget är tunt. Det är ett skäl att redovisa det tunna underlaget rakt och att utforma en försiktig beslutsregel kring det.
En lyckad körning är ett stickprov, inte en slutsats
Probabilistiska system inbjuder till en särskild form av övermod eftersom de är så lätta att demonstrera. Mata in en indata, få ett imponerande resultat, upprepa med en närliggande indata, få ytterligare ett. Demonstrationen kan visa att systemet kan utföra uppgiften. Den kan till och med visa något värt att undersöka. Den kan inte visa fördelningen av resultat, stabiliteten i poängen, hur systemet svarar på gränsfall, kvaliteten på referensetiketterna eller effekten av en ändrad driftsmiljö. Ett stickprov kan inleda en undersökning. Det kan inte avsluta en.
Detsamma gäller en enskild benchmarkkörning. Ett resultat kan ha samlats in korrekt, på ett väldokumenterat system, med ett legitimt mått. Om det kördes en gång är det bevis på det värde som observerades en gång under dessa förhållanden. Det är inte automatiskt bevis på en stabil egenskap hos systemet. Upprepning hjälper till att blotta variation. Det tar inte bort behovet av att fråga om testet representerar den avsedda användningen. Reproducerbarhet och validitet löser olika problem, och båda förtjänar en plats i dokumentationen.
OECD:s ramverk gör den åtskillnaden tydlig. Reliabilitet handlar om huruvida en utvärdering innehåller tillräckligt många upprepningar, tillräcklig episodlängd eller tillräckligt många instanser för att ge låg variation när den tillämpas igen. Reproducerbarhet handlar om huruvida samma test kan genereras igen, inklusive om stokastiska komponenter förändrar interaktionerna. Ett test kan vara exakt reproducerbart och ändå besvara en oanvändbar fråga. Det kan vara realistiskt och svårt att reproducera exakt eftersom miljön har förändrats. Ingen av dessa egenskaper är i sig en brist. Dokumentationen måste ange vilken egenskap som gäller och vad den tillåter läsaren att dra för slutsatser.
Det finns en blygsam men värdefull operativ vana här: behåll den lyckade körningen, men låt den inte bära mer än den kan. Spara indata, konfiguration, version, frö där det är tillämpligt, beroenden, utdata och utvärderingsbeslut. Placera den sedan bredvid upprepade mätningar, motexempel, avstående och ändrade förhållanden. Ett resultat som förblir användbart efter att det har mött sina besvärliga grannar är mer värt än ett resultat som var tvunget att skyddas från dem.
För generativa system är ett lyckat svar särskilt svagt bevis på repeterbarhet om inte interaktionskontraktet är dokumenterat. Samplingsinställningar, uppmaningar, hämtat material, tillgång till verktyg, modellversion, säkerhetspolicy och det omgivande arbetsflödet kan alla forma resultatet. Att spela upp en sekvens av ord utan det relevanta tillståndet kan återskapa utseendet av ett test samtidigt som det förutsättning som gjorde det meningsfullt saknas. I evidensarbete är likhet inte uppspelning.
Repeterbarhet är inte en synonym för tillit
En deterministisk uppspelning kan vara utmärkt bevis för ett enda snävt påstående: givet samma dokumenterade indata, konfiguration och implementeringsförhållanden producerade systemet samma resultat. Det gör undersökningar, regressionstester och versionsjämförelser mer hanterbara. Det fastställer inte att resultatet var korrekt, att indata var lämplig, att systemet borde ha använts för beslutet eller att resultatet kommer att generalisera bortom sin dokumenterade gräns. Repeterbarhet är en egenskap hos experimentet. Tillit är en bedömning av en bredare uppställning.
Stokastiskt beteende förändrar registret snarare än att ursäkta dess frånvaro. Om en utdata varierar måste utvärderingen registrera vilka delar som varierar, hur ofta, inom vilket intervall och hur variationen påverkar beslutet. Ett system som föreslår alternativa formuleringar kan tolerera ett bredare intervall än ett system som rangordnar ärenden för uppmärksamhet. Ett system som råder en människa kan kräva annan bevisning än ett system som gör en oåterkallelig åtgärd tillgänglig. Sannolikhet är inte en operativ kategori i sig. Konsekvensen avgör hur mycket osäkerhet en process säkert kan bära.
Det finns ett lätt misstag på båda sidor. Ett team kräver en fast utdata från ett verktyg vars uttalade syfte inkluderar utforskning och misstar sedan den resulterande determinismen för kvalitet. Ett annat team accepterar variabel utdata från ett beslutsstödssystem och kallar sedan variationen för kreativ när den blir svår att utvärdera. Ingen av positionerna är seriös. Frågan är om variationen är förväntad, avgränsad, observerbar och förenlig med den auktoritet som tilldelats systemet.
Europeisk reglering reducerar inte denna fråga till ett universellt mått. För AI-system med hög risk kräver artikel 15 i AI-förordningen en lämplig nivå av noggrannhet, robusthet och cybersäkerhet samt konsekvent prestanda i dessa avseenden under hela livscykeln. Den säger också att noggrannhetsnivåer och relevanta noggrannhetsmått måste anges i bruksanvisningen och uppmuntrar riktmärken och mätmetoder för de tekniska aspekterna av prestandamätning. Bestämmelsen säger inte att ett upprepat test avgör saken. Den kräver att prestanda specificeras och upprätthålls i sitt sammanhang.
Det är den förnuftiga hållningen för varje seriös utvärdering. Ett repeterbart test är en del av beviskedjan. Det behöver en ägare, en versionsgräns, en ändringsutlösare och en koppling till det operativa beslut det stöder. Utan dessa kan reproducerbarhet bli ytterligare ett attraktivt ord som färdas längre än experimentet.
Osäkerhet behöver en operativ väg
Det praktiska syftet med osäkerhet är inte att få en instrumentpanel att se sofistikerad ut. Det är att ändra vad systemet får göra. Om ett resultat inte har någon effekt på dirigering, granskning, förklaring, övervakning eller stoppande kan det vara en teknisk kuriositet snarare än en operativ signal. Om det däremot ändrar en åtgärd måste organisationen ange vägen från resultat till auktoritet.
Ett tröskelvärde är en sådan väg, men det är inte en magisk linje. Att sätta ett tröskelvärde innebär att välja en avvägning mellan typer av fel, arbetsbelastning, fördröjning och potentiell skada. Ett tröskelvärde kan vara lämpligt för att prioritera en granskningskö med låga konsekvenser och olämpligt för att neka en person tillgång till en tjänst. Samma numeriska tröskelvärde kan betyda olika saker när basfrekvensen, felkostnaden, tillgänglig rättelse och kvaliteten på efterföljande granskning ändras. Det finns inget universellt förnuftigt tal som väntar i en leverantörshandbok.
Av den anledningen bör en beslutsregel beskriva mer än en gräns. Den bör namnge det utfall som uppskattas, den bevisning som stöder resultatet, de fall som ligger utanför omfattningen, de omständigheter som tvingar till avhållsamhet, den mänskliga auktoritet som kvarstår, det register som kommer att föras och villkoren för att ompröva regeln. Ett tröskelvärde utan dessa följeslagare är ett beslut förklätt som konfiguration.
Ett användbart hypotetiskt exempel illustrerar poängen utan att uppfinna en offentlig incident. Tänk dig en tjänst som använder ett modellresultat för att sortera inkommande förfrågningar till en utbildad granskare. Bevisningen kan stödja ett begränsat påstående: resultatet kan hjälpa till att ordna jämförbara förfrågningar inom en angiven intagskategori, medan all slutlig prioritering ligger kvar hos granskaren. Samma bevisning stöder inte automatiskt avvisande av förfrågningar med låga resultat, eftersom det är en annan åtgärd med andra konsekvenser och andra bevisbehov. Utdatan ändrades inte. Dess auktoritet gjorde det.
Att avstå förtjänar samma allvar. Ett system som kan säga att dess underlag är otillräckligt kan skapa mer arbete på kort sikt och minska oupptäckta fel på lång sikt. Men avstående är bara användbart när det finns någon ansvarig att lämna över till. Om osäkra fall försvinner in i en kö utan ägare har systemet helt enkelt omvandlat osäkerhet till fördröjning. En bra väg anger vem som tar emot ärendet, vad de kan se, hur de rättar det och hur den rättningen informerar senare utvärdering.
Kausala påståenden kräver mer än ett före-och-efter-diagram
Sannolikhetsuppskattningar används ofta för att stödja påståenden om vad som kommer att hända om en organisation agerar. Det är en annan typ av bevisuppgift än att förutsäga vad som hände i historiska data. En modell kan uppskatta att ett ärende liknar andra ärenden med ett visst utfall. Det visar därmed inte att en förändring av ärendet, en policyändring eller ett följande av en rekommendation kommer att få utfallet att förändras. Prediktion och intervention bör inte blandas samman bara för att diagrammet ser prydligt ut.
Före-och-efter-siffror är särskilt frestande. Ett team introducerar ett verktyg, ett utfall förändras, och verktyget får äran eller skulden. Många andra saker kan ha förändrats: populationen som kommer in i verksamheten, dokumentationen, bemanningen, policyn, säsongsvariationer, uppströmsfilter eller själva mätningen. Observationen kan vara värd uppmärksamhet. Den är inte en kausal slutsats förrän jämförelsen, alternativa förklaringar och kvarvarande osäkerhet har hanterats.
Detta är viktigt för AI-styrning eftersom ett system kan vara operativt inflytelserikt långt innan det formellt är avgörande. En rangordning kan ändra vilken post en person öppnar först. En konfidensindikator kan knuffa en granskare att acceptera ett resultat. En rekommenderad åtgärd kan bli rutin eftersom kön är full. Den kausala vägen inkluderar mänsklig tolkning, gränssnittsdesign, incitament, tidspress och den tillgängliga korrigeringsvägen. Att utvärdera enbart modellen kan inte berätta hela historien.
När ett kausalt påstående är viktigt bör bevisplanen ange vilken jämförelse som skulle göra påståendet mer trovärdigt och vad den fortfarande inte skulle kunna utesluta. Det kan innebära ett kontrollerat test, en stegvis utrullning, en oberoende granskning, en omsorgsfullt konstruerad observationsdesign eller ett beslut att avstå från ett kausalt påstående helt och hållet. Poängen är inte att kräva akademisk perfektion av varje operativ förändring. Det handlar om att matcha påståendets säkerhet mot de bevis som faktiskt finns tillgängliga.
Det finns en holländsk sorts sunt förnuft i detta, även om det fungerar överallt: om du bara har mätt att vinden ändrades, meddela inte att du har konstruerat om vädret. En prediktion kan vara värdefull utan att bli en berättelse om kausalitet. Ärligheten är inte en reträtt. Det är det som gör resultatet användbart för någon som måste bestämma vad som ska göras härnäst.
Noggrannhet kan dölja en dålig beslutsregel
Noggrannhet är ofta användbar och ofta otillräcklig. Ett system kan uppnå hög noggrannhet där ett utfall är vanligt, samtidigt som det ger lite hjälp i de fall som betyder mest. Det kan ha ett starkt genomsnitt samtidigt som det presterar dåligt nära åtgärdsgränsen. Det kan göra korrekta prediktioner utan att erbjuda sannolikhetsuppskattningar som stödjer rimliga tröskelvärden. Det kan se framgångsrikt ut eftersom referensetiketten är lätt att förutsäga, även om etiketten i sig är en svag proxy för det beslut verksamheten behöver fatta.
Inget av detta innebär att noggrannhet är meningslös. Det innebär att läsaren bör fråga vad den mäter och vad den lämnar utanför bilden. AI-förordningen erkänner detta behov av sammanhang i sina krav på bruksanvisningar: dokumentationen för högrisksystem måste innehålla prestandaegenskaper och begränsningar, avsedd användning, relevanta noggrannhetsmått som använts för att testa och validera systemet, samt kända eller rimligen förutsebara omständigheter som kan påverka förväntad prestanda. En noggrannhetssiffra blir mer användbar när dess omgivande förhållanden hålls kvar.
En bra operativ granskning frågar därför efter felmönster, inte bara totaler. Vilka typer av fall klassificerades fel? Vilka var osäkra? Vilka fall exkluderades eller skickades för granskning? Vad händer med ett falskt positivt resultat, ett falskt negativt resultat, ett försenat svar eller en obefogad avhållsamhet? Vem kan upptäcka resultatet, ifrågasätta det och korrigera uppgifterna? Dessa frågor återför utvärderingen till tjänsten snarare än att lämna den hos modellen.
Det kan också vara användbart att skilja bevis för en komponent från bevis för ett arbetsflöde. Ett komponenttest kan fastställa egenskaper hos en modell under definierade indata. En arbetsflödesutvärdering kan fastställa hur modellen, gränssnittet, datan, människorna och policyn samverkar. En komponent kan ha stark kalibrering av poäng medan arbetsflödet ger upphov till automatiseringsbias eftersom gränssnittet döljer osäkerhet. Ett arbetsflöde kan ha en utmärkt granskningsprocess samtidigt som det förlitar sig på en komponent vars källdata inte längre passar den angivna omfattningen. Testerna måste mötas någonstans.
De resulterande bevisen är inte nödvändigtvis en storslagen rapport. Det kan vara en kortfattad, versionshanterad post om beslutet är snävt. Det viktiga är att en annan person kan granska påståendet, populationen, metoden, resultatet, begränsningen och beslutet. Filens storlek avgör inte kvaliteten på resonemanget. En kort post kan vara rigorös. En stor presentation kan till stor del vara luft.
Förändring gör gårdagens bevis till en fråga
Varje utvärderingsresultat har ett datum, även när datumet är dolt. Modeller förändras. Promptar förändras. Datakällor förändras. Ett uppströmsformulär får ett nytt fält. En leverantör ändrar en policy. Ett team flyttar en tjänst till en annan miljö. En ny grupp börjar använda systemet. Ett mått beräknas efter en ändrad granskningsprocess. Varje förändring kan ändra det påstående som de tidigare bevisen stödde.
Rätt svar är inte att köra om varje test efter varje redigering. Det är att definiera vilka förändringar som är väsentliga för vilka påståenden. En färgändring kanske inte påverkar sannolikhetskalibreringen. En ny ingångskanal kan göra det. En reviderad etikettpolicy kan ändra resultatdefinitionen. En ny modellversion kan ändra både prestanda och tolkningen av dess poäng. En ändring av den befogenhet som ges till systemet kan ogiltigförklara en beslutsregel även om modellen förblir identisk byte för byte. Testplanen bör göra dessa relationer synliga innan en release är bekväm.
Artikel 9 i AI-förordningen beskriver en kontinuerlig, iterativ riskhanteringsprocess för högrisksystem under hela deras livscykel. Processen omfattar att identifiera och analysera kända och rimligen förutsebara risker, uppskatta och utvärdera risker när systemet används som avsett och under rimligen förutsebart missbruk, samt att vidta riskhanteringsåtgärder. Poängen för utvärdering är direkt: bevis är inte en engångsceremoni vid lansering. Det tillhör ett operativt system av granskning, förändring och respons.
Att övervaka innebär inte att samla in varje tillgänglig signal och hoppas att ett mönster visar sig av sig självt. Det innebär att avgöra vilken observation som skulle kunna återuppta ett ärende. En kalibreringskontroll kan schemaläggas efter period, volym eller förändrad inmatningsmix. Ett tröskelvärde kan ses över när trycket i kön förändrar kvaliteten på den mänskliga tillsynen. En ändring av datakällan kan pausa en användning tills det relevanta testet upprepas. En seriös övervakningsplan anger vad som övervakas, av vem, mot vilken referens, och vilken åtgärd som följer.
Detta är mer krävande än ett modellkort som arkiveras på inköpsdagen, men det är också mer användbart. Ett statiskt dokument kan bevara vad som påstods. En levande bevispost kan visa om påståendet fortfarande har en hemvist. För ett probabilistiskt system är skillnaden densamma som mellan att veta att poängen fanns och att veta om den fortfarande betyder det tjänsten tror att den betyder.
Poster gör att en senare läsare kan invända på rätt sätt
Bevis behöver minne. En senare granskare kan inte bedöma ett påstående utifrån en skärmdump av en poäng och ett minne från mötet. De behöver det versionshanterade objektet: frågan, inmatningsförhållandena, test- eller observationsmetoden, resultatet, undantagen, osäkerheten, beslutet och ägaren. De kan också behöva veta vad som inte fångades. En post som gör sina blinda fläckar synliga är mer användbar än en perfekt utseende post som lämnar systemets tillstånd åt gissningar.
För AI-system med hög risk kräver AI-förordningen automatisk registrering av händelser under systemets livslängd, med loggningsfunktioner som är lämpliga för det avsedda syftet och användbara för att identifiera risker, stödja övervakning efter utsläppande på marknaden och övervaka driften. Den kräver också att teknisk dokumentation upprättas innan ett system släpps ut på marknaden och hålls uppdaterad. Dessa krav är inte bara en inbjudan att föra fler loggar. De är en inbjudan att göra loggar begripliga i relation till ett system, ett syfte och ett beslut.
Spårbarhet är särskilt viktig när sannolikhet tolkas av en människa. Om en granskare ser en poäng bör bevisposten göra det möjligt att rekonstruera vad poängen var kopplad till, hur den presenterades, vilka data eller källor som ingick, vad granskaren beslutade och om en senare korrigering skedde. Utan den kedjan kan ett team lära sig att ett utfall var fel men inte om problemet låg i inmatningen, modellen, gränssnittet, beslutsregeln eller den mänskliga processen runt omkring.
På Dweve är AION ett litet, relevant exempel på den bredare principen, inte ett påstående om att bevis kan reduceras till kryptografi. Dess offentliga beskrivning säger att en producent kan utfärda ett typat certifikat tillsammans med ett resultat och att AION kontrollerar certifikatet oberoende mot de ursprungliga premisserna. En sådan kontrollerbar post kan stärka ett snävt påstående om huruvida ett resultat följer av registrerade premisser. Den bevisar inte att premisserna var lämpliga, att uppgiften var rättvis eller att användningen var lämplig. Bevis kräver både verifiering och omdöme.
Den begränsningen är värd att behålla eftersom den förhindrar ett vanligt kategorifel. En perfekt bevarad spårning kan visa vad som hände. Den kan inte göra en dåligt formulerad fråga bra. Ett reproducerbart beslut kan fortfarande vara ett beslut som aldrig borde ha automatiserats. Posten bör hjälpa en senare läsare att ställa båda frågorna, inte i förtid besvara den andra.
Förtroende kan vara ärligt utan att vara användbart
En väl kalibrerad sannolikhet kan fortfarande vara till liten hjälp. Den kan vara för bred för att skilja mellan fall som kräver olika behandling. Den kan komma för sent för att påverka beslutet. Den kan vara knuten till ett utfall som inte är åtgärdbart. Den kan vara så osäker att varje fall kräver samma granskning. Detta är inte brister i ärlighet. Det är begränsningar i användbarhet, och de bör erkännas tidigt snarare än upptäckas efter att ett arbetsflöde har byggts kring poängen.
Omvänt behöver ett användbart system inte låtsas vara säkert. En blygsam signal kan förbättra hur arbetet organiseras om den har ett snävt syfte och en tydlig granskningsväg. Den kan hjälpa en operatör att se vilka fall som förtjänar ytterligare en källkontroll. Den kan välja ut en liten uppsättning för kvalitetssäkring. Den kan synliggöra en konflikt mellan register. I sådana användningar handlar evidenskravet om huruvida signalen förbättrar den specifika beslutsprocessen utan att införa oacceptabla nya fel eller beroenden. Signalen behöver inte bli ett orakel för att förtjäna en plats.
Det är därför det avsedda syftet måste styra utvärderingen. OECD:s AI-principer kräver meningsfull information om systemens förmågor och begränsningar, samt spårbarhet i förhållande till datamängder, processer och beslut så att utdata kan analyseras och frågor besvaras. Principerna kräver också lämplig mänsklig handlingsfrihet och tillsyn. Den praktiska innebörden är inte att varje gränssnitt behöver en sannolikhetsvisning. Det är att ett systems evidens och förklaring bör passa den person och det beslut som påverkas av det.
Det finns ingen belöning för att exponera ett osäkerhetsvärde som en användare inte kan tolka eller agera på. En siffra utan en beslutsväg kan skapa transparensens teater. Den ger människor något att peka på och inget sätt att utmana det. Bättre att visa den relevanta gränsen i klartext, till exempel detta förslag ligger utanför den validerade kategorin, eller detta resultat kräver granskning eftersom tillgänglig evidens är ofullständig. Den lämpliga presentationen följer den operativa kontrollen, inte tvärtom.
Av samma skäl bör en konfidenspoäng inte behandlas som ett mått på moraliskt värde, trovärdighet eller rättighet. Det är ett tekniskt uttalande med ett begränsat evidenskontrakt. Den kan hjälpa en process. Den bör inte bli en vag social rangordning bara för att dess numeriska form får den att se avgörande ut.
Organisationen äger inferensen
Leverantörer kan tillhandahålla modeller, dokumentation, poäng och testresultat. De kan inte i tysthet äga innebörden av ett beslut som fattas i någon annans tjänst. Den organisation som kopplar en probabilistisk utdata till en åtgärd måste avgöra vilken proposition den förlitar sig på, vilken population som är relevant, vilket tröskelvärde som är acceptabelt, vem som granskar avvikelser, vilka register som bevaras och när bevis har upphört att gälla. Kontrakt kan fördela uppgifter. De undanröjer inte behovet av omdöme.
Detta blir synligt vid upphandling. En köpare bör fråga en presumtiv leverantör inte bara om ett övergripande mätetal utan också om utvärderingsfrågan, populationen, etiketterna, undantagen, versionerna, variationen, kalibreringsmetoden om ett sannolikhetspåstående görs, kända begränsningar och ändringspolicy. Poängen är inte att kräva offentliggörande som leverantören inte lagligen kan tillhandahålla. Det är att fastställa om köparen kan förstå gränsen för påståendet tillräckligt väl för att använda det ansvarsfullt i en europeisk operativ kontext.
Svaret kan ibland vara att bevisen inte är tillräckliga för den avsedda användningen. Det är inte en misslyckad upphandlingsprocess. Det är upphandlingsprocessen som gör sitt faktiska jobb innan organisationen har gjort sig beroende av en oförklarad poäng. En mindre, granskningsbar användning kan fortfarande vara möjlig. En annan leverantör kan vara lämplig. Eller så kan beslutet förbli mänskligt eftersom bevisen och korrigeringsvägen inte är tillräckligt starka för att motivera automatisering. Att säga nej är en del av bevisdisciplinen.
Bevis behöver också en namngiven ägare efter lansering. Någon måste vara ansvarig för att kontrollera om populationen har förskjutits, om granskningar avslöjar ett nytt felmönster, om ett tröskelvärde fortfarande passar arbetsbelastningen, om register kan tolkas och om en ändring utlöser omprövning. Ägaren behöver inte personligen utföra varje test. Men om ingen roll äger inferensen kommer systemet gradvis att förvärva auktoritet genom vana. Vana är en dålig ersättning för en beslutsjournal.
Den svåraste delen är ofta kulturell. Team är vana vid att presentera framgångsrika modeller som produkter och misslyckade modeller som forskning. Probabilistiska bevis ber dem att bevara tvetydigheten däremellan: användbar, avgränsad, övervakad och ännu inte licensierad att bli mer än vad bevisen stöder. Det kan låta mindre spännande. Det är mer beständigt.
Vad en proportionerlig bevisjournal innehåller
Den lämpliga journalen beror på användningen. Ett skrivhjälpmedel som används av en författare har andra konsekvenser än ett system som påverkar tillgången till en offentlig tjänst. Ändå har en proportionerlig journal en igenkännbar form. Den identifierar påståendet och det avsedda syftet. Den identifierar modellen, konfigurationen och det omgivande arbetsflödet. Den definierar utfallet och populationen som används för att utvärdera påståendet. Den bevarar metoden, resultatet och meningsfulla begränsningar. Den identifierar beslutsregeln, ägaren, granskningsvägen och ändringsutlösarna. Varje fält ger en senare läsare någonstans att börja.
Journalen bör skilja mätning från tolkning. En uppmätt observation kan säga att, på en specificerad datamängd och period, motsvarade en angiven uppsättning poäng observerade utfall inom ett beskrivet intervall. En tolkning kan säga att detta stöder användning som en granskningsordnande signal under specificerade kontroller. Ett beslut kan säga att systemet får användas för det syftet tills en angiven ändringsutlösare inträffar. Att placera alla tre meningarna under en rubrik som kallas prestanda är effektivt bara om ingen någonsin behöver ifrågasätta resonemanget.
Det bör också göra okända faktorer användbara. Kanske är etiketterna försenade. Kanske saknar en liten språkgrupp tillräckligt med fall för en stabil kalibreringsbedömning. Kanske är driftsättningen ny och det finns ännu inga operativa bevis. Journalen kan säga det, sätta en tillfällig gräns för användning, ordna mer observation eller behålla en mänsklig väg. Att låtsas att det okända har lösts för att en modell har producerat en siffra omvandlar bara osäkerhet till en odokumenterad skuld.
Den visuella disciplinen är användbar här. Rita kedjan från indata till poäng, från poäng till visad förklaring, från förklaring till mänsklig handling och från handling till observerat resultat och korrigering. Rita var tillstånd fångas, var det går förlorat och var en person kan stoppa eller vända på vägen. Om teamet inte kan rita vägen är det osannolikt att de kan utvärdera den. Diagram ersätter inte bevis. De förhindrar att bevis tilldelas fel del av systemet.
Framför allt, skriv ner vad journalen inte fastställer. Den kanske inte fastställer kausalitet. Den kanske inte fastställer rättvisa över varje grupp. Den kanske inte fastställer beteende efter en leverantörsförändring. Den kanske inte fastställer lämplighet för en mer konsekvensrik åtgärd. Dessa icke-påståenden är inte en ursäkt. De är det som hindrar en avgränsad utvärdering från att användas som en universell auktorisation.
Bevis ger rätten att förbli osäker
Det finns en frestelse att tro att syftet med utvärdering är att ta bort osäkerhet. Ofta är det bättre syftet att lokalisera den. Ett probabilistiskt system är inte defekt för att det inte kan omvandla varje fall till en säkerhet. Det blir farligt när organisationen behandlar osäkerhet som en privat teknisk detalj samtidigt som den ger resultatet offentlig auktoritet. Arbetet är att besluta vilken osäkerhet som är tolerabel, synlig och återställbar för det aktuella ändamålet.
Det beslutet bör bli mer krävande i takt med att konsekvenserna ökar. Ett förslag med låg konsekvens kan behöva en tydlig omfattning, en synlig begränsning och en enkel korrigering. Ett system som påverkar rättigheter, säkerhet, tillgång eller materiella möjligheter behöver starkare bevis om hela processen, noggrannare övervakning, meningsfull mänsklig auktoritet och en väg till utmaning och gottgörelse. Modellens poäng avgör inte den standarden ensam. Effekten av att agera på den gör det.
En enda framgångsrik körning kan fortfarande vara värd att behålla. Det kan vara det första exemplaret i en användbar journal. Det kan avslöja en förmåga, ett felsätt eller en fråga som förtjänar en ordentlig utvärdering. Men det bör förbli ett exemplar tills organisationen har testat propositionen som den vill förlita sig på. Avståndet mellan dessa två saker är där ansvarsfull ingenjörskonst lever.
Så svaret på vad som räknas som bevis när maskinen är probabilistisk är inte en poäng, ett diagram eller en efterlevnadsetikett. Det är ett avgränsat argument: denna utdata, för denna fråga, i denna population och period, under dessa villkor, har observerats på detta sätt; detta är vad vi kan sluta oss till; detta är vad vi inte kan sluta oss till; och detta är den åtgärd som vi är, eller inte är, beredda att låta den förändra. Det argumentet är inte glamoröst. Det är inspekterbart, vilket är bättre.