Varför det inte finns någon slutpunkt
Modellen, körmiljön och analysen laddas alla ner till webbläsaren och körs där. Det är inte ett driftsättningsbeslut som kan ändras med en flagga; det är hela arkitekturen, och det är anledningen till att en bild aldrig lämnar enheten den kontrolleras på.
Ett API vänder på detta. Någon skickar en bild till en server, servern poängsätter den och skickar tillbaka ett värde, och bilden finns nu på infrastruktur som någon annan kontrollerar – hur kortvarigt det än är och hur goda deras avsikter än må vara.
För ett verktyg vars hela premiss är att ingenting laddas upp vore det en självmotsägelse att erbjuda en uppladdningsslutpunkt. Den här sidan beskriver därför inte en färdplan; den beskriver en begränsning och hur man hanterar den.
Det är värt att säga rakt ut eftersom alternativet är sämre. En sida som antyder en slutpunkt som inte finns slösar bort en eftermiddag för en utvecklare, och prissidan på denna webbplats anger redan att det inte finns någon betalnivå och inget API.
Vad automatisering egentligen är till för
Innan man sträcker sig efter en slutpunkt är det värt att vara precis med vad uppgiften innebär, eftersom en stor del av tilltänkt automatisering löses bättre på annat sätt.
| Kräver en tjänst | Webbläsarverktyg fungerar | Manuellt steg är bättre | |
|---|---|---|---|
| Granskning av användaruppladdningar i stor skala | Yes Volym och svarstid | No | No |
| Kontroll av en leverantörsleverans | No | Yes En batch på 25 räcker | Partly |
| Granskning av ett skadeärende | No | Yes En batch per ärende | Yes Bedömningen är själva arbetet |
| Granskning av den egna webbplatsen | Partly Endast vid enorma volymer | Yes Extrahera och kör i batch | No |
Tre av dessa fyra rader hanteras väl av en person som kör batcher, vilket är värt att fastställa innan någon skriver kod. Den första raden är genuint annorlunda, och det är den som kräver en serverbaserad tjänst.
Om du verkligen behöver automatisering
Det finns tre ärliga vägar, och var och en innebär olika kompromisser. Att låtsas om något annat hjälper ingen.
| Alternativ | Kompromiss | Passar för |
|---|---|---|
| Ett kommersiellt API | Bilderna lämnar din infrastruktur | Hög volym, låg känslighet |
| Driftsätt en öppen modell själv | Ingenjörs- och hårdvarutid | Känsliga data, intern kompetens |
| Kör det i en webbläsare du styr över | Omständligt men privat | Måttlig volym, strikt integritet |
| Ta stickprov snarare än att granska allt | Täckningen är partiell | De flesta verkliga arbetsflöden |
| Ett manuellt granskningssteg | Långsammare, bättre omdöme | Allt som påverkar en person |
Den tredje raden kräver en förklaring eftersom den är underutnyttjad. En headless-webbläsare som körs på din egen dator och styr en sida som utför analysen lokalt är ett legitimt sätt att automatisera utan att skicka bilder någonstans. Det är oglamoröst och det fungerar.
Den fjärde raden är den som de flesta team borde välja men sällan överväger. Att granska varje bild är dyrt och oftast onödigt; att ta stickprov på tio procent, plus allt från en källa som tidigare orsakat problem, fångar det mesta som spelar roll till en bråkdel av kostnaden.
Om du driftar själv
Detta är mer genomförbart än många tror, eftersom forskningsmodellerna inom detta område i stort sett är öppna. En kontrollpunkt publicerad under en tillåtande licens, en inferensmiljö och en enkel server återskapar det mesta av vad en kommersiell tjänst säljer.
Det du tar på dig är allt runt omkring modellen. Att hålla den uppdaterad när generatorerna förändras, kalibrera ett tröskelvärde för ditt eget material, mäta din egen andel falska positiva resultat och ha någon som kan förklara ett resultat när det ifrågasätts.
Den sista punkten är den dolda kostnaden. En detekteringsförmåga som ingen i organisationen förstår tillräckligt väl för att försvara blir en belastning första gången ett beslut baserat på den ifrågasätts – och den frågan kommer alltid förr eller senare.
Oavsett vad du bygger, bygg in detta
Två designbeslut är viktigare än vilken modell du använder, och båda handlar om vad som händer efter poängsättningen.
Låt aldrig ett poängvärde avgöra något om en person automatiskt. Dirigera flaggade fall till en människa, dokumentera vad människan beslutade snarare än vad modellen sa, och se till att personen som berörs kan få veta varför något ifrågasattes.
Och spara utfall, inte poängvärden. En sökbar historik med siffror kopplade till namngivna användare eller leverantörer är ett profileringsregister som kräver en egen motivering, inte tillför något operativt värde och blir ett problem i samma stund som någon begär ut sina personuppgifter.
En realistisk utgångspunkt
För de flesta team som kommer hit och vill ha automatisering kräver den första förnuftiga versionen ingen utveckling alls. En person, en batch per inkommande underlag och en anteckning i ärendet om vad de fann.
Det ger något värdefullt inom en vecka: en uppfattning om vilka poäng ditt eget material får. Nästan ingen har det när de börjar, och utan det är varje tröskelvärde du sätter i kod bara en gissning om en fördelning du aldrig har mätt.
När du väl vet var dina bilder ligger blir skälen för automatisering konkreta istället för teoretiska. Du vet hur många inskickade underlag i veckan som faktiskt kräver en titt, och ofta gör svaret utvecklingsarbetet onödigt.
Om det inte gör det kommer du åtminstone att automatisera mot en uppmätt baslinje snarare än en publicerad, vilket är skillnaden mellan en kontroll som fungerar på din egen data och en som fungerar på någon annans benchmark.
Vad du bör mäta innan du bygger något
Tre siffror förvandlar en vag avsikt till en specifikation, och alla tre kommer från att köra batcher manuellt under två veckor.
Fördelningen för ditt eget material: var äkta bilder från dina vanliga källor faktiskt landar. Nästan alla team blir överraskade, oftast för att deras underlag är mer bearbetade än de trodde.
Din egen andel falska positiva: hur ofta en flaggning visar sig vara vanlig redigering när någon undersöker saken. Detta är siffran som avgör om en kontroll kan användas på riktiga människor, och det är aldrig den siffra som står på en leverantörsida.
Volymen som faktiskt skulle flaggas: hur många objekt i veckan som en människa skulle behöva titta på. Om den siffran är låg är automatiseringen du planerade bara ett kalkylark och en vana.