Bakit walang endpoint
Ang modelo, ang runtime, at ang pagsusuri ay lahat nadodownload sa browser at doon tumatakbo. Hindi iyan desisyon sa deployment na mababago ng isang flag; iyan ang buong arkitektura, at iyan ang dahilan kung bakit hindi umaalis ang imahe sa device kung saan ito sinusuri.
Ang API ay binabaligtad iyon. May nagpapadala ng imahe sa server, ang server ang mag-i-score nito at magpapadala ng numero pabalik, at ang imahe ngayon ay nasa imprastraktura na kontrolado ng iba, gaano man ito kadali o gaano man kabuti ang kanilang intensyon.
Para sa isang tool na ang buong proposisyon ay walang ina-upload, ang pag-aalok ng upload endpoint ay magiging kontradiksyon sa produkto. Kaya ang pahinang ito ay hindi naglalarawan ng roadmap; inilalarawan nito ang isang limitasyon at kung ano ang dapat gawin tungkol dito.
Karapat-dapat itong sabihin nang malinaw dahil mas masama ang alternatibo. Ang pahinang nagpapahiwatig ng endpoint na wala naman ay nagsasayang ng oras ng engineer, at ang pricing page sa site na ito ay nagsasabi na na walang paid tier at walang API.
Para saan ba talaga ang automation
Bago mag-reach out para sa isang endpoint, mahalagang maging tumpak tungkol sa trabaho, dahil ang isang malaking bahagi ng nilalayong automation ay mas mabuting lutasin sa ibang paraan.
| Nangangailangan ng serbisyo | Gumagana ang browser tool | Mas mainam ang hakbang na may tao | |
|---|---|---|---|
| Screening ng mga upload ng user nang maramihan | Yes Dami at latency | No | No |
| Pagsusuri ng delivery ng supplier | No | Yes Sapat na ang batch na 25 | Partly |
| Pagrepaso sa isang claim bundle | No | Yes Isang batch bawat submission | Yes Ang paghuhusga ang trabaho |
| Pag-audit sa sarili mong site | Partly Kung napakalaki lang | Yes I-extract at i-batch | No |
Tatlo sa apat na row na iyon ay natutugunan ng isang taong nagpapatakbo ng mga batch, na mahalagang maitatag bago may sumulat ng code. Ang unang row ay talagang magkaiba, at iyon ang nangangailangan ng hosted service.
Kung kailangan mo talaga ng automation
May tatlong tapat na ruta, at bawat isa ay may kapalit na iba't ibang bagay. Ang pagpapanggap na hindi ay walang tinutulungan.
| Opsyon | Kapalit | Nababagay sa |
|---|---|---|
| Isang komersyal na API | Ang mga imahe ay umaalis sa iyong imprastraktura | Mataas na volume, mababang sensitivity |
| Self-host ng isang open model | Oras para sa engineering at hardware | Sensitibong data, in-house na kakayahan |
| Patakbuhin ito sa isang browser na kontrolado mo | Mahirap ngunit pribado | Katamtamang dami, mahigpit na privacy |
| Mag-sample sa halip na i-screen | Bahagya lang ang saklaw | Karamihan sa mga tunay na workload |
| Isang hakbang ng pagsusuri ng tao | Mas mabagal, mas mahusay na paghuhusga | Anumang bagay na nakakaapekto sa isang tao |
Ang ikatlong row ay nararapat na ipaliwanag dahil hindi ito masyadong nagagamit. Ang headless browser na tumatakbo sa iyong sariling makina, na nagpapatakbo ng page na gumagawa ng pagsusuri nang lokal, ay isang lehitimong paraan upang mag-automate nang hindi nagpapadala ng mga imahe kahit saan. Ito ay hindi glamoroso ngunit epektibo.
Ang ikaapat na row ang dapat piliin ng karamihan sa mga team pero bihira nilang isaalang-alang. Ang pag-screen sa bawat imahe ay mahal at karaniwang hindi naman kailangan; ang pag-sample ng sampung porsyento, kasama ang lahat mula sa isang source na nagkaroon na ng problema dati, ay nakakakuha ng karamihan sa mga mahalagang bagay sa mas mababang halaga.
Kung ikaw ang mag-host
Ito ay mas magagawa kaysa sa inaakala ng mga tao, dahil ang mga research model sa larangang ito ay halos publiko na. Ang checkpoint na inilathala na may permissive licence, inference runtime, at katamtamang server ay makakagawa ng karamihan sa mga ibinebenta ng komersyal na serbisyo.
Ang dapat mong harapin ay ang lahat ng bagay sa paligid ng model. Ang pagpapanatili nitong updated habang nagbabago ang mga generator, pag-calibrate ng threshold para sa sarili mong materyal, pagsukat sa sarili mong false positive rate, at pagkakaroon ng taong makakapaliwanag ng resulta kapag kinuwestiyon ito.
Ang huling puntong iyon ang nakatagong gastos. Ang kakayahan sa pagtukoy na hindi naiintindihan nang sapat ng sinuman sa organisasyon para ipagtanggol ay isang pananagutan sa unang pagkakataon na ang desisyong nakabatay dito ay kinuwestiyon, at ang tanong na iyon ay laging darating sa bandang huli.
Anuman ang buuin mo, isama ito
Dalawang desisyon sa disenyo ang mas mahalaga kaysa sa model na ginagamit mo, at pareho silang tungkol sa kung ano ang mangyayari pagkatapos ng score.
Huwag na huwag hayaang ang isang score ang awtomatikong magpasya tungkol sa isang tao. Ipadala ang mga flag sa isang tao, itala ang napagdesisyunan ng tao sa halip na kung ano ang sinabi ng model, at tiyaking ang taong naapektuhan ay nasasabihan kung bakit may kinuwestiyon.
At iimbak ang mga resulta, hindi ang mga score. Ang mahahanap na history ng mga numero na nakakabit sa mga pinangalanang user o supplier ay isang profiling record na mangangailangan ng sarili nitong katwiran, walang naidudulot na halagang operasyonal, at nagiging problema sa sandaling humingi ang isang tao ng kanilang data.
Isang makatotohanang panimulang punto
Para sa karamihan ng mga team na dumarating dito na gustong mag-automate, ang makatuwirang unang bersyon ay hindi nangangailangan ng engineering. Isang tao, isang batch bawat papasok na submission, at isang tala sa file tungkol sa kung ano ang nahanap nila.
Iyon ay nakakagawa ng isang bagay na mahalaga sa loob ng isang linggo: isang pakiramdam kung ano ang score ng iyong sariling materyal. Halos walang sinuman ang mayroon nito kapag nagsimula sila, at kung wala ito, anumang threshold na itatakda mo sa code ay hula lamang tungkol sa isang distribution na hindi mo pa nasusukat.
Kapag alam mo na kung saan naroroon ang iyong mga imahe, ang kaso para sa automation ay nagiging kongkreto sa halip na teoretikal. Malalaman mo kung ilang submission bawat linggo ang talagang nangangailangan ng pagsusuri, at madalas na ang sagot ay ginagawang hindi na kailangan ang engineering.
Kung saan hindi naman, hindi bababa sa mag-aautomate ka laban sa isang nasukat na baseline sa halip na sa isang inilathala, na siyang pagkakaiba sa pagitan ng control na gumagana sa iyong data at isa na gumagana sa benchmark ng iba.
Ano ang susukatin bago ka bumuo ng anuman
Tatlong numero ang nagpapabago sa isang malabong intensyon tungo sa isang specification, at ang tatlong ito ay nanggagaling sa pagpapatakbo ng mga batch nang manu-mano sa loob ng dalawang linggo.
Ang distribution ng sarili mong materyal: kung saan talaga napupunta ang mga tunay na imahe mula sa iyong mga normal na source. Halos bawat team ay nagugulat, kadalasan dahil ang kanilang mga input ay mas naproseso kaysa sa inaakala nila.
Ang sarili mong false positive rate: kung gaano kadalas na ang isang flag ay nagiging ordinaryong pagproseso kapag may nag-iimbestiga. Ito ang numerong nagpapasya kung ang isang control ay magagamit sa mga tunay na tao, at hindi ito kailanman ang numerong nasa pahina ng vendor.
Ang dami na talagang maba-flag: kung ilang item bawat linggo ang kailangang tingnan ng tao. Kung ang numerong iyon ay maliit, ang automation na pinaplano mo ay isang spreadsheet at isang nakagawian lang.