Perché non c'è un endpoint
Il modello, il runtime e l'analisi vengono scaricati sul browser ed eseguiti localmente. Non si tratta di una scelta di distribuzione reversibile, ma dell'architettura stessa; ecco perché un'immagine non lascia mai il dispositivo su cui viene analizzata.
Una API inverte questo processo. Qualcuno invia un'immagine a un server, il server assegna un punteggio e invia il risultato, e l'immagine ora esiste su un'infrastruttura controllata da terzi, indipendentemente dalla durata o dalle buone intenzioni.
Per uno strumento il cui presupposto fondamentale è che nulla venga caricato, offrire un endpoint di caricamento significherebbe contraddirsi. Pertanto, questa pagina non descrive una roadmap, ma descrive un limite e le azioni da intraprendere.
Vale la pena dirlo chiaramente perché l'alternativa è peggiore. Una pagina che sottintende l'esistenza di un endpoint inesistente spreca il tempo di un ingegnere; la pagina dei prezzi su questo sito dichiara già che non esiste un livello a pagamento né una API.
A cosa serve realmente l'automazione
Prima di cercare un endpoint, è utile definire con precisione l'obiettivo, poiché buona parte dell'automazione desiderata si risolve meglio in altri modi.
| Richiede un servizio | Lo strumento browser funziona | Un intervento umano è preferibile | |
|---|---|---|---|
| Screening dei caricamenti utenti su larga scala | Yes Volume e latenza | No | No |
| Controllo di una consegna da fornitore | No | Yes Un lotto di 25 è sufficiente | Partly |
| Revisione di un fascicolo di reclamo | No | Yes Un lotto per ogni invio | Yes Il giudizio è l'attività principale |
| Audit del proprio sito | Partly Solo se enorme | Yes Estrarre e gestire in lotti | No |
Tre di queste quattro righe sono soddisfatte da una persona che gestisce lotti, un aspetto da valutare prima di scrivere codice. La prima riga è realmente diversa ed è quella che richiede un servizio in hosting.
Se serve veramente l'automazione
Esistono tre percorsi corretti, ognuno dei quali comporta compromessi diversi. Fingere il contrario non aiuta nessuno.
| Opzione | Compromesso | Adatto a |
|---|---|---|
| Una API commerciale | Le immagini lasciano la tua infrastruttura | Volume elevato, bassa sensibilità |
| Auto-ospitare un modello aperto | Tempo di ingegneria e hardware | Dati sensibili, capacità interna |
| Eseguirlo in un browser sotto il tuo controllo | Scomodo ma privato | Volume moderato, privacy rigorosa |
| Campionamento invece di screening | Copertura parziale | La maggior parte dei carichi di lavoro reali |
| Una fase di revisione umana | Giudizio più lento e migliore | Qualsiasi cosa riguardi una persona |
La terza riga merita una spiegazione perché è sottoutilizzata. Un browser headless che gira sul proprio computer, gestendo una pagina che esegue l'analisi localmente, è un modo legittimo per automatizzare senza inviare immagini altrove. Non è appariscente, ma funziona.
La quarta riga è quella che la maggior parte dei team dovrebbe scegliere ma considera raramente. Controllare ogni singola immagine è costoso e solitamente non necessario; campionare il dieci per cento, più tutto ciò che proviene da una fonte che ha già creato problemi, rileva la maggior parte di ciò che conta a una frazione del costo.
Se si esegue l'hosting in proprio
È più fattibile di quanto si pensi, perché i modelli di ricerca in questo campo sono in gran parte pubblici. Un checkpoint pubblicato con una licenza permissiva, un runtime di inferenza e un server modesto riprodurranno gran parte di ciò che un servizio commerciale vende.
Ciò di cui ci si fa carico è tutto ciò che ruota attorno al modello. Mantenerlo aggiornato man mano che i generatori cambiano, calibrare una soglia per il proprio materiale, misurare il proprio tasso di falsi positivi e avere qualcuno in grado di spiegare un risultato quando viene contestato.
Quest'ultimo punto è il costo nascosto. Una capacità di rilevamento che nessuno nell'organizzazione comprende abbastanza bene da difendere è una passività la prima volta che una decisione basata su di essa viene messa in discussione, e quella domanda arriva sempre.
Qualunque cosa costruiate, includetelo
Due decisioni di progettazione contano più del modello che si usa, ed entrambe riguardano ciò che accade dopo il punteggio.
Non lasciate mai che un punteggio decida automaticamente qualcosa su una persona. Inviate le segnalazioni a un essere umano, registrate cosa ha deciso l'umano anziché cosa ha detto il modello, e assicuratevi che la persona coinvolta possa essere informata del perché è stato effettuato un controllo.
E archiviate i risultati, non i punteggi. Una cronologia ricercabile di numeri associati a utenti o fornitori nominativi è un record di profilazione che necessita di una propria giustificazione, non aggiunge valore operativo e diventa un problema nel momento in cui qualcuno richiede i propri dati.
Un punto di partenza realistico
Per la maggior parte dei team che arrivano qui cercando l'automazione, la prima versione sensata non richiede alcuna attività di ingegneria. Una persona, un lotto per ogni invio in arrivo e una nota nel file su ciò che è stato trovato.
Ciò produce qualcosa di prezioso entro una settimana: il senso del punteggio del proprio materiale. Quasi nessuno ce l'ha quando inizia e, senza di esso, qualsiasi soglia impostata nel codice è solo una stima basata su una distribuzione mai misurata.
Una volta noto dove si collocano le proprie immagini, il caso per l'automazione diventa concreto anziché teorico. Si saprà quanti invii a settimana meritano effettivamente un'occhiata e spesso la risposta rende superflua l'ingegneria.
Laddove non lo fosse, si automatizzerà almeno rispetto a una baseline misurata anziché una pubblicata, il che rappresenta la differenza tra un controllo che funziona sui propri dati e uno che funziona sul benchmark di qualcun altro.
Cosa misurare prima di costruire qualsiasi cosa
Tre numeri trasformano una vaga intenzione in una specifica, e tutti e tre derivano dall'esecuzione manuale di lotti per quindici giorni.
La distribuzione del proprio materiale: dove finiscono effettivamente le immagini autentiche dalle proprie fonti abituali. Quasi ogni team è sorpreso, solitamente perché i propri input sono più elaborati di quanto pensassero.
Il proprio tasso di falsi positivi: quanto spesso una segnalazione risulta essere una normale elaborazione quando qualcuno indaga. Questo è il numero che decide se un controllo è utilizzabile su persone reali, e non è mai il numero presente sulla pagina di un fornitore.
Il volume che verrebbe effettivamente segnalato: quanti elementi a settimana un essere umano dovrebbe controllare. Se quel numero è piccolo, l'automazione pianificata è solo un foglio di calcolo e un'abitudine.