Dlaczego nie ma endpointu
Model, środowisko wykonawcze i cała analiza są pobierane do przeglądarki i tam uruchamiane. Nie jest to kwestia konfiguracji wdrożenia, którą można zmienić jednym parametrem; to cała architektura systemu, dzięki której obraz nigdy nie opuszcza urządzenia, na którym jest sprawdzany.
API odwraca ten proces. Obraz jest wysyłany na serwer, serwer go ocenia i zwraca wynik liczbowy — w tym momencie obraz znajduje się na infrastrukturze kontrolowanej przez kogoś innego, niezależnie od tego, jak krótko to trwa i jak dobre są intencje usługodawcy.
Dla narzędzia, którego głównym założeniem jest brak przesyłania czegokolwiek na serwer, udostępnienie endpointu do przesyłania plików byłoby wewnętrzną sprzecznością. Dlatego ta strona nie przedstawia planów rozwoju, lecz opisuje ograniczenie i sposoby radzenia sobie z nim.
Warto powiedzieć to wprost, ponieważ alternatywa jest gorsza. Strona sugerująca istnienie nieistniejącego endpointu marnuje czas inżynierów, a cennik w tym serwisie jasno informuje o braku płatnych planów i braku API.
Do czego w rzeczywistości służy automatyzacja
Zanim sięgniesz po endpoint, warto precyzyjnie zdefiniować zadanie, ponieważ znaczną część planowanych procesów automatyzacji można lepiej rozwiązać w inny sposób.
| Wymaga usługi | Wystarczy narzędzie w przeglądarce | Lepsza jest weryfikacja manualna | |
|---|---|---|---|
| Masowa weryfikacja plików przesyłanych przez użytkowników | Yes Wolumen i opóźnienia | No | No |
| Sprawdzanie dostaw od podwykonawcy | No | Yes Wystarczy partia 25 plików | Partly |
| Weryfikacja dokumentacji szkody | No | Yes Jedna partia na zgłoszenie | Yes Ocena stanowi sedno pracy |
| Audyt własnego serwisu | Partly Tylko w przypadku ogromnej skali | Yes Wyodrębnij i sprawdź partiami | No |
Trzy z tych czterech zadań może zrealizować człowiek przetwarzający pliki partiami — warto to ustalić, zanim ktokolwiek zacznie pisać kod. Pierwszy wiersz to zupełnie inny przypadek, który faktycznie wymaga hostowanej usługi.
Jeśli rzeczywiście potrzebujesz automatyzacji
Istnieją trzy rzetelne ścieżki, a każda z nich wiąże się z innym kompromisem. Udawanie, że jest inaczej, nikomu nie pomaga.
| Opcja | Kompromis | Dla kogo |
|---|---|---|
| Komercyjne API | Obrazy opuszczają Twoją infrastrukturę | Duży wolumen, niska wrażliwość danych |
| Własny hosting otwartego modelu | Czas pracy inżynierów i koszty sprzętu | Wrażliwe dane, własne zaplecze techniczne |
| Uruchomienie w kontrolowanej przez siebie przeglądarce | Niezręczne, ale prywatne | Umiarkowany wolumen, ścisła prywatność |
| Próbkowanie zamiast pełnego skanowania | Pokrycie jest częściowe | Większość rzeczywistych obciążeń |
| Etap weryfikacji przez człowieka | Wolniejsza, lepsza ocena | Wszystko, co wpływa na człowieka |
Trzeci wiersz wymaga wyjaśnienia, ponieważ jest rzadko wykorzystywany. Przeglądarka headless uruchomiona na własnej maszynie, obsługująca stronę wykonującą analizę lokalnie, to w pełni poprawny sposób na automatyzację bez wysyłania obrazów na zewnątrz. Rozwiązanie mało spektakularne, ale skuteczne.
Czwarty wiersz to opcja, którą większość zespołów powinna wybrać, a rzadko bierze pod uwagę. Skanowanie każdego obrazu jest kosztowne i zwykle zbędne; próbkowanie 10 procent plus sprawdzanie wszystkiego ze źródeł, które sprawiały wcześniej problemy, wyłapuje większość istotnych przypadków za ułamek kosztów.
W przypadku self-hostingu
Jest to łatwiejsze do osiągnięcia, niż się powszechnie uważa, ponieważ modele badawcze w tej dziedzinie są w dużej mierze publicznie dostępne. Punkt kontrolny opublikowany na liberalnej licencji, środowisko uruchomieniowe do inferencji i skromny serwer odtworzą większość tego, co oferują płatne usługi komercyjne.
Wyzwanie stanowi cała otoczka modelu: utrzymywanie go na bieżąco w miarę zmian w generatorach, kalibracja progu dla własnych materiałów, mierzenie własnego odsetka fałszywych trafień oraz posiadanie kogoś, kto potrafi obronić i wyjaśnić wynik w razie wątpliwości.
Ten ostatni punkt to ukryty koszt. Możliwość detekcji, której nikt w organizacji nie rozumie na tyle dobrze, by jej obronić, staje się obciążeniem przy pierwszej zakwestionowanej decyzji — a taka sytuacja prędzej czy później nastąpi.
Niezależnie od tego, co budujesz, uwzględnij te zasady
Dwie decyzje projektowe mają większe znaczenie niż wybór modelu, i obie dotyczą tego, co dzieje się po uzyskaniu wyniku.
Nigdy nie pozwól, aby wynik decydował o człowieku w sposób automatyczny. Przekazuj zgłoszenia człowiekowi, rejestruj decyzję podjętą przez człowieka, a nie ocenę modelu, i upewnij się, że osobie, której to dotyczy, można wyjaśnić powód weryfikacji.
Zapisuj rozstrzygnięcia, a nie wyniki punktowe. Możliwa do przeszukania historia liczb przypisanych do konkretnych użytkowników lub dostawców stanowi profilowanie wymagające odrębnego uzasadnienia, nie wnosi wartości operacyjnej i staje się problemem, gdy ktoś zażąda wglądu w swoje dane.
Realistyczny punkt wyjścia
Dla większości zespołów szukających automatyzacji rozsądna pierwsza wersja nie wymaga żadnych prac inżynieryjnych: jedna osoba, jedna partia na każde zgłoszenie i notatka w aktach o ustaleniach.
Daje to wymierną wartość już po tygodniu: obraz tego, jakie wyniki uzyskują Twoje własne materiały. Niemal nikt nie ma tej wiedzy na początku, a bez niej każdy próg ustawiony w kodzie jest zgadywaniem rozkładu, którego nigdy nie zmierzono.
Gdy wiesz już, gdzie plasują się Twoje obrazy, potrzeba automatyzacji staje się konkretna, a nie teoretyczna. Dowiesz się, ile zgłoszeń tygodniowo rzeczywiście wymaga wglądu — często ta liczba sprawia, że prace inżynieryjne okazują się zbędne.
A jeśli automatyzacja okaże się potrzebna, będzie oparta na zmierzonym punkcie odniesienia, a nie na danych publikowanych przez innych. To różnica między zabezpieczeniem działającym na własnych danych a dopasowanym do cudzego benchmarku.
Co zmierzyć przed wdrożeniem jakichkolwiek rozwiązań
Trzy liczby zamieniają ogólny zamiar w specyfikację — wszystkie trzy wynikają z ręcznego sprawdzania partii danych przez dwa tygodnie.
Rozkład własnych materiałów: jakie wyniki uzyskują autentyczne obrazy z Twoich standardowych źródeł. Prawie każdy zespół jest zaskoczony, zwykle dlatego, że ich pliki wejściowe są mocniej przetworzone, niż sądzono.
Własny odsetek fałszywych trafień: jak często po weryfikacji okazuje się, że zgłoszony obraz przeszedł jedynie standardową obróbkę. To ta wartość decyduje o przydatności procedury wobec ludzi i nigdy nie pokrywa się z danymi dostawcy.
Rzeczywisty wolumen zgłoszeń: ile elementów tygodniowo musiałby sprawdzić człowiek. Jeśli ta liczba jest niewielka, planowana automatyzacja sprowadza się do arkusza kalkulacyjnego i wyrobienia nawyku.